The Bank Secrecy Act's travel rule, at 31 CFR 1010.410(f), requires financial institutions to exchange and retain specified originator and beneficiary information on transmittals of funds of $3,000 or more — a 1996 records regime that FATF Recommendation 16 extended conceptually to virtual assets in 2018, that the EU wrote into binding law for crypto-asset transfers effective December 30, 2024, and that FinCEN has proposed but not finalized for US virtual-asset service providers, leaving American firms to reconcile a domestic threshold, an international standard, and partner jurisdictions' laws in one message format.
3G Times publishes information, not legal advice. Travel-rule scoping turns on institution type and transfer facts, and the US proposal's status should be checked against the current rulemaking agenda.
What does the rule actually require?
The regulation is a recordkeeping-and-transmittal rule, not a report. For a covered transmittal of $3,000 or more, the transmittal-of-funds originator must transmit, and the intermediary and beneficiary institutions must retain, the originator's name, address, and account number; the beneficiary's name, address, account, and any other identifier; and the amount and execution date. Payments below $3,000 need lesser records; above the line, the information must travel with the payment through the chain. The discipline the rule imposes is completeness at speed: an intermediary that cannot produce the packet on request has the violation, regardless of who dropped the field.
How did FATF extend it to virtual assets?
In October 2018, and refined in its 2021 guidance, FATF revised Recommendation 16 so that its "originator and beneficiary information" obligations apply to virtual-asset transfers, with a softened de minimis threshold — the interpretive note contemplates countries setting a lower or no threshold for virtual assets, with $1,000 or €1,000 as the reference point for a higher one. Jurisdictions implemented unevenly and on different clocks, which produced the rule's central operational problem: a US-originated transfer at $2,500 to a German counterparty meets no US travel duty (below $3,000, and the VASP extension remains proposed) but lands inside the EU regime's all-transfers approach, where the receiving provider must collect the same data or return the funds. The compliance answer is a message format that always carries the full packet.
What does the EU Transfer of Funds Regulation add?
Regulation (EU) 2023/1113, applying since December 30, 2024, removes the threshold question inside Europe: every crypto-asset transfer between service providers carries originator and beneficiary information, verified against AML onboarding records, with the verification layered by amount — fuller diligence above €1,000. It also imported the "no data, no business" principle: a provider receiving an unaccompanied transfer must suspend, verify, or return. For US-headquartered venues, the TFR is the reason the travel rule ceased to be optional in practice: their European counterparty relationships demand compliant messages regardless of FinCEN's domestic timeline.
| Regime | Coverage | Threshold | Status |
|---|---|---|---|
| BSA travel rule, 31 CFR 1010.410(f) | Transmittals of funds | $3,000 | In force (fiat) |
| FinCEN VASP extension | Convertible virtual currency | $3,000 proposed / $250 for certain counterparties | Proposed; not finalized |
| FATF Recommendation 16 | Virtual-asset transfers | Country-set; $1,000/€1,000 reference | Standard; national implementation varies |
| EU Transfer of Funds Regulation 2023/1113 | Crypto-asset transfers | None for data; €1,000 verification layer | In force since Dec. 30, 2024 |
Why is interoperability the hard part?
The rule's data model is simple; its plumbing is not. Originators and beneficiaries on self-hosted wallets appear as addresses, not institutions; intermediaries appear and disappear with routing; and jurisdictions disagree on whether an unhosted counterparty can receive the packet at all. The industry's answer has been standardized messaging — the interVASP Messaging Standard (IVMS 101) defines the originator/beneficiary fields so that systems can parse each other — plus identity-resolution networks that translate counterparty VASPs into reachable endpoints. The residual failures are business-model failures: the exchange that cannot verify its own customer's name spelling at send time, the processor that strips fields for latency, the provider whose return-of-funds path was never tested. Examiners and counterparties both probe those seams.
Batch discipline deserves its own sentence in the runbook: the protocols exist because retail flows repeat, and the examination question is always whether the batch conditions — same parties, verified since when, by whom — can be reconstructed from the system of record rather than from an operator's memory.
What does a compliant packet contain, field by field?
The IVMS 101 model keeps the rule's fields and makes them transmissible: originator name; the originator's account number or, for unhosted sends, the wallet address used; and a physical address, national identifier, or date and place of birth to disambiguate the name — with the EU regulation accepting the address or identifier alternatives in defined combinations. The beneficiary side carries the name and account or wallet address. Transmission is expected before or at execution, not after settlement, because the packet is a decision input for the receiving provider's suspension duties, not a filing. Batch protocols cover repeated transfers between the same parties, easing the volume burden without diluting the first-transfer duties. The engineering discipline is boring and decisive: field completeness validated at send, rejections handled by process rather than improvisation, and every packet retained to the BSA's five-year line.
What does this mean in practice?
- Send the full packet always. Building to the strictest counterparty regime — EU all-transfers semantics in IVMS fields — collapses the threshold matrix into one code path.
- Verify at onboarding, reference at send. The send-time duty is to transmit what was verified; the failure mode is re-keying, so bind the packet to the KYC record, not the operator's fingers.
- Test the return path before the regulator does. An unaccompanied transfer must come back or resolve through verification; an untested suspension queue is a liquidity incident waiting for its transfer.
- Track FinCEN's rulemaking separately from policy statements. The proposal's $3,000/$250 structure and its unhosted-wallet duties have been the subject of years of comment; the final text, when it lands, will not match the EU rule and the map above will need redrawing.
The travel rule's quarter-century in fiat teaches the last lesson for free: the institutions that treated it as a data-integrity program, not a reporting form, were the ones that passed the multipart tests when transfers crossed the wrong border at the wrong hour.
How do unhosted wallets enter the packet?
As addresses, with the surrounding duties shaped by regime. The US proposal contemplated counterparty verification expectations for certain unhosted transfers; the EU regulation layers collection of wallet-ownership confirmation above its verification threshold. The packet structure does not change — originator and beneficiary fields travel regardless — but the confidence behind the beneficiary fields does, and programs document the verification method alongside the send so the receiving side can price it.
Frequently asked questions
Does the $3,000 threshold apply to crypto in the US today?
No US travel-rule duty applies to virtual-asset transfers under the existing regulation; FinCEN's extension remains a proposal. The practical duty arrives through counterparties: EU providers and other implemented jurisdictions require the packet, and US venues send it to keep the relationship.
What is IVMS 101?
An industry messaging standard defining the travel rule's originator and beneficiary fields for system-to-system exchange. It does not create obligations; it makes them satisfiable, by letting counterparties parse a message without bespoke integration.
Who is liable when a field is dropped mid-chain?
Each institution in the chain holds its own retention and transmittal duties; the intermediary that passed an incomplete packet and cannot reconstruct it is the exposed party. That allocation is why complete-at-send engineering beats repair-downstream workflows.
For more context, read OFAC's 50 Percent Rule: Ownership Screening for Shell Structures in Payment Chains.
For more context, read ecoa adverse action notices ai.
For more context, read regulation e error resolution.