Software Development
Sumsub Integrate Travel Rule
End-to-end recipe for integrating Sumsub Travel Rule — deciding which of the three exchange flows applies, identifying the counterparty VASP, submitting the transfer, reading the exchange status, finalising or cancelling it, answering requests other VASPs send you, handling the unhosted-wallet path when no VASP is attributed, and finding existing transactions (deduplication before after-settlement exchanges). TRIGGER when the user asks to "integrate / add / implement Travel Rule", "send Travel Rule data with a withdrawal", "collect Travel Rule data for a deposit that already arrived", "respond to / answer incoming Travel Rule requests", asks why their exchanges sit at `onHold` or `completed` and never reach `finished`, why counterparties never answer, how to test Travel Rule in Sandbox, about "unhosted / self-hosted / non-custodial wallet verification", "prove the user owns the wallet", "Satoshi test", what happens on `counterpartyVaspNotFound` or `applicantKytTxnAwaitingUser`, or to "find / search transactions", "check whether a transaction already exists for this hash". SKIP for building the transaction payload itself (use `sumsub-create-transaction`), for writing the scoring rules that act on the outcome (use `sumsub-create-kyt-rules`), for bulk-registering wallet addresses (use `sumsub-manage-wallet-address-book`), and for KYC/AML work unrelated to transfers between VASPs.
- Publisher / source
- sumsub/agent-skills (found on skills.sh)
- Upstream record
- sumsub/agent-skills
- Version
- Version 1
- Published
- Publication review
- Approved for publication
- Content fingerprint
4f08b6e04b2428b4d62745aa26bbd9ede46bd4bfcb136c5407f6314ba979cdda