Skip to main content
The Travel Rule is a global financial regulation that requires Virtual Asset Service Providers (VASPs) — including exchanges, custodians, and brokers — to collect and share identifying information about the sender and recipient of crypto transactions above certain value thresholds. Its purpose is to prevent money laundering, terrorist financing, and sanctions evasion. As a VASP, Uphold manages the compliance logic, the underlying data exchange with other VASPs (via Notabene), and the collection interface. You are responsible for surfacing that collection to your users at the right moment in the transaction flow.

​
When it applies

Travel Rule applies to crypto transactions only — fiat transfers (bank, card) are not in scope. Above jurisdiction-specific value thresholds, your integration must surface the data collection to the user via the Travel Rule Widget. From the integrator’s perspective, the trigger is always the same: respond to the API signal (see API signals). What differs is what happens to the collected data downstream: Withdrawals — you collect beneficiary info from the user and submit it with the transaction. Uphold forwards it through its Travel Rule network (Notabene) to the counterparty. If the counterparty VASP is on the same network, it verifies the data and may reject the transaction — for example, by instructing Uphold not to send. If the counterparty is on a different Travel Rule network (such as TRUST), is a non-compliant VASP, or is an unhosted (self-custodied) wallet, no downstream exchange happens — but the data is still collected the same way. Deposits — when a crypto deposit arrives, Uphold cannot reliably tell whether it originated from a VASP on a different network, a non-compliant VASP, or an unhosted wallet. Any deposit above the threshold is placed on hold until the user provides the required originator info via the widget.
Thresholds are dynamic and change as regulations evolve across jurisdictions. Uphold manages this logic entirely — you do not need to track or implement threshold rules. The API signals when a requirement is active; your integration only needs to respond to those signals.

​
API signals

Uphold signals when Travel Rule action is required on a transaction:
  • Withdrawals — the quote response includes "travel-rule" in the requirements array. This must be resolved before the transaction can be created.
  • Deposits — the transaction enters on-hold status with reason pending-requests-for-information, and a pending request for information of type travel-rule is attached. The deposit cannot complete until the RFI is resolved.

​
Handling Travel Rule

1

Monitor transactions

Look at the travel-rule requirement on withdrawal quotes and on-hold status on deposits. These are the signals that user action is required.
2

Surface the requirement to the user

For withdrawals, block the quote confirmation flow until the user completes the widget. For deposits, notify out-of-band — the hold may occur after the user has left the flow.
3

Mount the Travel Rule Widget

Create a widget session and mount the Travel Rule Widget in your application. The widget handles the compliance collection on behalf of your platform.
4

User completes the form

Depending on the user’s jurisdiction and transaction, the widget presents one of two checks:
  • Self-declaration — the user attests the wallet belongs to them by providing their name and declaring their relationship to it. No cryptographic action is required. This is the default check in most jurisdictions.
  • Proof of Ownership — the user proves control of the wallet by signing a challenge message using their wallet software (for example, by approving an action in their wallet app or connecting a hardware wallet). Required when the user’s jurisdiction mandates cryptographic proof; Uphold applies this automatically based on current regulations and user location.
Uphold and Notabene determine which checks are shown based on internal compliance rules.

​
Proof types

When verifying an external crypto address — either during a standalone address verification flow or when resolving a Travel Rule Request for Information (RFI) — the platform collects proof from the user to demonstrate ownership or control of the wallet. The applicable proof types depend on the action being performed (registering a crypto external account vs. an active transaction) and the destination wallet type. There are three available proof types.

​
Message signing

Type Slug: message-signing Message signing uses digital signatures to establish absolute ownership and cryptographic control of a self-custody address. The user signs a specific, randomized text string using their wallet’s private key without broadcasting a transaction to the blockchain.
  • How it works: The user signs an off-chain plaintext message string directly inside their wallet interface.
  • Processing Time: Instant (< 1 minute).
  • Best For: Self-custodial wallets on EVM networks (Ethereum, Base, Arbitrum), Solana, and modern hardware wallets.
When used:
  • verified-level Address Book verification.
  • High-value withdrawals and deposits requiring the highest level of cryptographic certainty.

​
Satoshi test

Type Slug: satoshi-test A Satoshi test verifies ownership of a destination address through an on-chain microtransfer. The user demonstrates control over the wallet by sending an exact, randomized micro-amount of cryptocurrency to a designated platform verification address.
  • How it works: The user manually transfers an exact, randomized micro-amount of crypto to a specific platform verification address.
  • Processing Time: 10 to 60 minutes (dependent on blockchain block confirmation times).
  • Best For: UTXO-based blockchains like Bitcoin, Litecoin, or Dogecoin where native message signing is poorly supported by standard user wallets.
When used:
  • verified-level Address Book verification when message signing is unavailable.
  • Peer-to-peer transfers on non-EVM chains.

​
Self-Declaration

Type Slug: self-declaration A self-declaration is a declarative form of proof that relies entirely on the user’s legal assertion about the transaction and beneficiary details. No cryptographic validation or financial movement is required.
  • How it works: The user checks a digital compliance box confirming they are the sole owner and beneficiary of the address.
  • Processing Time: Instant (< 10 seconds).
  • Best For: Low-value, retail-tier withdrawals and deposits where minimizing user friction is prioritized over strict cryptographic proof.
When used:
  • declared-level Address Book verification.
  • Active deposits and withdrawals.

​
Start building

Deposit via API

Resolve a Travel Rule RFI on an on-hold crypto deposit directly via the API.

Deposit via Widget

Resolve a Travel Rule RFI on an on-hold crypto deposit with the Travel Rule Widget.

Withdrawal via API

Handle a Travel Rule requirement on a crypto withdrawal quote directly via the API.

Withdrawal via Widget

Handle a Travel Rule requirement on a crypto withdrawal quote with the Travel Rule Widget.

Address Book

Verify ownership of a saved crypto address ahead of a transaction.