Travel Rule · FATF Rec.16 · EU TFR

Originator and beneficiary data travels with the transfer

We exchange data with the counterparty provider over the right protocol, verify ownership of unhosted wallets and hold the transfer until a response arrives, if you configure it that way.

Originator · you
[your exchange]
LEI [code]
Beneficiary
[other VASP]
or an unhosted wallet
protocol: TRP
Transfer created
Data sent
Beneficiary found
Data matched
Transfer approved
ProtocolsTRPGTRTRUSTVerifyVASPSygnaEmailInternal

Originator and beneficiary

NameWalletDate of birthVASP or self-hostedNationalityProvider nameAddressLEI

Threshold, timeout, action

The amount that triggers the rule, how strict name matching is, how long to wait for a response and what to do if none comes.

HOLD — keep on holdREJECT — declinePROCEED — let through

Check the beneficiary's wallet

From the transfer card, launch an agent investigation of the beneficiary's wallet in one click and attach it to the case.

How the agent works →

Problem transfers, with the deadline in plain sight

Transfers on hold, mismatched data, a provider that can't be found or isn't responding: all of it lands in one queue with a countdown. Match, send a reminder, release the hold, resend or cancel right from there.

TransferStatusDeadline
[amount] → [VASP]On hold
[--:--]
[amount] → unhostedOwnership not confirmed
[--:--]
[amount] → [VASP]Data mismatch
[--:--]
[amount] → [VASP]Provider not responding
[--:--]
matchremindrelease holdresendcancel

Client wallet book

The client confirms once that the wallet is theirs. After that, transfers to the address don't get stuck in the queue.

bc1q…ownership confirmed
0x…ownership confirmed
T…awaiting confirmation

Travel Rule without manual back-and-forth with other exchanges

API, webhooks and a real-time status stream. You can give your team read-only access.

No spam. Your data is securely protected.