Riset terverifikasi sumber: FATF 2026 Crypto Travel
Isi artikel ditampilkan dalam bahasa Inggris asli yang telah diverifikasi. Terjemahan ditambahkan setelah tinjauan sumber.
Direct answer
FATF reported in July 2026 that 83% of surveyed jurisdictions had passed Travel Rule legislation, up from 73% in 2025, while implementation and supervision remained uneven. For users, that does not create one global transfer form. It explains why exchanges may request different originator, beneficiary, wallet-ownership or counterparty information depending on entity, jurisdiction, asset, route and risk review.
Tampilkan lebih sedikit
Verified source facts
1. FATF reported that 83% of surveyed jurisdictions had passed Travel Rule legislation in 2026, compared with 73% in 2025. 2. FATF said legislation has progressed faster than effective implementation, supervision and enforcement in some jurisdictions. 3. The update identifies offshore VASPs, stablecoins, unhosted wallets and DeFi arrangements among continuing risk areas. 4. FATF frames the Travel Rule as part of Recommendation 15's risk-based controls for virtual assets and service providers.
Comparison at a glance
Tabel artikel: gulir secara horizontal atau fokuskan area tabel dan gunakan tombol panah.
| Decision layer | What to inspect | Minimum safe action |
|---|---|---|
| Sending entity | which legal exchange entity handles the transfer | identify the entity before interpreting the form |
| Receiving VASP | whether the destination is another service provider | select the exact counterparty when requested |
| Originator data | name and other required sender fields | provide data only inside the authenticated official flow |
| Beneficiary data | recipient identity required by the route | verify details with the intended recipient |
| Self-hosted wallet | ownership or control questions | separate wallet verification from seed disclosure |
| Stablecoin route | issuer, chain and cross-border counterparties | document every hop and legal entity |
| Data privacy | collection, retention and cross-border sharing | read the applicable privacy notice |
| Transfer delay | manual review or information mismatch | leave timing buffer and retain the transaction record |
| Rejection handling | return, hold or support escalation | check the official failure procedure before sending |
| Policy evidence | law, guidance and platform implementation | distinguish global standards from account behavior |
1. Route analysis: Sending entity
A multichain stablecoin transfer is a route across distinct ledgers, not a movement inside one universal balance. The sending entity layer covers which legal exchange entity handles the transfer. Write the route as origin venue or wallet → origin contract and chain → bridge or issuer mechanism → destination contract and chain → destination venue or wallet. Then identify the entity before interpreting the form.
At every edge, ask who performs conversion and who bears failure risk. A centralized exchange may internalize the route; an issuer may mint and burn native units; a bridge may lock one representation and issue another; a swap may change both asset and price exposure. These mechanisms are not interchangeable. The evidence does not resolve future entity routing, so a live check and test transfer remain necessary.
The same ticker can hide different contract addresses, redemption claims, liquidity pools, gas assets, confirmation rules, and compliance controls. Treat ticker matching as the beginning of identification, never the end. A sound route minimizes unverified intermediaries and leaves a transaction record that support teams can interpret if something goes wrong.
2. Route analysis: Receiving VASP
The receiving vasp layer covers whether the destination is another service provider. Then select the exact counterparty when requested.
The evidence does not resolve counterparty database accuracy, so a live check and test transfer remain necessary.
3. Route analysis: Originator data
The originator data layer covers name and other required sender fields. Then provide data only inside the authenticated official flow.
The evidence does not resolve jurisdiction-specific field sets, so a live check and test transfer remain necessary.
4. Route analysis: Beneficiary data
The beneficiary data layer covers recipient identity required by the route. Then verify details with the intended recipient.
The evidence does not resolve downstream verification time, so a live check and test transfer remain necessary.
5. Route analysis: Self-hosted wallet
The self-hosted wallet layer covers ownership or control questions. Then separate wallet verification from seed disclosure.
The evidence does not resolve acceptance by a specific entity, so a live check and test transfer remain necessary.
6. Route analysis: Stablecoin route
The stablecoin route layer covers issuer, chain and cross-border counterparties. Then document every hop and legal entity.
The evidence does not resolve future freeze or screening decisions, so a live check and test transfer remain necessary.
7. Route analysis: Data privacy
The data privacy layer covers collection, retention and cross-border sharing. Then read the applicable privacy notice.
The evidence does not resolve actual downstream retention, so a live check and test transfer remain necessary.
8. Route analysis: Transfer delay
The transfer delay layer covers manual review or information mismatch. Then leave timing buffer and retain the transaction record.
The evidence does not resolve review completion time, so a live check and test transfer remain necessary.
9. Route analysis: Rejection handling
The rejection handling layer covers return, hold or support escalation. Then check the official failure procedure before sending.
The evidence does not resolve discretionary support outcome, so a live check and test transfer remain necessary.
10. Route analysis: Policy evidence
The policy evidence layer covers law, guidance and platform implementation. Then distinguish global standards from account behavior.
The evidence does not resolve future supervisory convergence, so a live check and test transfer remain necessary.
Decision scenarios
Scenario 1: when sending entity becomes decisive
Consider a reader whose main constraint is which legal exchange entity handles the transfer. The correct response is not to infer a universal platform or product winner. It is to identify the entity before interpreting the form, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.
Scenario 2: when receiving vasp becomes decisive
Consider a reader whose main constraint is whether the destination is another service provider. It is to select the exact counterparty when requested, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 3: when originator data becomes decisive
Consider a reader whose main constraint is name and other required sender fields. It is to provide data only inside the authenticated official flow, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 4: when beneficiary data becomes decisive
Consider a reader whose main constraint is recipient identity required by the route. It is to verify details with the intended recipient, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 5: when self-hosted wallet becomes decisive
Consider a reader whose main constraint is ownership or control questions. It is to separate wallet verification from seed disclosure, retain the evidence, and define a stop condition before funds or permissions are committed.
Scenario 6: when stablecoin route becomes decisive
Consider a reader whose main constraint is issuer, chain and cross-border counterparties. It is to document every hop and legal entity, retain the evidence, and define a stop condition before funds or permissions are committed.
Topik dan alat:Berita regulasi kripto