Skip to content

Self-hosted wallet verification

Connect wallet ownership and additional evidence checks to your policies

Self-hosted wallet verification confirms that:

  • in case of withdrawals, the customer controls the destination address before you proceed with a withdrawal, or
  • in case of deposits, the customer controls the origin address before you release funds to them.

Regulations such as MiCA require transaction value based controls for transactions involving non-custodial wallets.

When to trigger verification

Common trigger points include first-time transactions, amounts above thresholds defined by the regulation or internally, or when analytics tools flag elevated risk. Align the trigger with your transaction monitoring policies so customers experience a consistent flow.

Where it fits in the workflow

Outgoing transactions (withdrawals)

  1. Collect the intended withdrawal details (asset, amount, destination wallet).
  2. Decide whether the withdrawal qualifies for a self-hosted wallet check based on your policy.
  3. Run the verification flow before you move funds, and store the result alongside the pending transaction.
  4. Continue with the post-transaction or pre-transaction Travel Rule workflow once ownership is confirmed, or escalate if verification fails.

Incoming transactions (deposits)

When receiving a deposit without a Travel Rule message, you can apply (depending on your internal AML policies) the following logic:

  1. If the deposit is above an internally defined threshold (for example, amount or risk score), ask the customer for the origin of the funds: a. Sent from another exchange - the customer can also enter the sender's name and exchange; use the backfilling workflow to capture the missing data. b. Sent from their self-hosted wallet.
  2. If they claim it was sent from their self-hosted wallet, run the verification flow before you release the funds.

Verification methods supported by CryptoSwift

  • Cryptographic signature proofs – Customers sign an off-chain message with their private key. CryptoSwift verifies signatures for Bitcoin, Solana, EVM-compatible networks following CAIP-122 and more.
  • Micro transactions (Satoshi Test) – Customers send a small deposit from the destination wallet within a 48-hour window. CryptoSwift monitors supported blockchains (Bitcoin, Ethereum, Dash, Litecoin, Dogecoin and more) and flags success automatically.
  • Wallet videos and screenshots – Customers upload evidence from their wallet application for manual review.
  • Self-declaration – Customers tick a checkbox declaring ownership. It is the least secure option but useful as a fallback when stronger evidence is unavailable.

You can find a detailed list of supported blockchains per verification method here

Additional steps in the workflow

Wallet verification can include additional customer steps after the ownership check. CryptoSwift supports a combined Source of Funds / Source of Wealth document request and a guided Selfie step in the same widget workflow.

  • Source of Funds / Source of Wealth collects supporting documents and requires manual review.
  • Selfie captures a random sequence of guided actions, a final selfie, and a short video. Backend liveness analysis can verify the step automatically when that setting is enabled, or leave it for manual review.

Each step has its own status, independent from the wallet ownership result. Your policy should decide which results must be accepted before funds are released or a withdrawal proceeds.

Follow the Additional steps workflow for a complete dashboard and customer journey. See the Additional Steps integration guide for request formats, status lifecycles, evidence endpoints, liveness results, and review behavior.

Choose an integration approach

  • Wallet verification widget – Embed a configurable web component or redirect to a hosted flow with minimal engineering effort. Ideal when you want a managed UX and rapid rollout.
  • Wallet verification API – Orchestrate verification completely within your app, combining your own UI with CryptoSwift endpoints for maximum flexibility. Useful for mobile-first or highly customised experiences.

Operational considerations

  • Store verification results with transaction metadata so auditors can confirm when proofs were obtained.
  • Reuse successful verifications according to your risk policy (for example, accept the same wallet for 12 months unless risk scores change).
  • Ensure webhook events are routed to the systems that update withdrawal status verification outcomes arrive alongside Travel Rule notifications.

Next steps

See also