> ## Documentation Index > Fetch the complete documentation index at: https://apidocs.bridge.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Crypto Travel Rule Guide # 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)](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/section-1010.410) and [FinCEN virtual currency guidance](https://www.fincen.gov/system/files/2019-05/FinCEN%20Guidance%20CVC%20FINAL%20508.pdf) * E.U.: [Regulation (EU) 2023/1113](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1113) 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. Note that even if you are not yourself a regulated entity, Bridge is a regulated EU entity and MSB and is required to collect originator and beneficiary information for qualifying transactions. This means you will need to pass this data to Bridge as a condition of processing these flows. A transaction is **EEA-related (no threshold)** if any of the following is true: * You are an EEA-regulated CASP. This applies to all your transactions regardless of customer location or currency * The transaction has a EUR or EURC leg (e.g. EUR pay-in to a vIBAN, EUR payout, EURC conversion, etc.) regardless of the customer's location * The end customer is EEA-based, regardless of currency If any part of the transaction is serviced through Bridge EEA-regulated infrastructure (including SEPA or EURC services), EU Travel Rule requirements apply regardless of end-user residency. A transaction is **US-related (above USD 3,000)** if any of the following is true: * You are a US-regulated MSB/VASP. This applies to all your transactions above \$3,000 regardless of customer location or currency * The transaction has a USD or USDC leg, regardless of customer location * The end customer is US-based, regardless of currency | Developer type | Customer type | Flow | Travel Rule data required by Bridge? | | --------------------- | ------------------------ | --------------- | ------------------------------------ | | EEA-regulated CASP | Any | Any | Yes, all transactions, no threshold | | US-regulated MSB/VASP | Any | Any | Yes, above \$3,000 | | Unregulated | EEA customer | Any currency | Yes, no threshold | | Unregulated | US customer | Any currency | Yes, above \$3,000 | | Unregulated | Non-EEA | EUR or EURC leg | Yes, no threshold | | Unregulated | Non-EEA, non-US customer | USD or USDC leg | Yes, above \$3,000 | | Unregulated | Non-EEA, non-US customer | No USD/EUR leg | No | 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”). ```json theme={null} { "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. # How to share travel rule data 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. ```bash theme={null} curl --location --request POST 'https://api.bridge.xyz/v0/travel_rule_data/' \ --header '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 1. Decide whether the movement is Travel Rule-eligible based on jurisdiction and amount. 2. 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. 3. 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. 4. 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. 5. 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`. # Related docs * [Transfers](/platform/orchestration/transfers/transfer) * [Source and destination updates](/platform/orchestration/transfers/transfer-updates) * [Virtual accounts](/platform/orchestration/virtual_accounts/virtual-account) * [Virtual account events](/platform/orchestration/virtual_accounts/virtual-account-events) * [Liquidation address](/platform/orchestration/liquidation_address/liquidation_address) * [Drains](/platform/orchestration/liquidation_address/drains)