> For the complete documentation index, see [llms.txt](https://docs.ospree.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ospree.io/developers/travel-rule/overview.md). # Overview Ospree’s Travel Rule Module is a standalone solution that helps crypto businesses automate the review and approval of incoming and outgoing transfers. It combines real-time checks—including blockchain analytics, jurisdictional thresholds, wallet-type identification, and Travel Rule data validation, to help ensure that each transaction meets applicable regulatory requirements before processing. Through its [**interoperability**](/developers/travel-rule/interoperability.md) capabilities, the module supports the secure exchange of Travel Rule information across different platforms and protocols. It can operate independently or integrate with other Ospree tools and external solutions, enabling businesses to strengthen compliance without disrupting their existing systems. ### **Account Categories and Type** When initiating a Travel Rule transfer, the originator and beneficiary roles must be clearly defined to meet regulatory requirements. These roles ensure that all necessary data is collected, structured, and transmitted in accordance with compliance standards. In Ospree, each role can be associated with one of two account categories * Customer: An individual or entity that has been fully onboarded by the VASP. * Non-Customer: An external individual or entity who is not onboarded but is participating in the transaction. Accounts are also classified by account type * Individual: A natural person acting on their own behalf. * Entity: A legal organization such as a business, institution, or government body. This flexible structure enables the platform to support a wide range of transfer scenarios through a single API endpoint. Travel Rule transfers in Ospree can involve any combination of account category and account type: ```json "originator_account": { "account_type": "individual", // "individual" or "entity" "account_category": "customer", // "customer" or "non-customer" // ... ``` ```json "beneficiary_account": { "account_type": "individual", // "individual" or "entity" "account_category": "non-customer", // "customer" or "non-customer" // ... ``` ### Using Unique Account IDs for Originator and Beneficiary When initiating a Travel Rule transfer, information about both the originator and beneficiary is required. This data can either be included directly in the transfer request or referenced using a unique account ID already stored in the system. The fields `originator_account_reference_id` and `beneficiary_account_reference_id` allow you to link to pre-registered accounts, simplifying repeat transactions and ensuring consistency. ```json '{ // ... "originator_account_reference_id": "random-ref-id-101", "beneficiary_account_reference_id": "random-ref-id-102", // ... ``` ### Direct Input for Originator and Beneficiary Direct Input refers to the method of providing all required originator and beneficiary information directly within the Travel Rule transfer request. This includes personal or entity details such as names, addresses, and identification data. While this approach allows for flexibility, especially when dealing with one-time or ad hoc transfers, it can lead to data duplication and a higher risk of errors or inconsistencies. It’s best suited for scenarios where the account information is not expected to be reused or when the account has not yet been registered in the system. Depending on the sending and receiving jurisdictions, the information required in a Travel Rule transfer may vary to meet local regulatory requirements. Additionally, the fields associated with individual accounts differ from those used for entity accounts. For example, fields like `name_legal` and `name_business` are specific to entities, while fields such as `name_first` and `name_last` apply to individuals. ```json // ... "individual": { "individual_name": { "name_type": "LEGL", "name_first": "Mark", "name_last": "Rover" } } }, // ... ``` ```json // ... "entity": { "entity_name": { "name_type": "LEGL", "name_legal": "Digital Capital", "name_business": "Digital Capital Pte. Ltd." } } }, // ... ``` ### Self Hosted Wallets A self-hosted wallet (also known as a non-custodial wallet) is a cryptocurrency wallet where the user controls the private keys. Examples include MetaMask, Ledger, or mobile wallets like Trust Wallet. Specifying whether a wallet is self-hosted during a Travel Rule transfer is important, as certain jurisdictions have specific requirements to restrict or verify the ownership of these wallet addresses. In Ospree, Travel Rule transfers can originate from or be sent to both hosted and self-hosted wallet addresses. This can be specified using the fields `originator_address_is_self_hosted` and `beneficiary_address_is_self_hosted` ```json '{ // ... "originator_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy", "originator_address_is_self_hosted": false, // true or false // ... "beneficiary_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa", "beneficiary_address_is_self_hosted": true, // true or false // ... }, ``` {% hint style="warning" %} Note that Ospree does not support both the originator and beneficiary addresses being self-hosted. {% endhint %} ```json '{ // THIS IS NOT SUPPORTED, ONLY ONE ADDRESS IS ALLOWED TO BE SELF-HOSTED // ... "originator_address_is_self_hosted": true, // ... "beneficiary_address_is_self_hosted": true, // ... }, ``` #### Send crypto to a user’s self-hosted wallet ([Self-Hosted Wallet Withdrawal](https://docs.ospree.io/ospree-api/api-integration-flows#self-hosted-wallet-withdrawal)) Self-hosted wallets have the unique characteristic that, whether for incoming or outgoing Travel Rule transfers, the process must always be initiated by the VASP. In both cases, the beneficiary\_vasp\_id must correspond to the VASP initiating the action. You can think of it as a transaction being “sent to itself” for record-keeping purposes, ensuring proper compliance documentation even when the counterparty is a self-hosted address. A customer of VASP A wants to **withdraw** crypto to their self-hosted wallet (e.g., MetaMask). Although the beneficiary address isn’t managed by another VASP, VASP A is still required to initiate a Travel Rule transfer and properly record the transaction. This ensures compliance and auditability, particularly in jurisdictions where self-hosted wallet activity must be tracked or verified. ```json '{ // Originator and Beneficiary VASP IDs are displayed for illustration purposes // ... // "originator_vasp_id": "VASPAA" "originator_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy", "originator_address_is_self_hosted": false, // ... // "beneficiary_vasp_id": "SLFHST" // self-hosted "beneficiary_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa", "beneficiary_address_is_self_hosted": true, // ... }, ``` #### Receive crypto from a user’s self-hosted wallet ([Self-Hosted Wallet Deposit](https://docs.ospree.io/ospree-api/api-integration-flows#self-hosted-wallet-deposit)) If the same customer of VASP A wants to deposit crypto from their self-hosted wallet, the Travel Rule transfer should still be initiated by VASP A. ```json '{ // Originator and Beneficiary VASP IDs are displayed for illustration purposes // ... // "originator_vasp_id": "SLFHST" // self-hosted "originator_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa", "originator_address_is_self_hosted": true, // ... // "beneficiary_vasp_id": "VASPAA" "beneficiary_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy", "beneficiary_address_is_self_hosted": false, // ... }, ```