The EU Transfer of Funds Regulation (TFR) requires VASPs to exchange originator and beneficiary information for crypto transfers. Striga is the VASP of record for transfers on your accounts and coordinates the required TFR messaging with the counterparty VASP.

For each external address an end user transacts with, we are legally obliged to collect information on the address, who owns it, what chain it lives on, and (above the EUR threshold) whether the user controls it. You have two ways to provide this information.

Integration paths

Counterparty API. Pre-declare every external address from your backend before the user transacts with it. Server-to-server, HMAC-authenticated. Use this whenever you can. You must prompt the end user to provide declaration details in your application UI. Submit only values the user has entered or confirmed. Do not populate yourself. Reown SDK is recommended for signature verification. Counterparties are identified by an on-chain counterpartyAddress or, for Lightning, by paymentHash — or a bolt11 invoice, which Striga decodes to its payment hash (see Lightning). Addresses are matched case-insensitively — declare in any casing.

Widget. Create a session, open the Striga-hosted widget in the user's browser, and let it collect the declaration. The widget renders inside an iframe, popup, or mobile WebView, so its behaviour can vary with the embedding environment. Use this only when you cannot host the declaration UX yourself.

The rest of this guide focuses on the API path. Widget specifics are at the end.

Decision flow

Deposit

Withrawal

Once the destination is declared ,Striga matches the originating address against the user's declared counterparties.

Withdrawal outcomes

Counterparty	Transaction amount	Signature / counterparty user info	Code	Result
VASP	Any	Counterparty user info on file	—	Proceeds. TFR sent to receiving VASP.
VASP	Any	No counterparty user info	42008	Create counterparty user info; retry.
OWNED	Under 1000 EUR	n/a	—	Proceeds.
OWNED	≥ 1000 EUR	Wallet ownership verified: Yes	—	Proceeds.
OWNED	≥ 1000 EUR	Wallet ownership verified: No	42002	Verify wallet ownership and retry.
THIRD_PARTY	Under 1000 EUR	n/a	—	Proceeds.
THIRD_PARTY	≥ 1000 EUR	n/a	42004	Blocked.

Deposit outcomes

Counterparty for source	Transaction amount	Signature / counterparty user info	Result
VASP	Any	Counterparty user info required per transaction	Held. `VASP_COUNTERPARTY_USER_INFO_REQUIRED` webhook. Create counterparty user info and link it to the transaction.
OWNED	Under 1000 EUR	n/a	Credited.
OWNED	≥ 1000 EUR	Wallet ownership verified: Yes	Credited.
OWNED	≥ 1000 EUR	Wallet ownership verified: No	Held (`WALLET_VERIFICATION_REQUIRED`). Verify wallet ownership via `POST /counterparty/self-hosted/verify-wallet` or the widget; credit releases automatically.
THIRD_PARTY	Under 1000 EUR	n/a	Credited.
THIRD_PARTY	≥ 1000 EUR	n/a	Held / blocked (`BLOCKED_DUE_TO_TRAVEL_RULE`).

When the TFR message reaches us before the on-chain confirmation, the deposit credits as soon as the chain confirms.

Lightning: for Lightning counterparties the source/destination is identified by paymentHash rather than an on-chain address — the outcome rules above still apply. See Lightning.

Special case: VASP counterparties

VASPs typically issue one deposit address per user , but on the chain withdrawals that address can be reused across many sends. Because of that asymmetry, Striga handles VASP counterparties differently from self-hosted OWNED / THIRD_PARTY:

Withdrawals to a VASP

Declare the address once with the VASP's counterpartyVaspId on POST /counterparty/vasp.
Create the per-transaction VASP counterparty user info record separately via POST /counterparty/vasp/counterparty-user-info; it identifies the beneficiary for withdrawals to that address.
If the VASP counterparty has no counterparty user info record when you try to withdraw, the call returns 42008 Travel rule VASP counterparty user info required. Create a record and retry.

Deposits from a VASP

Even with the sending address already declared as a VASP counterparty, every incoming deposit is held. VASPs reuse the same on-chain deposit address for many of their users, so the originator PII must be identified per transaction — the counterparty alone is not enough.
You receive a VASP_COUNTERPARTY_USER_INFO_REQUIRED webhook (or the held deposit is matched automatically if the originating VASP's TFR message arrives first).
Resolve by either:
- POST /counterparty/vasp/counterparty-user-info to create the originator record, then POST /counterparty/vasp/counterparty-user-info/link with the held deposit's txHash (or paymentHash for Lightning), or
- Start a widget session scoped to the held deposit by passing txHash on POST /widget/sessions.
The deposit then goes through compliance review before credit. If the originating VASP's TFR message arrives at any time, the hold releases automatically.

Cheat sheet

Direction	VASP counterparty user info needed	When
Withdraw	Once per counterparty	Create before first send.
Deposit	Once per transaction	Create + link per held `txHash` (or widget).

Travel Rule webhooks

All Travel Rule webhooks are delivered on the TRANSACTION channel. Dispatch on the inner type field. Owner identity is conveyed by userId (consumer) or businessId (business).

These events are separate from the standard deposit and withdrawal TRANSACTION webhooks you receive when funds actually move after a hold clears.

Travel Rule hold webhooks are sent immediately when the hold is placed — there is no grace-period delay.

Event types

`type`	When
`COUNTERPARTY_DECLARATION_REQUIRED`	A held deposit's source address has no declaration for this user.
`WALLET_VERIFICATION_REQUIRED`	A held deposit needs wallet-ownership proof for an `OWNED` self-hosted counterparty above threshold.
`VASP_COUNTERPARTY_USER_INFO_REQUIRED`	A held deposit from a declared VASP needs per-transaction originator counterparty user info created + linked.
`BLOCKED_DUE_TO_TRAVEL_RULE`	The transfer is blocked (e.g. third-party self-hosted at/above threshold).
`USER_ACTION_COMPLETED_FOR_TRAVEL_RULE`	The user action a held deposit was waiting on completed (declaration made, counterparty-user-info linked, or wallet ownership verified) — the hold's blocking condition is satisfied.
`WALLET_VERIFICATION_FAILED`	A Sumsub liveness wallet verification terminally failed (non-retryable). Prompt the user to start verification again.

Payload shapes

Shape	Identified by	Sent by
Hold placed	`txHash`, `sourceAddress`, `destinationAddress` (or `counterpartyAddress` on `VASP_COUNTERPARTY_USER_INFO_REQUIRED`)	Deposit pause (`type` reflects the required action)
Completion	`txId`, `txHash` (or `paymentHash`), `counterpartyId`, `memo`	`USER_ACTION_COMPLETED_FOR_TRAVEL_RULE`
Verification failure	`walletVerificationId`, `address`, `network`, `method`, `memo`	`WALLET_VERIFICATION_FAILED`

Deposit-hold webhooks

When an incoming deposit is placed on a Travel Rule hold, Striga immediately sends one webhook whose type reflects the required action — COUNTERPARTY_DECLARATION_REQUIRED, WALLET_VERIFICATION_REQUIRED, VASP_COUNTERPARTY_USER_INFO_REQUIRED, or BLOCKED_DUE_TO_TRAVEL_RULE.

Action: Surface the required action to the user and resolve it via the counterparty API or widget. Withdrawals return the equivalent error code synchronously instead (see Error codes).

Example (COUNTERPARTY_DECLARATION_REQUIRED):

{
  "type": "COUNTERPARTY_DECLARATION_REQUIRED",
  "userId": "940f999e-3625-47d2-baaa-c024814bd583",
  "txHash": "37a159ccf7632906a628316e267b7874d9b24d828e6867fd2cc7d1fed4a778ee",
  "currency": "USDC",
  "network": "ETH",
  "amountInSmallestUnit": "10",
  "sourceAddress": "0xaF36412aFE05241a5237E9899706de11F0695112",
  "destinationAddress": "0x20936Ee3f762677494ace0C1f9f22bCd3017461A"
}

counterpartyId is included only when a counterparty record already exists for the source address.

`VASP_COUNTERPARTY_USER_INFO_REQUIRED`

A held deposit from a declared VASP counterparty needs per-transaction originator counterparty user info created and linked to that transaction. Also re-sent for outstanding held deposits when you declare the VASP counterparty after the fact.

Action: Create the originator record (POST /counterparty/vasp/counterparty-user-info) and link it to the held transaction (POST /counterparty/vasp/counterparty-user-info/link with txHash, or paymentHash for Lightning), or guide the user through the widget.

Example:

{
  "type": "VASP_COUNTERPARTY_USER_INFO_REQUIRED",
  "txId": "bf4dbe08-2cb6-43c2-9892-a887e8f4937f",
  "counterpartyAddress": "0xaF36412aFE05241a5237E9899706de11F0695112",
  "txHash": "37a159ccf7632906a628316e267b7874d9b24d828e6867fd2cc7d1fed4a778ee",
  "userId": "940f999e-3625-47d2-baaa-c024814bd583",
  "counterpartyId": "9808388e-bd29-4110-b5d3-b183b59ca49e",
  "currency": "USDC",
  "network": "ETH",
  "amountInSmallestUnit": "10",
  "memo": "Travel Rule VASP counterparty user info required for transaction(txId: bf4dbe08-2cb6-43c2-9892-a887e8f4937f) to be completed."
}

For a Lightning deposit, counterpartyAddress and txHash are replaced by paymentHash.

`USER_ACTION_COMPLETED_FOR_TRAVEL_RULE`

Sent when the user action a held deposit was waiting on completes — a counterparty was declared (self-hosted or VASP) while deposits were held, VASP counterparty user info was linked to a held transaction, or wallet ownership was verified for a held OWNED deposit. The hold's blocking condition is satisfied.

Action: None for this step. The user's obligation for that hold is satisfied; the deposit may still wait for the Travel Rule message or other compliance before credit.

Example (on-chain):

{
  "type": "USER_ACTION_COMPLETED_FOR_TRAVEL_RULE",
  "txId": "bf4dbe08-2cb6-43c2-9892-a887e8f4937f",
  "txHash": "37a159ccf7632906a628316e267b7874d9b24d828e6867fd2cc7d1fed4a778ee",
  "sourceAddress": "0xaF36412aFE05241a5237E9899706de11F0695112",
  "destinationAddress": "0x20936Ee3f762677494ace0C1f9f22bCd3017461A",
  "userId": "940f999e-3625-47d2-baaa-c024814bd583",
  "counterpartyId": "9808388e-bd29-4110-b5d3-b183b59ca49e",
  "currency": "USDC",
  "network": "ETH",
  "amountInSmallestUnit": "10",
  "memo": "Travel Rule user action completed for transaction(txId: bf4dbe08-2cb6-43c2-9892-a887e8f4937f)."
}

For a Lightning deposit, the locator collapses to a single paymentHash (no sourceAddress / destinationAddress / txHash):

{
  "type": "USER_ACTION_COMPLETED_FOR_TRAVEL_RULE",
  "txId": "bf4dbe08-2cb6-43c2-9892-a887e8f4937f",
  "paymentHash": "8ac740817d5f7794f550764945c3ac35f830364ea11e8427e36cf0319d0e3f71",
  "userId": "940f999e-3625-47d2-baaa-c024814bd583",
  "counterpartyId": "9808388e-bd29-4110-b5d3-b183b59ca49e",
  "currency": "BTC",
  "network": "BTC",
  "amountInSmallestUnit": "1500",
  "memo": "Travel Rule user action completed for transaction(txId: bf4dbe08-2cb6-43c2-9892-a887e8f4937f)."
}

Wallet-signature verification is synchronous, not a webhook. POST /counterparty/self-hosted/verify-wallet returns the result in its HTTP response — { "status": "VERIFIED", "walletVerificationId": "<uuid>", "counterparty": { ... } }. When the verified address has deposits on hold, those settle and emit USER_ACTION_COMPLETED_FOR_TRAVEL_RULE as above; expect normal TRANSACTION credit webhooks once each deposit clears.

`WALLET_VERIFICATION_FAILED`

A wallet verification submitted through Sumsub liveness reached a terminal, non-retryable failure. Notification-only — no hold or balance changes.

Action: Surface to the user and let them start verification again.

Example:

{
  "type": "WALLET_VERIFICATION_FAILED",
  "userId": "940f999e-3625-47d2-baaa-c024814bd583",
  "walletVerificationId": "b2808090-f12a-48fc-8a7e-ddc77adb3a9e",
  "counterpartyId": "9808388e-bd29-4110-b5d3-b183b59ca49e",
  "address": "0xaF36412aFE05241a5237E9899706de11F0695112",
  "network": "Ethereum",
  "method": "SUMSUB_LIVENESS",
  "memo": "Travel Rule SumSub liveness wallet verification failed (walletVerificationId: b2808090-f12a-48fc-8a7e-ddc77adb3a9e). The user can start verification again."
}

Retryable Sumsub outcomes do not emit this webhook. Wallet-signature verification never produces it — it completes synchronously through the verify-wallet HTTP response. Verification applies to on-chain addresses only — Lightning paymentHash counterparties have no signable wallet (see Lightning).

Widget

If you choose to delegate the declaration UX to Striga, create a session from your backend and render the returned URL in the user's browser.

POST /api/v1/travel-rule/widget/sessions
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "currency": "ETH",
  "network": "ETH",
  "counterpartyAddress": "0xabc..."
}

Response:

{
  "sessionId": "widget_session_<...>",
  "token": "<jwt>",
  "widgetUrl": "https://<widget-host>/<sessionId>?token=<token>",
  "expiresAt": "<ISO date>"
}

Open widgetUrl in an iframe, popup, or WebView. The widget walks the user through the declaration and any signature or liveness verification, then closes. Track completion through the webhooks above. Optionally scope the session to a specific held deposit by passing txHash.

For standing orders

Declare the counterparty address via the counterparty API or widget before you create the standing order. If the standing order uses crypto as the source, that crypto must already meet Travel Rule when it was deposited—declare the source address or handle COUNTERPARTY_DECLARATION_REQUIRED webhooks as in the deposit outcomes table.

Lightning

Lightning counterparties follow the same Travel Rule model as on-chain BTC, with one structural difference: a Lightning payment has no reusable on-chain destination address, so the counterparty is identified by the payment hash of the invoice rather than a wallet address.

Identifying a Lightning counterparty: `paymentHash` or `invoice`

Everywhere the counterparty API and webhooks accept or return counterpartyAddress for on-chain transfers, Lightning uses paymentHash instead:

paymentHash — the 64-character hex payment hash (the 32-byte Lightning payment hash, hex-encoded) of the invoice. Lowercased on storage; submit in any casing.
invoice — alternatively, submit the bolt11 Lightning invoice and Striga decodes it server-side to its payment hash. The counterparty is stored and echoed back by the resulting paymentHash.
Valid on Bitcoin only: declare with currency: BTC and network: BTC.
On every declaration and link endpoint, provide exactly one of counterpartyAddress (on-chain), paymentHash (Lightning), or invoice (Lightning bolt11). They are mutually exclusive — sending more than one, or none, fails with 42005.
Counterparty responses echo back only the field that applies: a Lightning counterparty has paymentHash set and counterpartyAddress omitted; an on-chain counterparty has counterpartyAddress set and paymentHash omitted.

Declaring a Lightning counterparty

Use the same declaration endpoints as on-chain — POST /counterparty/self-hosted (for OWNED / THIRD_PARTY) and POST /counterparty/vasp — passing paymentHash (or invoice) in place of counterpartyAddress:

POST /api/v1/travel-rule/counterparty/self-hosted
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "invoice": "...",
  "currency": "BTC",
  "network": "BTC",
  "subType": "THIRD_PARTY",
  "entityType": "NATURAL",
  "firstName": "Jane",
  "lastName": "Doe",
  "country": "DE"
}

Response (201) — note paymentHash is returned and counterpartyAddress is absent:

{
  "counterpartyId": "9808388e-bd29-4110-b5d3-b183b59ca49e",
  "userId": "<uuid>",
  "identityType": "CONSUMER",
  "paymentHash": "8ac740817d5f7794f550764945c3ac35f830364ea11e8427e36cf0319d0e3f71",
  "blockchain": "Btc",
  "type": "SELF_HOSTED",
  "subType": "THIRD_PARTY",
  "disabled": false,
  "declaredAt": "2026-05-15T12:00:00.000Z",
  "createdAt": "2026-05-15T12:00:00.000Z",
  "updatedAt": "2026-05-15T12:00:00.000Z"
}

A VASP Lightning counterparty is declared the same way on POST /counterparty/vasp, passing paymentHash (or invoice) plus counterpartyVaspId.

No wallet-ownership proof for Lightning

A Lightning payment hash is not a signable wallet, so wallet-ownership proof is not supported for paymentHash / invoice declarations:

The POST /counterparty/self-hosted/verify-wallet flow (wallet signature) and Sumsub liveness do not apply to Lightning counterparties.

This has no practical impact on OWNED flows, because any Lightning transfer at or above the threshold is rejected outright (see Limit rule) — so ownership verification, which is only required at or above the threshold, never comes into play for Lightning.

Linking VASP counterparty user info to a Lightning transaction

When per-transaction originator counterparty user info is required for a Lightning deposit from a VASP, link the counterparty user info record by paymentHash (or invoice) instead of txHash:

POST /api/v1/travel-rule/counterparty/vasp/counterparty-user-info/link
Authorization: <HMAC>

{
  "userId": "<uuid>",
  "vaspCounterpartyUserInfoId": "<uuid>",
  "paymentHash": "8ac740817d5f7794f550764945c3ac35f830364ea11e8427e36cf0319d0e3f71"
}

txHash, paymentHash, and invoice are mutually exclusive here too — provide exactly one.

Lightning in webhooks

Travel Rule webhooks for Lightning deposits carry paymentHash in place of the on-chain counterpartyAddress / txHash locators (txId and memo are unchanged). Match held Lightning deposits to your declaration by paymentHash. See the transaction-scoped example above.

Limit rule

Lightning payins and payouts follow the same withdrawal and deposit outcome rules as on-chain transfers, with one exception:

Any Lightning payin or payout at or above the 1000 EUR equivalent limit is always rejected with 42004.

Declare the recipient (the node behind the Lightning invoice your user pays) and provide any required VASP counterparty user info before the user initiates a below-threshold Lightning withdrawal — using the same counterparty API or widget flow as for other crypto addresses. Striga applies the same checks as for an on-chain withdrawal: declaration required (42001), third-party blocks at or above the limit (42004), and VASP counterparty user info where applicable (42008).

Currency and network

Both fields are required on the counterparty endpoints and must form a valid pair.

`currency`	`network`
`BTC`	`BTC`
`ETH`	`ETH`
`USDC`	`ETH`
`BNB`	`BSC`
`POL`	`POLYGON`
`MATIC_POLYGON`	`POLYGON`
`USDC_POLYGON`	`POLYGON`
`SOL`	`SOL`
`USDC_SOL`	`SOL`

Lightning counterparties use the BTC / BTC pair and supply paymentHash (or invoice) instead of counterpartyAddress.

Error codes

Code	Meaning
`42001`	Declare a counterparty for this address, then retry.
`42002`	`OWNED` address exceeded the EUR threshold. Verify wallet ownership via `POST /counterparty/self-hosted/verify-wallet`.
`42003`	Travel Rule message rejected by the beneficiary VASP.
`42004`	`THIRD_PARTY` address (or any Lightning transfer) exceeded the EUR threshold. Blocked.
`42005`	Travel Rule evaluation failed, signature invalid, or declaration payload invalid (e.g. more than one of `counterpartyAddress`, `paymentHash`, `invoice`, or none provided). Check the response message.
`42006`	Counterparty not found for the given identifier.
`42007`	Travel Rule application configuration not found.
`42008`	Travel rule VASP counterparty user info required for this transaction.