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.

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.

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):

{
  "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"
    }
  }
}

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.

Integration Checklist

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.
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.
Specify wallet custody type — Set hosted to yes for exchange-custodied wallets and provide VASP details. Set hosted to no for self-hosted wallets.
Handle compliance statuses — Implement handling for requires_action (pending verification) and compliance_hold (pending compliance review) in your payout workflow.

Overview

Core Concepts

Travel Rule

How Tazapay Complies

What the Travel Rule message includes

Providing Travel Rule Data via API

API field mapping

Example request

Integration Checklist

​How Tazapay Complies

​What the Travel Rule message includes

​Providing Travel Rule Data via API

​API field mapping

​Example request

​Integration Checklist

​Related

How Tazapay Complies

What the Travel Rule message includes

Providing Travel Rule Data via API

API field mapping

Example request

Integration Checklist

Related