Why does an exchange ask who sent you a payment?

An exchange asks who sent you a payment because the law requires it to: under what is called the travel rule, a regulated provider must collect and pass on information about the sender and the recipient of a transfer, and it must assess transfers that involve a wallet no provider stands behind. A stablecoin payment that reaches your account from a wallet the provider cannot identify therefore opens a questionnaire, and sometimes a hold, until you say who paid you and why.

This article is written for a business or a professional who is paid in stablecoins for real work, a broker, an agent, a freelancer, a small company, and who then converts to cash through a regulated exchange or payment provider. Rules differ from one country to the next and change over time, so what follows is general information, not legal or tax advice.

What is the travel rule, in plain words?

The travel rule is the obligation for a regulated financial provider to make the identity of the sender and of the recipient travel with a transfer, from the provider that sends it to the provider that receives it. The name comes from that image: the information accompanies the money along its route instead of staying in the first provider's records.

A bank wire already works this way: the message carries the payer's name and account, and your bank reads them before crediting you. A blockchain transfer carries none of that. It records a sending address, a receiving address, an amount and a time, and nothing about who stands behind either address. The travel rule fills that gap for regulated providers: they must obtain the names and identifiers themselves, hold them, and send them to the provider on the other side through a separate, private channel. Nothing is written on the blockchain, and the public record of the transfer stays exactly as bare as before.

Two words come back in every form you will be given. The originator is the person or company that sends the payment: your client. The beneficiary is the one who receives it: you, or your company. A provider acting for the beneficiary has to know who the originator is, and that is the question on your screen.

Where does the travel rule come from?

The travel rule comes from Recommendation 16 of the Financial Action Task Force, the intergovernmental body that sets the international standards against money laundering and terrorist financing, and it was extended to virtual assets in 2019. The Task Force does not regulate any company directly: it publishes standards, and each member country writes them into its own law.

Recommendation 16 was written for wire transfers. In its own words it requires financial institutions to include required and accurate originator information, and required beneficiary information, on a transfer. In 2019 the Task Force revised the interpretive note to its Recommendation 15, the one that deals with new technologies, so that the same duty covers what it calls virtual asset service providers: exchanges, custodians, brokers and payment firms that handle crypto-assets for customers.

The Task Force's guidance for these providers sums up the duty in one line: they must obtain, hold and transmit required originator and beneficiary information, immediately and securely. The same guidance is explicit about what the standard leaves out. A transfer between two self-hosted wallets whose users act for themselves, with no provider on either side, is a peer-to-peer transfer, and the guidance notes that such transfers are not explicitly subject to these controls. The rule binds the provider, never the wallet.

That is why the rule reaches you at one precise moment: when the money touches a regulated provider. A client can pay your own wallet without any form being filled. The day you send those funds to an exchange to convert them, the exchange becomes the point where the standard applies, and it applies to you as the exchange's customer.

How is the travel rule applied in the United States, the European Union and the United Kingdom?

The three regimes apply the same principle with different amounts: the United States sets its funds travel rule at $3,000, the European Union applies its regulation to crypto-asset transfers of any amount and adds a check on self-hosted addresses above €1,000, and the United Kingdom asks its firms to collect, verify and share the information and lets them question transfers involving an unhosted wallet according to risk. The table gives each figure with the text it comes from.

Two remarks help in reading it. First, the United States rule dates from the world of wires. The Financial Crimes Enforcement Network explained in its 2019 guidance that transactions in convertible virtual currency qualify as transmittals of funds and may therefore fall within the funds travel rule, with the same $3,000 threshold.

Second, the United Kingdom shows that these figures move. The Financial Conduct Authority has applied the travel rule to cryptoasset businesses since 1 September 2023, and the amount in the regulations on unhosted wallet transfers was first expressed in euros before being replaced in 2026 by a figure in pounds. A British firm that does not receive the information it asked for must not make the cryptoasset available to the recipient: that sentence of the regulations is the legal basis of a hold.

Do not read the table as a list of safe amounts. Each provider adds its own policy on top of the law, often asks its questions well below the legal figure, and may treat several small transfers that are linked as one. A provider licensed in several countries commonly applies its strictest rule to every customer. The only reliable threshold is the one your provider gives you when you ask.

Why does a payment from a self-hosted wallet draw more questions?

A payment from a self-hosted wallet draws more questions because no regulated provider stands on the sending side to supply the sender's details, so the receiving provider has to obtain them from its own customer. A self-hosted wallet, also called unhosted or self-custody, is one whose owner holds the keys personally, with no company in between.

Compare the two routes a client's payment can take to your exchange account.

When the client pays from an account at another regulated provider, that provider already knows its customer. It sends the client's name and identifiers to your provider at the time of the transfer, your provider checks that the recipient named matches the holder of your account, and the deposit is credited. Often you are asked nothing at all. When a question does come, it tends to concern a mismatch: the client typed your trading name where your account is in your personal name, or the reverse.

When the client pays from a self-hosted wallet, nobody sends anything. Your provider receives funds from an address it cannot attach to a person. The European regulation spells out what it must then do: obtain and hold the information on the sender and the recipient, and make sure the transfer can be individually identified. The United Kingdom regulations let the firm request the information from its customer according to the risk it sees, and they list what that assessment weighs: the purpose and nature of the relationship and of the transfer, its value, the frequency of transfers and the duration of the relationship.

There is a third route, which many professionals use: the client pays your own self-hosted wallet, and you forward the funds to the exchange later. The provider now sees a deposit from an address you say is yours. It will ask you to prove that, which is the subject of a section below, and it may still ask where the funds came from before they reached your wallet. Passing through your own wallet does not remove the question about the payer. It adds a question about you.

What will the provider ask you for?

A provider typically asks for five things: the sender's name and details, your relationship with the sender, the purpose of the payment, a document that supports it, and, where a wallet is said to be yours, proof that you control it. The form varies from one provider to the next; the substance hardly does.

The sender's identity. For a person: full legal name, and often country of residence and address. For a company: registered name, country of registration and, where it exists, a registration number. Some forms ask whether the sending wallet is the sender's own or is held with a provider, and which one.

The relationship. Client, employer, buyer, counterparty in a transaction. One line is enough, as long as it agrees with the document you attach.

The purpose. What the payment is for, in ordinary words: a brokerage fee on the sale of a company, an invoice for design work, a deposit on an order. Avoid vague labels such as "services" or "transfer". Purpose is the field compliance teams read first, and a precise sentence saves a round of follow-up questions.

The supporting document. An invoice, a signed contract or engagement letter, a purchase order, a closing statement. The best document shows the same parties, the same amount and a date close to the transfer. If the invoice is in another currency, or the amount differs because of a discount or a partial payment, say so in one line instead of letting the reviewer find the difference.

The origin of the funds, sometimes. For larger amounts the provider may ask how the payer came to hold the money. You are rarely in a position to prove this for someone else. State what you know, give the payer's business activity, and say plainly what you do not know. A reviewer accepts "I do not have that information" far more easily than a guess that later turns out to be wrong.

Answer as a business that received a payment, because that is what you are. Many forms are designed for people who trade, with choices such as "investment" or "trading profit". Choose the option that describes a commercial receipt, or the free-text field, and describe the deal.

How do you prove you control a wallet?

Wallet control is proven in one of two ways: by signing a short message with the wallet, or by sending a small test transfer from it. Both show that you hold the keys of the address, and neither requires you to reveal those keys to anyone.

The signed message. The provider displays a short text, usually a sentence containing a unique code. You paste it into your wallet's signing function. The wallet uses your private key to produce a signature, a long string of characters, which you copy back to the provider. Anyone can check mathematically that this signature could only have been produced by the key of that address, while the key itself never leaves your wallet. Signing a message moves no funds and costs no network fee. Read what you sign: a genuine proof of ownership is a plain sentence, not a transaction and not a permission to spend.

The test transfer. The provider asks you to send a small, exact amount from the address to your account, within a set time. If the amount arrives from that address in that window, the provider accepts that you control it. This method works with any wallet, including those with no signing function, at the cost of a network fee and a short wait. Send the exact figure requested, since the amount is the code.

One limit matters for a business. You can only prove control of a wallet that is yours. If the deposit came straight from your client's wallet, do not declare that address as your own to get through the form faster. Declare it for what it is, a third party's wallet, and give the client's details. A false declaration of ownership is the kind of inconsistency that turns a routine review into a closed account.

What should you prepare before a large payment arrives?

Before a large payment arrives, prepare a file of five items: the invoice, the contract, the payer's identity details, the transaction reference and a short note linking the payment to the deal. Three of the five exist before the money moves, and the other two take minutes to add.

Two steps outside the file are worth the time. Tell your provider in advance when an unusually large payment is expected: many have a channel for this, and a reviewer who has already seen the contract treats the deposit as expected. And check which name your account is in. If the contract and invoice are in your company's name and the exchange account is personal, the documents will not match the account holder, and opening a business account before the deal is simpler than explaining the difference after it.

What does the review look like on a $48,000 fee?

On a $48,000 fee, a complete file turns the review into a two-day formality, while a missing file stretches it by as long as it takes to obtain documents from other people. The example below is an illustration, with invented parties and timings chosen to show the mechanism; no provider commits to these delays.

Call her Elena, an independent business broker. She advises the owner of a small company on its sale. The company sells for $1,200,000 and her engagement letter sets a success fee of 4%, which makes $48,000. The seller's holding company pays the fee in a dollar stablecoin, from a self-hosted wallet, to Elena's business account at a regulated provider. The amount is 16 times the $3,000 threshold of the United States rule, and it is the first large deposit on her account, so questions are certain.

Her file holds five items: the engagement letter signed by both parties, stating the 4% fee; the holding company's registered name, country, registration number and address, with the name of its director; her invoice for $48,000, naming the stablecoin, the network and her deposit address; the transaction reference with its date and both addresses; and a five-line note. The note reads roughly as follows: success fee due under the engagement letter of the stated date, for the sale of the named company at $1,200,000, 4% of the price, invoice number stated, paid by the seller's holding company from its own wallet in one transfer, reference stated.

The table sets that file against the same deposit with nothing prepared. Days are business days, counted from the deposit.

In this illustration the prepared file saves six business days, the gap between a release on day 2 and a release on day 8. None of that gap is spent by the provider. It is spent waiting for a counterparty whose deal is finished and who no longer has a reason to hurry.

What does the travel rule not do?

The travel rule is not a tax report, does not make an onchain payment reversible, and does not put your identity on the blockchain. It governs one thing: the information that regulated providers must hold and exchange about the two ends of a transfer.

No tax return is filed for you. The details collected under the travel rule serve the prevention of money laundering. They do not declare your income and do not replace your own accounting. Tax reporting by crypto providers exists in a growing number of countries, under separate rules with their own scope. Assume that what you receive is taxable in the ordinary way for your business, and take the question to your accountant with the same file.

The payment stays final. A hold applies to the balance in your account at the provider. It does not undo the transfer, and the provider cannot send the payment back along the chain as a bank might recall a wire. If a provider declines to credit a deposit, what follows is governed by its terms and by the law it operates under, and can take time. Hence the value of clearing the question before the payment.

Your details are not published. The names and identifiers travel between providers through private channels and are stored in their records. The blockchain shows the same addresses and amounts as it did before.

How does record-keeping at the moment of the deal make conversion smooth?

Record-keeping at the moment of the deal makes conversion smooth because every answer the provider will ask for already exists then, agreed by both parties and dated before the money moved. A document created after a hold answers the same question with less weight, since the reviewer can see that it was produced for the review.

Two habits carry most of the benefit.

Keep one folder per deal, with the five items of the file and nothing else, named so that you can find it months later.

Keep the amounts aligned. The contract, the invoice and the transfer should show the same figure, or the difference should be explained in the note. When a deal pays several people, the best practice is for each of them to be paid their own share by the payer instead of one person receiving the total and redistributing it. A broker who receives the whole fee and forwards half to a co-broker has to document two transfers and explain why the amount received is twice the amount earned.

On the point of shares, a payment router such as Shaka works at the same moment as the paperwork. Each party's share of a deal is agreed, and can be signed by each recipient, before the client pays; the client then pays once, every party is paid at the same moment, and the payment is final. Shaka routes the payment and never holds the funds. For record-keeping, this means that the statement of who is owed what exists before the payment and matches what each party receives. It does not replace the checks your own provider carries out when you convert: those remain between you and the provider, with the file described above.

One last practice costs nothing. Keep the file for as long as your accounting records are kept, alongside the invoice it belongs to. The same five documents answer the exchange today, the accountant at year end, and the bank the day it asks where a large incoming transfer from an exchange came from.