Deposits

A deposit to one of your customers starts in one of two ways, and each has its own page. Either its Travel Rule data arrives first and you deal with it before the funds land, or the funds land first with no data to explain them.

1. Travel Rule data first: The Travel Rule data arrives (transfer.created.v3, Notabene, to your webhook endpoint). An incoming transfer, usually before the funds: Travel Rule data first.
2. Travel Rule data first: Answer what is asked (Notabene, and you when needed). The address, and the name or compliance checks you turned on: Travel Rule data first.
3. Travel Rule data first: Your policies approve it, or your team reviews it (Your policy engine, or your compliance team). As for any transfer: Travel Rule data first.
4. Travel Rule data first: The sender settles, and you match the deposit and credit your customer (GET /api/v1/transfers/match, The sending institution, then your backend). Look up the deposit within your window: Looking for the transfer of a deposit. Each step, with its calls: Continues in: Deposits, Travel Rule data first.
5. Funds first: The funds land on chain (Your wallet). A deposit no transfer explains: Funds first.
6. Funds first: Look for its transfer (GET /api/v1/transfers/match, Your backend). Retry within your window: Looking for the transfer of a deposit.
7. Funds first: No transfer, so you create it (POST /api/v1/transfers, Your backend, then your customer). Ask the sending institution, or record the sender your customer declares: Funds first.
8. Funds first: Credit your customer (transfer.status_changed.v3, Your backend). Each step, with its calls: Continues in: Deposits, funds first.

Travel Rule data first

The sending institution creates a transfer to your customer’s address, and once its own policies have approved it, your webhook endpoint receives transfer.created.v3 with direction set to Incoming. At that point the funds have usually not been sent yet.

Notabene confirms the deposit address by itself when you registered it, and asks you otherwise. The sender’s personal data only arrives after that, and if you match names or run your own compliance check, you report the result. Your policies then approve the transfer or flag it for your team, and once the funds land, you match them to the transfer and credit your customer.

Deposits, Travel Rule data first takes you through each step.

Funds first

Your wallet sees a deposit to one of your customers’ addresses, and the lookup finds no transfer for it within your retry window. You then create the transfer yourself: ask the sending institution for its data, or record the sender your customer declares. Once your policies approve it and every institution has authorized it, you credit your customer.

Deposits, funds first takes you through each step.

Looking for the transfer of a deposit

Look up every deposit your wallet receives with GET /api/v1/transfers/match, whichever way it started, and do not expect it to find a transfer right away. Travel Rule data can still arrive after the funds, and a sending institution records the transaction hash only once it sees its withdrawal complete on chain. Until then, the lookup comes back empty.

Call the lookup as soon as the deposit arrives, and retry it with a back-off while nothing is found. Stop after a retry window you define rather than retrying indefinitely. If nothing has matched by then, treat the deposit as having arrived without Travel Rule data, and ask your customer where the funds came from.

For assets that use a destination tag or a memo, such as XRPL or Stellar, add memo_tag to the lookup.