A Travel Rule workflow is the sequence a payment provider runs so that sender and recipient identity data travels with a crypto transfer: collect the data, validate it, screen the parties, then release the transfer, hold it for a fix, return it, or reject it. Each outcome needs a written trigger, a clock and a log entry.
The rule, with thresholds and data fields by country, is in guidelines for the Travel Rule. This post covers what happens after a transfer fails a check.
What is the order of a Travel Rule workflow?
The checks run as a gate in front of settlement, and funds move only after the last one passes. A check after release is a report, not a control, because a confirmed stablecoin transfer cannot be pulled back (are stablecoin payments reversible).
The six gates of a Travel Rule workflow, in the order they run, and what a failure at each one produces.
Gate | What runs | If it fails |
1. Classify the counterparty | Decide whether the other side is a VASP (virtual asset service provider, the FATF term), a self-hosted wallet, or unknown | Treat as unknown and hold |
2. Collect the data | Originator and beneficiary fields, mostly from onboarding records | Hold and ask |
3. Validate it | Required fields present, formats valid, no placeholders such as "N/A", beneficiary name matches your own record | Hold and ask |
4. Screen the parties | Names, wallet addresses and the counterparty against sanctions lists | Stop and escalate, which is a different procedure from a hold |
5. Exchange or prove | Send the data to the counterparty provider and wait for acknowledgement, or get proof that the customer controls a self-hosted address | Hold, then reject when the window closes |
6. Release and log | Funds move, and the data, the screening result, the decision and its decider are logged with a time | Not applicable |
Gate 4 is not a softer gate 2. A missing field is a service problem and a sanctions hit a legal one, so keep separate queues.
On Lumx, the customer's KYC (know your customer, the verification of an individual) or KYB (know your business, the verification of a company and its owners) is complete before any transaction, and KYC runs through Sumsub. Every payout is tied to a registered destination and carries a purpose, and an on-ramp or off-ramp flagged by Chainalysis monitoring is held for review. Lumx screens every transaction, inbound and outbound, before it executes, and it is aligned with the Travel Rule. The destination wallet addresses are due to become destinations in the API, like fiat destination accounts, with no date yet.
What data do you collect, and at which point?
Collect identity data once, at onboarding, and take per-transfer data only where it changes.
Which Travel Rule data belongs to onboarding, which to the transfer, and where it sits in a Lumx integration.
Data | Collected at | Where it sits in Lumx |
Originator name, address, tax ID | Onboarding | The customer's KYC or KYB record, complete before the customer can transact |
Ownership and control of a company | Onboarding | KYB documents from the representative, the UBOs and any shareholder above 25% |
Beneficiary name and bank details | Per payee, reused | The destination, tied to one customer |
Relationship between originator and beneficiary | Per payee | The destination's holder relationship, such as |
Reason for the payment | Per transaction | The |
External wallet address | Per transfer | The |
Thresholds change how much data a regime insists on, not the order of the gates. The US rule, read today in 31 CFR 1010.410(f), applies to a transmittal of funds of $3,000 or more, and FinCEN applies it to convertible virtual currency through its May 9, 2019 guidance (FIN-2019-G001), not through separate text in the CFR. The EU rule in Regulation (EU) 2023/1113 of May 31, 2023 applies to crypto-asset transfers with no minimum, and adds measures for transfers with a self-hosted wallet above EUR 1,000. Brazil, Mexico and the UK, Lumx's core corridors, are not covered here: the country detail is in the guide linked above. Supported jurisdictions are on the supported countries page.
On Lumx, these fields are not a form your user fills in at payment time. KYB asks for formation documents, proof of address and transactional information (source of funds, expected volume, counterparties) before approval, and the destination records who receives the money. The purpose has nine values, and the docs say a mismatch can hold up the transaction or trigger an RFI (request for information, a compliance hold that asks for a document before a transaction clears). What KYB verifies is explained in what KYB is.
Hold, return or reject: three different outcomes
A hold pauses a transfer that has not settled or a credit not yet released. A return sends back funds that already arrived. A reject refuses the transfer before it is accepted. Give each failure exactly one. An outbound transfer can still be stopped, while an inbound one has landed, so hold the credit, ask the sender's provider, and return if no answer comes.
Nine failure cases in a Travel Rule workflow, by direction, with the default outcome and the evidence to keep.
Case | Direction | Default outcome | Evidence to log |
Beneficiary name or address missing | Outbound | Hold, ask the customer, reject when the window closes | Request, reply or timeout, decision |
Counterparty provider cannot receive the data | Outbound | Hold, then reject or proceed under a written exception | Counterparty assessment, clause applied, approver |
Sanctions match on a party or address | Outbound | Stop and escalate to the sanctions procedure, no release and no return | Screening hit, match review, outcome |
Self-hosted wallet with no proof of control | Outbound | Hold until the customer proves control | Proof method, result, time |
No Travel Rule data with the funds | Inbound | Hold the credit, ask the originating provider | Request time, reply |
Beneficiary name does not match your customer | Inbound | Hold, ask, return to the sending address when the window closes | Mismatch detail, correspondence, return reference |
Same counterparty keeps sending incomplete data | Inbound | Escalate the relationship review, restrict or end it | Counterparty history, decision |
Funds arrive after the payment window expired | Inbound | Return to the original sender, no conversion | Expiry time, return reference |
Sanctions match on an inbound sender | Inbound | Hold, do not credit, escalate | Screening hit, review, outcome |
Return to the address or account the funds came from, never to a new one a sender asks for, because redirection is the oldest move in laundering. Store the return reference next to the original transaction.
Lumx documents two inbound behaviours, and neither is a Travel Rule-specific return policy. A fiat deposit that lands after an on-ramp has expired is not processed, and the funds are refunded to the original sender on the same rail used for the deposit. A transaction held by transaction monitoring goes to manual review, and if the answer to Lumx compliance does not arrive within 24 hours the transaction may be refunded to the sender. That window applies to every transaction.
Clocks, logs and tests
Every hold needs a deadline written before the hold exists, or it turns into an exception granted by whoever is loudest. Set the window by the slowest counterparty reply in your own logs, not by a round number.
The log is what makes the outcome defensible. For each decision, keep the data exchanged, the counterparty, the screening result, the outcome and the timestamps, plus who or what decided. See AML compliance for stablecoin fintechs.
Test it. Run the cases in the table above through the live logic on a schedule and after every change to rules or vendors, and check each produces the expected outcome and a complete log entry. Track the share of outbound transfers with complete data, counterparty acknowledgement rate, median hold time and returns.
An illustration, not a Lumx policy: for a missing beneficiary name on an outbound transfer, ask at hour 0, remind at hour 24, reject at hour 72. For an inbound credit with no data, ask the originating provider at once and return to the sending address at day 5. A sanctions match has no clock.
Lumx gives the integrator a status trail for this log. Off-ramps move through TRANSFERRING_STABLECOIN, TRADING and TRANSFERRING_FIAT to SUCCESS, with offramp.success and offramp.failed webhooks, and customers and destinations have their own events such as customer.rfi and destinations.final_rejection. Store the event ID next to your own decision so the two records join. The transaction RFI arrives by email or Slack today, with an API for it due between the end of 2026 and the first quarter of 2027, so its reply time is yours to log.
Counterparty providers and self-hosted wallets
A counterparty VASP (the provider on the other side) is a correspondent and deserves due diligence. Before sending volume, confirm that it is licensed or registered somewhere you can verify, can exchange Travel Rule data, has no sanctions concern in its owners or jurisdiction, and that its country enforces the rule. Then check your logs for how many of its messages arrived complete, and re-score it on a schedule. What the category covers is in what a VASP is.
A self-hosted wallet has no provider to exchange data with, so the workflow keeps your own customer's information and, where the regime asks, gets proof that the customer controls the address, usually a signed message from the wallet. The address also goes through screening, covered in wallet screening for stablecoin payouts.
A counterparty in a country that does not enforce the rule may be unable to exchange data, yet your obligation stands. Write one policy per risk tier and apply it the same way each time.
On Lumx, stablecoin moves to and from any external wallet address through the Transfer endpoint, and the customer sending has been onboarded first. The nested payments rule requires every payer and payee to be an onboarded customer or a disclosed, approved third party, and a transaction that does not meet it may be delayed, rejected or reversed. For a counterparty outside Lumx, classify it in your own flow before you call the endpoint.
Where I would put the gate
I recommend putting the gate before the debit, not after the send, and writing the return rule before the first hold exists. I would rather ship three outcomes with a clock on each than a clever scoring model, because an analyst looking at a held transfer should know what happens at hour 24, the length of a transaction RFI window on Lumx, without asking anyone. I would also refuse every exception to the return address, even for a customer who is polite and in a hurry, because that exception is what the next bad actor will ask for.
When a Travel Rule hold is the wrong call
A hold is the wrong call when the missing item is not required: holding for a field nobody needs trains analysts to release without reading. Document which fields block and which are advisory, so a hold always points at a rule.
It is also the wrong call for a sanctions hit. Holding for "more information" when the issue is a listed party delays an escalation the law may require. Send those to the sanctions queue.
What this looks like on a Lumx payout
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Take a company onboarded as a Lumx customer that pays a supplier abroad. It has finished KYB, the supplier is a destination with the relationship SUPPLIER, and the payout carries a purpose. That covers the originator, the beneficiary and the reason before the payment.
The name-match gate depends on what the beneficiary sees. On Pix (Brazil's instant payment system) the recipient sees the customer's name as the payer. On SPEI (Mexico's interbank transfer system), ACH, FEDWIRE, SEPA, Faster Payments and SWIFT the sender of record is the customer too, so the customer record should carry the legal name.
If the payout is flagged, Lumx compliance reviews it by hand. If it is not a false positive, compliance asks you, on your usual channel, for the relationship between sender and receiver, the purpose, the expected outcome and other context. If no one answers within 24 hours, the transaction may be refunded to the sender. A customer, or an account, that needs more information moves to RFI, and for a customer the reason is in statusReason. A destination under review emits destinations.under_verification, then destinations.approved, or destinations.final_rejection if it is permanently rejected. For a customer, FINAL_REJECTION is permanent: the docs say it cannot resubmit or be re-verified.
What your own users see in that window is your product's decision. Show a held payout as "in review" with the next step named, never as failed, because a failed payout invites a duplicate. Refusals are covered in why stablecoin payouts get rejected, and the payout side in what a stablecoin off-ramp is. The named virtual accounts, global payments, coverage page and operator map pages show the rest, and what a named virtual account is explains the deposit side.
Methodology and sources
Product behavior was read in the Lumx documentation on November 1, 2026: Request for Information, Accounts, Transactions, Destinations, Identity Verification, Nested Payments, Sender of Record, Wallets, Webhooks and the Transfer endpoint. 31 CFR 1010.410 was read the same day. Regulation (EU) 2023/1113 is linked to its official EUR-Lex page, which returned a bot wall on that date, so its text was not re-read.
31 CFR 1010.410 checked against ecfr.gov on November 1, 2026.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
What is a Travel Rule workflow?
A Travel Rule workflow is the process a provider runs so that sender and recipient identity data accompanies a crypto transfer. It classifies the counterparty, then gathers and checks the data, screens the parties, exchanges the data or verifies wallet ownership, then releases or holds the transfer and logs the decision. Lumx runs KYB or KYC before any transaction, ties each payout to a registered destination and a purpose, and holds flagged transactions for compliance review.
When should a transfer be held, returned or rejected?
Hold when the problem can be fixed before settlement, such as a missing name. Return when funds arrived and the data never came. Reject when a transfer should not be accepted at all. At Lumx, a flagged transaction is held for manual review and may be refunded to the sender if no one answers within 24 hours.
What data does a Travel Rule workflow collect?
Originator name and address plus an identifier, the beneficiary name, the account or wallet address on each side, and the reason for the payment. Most of it should come from onboarding, where it is already verified. At Lumx, the customer record from KYB or KYC holds the originator, the destination holds the beneficiary and the relationship, and every on-ramp and off-ramp carries a purpose.
How long can a held transfer stay on hold?
Only as long as the written window allows, set from the slowest counterparty reply in your own logs. When it closes, the transfer is rejected or the credit returned to the source. At Lumx, the documented clock on a transaction RFI is 24 hours, after which the transaction may be refunded to the sender.
Who runs the Travel Rule workflow, you or your provider?
Both, and the split should be written down: the provider holds the verified record and runs review, and you decide what your users see. At Lumx, KYB or KYC comes before any transaction, a destination carries a holder relationship, every on-ramp and off-ramp has a purpose, and monitoring holds start a 24-hour RFI clock.
