Verification of a counterparty and, where funding originates in digital assets, of the wallet and conversion record attached to the payment. Searchers name it crypto KYC. It runs in two layers that are performed by different parties at different moments: the counterparty layer, which establishes who is contracting and which natural persons stand behind them, and the funding layer, which attaches to the address the assets were held at and to the record of their conversion into national currency. A counterparty clears the first layer once. The second is re-run on every payment.
What each of the two layers verifies
The counterparty layer is an entity file. It establishes the legal existence and standing of the contracting company, the authority of the individuals who sign for it, the ownership chain through to natural persons, and the exposure of the entity and those persons to sanctions, politically-exposed-person and adverse-media data. For an operating company that means constitutive documents, a current register extract, the ownership chain, board authority or power of attorney, and identification of the authorised representatives. Nothing in this layer is specific to digital assets; it is the same file a bullion counterparty produces when the money arrives by wire.
The funding layer attaches to the money and has three objects. The address the assets were held at, and its transaction history. The conversion — who performed it, under whose authorisation, on what date, into which account. And the payment that arrives, which has to be attributable to one specific instruction rather than to the counterparty in general. Source of funds sits in this layer: documentary evidence of where the assets came from, which for digital assets means an acquisition record, not an account of one.
One point in the funding layer is routinely misjudged. A payer’s own statement that a self-hosted address belongs to them is not verification. Under the European Banking Authority’s travel-rule guidelines, as applied by EU supervisors, self-declaration does not satisfy the ownership check on a transfer to or from a self-hosted address; the provider has to establish control by technical means. A counterparty who expects to assert ownership of an address and be believed is planning for a conversation that will not happen.
Who performs which check
What is loosely called crypto KYC requirements is not one requirement set but three, applied from three seats that cannot substitute for one another.
The licensed digital-asset platform. Under its own licence it applies customer due diligence to the payer, screens the address and the transaction, converts, and settles in national currency. Every one of those checks completes before anything reaches the seller.
The seller. It onboards the counterparty, screens against sanctions and PEP data, reviews source of funds, and binds the payment to a stated order reference. Golden Ark Reserve is settled in fiat against a named order reference, holds no digital assets, and issues no token or claim on metal. It performs no address screening, because it never receives an address.
The receiving bank. It applies its own controls to the incoming payment: who sent it, on whose behalf, and against what.
A platform’s clearance is not a KYC file on the buyer. A seller’s counterparty file is not an answer to the bank’s question about the payer of record. A bank’s acceptance of a payment is not a finding about the address behind it. Counterparties who treat any one of the three as covering the others discover the gap at the point where the money is already in motion.
The sequence, and what each step gates
- Counterparty onboarding, before any quote is executable. Entity documents, ownership chain, authorised representatives, sanctions and PEP screening. The output the counterparty sees is a verified status with a date and an internal reference; the screening report itself is internal and is not issued.
- Quote and pro forma invoice, issued against an order reference. The reference is created here, and every document and payment downstream carries it.
- Payer and address checks at the platform, before conversion. Address screening, transaction analytics, and — where the assets sit at a self-hosted address — verification that the address is controlled by the payer.
- Conversion and fiat settlement. The platform converts and settles the seller in national currency, quoting the order reference.
- Attribution. The incoming payment is matched to the instruction. A payment that cannot be matched is an unattributed credit, and no metal is allocated against one.
- Allocation and documentation. Bars are allocated by serial number; the commercial invoice issues against the actual allocated bars; the compliance record joins the counterparty’s document set.
- Re-entry. A further purchase, or a buyback, re-runs screening. Verification is a state with a date on it, not a permanent condition.
What the check costs, and what sets the timing
The cost is time and documents rather than a fee, and it is not evenly distributed. Four components carry it: producing the corporate file, which runs longest where ownership passes through several layers or several jurisdictions; the platform’s own onboarding, which proceeds in parallel and to its own standard; the address and transaction review, which lengthens with the number of hops between acquisition and payment and with any exposure that has to be explained rather than merely observed; and the receiving bank’s review of a payment sent by an intermediary.
Elapsed time is set by the weakest-documented element, not the average one. A counterparty with a clean ownership chain and a five-year-old acquisition it cannot evidence is slow for the second reason, not the first. No stage is priced here and no turnaround is quoted.
What the completed check leaves behind
A record set, not a certificate. On the counterparty side: the verified status, its date and its internal reference. On the funding side: the conversion record from the platform, the settlement confirmation naming the order reference, and the pro forma invoice against which the advance was paid. On the metal side: the commercial invoice issued against the allocated bars, the Allocation Record with serial numbers, and the confirmation of title.
These are the documents from which a reviewer reconstructs the transaction, which is why the order reference has to appear in each of them rather than in most of them. A document set in which one instrument carries no reference is a set in which one link of the chain is asserted rather than shown.
What has changed in 2026
The framework a compliance reviewer is working against moved twice this year, in opposite directions, and both movements matter to a payment that starts in digital assets and ends in bullion.
Coverage is nearly universal; enforcement is not. In its seventh targeted update on virtual assets, published 16 July 2026, the FATF found that 83% of surveyed jurisdictions now have travel-rule legislation in force, up from 73% a year earlier, with a further eleven reporting implementation under way. The same report finds that many jurisdictions have not translated those legal frameworks into effective supervision and enforcement in practice, and names offshore providers, self-hosted wallets and stablecoins among the standing gaps — noting that most identified on-chain illicit activity now involves stablecoins, which are also the assets most often used to fund this kind of purchase. The operative question about a platform is therefore no longer whether its jurisdiction has the rule. It is whether that jurisdiction supervises against it, and a reviewer who checks only the first has checked the cheaper of the two.
The European rules set the practical floor. Regulation (EU) 2023/1113, applicable since 30 December 2024, requires originator and beneficiary information to accompany every crypto-asset transfer with no de minimis amount — the strictest implementation in force anywhere, and the standard a platform serving European counterparties builds to. For transfers to or from a self-hosted address above EUR 1,000 the provider must additionally establish that the address is owned or controlled by its customer. Where the originator is a legal entity, the required dataset names its Legal Entity Identifier, or an equivalent official identifier where no LEI exists. From 10 July 2027, Regulation (EU) 2024/1624 places crypto-asset service providers on the same obliged-entity footing as banks: full due diligence on occasional transactions at or above EUR 1,000, a prohibition on anonymous crypto accounts, and collection of the LEI where available when identifying a legal-entity customer. These are European thresholds attaching to European providers, not thresholds this seller states.
The fiat leg is being rebuilt to match. The FATF’s revised Recommendation 16, agreed in June 2025 and to be implemented worldwide by the end of 2030, extends structured originator and beneficiary data across the whole cross-border payment chain and introduces alignment checks — a beneficiary institution comparing the names in a payment message against its own records. Draft guidance went out for public consultation on 24 June 2026, with Chapter 10 devoted to how those alignment checks are to be met. The direction is unambiguous: the payment arriving at a seller’s bank will carry more structured data about who sent it and on whose behalf, and a payment whose payer of record is not the counterparty of record is precisely what an alignment check is designed to surface.
Where it fails
Screening after conversion instead of before. Once assets have been converted, the address history is a document rather than a control. Nothing found at that point can stop a settlement that has already happened.
Self-declared address ownership. Covered above, and the single most common assumption a payer brings to a first transaction.
A payment sent without the reference. It arrives as an unattributed credit. No allocation follows, and the money sits until it is matched or returned to its source account.
Assets acquired long ago with no acquisition record. A source-of-wealth account is offered where source-of-funds evidence is required. The two are different questions and the substitution is visible.
Entity data that has drifted. A lapsed LEI, a legal name that no longer matches the register, an authorised signatory who has left. These fail automated matching before a human reads the file, and the counterparty is told only that the file is incomplete.
De-risking. The bank declines the category rather than assessing the case. It is not a finding about the counterparty and cannot be answered by producing more of the same documents.
How it differs from the terms it is confused with
| Term | What it addresses | Who performs it |
|---|---|---|
| KYC (digital-asset funding) | Who the counterparty is, plus the wallet and conversion record behind the payment | Seller and platform, in their own layers |
| Source of funds | Where the money in this transaction came from | Seller, and the receiving bank |
| Source of wealth | Where the payer’s overall assets came from | Seller, and the receiving bank |
| Proof of funds | That the payer holds the money, not where it originated | Produced by the counterparty |
| AML | The whole control set, including monitoring, record-keeping and reporting | Every obliged entity in the chain |
| Wallet screening | An address, against sanctions lists and risk indicators | The platform |
| Transaction screening | One transaction, before it is processed | The platform, and the bank |
| Travel Rule | Originator and beneficiary information travelling with a transfer | The platform and its counterparty provider |
| KYB / beneficial ownership | The entity and the natural persons behind it | Seller, inside the counterparty layer |
Attribution before identity
Ordinary KYC answers one question: who is this. Verification of digital-asset funding has to answer that and then answer a second one that the payment itself cannot. On whose behalf did this money arrive.
In this route the payer of record on the incoming settlement is the platform. The buyer’s name is not in the payment message. The buyer’s address is not visible to the seller, which never receives one. The seller’s bank sees a payment from a licensed intermediary to a beneficiary it recognises, and nothing between the two. Every incumbent treatment of this subject is written from the provider’s seat, where identity is the whole problem. From the seat that receives the fiat, identity is settled early and attribution is what remains.
Two identifiers close that gap, and narrative does not. The order reference closes it inward: created at quote, repeated in the pro forma, the gateway payment, the settlement, the allocation and the resulting documents, it is the thing that makes incoming money an instruction rather than a credit. The entity identifier closes it outward: the LEI is already named in the European dataset that must accompany a crypto-asset transfer where the originator is a legal entity, and from July 2027 it is named again in the identifying dataset an EU obliged entity collects. It resolves to public reference data that a reviewer can check without asking anyone, which is what a legal name spelled four ways cannot do.
The consequence is narrow and practical. A file clears when the counterparty named in the contract, the counterparty named in the Allocation Record, and the counterparty a reviewer resolves from a public identifier are demonstrably one party, and when every payment between them carries a reference tying it to a single instruction. None of that is specific to digital assets. It is only that a payment arriving through an intermediary is the case where its absence becomes visible immediately.
The controls described here are set out in full on AML & KYC Controls in Physical Gold Transactions.