Travel Rule
The Travel Rule is part of our compliance implementation as a virtual asset service provider (VASP). The Travel Rule API ensures that identity details for both the sender and the recipient are included in payment and payout requests when a transaction meets regulatory thresholds. A regulation that requires financial institutions to collect and share personal information (like DoB) for certain transactions to combat money laundering and terrorist financing.
The Travel Rule API is designed to:
- Prevent fraud and unauthorized transactions
- Strengthen security through accurate identity verification
- Maintain compliance with financial regulations
- Protect both senders and recipients during cross-border exchanges
Travel Rule Integration Paths
The Travel Rule can be implemented without changing your existing endpoint structure. Compliance is achieved by including specific identity fields in your deposit and payout requests when applicable.
There are two ways to integrate the Travel Rule API:
New Integrations
New merchants can start with the latest Postman Collection, which includes required Travel Rule fields and example requests. This is the recommended path if you're building your integration from scratch.
Existing Integrations
If you're already integrated, there's no need to update your endpoints. Simply include the required Travel Rule fields related to end-user identity in your existing payment (deposit) and payout (withdrawal) requests. The payload structure remains the same just with the additional fields needed for compliance.
Integration Methods
The Travel Rule applies across all supported payment and payout integrations which includes:
- Hosted Payment Page (HPP) – Redirects the user to a hosted checkout page for deposits
- Embedded Payment Page (EPP) – Embeds the payment experience directly into your application
- Rapid Integration – Provides full control over the payment flow using direct API calls
- Invoice – Allows you to generate and send payment links to users
- RBL Integration – Used for partner-level integrations with banks or virtual asset service providers
- Payout APIs – Supports outbound transactions to users or third-party recipients
Note
The Travel Rule is enforced at the transaction level. If the regulation applies to a payment or payout, the required identity fields must be included in the request, regardless of the integration method used.
OUTBOUND Transactions (Withdrawals/Payouts)
Outbound transactions are payouts to an external user or beneficiary. Under the Travel Rule, identity information must be included for the recipient of the funds.
The following fields are required:
| Field Name | Format | Required |
|---|---|---|
firstName | Text (max 100 characters) | Yes |
lastName | Text (max 100 characters) | Yes |
These fields must be included in payout requests whenever a transaction meets regulatory thresholds. Additional information may be required depending on the jurisdiction or payout flow.
Inbound Transactions (Deposits / Payins)
Inbound transactions refer to crypto payments received from the end user. In this case, you must collect identity information for the originator of the funds (the person sending the transaction).
A standard set of identity fields is required for all inbound transactions. Additional fields may be required depending on the of identificationType provided either: nationalRegistration or placeOfBirth.
Common Fields (Required for all inbound transactions)
| Field Name | Format | Required |
|---|---|---|
firstName | Text (max 100 characters) | Yes |
lastName | Text (max 100 characters) | Yes |
streetName | Text (max 70 characters) | Yes |
townName | Text (max 35 characters) | Yes |
countryOfResidence | ISO-3166-1 alpha-2 code or "XX" | Yes |
buildingNumber | Text (max 16 characters) | Yes |
postcode | Text (max 16 characters) | Yes |
identificationType | nationalRegistration or placeOfBirth | Yes |
If identificationType = nationalRegistration
identificationType = nationalRegistrationYou must also include the following fields:
| Field Name | Format | Required |
|---|---|---|
documentCountryOfIssue | ISO-3166-1 alpha-2 code or "XX" | Yes |
documentNumber | Text (max 35 characters) | Yes |
documentType | One of the accepted values below | Yes |
customerId | Text (max 50 characters) | Yes |
Accepted values fordocumentType:
ARNU– Alien registration numberCCPT– Passport numberRAID– Registration authority identifierDRLC– Driver license numberFIIN– Foreign investment identity numberTXID– Tax identification numberSOCS– Social security numberIDCD– Identity card numberLEIX– Legal Entity Identifier
If identificationType = placeOfBirth
identificationType = placeOfBirthYou must instead include:
| Field Name | Format | Required |
|---|---|---|
dateOfBirth | YYYY-MM-DD | Yes |
placeOfBirth | Text (max 70 characters) | Yes |
Customer Identity Requirements
Natural Persons
If the customer paying in is an individual (natural person), you must collect:
- First name and last name
- Full residential address (Country, Postal Code, Town/City, Street Name, Building Number)
- Either:
- National ID number (e.g., passport) and internal customer ID
- Or date of birth and place of birth
Businesses (Legal Entities)
If the customer paying in is a business, you must collect:
- Registered or trading name
- Registered or official office address (Country, Postal Code, Town/City, Street Name, Building Number)
- Legal Entity Identifier (LEI) or company identifier
Best Practices
- Always validate user input before submission to ensure required fields are present
- Use standardized country codes (ISO-3166-1 alpha-2)
- Handle incomplete or missing Travel Rule data with proper error messaging
- Transmit identity data securely, in compliance with applicable data protection regulations
Support
For additional support or questions regarding Travel Rule implementation, please contact your Relationship Manager or the Orbital Integration team.
Updated 8 days ago