Crypto Travel Rule, KYC, AML, and Source-of-Funds Records

The crypto Travel Rule, KYC, AML controls, sanctions checks, and source-of-funds records answer different questions about the same payment. A defensible file lets another reviewer reconstruct who paid, why, where the funds came from, how they moved, and why an alert was resolved or escalated. Official sources reviewed August 26, 2026.

KYC, AML, sanctions controls and the Travel Rule are related, but they are not interchangeable. A freelancer receiving one legitimate customer payment is not automatically a virtual asset service provider. However, the exchange, wallet provider, bank or other regulated intermediary may still ask both parties for information before, during or after settlement.

Do not treat this article as a universal legal checklist. Your role, country, provider, counterparty, transaction pattern and current rules determine what applies. The practical response is to keep proportionate evidence and follow requests through official secure channels—not to invent data or route around a review.

In this guide

• Know what each term means
• Build one evidence pack around the payment
• Scale the checks to the risk signal
• Follow a USD 2,400 example from contract to bank
• Handle crypto Travel Rule requests correctly
• Treat red flags as stop-and-explain events
• Verify the Cambodia layer before relying on a provider
• Your evidence pack is ready for review

Know what each term means

The Financial Action Task Force (FATF) sets international standards that countries implement through local law. Its Recommendation 15 framework brings virtual-asset service providers into risk-based AML/CFT controls, while Recommendation 16 underpins originator and beneficiary information requirements commonly called the Travel Rule. Exact thresholds, fields and implementation differ by jurisdiction and provider, so this guide deliberately does not invent one universal number.

Build one evidence pack around the payment

Keep each document linked by invoice number or internal reference:

1. Counterparty identity: legal name, verified business/contact details and the authorized payer.
2. Business purpose: signed contract, purchase order, deliverables and the crypto invoice template.
3. Source of funds: proportionate evidence showing how the payer funded this transaction when reasonably requested.
4. Relationship: explanation if the wallet/account holder differs from the contracting customer; do not accept an unexplained third party.
5. Route record: exact asset, network, receiving address, memo/tag state and approved provider.
6. Transaction evidence: test and main transaction hashes, timestamps, credited amounts and provider statement.
7. Screening/review evidence: provider questions, your truthful responses, and any decision to continue, pause, reject or refund.
8. Accounting and cash-out: invoice status, rate evidence, fees, conversion record and bank credit.

Collect only what is needed. Use the provider's authenticated app, website or secure upload channel. Do not ask a customer to send ID documents, recovery phrases or one-time codes through social media. Restrict access, encrypt or otherwise protect stored records, and define a retention/deletion policy based on current legal, tax, accounting and contractual requirements. There is no single retention period that is correct everywhere.

Scale the checks to the risk signal

Risk-based does not mean “approve small amounts automatically” or “reject self-custody automatically.” It means examine the actual customer, purpose, route, geography, behavior and evidence together.

Follow a USD 2,400 example from contract to bank

Assume a Cambodian web designer invoices an overseas business USD 2,400, to be settled in USDC.

Before payment: the designer retains the signed scope, customer legal name, invoice SPG-2026-018, authorized payer, exact asset/network route and fee/test terms. The customer confirms the sending account belongs to the contracting business.

During payment: the designer records the test and main transaction hashes and waits until the receiving provider credits the correct total. A blockchain explorer screenshot alone is not treated as completion.

If reviewed: the designer provides the invoice, contract, customer correspondence and transaction evidence through the provider's real authenticated channel. If the sender is an unrelated person or the source cannot be explained, the transfer is paused rather than split or rerouted.

At cash-out: the conversion receipt and bank credit are linked back to the same invoice. The names, gross amount, fees, rate difference and net amount are reconciled using the selling USDT and cashing out in Cambodia.

The result is a continuous story: service agreement → invoice → payer → blockchain transactions → provider credit → conversion → bank credit. A pile of screenshots without those links is weaker evidence.

Handle crypto Travel Rule requests correctly

For a qualifying transfer, a provider may need originator and beneficiary information and may ask whether the destination is another provider or a self-hosted wallet. Enter the real recipient and wallet type. Never select a false category merely to make a transfer proceed.

Before sending:

• read the current withdrawal/deposit form and provider help notice;
• make the name and destination details consistent with the actual beneficiary;
• confirm whether the receiving provider can accept the transfer and information flow;
• keep the request and confirmation with the transaction record;
• stop if the form requires information you do not know—ask the actual beneficiary through a verified channel.

FATF's 2026 targeted update reports continued implementation progress but also persistent global gaps and risks involving offshore providers, stablecoins, peer-to-peer activity and unhosted wallets. That is why an app being accessible does not establish that its current product or route is authorized where you are.

Treat red flags as stop-and-explain events

Pause the payment when you see:

• the payer name does not match the customer and there is no documented relationship;
• the customer asks you to split payments to avoid a review or reporting control;
• the money is said to be salary or business revenue but the evidence points elsewhere;
• documents are edited, inconsistent or issued to a different party;
• the customer insists on a new wallet after the invoice was approved;
• funds appear linked to theft, scams, obfuscation services or unexplained rapid hops;
• someone claiming to be support requests a seed phrase, OTP, remote access or payment to “unlock” funds;
• an official provider or competent authority instructs you to hold, reject or supply information.

Preserve the evidence and seek qualified legal/compliance advice when needed. Do not tip off a potentially suspicious counterparty about confidential reporting, and do not “test” a restricted route by moving a smaller amount.

Verify the Cambodia layer before relying on a provider

Official NBC Prakas PDF opened in the browser and captured 2026-08-26. It is an unofficial English translation of the Cambodian rule; use the current official text and qualified local advice for a real transaction.

Cambodia-specific status can change. Before using a service or route:

1. Review the Securities and Exchange Regulator of Cambodia's current sandbox list and the exact activity shown for a participant.
2. Review the National Bank of Cambodia's Prakas and Circulars, including the listed Prakas on transactions related to cryptoassets dated December 26, 2024.
3. Confirm the provider's current country eligibility, account terms and live product availability.
4. Confirm your bank's current policy for the intended incoming funds.
5. If the activity, role or authorization is unclear, pause and obtain local professional advice.

A sandbox entry, memorandum, news story or accessible application should not be stretched beyond the activity and date it actually covers.

Your evidence pack is ready for review

Before treating a crypto payment as compliant enough to proceed within your role, confirm:

• the customer, authorized payer and beneficiary are identified and consistent;
• the contract and invoice explain a real commercial purpose;
• source-of-funds evidence is proportionate and resolves, rather than adds, inconsistencies;
• asset, network, wallet type, transaction hashes and provider credits are recorded;
• current provider forms and Travel Rule questions were answered truthfully;
• sanctions or provider alerts were checked through official channels and not bypassed;
• exceptions, review decisions and refunds have an audit trail;
• the final conversion and bank credit reconcile to the invoice;
• sensitive records are secured, access-limited and retained/deleted under a documented current policy.

Official references

• FATF: 2026 Targeted Update on Virtual Assets and VASPs
• FATF: Risk-Based Approach Guidance for Virtual Assets and VASPs
• FATF: Quick Guide on Assessing Virtual-Asset and VASP Risks
• SERC: Current Sandbox List
• NBC: Prakas and Circulars

Educational information only; not legal, regulatory, sanctions, tax, banking or financial advice. Current law, lists, provider requirements and service availability can change. Use official channels and qualified local advice for your facts.