Travel Rule Enforcement (PTC): API Guide for non-3P Customers

This guide is for non-3P Paxos Trust Company (PTC) customers who integrate with Paxos through the API. This could mean you use Paxos to hold and move crypto for your own company: the crypto belongs to you, and you manage your own withdrawal addresses. If you hold crypto on behalf of your own end users and will create multiple end-user / institutional identities on our platform, read the API Guide for 3P Customers instead.

Note that this guide applies only to accounts onboarded to the Paxos Trust Company (PTC) entity. If your account is with Paxos Global PTE (Singapore), see the PTE Travel Rule FAQ. If you are not sure which applies to your account, contact your account manager or raise a support request.

What is changing

Starting November 30, 2026, crypto transfers of $3,000 USD-equivalent or more to external destination addresses will require Travel Rule information. That information is collected once per destination address and stored on the saved address, not entered on each transaction. Once an address is saved with valid information, every later withdrawal or orchestration to that address inherits it automatically. Collect once, transact many times. Each destination address you save has its own Travel Rule information.

Why this is happening

Paxos Trust Company is a regulated financial institution and is required to comply with the U.S. Travel Rule (31 CFR 1010.410(f)). The Travel Rule requires financial institutions to collect and, where applicable, transmit identifying information about the sender and recipient of a transfer once it reaches a set value threshold. This is the same principle already applied to bank wires, extended to crypto transfers.

Affected endpoints

As a direct account holder you operate under a single identity, so you address destinations by (crypto_network, address) and do not need to send an identity_id.

Timeline

What you need to do

1. Review the Travel Rule developer guide and choose an integration pattern:

   • Pattern A, collect up front. Collect Travel Rule information when a destination address is saved. Recommended if most of your transfers are $3,000 or more.

   • Pattern B, try-catch on transaction. Save the address without information, handle the 403 at transfer time, collect the information, and retry. Suited to flows where most transfers are small.

   You can mix both (for example, Pattern A for business counterparties and Pattern B for personal addresses). See Collection patterns.

2. Add VASP directory lookup (GET /v2/travelrule/vasps) and beneficiary collection to your address-save flow, and submit travelrule_metadata via PUT /v2/transfer/crypto-destination-address. See the field reference for the full schema. A minimal travelrule_metadata object for a transfer to an individual at a VASP looks like this:

   {
     "custodian_type": "VASP",
     "vasp": { "id": "<id from GET /v2/travelrule/vasps>" },
     "beneficiary": {
       "person_details": {
         "first_name": "Jane",
         "last_name": "Doe",
         "physical_address": { "country": "USA" }
       }
     }
   }

   The example shows the fields required for a transfer to an individual at a VASP. One more field, transfer_purpose (the purpose of the transfer), is optional in the US, required in SG/EU, and recommended for partners with cross-jurisdictional flows.

3. Add Travel Rule information to your existing saved destination addresses before enforcement. Paxos does not backfill historical addresses on your behalf. Any address still missing information on November 30 is blocked for above-threshold transfers until you update it.

4. Stop sending the legacy top-level beneficiary field on POST /v2/transfer/crypto-withdrawals (this is the old per-transaction field, different from the beneficiary object inside travelrule_metadata), and stop using address_id / crypto_address_id on the orchestration endpoints. Requests that still include these are rejected at enforcement.

5. If you use orchestration rules, handle them carefully. A rule requires Travel Rule information on the referenced address regardless of the expected transfer size, because incoming deposit amounts are not predictable. A rule that fires against an address without valid information fails asynchronously: the orchestration lands in a failed state with a reason you can see in the Dashboard, via ListOrchestrations, or through webhooks. To recover, save the information on the address, then resend the transaction that triggers the orchestration rule.

6. Test your error handling before enforcement. Send the header X-Paxos-Test-Travel-Rule-Reject (any non-empty value) on Create Crypto Withdrawal and Create Orchestration calls in sandbox to force a 403 Travel Rule Information Required response, so you can validate your collection and retry flow. The response identifies the network and address so you can build the follow-up PUT call. Use this in sandbox only, and remove it for real transfers.

7. Complete sandbox testing and target your production rollout by end of September 2026.

Migration mapping

Special cases

• Sending to an account you own at another exchange or VASP: this is a self-transfer, so set beneficiary.self = true and skip the person and institution details. The destination is still a hosted venue, so keep custodian_type as VASP and include the receiving vasp so Paxos can identify the receiving institution.

• Unhosted (self-custodial) wallets such as MetaMask or Ledger: set custodian_type: PRIVATE and omit vasp. The information is still required to record the determination, but no Travel Rule message is transmitted because there is no receiving institution. This is also how you handle a self-transfer to your own unhosted wallet, and it is the only case where vasp is omitted.

• Receiving VASP not in the Paxos directory: provide vasp.custom_vasp_name and vasp.custom_vasp_website instead of vasp.id. Paxos Compliance handles the off-directory obligation, and the directory expands over time. Prefer vasp.id from the directory when available.

What is not affected

• Withdrawals under $3,000 USD-equivalent.

• First-party transfers between Paxos sub-accounts you own.

• Fiat (cash) payments and internal Paxos-to-Paxos transfers.

• Internal Paxos-to-Paxos transfers

• Regulated Customers using their own licensing

Getting help

Developer guide: docs.paxos.com/guides/travel-rule (see also field reference, collection patterns, and the rollout timeline). To schedule a migration review or ask a question, contact your account manager or raise a support request.