A requirement that originator and beneficiary information accompany a transfer of digital assets between regulated service providers. The obligation sits on the providers at each end of the transfer, not on the customers whose details travel with it. It began as FATF Recommendation 16, a wire-transfer standard adopted in 2001, and was extended to virtual assets in 2019; in digital assets it is known as the crypto travel rule. Each country legislates it separately, so the data fields, the thresholds and the enforcement posture differ by jurisdiction — a transfer that clears in one corridor is held in another for information the sending side was never required to collect.
Who the rule binds, and who only supplies the data
Three parties can be obliged: the institution or provider that receives the payment instruction from the customer, any intermediary in the chain, and the institution or provider that receives the transfer. Under the revised standard the payment chain is treated as starting with the institution that receives the customer’s instruction, which fixes where responsibility for the data begins.
Neither the payer nor the seller of the goods is an obliged party. They are the subjects of the data, named in a message they never send. A bullion seller receiving settlement is the beneficiary customer identified in that message — a name to be matched, not a party with a transmission duty.
That matters for anyone assembling a counterparty file. A dealer in precious metals is a designated non-financial business under the FATF Standards, carrying customer due diligence, record-keeping and suspicious-transaction reporting obligations under Recommendations 22 and 23. Those are a different instrument from Recommendation 16. A reviewer who asks a bullion counterparty for its travel-rule transmission policy is asking for a document that, by the structure of the standards, sits with the payment providers; what the seller holds is due diligence and records.
What information travels
Both names — originator and beneficiary. An account or address identifier on each side that allows the transfer to be traced. And, on the originator side, either a location detail or an official identifier: a residential or registered address, a national identity or customer number, a date and place of birth, or a Legal Entity Identifier where the originator is a legal person.
Scope is where regimes diverge. In the European Union, Regulation (EU) 2023/1113 — the recast Transfer of Funds Regulation, applying since 30 December 2024 alongside the MiCA authorisation regime — imposes the information requirement on crypto-asset transfers between providers with no de minimis exemption, so value does not determine whether the rule applies. Other regimes apply a full data set above a stated threshold and a reduced set below it, and set that threshold themselves. The figure is jurisdictional and is not reproduced here.
For a corporate payer the official identifier is the field that removes ambiguity. A trade name renders differently in every system that touches it; an LEI resolves to one record in a public register.
What happens on each leg of a crypto-funded purchase
A purchase funded from digital-asset proceeds crosses two separate perimeters, governed by different instruments and failing in different ways.
| Leg | Obliged parties | What must accompany the transfer | Where it stops |
|---|---|---|---|
| Digital-asset leg — payer’s provider to the platform | The ordering provider and the receiving provider | Originator and beneficiary information, transmitted before or simultaneously with the transfer | Missing or unmatched data; no counterpart obligation on the receiving side; a self-hosted sending address with no ordering provider |
| Fiat settlement leg — the platform’s bank to the seller’s bank | The ordering institution, any intermediary, the beneficiary institution | Structured originator and beneficiary information in the payment message, with the remittance reference intact through the chain | Incomplete originator data, truncated or unstructured address fields, a beneficiary name that does not align with the receiving account |
Between the two legs sits the conversion. A licensed digital-asset platform screens the transaction and the sending address under its own licence, converts, and settles in national currency — the off-ramp function. Golden Ark Reserve receives national currency only; it holds no digital assets and issues no token or claim on metal.
How it runs, step by step
- The payer instructs their provider to send digital assets to the platform against a stated order reference.
- The ordering provider collects and verifies its own customer’s details and transmits the required originator and beneficiary information to the receiving provider before or with the transfer. Where the payer sends from a self-hosted address there is no ordering provider to transmit anything, and the receiving provider substitutes checks on ownership or control of that address.
- The receiving provider tests the message for missing or incomplete information and applies its documented procedure — execute, suspend pending a request, reject, or report.
- The platform screens, converts and settles. Screening runs on the address and the transaction under the platform’s own licence; the seller sees an outcome, not the analytics.
- The platform’s bank sends the payment. The originator field names the platform, the beneficiary field names the seller, and the order reference travels in the remittance field.
- The seller’s bank tests the incoming message — including, under the revised standard, alignment checks intended to catch misdirected payments — and the funds post against the order reference rather than arriving unattributed.
The route those steps describe is set out on Buy Gold with Crypto.
What it costs, and what sets the clock
No fee is charged to a payer for the travel rule itself. The cost is elapsed time, and it lands on a price that has been fixed.
Five components consume that time. Data collection and verification at the ordering provider, which is front-loaded and happens before anything moves. The receiving provider’s missing-information procedure, where a single request for a missing field stops the clock entirely until the payer’s provider answers. Screening, which runs alongside and is not visible from outside. The correspondent chain on the fiat leg, where any intermediary may hold a message its own rules read as incomplete. And, where a transfer is rejected, the return trip to the source account, which is measured in days rather than hours and returns the payer to the start.
Against a quoted price held for a stated window, each of these consumes that window. The practical cost of a travel-rule stop is therefore not a charge but a re-fixation: the metal is repriced at the quote in force when the funds finally arrive. The length of the window is a term of the quote and is stated there, not here.
What the rule produces, and what never reaches the buyer
The travel-rule message moves provider to provider. It is not issued to either customer, and neither the payer nor the seller receives a copy as a matter of course. What the payer can obtain is the provider’s own record of the transaction — the account statement, the conversion record and the screening outcome held under the platform’s licence — and it is that record, not the travel-rule message, that joins a counterparty document set. Requesting “the travel rule record” from the seller asks the wrong party for an artefact that structurally sits elsewhere; the workable request is made to the payer’s own provider, before the payment, while the account is still active and the data still retrievable. The evidential side of this is worked through in Crypto source of funds for a gold purchase.
The record Golden Ark Reserve issues to a counterparty is the Evidence Set; the digital-asset funding leg adds the screening record and the conversion record to it.
Where transfers fail
Name mismatch. The commonest failure and the one with the least regulatory content. The name on the paying account, the name in the payment message and the name on the purchase instruction must be one legal person. A payment made from a principal’s personal account against a corporate instruction, or from a group treasury entity against a subsidiary’s order, presents as an inconsistency — which is precisely what alignment checks exist to surface.
Missing or incomplete information. The EBA Travel Rule Guidelines (EBA/GL/2024/11) require providers to operate documented procedures for detecting missing information and for managing a transfer that lacks it; the available outcomes include suspension, rejection and reporting. From the payer’s side this presents as silence, then a request, then either a release or a return.
The sunrise issue. Where the two providers sit in jurisdictions at different stages of implementation, the sending side may carry obligations with no counterpart on the receiving side and no shared protocol to deliver into. The data has nowhere to land, and the transfer waits.
Self-hosted sending addresses. With no ordering provider in the chain, the receiving provider applies its own ownership or control checks, which can require the payer to demonstrate control of the sending address before the transfer is released.
Address format on the fiat leg. Cross-border payments over the Swift network have run on ISO 20022 under CBPR+ since the MT coexistence period ended on 22 November 2025, and from 14 November 2026 CBPR+ messages will no longer accept fully unstructured postal addresses, with non-compliant messages rejected. A payment held for a formatting defect is indistinguishable, from the payer’s side, from one held for a compliance defect.
Where the rule stands in 2026
FATF revised Recommendation 16 in June 2025 — the first substantial revision since the standard was adopted — clarifying responsibility along the payment chain, strengthening the information requirements, introducing alignment checks to detect misdirected payments, and placing new obligations on beneficiary institutions to obtain, transmit and use beneficiary information. Countries are expected to be ready by the end of 2030, which means national rules will reflect different generations of the same standard for years. In October 2025 FATF published Annex IV to its assessment methodology, setting out how compliance with the revised standard will be assessed in mutual evaluations — a shift from whether a jurisdiction has legislated to whether its payment data is traceable, accurate and complete in practice. On 24 June 2026 FATF opened a public consultation on draft implementation guidance, with responses due by 21 August 2026; one chapter addresses alignment-check obligations for beneficiary institutions specifically.
On the digital-asset side, FATF’s seventh targeted update, published on 16 July 2026, records that 83% of surveyed jurisdictions have now passed legislation implementing the Travel Rule, up from 73% a year earlier, with a further eleven reporting implementation under way — while finding that many jurisdictions have yet to translate those frameworks into supervision and enforcement. For a payer, the gap between legislation and enforcement is operational, not academic: it separates a counterparty provider running a working protocol from one that has a statute and no channel.
How the Travel Rule differs from the checks it is confused with
| Check | The question it asks | Who performs it | When |
|---|---|---|---|
| Travel Rule | Does the required originator and beneficiary information accompany this transfer, and does it match the receiving record? | The providers at each end, and any intermediary | At the moment of transfer |
| KYC | Who is this customer? | Each provider, and separately the seller | At onboarding and on review |
| Source of funds | Where did the money for this specific transaction come from? | The party accepting the payment | Before the payment is accepted |
| Wallet screening | Is this address exposed to sanctioned or illicit activity? | The platform, under its own licence | Before the transaction is accepted |
| Sanctions screening | Is a party to this payment a designated person? | Every provider in the chain | Continuously |
Why the name is what stalls the payment
Every account of the Travel Rule is written for the providers, because the providers are the ones it binds. That framing leaves out the party for whom it has the sharpest consequence. A buyer of physical bullion carries no obligation under the rule at all and can still lose a fixed price to it — not through a breach, but because the identity data that travelled did not match the identity data on the receiving side, and a machine check said so.
Two things follow for how a large purchase is set up. First, the paying identity is chosen before the quote, not after. The entity that pays, the account it pays from and the counterparty named in the instruction have to be one legal person; a substitution made late for treasury convenience arrives at the beneficiary institution as an inconsistency, and under the revised standard that inconsistency is what an alignment check is built to find. Second, an official identifier does work a name cannot. A registered legal person can be carried in a payment message by its Legal Entity Identifier — Golden Ark Reserve’s is 98450040E688696D1C47 — which resolves to a single public register entry, where a trade name is a string that four systems will render four ways.
The order reference carries the remainder. It binds quote, pro forma invoice, incoming payment, settlement and allocation to one instruction, so a payment that arrives complete posts against that instruction instead of sitting as an unattributed credit while someone reconstructs where it belongs.
Both legs, one name, one reference. That is the whole of what the Travel Rule asks of a party it does not regulate.
The counterparty and payment controls applied before an instruction is accepted are set out in AML & KYC Physical Gold Controls.