AML and the Travel Rule: What Fintech Companies on DLT Rails Must Know
FinCEN's Travel Rule applies to crypto transfers above $3,000 — requiring VASPs to collect, verify, and transmit originator and beneficiary data with every qualifying transaction. Understanding this framework is table stakes for any fintech company building on XRPL or other DLT payment rails.
This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for compliance guidance specific to your situation.
WHAT THE TRAVEL RULE ACTUALLY IS
The Travel Rule originated in the Bank Secrecy Act (BSA) of 1970 and was formalized by FinCEN in 1996. Originally designed for traditional wire transfers, it requires financial institutions to "pass along" — have the information "travel" with — certain identifying information when transmitting funds above a threshold amount.
In 2019, the Financial Action Task Force (FATF) — the international standard-setting body for anti-money laundering — extended its Travel Rule guidance (Recommendation 16) explicitly to virtual asset service providers (VASPs). FinCEN confirmed in 2019 that VASPs operating in the U.S. are subject to the same Travel Rule requirements as traditional money transmitters under the BSA.
The core obligation: when a VASP transmits a virtual currency transfer of $3,000 or more on behalf of a customer, it must collect and transmit to the receiving VASP (or financial institution):
- Originator information: Name, account number (or blockchain address), physical address, or national identification number
- Beneficiary information: Name and account number (or blockchain address)
The receiving institution must retain this information for five years.
WHO IS A VASP FOR THESE PURPOSES
A Virtual Asset Service Provider (VASP), in FinCEN's framework, is any entity that conducts one or more of the following as a business on behalf of a customer:
- Exchange between virtual assets and fiat currencies
- Exchange between one or more forms of virtual assets
- Transfer of virtual assets
- Safekeeping or administration of virtual assets
- Participating in and providing financial services related to ICOs or token issuances
If your fintech application accepts customer funds, executes transactions on their behalf, or operates as a custodian of digital assets — you are likely a VASP under U.S. law and a Money Services Business (MSB) under the BSA. This triggers Travel Rule requirements for qualifying transactions.
Critically: peer-to-peer wallet software that facilitates direct user-to-user transactions without intermediary custody is generally not a VASP. If your application provides software tools but does not itself hold or transmit funds, the Travel Rule obligation may not apply to you. The line is custody and control, not mere software provision.
NON-CUSTODIAL VS. CUSTODIAL ARCHITECTURE
This distinction is operationally critical for fintech developers choosing their architecture. A custodial platform — where the platform holds customer private keys and executes transactions on their behalf — is almost certainly a VASP with full Travel Rule obligations. A non-custodial platform — where users hold their own keys and the platform only provides a user interface — may fall outside VASP classification for Travel Rule purposes.
XRPL-native infrastructure like XAMAN (formerly Xumm) takes a non-custodial approach: users hold their own keys, and XAMAN provides a signing interface. The payment originates from the user's own wallet, not from XAMAN's custody. This architecture is specifically designed to avoid VASP classification.
OnrampDLT's non-custodial token issuance model follows the same principle: issuers use their own Xaman wallet addresses, and the platform never holds private keys. This is not just a security benefit — it has regulatory implications for Travel Rule compliance obligations.
THE TECHNICAL CHALLENGE: TRANSMITTING TRAVEL RULE DATA
Here's where the practical complexity comes in. Traditional wire transfers use SWIFT messaging, which has established fields for originator and beneficiary information. Blockchain transactions don't have a built-in "memo field" for full KYC data — and putting PII (personally identifiable information) on a public blockchain would create serious GDPR and privacy issues.
The industry solution is Travel Rule protocol standards — separate, encrypted communication channels between VASPs that transmit the required information off-chain, keyed to on-chain transaction identifiers. Several protocols have emerged:
- TRUST (Travel Rule Universal Solution Technology): Industry consortium including Coinbase, Gemini, Kraken, and others; U.S.-focused
- OpenVASP: Open-source protocol; European origin
- Veriscope (Shyft Network): FATF-compliant; focused on global interoperability
- Sygna Bridge: Widely used in Asia-Pacific
For XRPL specifically, the destination tag system provides a natural transaction identifier that can key Travel Rule data in a TRUST or VASP-to-VASP communication. Your platform sends the XRP/RLUSD transaction with a destination tag, simultaneously transmits Travel Rule data to the counterparty VASP using the transaction hash as a reference key, and both parties retain the required records.
THE $3,000 THRESHOLD AND AGGREGATION RULES
The $3,000 threshold applies to individual transfers. However, FinCEN's rules also require institutions to track structuring — multiple smaller transactions designed to avoid the reporting threshold ("smurfing"). If a customer sends nine transactions of $400 each in a single day to the same beneficiary, a compliant system should flag this pattern for potential Suspicious Activity Report (SAR) filing, even though no individual transaction triggered the Travel Rule.
FATF guidance also distinguishes between transactions where both parties are identified (VASP-to-VASP) and transactions where the beneficiary holds a self-hosted wallet (VASP-to-unhosted wallet). For VASP-to-unhosted wallet transfers above threshold, some jurisdictions require enhanced due diligence on the wallet owner, though U.S. FinCEN has not yet finalized its unhosted wallet rule (a 2020 proposed rule was withdrawn and the issue remains pending as of early 2026).
AML PROGRAM REQUIREMENTS FOR VAPS
Beyond the Travel Rule, U.S. VASPs operating as MSBs must maintain a full BSA/AML compliance program covering:
1. KYC (Know Your Customer)
Verify the identity of customers before allowing transactions above de minimis thresholds. Standard KYC collects: full legal name, date of birth, physical address, government-issued ID number. For businesses: legal entity name, EIN/TIN, beneficial owner information (under FinCEN's Beneficial Ownership Rule, effective 2024). XRPL trust line compliance features can be used to whitelist verified wallet addresses, ensuring only KYC'd addresses can hold or receive specific tokens.
2. Sanctions Screening
OFAC (Office of Foreign Assets Control) maintains the SDN (Specially Designated Nationals) list and various sanctions programs. Every customer onboarding and every transaction must be screened against current OFAC lists. Blockchain analytics firms (Chainalysis, Elliptic, TRM Labs) provide XRPL-compatible screening tools that flag wallets associated with sanctioned addresses. OFAC does not recognize "good faith" exceptions for transfers involving sanctioned parties — the compliance burden is strict liability.
3. Transaction Monitoring
Ongoing monitoring of transaction patterns for suspicious activity indicators: unusual volumes, rapid movement through multiple wallets (layering), transactions inconsistent with customer profile, connections to high-risk jurisdictions. Automated monitoring systems should flag for human review; confirmed suspicious activity requires SAR filing with FinCEN within 30 days of detection.
4. Record Retention
BSA requires five-year retention of: KYC records, transaction records, Travel Rule data, SARs, Currency Transaction Reports (CTRs for transactions over $10,000 in cash equivalents), and related correspondence.
XRPL-SPECIFIC COMPLIANCE FEATURES
XRPL's on-ledger feature set was designed with institutional compliance use cases in mind. Several native features directly support AML/KYC programs:
- Trust Lines with Freeze: Token issuers can freeze individual trust lines, preventing a flagged wallet from transacting in their token until compliance review is complete. This mirrors a bank's ability to freeze an account under investigation.
- Global Freeze: An issuer can freeze all transfers of their token across all holders simultaneously — useful in the event of a security incident or regulatory order.
- RequireAuth: Token issuers can require explicit authorization before a wallet can hold their token — enabling a whitelist model where only KYC-verified addresses can receive the asset.
- Clawback (enabled 2024): Token issuers can reclaim tokens from specific wallets — a critical feature for complying with court orders and regulatory asset recovery requirements.
These features distinguish XRPL from permissionless blockchains where issuers have no compliance tools once tokens are distributed. They're the reason regulated institutions issuing stablecoins and tokenized assets (like RLUSD's issuer using NYDFS-approved architecture) choose XRPL.
PRACTICAL STEPS FOR A NEW FINTECH ON DLT RAILS
- Determine your regulatory classification: Non-custodial (likely not an MSB) vs. custodial (likely an MSB requiring FinCEN registration)
- Register with FinCEN as an MSB if required (free, online at fincen.gov)
- Obtain state money transmitter licenses where required (currently required in most U.S. states for businesses transmitting funds; the state-by-state patchwork is the primary compliance burden for U.S. fintechs)
- Build or buy KYC: Identity verification APIs (Persona, Onfido, Jumio) integrate readily with web applications and provide audit-trail records
- Integrate blockchain analytics: Chainalysis, Elliptic, or TRM Labs for wallet screening on every transaction
- Join a Travel Rule network: TRUST consortium membership for U.S.-to-U.S. VASP transfers; Veriscope or Sygna for international corridors
- Document your AML program: Written policies, procedures, designated BSA Officer, annual independent testing
Non-Custodial Token Infrastructure
OnrampDLT's non-custodial architecture means issuers retain control of their own keys — reducing compliance exposure while maintaining full on-chain capabilities.
Explore OnrampDLT →