Overview

Global Travel Rule regulations require financial institutions and crypto providers to collect and share basic information about their customers for certain crypto transfers. For Bridge integrations, the practical rule is simple: if Bridge needs originator or beneficiary information for a crypto movement, your application will need to collect it and send it to Bridge to support Travel Rule compliance. Bridge stores and uses this data during compliance workflows, but your application is usually the system that knows:

who the customer is transacting with (“the counterparty”)
whether the wallet should be treated as self_custodied, hosted, or external
whether the counterparty remains the same for every movement on a route or varies for each transaction

Official references:

U.S.: 31 CFR 1010.410(f) and FinCEN virtual currency guidance
E.U.: Regulation (EU) 2023/1113

This guide is about implementation decisions: when data is required, what data to collect, and where to send it.

Eligible Transactions

You should determine whether Travel Rule data is required before funds move. As a developer integrating with Bridge, there are two separate checks to make:

Amount requirements

Crypto Travel Rule requirements depend on jurisdiction:

U.S. customer crypto money movements above USD 3,000 equivalent
E.E.A. customer crypto money movements at any amount

E.E.A.-related crypto flows include the following:

any transaction with either an EUR or EURC leg (e.g. EUR pay-in to a vIBAN, EUR payout, EURC conversion, etc.) regardless of the customer’s location OR
any transaction involving an EEA customer, regardless of the currencies used.

Ownership verification and attestation are required for any E.E.A.-related transaction exceeding €1,000 involving a self_custodied or hosted wallet tied to a Bridge customer.

Source and flow requirements

Source matters because Bridge may or may not receive Travel Rule data from the sending provider. If the source wallet belongs to another Crypto Asset Service Provider (CASP), that provider should send the required Travel Rule data to Bridge. In that case, you generally do not need to collect and submit the sender’s data yourself. Otherwise, you should collect and submit Travel Rule data for:

incoming crypto from a self-custodied wallet
incoming crypto from any source where no crypto provider is transmitting Travel Rule data to Bridge
onramps where Bridge will send crypto to a destination wallet, because Bridge needs beneficiary information before payout

In practice, this usually means:

collect originator data for inbound crypto deposits into Bridge
collect beneficiary data for outbound crypto payouts from Bridge, including onramps and withdrawals to destination wallets

Understanding the travel rule data

Bridge accepts the same travel_rule_data shape whether you attach it on a reusable resource or submit it with the one-off endpoint. For eligible crypto deposits and withdrawals, we require originator information about the party sending the crypto and beneficiary information about the party receiving the crypto from either you or from another crypto-asset service provider (“CASP”).

{
  "originator": {
    "name": "Jane Smith",
    "address": {
      "street_line_1": "123 Market St",
      "street_line_2": null,
      "city": "San Francisco",
      "state": "CA",
      "postal_code": "94105",
      "country": "USA"
    },
    "identifying_information": {
      "type": "national_id",
      "number": "1234567890",
      "issuing_country": "USA"
    },
    "birth_date": "2000-01-31",
    "place_of_birth": {
      "city": "San Francisco",
      "country": "USA"
    },
    "wallet_type": "self_custodied",
    "wallet_attested_ownership_at": "2026-04-01T12:00:00Z"
  },
  "beneficiary": {
    "is_self": true,
    "wallet_type": "external"
  }
}

How is_self works:

Set is_self: true when that party is the same person or business as the Bridge customer on the resource. Bridge uses the verified customer name and address already on file instead of relying on name and address in the payload
Set is_self: false when that party differs from the Bridge customer. In this case, you need to provide the counterparty details including that party’s name and address

How wallet fields work:

wallet_type: "external" means the wallet is exchange-owned or a smart contract
wallet_type: "self_custodied" means the wallet is customer-owned
wallet_type: "hosted" means the wallet is developer-owned or developer-hosted

For self_custodied and hosted wallets, you must validate wallet ownership before sending Travel Rule data. wallet_attested_ownership_at is required and should reflect when that ownership check was completed.

Bridge supports two ways to send Travel Rule data. You need to choose the one that matches how stable the counterparty is.

1. Attach `travel_rule_data` on the reusable resource

Use the resource’s travel_rule_data field on create or update for:

transfers
virtual accounts
liquidation addresses

Use this option only when the same originator and beneficiary should apply to every future money movement through that resource. Good fits:

self-to-self routes
treasury flows
a fixed business counterparty
a route that is intentionally dedicated to one known sender or one known receiver

Do not use this option when:

multiple senders may fund the same virtual account
multiple counterparties may use the same liquidation address
the destination wallet changes from movement to movement
you only learn the real counterparty after an event or drain exists

2. Submit one-off data with `POST /v0/travel_rule_data/:id`

Use POST /v0/travel_rule_data/:id when the Travel Rule payload belongs to one specific money movement. This is the right choice when:

a reusable route can be used by different counterparties over time
you need to attach data to a specific transfer
you only know the sender after a virtual account event is created
you only know the relevant counterparty after a drain or bridge wallet event exists

Current supported one-off resource IDs include:

transfer IDs
virtual account event IDs
bridge wallet event IDs
drain IDs

The payload is the same travel_rule_data object shown above.

curl --location --request POST 'https://api.bridge.xyz/v0/travel_rule_data/<resource_id>' \
--header 'Api-Key: <API Key>' \
--header 'Content-Type: application/json' \
--data-raw '{
  "originator": {
    "name": "Jane Smith",
    "address": {
      "street_line_1": "123 Market St",
      "street_line_2": null,
      "city": "San Francisco",
      "state": "CA",
      "postal_code": "94105",
      "country": "USA"
    },
    "identifying_information": {
      "type": "national_id",
      "number": "1234567890",
      "issuing_country": "USA"
    },
    "birth_date": "2000-01-31",
    "place_of_birth": {
      "city": "San Francisco",
      "country": "USA"
    },
    "wallet_type": "self_custodied",
    "wallet_attested_ownership_at": "2026-04-01T12:00:00Z"
  },
  "beneficiary": {
    "is_self": true,
    "wallet_type": "external"
  }
}'

Decision rule:

if the parties are stable for every future use of the resource, attach travel_rule_data on create or update
if the parties are specific to one movement, use POST /v0/travel_rule_data/:id

Integration Checklist

Decide whether the movement is Travel Rule-eligible based on jurisdiction and amount.
Decide which side you need to populate: originator, beneficiary, or both. This is based on whether there is a crypto deposit and/or withdrawal involved and whether another crypto-asset service provider (“CASP”) already has the data.
Determine who is sending and receiving the funds. Use is_self: true if that party is the customer, and make sure the Bridge customer record already has the correct legal name and address. Otherwise use is_self: false and include the required identifying information.
Determine whether the wallet is external, self_custodied, or hosted. If the wallet is self_custodied or hosted, validate wallet ownership and send wallet_attested_ownership_at as the past timestamp when that check was completed.
Decide whether the counterparty is stable across all future uses of the resource. If the counterparty is stable, send travel_rule_data on the transfer, virtual account, or liquidation address create or update call. If the counterparty is movement-specific, wait until the relevant transfer, event, or drain exists and then call POST /v0/travel_rule_data/:id.

Introduction

Guides

Crypto Travel Rule Guide

Overview

Eligible Transactions

Amount requirements

Source and flow requirements

Understanding the travel rule data

1. Attach `travel_rule_data` on the reusable resource

2. Submit one-off data with `POST /v0/travel_rule_data/:id`

Integration Checklist

Introduction

Guides

Documentation Index

​Overview

​Eligible Transactions

​Amount requirements

​Source and flow requirements

​Understanding the travel rule data

​How to share travel rule data

​1. Attach travel_rule_data on the reusable resource

​2. Submit one-off data with POST /v0/travel_rule_data/:id

​Integration Checklist

​Related docs

Overview

Eligible Transactions

Amount requirements

Source and flow requirements

Understanding the travel rule data

How to share travel rule data

1. Attach `travel_rule_data` on the reusable resource

2. Submit one-off data with `POST /v0/travel_rule_data/:id`

Integration Checklist

Related docs