Travel Rule

FATF Recommendation 16 requires Virtual Asset Service Providers to exchange originator and beneficiary information on transfers above a threshold. PAX captures the required fields at withdrawal time and stores them alongside the payout batch. This page documents the schema so counterparty VASPs know what to expect.

When Travel Rule kicks in

Both the FATF baseline and most implementing jurisdictions (Singapore MAS, EU TFR, US FinCEN proposed) set the threshold at USD 1,000-equivalent. PAX applies the rule at the Worker layer for every payout batch where total_amount_usd ≥ 1000.

Below the threshold, no counterparty information is requested; the payout goes through with only the standard OFAC + 24-hour whitelist checks.

Fields captured on the builder side

At withdrawal time, the Builder Portal presents a Beneficiary Details form the first time a wallet is used for a payout ≥ $1,000. The field layout maps to IVMS 101:

How PAX stores it

The full beneficiary object is stored on the payout_batches row under metadata.travel_rule as a JSON payload. Access is restricted to admin operators with the compliance:read scope. Retention: 7 years per FATF R.11 recordkeeping.

{
  "payout_batch_id": "pay_abc123",
  "metadata": {
    "travel_rule": {
      "collected_at_ms": 1789900000000,
      "collected_via": "builder_portal_form",
      "collector_ip_country": "SG",
      "beneficiary": {
        "entity_type": "natural_person",
        "name": {"primary": "Builder Sanchez", "secondary": null},
        "address": {"country": "SG", "street": "…", "city": "Singapore", "postcode": "…"},
        "national_id": {"type": "passport", "number": "…", "issuer_country": "PH"},
        "dob": "1990-01-15"
      },
      "beneficiary_vasp": null,
      "amount_usd": "1500.00",
      "currency": "USDT",
      "network": "polygon"
    }
  }
}

Counterparty VASP integration

PAX is progressively integrating with Travel Rule messaging networks. Current status:

• Sumsub Travel Rule — evaluation in progress
• Notabene — evaluation in progress
• TRP (Travel Rule Protocol) via OpenVASP — planned Q1 2027

Until direct network integration lands, PAX operates in collect-and-hold mode: we capture the required fields from our builder and store them; on request from an audited counterparty VASP with a valid Travel Rule inquiry we release the record per FATF R.16.

Worked example

Builder bld_abcd1234 withdraws $1,500 USDT on Polygon:

1. Portal calls POST /v1/builders/me/withdraw with the target wallet.
2. Worker sees amount_usd ≥ 1000, checks metadata.travel_rule for that wallet.
3. First time on this wallet: Portal is instructed to render the Beneficiary Details form (via error code TRAVEL_RULE_INFO_REQUIRED).
4. Builder submits the form. Portal reposts POST /v1/builders/me/withdraw with the beneficiary object.
5. Worker validates required fields per beneficiary type, writes metadata.travel_rule, cachechecks OFAC + Chainalysis (once wired), and enqueues the payout batch.
6. Subsequent payouts to the same wallet skip the form until material change (annual refresh or amount jump ≥ 3×).

Where this applies today

PAX runs the Travel Rule flow globally for consistency, regardless of the builder's declared country. If your jurisdiction has a stricter threshold (e.g., Switzerland CHF 0) we honour that on request via /security contact.