Travel Rule History

Travel Rule History is a consolidated page for GTR clients to view the history of both sent and received Travel Rule requests.

With the addition of the Out of Network Messages subtab, you can now manage both:

1. Travel Rule Requests: exchanged with your counterparty VASPs through the GTR network, whether submitted via API or manually.
2. Out of Network Messages: for transactions involving VASPs outside of the GTR network. It’s a secure, email-based solution that allows your VASP to fulfill Travel Rule obligations with non-GTR counterparties.

Travel Rule Request History

On the Travel Rule History page, each Travel Rule request will display detailed information about the transaction, including the network, token, and amount, as well as the addresses of both the originator and beneficiary, and VASP information. Additionally, it will display the status of the Travel Rule, and most importantly, the transmitted PII content and the verification status of each PII field.

Travel Rule Status

For a specific Travel Rule request, it typically goes through 3-4 stages in its lifetime, depending on different Travel Rule scenarios. On the Travel Rule History page , you can clearly view the current stage of a Travel Rule request and its status.

Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction

GTR clients will see below 3 stages and its current status.

	Stage	Status Transition
1	Initialize Travel Rule by Originator VASP	Success
2	Address Verification by Beneficiary VASP	Pending for review -> Passed or Failed
3	PII Verification by Beneficiary VASP	NA -> Pending for review -> Passed or Failed

Additionally, there is one last step for the Originator VASP to update the Transaction ID (TXID) to its counterpart VASP and GTR once the Travel Rule process is completed and the transaction has been sent to the blockchain.

If the Notify TXID step finishes, GTR clients will see the TXID populated in the "Transaction Information" section.

Scenario 2: If the Beneficiary VASP initialized this Travel Rule request after transaction on chain

GTR clients will see the following 3 stages, including their current statuses, on the Travel Rule History page.

The difference between Scenario 1 and Scenario 2 concerns the action owner for each stage. Moreover, as the transaction in this scenario is already on the blockchain, it includes the step of verifying the Transaction ID instead of the address as in Scenario 1.

	Stage	Status Transition
1	Initialize Travel Rule by Beneficiary VASP	Success
2	Transaction ID Verification by Originator VASP	Pending for review -> Passed or Failed
3	PII Verification by Originator VASP	NA -> Pending for review -> Passed or Failed

Travel Rule Verification Result

To check the verification status of a specific Travel Rule request, you may navigate to the "Travel Rule Status" section and click on the "More" arrow. Typically, the verification results include:

• Address Verification Result or Transaction ID Verification Result

• PII Verification Result

Address Verification Result

For a Travel Rule request undergone Address Verification stage as described in Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction, Address Verification Result will be displayed, consisting of:

• Beneficiary Address;
• Verify result replied by Beneficiary VASP: FOUND, NOT FOUND, or NA.

Transaction ID Verification Result

For a Travel Rule request went through Transaction Verification stage as described in Scenario 2 If the Beneficiary VASP initialized this Travel Rule request after transaction on chain, Transaction Verification Result will be displayed, consisting of:

• Transaction ID;
• Verify result replied by Originator VASP: FOUND, NOT FOUND, or NA.

PII Verification Result

PII Verification Result table displayed the overall verification result along with the verification status of each PII field. The specific fields included and displayed may vary from VASP to VASP.

For each field, there are 5 possible verification statuses replied by the Travel Rule Request Receiving VASP, the Beneficiary VASP in Scenario 1 Link to Scenario 1: If the Originator VASP initialized this Travel Rule request before transaction , or the Originator VASP in Scenario 2 Link to Scenario 2 If the Beneficiary VASP initialized this Travel Rule request after transaction on chain.

• MATCH: The PII Receiving VASP received this field and confirmed the verification result is a match;
• MISMATCH: The PII Receiving VASP received this field and confirmed the verification result is a mismatch;
• INFO_EXIST: The PII Receiving VASP expects this field but doesn't support to validate it;
• INFO_MISSING: The PII Receiving VASP expects to receive this field but didn't receive it;
• NOT_SUPPORT: The PII Receiving VASP neither expects this field nor supports to validate it;

Based on the direction of transaction and the role your VASP played in this Travel Rule, it will be drilled down into four cases.

I: If the Originator VASP initialized a Travel Rule request before transaction:

• If your VASP is the Originator VASP (also served as Travel Rule Request Initiating VASP): CASE A;
• If your VASP is the Beneficiary VASP (also served as Travel Rule Request Receiving VASP): CASE B;

II: If the Beneficiary VASP initialized Travel Rule request after transaction on chain:

• If your VASP is the Beneficiary VASP (also served as Travel Rule Request Initiating VASP): CASE C;
• If your VASP is the Originator VASP (also served as Travel Rule Request Receiving VASP): CASE D;

Case A

Scenario Description: When a customer on our VASP initiates a transfer of assets to another VASP but the transaction has not yet been sent to the blockchain, our VASP takes on the role of both the Originator VASP and the Travel Rule Request Initiating VASP. Before the blockchain transaction takes place, your VASP is responsible for preparing and sending the PII payload to the Beneficiary VASP.

• If your VASP triggered this Travel Request manually, the Beneficiary PII fields filled on GTR website will be fully displayed in the PII Verification result table.
• If this is an API Travel Rule, the PII fields displayed will be correspond to the expectVerifyFields specified in the /api/verify/v2/verify_pii API documentation. If your VASP didn't specify any expectVerifyFields, you may see verification results as NA or blank.

Case B

Scenario Description: When your counterpart VASP sends you a Travel Rule request before the transaction takes place on the blockchain, and in this request, it specifies that a customer from your VASP is expected to receive assets from the counterparty VASP. In this scenario, your VASP acts as both the Beneficiary VASP and the Travel Rule Request Receiving VASP. Consequently, your VASP is likely to receive the PII payload and is responsible for completing the verification process.

PII fields in the PII Verification result table will be fields your VASP actually verified, no matter in an API or Manual way.

Case C

Scenario Description: When your VASP has already received assets from a counterparty VASP, and you subsequently request PII verification from the counterparty, your VASP as the Beneficiary VASP of this asset transfer, becomes the Travel Rule Request Initiating VASP. As such, your VASP is responsible for initiating the Travel Rule request, preparing and sending the PII payload.

• If your VASP triggered this Travel Request manually, the Originator PII fields filled and sent will be fully displayed.
• If this is an API Travel Rule, the PII fields displayed will be correspond to the expectVerifyFields specified in the /api/verify/v2/verify_pii API documentation. If your VASP didn't specify any expectVerifyFields, you may see verification results as NA or blank.

Case D

Scenario Description: When your VASP received an Travel Rule request from your counterparty VASP after transaction already taken place, and in this request, it indicates that a customer from your VASP was the originator of this asset transfer, this makes your VASP served as the Travel Rule Receiving VASP. Your VASP can expect to receive PII payload and is responsible for completing the verification process.

PII fields in the PII Verification result table will be fields your VASP actually verified, no matter in an API or Manual way.

Transmitted PII Information

Transmitted PII Information shows the information prepared and sent by the PII Sending VASP concerning the PII of both the Originator and the Beneficiary. This typically includes details such as Name, Country of Residence, Date of Birth, Address, and more.

Contact Counter VASP

When there is a need for your VASP to contact the counterparty VASP regarding a specific Travel Rule request, you can use this function for email communication.

By clicking the “Contact Counter VASP” button on the Travel Rule History page, a mail thread will be initiated. You can then add additional content as needed. Email will then be sent securely after you confirm.

Considering many VASP concerned about the privacy of email addresses, your VASP’s email address will remain confidential and will not be exposed to your counterparty VASP. GTR will work as a proxy and will forward the reply to your email box.

Comment

When you think there is a need to leave a note for a specific Travel Rule request, you can click the “Add New Comment” button. Multiple notes are supported for each Travel Rule request.

Comments will only be visible to your VASP, your counterparty VASP will not be able to see them.

Out-of-Network Message History

The Out-of-Network Message History page provides detailed information for each request, including the network, token, amount, originator/beneficiary addresses, and VASP information. You can also track the real time status of Out-of-Network message processing, including TXID update status, and the progress of email distribution.

Typically, an Out-of-Network request progresses through three distinct stages. From this page, you can easily track its current stage and overall status.

	Stage	Status Transition
1	Initialize Out-of-Network request by Originator VASP	Sent
2	TXID Update by Originator VASP	Pending -> Received
3	Out-of-Network Email Distribution by GTR	NA -> Pending -> Sent or Not Sent

For each Out-of-Network request, its general status could be:

	Status	Description
1	Pending	Your VASP successfully initiated this Out-of-Network request. However, GTR hasn't yet received its corresponding TXID from your VASP.
2	Completed	Your TXID has arrived in GTR and GTR has successfully distributed an Out-of-Network email to your counterparty.
3	Failed	Your TXID has arrived in GTR. However GTR failed to complete the Out-of-Network email distribution to your counterparty due to a variety of reasons.

If your VASP wishes to integrate with GTR Out-of-Network solution, please visit below docs for more information:

• Out-of-Network Solution Overview
• Out-of-Network Technical Integration
• Out-of-Network Messages Configuration

Address Screening

The Address Screening feature provides risk assessment of counterparty wallet addresses during Travel Rule flows, powered by an intelligence datasource covering 400M+ labelled wallets, 30K+ entities, and 30+ blockchain networks. Screening results are displayed directly on the Travel Rule History detail page, enabling compliance teams to quickly assess counterparty risk.

When is Address Screening Performed?

Address Screening is triggered automatically based on the GTR travel rule flow type:

Flow Type	Screened Address	When Screening is Performed
Out-of-Network	Beneficiary Address	Always performed, no pre-condition
Unhosted Wallet	Beneficiary / Originator Address	After wallet ownership is verified (QR code scan + message signing confirmed)
Standard 2.0 (Pre-Transaction)	Beneficiary Address	After address verification is completed with a PASS result
Standard 2.0 (Post-Transaction)	Originator Address	After TX ID verification is completed with a PASS result
Standard 3.0	Beneficiary / Originator Address	After user verification is completed with a PASS result

INFO

Please note: Address Screening results are only visible when your VASP is the initiator of the Travel Rule request. If your counterparty VASP initiated the request, the Address Screening section will not be displayed on your side.

Screening States

The Address Screening section displays one of the following states:

Success

When screening has been completed, the following information is displayed:

• Risk Score: A score from 0.0 to 10.0 indicating the risk level of the address, displayed with a color-coded label and gradient scale bar. Scores are generated by an independent third-party intelligence provider and are not determined by GTR. The scoring uses rule-based, heuristic methods — not black-box AI/ML models — so every score is explainable and auditable.

• Screened Address: The wallet address that was screened, with a copy-to-clipboard button.

• Entity Name: The identified entity associated with the address (e.g., exchange name). Each address is matched against 400M+ labelled wallets. If a known entity is identified, the risk score reflects the category of that entity.

• Risk Category: A tag pill showing the wallet type classification. Hover over the tag to see the full category path and description.

Not Applicable

Displayed when the pre-condition for screening has not been met (e.g., address verification is still in progress). Complete the required verification step, and screening will run automatically.

Error / Pending

Displayed when the screening service is temporarily unavailable. No action is required. The system will retry automatically and display the result once available.

Risk Score Scale

Score Range	Label	Descriptions
0.0 – 3.9	Low Risk	Known exchanges, verified financial services, and other trusted entities.
4.0 – 6.9	Medium Risk	Unverified addresses, mixed counterparty exposure, or insufficient attribution data.
7.0 – 10.0	High Risk	Mixers, sanctioned entities, ransomware, dark markets, and other illicit activity.

Risk Category

Each screening result displays a tag pill showing the Wallet Type (the most specific level of the category taxonomy). Hovering over the tag reveals:

• The full three-level category path (Category > Sub-category > Wallet Type)

• A description of the wallet type

The top-level categories determine risk classification and are the primary input to the risk score. Below is a summary of the main categories and representative subcategories.

Category	Key Subcategories / Wallet Types
Exchange & Trading Platforms	Centralized Exchange, Decentralized Exchange, P2P Exchange, High Risk Exchange, Coin Swap Service, OTC Service
Financial Services & Infrastructure	Broker, Custody Service, Miner, Validator, Hardware/Software/Privacy Wallet, Layer 2, Payment Services, ATM
Service Providers & Other	DeFi/Lending/OTC, Payment Processors, Custodial Services, NFT Marketplace, Gaming, Crowdfunding, E-commerce, Merchant
Illicit or High Risk	Ransomware, Phishing, Scam, Ponzi Scheme, Mixer/Tumbler, Dark Market, Thief, Money Laundering, Pig Butchering, Fraud, Malware, Extortion
Illicit, High-Risk & Sanctioned	OFAC SDN, Sanctioned Individual/Organization/State Actor, FinCEN Money Laundering Concern, Blacklisted Entity, CSAM, Criminal Organisation
Sanctions	OFAC Sanctioned Entity, Sanctions List, Sanctioned Countries (Iran, Cuba, North Korea, Crimea, Donetsk, Luhansk, Khersonska, Zaporizka)
Community, User & Other	Personal Wallet, User Wallet, Token Wallet, Stablecoin Holder, NFT Wallet, Forum Wallet, Unlabelled Wallet

The full taxonomy includes 150+ wallet types. Categories such as Sanctions and Illicit or High Risk carry the highest risk scores by default.

FAQ

What does a risk score of 0 mean?

A score of 0 indicates the address is attributed to a well-known, low-risk entity such as a major regulated exchange. It does not mean the address has never been involved in any transaction — only that the entity itself carries no elevated risk based on current intelligence.

What happens if an address is unlabelled?

Unlabelled addresses are scored based on counterparty exposure — the entities they have transacted with, weighted by value and risk category. An unlabelled address that has interacted primarily with sanctioned entities will still receive a high risk score.

How often are labels updated?

Labels are updated continuously as new intelligence is ingested and validated. Sanctions lists (OFAC, UN, EU, UAE) are monitored in real time, with automated alerts on new designations. All other labels go through the standard validation pipeline before updates are deployed to production.

Can I proceed with a transaction if the risk score is high?

Address Screening is informational only — it does not block any Travel Rule flow or transaction. Whether to proceed with a high-risk transaction is determined by your VASP's own compliance policy. GTR provides the risk data; your compliance team decides the appropriate action.

Is the screening result final or can it change?

Screening results are a point-in-time snapshot based on the latest available intelligence at the time of screening. As new labels and risk data are ingested, the risk assessment for the same address may change in future screenings. A previously low-risk address could be reclassified if new adverse intelligence emerges, and vice versa.