FATF Travel Rule’s Technical Challenges andSolution Taxonomy
Yuto Takei

Kazuyuki Shudo

Mercari, Inc., andTokyo Institute of Technology

Kyoto University

Abstract—Virtual assets are globally recognized as a decentralized digital currency system. They are also being used to transfer
criminal proceeds. In 2019, the Financial Action Task Forcemandated the Travel Rule for virtual asset service providers(VASPs). However, as of March 2024, it has not been fully
implemented worldwide due to the Sunrise issue. Complying
with the Travel Rule poses challenges such as identifying therecipient VASP from a virtual asset address, proving ownershipof the address, and ensuring communication protocols between
the VASPs. In this paper, we focus on these three challenges
and provide potential approaches for each, along with additional
considerations. We have analyzed multiple existing protocols andcategorized their characteristics. Our findings revealed that the
majority of them are based on an alliance of VASPs, while there
are a few solutions that suggest peer-to-peer messaging for every
VASP or blockchain as a communication hub. Additionally, weoffer insights into open challenges that need to be solved in thelong term.
Index Terms—virtual asset, cryptocurrency, FATF, travel rule,
VASP, anti-money laundering, compliance

I. I NTRODUCTION
Virtual assets (VAs), also commonly known as cryptocurrencies, are recognized worldwide as decentralized digitalcurrency systems. Various VAs are used as investment instruments, but they are also being used as a means to transfer
criminal proceeds. To fight against such illegal activities, theFinancial Action Task Force (FATF) has mandated the Travel
Rule for VA transfers, which is an information collection
obligation about senders and recipients to virtual asset service
providers (VASPs), such as exchanges.
From the perspective of VASPs, the regulation comes withseveral technical challenges, such as the discovery of thereceiving VASP for each VA transfer and the establishmentof communication protocols between VASPs. Still, it can besaid that proper Anti-Money Laundering / Combating the
Financing of Terrorism (AML/CFT) efforts must be madeso that VAs become widely accepted financial instruments
and aim for the future prosperity of the VA economy. Thus,
interoperability between any VASPs and the efficiency andeffectiveness of the implementation are critical.
Compared to the entire history of VAs since 2008, beginningwith Bitcoin, the Travel Rule for VAs is a new initiative
proposed in 2018, and the established research literature islimited. Several vendors have developed solutions to implement the Travel Rule, but none of them have become the vast
majority. It is hard to say that the domain knowledge available
to stakeholders is well organized. Therefore, systematicallyorganized literature from a neutral perspective is necessary.
We aim to overlook the entire picture of the Travel Ruleand help VASPs, Travel Rule solution providers, regulatory
authorities, and researchers understand the ecosystem. Ourcontributions in this paper are as follows:
We will aggregate knowledge about the Travel Rule basedon public information sources.
• We will list the technical challenges the industry faces in
implementing the Travel Rule.
• We will also organize, analyze, and categorize currently
available solutions as of March 2024.
•

The authors have experience developing blockchain analysis
software and are currently in a position to implement theTravel Rule at a VA exchange. We believe the information
depicted in the paper is neutral and fills the gap of generally
available knowledge.
The composition of this paper is as follows. In Section II,
we will explain the mechanism and rationale behind money
laundering through VAs and the efforts of the FATF toregulate it. In Section III, we will revisit the definition of
the FATF’s Travel Rule for VAs. We will also describe thecurrent legislative situation in major countries and mention
the “Sunrise issue”. From Section IV to Section VI, we
will discuss the challenges that VASPs and the industry will
inevitably face in implementing the Travel Rule. In each ofthese sections, we will describe the overview of the issue,
list several possible solutions, and delve into further minor
issues that each option entails. In Section VII, we will observe
major Travel Rule solutions and systematize how solutions are
combined. After we discuss open challenges and other generalissues in Section VIII, we conclude in Section IX.
We follow the FATF terms for technical vocabulary1 . Virtual
currency, cryptoassets, or similar financial instruments are referred to as virtual assets (VAs). Exchanges or similar entities
are referred to as virtual asset service providers (VASPs).

1 The list of abbreviations in the paper is available in Appendix A.

© 2024 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media,
including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers
or lists, or reuse of any copyrighted component of this work in other works.

II. BACKGROUND
A. Virtual Assets and Criminal Activities
Many VAs, such as Bitcoin [1] and Ethereum [2], arerecorded using blockchain technology [3]. The informationon the blockchain is maintained on each participating nodeon the Internet and synchronized worldwide. VA holders cantransfer their assets by specifying a VA address and an amount.
These features enable payment regardless of the purposeor recipients. In particular, in countries and regions whereadministrative, judicial, or financial institutions are corrupt,
VAs serve as a trusted financial infrastructure compared tolegal currencies. There is no risk of payment being tamperedwith or obstructed, no demands for bribes, and the privacy ofboth the sender and recipient is protected.
Despite its advantages, these characteristics are convenient
for criminals. Since a VA holder cannot be easily identified
from their address, it is possible to send criminal proceeds
without being noticed by law enforcement agencies. Also, theease of making cross-border transfers could facilitate illegal
funding for organized crime or terrorism [4]. In fact, VAs
are used as a means of payment on dark web markets tohide the identities of both sellers and buyers, where illegal
drugs, counterfeit identification documents, and other unlawful
materials are on sale over anonymous network connections
such as Tor [5].
While there are some techniques known to deanonymize
blockchain transactions, there are also VAs that have privacyenhancing features in the underlying blockchain, providing
resistance against such analysis. For example, Ben-Sasson
et al. developed Zcash [6] based on their earlier work on
zk-SNARKs [7]. Zcash allows users to create a shieldedtransaction, whose sender can hide the destination and theamount from anyone else other than themselves and therecipient. Monero [8] uses ring signatures and confidential
transactions to accomplish a similar goal. These blockchains
have demonstrated the potential of advanced cryptography inthe use of the blockchain field. However, there is a significant risk that unlawful proceeds are exchanged over theseblockchains. FATF refers to such VAs as Anonymity Enhanced
Coins (AECs), and VASPs in some jurisdictions are prohibitedfrom offering services related to AECs.
A mixing technique is also known to enhance privacy
and anonymity. CoinJoin aggregates Bitcoin withdrawals frommultiple users into a single transaction, obscuring the flowof funds [9]. Privacy-focused wallets like Samourai Walletand Wasabi Wallet have these features built-in [10]. Tornado
Cash, a distributed application on Ethereum, mixes Etherand ERC-20 on the same principle using zk-SNARKs. Whilethese mixing services are convenient for legitimate users whowant to maintain their privacy, they are frequently used bycriminals. The developers of Tornado Cash have been indictedby financial authorities, knowing that it was being used formoney laundering exceeding 1 billion USD [11].
Recently, criminals may use bridge services that enable thetransfer of assets between different blockchains to move illicit

funds from one cryptocurrency on a blockchain to another.
According to Elliptic’s analysis, the techniques used to evadeblockchain analysis have shifted from mixing to cross-chain
methods since August 2022 [12]. This shift is said to be a
response to the sanctioning of Tornado Cash.
B. Law Enforcement Efforts
Blockchain analysis tools are used by law enforcement
agencies to combat criminal activities involving VAs. One of
the first techniques employed by these tools is the commoninput-ownership heuristic. This method guesses multiple addresses that are controlled by the same owner [13].
Law enforcement agencies monitor transactions involving
known addresses identified as illegal entities and track theflow of funds. When the illegal funds have been deposited
into a VASP address, law enforcement will try to identify theaccount owner using search warrants and other legal means.
If a suspect is arrested and the private keys for the addresses
are found on the seized devices, such a fact will be used asstrong evidence of the involvement of the arrested suspect.
However, it is extremely difficult to resolve cases whencross-border transactions are involved across multiple jurisdictions. For example, one of the convicts was detained in Greece
in 2017, who conducted a cyber attack against Mt. Gox, aBitcoin exchange in Japan between 2011 and 2014 [14]. He
was eventually indicted in the U.S. in 2023 for laundering thestolen funds by running another exchange, BTC-e [15].
The methods used by attackers have become more sophisticated in order to evade judicial enforcement. Data processing
technology for analyzing related transactions across multiple
blockchains is becoming increasingly important.
C. Overview of FATF’s Regulation
The FATF has documented the FATF Recommendations[16], which dictate AML/CFT measures for countries andtheir private sectors. These recommendations are applied toover 200 jurisdictions worldwide, either directly through FATF
membership or indirectly through FATF-Style Regional Bodies (FSRBs). Participating countries are subjected to regularmutual evaluations to ensure legislative alignment, and theevaluation reports are made public. Each country is expected
to enact laws that align with the recommendations.
Money laundering is understood to involve three steps:
1) Placement where criminal proceeds are deposited into
the financial network.
2) Layering where illegal funds are transferred repeatedly
or mixed with legitimate funds to obscure the origin andinvolvement in the crime.
3) Integration where the illegal funds are invested in legitimate assets, e.g., real estate, to legitimize them andgenerate seemingly lawful profits.
Among these, preventing (1) placement and (2) layering
is particularly important for VAs, and the FATF urges eachcountry to establish regulations for VASPs.
As a measure against (1) placement, the FATF requires all
financial institutions including VASPs to conduct customer due

Settlement networkA

TABLE IO BLIGATION OF VASP S

Virtual asset

Withdrawal
request to B

Depositnotiﬁcation

B

Travel rule data
Originator

Originator
VASP

Beneﬁciary
VASP
Messaging network

Beneﬁciary(can be same
person as A)

collect
ensure accuracy of
conduct screening withsend to other VASP
information of

Originator VASP must Beneficiary VASP must
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
originator beneficiary originator beneficiaryFig. 1. Travel Rule at its Heartdiligence (CDD). A compliant institution can prevent highrisk users from opening accounts through a process known
as Know Your Customer (KYC). This involves verifying theidentity of customers by reviewing legal identification documents and their authenticity, as well as conducting searches
across various sources, such as sanction lists, prison inmate
registries, or newspaper archives.
As a measure against (2) layering, the FATF requires boththe sending and receiving institutions to collect and verify theidentity of both parties involved in a transfer. The sending
institution must transmit customer information to the receiving
institution, a requirement known as the Travel Rule. This
allows the receiving institution to verify the sender’s identityand prevent the inflow of criminal funds. In case of suspected
involvement of high-risk users, an institution should file a
suspicious transaction report (STR) and retain all records forfive years to cooperate with investigative authorities.
III. S TATUS Q UO OF T RAVEL RULE
A. Details of Travel Rule
The Travel Rule is widely, albeit inaccurately, known as
the obligation to transmit the sender’s information from theoriginator VASP to the receiving VASP when a user requests
a VASP to withdraw VAs to another VASP. We will clarify thedetails of the stipulation based on Recommendation 15 (Newtechnologies), Recommendation 16 (Wire transfers), and theirInterpretive Notes, as this will serve as the premise for the restof this paper.
In the FATF Recommendation, the sender is referred to as
the originator, and the recipient as the beneficiary. For the restof the paper, we will follow these.
As outlined in Figure 1 and Table I, VASPs are obligated tocomply with the following requirements regarding the transfer
of VAs:• The originator VASP and the beneficiary VASP mustobtain and retain personally identifiable information (PII)
about both the sender and the recipient.
• The originator VASP must transmit PII of both the senderand the recipient to the beneficiary VASP.
• Both VASPs must ensure the accuracy of PII for the user
on their sides.
These apply when a customer sends VAs held in a VASP
account to an account on another VASP, regardless of whether
the destination account is owned by the sender or a different
person or entity.

We do not consider intermediary VASPs in this paper
because VAs are typically transferred directly, although intermediary VASPs, if any, have an obligation similar to a correspondent bank in cross-border wire transfers. Additionally,
we consider all VA transfers as cross-border for simplicity ofthe discussion while the obligations slightly differ between
domestic and cross-border transfers.
The PII must include the following:
Name, typically the legal name for natural persons andthe registration name for legal entities.
• Account number of the account used to process thetransfer, such as the user ID within the VASP or VA
address.
• (For the sender only) Address, national identification
number, customer identifier, or date and place of birth.
•

The PII must be transmitted either before or simultaneouslywith VASP-to-VASP transfers exceeding a value of 1,000 USD/ EUR. However, this obligation does not apply to transfers
between addresses not managed by VASPs, i.e., unhosted
wallets. Both VASPs must conduct CDD based on the PII
collected and process or reject the transaction as necessary.
The PII must be retained for five years and disclosed to legal
authorities upon request.
As mentioned in Section II-C, each country has to legislate in alignment with the above requirements, as the FATF
Recommendations are inherently applied to countries and not
private sectors. In practice, as an exception, it is common to
exclude the enforcement of the Travel Rule for transfers to
VASPs in non-FATF/FSRB member countries or regions.
B. Sunrise Issue
As depicted in Figure 2, VASPs that comply with the Travel
Rule inevitably fail if the VASP on the other side is notcompliant. This is due to the fact that the implementation
timeline for Travel Rule regulations varies across countries. In
some jurisdictions, VASPs are already required to comply with
the Travel Rule in their local law, while in others, transfers are
executed without the transmission of PII as the Travel Rule has
yet to be enacted. This legislative timing difference is known
as the Sunrise issue [17], [18].
The Sunrise issue has a significant impact on compliant
VASPs as there is a risk of violating the Travel Rule if
the counterparty involved in the transfer is non-compliant.
When a compliant originator VASP is unable to communicate
with a non-compliant beneficiary VASP, the originator VASP
fails to transmit PII. Similarly, a compliant beneficiary VASP

Non-compliant

Travel Rule Enforced

D. Overview of Current Technical Challenges
No information
about originator

Originator
VASP

Beneﬁciary
VASP

Fail to comply!

(a) Receiving from non-compliant VASP
Travel Rule Enforced

Non-compliant

Originator
VASP

Beneﬁciary
VASP

No way tocommunicate with
Beneﬁciary VASP

Fail to comply!

(b) Sending to non-compliant VASP
Fig. 2. Sunrise Issue

cannot receive PII from a non-compliant originator VASP and
therefore cannot conduct CDD against the sender.
On the other hand, VASPs in countries that have not yet
enacted the Travel Rule may find it challenging to comply.
It is reasonable for VASPs to be hesitant in incurring extra
costs without legal enforcement, especially considering that
the Travel Rule involves multiple parties. Additionally, there
may be conflicts with privacy protection laws that prevent
VASPs from transmitting PII.
In response to this situation, the FATF is urging countries
that have not implemented the Travel Rule to expedite legislation to resolve the Sunrise issue. They are actively engaging
with jurisdictions to assess the effectiveness and operationalityof the laws that have been enacted.
C. Messaging Format
IVMS 101 [19], established by the Joint Working Group(JWG) on interVASP Messaging Standards, defines the schemaof information exchanged between VASPs for Travel Rulecompliance. The purpose of it was to establish a common
data model agreed upon by VASPs worldwide.
The JWG has referred to various standards, such as theSWIFT message format, ISO 20022 [20], or Legal Entity
Identifier [21], during the design process to ensure interoperability. It has considered the business practices and cultural
backgrounds of each country, resulting in the adoption of,for example, multiple representations of a natural person’sname and transliteration support for characters other than thealphabets used in Western countries.
IVMS 101 does not specify serialization, encoding, or
encryption methods to keep it simple as a data model. Specificcommunication protocols are to be defined separately, and inpractice, they are left to the discretion of each VASP.

There are three major technical challenges in implementing
the travel rule. These challenges are outlined below in theorder they occur in the travel rule procedure.
1) Destination VASP Identification: To ensure that the PII istransmitted to the correct recipient, an originator VASP needs
to identify the controlling VASP of the destination address.
If the address belongs to an unhosted wallet otherwise, theoriginator VASP would like to know it as well. Various
approaches exist to address this challenge, such as utilizing acentral database of addresses or reaching out to other VASPs
to inquire if they manage the address. It will be discussed in
Section IV.
2) Proof of Address Ownership: Let’s focus on the beneficiary VASP. If a VASP wants to demonstrate that they havecontrol over a specific VA address to someone else, it can bechallenging. It is because an address can be derived from apublic key but not the other way around in many VA systems.
As a result, it is difficult for others, e.g., the originator VASP,
to verify if the VASP possesses the corresponding key to an
address. This issue was known by VASPs before the travel
rule, to prove their ownership of VAs during the audit process,known as Proof of Reserve. Hardjono et al. have conducted astudy on various methods for attesting VASP’s wallets [22].
Depending on the architecture, the beneficiary VASP may
provide a cryptographic proof either in real-time to the originator VASP or prior to the transaction through registration to acentralized VA address directory, if one exists. The VASP may
also ensure the control of the address through other means,such as a legal guarantee. The current approaches used by
VASPs will be discussed in Section IV.
3) PII Transmission Interface: After the originator VASP
identified the beneficiary VASP, they need to negotiate toestablish a communication channel between them.
The most decentralized approach involves each VASP establishing a direct peer-to-peer communication channel withevery other VASP. Conversely, the most centralized approachis to maintain a jointly managed VASP directory, which allows
an originator VASP to easily find the communication endpoint
for the beneficiary VASP. However, these two methods represent the extreme ends. In practice, a more balanced solution
can be achieved by forming alliances among multiple VASPs.
Details on this challenge will be discussed in Section VI.
IV. C HALLENGE 1: D ESTINATION VASP I DENTIFICATION
Consider a scenario depicted in Figure 3. Alice requests totransfer VAs from a VASP, 𝑉𝑎 , to Bob’s address, addr. Upon
the withdrawal request, 𝑉𝑎 asks Alice to provide Bob’s PII andhis VASP. Note that Alice and Bob may be the same person.
Alice may provide false information to 𝑉𝑎 , either by mistakeor deliberately. Therefore, regardless of Alice’s declaration, 𝑉𝑎
needs to determine whether addr is controlled by one of:𝑉𝐶 ) VASPs that comply with the Travel Rule and have aknown communication channel,

VASPs in regulated areas

Send toUnknown
VASPs

addr...
Withdraw

Compliant
VASPs (VC)

Va

Alice

VASPs in nonregulated areas (VN)

Alice’s
VASP

Others (VO)

Unhosted wallets (U)Hardwarewallets

Softwarewallets

Fig. 3. Challenge on Destination VASP Identification

𝑉𝑁 ) VASPs that are neither in a participant country of
FATF/FSRB nor in a FATF blacklist country and haveno obligation to comply with the Travel Rule, or𝑉𝑂 ) other VASPs with no known communication channel,
or addr is one from:𝑈) unhosted wallets.
As per the Travel Rule compliance, 𝑉𝑎 can proceed with thetransfer if 𝑉𝑏 ∈ 𝑉𝐶 , with sending PII of Alice and Bob, or 𝑉𝑏 ∈𝑉𝑁 ∪ 𝑈 without sending PII. 𝑉𝑎 must reject the withdrawal
request to 𝑉𝑂 .
Approach 1-A. Restricting Withdrawal Destinations
𝑉𝑎 can mandate Alice to declare that the withdrawal is either
to 𝑉𝑁 or 𝑈. However, this method would be difficult to justify
from a business perspective, considering the fact that the
major global VASPs are located in FATF member countries.
Furthermore, this method does not address the possibility of
Alice making false declarations.
Approach 1-B. Using Lookup Service
Suppose a lookup service exists to find the controlling VASP
of addr. 𝑉𝑎 can use the lookup service for Alice’s withdrawal
request. As a basic idea, if the lookup service responds with 𝑉𝑏★
as the controlling VASP of addr, then 𝑉𝑎 transmits PII to 𝑉𝑏★.
Otherwise, 𝑉𝑎 may consider it unhosted. Figure 4 illustrates
the approach.
𝑉𝑎 may additionally use a blockchain analysis tool if available. Tools typically provide some guess if any withdrawals
from addr were performed in the past. On the other hand, they
may not be able to identify newly generated addresses andmay respond as unknown. Many tools report the result witha probability, and we only consider the most likely candidate
here for simplicity.
Algorithm 1 illustrates a typical decision algorithm that 𝑉𝑎
can use. Lookup returning 𝑉 or nil denotes the query to thelookup service. Analyze returning 𝑉, 𝑈, or unknown denotes
the query to the blockchain analysis tool.
In the algorithm, let Alice’s declaration about addr bedenoted as 𝑉𝑏 , which is one among 𝑉𝐶 |𝑉𝑁 |𝑉𝑂 |𝑈.
First, 𝑉𝑎 checks if 𝑉𝑏 is not 𝑉𝑂 , or rejects the transfer request. In reality, some VASPs proceed with the transfer without

PII transmission, although non-compliant, as a compromisedue to the Sunrise issue.
Next, suppose a registration for addr by 𝑉𝑏★ is found in the
lookup service. If 𝑉𝑏 matches with 𝑉𝑏★, then 𝑉𝑎 can confidently
proceed with the PII transmission to 𝑉𝑏 . Otherwise, customer
support will contact Alice and perform additional verification
regarding the purpose of the transfer. It may be necessary to
reject the transfer or file an STR depending on the situation.
When no record is found about addr, e.g., in the case where
𝑉𝑏 fails to register with the lookup service, 𝑉𝑎 may perform
an analysis of addr. Let the analysis result be denoted as 𝑉𝑏• ,one among 𝑉𝐶 |𝑉𝑁 |𝑉𝑂 |𝑈|unknown.
If 𝑉𝑏 = 𝑉𝑏• or 𝑉𝑏• = unknown, i.e., Alice’s declaration
matches with the analysis result if available or the tool did
not have insights about the address, then 𝑉𝑎 should proceed
based on Alice’s declaration. That is, initiate the virtual transfer
with the transmission of PII to 𝑉𝑏★ if it is (𝑉𝐶 ), or without
if it is (𝑉𝑂 ) or (𝑈). Although additional verification for risk
assessment may be preferred in the latter case, it does not
immediately constitute a violation of the Travel Rule.
Otherwise, such as in the case where Alice declared as
unhosted while the tool responded with a VASP, 𝑉𝑎 may needto consider the possible analysis error and adjust its response
depending on the tool’s confidence on result.
Several considerations must be made for this approach.
1) Performance and Security of Lookup Service: Each time
VASPs issue a new address to a customer, they are required
to register it with the lookup service. The performance of
this lookup service is crucial for facilitating any VA transfers
for participating VASPs, making it a vital and indispensable
system. The implementation of the lookup service does notnecessarily need to be centralized; it could also be decentralized, and it is technically feasible to record it in the same
blockchain as the addr. Nonetheless, any architecture needs
to be resilient against failure or attacks. For example, we needto consider the possibility of Denial of Service (DoS) attacks
through the mass registration of fake addresses.
2) Data Governance and Access Control: From a privacy
perspective, it is not suitable to allow public access to thelookup service’s database. Ideally, only the VASP that needs
to initiate a transfer to a specific addr should have the ability tolook up addr, and only during the transfer process. Therefore,
it is important for the lookup service to implement proper
access control and rate limiting.
Another concern is that the operator of the lookup service
might use the data without the consent of VASPs or end-users.
This information could be valuable to blockchain analysis
companies for understanding the flow of funds. One possible
solution would be to hash addresses when registering, although
this would make it difficult to prove ownership. This will befurther discussed in the section on Section VIII-B.
3) Unregistered Addresses: VASPs are unable to look up
unregistered addresses, which means that 𝑉𝑎 might incorrectlyclassify 𝑎𝑑𝑑𝑟 as 𝑈 if 𝑉𝑏 fails to register it. This highlights thesignificance of blockchain analysis tools as a supplementary
aid to the risk-based approach for AML/CFT [23], but it(1-C) Special identiﬁer and (1-D) Domain name(1-B) Lookup serviceX(2) “Which VASP
hosts 1ABC...?”(1) hoste”“W BC...
1A(3) “It’s VASP X.”

“1BC

Y

D...”

Originator

Lookup

VASP

service(5VAS ) Looku
p
P fo
r “b
b...”

VASP

(6) “Which virtual asset address
corresponds to bb1234...?”

Va

o
dt
sen ”
(4) ease 34...
“Pl bb12Vb(7) “It is 1ABC...”

directory(8) Transfer virtual asset /Transmit travel dule data

Originator

Beneﬁciary

VASP

VASP

(1)
dep “Whosi at(2) t add is myr“bb1 ess?”23
4..
.”(3) “Here is my address: bb1234...”

Alice

Bob

Fig. 4. Possible Approaches for Destination VASP Identification

Algorithm 1 Decision flow of withdrawal compliance anddestination
𝑉𝑏 ← Alice’s declaration about addr
if 𝑉𝑏 ∈ 𝑉𝑂 thenreturn (no, 𝑉𝑏 )⊲ non-compliantelse
𝑉𝑏★ ← Lookup(addr)
if 𝑉𝑏★ ≠ nil thenif 𝑉𝑏 = 𝑉𝑏★ thenreturn (yes, 𝑉𝑏 )⊲ truthful declarationelse⊲ possible false declaration
return (no, 𝑉𝑏★)
end ifelse
𝑉𝑏• ← Analyze(addr) ∥ unknown
if 𝑉𝑏 = 𝑉𝑏• ∥ 𝑉𝑏• = unknown thenreturn (yes, 𝑉𝑏 )⊲ presumably truthfulelse⊲ possible wrong analysis
return (no, 𝑉𝑏• )end ifend ifend ifis worth mentioning that there can be occasional errors in
the analysis. Hence, it is essential to encourage participating
VASPs to register their addresses in a timely manner after they
are generated.
4) Multiple Lookup Services: With the emergence of several Travel Rule solutions, it is now possible for a VASP
to connect to multiple lookup services. In such a scenario,
the VASP needs to conduct lookups simultaneously until it
receives a positive response from at least one service or until
it receives negative responses from all services. This mightcause a delay in the completion of withdrawals for users.
The issue of performance caused by time differences between the settlement network and messaging network has been
identified during the designing of financial networks [24]. The
VA transfer has to wait for the messaging to be completed, andtherefore, any latency in the lookup must be minimized.
5) Proof of Address Ownership: If a lookup service accepts
address registrations without requiring proof of ownership,

there is a risk of fraudulent registrations. This could lead to thedisclosure of a customer’s PII, which VASPs are unlikely totolerate. To prevent this, the lookup service should implementa mechanism to require proof of address ownership or request
a certain level of guarantee from registering parties about theaccuracy of their information.
Approach 1-C. Using a Special Identifier
The use of a special identifier is an alternative to VA addresses for representing an account on VASPs. This eliminates
the requirement for a lookup service. The following steps,aligned with the numbers depicted in Figure 4, illustrate theexample.
(1) and (2) Bob first requests his deposit address at 𝑉𝑏 andreceives a special identifier addr★ (bb1234. . . inthe figure) that encodes the issuer 𝑉𝑏 .
(3) and (4) Bob shares addr★ with Alice, who requests a
withdrawal to addr★ from 𝑉𝑎 .
(5) 𝑉𝑎 decodes addr★ to determine 𝑉𝑏 .
(6) – (8) 𝑉𝑎 queries 𝑉𝑏 to obtain the actual address addr
and completes the transfer.
The use of specially encoded identifiers is a common practice in international banking systems for identifying recipientsand their respective financial institutions. For example, theInternational Bank Account Number (IBAN) [25], widelyadopted in Europe, encodes both the account number andthe financial institution using the Basic Bank Account Number, which follows a 2-letter country code and check digits.
Another example is the SWIFT Bank Identifier Code (BIC)[26], which facilitates the identification of financial institutions
and their branches worldwide through an 8-character or 11character code.
When considering the format of the special identifier, it isrecommended to design the system in such a way that theoriginal address is not included. This approach is advantageous
for several reasons:• By excluding the address from the special identifier,it can be shortened, resulting in a more concise andcustomizable representation.
• It prevents the possibility of Alice creating a false identifier to evade the travel rule.
By the nature of the travel rule, 𝑉𝑎 must establish communication with 𝑉𝑏 for PII transmission. At the beginning of thisprocess, 𝑉𝑎 should redeem addr★ for addr.

1) Necessity of VASP Directory: In this approach, a comprehensive list of VASPs needs to be maintained. This list,
referred to as a VASP directory, can be managed either online,
allowing for centralized management and inclusion of all
VASPs, or offline, where it can be cached within a VASP’s
internal system and periodically updated.
2) Conflict with Unhosted Wallets: In order to enable Aliceto withdraw funds to an unhosted wallet, 𝑉𝑎 must accept thewithdrawal request to the conventional VA address. However,this introduces the risk of malicious Alice making false declarations by simply specifying addr to evade the travel rule.
As a result, the advantages of using the special identifier arecompromised.
Approach 1-D. Using Domain Name for Transfers
As a variant of (1-C), the domain name of VASPs can beused as a part of a special identifier. This removes the need fora lookup service or VASP directory. We refer to this identifier
as Deposit URI.
Suppose Alice wants to make a Bitcoin transfer to Bob. He
provides his deposit URI vasp-b.example/btc/12345
to Alice, which includes:
𝑉𝑏 ’s domain name vasp-b.example
Type of VA Bitcoin (btc)
Bob’s user ID 12345
𝑉𝑏 implements a certain API on the given URI, and 𝑉𝑎 cancall this API to obtain the actual addr. The API specificationmust be pre-defined and agreed upon by VASPs.
In practice, it is reasonable to assume that VASPs have areachable domain name on the Internet to comply with the
PII transmission obligation. The structure of the deposit URI
provided is just one example, and a dedicated URI scheme
could be defined to clearly differentiate it from HTTPS orother protocols.
1) DNS-Specific Security Concerns: This approach entirely
relies on DNS, which has a different architecture and security
implications. As a result, VA transfers may be vulnerable to
DNS security risks in addition to existing ones. For instance,
an attacker could target a specific VASP, 𝑉𝑥 , and potentiallysteal all VAs that are intended to be deposited to 𝑉𝑥 throughDNS contamination [27], [28]. Additionally, there is a potential risk of phishing attacks using similar DNS names inthe deposit URI. Furthermore, if a VASP changes its domain
name, the old deposit URI may no longer be valid.
V. C HALLENGE 2: C LAIMING A DDRESS OWNERSHIPThe beneficiary VASP, who manages 𝑎𝑑𝑑𝑟, may need toclaim their control over the address, such as in the case (1)when the originator VASP wants to verify the correctness of
the identified beneficiary VASP before initiating PII transmission, as mentioned in Section III-D2, or (2) when a lookup
service wants to verify a new registration request from aparticipating VASP, as mentioned in (1-B).

(2-A) Contract-based(2-B) Providing proof“We manage
1ABC...
Here is proof:****”

Legal relationship“We manage
1ABC...”
Lookupservice

Member
VASP

Lookupservice

Member
VASP

Fig. 5. Possible Approaches for Claiming Ownership of Address

Approach 2-A. Contractual Commitment
One possibility is that the claiming VASP provides a legal
guarantee of possessing a corresponding key to 𝑎𝑑𝑑𝑟. Thisguarantee is simply a contractual commitment.
This approach facilitates the access-controlled lookup service where only VASPs with a low-risk profile can participate,
as mentioned in (1-B). It is also compatible with peer-to-peer
communication between VASPs, as discussed later in (3-A),or in the creation of an alliance network mentioned in (3-C).
Although the contractual framework helps limit the risk of
VASPs declaring addresses that are not under their control, it
does not completely eliminate this risk.
Approach 2-B. Cryptographic Proof
Another option is to generate a cryptographic proof for𝑎𝑑𝑑𝑟, typically a digital signature generated from the private
key of 𝑎𝑑𝑑𝑟. This process is similar to signing a VA transaction
for transfer from 𝑎𝑑𝑑𝑟.
Assuming that 𝑉𝑏 is making a claim of ownership for addr
against 𝑉𝑎 (or possibly the lookup service), the claim message
msg that needs to be signed should contain the following fields:• Unique identifier of 𝑉𝑏 , which can be the legal name of𝑉𝑏 .
• Challenge message to ensure that the proof is generated
after 𝑉𝑎 ’s request, which can be random bytes specified
by 𝑉𝑎 .
• Public key(s), required to derive 𝑎𝑑𝑑𝑟 and to verify thedigital signature.
• Other optional metadata. For example, a block height ora timestamp, to associate the validity of the 𝑎𝑑𝑑𝑟 to thespecific time on the blockchain.
To prevent the proof from being falsely reused by others, either
the unique identifier of 𝑉𝑏 or the challenge message by 𝑉𝑎should be mandatory in the protocol.
𝑉𝑎 verifies the validity of the digital signature for msg alongwith its contained fields. If valid, 𝑉𝑎 can confidently proceedwith the transmission of PII, or the lookup service can accept
the registration of addr by 𝑉𝑏 .
The above method works well if 𝑎𝑑𝑑𝑟 is simply generated
from a single private key. It also works with a hierarchicaldeterministic (HD) wallet, which generates a set of different
keys and addresses from a single master seed [29]. However,in reality, VASPs use several other different types of VA
addresses which need to be taken into consideration.
• Cold Wallet: The key may not be available online.

Multisignature Wallet, Secret-Sharing Scheme Wallet andMulti-Party Computation Wallet: Consisting key or shares
may not be available simultaneously.
• Smart Contract Wallet or VAs with key update capability:
There may be no method to derive 𝑎𝑑𝑑𝑟 from cryptographic keys.
•

We will discuss the detail on each.
1) Cold Wallet: 𝑉𝑏 may keep the key corresponding to
𝑎𝑑𝑑𝑟 offline to protect against cyberattacks. This can causedelays in 𝑉𝑏 digitally signing msg. In the worst-case scenario,
the proof may need to be deferred until the withdrawal from𝑎𝑑𝑑𝑟 occurs, which is unrelated to the transfer from 𝑉𝑎 to 𝑉𝑏
and cannot be predicted. As a result, 𝑉𝑎 is unable to verify
that 𝑉𝑏 possesses 𝑎𝑑𝑑𝑟 at the time of the transfer.
As a solution, 𝑉𝑏 can generate a proof for 𝑎𝑑𝑑𝑟 in advancewhen it is initially generated in the cold wallet environment.
2) Multisignature Wallet: Bitcoin-like VAs enable a multisignature address that allows withdrawals when 𝑚 out of 𝑛
keys are used to sign the transaction [30]. A multisignatureaddress is uniquely identified by 𝑛 public keys in a particularorder and the value of 𝑚. VASPs may use multisignatureaddresses for security or backup purposes, for example, where
keys are managed individually by different officers, or someare managed offline in a secure vault.
A straightforward method for proving ownership of a multisignature address is to sign using 𝑚 keys in the same manneras signing the transaction to transfer from it. However, similar
to the case of cold wallets, not all 𝑚 keys may be accessibleat the same time, depending on how the VASPs manage them.
One possible solution is to modify the protocol so that 𝑉𝑏
signs msg with only a single key out of the 𝑛 keys. The msg
should contain a list of all 𝑛 keys. Once 𝑉𝑎 confirms thevalidity of the signature by one of the listed keys, 𝑉𝑎 candetermine that 𝑎𝑑𝑑𝑟 belongs to 𝑉𝑏 .
Yet, this solution has a caveat. Semi-custodians [31] or afew VASPs [32] allow users to import their public key forcreating a multisignature wallet. This can result in the reuseof some keys among the 𝑛 keys on different VASPs.
3) Secret-Sharing Scheme Wallet and Multi-Party Computation Wallet: A single private key can be divided into multiple(𝑛) shares with a recovery threshold (𝑚) using cryptographic
techniques. The earliest method for this is Shamir’s secretsharing [33], but more sophisticated protocols have beenstudied as well [34]–[36]. These approaches enable VASPs
to create secret-sharing scheme wallets or multi-party computation (MPC) wallets, which mimic the access control ofmultisignature addresses.
In contrast to a multisignature wallet, where a single key
among 𝑛 may be sufficient for cryptographic proof, there
is currently no general lightweight method to demonstrate
control over 𝑎𝑑𝑑𝑟 other than by actually using 𝑚 shares.
4) Smart Contract Wallet, or VAs with Key Update Capability: In some VA systems, there may not be a cryptographic
relationship between an address and its signing keys. Thismeans that an address may not have any corresponding keys,

or the set of keys associated with an address may be modified
after the address is generated.
In Ethereum, instead of a regular address called an Externally Owned Account, smart contracts can be used to manage
Ethers or ERC-20 tokens [37]. VASPs can utilize smart
contract wallets [38], [39] to simulate multisignature wallets,
aiming to increase security. These smart contract wallets have
VA addresses that are assigned programmatically based on thestate of the blockchain, and there are no cryptographic keys
that directly match these addresses.
The Flow blockchain has built-in support for modifying theaccess control list of an account, which is equivalent to an
address in the Flow [40]. While the account address is fixed,
the owner of the account can change the list of keys associatedwith it, each with a different weight. A transaction needs to besigned by a combination of registered keys that meet a weightthreshold.
These examples highlight the need for 𝑉𝑎 (or a lookup
service) to confirm the association between 𝑎𝑑𝑑𝑟 and the
public key(s) that 𝑉𝑏 claims, using the blockchain node alongwith the timestamp or the block height in msg. Additionally,
the lookup service may need to implement a mechanism tomonitor changes in the state of the blockchain to detect any
changes in 𝑎𝑑𝑑𝑟’s ownership.
VI. C HALLENGE 3: PII T RANSMISSION I NTERFACE
Assume that 𝑉𝑎 has identified 𝑉𝑏 as its counterpart for
the transfer. In order to transmit PII, 𝑉𝑎 needs to establish acommunication channel to 𝑉𝑏 . However, the specific channel
is often not known in advance. They need to agree on various
aspects of the communication, such as:• Network Connectivity: Is it over the Internet, over a VPN,
or in a closed dedicated network?
• Network Address of Each Party: Is the peer VASP resolved by DNS, or provided as an IP address and how?
• Type of Authentication and Encryption: Is it provided by
TLS, or another protocol? Who issues certificates?
• Application Layer: How is the communication done?
• Encoding: How are the messages serialized?
Figure 6 illustrates various approaches. The network security in the design of each approach is important, as cyberattacks could lead to the potential disclosure of PII.
Approach 3-A. Peer-to-Peer
The most obvious method is to agree on the communication
protocol prior to any transfers between VASPs. The transmission process can be customized for each VASP, providing aflexible solution.
For example, as depicted in the figure, 𝑉𝑎 and 𝑉𝑏 may
publish the following API endpoints:
𝑉𝑎 ) REST API at https://api.vasp-a.example/
𝑉𝑏 ) gRPC at grpc://travel.vasp-b.example/
𝑉𝑎 and 𝑉𝑏 mutually agree that 𝑉𝑎 contacts 𝑉𝑏 ’s endpoint andprotocol (gRPC) when 𝑉𝑎 transmits PII to 𝑉𝑏 , and vice versa.
They may choose to use the IVMS 101 data model over theAPI.

(3-A) Peer-to-peer relationships
Va“We host our API at:
https://api.vasp-a.example/ ”
1-to-1 legal relationship for
direct information exchangeVb(3-B) VASP directoryVa(3) Directly communicate
through resolved endpoint(2) Lookup
identiﬁed VASP“We host our API at:
grpc://travel.vasp-b.example/ ”(3-C) Alliance(1)
Register
endpoint

Vb

Va

Legal relationship(2)
Forward(1) Request
PII transmission

VASP directory(openly maintained)

Vb

Central dispatcher

Fig. 6. Possible Approaches for Inter-VASP Communication for PII Transmission

One major drawback of this approach is its lack of practicality and feasibility in requiring every pair of VASPs toestablish independent contracts with one another. Moreover,accommodating different protocols or APIs used by each
VASP would demand significant development efforts and time.
Approach 3-B. Public VASP Directory
As an alternative, an open directory can be built that any
VASPs can participate in to register their corporate name, network endpoints, jurisdictions, and other necessary information
for PII transmission.
The management of the open VASP directory is flexible,
allowing for various approaches. The directory contains information that does not require frequent updates and can becached to facilitate speedy lookups at each VASP. In combination with the (1-D) approach, we speculate the possibilityof implementing this method using DNS infrastructure as apossible extension.
1) Coverage and Accuracy: Ensuring the quality of thedirectory is crucial as it should encompass a comprehensive
list of VASPs from around the world. However, making thedirectory publicly editable without authorization presents arisk to its accuracy. This could result in incorrect information
about existing VASPs or the inclusion of fake listings withsimilar names, potentially leading to the theft of PII.
To mitigate these risks, it is advisable to restrict the editingof the directory to VASPs only, with each company having
only one record per jurisdiction. To achieve this, we proposea verification process similar to the Extended Validation used
in TLS certificates. This process would verify the authenticityof newly registered companies, ensuring that only legitimate
VASPs are included in the directory. It is also necessary to
regularly update the directory to keep it current and accurate.
2) Standardization of Protocols and APIs: The VASP directory may list various parameters, such as the endpoint
URLs for VASPs or the digital certificate to authenticate theidentity. Even then, VASPs should also consider standardizing the communication protocols. This means reaching a
consensus on protocols and APIs to ensure seamless andefficient interactions between VASPs. While the IVMS 101
message model standard has gained significant acceptance in
the industry, it is important to extend standardization to otherlayers of PII transmission protocols as well. This will promoteinteroperability and enhance the overall security and reliabilityof the directory.
Approach 3-C. Alliance of VASPs
To strike a balance between (3-A) and (3-B), VASPs thatshare a certain level of trust can form an alliance and jointly
manage the member VASP directory. This directory allows
member VASPs to easily access each other’s information forpeer-to-peer communication. Alternatively, the alliance can act
as a communication hub by providing connectivity to eachmember. By establishing a communication standard within
the alliance, VASPs can ensure efficient implementation andoperation of the Travel Rule.
The notable advantage of this approach is its high compatibility with (1-B). Since the alliance is composed of VASPs thathave already evaluated their risk profiles, a lookup service canbe operated by the alliance safely while alleviating concerns
described earlier. Furthermore, it makes sense for the allianceto provide lookup services in order to enable the identificationof suitable VASPs.
A potential downside of this approach is the issue of compatibility between different alliances. When multiple alliances
are formed, VA transfers cannot cross between the border ofdifferent alliances if they are incompatible. As a real-world
example, VASPs in Japan are virtually divided into two groups
based on the alliances they join [41]. Users are required touse an unhosted wallet to transfer between VASPs of different
alliances. A similar case is also reported in Switzerland [42].
A VASP may participate in multiple alliances to communicate with more VASPs globally, but this increases the operationand maintenance load for each alliance they join, as well as thecost they pay. This is similar to credit card merchants being
connected to multiple payment processing networks.
There are two ways to solve this issue.
1) Bridges Provided by Alliances: The first is for analliance to ensure compatibility in the architecture with otheralliances and to provide bridges which convert communication.
Due to potential architecture changes in each alliance, thisapproach may take time to implement but is feasible.
2) Intermediary VASPs: The second method is for a VASP
participating in multiple alliances to act as a gateway, similar
to a correspondent bank for international fiat currency transfers, facilitating transfers through this VASP. Although thisTABLE IIC OMPARISON OF T RAVEL RULE S OLUTIONS

)

G
RW

D
RP
ctI
pe
/T
nsa
P
sco
a
P
i
S
r
r
S
T
A
/
Ve
VA
ISA
US
enV
tki
gna
rify
yft
TR
TR
Ne
Sy
Ve
Sh
Op
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
T
US

T(

Challenge 1)
Identification of
Destination VASP
Challenge 2)
Address Ownership
Challenge 3)
PII Transmission

Approaches(1-B) Lookup service(1-C) Special identifier(1-D) Domain name(2-A) Contract-based(2-B) Providing proof(3-A) Peer-to-peer(3-B) VASP directory(3-C) Alliancemethod is simpler, there are presumably concerns regardingtransaction fees, privacy, and complexity of the solution, andno examples have been observed to our knowledge. However,we speculate that this method has the potential to be effective
for cross-chain swap DeFi; they exchange VAs across multiple
blockchains through the use of smart contracts and may bewell-suited for serving as an intermediary VASP.
VII. K NOWN T RAVEL RULE I MPLEMENTATIONS
A. Summary
We conducted a survey of multiple solutions for the Travel
Rule using publicly available information. Many of thesewere proposed and developed between 2019 and 2021, butsome also utilized technologies that existed prior to that.
Table II illustrates the summary of the comparison basedon the previously explained approaches. We outline major
observations below.
1) Dominance of Alliance-based Solutions: Among thesolutions that were surveyed, USTRWG (currently, TRUST),TRISA, Sygna Bridge, and VerifyVASP all adopt an alliancebased approach as in (3-C). Each of these solutions aims to
attract and expand the alliance by recruiting VASPs. VASPs are
subjected to a thorough due diligence process before they canjoin the alliance, ensuring their legitimacy. It is worth notingthat the establishment of these solutions was greatly facilitatedby blockchain analytics companies: Elliptic for Sygna Bridge,
Chainalysis for VerifyVASP, and CipherTrace for TRISA.
There are two solutions in the (3-A) peer-to-peer communication approach: Netki/TransactID and TRP by OpenVASP.
It is uncertain how widely these protocols are currently being
adopted by VASPs.
Lastly, the other two solutions leveraged blockchain technology, which can be categorized as the (3-B) open directorymodel: Shyft Veriscope and the Ethereum-based OpenVASP(legacy). There is limited activity on the public blockchain of
Shyft Veriscope, making it difficult to confirm its active usage.
The Ethereum-based OpenVASP solution is no longer being
maintained.

ge

d
Bri

2) Various Address Lookup Methods: We confirmed that
USTRWG and VerifyVASP offer lookup services within thealliances. Especially, VerifyVASP takes a unique approachby directly querying each VASP in the alliance for transfer
requests. Both USTRWG and VerifyVASP do not seem tomandate cryptographic proofs, taking (2-A) approach.
TRISA and Sygna Bridge actively promote the use ofblockchain analysis. As mentioned earlier, the involvement ofthese analytics companies has had an influence on this.
Early solutions like TransactID, OpenVASP, and Sygna
Bridge implemented methods using special identifiers. However, newer solutions do not actively propose the use of
special identifiers. This suggests that introducing them would
require cooperation from multiple stakeholders and can bechallenging.
B. Travel Rule Universal Solution Technology (TRUST)
formerly the U.S. Travel Rule Working Group (USTRWG)
The Travel Rule Universal Solution Technology (TRUST)[43] is a network that was established in February 2022, and it
is led by Coinbase, a U.S. virtual asset exchange. While there
is limited public information available on TRUST, official
announcements indicate that it has several key features. These
include the ability to send PII without it being centrally stored,
the mechanism for address ownership verification, and a due
diligence process for all VASPs [44]. TRUST was precededby the U.S. Travel Rule Working Group (USTRWG), which
released a whitepaper in October 2020 [45]. Since there is noclear public information available on TRUST, we will mainly
analyze the USTRWG based on their whitepaper instead.
As per the whitepaper, the system initially utilized (1A), which involved a centralized Bulletin Board where allparticipating VASPs posted their addresses. The system wasdesigned to operate on an access-controlled closed network,
isolated from the Internet. At the time of the USTRWG’s
whitepaper, (2-A) proof of address was not provided. We
believe from TRUST’s announcements that they have shiftedto (2-B), where member VASPs are required to provide proof.
As stated by the whitepaper, the transmission of PII is carriedout end-to-end through a REST API on HTTP over TLS 1.3,
on (3-C) the closed network provided by the alliance.
Here are the steps taken when a withdrawal is requested:
1) 𝑉𝑎 posts a message on the Bulletin Board regarding the
VA transfer to addr.
2) 𝑉𝑏 claims ownership of addr on the Bulletin Board.
3) 𝑉𝑎 confirms 𝑉𝑏 ’s control over addr, and initiates the VA
transfer to addr along with sending PII to 𝑉𝑏 .
There are two defects in compliance with the travel rule in
USTRWG’s specification:
1) Temporal Difference between Transmission of PII andTransfer of VAs: If 𝑉𝑏 does not claim ownership of addr in atimely manner, 𝑉𝑎 proceeds with the transfer first and sends
the PII later once addr is claimed by 𝑉𝑏 . However, the FATF
later pointed out that transactions need to be conducted before
or at the same time as the transfer. The protocol can be fixedby waiting for time 𝑇, where all participants in the network
guarantee to claim any posted address in no longer than 𝑇.
However, it is unclear whether TRUST has made this fix.
2) Lack of Support for Other Types of VAs: Initially,
USTRWG only supported Bitcoin and Ethereum transactionsin its first phase. However, the FATF pointed out that all virtual
assets are subject to the Travel Rules.
Assume TRUST has the same architecture as USTRWG’sproposal, similar observations can be made about TRUST.
C. Travel Rule Information Sharing Alliance (TRISA)The Travel Rule Information Sharing Alliance (TRISA)[46] is a platform launched on September 10, 2019, led by
CipherTrace, a U.S. blockchain analysis tool vendor. TRISA
releases a variety of information as open source.
TRISA operates as (3-C) an alliance among VASPs. Whena new VASP joins TRISA, they are required to submit aquestionnaire checklist for due diligence purposes. Once theprocess is completed, the VASP is listed on the TRISA VASP
Directory and becomes searchable.
From a technical standpoint, TRISA adopts a strict PKI
model. The alliance issues EV certificates from the Trusted
VASP CA operated by TRISA. VASPs communicate throughmessages encoded in a protocol buffer over a gRPC on anmTLS channel authenticated with the EV certificate.
While TRISA plans to implement the address lookup mechanism or ownership verification in the future, they do notcurrently provide an explicit solution and instead leave thechoice to participating VASPs. While they mention a method
such as querying the destination VASP based on the user’s
declaration or using the blockchain to record addresses asmentioned in (1-A), they seem to ultimately recommend using
blockchain analysis tools.
In August 2023, TRISA announced its completion of a proof
of concept to interoperate with OpenVASP / TRP [47] andSygna Bridge [48].
D. Sygna Bridge
Sygna Bridge [49] is a VASP alliance provided by CoolBitX, a Taiwanese blockchain security company, and Elliptic,(6) PII Transmission(bidirectional)

Enclave
Server(1) Withdrawal
request to addr

Enclave
Server(5) “Vb has addr.”(3) “Do you
have addr?”(2)
ForwardInternal
SystemVa

Originator
VASP

(4)
“Yes”

Internal
SystemVega

Vb

Beneﬁciary
VASP

Fig. 7. Architecture of VerifyVASP

a U.K blockchain analysis tool vendor. Sygna Bridge conducts
due diligence for VASPs to participate. The originator VASP
requests permission from the beneficiary VASP and initiates
the transfer only after being granted. The central server operated by Sygna Alliance, called the Bridge, plays a role inprocessing the messages, which characterizes it as a highly
centralized solution. Sygna Bridge is tightly integrated into
their compliance solution, such as user screening and riskbased transaction analysis.
When using Sygna Bridge, each VASP is assigned a unique
VASP code, and each user has an address called Virtual Asset
Account Information (VAAI), described in the extended formatof BIP 21 [50]. VAAI encodes the VA address, the VASP code,and the name of the sender.
When an originator VASP initiates a transfer using Sygna
Bridge to a VAAI, the beneficiary VASP code in the VAAI
is referenced, and the message is automatically relayed tothe counterparty VASP. Otherwise, when sending to a regular
VA address, blockchain analysis is performed to determine
which VASP it belongs to using the Wallet Address Filter API[51]. Therefore, we observe that the addresses are identified
by a hybrid method, either by lookup incorporating special
encoding or through blockchain analysis. No ownership proof
is required.
E. VerifyVASPVerifyVASP [52] is a solution co-developed by Upbit, aSouth Korean virtual asset exchange, and Chainalysis, a U.S.
blockchain analysis tool vendor. It operates as a closed alliancefor affiliated VASPs.
Figure 7 depicts its architecture. VerifyVASP provides aDocker image called Enclave Server, which runs inside each
VASP’s infrastructure. VASPs use this container as an interface
to connect to Vega, the central server of VerifyVASP. VASPs
need to establish communication between their internal systems and the Enclave Server. Vega acts as a lookup service
and a VASP directory, receiving address lookup queries fromeach VASP and providing responses along with the beneficiary
VASP’s endpoint.
The following steps outline the process when Alice requests
a withdrawal from 𝑉𝑎 to Bob on 𝑉𝑏 , with both VASPs
participating in VerifyVASP:

1) The internal system of 𝑉𝑎 calls the withdrawal request
API of the Enclave Server hosted on 𝑉𝑎 ’s infrastructure.
2) The request is forwarded to Vega.
3) Vega queries other member VASPs in the alliance todetermine the controlling VASP for 𝑎𝑑𝑑𝑟.
4) The internal system of 𝑉𝑏 responds to the callback from𝑉𝑏 ’s container, notifying the ownership of 𝑎𝑑𝑑𝑟.
5) Vega informs 𝑉𝑎 ’s Enclave Server about 𝑉𝑏 ’s ownership.
6) The Enclave Servers of 𝑉𝑎 and 𝑉𝑏 establish an end-toend encrypted communication channel to exchange PII.
In VerifyVASP, 𝑉𝑏 does not need to provide cryptographic
proof of 𝑎𝑑𝑑𝑟. Network security for each VASP and Vega isensured through IP restrictions.
Based on our investigation, VerifyVASP is unique in two
ways:• Instead of actively collecting addresses from member
VASPs, it queries the member VASP when a transfer
request is made.
• The beneficiary VASP (𝑉𝑏 ) transmits recipient information back to the originator VASP (𝑉𝑎 ). This enhances theaccuracy of PII on both ends, although it is not requiredby the travel rule.
F. Shyft Veriscope
Shyft Veriscope [53] utilizes a private Ethereum blockchain
called the Shyft Network. VASPs need to purchase dedicatedtokens (SHFT) available on the Shyft Network, which isoperated by Proof-of-Authority consensus algorithm. Shyft
Network functions as (1-A) a lookup service, (2-A) does not
require proof of address, and (3-C) operates within a limited
alliance.
Whenever there is a withdrawal request from a customer on
the originator VASP, they publish a transaction on the Shyft
Network that contains information about the transfer request.
Once the beneficiary VASP detects the transaction, it starts an
end-to-end network connection with the originator VASP topermit the transfer. The beneficiary VASP does not particularly
need to prove address ownership. Eventually, they exchange
messages in the IVMS 101 format via P2P outside the Shyft
Network.
As of September 2023, the total number of transactions on
the Shyft Network mainnet is between 10 and 20 per day
according to the official blockchain explorer [54]. The smart
contracts and documents are publicly available [55].
G. OpenVASP / Travel Rule Protocol (TRP)The Travel Rule Protocol (TRP) [56], developed by the
OpenVASP Association, aims to be a minimum set of APIsfor PII transmission. Much of the information is open source
and can be found on their GitLab.
The TRP uses a unique identifier called the Travel Address
to indicate the transfer destination. The Travel Address starts
with ta and is encoded using Base58 with the deposit URI,
as explained in (1-C). The recipient VASP assigns the Travel
Address to each user, and a sender provides it to the originator
VASP when a transfer is requested.

Here’s an example of how the TRP works:
1) Bob obtains his Travel Address addr★ from 𝑉𝑏 .
2) Alice requests a transfer to Bob by providing addr★ to𝑉𝑎 .
3) 𝑉𝑎 decodes addr★ to get the deposit URL uB , and sends
PII and a callback URL uA to uB .
4) 𝑉𝑏 either responds with an actual VA address addr or
notifies the rejection.
The Travel Address contains the beneficiary VASP’s endpoint, so the originator VASP doesn’t need to look up the
beneficiary VASP. VASPs communicate with each other using
a peer-to-peer (P2P) connection over HTTPS.
H. Other solutions
Netki originally promoted Bitcoin payment using humanreadable names [57] specified in BIP 70 [58] in 2015. TransactID aims to exchange PII outside the blockchain, as definedin BIP 75 [59], and adapted to the Travel Rule [60].
OpenVASP originally proposed a solution, before TRP, to
use the Ethereum blockchain [61]. It required VASPs to deploy
an identifying smart contract on Ethereum [62]. The users
were identified by a unique Virtual Asset Account Number,which contains the VASP code, based on the smart contract
address. VASPs communicated peer-to-peer using Ethereum
Whisper [63], which is deprecated.
Lee et al [64] suggested the solution CODE over a permissioned blockchain using Corda [65] to build a VASP alliance.
In the design, the PII is transmitted peer-to-peer over Corda’s
messaging mechanism.
VIII. O PEN C HALLENGES WITH THE T RAVEL RULE
A. Money Laundering using Unhosted Wallets
By relaying through unhosted wallets, the Travel Rulecan be bypassed. Currently, there are no effective solutions
proposed to address this issue other than restricting transfers
to and from unhosted wallets.
This problem arises from a lack of travel rule requirements involving unhosted wallets. Some concerns have beenraised that this lack of regulation may encourage criminals
to use unhosted wallets [66]. However, imposing regulations
on unhosted wallets and limiting transactions solely between
VASPs would significantly undermine the economic benefits
mentioned in Section II-A. For example, the case of Hawala,
an informal value transfer system in the Middle East, highlights the potential for underground economies and increased
complexity in AML/CFT efforts [67].
In proposing technical solutions to integrate unhosted wallets into the Travel Rule, it is crucial to prioritize the privacyof unhosted wallet owners.
B. Privacy-Preserving Proof of Address Ownership
From our investigation, we observed that many alliances
provide address lookup services. However, it is not desirablefrom a privacy perspective for the lookup service to centrallycollect addresses.

Technically, it is ideal to meet the following two requirements: (1) a beneficiary VASP registers a cryptographic
commitment to prove the possession of a secret key for addr
without showing addr, (2) only those who know addr canverify the commitment. A simple hash value of addr does notsatisfy requirement (1).
To our knowledge, there hasn’t been any proposed scheme,
even for single-key wallets in Bitcoin-like systems. We believethat the process of deriving addr from the hash value of the
public key does not align with zero-knowledge proof techniques, which poses a challenge in addressing this problem.
C. Support for Various Types of VAs
During our investigation, we discovered that most solutions
support Bitcoin and Ethereum, but the level of support varies
for other types of VAs. The reasons behind this inconsistency
were not clearly understood by the authors, whether theamount of effort required for support or any fundamental issue
related to the architecture or cryptography of blockchains inother VAs.
This issue applies to new forms of VAs, such as NFTs
and stablecoins, that have emerged since 2020. Some of thesehave a certain exchange value, and there are reports of NFTs
being used for money laundering [68]. Further research should
evaluate the compliance difficulty of ERC-20 and other tokens.
Furthermore, AECs such as Zcash and Monero are categorized as VAs according to FATF’s definition. A few VASPs
handle AECs in reality, and they are subject to Travel Rules
for AECs as well. The authors did not conduct a detailed
examination of AECs in this study, but the challenges ofmaking AECs compliant with travel rules should be analyzed
in the future.
D. Other General Issues
1) Risk Evaluation for PII Transmission: An originator
VASP must evaluate the risk of PII disclosure against abeneficiary VASP. The same applies when an originator VASP
considers joining an alliance.
Since the introduction of the travel rule, there has always
been a debate. VASPs in the European Union are subject tostrict protection of personal information under the General
Data Protection Regulation, and there are significant concerns
about sharing information outside of the EU region [69].
Similarly, in Japan, a legal amendment was made to set interVASP PII transmission as an exception to the prohibition of
PII disclosure without the originator’s consent [70], [71].
2) Shell VASPs and Money Mules: The FATF Recommendations call for member countries to legislate the issuanceof licenses to operate VASPs, and the implementation ofstrict KYC by VASPs. However, improper implementationof these measures in one country or region may decrease
the effectiveness of the Travel Rule globally, even if othercountries have stipulated the Travel Rule in their local law.
The existence of Shell VASPs is one major issue causedby the inappropriately issued license by a vulnerable country.
Such fictional financial institutions have been a major problem

in the traditional financial system, known as shell banks.
The credibility of a VASP directory or an alliance could becompromised if a fictional VASP is part of them.
In addition, the strictness of the KYC process with VASPs
is crucial. Many financial institutions, as well as VASPs, arefighting against illegal KYC attempts using forged copies
of government-issued identification documents to create fictitious accounts. Additionally, legitimately created accounts
are illegally traded over Telegram or other highly anonymized
chats. This poses a risk to economically vulnerable individuals
who can be exploited as money mules [72]. To address theseissues, it is necessary to establish and implement robust KYC
procedures, such as the use of IC chips or smart cards on
digital identification cards.
IX. C ONCLUSION
Virtual assets are becoming important financial tools alongside legal currencies, necessitating measures to prevent their
exploitation for criminal purposes. One such measure is the
FATF’s Travel Rule, which aims to prevent transfers of illicit
funds. The Travel Rule enhances AML/CFT efforts by extending CDD obligations from conventional financial institutions
to VASPs.
Unlike traditional banking networks, virtual assets pose aunique challenge. Users can simply specify a destination VA
address on a VASP for transfers, and the VASP inherently
has no way to know the address’s owner. Consequently, theneed for a lookup mechanism has been emphasized to identify
the controlling VASP of a given address. A newly generated
address should be registered with the lookup service in atimely manner, preferably with proper cryptographic proof toenhance the authenticity of registration. It is essential to ensurethat VASPs worldwide actively participate in the mechanism
for an accurate lookup, while excluding malicious entities
falsely claiming ownership of irrelevant addresses. This canbe achieved by verifying participating VASPs’ legitimacy andproviding authentication and authorization mechanisms. The
effectiveness of such a mechanism is crucial for the global
implementation of the Travel Rule.
We conducted a comprehensive review of various Travel
Rule solutions and obtained the following findings from oursurvey:• Alliance-based solutions are the most prevalent. They are
actively seeking new VASPs to join their networks.
• The methods used to identify beneficiary VASPs fromdestination addresses vary among the solutions. Some rely
on lookup services, while others encourage the use ofblockchain analysis tools.
• Although peer-to-peer and blockchain-based solutions
have been developed in the past and present, we did notobserve widespread adoption of these alternatives.
This outcome can be attributed to the efficiency and convenience of mutual due diligence and consensus on communication protocols among VASPs. However, there are concerns
regarding the potential division of the VA economy due tothe formation of multiple alliances. To address this issue,

some alliances are planning to establish bridges that facilitate
interoperability and further expand the alliance-based Travel
Rule network.
R EFERENCES[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[Online]. Available: https://bitcoin.org/bitcoin.pdf[2] G. Wood et al., “Ethereum: A secure decentralised generalised
transaction ledger,” Ethereum project yellow paper, 2014. [Online].
Available: https://ethereum.github.io/yellowpaper/paper.pdf[3] A. A. Monrat, O. Schelén, and K. Andersson, “A survey of blockchain
from the perspectives of applications, challenges, and opportunities,”
IEEE Access, vol. 7, pp. 117 134–117 151, 2019.
[4] M. Alnasaa, N. Gueorguiev, J. Honda, E. Imamoglu, P. Mauro,
K. Primus, and D. Rozhkov, “Crypto-assets, corruption, and capital
controls: Cross-country correlations,” Economics Letters, vol. 215, p.
110492, Jun. 2022.
[5] K. Kirkpatrick, “Financing the dark web,” Commun. ACM, vol. 60, no. 3,
pp. 21–22, feb 2017.
[6] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer,
and M. Virza, “Zerocash: Decentralized anonymous payments from
Bitcoin,” in 2014 IEEE Symposium on Security and Privacy, May 2014,
pp. 459–474.
[7] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza, “Succinct NonInteractive zero knowledge for a von neumann architecture,” in 23rd
USENIX Security Symposium (USENIX Security 14). San Diego, CA:
USENIX Association, Aug. 2014, pp. 781–796.
[8] S. Noether, “Ring signature confidential transactions for Monero,”
Cryptology ePrint Archive, Paper 2015/1098, 2015. [Online]. Available:
https://eprint.iacr.org/2015/1098[9] F. K. Maurer, T. Neudecker, and M. Florian, “Anonymous CoinJoin transactions with arbitrary values,” in 2017 IEEE Trustcom/BigDataSE/ICESS, Sep. 2017.
[10] R. Stütz, J. Stockinger, P. Moreno-Sanchez, B. Haslhofer, and M. Maffei,“Adoption and actual privacy of decentralized coinjoin implementations
in bitcoin,” in Proceedings of the 4th ACM Conference on Advancesin Financial Technologies, ser. AFT ’22. Association for Computing
Machinery, Sep. 2023, pp. 254–267.
[11] Southern District of New York, U.S. Attorney’s Office, “Tornado Cashfounders charged with money laundering and sanctions violations,” Aug.
2023. [Online]. Available: https://www.justice.gov/usao-sdny/pr/torna
do-cash-founders-charged-money-laundering-and-sanctions-violations[12] Elliptic, “The state of cross-chain crime,” p. 9, Oct. 2023. [Online].
Available: https://www.elliptic.co/hubfs/Elliptic\ The\ State\ of\ Cro
ss\ Chain\ Crime\ Report\ 2023.pdf[13] D. Ermilov, M. Panov, and Y. Yanovich, “Automatic bitcoin address
clustering,” in 2017 16th IEEE International Conference on Machine
Learning and Applications (ICMLA), Dec. 2017, pp. 461–466.
[14] A. Feder, N. Gandal, J. T. Hamrick, and T. Moore, “The impact of DDoS
and other security shocks on Bitcoin currency exchanges: evidence from
Mt. Gox,” Journal of Cybersecurity, vol. 3, no. 2, pp. 137–144, Jan.
2018.
[15] Office of Public Affairs, U.S. Department of Justice, “Alleged Russian
cryptocurrency money launderer extradited to United States,” Aug.
2022. [Online]. Available: https://www.justice.gov/opa/pr/alleged-russi
an-cryptocurrency-money-launderer-extradited-united-states[16] FATF, International Standards on Combating Money Laundering andthe Financing of Terrorism & Proliferation, Feb. 2012. [Online].
Available: https://www.fatf-gafi.org/recommendations.html[17] ——, Targeted Update on Implementation of the FATF Standards
on Virtual Assets/VASPs, Jun. 2023. [Online]. Available: https://www.fatf-gafi.org/content/fatf-gafi/en/publications/Fatfrecommendati
ons/targeted-update-virtualassets-vasps-2023.html[18] A. Matsuzawa, “The travel rule challenge: Virtual asset transfers versus
wire transfers,” Aspects of APAC, pp. 88–95, Oct. 2020. [Online].
Available: https://www.fsa.go.jp/frtc/kikou/2020/FSA article ACAMS
Today2020 Sept-Nov.pdf[19] Joint Working Group on interVASP Messaging Standards, “interVASP
messaging standards,” May 2020. [Online]. Available: https://www.intervasp.org/[20] ISO 20022-1:2013 - Universal financial industry message scheme.
International Organization for Standardization, May 2013. [Online].
Available: https://www.iso20022.org/[21] ISO 17442-1:2020 - Legal entity identifier (LEI). International Organization for Standardization, Aug. 2020.
[22] T. Hardjono, A. Lipton, and A. Pentland, “Wallet attestations forvirtual asset service providers and crypto-assets insurance,” May 2020.
[Online]. Available: https://arxiv.org/abs/2005.14689[23] FATF, Updated Guidance for a Risk-Based Approach to Virtual Assets
and Virtual Asset Service Providers, Oct. 2021. [Online]. Available:
https://www.fatf-gafi.org/publications/fatfrecommendations/documents/Updated-Guidance-RBA-VA-VASP.html[24] J. Lovejoy, C. Fields, M. Virza, T. Frederick, D. Urness, K. Karwaski,
A. Brownworth, and N. Narula, “A high performance payment
processing system designed for central bank digital currencies,”
Cryptology ePrint Archive, Paper 2022/163, 2022. [Online]. Available:
https://eprint.iacr.org/2022/163[25] ISO 13616-1:2020 - International bank account number (IBAN). International Organization for Standardization, Sep. 2020.
[26] ISO 9362:2022 - Banking telecommunication messages ̶ Business
identifier code (BIC). International Organization for Standardization,
Apr. 2022.
[27] K. Oosthoek and C. Doerr, “From hodl to heist: Analysis of cybersecurity threats to Bitcoin exchanges,” in 2020 IEEE International
Conference on Blockchain and Cryptocurrency (ICBC), 2020, pp. 1–9.
[28] N. Rustgi, “Balancer frontend hit by DNS attack, over $250k stolen,”Sep. 2023. [Online]. Available: https://decrypt.co/197953/balancer-fro
ntend-hit-by-dns-attack-over-250k-stolen[29] P. Wuille, “Hierarchical deterministic wallets,” Feb. 2012. [Online].
Available: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki[30] G. Andresen, “Pay to script hash,” Jan. 2012. [Online]. Available:
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki[31] Z. Jaroucheh and B. Ghaleb, “Crypto assets custody: Taxonomy, components, and open challenges,” in 2023 IEEE International Conference
on Blockchain and Cryptocurrency (ICBC), 2023, pp. 1–6.
[32] Blockchain.com, “How do I import a Bitcoin address?” [Online].
Available: https://support.blockchain.com/hc/en-us/articles/899734771
1388[33] A. Shamir, “How to share a secret,” Commun. ACM, vol. 22, no. 11,
pp. 612–613, nov 1979.
[34] R. Gennaro and S. Goldfeder, “Fast multiparty threshold ECDSA
with fast trustless setup,” in Proceedings of the 2018 ACM SIGSAC
Conference on Computer and Communications Security, ser. CCS ’18.
Association for Computing Machinery, 2018, pp. 1179–1194.
[35] Y. Lindell and A. Nof, “Fast secure multiparty ecdsa with practical
distributed key generation and applications to cryptocurrency custody,”
in Proceedings of the 2018 ACM SIGSAC Conference on Computer andCommunications Security, ser. CCS ’18. Association for Computing
Machinery, 2018, pp. 1837–1854.
[36] J. Doerner, Y. Kondi, E. Lee, and abhi shelat, “Threshold ECDSA in
three rounds,” Cryptology ePrint Archive, Paper 2023/765, May 2023.
[Online]. Available: https://eprint.iacr.org/2023/765[37] Y. Takei, Complete Guide to the Theory and Practice of NFTs (translated). Ohmsha, 5 2023.
[38] BitGo, “Ethereum multisig wallet contract.” [Online]. Available:
https://github.com/BitGo/eth-multisig-v4[39] Safe Ecosystem Foundation, “Safe contracts.” [Online]. Available:
https://github.com/safe-global/safe-contracts[40] R. M. Seraj, “Flow’s account model offers real ownership to users,”
Feb. 2023. [Online]. Available: https://flow.com/post/flow-blockchain-n
ews-analysis-ownership-account-model[41] CoinDesk Japan, “Impact of the travel rule on crypto asset
exchanges on remittances, disadvantages, and the response ofeach domestic exchange,” Jul. 2023. [Online]. Available: https://www.coindeskjapan.com/learn/travel-rule/[42] K. L. Heller and A. Fromm, “The travel rule and its impact on
cryptocurrency: A simple explanation of differences between fatf andthe swiss approach published by finma,” Jan. 2021. [Online]. Available:
https://lexcellence.swiss/en/travel-rule-and-its-impact-cryptocurrency-s
imple-explanation-differences-between-fatf-and-swiss[43] Coinbase, “Travel rule universal solution technology (TRUST).”[Online]. Available: https://www.coinbase.com/travelrule[44] TRUST, “Introducing the travel rule universal solution technology(“TRUST”),” Feb. 2022. [Online]. Available: https://www.coinbase.com/blog/introducing-the-travel-rule-universal-solution-technology-trust[45] USTRWG, “Travel rule solution white paper version 1.0,” Oct. 2020.
[Online]. Available: https://web.archive.org/web/20201101123224/https://www.gdf.io/wp-content/uploads/2020/10/USTRWG-Travel-Rule-Sol
ution-V1.pdf[46] D. Jevans, T. Hardjono, J. Vink, F. Steegmans, J. Jefferies, A. Malhotra,
and the TRISA Technical Subcommittee, “Whitepaper version 9,” Feb.
2022. [Online]. Available: https://trisa.io/trisa-whitepaper/[47] TRISA, “TRISA-OpenVASP/ TRP Demonstrate Interoperability,” Aug.
2023. [Online]. Available: https://trisa.io/trisa-trp-interoperability/[48] Sygna, “Trisa and sygna announce interoperability to simplify global
travel rule compliance.” [Online]. Available: https://www.sygna.io/blog/
trisa-sygna-coolbitx-announce-fatf-travel-rule-solution-interoperability/[49] CoolBitX and Elliptic, “Sygna bridge.” [Online]. Available: https://www.sygna.io/bridge/[50] N. Schneider and M. Corallo, “URI scheme,” Jan. 2012. [Online].
Available: https://github.com/bitcoin/bips/blob/master/bip-0021.mediaw
iki[51] Sygna, “Bridge/wallet address filter.” [Online]. Available: https://developers.sygna.io/reference/bridgewallet-address-filter[52] VerifyVASP. [Online]. Available: https://docs.verifyvasp.com/[53] Shyft, “Veriscope Docs.” [Online]. Available: https://docs.veriscope.net
work/[54] ——, “Poa explorer (mainnet).” [Online]. Available: https://bx.shyft.net
work/[55] ——, “Veriscope docs.” [Online]. Available: https://docs.veriscope.net
work/[56] OpenVASP Association, “Travel rule protocol (TRP),” Dec. 2020.
[Online]. Available: https://gitlab.com/OpenVASP/travel-rule-protocol/-/blob/master/core/specification.md[57] Netki, “Netki wallet name service.” [Online]. Available: https://www.youtube.com/watch?v=gunA1zBnEcs[58] G. Andresen and M. Hearn, “Payment protocol,” Jul. 2013. [Online].
Available: https://github.com/bitcoin/bips/blob/master/bip-0070.mediaw
iki[59] J. Newton, M. David, A. Voisine, and J. MacWhyte, “Out of band
address exchange using payment protocol encryption,” Nov. 2015.
[Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-007
5.mediawiki[60] N. DiCamillo, “Netki retools digital ID service for FATF’s new crypto’travel rule’.” [Online]. Available: https://www.coindesk.com/business/
2019/09/09/netki-retools-digital-id-service-for-fatfs-new-crypto-travel-rule/[61] D. Riegelnig and Bitcoin Suisse, “OpenVASP: An open protocol to
implement FATF’s travel rule for virtual assets,” Nov. 2019. [Online].
Available: https://www.crowdfundinsider.com/wp-content/uploads/201
9/11/OpenVasp Whitepaper-Nov-2019.pdf[62] OpenVASP Association, “OpenVASP contracts,” Apr. 2020. [Online].
Available: https://github.com/OpenVASP/openvasp-contracts/tree/1.0[63] Ethereum community, “Ethereum whisper archive.” [Online]. Available:
https://github.com/ethereum/whisper[64] C. Lee, C. Kang, W. Choi, M. Cha, J. Woo, and J. Hong, “CODE:
Blockchain-based travel rule compliance system,” in 2022 IEEE International Conference on Blockchain (Blockchain), Aug. 2022, pp. 222–
229.
[65] R. G. Brown, “The Corda platform: An introduction,” May 2018.
[Online]. Available: https://www.corda.net/content/corda-platform-whi
tepaper.pdf[66] His Majesty’s Treasury, “Response to the consultation,” p. 28, Oct.
2020, paragraph 6.21. [Online]. Available: https://assets.publishing.serv
ice.gov.uk/government/uploads/system/uploads/attachment data/file/10
83351/MLRs SI 2022 - Consultation Response final.pdf[67] F. M. J. Teichmann and C. Wittmann, “Challenges resulting from hawalabanking for anti-money laundering and anti-terrorist financing policiesof swiss banks,” Journal of Money Laundering Control, 2022.
[68] FATF, Money Laundering and Terrorist Financing in the Art
and Antiquities Market, Feb. 2023. [Online]. Available: https://www.fatf-gafi.org/publications/Methodsandtrends/Money-Laundering-Terrorist-Financing-ArtAntiquities-Market.html[69] S. B. Neagu, “A sharp turn towards crypto-surveillance: Analyzing
implications of the EU’s revised transfer of funds regulation,” Jul.
2022. [Online]. Available: https://law.stanford.edu/publications/no-64-a-sharp-turn-towards-crypto-surveillance-analyzing-implications-of-the-eus-revised-transfer-of-funds-regulation/[70] Japan Financial Services Agency, Publication of the Draft Cabinet
Order for Partial Revision of the Order for Enforcement of the Act on
Prevention of Transfer of Criminal Proceeds (translated), Feb. 2023.
[Online]. Available: https://www.fsa.go.jp/news/r4/sonota/20230203-2/2
0230203-2.html[71] Nikkei, Japan cryptocurrency transfer rules take aim at money
laundering, Sep. 2022. [Online]. Available: https://asia.nikkei.com/Spotlight/Cryptocurrencies/Japan-cryptocurrency-transfer-rules-take-aim-at-money-laundering[72] M. S. Raza, Q. Zhan, and S. Rubab, “Role of money mules in money
laundering and financial crimes a discussion through case studies,”
Journal of Financial Crime, vol. 27, pp. 911–931, 2020.
[73] Reuters, “South Korean intelligence says N. Korean hackers possibly
behind Coincheck heist,” Feb. 2018. [Online]. Available: https://reut.rs/2BI6Oh1[74] K. Ji-Young, L. Jong In, and K. Kyoung Gon, “The all-purpose sword:
North Korea’s cyber operations and strategies,” in 2019 11th International Conference on Cyber Conflict (CyCon), vol. 900, 2019, pp. 1–20.

A PPENDIX
A. List of FATF Vocabulary Abbreviations
Table III illustrates the list of abbreviations from the FATF
vocabulary used in this paper, in alphabetical order.
TABLE IIIL IST OF FATF VOCABULARY A BBREVIATIONS
AML
CDD
CFT
FATF
FSRB
KYC
STR
VA
VASP

Anti-Money Laundering
Customer Due Diligence
Combating the Financing of Terrorism
Financial Action Task Force
FATF-Style Regional Bodies
Know Your Customer
Suspicious Transaction Report
Virtual Asset
Virtual Asset Service Provider

B. History of Travel Rule
The original Travel Rule is defined by the Bank Secrecy
Act (31 CFR 103.33(g)) in the United States in 1996. The
stipulation was incorporated into the FATF Recommendationsin 2001 as Special Recommendation VII (Wire transfers). It
became mandatory for international banking transactions by
December 2006.
In 2012, the FATF entirely revised the recommendations.
The Travel Rule was renumbered as Recommendation 16.
While the Bitcoin blockchain had started in 2009, the thencurrent version did not yet consider virtual asset technology.
In 2017, Bitcoin experienced price inflation of about 20
times, gaining public attention, followed by a massive Nem
theft in a Japanese exchange in January 2018. This incident
was suspected of being a state-backed cyber attack by North
Korea [73], [74], which has been listed on the FATF blacklist
since 2012.
In response to these social movements, in October 2018,
the FATF defined the terms VA and VASP and amended
Recommendation 15 (New technologies). The Interpretation
Note to Recommendation 15, which provides supplementary
practical information, was amended in 2019. Upon this, theFATF asked each country to legislate so that VASPs must
be regulated with licenses as well as expand the Travel Rule
obligation to virtual assets.

The FATF set a 12-month grace period for preparation,
which was later adjusted with another 12-month window
until mid-2021 based on feedback from the industry. Most
recently, in April 2023, the FATF’s Virtual Assets Contact
Group (VACG) meeting, which the author of this paper also
attended, was held to facilitate dialogue among the FATF,
participant jurisdictions, and the private sector. The progressof the Travel Rule implementation was reported during themeeting. The regulation plans against NFTs or other means ofvirtual assets were also discussed.