> ## Documentation Index
> Fetch the complete documentation index at: https://developer.uphold.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Travel Rule overview

> Understand the Travel Rule regulatory requirement, when it applies to crypto transactions, and how Uphold's Travel Rule solution works.

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](#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.

<Warning>
  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.
</Warning>

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.

    <Note>Uphold and Notabene determine which checks are shown based on internal compliance rules.</Note>
  </Step>
</Steps>

## Start building

<CardGroup cols={2}>
  <Card title="Deposit flow" icon="arrow-down-to-bracket" href="/developer-guides/travel-rule/deposit">
    Resolve a Travel Rule RFI on an on-hold crypto deposit.
  </Card>

  <Card title="Withdrawal flow" icon="arrow-up-from-bracket" href="/developer-guides/travel-rule/withdrawal">
    Handle a Travel Rule requirement on a crypto withdrawal quote.
  </Card>
</CardGroup>