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

# Travel Rule

The Travel Rule requires virtual asset service providers to collect and share identifying information about the sender and recipient of a virtual asset transfer. While the Financial Action Task Force (FATF) sets the international standard, for Tazapay the Travel Rule is a binding obligation under Canada's AML framework, enforced by FINTRAC.

Tazapay is a registered Money Services Business (MSB) with FINTRAC (Canada) and is fully Travel Rule compliant. For virtual assets payouts processed through Tazapay, we collect the required originator and beneficiary information, screen wallets and transactions for risk, and transmit a Travel Rule message to the counterparty provider where applicable.

In Canada, the Travel Rule applies to virtual currency transfers of **CAD 1,000 or more**. Tazapay collects beneficiary information for all virtual asset payouts as a best practice, regardless of amount.

<Info>
  Even if your business is not itself a regulated entity, Tazapay must collect originator and beneficiary information for qualifying transactions. You will need to pass this data to Tazapay as a condition of processing virtual asset payouts.
</Info>

# How Tazapay Complies

For every outbound virtual asset payout, Tazapay performs the following:

**Wallet screening** — Each wallet address is screened using blockchain analytics for sanctions exposure, risk scoring, transaction history analysis, and entity clustering. Wallets flagged as high-risk may require further checks before processing.

**Travel Rule message** — For transfers to hosted (exchange-custodied) wallets, Tazapay publishes a Travel Rule message containing originator details, beneficiary details, and transaction information. The message is transmitted to the recipient's provider through a secure, encrypted channel.

**Originator data** is sourced automatically from your verified merchant account (KYB records). For on-behalf-of payouts, originator data is sourced from the entity information associated with the payout. You do not need to pass originator details separately.

**Beneficiary data** is sourced from the information you provide when creating a beneficiary through the API.

## What the Travel Rule message includes

| Data        | What is shared                                                                               | Source                                                            |
| :---------- | :------------------------------------------------------------------------------------------- | :---------------------------------------------------------------- |
| Originator  | Name, address, account identifier                                                            | Merchant KYB records or entity information (on-behalf-of payouts) |
| Beneficiary | Name, address, wallet address, date of birth (individuals), registration number (businesses) | Create Beneficiary API fields                                     |
| Transaction | Amount, blockchain network, currency, transaction hash, timestamp                            | From payout request and on-chain settlement                       |

# Providing Travel Rule Data via API

When you create a beneficiary with `destination_details.type: "wallet"`, the fields you provide are used both for compliance screening and for constructing the Travel Rule message.

## API field mapping

| Travel Rule Element | API Field                                                  | Required             |
| :------------------ | :--------------------------------------------------------- | :------------------- |
| Beneficiary name    | `name`                                                     | Yes                  |
| Beneficiary type    | `type` (`individual` or `business`)                        | Yes                  |
| Address             | `address.line1`, `city`, `state`, `country`, `postal_code` | Yes                  |
| Date of birth       | `date_of_birth` (DD-MM-YYYY)                               | Yes, for individuals |
| Registration number | `registration_number`                                      | Yes, for businesses  |
| National ID         | `national_identification_number`                           | Recommended          |
| Nationality         | `nationality` (ISO 3166-1 alpha-2)                         | Recommended          |
| Party relationship  | `party_classification` (`self` or `third_party`)           | Yes                  |
| Wallet address      | `destination_details.wallet.deposit_address`               | Yes                  |
| Blockchain network  | `destination_details.wallet.type`                          | Yes                  |
| Cryptocurrency      | `destination_details.wallet.currency`                      | Yes                  |
| Wallet custody      | `destination_details.wallet.hosted` (`yes` or `no`)        | Yes                  |
| VASP name           | `destination_details.wallet.vasp_name`                     | Yes, if hosted       |
| VASP website        | `destination_details.wallet.vasp_website`                  | Yes, if hosted       |

## Example request

**Third-party individual, hosted USDC wallet (Polygon):**

```json theme={null}
{
  "name": "Jane Doe",
  "type": "individual",
  "email": "jane.doe@example.com",
  "date_of_birth": "15-03-1990",
  "nationality": "CA",
  "national_identification_number": "AB1234567",
  "party_classification": "third_party",
  "address": {
    "line1": "100 King Street West",
    "line2": "Suite 3400",
    "city": "Toronto",
    "state": "ON",
    "country": "CA",
    "postal_code": "M5X 1A1"
  },
  "destination_details": {
    "type": "wallet",
    "wallet": {
      "deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
      "type": "polygon",
      "currency": "USDC",
      "hosted": "yes",
      "vasp_name": "Binance",
      "vasp_website": "https://www.binance.com"
    }
  }
}
```

<Note>
  For self-hosted wallets with `party_classification: "self"`, Tazapay will initiate a cryptographic signature verification flow after the beneficiary is created. The beneficiary will remain in `requires_action` status until ownership is verified.
</Note>

# Integration Checklist

1. **Collect full beneficiary details** — Ensure your application collects all mandatory fields for wallet beneficiaries: `name`, `type`, `address`, `date_of_birth` or `registration_number`, `party_classification`, and wallet destination details including `hosted`, `vasp_name`, and `vasp_website` where applicable.
2. **Classify the party relationship** — Determine whether each payout is `self` (the merchant's own wallet) or `third_party` (a different recipient). This drives the verification and approval flow.
3. **Specify wallet custody type** — Set `hosted` to `yes` for exchange-custodied wallets and provide VASP details. Set `hosted` to `no` for self-hosted wallets.
4. **Handle compliance statuses** — Implement handling for `requires_action` (pending verification) and `compliance_hold` (pending compliance review) in your payout workflow.

### Related

* [Create Beneficiary API Reference](/api-reference/tazapay-api/create-beneficiary)
* [FATF Recommendation 16 — Wire Transfers](https://www.fatf-gafi.org/en/topics/fatf-recommendations.html)
* [FINTRAC — Travel Rule for Electronic Funds and Virtual Currency Transfers](https://fintrac-canafe.canada.ca/guidance-directives/transaction-operation/travel-eng)
* [Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA)](https://laws-lois.justice.gc.ca/eng/acts/p-24.501/)
* [Proceeds of Crime (Money Laundering) and Terrorist Financing Regulations (PCMLTFR)](https://laws-lois.justice.gc.ca/eng/regulations/SOR-2002-184/index.html)