Travel Rule Solutions

We provide a one-stop shop for all your Global Travel Rule needs. Simply integrate with us once and we will facilitate Travel Rule compliance. Figure 1-1. shows the overview of GTR components and functions.

Figure 1-1. GTR Components and Functions.

Travel Rule Standard 2.0 Solution

What is Standard Travel Rule 2.0

Based on the FATF Travel Rule guidelines, in 2022 we developed GTR 1.0, also known as the GTR before-on-chain version, which multiple VASPs have already adopted. To enable GTR to provide Travel Rule services to a wider range of VASP types (regulated/offshore VASPs, custodial wallets, etc.), we developed GTR Standard Version 2.0. GTR 2.0 clearly defines the responsibilities between GTR and VASPs: GTR as the transmitter and VASPs as the verifiers, making the Travel Rule more secure, reliable, universal, and efficient.

The standard travel rule 2.0 can cover 2 situations:

1. Travel rule from one RVASP(regulated VASP) to another RVASP, this means both of the VASPs should comply with the local regulations, and share user information to a counterparty.
2. Travel rule from OFFVASP(offshore VASP) to RVASP, an OFFVASP is not obliged to share its user information to the counterparty. Detailed workflow as follows:

1. RVASP to RVASP

• Step 1, when a user at VASP (O) starts preparing to withdraw their assets, they should provide the necessary beneficiary information, which may include Name, DOB (Date of birth), ID, nationality, etc. This information complies with the IVSM101 standard.
• Steps 2-3, VASP (O) can call the GTR API to request the VASP(B) code, PublicKey(B), and verifiable information. This information is updated in the GTR system when the VASP registers with GTR. GTR responds with the information required to VASP (O).
• Steps 4-8, VASP (O) initiates an API address verification request. The purpose of this request is for VASP (B) to confirm that the target deposit address provided by the user at VASP (O) indeed belongs to VASP (B). Once VASP (B) completes the address verification, it returns the verification result to VASP (O) through GTR.
• Step 9, if VASP (O) receives a negative address verification result, it means that the beneficiary address provided by the user does not match the beneficiary VASP. VASP (O) should terminate the current Travel Rule process according to its compliance requirements.
• Step 10, VASP (O) uses the public key obtained in Steps 2-3 to encrypt the beneficiary user and originator user information provided by the user using an appropriate algorithm.
• Steps 11-16, VASP (O) initiates a new API request to transmit the encrypted information obtained in Step 10 to VASP (B) through GTR. VASP (B) uses its private key to decrypt the information and verify whether the beneficiary information indeed belongs to a real user of VASP (B). VASP (B) returns the verification result to VASP (O) through GTR.
• Step 17, if VASP (O) receives an expected result, it will initiate a blockchain transaction.
• Steps 18-20, VASP (O) needs to register the relationship between the blockchain transaction and the Travel Rule with GTR.
• Step 21, VASP (O) completes the user deposit process based on the relationship between the blockchain transaction and the Travel Rule.

2. OFFVASP to RVASP

• Step 1, VASP(O) initiates a blockchain transaction.
• Step 2, VASP(B) collects the originator information from the user.
• Steps 3-4, VASP (B) can call the GTR API to request the VASP(O) code, PublicKey(O), and verifiable information. This information is updated in the GTR system when the VASP registers with GTR. GTR responds with the necessary information to VASP (B).
• Steps 5-8, VASP (B) initiates an API transaction verification request. The purpose of this request is for VASP (O) to confirm that the transaction provided by VASP (O) indeed occurred on VASP (O). Once VASP (O) completes the transaction verification, it returns the verification result to VASP (B) through GTR.
• Step 9, if VASP (B) receives a negative transaction verification result, it means that the transaction provided by VASP(B) did not occur on VASP(O). VASP (B) should terminate the current Travel Rule process according to its compliance requirements.
• Step 10, VASP (B) uses the public key obtained in Steps 3-4 to encrypt the originator user information provided by the user using an appropriate algorithm.
• Steps 11-16, VASP (B) initiates a new API request to transmit the encrypted information obtained in Step 10 to VASP (O) through GTR. VASP (O) uses its private key to decrypt the information and verify whether the originator information indeed belongs to a real user of VASP (O). VASP (O) then returns the verification result to VASP (B) through GTR.
• Step 17, VASP (B) completes the user deposit process based on the originator user PII verification result.

Verify Emails from Global Travel Rule (GTR)

To ensure compliance with Travel Rule, GTR provides a service that enables the originating VASP to send an email notification to the beneficiary VASP with contact information for Travel Rule verification.

All legitimate emails related to this service will be sent from the following domains:

• mg.globaltravelrule.com
• ses.globaltravelrule.com

If you receive an email from this domain, it has been officially sent by GTR as part of this service. We encourage beneficiary VASPs to recognize emails from this domain and contact the originating VASP directly to retrieve necessary Travel Rule-related PII information.

If your organization is interested in this service or has compliance requirements related to sending email notifications with each transaction, please feel free to

contact us for more details.

For any concerns regarding email authenticity, please contact our support team.