Skip to main content

​
Scope & Applicability

The Travel Rule applies to on-chain crypto transactions where funds are sent on-chain to or from a wallet outside of Bridge’s ecosystem. It does not apply to funds flows that stay within Bridge custody or fiat flows with no on-chain leg outside of Bridge.As a general rule, if the transaction involves moving crypto on-chain outside of Bridge’s custody, the Travel Rule applies.
No. If funds never leave Bridge’s custody and no on-chain transfer is made to an external VASP or self-hosted wallet, there is no Travel Rule obligation. For example:
  • Fiat into a Bridge custodial wallet (onramp only, no outbound disbursement): No Travel Rule data required
  • Bridge wallet to Bridge wallet (internal transfer): No Travel Rule data required
  • Bridge wallet to fiat bank account (no on-chain leg): No Travel Rule data required
Yes. You are permitted to attach travel_rule_data to any money movement even if it is not strictly required for that specific flow. This is a perfectly valid approach.

​
Originator & Beneficiary: Identifying the Parties

The originator is whoever is actually sending the funds. This may be your customer or a third party. The key distinction is whether the transfer is self-to-self or involves an identifiable third party:
  • Self-to-self transfer (your customer sends to themselves): Set originator.is_self: true. Bridge will automatically pull the originator’s information from the customer’s profile.
  • Identifiable third-party originator (a third party sends funds and their identity is known or obtainable): The third party is the originator. Where you are able to identify them (for example, on outbound transactions you initiate or inbound transfers where your customer knows the sender), you are expected to collect and submit their name and address. Bridge will work through its own resolution process internally and will reach out to you directly if additional information is needed.
  • Unidentifiable originator (funds arrive from an unknown source, e.g., open liquidation addresses): This is a distinct scenario with its own obligations and resolution framework. See the question below on unidentifiable originators.
A documented, good-faith effort to collect originator data wherever possible is required. Where an originator cannot be identified, the obligation does not disappear.is_self: true means the person sending the funds is your customer sending to themselves. It is not a substitute for collecting third-party originator data when that data is obtainable.
The third party is the originator. Where their identity is known or can be obtained (for instance, your customer knows the sender), you are expected to collect and submit their information. You do not need wallet ownership attestation for the third party.
  • A friend sends fiat to your customer’s Virtual US Account and the customer can identify them: Originator = the friend (no attestation required)
  • A business partner deposits funds to your customer’s Liquidation Address and the customer confirms who sent it: Originator = the business partner (no attestation required)
Where the originator cannot be identified even after reasonable effort (such as with open liquidation addresses that accept funds from unknown senders), different obligations apply. See the question below on unidentifiable originators.
  • Originator: The third-party sender (their third-party information, collected from your customer)
  • Beneficiary: Your customer (the receiving party); use is_self: true
Some product models involve liquidation addresses that accept inbound on-chain transfers from any sender, including parties unknown to both the developer and their customer. This is a recognized scenario with defined developer obligations.1. Submit what you have.You are required to submit originator data you can reasonably obtain. If your customer cannot identify the sender, you are not expected to produce information you do not have. If partial information is available (e.g., the customer knows a name but not an address), submit what you can. Bridge will work through its own resolution process on the back end and will reach out to you directly if additional information is needed.2. Document your product model with Bridge.If your use case structurally involves inbound transfers from unknown third parties (e.g., you operate open liquidation addresses), this should be communicated to Bridge. This documents that the scenario is known, intentional, and that your obligations as a partner are understood, including downstream AML responsibilities on your end-customer accounts.3. Bridge will manage unresolvable cases on a risk basis.For transfers above €1,000 where the originator cannot be identified, as well as any other transfers with missing required Travel Rule data, Bridge will take a risk-based approach to determine how those transfers are handled. Bridge will reach out to you directly if action or additional information is needed.
The beneficiary is the ultimate bank account holder, not Bridge. If the bank account holder is the same person as your customer, use is_self: true. If it is a different person, provide the bank account holder’s details as the beneficiary.
  • Originator: Your customer (who initiated the transfer). Set is_self: true on the originator and Bridge will pull their info from the customer profile.
  • Beneficiary: The third-party recipient (name, address, and legal_entity_identifier if a business)
You collect the beneficiary’s data from your customer. You do not need wallet ownership attestation from the third-party recipient.

​
Required Fields

This depends on whether the originator is your customer (self-to-self) or a third party.Self-to-self (originator.is_self: true, where your customer is the sender):
  • Set is_self: true. Bridge automatically pulls all originator data (name, address, identifying_information) from the customer’s on-file profile.
  • You only need to provide the beneficiary if they are different from the customer.
Third-party originator (a third party is the sender):For individual third-party originators:
  • name
  • address
  • wallet_type (if applicable; no attestation required)
  • identifying_information (ID number, DoB, etc.) when available
For business third-party originators:
  • name
  • address
  • legal_entity_identifier (e.g., VAT number or other official business identifier)
For individual beneficiaries:
  • name
  • address
  • wallet_type and wallet_attested_ownership_at (if applicable)
For business beneficiaries:
  • name
  • address
  • legal_entity_identifier
Date of birth and place of birth are not required at the beneficiary level. They are only needed for the originator when no physical ID is available.
No. If you set is_self: true for the beneficiary (indicating the beneficiary is the same person as your customer), you do not need to provide the other beneficiary fields (name, address, wallet_type, wallet_attested_ownership_at).
Yes, for self-to-self transfers. When originator.is_self: true, Bridge will automatically pull the originator’s full profile (including name, address, and identifying_information) from the customer’s profile, as long as you provide the beneficiary information (if the beneficiary is different from the customer). You do not need to re-submit data that was already collected at KYC/KYB onboarding.For third-party originators, Bridge has no profile on file for the third party. You are expected to take reasonable measures to obtain and submit their name and address. identifying_information (ID number, DoB, etc.) should be submitted if available.

​
wallet_type, Attestation & Bridge Wallets

wallet_type represents the custody arrangement, not the technology. It applies to the depositing wallet for inbound flows and the receiving wallet for outbound flows.
No. Bridge-custodied wallets do not require attestation. You only need to note the wallet type as hosted (if you custody it) or you can omit attestation fields entirely for Bridge wallets.
Attestation is required when:
  • The sending wallet is self-hosted (self_custodied) AND
  • The transaction is through Bridge’s EU entity (EUR transaction) AND
  • The transaction exceeds €1,000 in a single transaction or in several transactions which appear to be linked.
For US flows, wallet attestation is not required when sending to or receiving from a self-hosted wallet.Attestation is never required for:
  • Bridge-custodied wallets
  • Third-party originators or beneficiaries (non-customers); collect their name and address, but no wallet attestation
  • Fiat-only flows
No. Wallet ownership attestation is not required for third-party originators or recipients. When a third party is the originator, you collect their name and address from your customer, but no wallet attestation is needed. Attestation only applies to wallets owned by your own customers.
Where your flow allows for it, a dropdown asking the customer to indicate the wallet type is sufficient. For example: “Was the sending wallet self-hosted, at an exchange, or hosted by a provider?” The customer (your platform’s account holder) can provide this information. You do not need to independently verify it; the attestation obligation is out of scope for third-party originators. Where your flow does not allow you to collect this information, submit what you have and Bridge will work with you on the gaps.
A signature challenge is the most common method, but Bridge does not require a specific method. Acceptable approaches include:
  • Cryptographic signature challenge (e.g., via WalletConnect, MetaMask personal signature)
  • Micro-deposit / satoshi test (send a small amount and verify the customer received it)
  • Third-party vendor tools that manage wallet verification
Bridge will QA attestations on a sample basis to ensure they are captured and recorded accurately. Reach out if you would like vendor recommendations.
Not applicable. These fields are specific to crypto wallets. For transactions where the destination or source is a fiat bank account, wallet_type and wallet_attested_ownership_at should be omitted.
If the sending wallet is external (custodied by another CASP like Coinbase), you can declare wallet_type: external and that CASP is expected to transmit Travel Rule data directly to Bridge through standard VASP-to-VASP protocols. In practice, it is still best to submit the beneficiary information on your end regardless, to ensure Bridge has what it needs.

​
Flow-Specific Scenarios

For these flows, you may not know a payment is happening in advance. In that case:
  • Funds will not be held or frozen while Travel Rule data is pending
  • You can submit the Travel Rule data after the deposit, referencing the event ID from the webhook
  • Bridge will reach out if data is missing and is not provided in a timely manner
No. For offramps converting crypto to fiat:
  • If is_self: true, no other fields are required
  • If the beneficiary is a third party, provide name and address; wallet_type and wallet_attested_ownership_at are not applicable to fiat destinations

​
Timing & API Integration

The intent of the Travel Rule is for required data to travel with the payment. Depending on your flow, there are two ways to achieve this:
  1. Inline at creation: Include travel_rule_data when creating a transfer, Virtual Account, or Liquidation Address
  2. One-off afterward: Submit Travel Rule data separately via a POST to /v0/travel_rule_data/{id}, referencing the relevant resource ID (transfer ID, virtual account event ID, drain ID, etc.)
The second option is especially useful for inbound flows (VA deposits, Liquidation Address pushes) where you cannot predict the payment in advance.
Use the one-off POST endpoint: POST /v0/travel_rule_data/{id} where {id} is the resource ID of the relevant money movement (e.g., the transfer ID, virtual account event ID). See the API reference.
Yes. For self-to-self transfers (where the originator and beneficiary are the same customer), you can use a reusable resource instead of submitting TR data on every individual transfer.

​
Travel Rule Compliance Expectations and Enforcement

Bridge will not hold or freeze funds due to missing Travel Rule data at the time of a transfer. However:
  1. Bridge will reach out to you (the developer/partner) directly to collect the missing data
  2. If data is not provided after outreach, Bridge will apply enhanced controls and may reject the transfer in case of increased risk.
Bridge takes a risk-based approach with the goal of having complete Travel Rule data for all in-scope transactions.
Bridge will always reach out to you (the developer/partner), not to your end customers. If Travel Rule data is missing, Bridge will contact you to resolve it.
No. Bridge does not block or hold funds for lack of Travel Rule data at the time of the transaction. Funds will be immediately available in the user’s wallet as normal. Controls are only imposed if data remains missing after Bridge reaches out.