Overview

Ospree’s Travel Rule Module is a standalone solution built to help crypto businesses automate the review and approval of both incoming and outgoing transfers. It combines real-time checks, such as blockchain analytics, jurisdictional thresholds, wallet-type identification, and Travel Rule data validation, to ensure each transaction meets regulatory requirements before processing. The module can operate independently or integrate seamlessly with other Ospree tools, making it ideal for businesses aiming to enhance 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:

"originator_account": {
        "account_type": "individual", // "individual" or "entity"
        "account_category": "customer", // "customer" or "non-customer"
        // ...

 "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.

'{
// ...
    "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.

// ...
    "individual": {
        "individual_name": {
            "name_type": "LEGL",
            "name_first": "Mark",
            "name_last": "Rover"
            }
        }
},
// ...

// ...
    "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

 '{
     // ...     
    "originator_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy",
    "originator_address_is_self_hosted": false, // true or false
     // ...     
    "beneficiary_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
    "beneficiary_address_is_self_hosted": true, // true or false
     // ... 
 },    

Send crypto to a user’s self-hosted wallet (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 own 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. In this case, the field "beneficiary_vasp_id": "MLESJF" should reflect the ID of VASP A, since the transaction is initiated and recorded by the same VASP.

'{
    // ...     
    "beneficiary_vasp_id": "MLESJF", // ID of VASP A
    "originator_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy",
    "originator_address_is_self_hosted": false,
    // ...     
    "beneficiary_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
    "beneficiary_address_is_self_hosted": true,
    // ...    
 },     

Receive crypto from a user’s self-hosted wallet (Self-Hosted Wallet Deposit)

If the same customer of VASP A wants to deposit crypto from their own self-hosted wallet, the Travel Rule transfer should still be initiated by VASP A. In this case, the field "beneficiary_vasp_id": "MLESJF" should continue to reflect the ID of VASP A, with the originator and beneficiary roles reversed. Below is an example illustrating this setup:

'{
    // ...     
    "beneficiary_vasp_id": "MLESJF", // ID of VASP A
    "originator_address": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa",
    "originator_address_is_self_hosted": true,
    // ...     
    "beneficiary_address": "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy",
    "beneficiary_address_is_self_hosted": false,
    // ...    
 },