1. Home
  2. Insights
  3. Wallet Ownership Verification
Digital assets · 8 min read

Wallet ownership verification: how it works and why providers ask for it

Before converting digital assets into fiat, or sending them out, a regulated provider needs to know that the wallet involved belongs to the person it is dealing with. Proving that is simpler than many clients expect, once they know which method applies.

The problem verification solves

A bank transfer comes with a name attached. The sending bank has identified its customer, and the payment message carries that customer's name and account number. A transfer on a public blockchain has none of that. It moves value from one address to another, and an address is just a string of characters. Nothing on the chain says who controls it.

That creates a gap for any regulated business dealing in digital assets. If a client says the coins arriving from a particular address are theirs, the provider needs some way to confirm it. If a client asks for funds to be sent to an address, the provider needs to know whether that address belongs to the client or to someone else. Without that confirmation, the provider cannot properly identify who it is dealing with, cannot apply the travel rule correctly and cannot rule out that it is helping move someone else's money.

Wallet ownership verification is the set of methods used to close that gap. It proves control of an address, which in most cases is the closest available evidence of ownership.

Why providers verify

Several obligations push providers to verify wallets. Know-your-client rules require a provider to understand who its client is and where the client's funds come from. If coins arrive from an address the client does not control, the true source of those funds is someone else, who has not been identified.

The travel rule applies to virtual currency transfers. It requires information about the originator and beneficiary of a transfer to accompany or be associated with it, broadly in the same way that information travels with a wire transfer. When the counterparty is another regulated service, that information can be exchanged between the two services. When the counterparty is a self-hosted wallet, there is no other service to exchange data with, so providers commonly need to establish who controls that wallet in some other way.

Fraud prevention also matters. Clients are sometimes manipulated by scammers into sending funds to addresses they believe are their own. Verifying that a destination address is controlled by the client before sending a withdrawal catches some of these cases.

Finally, sanctions and screening obligations require providers to know whose funds they are handling. Verification works alongside on-chain screening, which looks at the history of the address. Our article on on-chain analytics covers that side.

Self-hosted and exchange wallets

The method a provider uses depends heavily on what kind of wallet is involved.

A self-hosted wallet, sometimes called an unhosted or non-custodial wallet, is one where the client holds the private keys. This includes hardware devices, desktop and mobile wallet apps, and multi-signature arrangements. Only the key holder can move funds or sign messages from the address. Because there is no intermediary, verification relies on the client demonstrating control directly.

An exchange or custodial wallet is one where a third party, such as a crypto exchange or custodian, holds the keys on the client's behalf. The client has an account with the exchange and sees a balance, but cannot sign messages from the underlying address and often shares deposit addresses with other users in ways that are not visible from outside. Here, verification usually relies on evidence that the client holds the account at the exchange, and on information exchanged between the provider and the exchange under the travel rule.

Mixing these up causes most of the confusion clients experience. A client asked to sign a message from an exchange deposit address cannot do it, because they do not hold the key. A provider expecting a signed message from such an address will need to use a different method.

Signed messages

The cleanest method for self-hosted wallets is a cryptographic signature. The provider gives the client a short piece of text, often including a unique code and the date. The client uses their wallet software to sign that text with the private key controlling the address. The resulting signature is sent back to the provider, which checks it against the address and the original text.

If the signature verifies, it shows that whoever produced it held the private key for that address at the time of signing. It does not move any funds and does not reveal the private key. Most major blockchains and many common wallet applications support message signing, though the menu option may be labelled differently from one app to another, and some hardware wallets require a companion app.

The unique text matters. A signature over a generic phrase could be reused or supplied by someone else. A signature over a message that the provider generated for this client, today, is much stronger evidence.

Signed messages work less smoothly for some multi-signature wallets and smart contract wallets, where control is shared or defined by code. In those cases the provider may need to understand the wallet's structure and accept evidence of how signing authority is arranged.

Test transactions

Where signing is impractical, a provider may ask for a small test transaction instead. The client sends a specified small amount, sometimes an unusual figure chosen by the provider, from the address in question to an address the provider controls. When the provider sees that exact amount arrive from that address, it has evidence that the client could move funds from it.

Test transactions are easy for clients to understand and work with almost any wallet. They have some drawbacks. They cost network fees. They take time to confirm on some chains. And on their own they show only that someone sending on the client's behalf controlled the address, so they are usually combined with the client's confirmation and the provider's other checks.

A variation works in the other direction: the provider sends a small amount to the client's address and asks the client to confirm the exact amount received, or to send it back. This proves the client can see the wallet, but proving the ability to see is weaker than proving the ability to spend.

Other approaches

Several other forms of evidence are used, usually alongside one of the methods above.

  • Exchange account evidence. For custodial wallets, a statement or account export from the exchange showing the client's name, the relevant deposit or withdrawal, and the transaction reference.
  • Travel rule data. Where both sides of a transfer are regulated services, originator and beneficiary information exchanged between them can confirm who the transfer belongs to.
  • Screen evidence. Screenshots or screen recordings of the wallet application showing the address and balance. These are easy to fake and are generally treated as supporting material only.
  • Declarations. A signed confirmation from the client that they own and control the address. This is useful for the record but not sufficient alone for higher value or higher risk transfers.
  • Address whitelisting. Once an address has been verified, the provider adds it to an approved list for that client. Later transfers to or from it can rely on the earlier verification, subject to ongoing screening.

Which combination a provider uses depends on the amount, the risk profile of the client and the address, and its own policies.

Wallets held by companies, trusts and funds

When the client is an entity, verification has an extra layer. The provider needs to know that the wallet is controlled by the entity, and that the people operating it are authorised to do so. A family office holding digital assets for a trust, for example, should be able to show that the wallet is held for that trust, who holds the keys or signing devices, and that those people are acting under the trustees' authority.

Multi-signature arrangements are common for entities, with keys split between directors or trustees. That is good practice for security, and it fits well with verification if the entity documents how signing authority is shared. A short internal policy naming the key holders, the signing threshold and how keys are stored is helpful evidence for a provider, and good governance in its own right.

For custodial holdings, the entity should hold the custody account in its own name. An exchange account held personally by a director, used to hold company or trust assets, creates confusion about ownership and is likely to be challenged.

Practical tips for clients

  • Know whether your wallet is self-hosted or custodial before you start. If you do not hold a seed phrase or hardware device, it is almost certainly custodial.
  • Check that your wallet software supports message signing, and practise once on a small address if you are unfamiliar with it.
  • Do not send funds to a provider from an address until it has been verified, unless the provider has told you to do so as a test.
  • Never share a private key or seed phrase with anyone, including a provider. No legitimate verification process needs it.
  • Keep exchange statements for transfers that fund your account, showing your name and the transaction.
  • Use a dedicated address for transfers to and from a provider where possible, which keeps the history clean and simplifies screening.

General information only

This article is general information about wallet verification practices. It is not legal, tax or investment advice, and the exact methods a provider uses will depend on its policies, the client and the circumstances of each transfer.

CCYFX converts digital assets to and from fiat for eligible clients, with wallet ownership verification and on-chain screening as part of each relationship. Read more on our digital assets page.

Open an account

Tell us about your business

Apply online in about ten minutes. We will reply with the documents your structure requires and an indicative timeline for onboarding.

Book a callOpen an account