Travel Rule

The Travel Rule requires certain information about originators and beneficiaries to accompany qualifying transfers, including crypto-asset transfers.

CashXChain role

For a bank payout, the payee's details are registered with our banking partner when you create the beneficiary, and the partner carries them with each payment. CashXChain attaches no separate Travel Rule data.

For a send from a digital-asset account (sandbox), the request itself carries who receives the money, and CashXChain checks it before anything is sent and passes it to our crypto-asset service provider with the transfer. The provider refuses no transfer for most missing data, so CashXChain does.

Regulated partners are responsible for collecting, verifying, transmitting, and enforcing Travel Rule obligations where they provide the regulated service.

Digital-asset sends

Send	Travel Rule data	Where
On chain, to a third party	beneficiary: type (individual or business), name, address with street_line_1, city and country (postal_code optional), wallet_type (external or self_custodied), and for a business a business_identifier	destination.beneficiary
On chain, to your own wallet elsewhere	{"is_self": true, "wallet_type": …}	destination.beneficiary
To an IBAN or a bank account, a third party	owner: the holder's name, address with street_line_1, city and country, and for a business a business_identifier. A US account needs the whole address, postal_code and state included	destination.owner
To an IBAN or a bank account held in your own name	owner with address.country; no business identifier for your own business	destination.owner
By @handle, to another CashXChain business	None: the transfer moves between two wallets inside the provider	—
Between your own accounts (swap, send-back, convert)	None: a payment to self	—

A business identifier is {"type": "lei" | "vat" | "company_registration", "value", "issuing_country"} — an LEI, a VAT number or a commercial-register number; issuing_country is required for the last two.

Anything missing is refused before your approval is spent: 422 travel_rule_incomplete, with every missing field listed in details.fields. A malformed field is 400 bad_request. A trusted beneficiary is approved with the same data and checked by the same rules, so an API key's send to it carries what the person approved.

Sends to your own self-custodied wallets are limited to 1,000 of each asset over 30 days until the provider's attestation of wallet ownership is offered (422 wallet_attestation_required).

Typical data fields

Depending on corridor and product, required data may include:

• Originator name.
• Originator account or customer identifier.
• Originator address or country.
• Beneficiary name.
• Beneficiary account or wallet identifier.
• Beneficiary address or country.
• Transaction amount and asset.
• Purpose or reference.

When additional information is required

A beneficiary missing a field its corridor requires is refused when you register it — 400 bad_request, naming the field. The partner can still refuse a payout. Corridor requirements are published by GET /v1/banking/corridors, so they can be collected up front.

Developer guidance

• Use structured fields instead of free-form metadata.
• Keep beneficiary records current.
• Provide purpose of payment where required.
• Ask the corridor for its required fields before you build the beneficiary form.
• Collect a third party's street and city — and a business's identifier — before a digital-asset send, not after a refusal.
• Do not submit placeholder information in production.