Travel Rule Solutions
GTR mainly provides Before On-Chain Verify exchange solutions, and also provides secondary Challenge Verify solutions. We will introduce them in the next section. These flows (before on-chain and challenge verify) are created for GTR users to be able to adapt to the requirements of their respective regions and countries.
This is made for regions that require the clear text of information, GTR will transmit encrypted data. Figure 1-1. shows the overview of GTR components and functions.
Figure 1-1. GTR Components and Functions.
Based on differing regulations across various jurisdictions, GTR provides two types of scenarios for VASPs:
- Travel Rule initiation before the on-chain process
- Travel Rule initiation challenge verify process
As a VASP, you can choose the appropriate option depending on your specific requirements and compliance obligations.
Before On-Chain Verify Solution
Before on-chain verification means that the GTR system can complete the PII (Personally Identifiable Information) exchange between the originator VASP and the beneficiary VASP before the on-chain transaction takes place. Figure 1-2. shows the detailed information about the before on-chain workflow.
Figure 1-2. Before On-Chain Flow.
For integration steps, please refer to this link:
Before-On-Chain Verify Solution. This will guide you on how to integrate the Before-On-Chain Verify flow into your service.Challenge On-Chain Verify
The figures demonstrate two distinct scenarios, each with a fundamentally similar purpose. Figure 1-3 shows the withdrawal process originating from one party (Originator) and depositing to another party (Beneficiary). During this process, the system checks if the transfer recipient exists in the Beneficiary's service and follows the compliance policy. Conversely, Figure 1-4 presents the deposit process initiated by the Beneficiary, withdrawing funds from the Originator and depositing them into their own account. In this case, the system verifies if the deposit originator exists in the Originator's service and adheres to the compliance policy.
The key difference is the timing and responsibility of the verification process. In the withdrawal scenario (Figure 1-3), verification occurs before the on-chain transaction, which implies that the Originator is responsible for verifying the recipient's existence. On the other hand, for a deposit (Figure 1-4), the verification takes place after the on-chain transaction, indicating that the Beneficiary is responsible for checking the deposit originator's existence. This difference also determines whether or not the transaction ID (txId) is known.
Both scenarios use address, ticker and network information to identify the person's existence. The verification focus depends on which party wants to confirm the profile's existence and ensure compliance with the policies. In Figure 1-3, the Originator acts as the submitter, meaning they want to gather the necessary information, whereas in Figure 1-4, the Beneficiary fulfills this role.
Figure 1-3. Withdraw from originator, and originator wants to initiate the verification.
Figure 1-4. Deposit to beneficiary, and beneficiary wants to initiate the verification.
For integration steps, please refer to this link Challenge Verify Solution. This will guide you on how to integrate the Challenge Verify flow into your service.
