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

# FAQ

> Frequently asked questions about Bridge's Crypto Travel Rule requirements

## Scope & Applicability

<AccordionGroup>
  <Accordion title="When does the Travel Rule apply?">
    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.
  </Accordion>

  <Accordion title="What are the transaction thresholds?">
    | Jurisdiction | Threshold                                                                                                    |
    | ------------ | ------------------------------------------------------------------------------------------------------------ |
    | **US**       | > \$3,000 USD equivalent                                                                                     |
    | **EEA**      | All EEA-related transactions (no minimum); wallet attestation required for EUR or EURC transactions > €1,000 |
  </Accordion>

  <Accordion title="What makes a transaction EEA-related?">
    A transaction is EEA-related and subject to Travel Rule requirements with no minimum threshold if any of the following is true:

    * Bridge (or your entity) is an EEA-regulated CASP: 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): applies regardless of customer location
    * The end customer is EEA-based: applies regardless of currency

    The **€1,000 threshold applies only to wallet ownership attestation**, and only when the transaction has a EUR or EURC leg. All EEA-related transactions require Travel Rule data with no minimum threshold.
  </Accordion>

  <Accordion title="What location matters for EEA scope: a customer's operating address or legal address?">
    Generally, the residential or legal (registered) address should be used. For businesses, EEA scope is determined by the business's registered address, not the residential addresses of individual UBOs or associated persons.
  </Accordion>

  <Accordion title="Does the Travel Rule apply when funds stay entirely within Bridge's ecosystem?">
    **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**
  </Accordion>

  <Accordion title="Can I submit Travel Rule data for ALL money movements to avoid building a decision engine on my end?">
    **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.
  </Accordion>
</AccordionGroup>

## Originator & Beneficiary: Identifying the Parties

<AccordionGroup>
  <Accordion title="How does Bridge define 'originator'?">
    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.
  </Accordion>

  <Accordion title="What if a third party (not my customer) sends funds to my customer's Virtual Account or Liquidation Address? Who is the originator?">
    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.
  </Accordion>

  <Accordion title="For a third-party onramp (e.g., a friend sends funds to my customer's Virtual Account), who is the originator and who is the beneficiary?">
    * **Originator:** The third-party sender (their third-party information, collected from your customer)
    * **Beneficiary:** Your customer (the receiving party); use `is_self: true`
  </Accordion>

  <Accordion title="What if we genuinely cannot identify the originator? (e.g., open liquidation addresses)">
    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.
  </Accordion>

  <Accordion title="Who is the beneficiary in an offramp flow where funds go to an external bank account?">
    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.
  </Accordion>

  <Accordion title="For a crypto payout to a third party who is not my customer, who is the originator and 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.
  </Accordion>
</AccordionGroup>

## Required Fields

<AccordionGroup>
  <Accordion title="What originator fields are required?">
    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)
  </Accordion>

  <Accordion title="What beneficiary fields are required?">
    For **individual beneficiaries:**

    * `name`
    * `address`
    * `wallet_type` and `wallet_attested_ownership_at` (if applicable)

    For **business beneficiaries:**

    * `name`
    * `address`
    * `legal_entity_identifier`

    <Note>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.</Note>
  </Accordion>

  <Accordion title="If is_self: true, do I still need to provide all beneficiary fields?">
    **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`).
  </Accordion>

  <Accordion title="Does Bridge auto-pull the customer's KYC data (including identifying_information) for Travel Rule purposes?">
    **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.
  </Accordion>

  <Accordion title="For businesses, what counts as a 'legal entity identifier'?">
    Any official government-issued business identifier, such as:

    * VAT registration number
    * EIN (US Employer Identification Number)
    * Company registration number
    * LEI (Legal Entity Identifier)
  </Accordion>
</AccordionGroup>

## wallet\_type, Attestation & Bridge Wallets

<AccordionGroup>
  <Accordion title="What are the valid values for wallet_type and what do they mean?">
    | Value            | Meaning                                                                          |
    | ---------------- | -------------------------------------------------------------------------------- |
    | `hosted`         | The wallet is custodied by you (the developer) on behalf of the customer         |
    | `external`       | The wallet is custodied by an external exchange or CASP (e.g., Coinbase, Kraken) |
    | `self_custodied` | The customer personally controls the wallet (e.g., MetaMask, Ledger)             |

    `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.
  </Accordion>

  <Accordion title="Do Bridge-hosted wallets require wallet ownership attestation?">
    **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.
  </Accordion>

  <Accordion title="When is wallet ownership attestation (wallet_attested_ownership_at) required?">
    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
  </Accordion>

  <Accordion title="When a third party (non-customer) sends crypto to my customer's Bridge wallet, is attestation required from that third party?">
    **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.
  </Accordion>

  <Accordion title="If the originator is a third party (not my customer), how do I determine their wallet_type? Can I ask them via a dropdown?">
    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.
  </Accordion>

  <Accordion title="What methods are acceptable for wallet ownership attestation? Is a signature challenge required?">
    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.
  </Accordion>

  <Accordion title="What do wallet_type and wallet_attested_ownership_at mean in a fiat context (e.g., an offramp to a bank account)?">
    **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.
  </Accordion>

  <Accordion title="How do I know if the other VASP (e.g., Coinbase) will submit Travel Rule data to Bridge?">
    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.
  </Accordion>
</AccordionGroup>

## Flow-Specific Scenarios

<AccordionGroup>
  <Accordion title="What Travel Rule data is required for each common flow?">
    | Flow                                                                     | TR Required?           | Submit What?                                                                        | Notes                                                                      |
    | ------------------------------------------------------------------------ | ---------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
    | **Fiat into Bridge custodial wallet** (onramp, no outbound disbursement) | No                     | N/A                                                                                 | No on-chain transfer to external VASP                                      |
    | **Fiat into Bridge custodial wallet, then disbursement**                 | Yes (disbursement leg) | Originator + beneficiary                                                            | TR applies to the disbursement on-chain leg                                |
    | **External/self-hosted wallet into Bridge wallet** (crypto deposit)      | Yes                    | Originator (your customer or an identifiable third party) + beneficiary (`is_self`) | Wallet type of depositing wallet; attestation if self-hosted, EU, and >€1K |
    | **External VASP wallet (e.g., Coinbase) into Bridge wallet**             | Yes                    | Beneficiary (`is_self` or beneficiary details)                                      | Coinbase expected to send TR data; also submit beneficiary info            |
    | **Bridge wallet to external/self-hosted wallet** (crypto payout)         | Yes                    | Originator (your customer) + beneficiary info                                       | No attestation needed for third-party recipient                            |
    | **Bridge wallet to fiat bank account** (offramp)                         | No on-chain TR         | Beneficiary name if different from customer                                         | No crypto wallet TR fields applicable                                      |
    | **All-fiat flow** (no on-chain leg)                                      | No                     | N/A                                                                                 | TR only applies to on-chain legs                                           |
    | **Bridge wallet to Bridge wallet** (internal)                            | No                     | N/A                                                                                 | Stays within Bridge ecosystem                                              |
    | **Bridge wallet to external PSP** (for downstream fiat payouts)          | Yes                    | Originator + beneficiary (`is_self` if applicable)                                  | Set `wallet_type: external`; `is_self` if user is the ultimate beneficiary |
  </Accordion>

  <Accordion title="For incoming payments I did not initiate (VA deposits, Liquidation Address pushes), when do I submit Travel Rule data?">
    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
  </Accordion>

  <Accordion title="For fiat offramp flows, are all five beneficiary fields (is_self, name, address, wallet_type, wallet_attested_ownership_at) required?">
    **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
  </Accordion>
</AccordionGroup>

## Timing & API Integration

<AccordionGroup>
  <Accordion title="Does Travel Rule data need to accompany the transfer in real time?">
    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.
  </Accordion>

  <Accordion title="How do I attach Travel Rule data to a specific transaction after the fact?">
    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](/api-reference/travel-rule/submit-travel-rule-data).
  </Accordion>

  <Accordion title="Can I submit a single reusable Travel Rule resource for repeated self-to-self transfers?">
    **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.
  </Accordion>
</AccordionGroup>

## Travel Rule Compliance Expectations and Enforcement

<AccordionGroup>
  <Accordion title="What happens if Travel Rule data is not submitted?">
    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.
  </Accordion>

  <Accordion title="Does Bridge reach out to my end customers directly, or to us?">
    **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.
  </Accordion>

  <Accordion title="Will Bridge block transactions if Travel Rule data is missing?">
    **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.
  </Accordion>
</AccordionGroup>