Crypto Travel Rule data
What is crypto Travel Rule data?
Crypto Travel Rule data is the originator and beneficiary information a regulated firm sends to the receiving firm when a customer’s crypto transfer goes from one to the other, the crypto version of the rule banks follow for wire transfers (often called the FATF Travel Rule).
Exchanges, custodian banks and custody platforms send it through a Travel Rule network, and their compliance teams have to show that every outgoing transfer that needed a message had one.
Goldsky spots each transfer leaving your wallets and delivers it to your systems; sending the messages stays with your Travel Rule provider, and matching transfers to messages and following up the gaps stay with your team.
You can build it two ways: stream every outgoing transfer from your wallets to your systems with Turbo Pipelines, or call the Feeds transfers API for each hot wallet’s outgoing transfers.
Who uses crypto Travel Rule data?
Crypto exchanges, custodian banks and custody and wallet platforms that send customer withdrawals to other regulated firms.
How crypto Travel Rule matching works
The diagram follows one customer withdrawal from the moment it’s booked to your team chasing any transfer left without a message, and shows who does each step. Your setup may differ.
Ways to match transfers to Travel Rule messages
The pipeline pushes each outgoing transfer from every wallet on your list as it’s detected; the transfers API returns one wallet’s transfers when your matching system calls it.
- Best for
- Many wallets, with each transfer pushed as it’s detected
- Products
- Turbo
- What you run
- The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
- What you write
- Pipeline YAML and SQL; TypeScript transforms when needed
- Where your data lives
- In your own database or systems
- How results reach you
- Pushed to you
- Best for
- A few hot wallets, checked on a timer
- Products
- Feeds
- What you run
- Nothing; you call an endpoint and keep what you need
- What you write
- REST requests
- Where your data lives
- Hosted by Goldsky
- How results reach you
- Returned when you call
| Usual setupOption 1: Stream outgoing transfers | Option 2: Wallet transfers API | |
|---|---|---|
| Best for | Many wallets, with each transfer pushed as it’s detected | A few hot wallets, checked on a timer |
| Products | Turbo | Feeds |
| What you run | The destination: your database, queue or bucket, or a Postgres database Goldsky hosts | Nothing; you call an endpoint and keep what you need |
| What you write | Pipeline YAML and SQL; TypeScript transforms when needed | REST requests |
| Where your data lives | In your own database or systems | Hosted by Goldsky |
| How results reach you | Pushed to you | Returned when you call |
Book the customer’s withdrawal
The withdrawal record holds who is sending, to whom and how much, which is what the message has to carry.
Your platform records the customer, the destination address, the receiving firm and the amount before anything is sent. If the receiving firm isn’t identified at this point, the message can’t be addressed, and the transfer goes out with nothing to match.
Send the Travel Rule message
The receiving firm needs the sender’s and the recipient’s details to run its own checks.
Your Travel Rule provider sends the originator and beneficiary details to the receiving firm over its network and keeps a record of what it sent and when. Open protocols such as the Travel Rule Protocol (TRP) send this message before the funds move, so the receiving firm can check the details and, where the protocol allows, turn the transfer down before it happens.
Send the funds from your wallet
The withdrawal itself moves on the chain, from one of your hot wallets to the receiving firm’s address.
Once the transaction is in a block, anyone can see it. For a short time the chain can still replace its newest blocks (a reorg), so a transfer seen once isn’t final yet.
Confirm the message with the transaction hash
The message went out before the transfer existed, so it has to be tied to the transfer once the funds are sent.
Your system passes the transaction hash to your Travel Rule provider once the transfer is sent, and the provider forwards it to the receiving firm as a confirmation of the message and records it beside the message. A message that never gets its hash leaves both firms matching by address and amount, which can pair the wrong transfers.
Spot every transfer leaving your wallets
Handled by Goldsky TurboYou can only match a message to a transfer you know about, so every outgoing transfer has to be caught.
The check covers every wallet you send from, including new ones, and records each transfer with its hash, sender, recipient, token and amount. A wallet left off the list sends transfers nobody checks.
With Goldsky, you can keep your wallet addresses in a Turbo Pipelines dynamic table, which lives in a Postgres database, and keep only transfers whose sender is on it with
Learn about dynamic tables (opens in a new tab)dynamic_table_check(). Adding a wallet is an insert into that table.Deliver each transfer to your matching system
Handled by Goldsky TurboYour matching system has to receive each transfer in a form it can act on.
Delivery can repeat after a network error, and a transfer undone by a reorg arrives later as a correction, so the receiving side needs a stable ID for each transfer. Without one, a repeat looks like a second withdrawal with no message.
The Turbo Pipelines webhook sink posts each row to your endpoint and retries until it gets a
Set up the webhook sink (opens in a new tab)2xxresponse. Your endpoint checks the row’sidbefore recording it and applies the correction records a reorg sends.Match each transfer to its message
A transfer with a matching message is covered; one without is a gap your team has to explain.
Your system pairs each transfer with the message whose confirmation carries the same transaction hash. A message still waiting for its hash, or a transfer whose hash no message carries, stays open in your records until the other side turns up or your team looks into it.
Chase the transfers left unmatched
An outgoing transfer without a message, or a message without a transfer, needs an explanation before your next review.
Your compliance team works through the exceptions: send a late message, correct a wrong one, or record why none was needed, such as a transfer below your threshold. Gaps left open pile up and are harder to explain the older they get.
What to know about streaming outgoing transfers
- Goldsky runs the pipeline; you run the endpoint or database it writes to and the code that matches transfers to messages.
- Transfers are pushed when they’re detected, before they’re final, so your matching decides how long to wait.
- A webhook endpoint can receive the same transfer twice and gets reorg corrections as separate records, so it deduplicates on the transfer
idand applies the corrections itself. - Your wallet list lives in a table the running pipeline reads, so adding a wallet needs no redeploy.
Book the customer’s withdrawal
The withdrawal record holds who is sending, to whom and how much, which is what the message has to carry.
Your platform records the customer, the destination address, the receiving firm and the amount before anything is sent. If the receiving firm isn’t identified at this point, the message can’t be addressed, and the transfer goes out with nothing to match.
Send the Travel Rule message
The receiving firm needs the sender’s and the recipient’s details to run its own checks.
Your Travel Rule provider sends the originator and beneficiary details to the receiving firm over its network and keeps a record of what it sent and when. Open protocols such as the Travel Rule Protocol (TRP) send this message before the funds move, so the receiving firm can check the details and, where the protocol allows, turn the transfer down before it happens.
Send the funds from your wallet
The withdrawal itself moves on the chain, from one of your hot wallets to the receiving firm’s address.
Once the transaction is in a block, anyone can see it. For a short time the chain can still replace its newest blocks (a reorg), so a transfer seen once isn’t final yet.
Confirm the message with the transaction hash
The message went out before the transfer existed, so it has to be tied to the transfer once the funds are sent.
Your system passes the transaction hash to your Travel Rule provider once the transfer is sent, and the provider forwards it to the receiving firm as a confirmation of the message and records it beside the message. A message that never gets its hash leaves both firms matching by address and amount, which can pair the wrong transfers.
Look up each hot wallet’s outgoing transfers
Handled by Goldsky FeedsYour matching system finds new withdrawals by fetching each wallet’s recent outgoing transfers.
The lookup covers every wallet you send from and every token you allow, for the window since the last check. A gap between windows, or a token left out, means a transfer is never checked.
Feeds returns a wallet’s native and ERC-20 transfers from its transfers endpoint, newest first. Ask with
Read the transfers endpoint reference (opens in a new tab)direction=outand afromtime just before your last check, and setinclude_unknown_price=trueso transfers of tokens with no price aren’t left out.Match each transfer to its message
A transfer with a matching message is covered; one without is a gap your team has to explain.
Your system pairs each transfer with the message whose confirmation carries the same transaction hash. A message still waiting for its hash, or a transfer whose hash no message carries, stays open in your records until the other side turns up or your team looks into it.
Chase the transfers left unmatched
An outgoing transfer without a message, or a message without a transfer, needs an explanation before your next review.
Your compliance team works through the exceptions: send a late message, correct a wrong one, or record why none was needed, such as a transfer below your threshold. Gaps left open pile up and are harder to explain the older they get.
What to know about using a wallet transfers API
- Your system pulls, so a transfer is matched only after your next call, and how current the check is depends on how often you call.
- Each request covers one wallet, so the number of calls grows with the number of wallets you send from.
- A transfer undone by a reorg stops appearing in responses with no flag, so your matching re-checks recent transfers before closing them.
- Native and ERC-20 transfers are covered; other token types need a different source.
Related jobs
Find out whether the other side is self-hosted
A transfer to another regulated firm carries a Travel Rule message; a wallet your customer runs has nobody to receive one.
Your Travel Rule provider checks whether a regulated firm runs the address, using identifiers from its messaging network, blockchain analytics and other data providers. Where none of them can tell, you ask your customer.
Collect the sender and recipient details
With no firm on the other side, the details a message would carry come from your own customer.
Your customer gives the details for both sides of the transfer, and you keep them with the transfer so it can be identified later. A transfer with no details recorded can’t be shown to have been checked.
Ask the customer to prove they control the wallet
Above the threshold your rules set, you confirm that the self-hosted wallet really is your customer’s.
Common ways are a message signed with the wallet’s key, or a small amount you set, sent from the wallet to an address of yours. The right method depends on what the wallet can do and how risky the transfer is, so record which one you used.
Receive the test payment
Only whoever holds the wallet’s key can send a payment from it.
The test amount moves from the customer’s wallet to your address like any other transfer. For a short time the chain can still replace its newest blocks (a reorg), so a payment seen once isn’t final yet.
Spot the test payment from the wallet under review
Handled by Goldsky TurboYour team needs to know as soon as the payment arrives from the wallet being checked, and from no other.
The check matches the sender to the wallet under review, the recipient to your address and the amount to what you asked for. A payment from a different wallet, or of a different amount, proves nothing, and a repeated delivery mustn’t count twice.
With Goldsky, the wallets under review can sit in a Turbo Pipelines dynamic table, so the pipeline keeps only transfers whose
Learn about dynamic tables (opens in a new tab)senderis on it and whoserecipientis your test address. The webhook sink posts each match to your endpoint, which ignores a rowidit has already recorded.Mark the wallet verified and keep the record
Once you’re satisfied the wallet is your customer’s, later transfers to it needn’t repeat the check.
Record the wallet, the method and the result, then release or hold the transfer under your rules. Keep watching a verified wallet’s risk, and take it off your verified list if there are signs your customer no longer controls it.
What you control
- Your team
- Book the customer’s withdrawal
- Match each transfer to its message
- Chase the transfers left unmatched
- Your providers
- Travel Rule provider
Questions and answers
What is the Travel Rule in crypto?
The Travel Rule requires regulated crypto firms, such as exchanges and custodians, to send identifying details about the sender and the recipient along with a transfer to another regulated firm. It applies to crypto the rule banks already follow for wire transfers, under a standard set by the Financial Action Task Force (FATF) that each country writes into its own law. Thresholds, which transfers are covered and the details required vary by country.
What is Travel Rule compliance?
Travel Rule compliance means sending the required sender and recipient details with each covered outgoing transfer, receiving them for incoming ones, and being able to show which transfers had a message. Firms usually exchange the messages through a Travel Rule provider, and their compliance teams decide which transfers are covered. Matching each outgoing transfer on the chain to its message is how a team finds the transfers that went without one.
Does the Travel Rule apply to self-hosted wallets?
In the EU it does: the Transfer of Funds Regulation covers transfers between a crypto-asset service provider (CASP) and a self-hosted wallet, one no regulated firm runs. The provider collects the sender and recipient details from its own customer, and for transfers over EUR 1,000 it checks that the customer owns or controls the wallet, for example with a signed message or a small test payment, as the European Banking Authority’s Travel Rule guidelines describe. Other countries set their own rules.
Security and deployment
- SOC 2 Type IIIndependently audited security controls.
- Dedicated infrastructureSingle-tenant options for production workloads.
- Data residencyCloud, on-premises or co-located.
Use cases built the same way
- Stablecoin wallet top-upsCredit a user’s app balance when a stablecoin transfer to their embedded wallet confirms.
- Accept stablecoin paymentsConfirm stablecoin payments from shoppers and mark the order paid.
- Stablecoin off-rampsDetect the stablecoin a customer sends to cash out, so the provider can pay fiat to their bank account or card.
- Stablecoin subscription paymentsConfirm each scheduled stablecoin charge onchain and mark the subscription paid.
Match outgoing transfers to Travel Rule messages with Goldsky
We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.
Robinhood
HyperEVM
Arc
Solana
Ethereum
Polymarket
Base
Tempo
Bitcoin
