FATF Recommendation 16 - Virtual Asset Travel Rule

Counterparty VASP Due Diligence (CVDD): VASPs must conduct due diligence on counterparty VASPs (the VASP on the other side of a virtual asset transfer) BEFORE establishing a counterparty relationship + on an ongoing basis. CVDD elements include: (a) verification that the counterparty VASP is licensed / registered in its home jurisdiction; (b) assessment of the counterparty VASP's AML/CFT compliance programme + customer due diligence procedures + sanctions screening + record-keeping + STR-filing arrangements; (c) review of the counterparty VASP's beneficial ownership + governance; (d) review of the counterparty VASP's regulatory record (any sanctions + supervisory findings + enforcement actions); (e) risk-rating the counterparty + applying enhanced or simplified measures accordingly; (f) periodic review (typically annually or more frequently for higher-risk counterparties); (g) wind-down

• CVDD policy + procedure
• Counterparty VASP risk-rating + assessment file
• Periodic review evidence
• Enhanced-measures protocol for higher-risk counterparties

• CVDD limited to verifying licensing status without programme assessment
• No periodic review of established counterparties
• No wind-down protocol for counterparties that fall out of compliance

Sanctions screening of Travel Rule data: VASPs must screen originator + beneficiary information against applicable sanctions lists - the UN consolidated sanctions list (UNSCR 1267 + 1373 regimes + DPRK + Iran + successor sanctions) + national sanctions lists (US OFAC SDN + Specially Designated Nationals + EU Consolidated List + UK OFSI + national equivalents). Screening must occur: (a) at customer onboarding (KYC + screening match); (b) at each virtual asset transfer (transmission + receipt screening); (c) periodically on the full customer base (typically daily or near-real-time delta-list screening). Match management: positive matches require freezing + filing of suspicious transaction report (STR) + reporting to the FIU + sanctions-authority reporting + counterparty notification + transaction blocking. The 2024 Targeted Update reinforced that VASPs must screen incoming + outgoing trans

• Sanctions screening tool + lists
• Match-management procedure
• Reporting evidence to FIU + sanctions authority

• Sanctions screening only at onboarding without transfer-level screening
• Match management slow leading to fund-flow continuing
• Reliance on counterparty VASP screening as substitute for own screening

Governance + training + independent testing: VASPs must establish appropriate governance arrangements for Travel Rule compliance including: (a) BOARD + SENIOR MANAGEMENT OVERSIGHT - the Travel Rule programme must be approved by the board + reviewed periodically + reported on; (b) DEDICATED COMPLIANCE FUNCTION - a designated compliance officer + AML/CFT officer with Travel Rule responsibilities + adequate resources + authority; (c) WRITTEN POLICIES + PROCEDURES - the Travel Rule policy must be written + approved + reviewed; (d) ANNUAL TRAINING for all employees with Travel Rule responsibilities + role-specific training for high-volume / complex roles; (e) INDEPENDENT TESTING - the Travel Rule programme must be tested by an independent function (typically internal audit OR external audit) at least annually + the test results reported to management + the board; (f) ISSUE TRACKING + REMEDIAT

• Board approval + reporting of Travel Rule programme
• Compliance officer mandate + resource records
• Annual training programme + records
• Annual independent testing report

• Travel Rule programme without board approval + reporting
• Compliance officer dual-hatted without adequate Travel Rule time + authority
• Annual training absent or limited to once-on-onboarding
• No independent testing or testing scope inadequate

Record retention: VASPs must retain all Travel Rule records - originator + beneficiary information + counterparty VASP information + sanctions screening results + investigation files + STR records - for at least 5 YEARS following the virtual asset transfer (extending to longer periods where local law requires or where the records support a continuing investigation). Records must be maintained in a form that can be: (a) produced to competent authorities on request without undue delay; (b) used to reconstruct individual virtual asset transactions + the supporting Travel Rule information; (c) retrieved + analysed for regulatory review + supervisory examinations + statistical reporting; (d) protected against tampering + unauthorised modification + premature destruction. Record retention applies on top of broader R.11 record-keeping requirements + complements FATF R.20 STR filing.

• Record-retention policy specifying 5-year + jurisdictional extension
• Retrieval procedure + competent-authority response capability
• Tamper-protection + access-control + audit logging

• Retention period shorter than 5 years
• Retrieval slow + not meeting competent-authority deadlines
• Records stored on systems that allow modification without audit trail

This corpus node tracks FATF Recommendation 16 (Wire Transfers) as extended to Virtual Asset Service Providers (VASPs) by the FATF October 2018 Public Statement + the June 2019 Interpretive Note + the 2024 Targeted Update on Virtual Assets + VASPs. Implementation status: 60+ jurisdictions have transposed R.16 for VASPs into national law / supervisory expectations as of 2024-2025; the Sunrise Problem persists as several major jurisdictions (or sub-national levels) are still working through transposition. Industry implementation infrastructure: IVMS101 data standard + multiple competing Travel Rule networks (TRP + TRUST + Sygna Bridge + Notabene + Sumsub + others) with imperfect interoperability. The 2024 FATF Targeted Update + ongoing R.16 reviews are emphasizing: (a) cross-jurisdictional interoperability + ending the Sunrise Problem; (b) DeFi + NFT case-by-case applicability; (c) stablec

• Tracking of FATF R.16 + Targeted Update changes
• Jurisdictional transposition map
• Industry-network coverage + multi-network strategy

• Compliance program tied to 2019 baseline without tracking 2024 Targeted Update
• No jurisdictional transposition tracking
• Single-network coverage limiting counterparty reach

Beneficiary (receiving VASP customer) information required for transmission with the virtual asset transfer + retention by the originating VASP: (a) beneficiary NAME; (b) beneficiary ACCOUNT NUMBER / wallet identifier. (NB beneficiary address + identification equivalents are NOT required by FATF baseline R.16 but the EU TFR (Regulation (EU) 2023/1113) requires beneficiary address + Member-State-specific identification details). The originating VASP must obtain the beneficiary information from the originator + transmit it WITH the virtual asset transfer to the beneficiary VASP. The beneficiary VASP must VERIFY the beneficiary information against its own KYC records on receipt + apply risk-based measures + freeze + return funds where the transfer cannot be matched to a customer or where the beneficiary VASP determines the transfer must not be processed.

• Beneficiary data collection + transmission procedure
• Receiving-side verification + reconciliation procedure
• EU TFR additional-fields compliance for EU operations

• Beneficiary information limited to wallet address without name
• Receiving VASP not verifying beneficiary information against KYC records
• EU TFR-specific fields (beneficiary address + Member-State ID) not collected for EU operations

Originator (sending VASP customer) information required for transmission with the virtual asset transfer + retention by the originating VASP: (a) originator NAME; (b) originator ACCOUNT NUMBER / wallet identifier; (c) originator's ADDRESS OR national identity number / customer identification number / date and place of birth (at least one of these address-or-identification-equivalents must be transmitted). Required for all transfers >= USD/EUR 1,000. For transfers BELOW the threshold simplified information (name + account number / wallet identifier) is acceptable + the full information must be available on request. INFORMATION MUST BE ACCURATE (verified by the originating VASP through KYC at customer onboarding + on-going due diligence per FATF R.10). The originating VASP is responsible for verifying the accuracy + completeness of the originator information.

• Originator data collection + verification procedure
• Threshold-based transmission rules
• Accuracy testing + monitoring

• Originator name field accepts free text without verification
• Address / national ID / customer ID / DOB equivalents not collected (only name + account)
• Below-threshold simplified information not available on request

Travel Rule scope: applies to ALL Virtual Asset Service Providers (VASPs) - centralised exchanges + custodial wallet providers + ICO issuers + investment + management + virtual asset trading platforms + administrators / operators / issuers / brokers / dealers of virtual assets - making + facilitating virtual asset transfers ABOVE the de minimis threshold of USD/EUR 1,000. Lower threshold than traditional wire transfers (USD/EUR 1,000 vs traditional USD/EUR 1,000 or higher in some jurisdictions). Applies to ALL virtual asset transfers crossing institutional boundaries between VASPs + to / from unhosted wallets. The 2024 Targeted Update reinforced application to: stablecoin transfers; DeFi platforms where a centralised actor functions as a VASP; NFT issuers where the NFT functions as an investment / payment instrument rather than as a pure digital collectible (case-by-case assessment).

• VASP scope determination memo identifying which entity types + activity categories qualify
• Travel Rule threshold monitoring + transaction-level enforcement
• DeFi / NFT case-by-case applicability assessment

• Travel Rule treated as applying only at higher threshold (e.g. USD 3,000 traditional wire threshold)
• DeFi platform claiming non-VASP status without case-by-case analysis
• NFT issuer claiming pure-collectible status without distinction from investment-instrument NFTs

Cross-border virtual asset transfers may involve intermediary VASPs (e.g. cross-chain bridges + multiple VASP-to-VASP relays before reaching the ultimate beneficiary VASP). Intermediary VASPs must: (a) retain all originator + beneficiary information received with the transfer; (b) transmit the information to the next VASP in the chain; (c) where the intermediary VASP cannot transmit some information for technical reasons (e.g. messaging-protocol limitations) - apply risk-based measures + freeze / return transfers per Article 11 of the Interpretive Note to R.16. Cross-border + multi-hop transfers also engage sanctions screening at each hop. The 2024 Targeted Update reinforced that intermediary VASPs must NOT strip + must retain ALL information received + transmit it unchanged.

• Intermediary VASP role identification + handling procedure
• Multi-hop sanctions-screening + AML controls
• Audit of intermediary VASP information transmission

• Intermediary VASP stripping originator information for privacy or technical reasons
• Multi-hop transfers without sanctions screening at intermediary nodes
• Intermediary VASP not retaining information beyond the initial transmission

The Sunrise Problem refers to the cross-jurisdictional implementation gap where some jurisdictions have transposed FATF R.16 for VASPs into national law + supervisory expectations + others have not - leaving VASPs in compliant jurisdictions transferring to or receiving from VASPs in non-compliant jurisdictions facing ambiguity about Travel Rule obligations. Sunrise Problem handling: (a) jurisdictional mapping - identify which counterparty VASPs operate in Travel-Rule-compliant jurisdictions vs jurisdictions where R.16 transposition is incomplete; (b) bilateral arrangements - some VASPs apply Travel Rule on a voluntary basis with counterparties even when the counterparty jurisdiction has not yet transposed; (c) information collection without transmission - VASPs may collect Travel Rule information at customer onboarding + retain records even where the counterparty VASP does not implement;

• Jurisdictional mapping of counterparty VASPs + transposition status
• Bilateral Travel Rule arrangements register
• Records of voluntary Travel Rule compliance for non-transposing counterparty jurisdictions

• No jurisdictional mapping of counterparty VASPs
• Voluntary Travel Rule compliance not documented
• Sunrise Problem cited as blanket excuse to skip Travel Rule altogether

Data quality + accuracy: Travel Rule information must be accurate + complete + transmitted in a format that the receiving VASP can process. Data quality measures: (a) format validation - originator + beneficiary names must conform to permitted character sets + length limits; wallet identifiers must be valid for the relevant virtual asset; (b) cross-field validation - originator name + customer identification number must be consistent; (c) integrity assurance - data must not be altered in transit (cryptographic signing + verification via IVMS101 + the Travel Rule network); (d) reconciliation - the receiving VASP must reconcile received Travel Rule information against the actual virtual asset transfer on the blockchain (transaction hash + amount + sender + recipient address); (e) discrepancy management - investigate + resolve any discrepancies + freeze + return funds where reconciliation f

• Data validation rules + monitoring
• Cryptographic signing / verification of Travel Rule data
• Blockchain-Travel-Rule reconciliation evidence
• Discrepancy resolution log

• Free-text fields without validation
• Travel Rule data not cryptographically signed
• Reconciliation between Travel Rule data + blockchain transaction not performed
• Discrepancies passed through without resolution

IVMS101 (the InterVASP Messaging Standard) is the global data-interoperability standard for Travel Rule messaging between VASPs - developed by the Joint Working Group on InterVASP Messaging Standards (JWG) which includes representatives from FATF + the major Travel Rule solution providers + industry bodies. IVMS101 standardises the data fields for originator + beneficiary + VASP identification + transfer metadata for interoperable VASP-to-VASP messaging. Competing implementation networks include: TRP (Travel Rule Protocol); TRUST (Travel Rule Universal Solution Technology, established by Coinbase + Anchorage + Robinhood + others); Sygna Bridge; OpenVASP; Notabene; Sumsub Travel Rule; Veriscope; Synchrology; Shyft; 21 Analytics. Network interoperability remains imperfect - many VASPs operate multiple Travel Rule networks to communicate with counterparties on different networks. The 2024 T

• IVMS101 compliance + data-field mapping
• Travel Rule network coverage + multi-network strategy
• Network interoperability gap analysis

• Proprietary data format not aligned with IVMS101
• Single-network coverage limiting counterparty reach
• Network gaps treated as Sunrise Problem instead of multi-network strategy

Unhosted (self-hosted / non-custodial) wallet transfers: virtual asset transfers between a VASP-controlled customer wallet + an unhosted wallet controlled by an individual or entity not registered/licensed as a VASP raise specific risks. The 2024 FATF Targeted Update reinforced risk-based measures: (a) for OUTBOUND transfers to unhosted wallets - VASPs should obtain originator information + apply risk-based + enhanced measures + retain records; the VASP may apply additional verification of the customer's ownership / control of the unhosted wallet (e.g. via Address Ownership Proof Protocol AOPP + Satoshi Test) where risk warrants; (b) for INBOUND transfers from unhosted wallets - VASPs should obtain beneficiary information + apply risk-based + enhanced measures + assess source of funds where appropriate. Some jurisdictions impose stricter requirements (e.g. EU TFR requires that unhosted w

• Unhosted wallet transfer policy + risk-based procedure
• AOPP / Satoshi Test integration where applicable
• Source-of-funds assessment for incoming transfers

• Outbound transfers to unhosted wallets without originator information collection
• Inbound transfers from unhosted wallets without beneficiary information collection
• Absolute prohibition of unhosted wallet transfers instead of risk-based approach