Travel Rule Information Sharing Architecture for Virtual Asset Service Providers

The Travel Rule Information Sharing Architecture (TRISA) was initiated in July 2019 as a response to emerging regulations from the FATF and FinCEN around data transfer for cryptocurrency transactions between Virtual Asset Service Providers (VASPs). The goal of TRISA is to enable compliance with the FATF and FinCEN Travel Rules, as well as Travel Rules implemented by equivalent (non-US) competent authorities for cryptocurrency transaction identity information without modifying the core blockchain protocols, and without incurring increased transaction costs or modifying virtual currency peer-to-peer transaction flows. TRISA aims to do this on a global level while:

Protecting user privacy
Ensuring fast and inexpensive transactions
Remaining open source and decentralized
Having an open governance body
Maintaining interoperability with other approaches

In June 2019 the Financial Action Task Force (FATF) proposed global rules regarding the sharing of beneficiary and originator information between Virtual Asset Service Providers (VASPs), inspired by regulation from the Financial Crimes Enforcement Network (FinCEN) in the US. Entities subject to these regulations are cryptocurrency exchanges, custodial wallets, DEX operators, and others depending on the interpretation of regulations in each jurisdiction.

This whitepaper proposes a peer-to-peer mechanism for complying with these regulations, with minimal cost impact to participants, and with consideration for preserving high performance transaction processing by cryptocurrency virtual asset service providers.

2.1 FATF Funds Travel Rule

In June 2019, the Financial Action Task Force (FATF)—an international money-laundering watchdog organization based in Paris—released clarification to its guidance to member nations regarding the regulation of VASPs and other crypto entities. In response to the increasing use of virtual assets for money laundering and terrorist financing, the updated guidance included a “Travel Rule.” This rule requires VASPs to share sender (originator) and receiver (beneficiary) information for cryptocurrency transactions. This is similar to so-called Travel Rules that have for years required financial institutions to share this information when executing bank wire transfers and SWIFT electronic funds transfers.

At the close of a summit on June 29, 2019, finance ministers and central bankers of the G20 economic bloc formally announced their support for FATF’s updated cryptocurrency guidelines, which include the Travel Rule. The G20 member countries have now rapidly begun the process of translating the Travel Rule into their respective local laws.

2.2 BSA Travel Rule – 31 CFR 103.33(g)

The Bank Secrecy Act (BSA) established a Funds Travel Rule for fiat currency transfers in the US in 1996. An amendment to the BSA in 2012 expanded the Rule to include electronic funds transfers. FinCEN is charged with enforcing BSA rules, and in May 2019 released guidance that the US Department of Treasury would classify many cryptocurrency exchanges as money service businesses (MSBs), meaning exchanges operating within the United States must now comply with the BSA Travel Rule. According to the rule, any time a transfer of funds is greater than or equal to $3,000, financial institutions must include the following in the transmittal order: the name, account details, and financial institution of the recipient and the transmitter. The regulation’s text does not dictate exactly how financial institutions must collect, verify or transfer this information.

2.3 The Solution: Modify Blockchains or Add an Overlay Layer?

The goal of the Travel Rule Information Sharing Architecture (TRISA) is to enable compliance with the FATF and FinCEN Travel Rules for transaction identity information without modifying the core blockchain and cryptocurrency protocols. Trying to modify these protocols is bound to fail, as there are many different protocols, and forcing hard forks is simply not feasible. A better option involves creating a separate out-of-band mechanism to augment existing blockchains and cryptocurrencies for compliance purposes.

This whitepaper describes a peer-to-peer mechanism for VASPs to comply with the respective Funds Travel Rule for transaction identification exchange between originators and beneficiaries.

2.4 What the FATF Travel Rule Requires VASPs to Retain and Share

The FATF guidelines require both sending and receiving VASPs to exchange and store originator and beneficiary identification information in addition to the cryptocurrency addresses and transaction ID for each transaction. Regulators require the latter since cryptocurrency addresses can be used by multiple beneficiary customers. For example, some exchanges use a single address to send all transactions. Also, cryptocurrency addresses can be recycled and consequently may be used by multiple customers at a VASP.

3. Applying the Certificate Authority Model to Reliably Identify and Verify VASPs

The FATF rule creates a technical challenge for VASPs—how to comply with the requirement to exchange information while still protecting user privacy. The solution requires the equivalent of a certificate authority (CA) that verifies the identity of VASPs and serves as a dictionary for their public key certificates so that they can be identified and establish secure communications between peer VASPs.

Figure 1: Mutual Authentication with X.509 Certificates and a Certificate Authority

Receiving VASPs should return receipts, ideally digitally signed, to sending VASPs to confirm that the transaction identity information has been received. It is desirable to be able to reject a transaction in a receipt, for example if the sender’s identity or purported beneficiary’s identity data fails sanctions or other blocking tests by the receiving VASP. In such cases, the sending VASP should not proceed with the blockchain transaction and should notify the originator of a failed transaction. This enhanced validation standard is known as Extended Validation Know Your VASP (EV KYV). See Figure 1.

In a CA model, one or more third parties verify the identity of a VASP through a number of steps such as email identification, domain name ownership identification, phone call verification, and business paperwork verification. The CA can then issue a digital certificate signed by the CA and the VASP to serve as identification and a way to establish secure encrypted communications with the verified VASP (Figure 2). These certificates should have an expiration date. They should also be subject to revocation by the CA through an Online Certificate Status Protocol (OCSP) mechanism or revocation list.

Figure 2: A validated certificate X.509 from a certificate authority (CA) protects communications between two VASPs by encrypting the connection between them. In this model, a VASP applies for certification through a registered VASP CA. The CA would then verify that all legal requirements have been met before the VASP can send a certificate signing request (CSR) and the TVASP CA (Trusted VASP Certificate Authority) can produce the signed certificate.

Another approach might be to use a mechanism similar to DomainKeys Identified Mail (DKIM) whereby public keys and configuration information regarding where to connect to the transaction identity services are published in the DNS records of VASPs. A problem with this approach, however, is that many VASPs operate multiple domain names for different services, sometimes in different jurisdictions. The CA model provides more oversight and simplification; however, it does require one or more trusted third parties to operate the verification, issuance, and revocation of certificates.

In web connections, the CA is the cornerstone of trust for public key infrastructure (PKI), issuing trusted digital certificates and managing, distributing, and revoking these certificates. The CA works by using two different cryptographic keys: a public key and a private key. In a TLS interaction, for example, the public key is available to any user that connects with the website. The private key—a unique key generated when a connection is made—remains secret. When communicating, the client app or browser uses the public key to encrypt and decrypt data, while the server uses the private key. This match-up of keys enables the sending and receiving machines to establish a secure connection, which protects users’ information from theft or tampering. In addition, since the CA issues digital certificates that associate an entity with a given public key, this approach ensures users interact with the intended party, not an imposter.

The CA model is one that has been developed and used by the Internet for over 20 years. The model has been successfully used to establish trust across untrusted networks and facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking, and government communications. It provides proven and well-established trust models, audit procedures, issuance, and revocation mechanisms.

4. Global VASP Directory and TRISA Certificate Authority Enables Trusted Information Sharing

When a VASP wishes to send transaction originator and beneficiary information to another VASP in support of Travel Rule requirements, they must establish secure communication with the other VASP. One way to do this is to identify the VASP, obtain its trusted certificate, communications address and port, and then establish an SSL/TLS secure connection directly to the receiving VASP. This is similar to the way that browsers connect securely to web servers.

4.1 Discovery and Mutual Authentication TRISA VASP Directory

The TRISA Global Directory Service enables VASPs to look up the VASP name, jurisdiction, contact information and physical address details. VASPs that wish to become part of the TRISA Alliance will submit required information to the Global Directory Service and upon review and approval, be granted certificates and access to the Directory. The Global Directory can be used by VASPs to determine if the counterparty is a VASP and if that VASP is in a jurisdiction that enforces travel rule legislation, thus allowing Alliance members to make informed compliance decisions before sending or receiving large sums of virtual assets. The Global Directory will be augmented with:

Additional entity details
Regulator/licensing information
Privacy information
Travel rule sharing end-point and protocols registered VASPs.

For VASPs that are part of the TRISA Alliance, the directory will also include legal identifiers, privacy protections, and relevant KYC and AML factors from the TRIXA questionnaire. The purpose of the TRIXA questionnaire, developed in collaboration with GDA, is to provide a common set of questions VASPs can ask other VASPs with whom they are planning to exchange Travel Rule information.

The Global Directory will include entity detail information such as legal name, doing business as (dba) name, legal and primary business address, incorporation number and legal entity identifier. It will name the entity’s primary financial regulator and list of licensed jurisdictions. It will provide information on the VASP’s Customer Due Diligence (CDD) processes, Know Your Customer (KYC) thresholds and PII protections. Importantly, it will help each VASP understand the counterparties’ data protections, legal requirements to safeguard PII, and external security validations. The directory will include Travel Rule specifics, including compliance requirements, contact information and technical details.

Figure 3: Implementing Enhanced Validation Know Your VASP (EV KYV)

The directory will be distributed to eliminate the risks associated with centralized directories. The TRISA VASP Directory will store the public key of the VASPs so they can mutually authenticate by verifying the signature on the account discovery request. The directory schema is extensible to support alternative trust for models or authentication including vetted Ethereum keys and self-signed certificates.

4.2 Verifying VASP Identities

TRISA will support multiple levels of VASP verification for issuance of X.509 certificates from the TRISA Certificate authority. For the MVP, email validation will be sufficient to demonstrate control. Domain Certificates will be issued to VASPs that can demonstrate control of that domain name, providing higher levels of trust.

Extended Verification SSL (EV SSL) certificates provide an additional layer of trust for web communications beyond that provided by standard SSL certificates. Similar to the way in which an EV SSL Certificate authenticates a website and the entity controlling the website, an EV KYV Certificate contains the following required fields, which are validated by a trusted third party:

4.3 Required VASP Identity Fields

Subject Organization Name – Must contain the full legal name of the entity
Registration Number – The unique Registration Number assigned by the Incorporating Agency in the Jurisdiction of Incorporation
Address of Place of Business – Must contain the address of the physical location for the Subject. City, state, and country information are required
Business Category – Must contain one of the following strings: “Private Organization,” “Government Entity,” “Business Entity,” or “Non-Commercial Entity”
Subject Jurisdiction of Incorporation or Registration – The Jurisdiction of Incorporation or Registration
Domain name – Must contain one or more host domain name(s) owned or controlled by the Subject for association with the Subject’s publicly accessible server

Mutual authentication can be facilitated over the connection protocol by the originating VASP providing their identification certificate to the receiving VASP, which is then verified during the secure communication session establishment and checked for revocation status. In this way, both VASPs are certain the counterparty on the other end of the connection is trusted.

4.4 VASP Verification Questionnaire: TRIXO

The biggest challenges in developing and maintaining a global VASP network is the ability to (1) reference and validate VASPs and (2) identify which protocols each VASP supports. The initial validation of a VASP must include verification of business identity, regulatory jurisdiction, control over URLs and email addresses, and risk ratings. VASP validation must also be available on an ongoing, real-time basis to notify members when a VASP has lost its certification as a regulated entity, as well as theft and fraud incidents.

The TRISA working group has worked with the GDF (Global Digital Finance) working group and VASPs to develop a VASP verification questionnaire that can be used across various protocols and technical implementations.

The TRIXO VASP questionnaire includes the fields shown in Figure 4.

Figure 4: The TRIXO Questionnaire

5. A Standard Process for Verifying VASPs and a Global Directory

5.1 TRISA Certificate Authority

TRISA operates a hosted certificate authority (CA) which issues certificates to VASPs to authenticate each other. The TRISA CA will issue X.509 test certificates to enable authentication interoperability among VASPs. These certificates will first be issued to TRISA members.

The root certificate from the TRISA Certificate Authority is embedded in the TRISA source code and will ensure that only instances with valid certificates can interact with other valid instances. This will deliver one-way authentication during interoperability testing for both the sending and receiving VASPs. The sending and receiving VASPs will also be able to validate that the counterparty VASP is part of the TRISA community.

5.2 VASP Identity Certificates

One of the key requirements for the establishment of secure messaging between two VASP entities is the correct identification of the endpoints of the corresponding VASPs. Although a VASP may possess a private-public key pair used to establish a secure channel (e.g. SSL/TLS session) with another VASP, the possession of the private key itself is insufficient to prove that the VASP is in fact connecting to the entity with which it seeks to transact. A secure channel is needed when transferring customer information as mandated by the Travel Rule.

Figure 5: Use of Digital Certificate to Identity VASPs during Secure Channel establishment.

The purpose of Identity Certificates is to provide unambiguous binding between a public key and the entity which (legally) owns the private-public key pair. The most common format for digital certificates is the X.509 Standard (ISO9594 [1]). A digital certificate that carries a copy of the public key of the subject (i.e. the VASP or entity being issued the certificate), as well as other standard fields. The certificate itself is issued (signed) by a certificate authority (CA) [2,3].

5.3 Extended Validation Certificates

For entities requiring additional business-related information not included in the base X.509 digital certificate, extended validation (EV) certificates can be used to obtain, validate, and represent additional relevant information. These certificates are typically issued to subjects (entities) who are legal entities (versus individual persons) and are subject to verification by the certificate issuer.

The purposes of extended validation (EV) of subjects (entities) are:

Identification of the entity (subject) that controls a given domain (i.e. website): Provide assurance to the end user that the entity controlling a domain website (e.g. merchant) is a true legal entity. This task involves incorporating various legal information into the EV certificate (e.g. business name & address, LEI number, etc.).
Assurance of the endpoint for SSL communications: Provide assurance that an endpoint is the correct endpoint in an SSL secure channel establishment, which involves performing a standard key-exchange handshake using the X.509 certificate bound to that endpoint.

The TRISA community will define a certificate profile for EV certificates for VASPs.

5.4 Identity Certificates for VASPs with Extended Validation

For Virtual Asset Service Providers (VASPs) there are at least two basic needs for EV certificates:

(a) VASP-to-VASP messaging protection: When an originator-VASP transmits messages (e.g. off-chain) to a beneficiary-VASP, these messages must be signed (for source authenticity) and must be delivered over a secure channel. To ensure that each VASP obtains assurance that the destination VASP is the correct legal entity, EV certificates can be employed by both VASPs. Here the intended consumer of the business information (contained in the EV certificate) are VASPs themselves.

(b) VASP identification for customers using browser and wallet connections: The second requirement for EV certificates for VASPs follows the classic usage of EV certificates—namely to enable customers using a browser or a wallet to know that he or she is connecting to the desired VASP.

There are a number of benefits from this configuration based on a common TRISA certification authority. Some of the benefits include:

Certificate issuance based on a common legal framework: As a certification authority, the TRISA organization will publish a Certification Practices Statement (CPS) document, which is a form of legal service-level agreement by which all TRISA members must abide. This process allows VASPs to develop their respective business models based on a common set of certificate processing procedures (the “plumbing’’), thereby allowing VASPs to focus on the higher-layer aspects of their business where revenue can be found.
Efficient VASP certificate-status check: On the operational side, by sharing a Root CA a VASP can very quickly and efficiently validate the status of the certificate of another VASP. This allows a secure channel between VASPs on the messaging network to be established, allowing VASPs to quickly exchange customer information as required by the Travel Rule.
Scalability through bridging with other VASP jurisdictions: When different communities of VASPs in different jurisdictions observe the Travel Rule, there are often additional constraints implemented by the local regulations in their respective jurisdictions. When each community employs a certificate-hierarchy based in an organizational Root CA, the communities can establish a shared bridge across the two Root CAs, allowing VASPs in their respective communities and jurisdictions to quickly and efficiently cross-validate the status of other VASPs.
VASP-to-VASP messaging protection: When an originator VASP transmits messages (e.g. off-chain) to a beneficiary VASP, these messages must be signed (for source authenticity) and must be delivered over a secure channel. To ensure that each VASP obtains assurance that the beneficiary VASP is the correct legal entity, EV certificates can be employed by both VASPs. Here the intended consumer of the business information (contained in the EV certificate) are VASPs themselves.
VASP identification for customers using browser and wallet connections: The second requirement for EV certificates for VASPs follows the classic usage of EV certificates—namely to enable customers using a browser or a wallet to know that he or she is connecting to the desired VASP.

This family of certificates is referred to as VASP Identity Certificates, which are issued by the TRISA organization.

5.5 Transactions Signing Certificates for VASPs

In various circumstances, VASPs may transmit ledger transactions to the blockchain which are signed using a key pair controlled by the VASP (i.e. the VASP is the audience).

To maintain strong security practices, it is beneficial to use different private-public keys for the identification of entities (e.g. the Identity Certificates described in the above section) from that of transactional digital signatures of the entity (e.g. signing documents, contracts, etc.).

For VASPs, this second type of private-public keys are referred to as transaction signing keys, and the corresponding certificates are transaction signing-key certificates. The sole purpose of this certificate is to certify the ownership of the private-public keys owned by the VASP.

A given VASP may own multiple transaction signing keys and multiple signing-key certificates for different audiences or use cases.

For TRISA, this standard practice has been adopted to secure data both in flight and at rest in a “secure envelope”. In a compliance information transfer, the transactional digital signature keys are referred to as Envelope Seals, and it is strongly suggested that they be different from the Identity Certificates issued to VASPs when they join the TRISA Global Directory.

5.6 Certificate Hierarchy for TRISA

By acting as a common industry organization, TRISA streamlines the validation of identity certificates between VASPs. Similar to the Browsers/SSL community and the Cable Modem industry, the TRISA organization acts as the certification authority (CA) for the certificates issued in the VASP messaging network. This is shown in figure 6, where TRISA becomes the Root-CA for the certificates issued to all VASPs in the TRISA organization.

Figure 6: TRISA Certificate Hierarchy for VASP Identity EV-Certs and Signing-Key Certificates.

5.7 TRISA Certificate Profile and CA Certificate Practices Statement

In order to ensure a high degree of interoperability among a community of users (i.e. VASPs), typically a Certificate Profile for the community is defined. The profile defines the base aspects of the certificate that the community agrees to employ (e.g. cipher type, hash function, format of timestamp, etc.).

For Certificate Authorities (CA) who wish to legally issue certificates conforming to one or more certificate profiles, the CA must publish a Certificate Practices Statement (CPS) document. A CPS is a formal statement that explains the methods and practices a CA employs in the issuance, suspension, revocation, and renewal of certificates and the provision of access to them, in accordance with specific requirements (i.e., requirements specified in this Certificate Policy, or requirements specified in a contract for services) [4,5].

We anticipate that Certificate Authorities within TRISA will publish a CPS document, including for X.509 EV certificates and signing-key certificates used within the TRISA network.

5.8 TRISA Business Information for VASP EV Certificates

For a VASP, an Extended Validation (EV) SSL Certificate authenticates the VASP’s website (by domain name), the VASP connection endpoints, and the VASP entity controlling the website.

Under TRISA, the EV Certificate for VASPs (referred to as the Subject) includes the following required fields [6]:

VASP Organization Name: The Organization field must contain the full legal name of the entity controlling the VASP website as listed in the official records in the VASP’s Jurisdiction or as otherwise verified by the CA according to the TRISA EV Guidelines.
VASP Country Code: The Country field must contain the ISO-3166-1 Alpha-2 country code of the entity as listed in the official records in the VASP’s Jurisdiction.

6. The TRISA Transfer Protocol

The TRISA transfer protocol enables the peer-to-peer exchange of compliance information over a mutually authenticated connection so that the identity of both the sender and the recipient can be verified. The protocol contains methods for unary and streaming information exchanges as well as helper functions for key exchange and address confirmation to facilitate the secure transfer of PII information. The protocol itself is designed to be flexible, adaptable to regulatory changes, the needs of different types of VASPs, and future proofing for tomorrow’s technology.

The goal of a TRISA information transfer is to synchronize compliance information such that both the originator and the beneficiary VASPs can cryptographically prove they have identical compliance information for a specific transaction. The sending VASP encrypts and digitally signs the compliance payload along with a timestamp of when the compliance information is sent. The receiving VASP will verify the payload and add the timestamp of receipt, re-encrypting and digitally signing the payload, echoing it back to the sender. At the end of the information transfer, both parties will have an identical payload and digital signature that they will store for the duration of regulatory compliance.

This section describes the transfer protocol at a high level as well as issues and considerations for TRISA implementers joining the network.

6.1 Reliable Communications Between VASPs

In the case where peer-to-peer communication of transaction identity information is used to satisfy Travel Rule requirements, it is essential that communication between VASPs be reliable. To that end, sending VASPs must ensure that their systems can reliably re-try and resend information if the receiving party’s servers are unreachable, or they do not receive a response. On the other end, receiving VASPs must ensure that their systems are online and available to handle and respond to information exchanges.

Reliable communication is essential to ensure that both counterparties can conduct virtual asset transactions on the chain in a timely manner. The FATF Travel Rule requires senders to wait to conduct a transaction until a complete compliance exchange has been concluded. Similarly, receivers should not should not make funds available to a beneficiary until the transaction identity information is received from the sending VASP. This brings up the challenge of the receiving VASP determining if an inbound transaction is from a VASP or from an individual private wallet, which is not required to provide transaction identification information under the FATF Travel Rule and is discussed further in Section 6.4.

6.2 Protocol

The protocol for sending transaction identity information should be:

Determine how to connect to the Beneficiary VASP using the Global Directory Service.
Establish a secure, mutually authenticated TLS connection between the VASPs to assure privacy of data in transit.
Originator VASP sends a PII information transfer request to the Beneficiary VASP in a secure envelope with a unique message identifier.
Beneficiary VASP verifies counterparty PII information (and may update it as necessary) and returns a signed secure envelope with the receipt timestamp using the same message identifier.
Once the Originator VASP has confirmed all required compliance information has been correctly received, Originator VASP posts a transaction to the blockchain.
If necessary, Originator VASP updates the transaction payload in the secure envelope with the transaction ID, signs it and sends it to the Beneficiary VASP using the same envelope ID.
The Beneficiary VASP updates the receipt timestamp, signs and returns the secure envelope using the same envelope ID.
At this point the Originator and Beneficiary VASPs have identical encrypted and digitally signed payloads for a completed transaction on the blockchain; both VASPs should maintain this information on durable long term storage for the compliance period.

Figure 7: Communication between exchanges begins when the originating exchange establishes a secure connection through CA.

The diagram in Figure 7 demonstrates how mutual authentication can be facilitated over the connection protocol as the Originator VASPs (here called “Alice’s VASP” as a real-world example) also provides their identification certificate to the destination exchange (here Bob’s VASP). Once a secure connection is established, the Originating VASP can then initiate the virtual asset transfer to the Beneficiary VASP along with the information required under the Travel Rule. To prove it has received the data, the Destination VASP sends a time-stamped and digitally signed receipt that includes the hash of the identity information that was sent. The Originator VASP must keep this information to meet its record-keeping obligations under FATF recommendations.

6.2.1 Connection Optimization

Because establishing a new SSL/TLS mutually authenticated session between VASPs for every single transaction could prove to be overly costly in computation for key exchange and session establishment, it is acceptable to keep a connection open and exchange data for multiple transactions over a single connection. This is similar to how a browser keeps HTTPS web connections open for accessing multiple web pages in a single connection with a web server.

The v1beta1 implementation of the TRISA protocol uses the gRPC library to establish secure communication. gRPC includes a bidirectional streaming mode that allows long running connections with high throughput messaging between nodes. This mode is optional in TRISA but can be used to support batch messaging and increase the performance of TRISA messaging.

6.2.2 Provision for Batch Processing

Many VASPs—primarily exchanges who have large daily transaction volumes—are looking to retrofit Travel Rule compliance onto existing cryptocurrency transaction flows. The idea is to support batch transaction processing at the end of a day of trading and transactions. Batch processing can be done without impacting the Straight Through Processing (STP) of existing VASP data processing and transaction processing pipelines.

For example, some VASPs have optimized blockchain transactions to group 50-200 payments in a single blockchain transaction, which dramatically reduces transaction costs. VASPs can use TRISA to batch the originator and recipient data and not interrupt their existing optimized payment flows. However, there are two issues with this approach that are not solved in this version of the TRISA whitepaper:

Funds availability: According to FinCEN, batch processing is acceptable, but funds received cannot be delivered to the recipient until the corresponding originator information has been provided and scanned for sanctions and risk compliance. This requirement can delay the availability of inbound cryptocurrency payments to customers for many hours.
Transaction finality: FATF, FinCEN and other guidance and regulation allows VASPs to process private transactions without Travel Rule compliance. VASP-to-VASP transactions, however, must send originator and beneficiary information. This requirement raises the problem of how a VASP is to know that an outbound or inbound blockchain transaction is from a private wallet, or from another VASP. In a world of batch processing, there is no current solution for a VASP to determine if a payment inbound or outbound is to or from a private wallet in a deterministic fashion. This limitation argues for real-time address detection. The TRISA community is still researching this issue. Perhaps timeouts (24 hours, for example) will suffice. Otherwise a real-time verification and processing model is preferred, as this solution preserves one of the most valued capacities of cryptocurrencies—near real-time transfer of funds globally with provable receipt of said funds.

6.2.3 Provision for Asynchronous Transfers

When a Beneficiary VASP receives Travel Rule transfer information from the Originating VASP through the TRISA protocol it may not always be able to respond immediately with any needed corrections or fill in for the missing/incorrect Beneficiary information provided. Thus the Beneficiary VASP should be able to respond back, at a later time, with the correct beneficiary information or provide errors if appropriate e.g. the beneficiary address is not owned by the Beneficiary VASP.

The Beneficiary VASP will return a control flow response to the transfer message to notify the Originating VASP that they will handle the compliance transfer in an asynchronous manner. The reply is also composed as a secure message with digitally signed timestamps for auditing purposes. Inside of the transaction payload, the Beneficiary VASP will provide additional information about when the Originating VASP can expect a response. The Originating VASP should delay any further action or communication until either the expected time frame expires or they receive a follow-on response from the Beneficiary VASP.

The Originating VASP should be prepared to receive such asynchronous callbacks from the Beneficiary VASP and take appropriate measures to handle it by caching the original message and awaiting a subsequent transfer message from the Beneficiary VASP. All messages that refer to the same blockchain transaction will contain the same envelope ID so that all messages may be linked together. Messages are ordered by the digitally signed timestamps in the payload, so it is important for integrators to ensure they are correctly decrypting payloads and sending correctly modified responses with new timestamps.

Once the Beneficiary VASP has completed their compliance processing, they should initiate a TRISA transfer back to the originating VASP that accepts the original transfer by providing the original or corrected compliance information, or rejects it by providing an error in the secure envelope. This will give the Originating VASP conclusive information to take follow on actions like executing the transaction on the chain or handling the error and following the appropriate workflow.

6.3 Mitigating the Risk of Sending Private Information to the Wrong Entity

The simple way to do this is to ask the sending user if they are sending to a VASP, and if so, which one. VASPs such as Coinbase have used this mechanism for several years. It does rely on trusting the user, and is the simplest way to implement compliance by senders. To fully comply with the Travel Rule requirements, the user would also have to enter the beneficiary’s information before the transaction can proceed, so that this information can be stored by the originating VASP and also communicated to the receiving VASP.

This method poses the danger that the user can claim the wrong VASP as the intended destination. For example, a user could claim that they are sending to VASP CoinAA when they are really sending to VASP CoinBB. Assuming both VASPs are legitimate and are registered in the system, then the sending VASP would establish a connection to CoinAA and would send the user and beneficiary’s information to CoinAA. This discloses this private data to the wrong VASP, and puts the actual receiving VASP, CoinBB, in a compliance violation.

This risk is mitigated by verifying that the receiving address is actually controlled by the declared beneficiary VASP. This requires a high-speed lookup whereby the sending VASP can query the beneficiary VASP about the address and confirm that the receiving address actually belongs to that VASP (VASP Address Confirmation protocol). CoinBase and several others call this “Proof of Control,” which requires the queried entity to respond with a challenge, using the private key of the queried entity to sign a randomly generated number with the private key corresponding to the cryptocurrency address. This procedure allows the querying VASP to ensure that the receiving VASP does in fact control the address. One challenge here is that the procedure must be implemented across multiple blockchains, each of which may have different public-private key systems.

Potential risks and considerations:

Transactions should not be posted to the blockchain until the receiving VASP confirms the receiving address. This can delay transaction delivery if the lookup mechanism goes down for any reason.
It could allow mining of addresses to map them to VASPs.
It will create errors and delays for users if there is not a match, or the matching is delayed for several minutes. In such cases, the originating VASP would notify the user that there is no match. This error could cause much customer support overhead if in fact it was due to the receiving VASP having a maintenance delay or other problem with the mechanism, when in fact it really is a match.

6.4 Determining by Receiver if Sender Is a VASP

A somewhat more complicated problem is how a receiving VASP, upon getting an inbound transaction to one of their addresses, can determine if the inbound transaction is from a VASP or not. For full compliance, if the inbound transaction is from a regulated VASP, the receiving VASP should not make funds available to the beneficiary until the Travel Rule transaction identity information is received and recorded.

One approach would require the receiving VASP to wait for a period of some minutes, and then if no transaction identity information is received, to assume that it is from a private individual and not another VASP. The VASP would record it as such, and only then make the funds available to the beneficiary. This delay could be due to problems with the transaction identity system by either the sender’s or receiver’s systems, which operate separately from the underlying blockchain.

Lack of clarity surrounding transaction identities, VASP or private individual, could result in slowed transaction speed as VASPs attempt to comply with Travel Rule, and ultimately a violation of the guidance.

Subject to local laws and requirements by the local regulator, TRISA recommends that VASPs proceed on a “best effort basis”. In other words, when a VASP receives a blockchain transfer it checks to ensure that there is a related TRISA exchange. If not, the VASP should perform reasonable due diligence to ensure the sending entity is not a VASP (e.g. by checking the sending wallet against known VASP wallets). If there is reasonable grounds to suspect the sender is a VASP, it should hold funds and conduct a TRISA exchange, otherwise it may proceed with receipt as usual.

Originating VASPs should always ensure they receive a signed receipt of transaction identity information from a Beneficiary VASP before transactions are placed onto a blockchain. This requirement can complicate the processing systems at Originating VASPs because multiple transfers of value are typically batched up into a single transaction in order to reduce blockchain processing fees. That workflow would have to be reworked to queue only transfers to happen once the Travel Rule processing has been confirmed.

6.5 Automatically Determining a VASP from a Blockchain Address

We propose that originators with cryptocurrency stored at a VASP declare that they are sending funds to another VASP rather than to an individually managed address. This mechanism has been used by VASPs such as Coinbase for several years. However, some parties have requested the ability to automatically reference a receiving address to verify if it is hosted by a VASP and not require users to self-declare their status. This capability can be provided in two ways:

By using the VASP Address Confirmation peer-to-peer protocol to test every VASP to see if a new beneficiary address belongs to that VASP. An implementation of this “data mining” approach is highly undesirable, as it tests every address against every VASP until a hit is found. The process can be optimized by storing address-to-VASP correlations for addresses that are reused by beneficiaries. The following section discusses optimization of the protocol and detection and revocation of data miners in more detail.
Encourage VASPs to publish address-to-VASP mappings to a high-speed blockchain when those addresses are created. VASPs can post hashes of addresses rather than actual addresses, providing a modicum of privacy; however, this approach does not protect against data mining of address-to-VASP relationships. This approach requires a very high speed blockchain with minimal confirmation times (seconds) in order to avoid delaying the sending of transactions. If performance of that system is slow, address-to-VASP mapping would become unreliable. Another challenge is that this blockchain would contain every beneficiary address and its associated VASP for all blockchains. It seems like a very heavyweight approach with the aforementioned reliability issues. A more efficient mechanism involves using a centralized service to provide this functionality. Such a service could expire address-to-VASP mappings over time and throttle data mining attempts but would constitute a central point of failure.

The peer-to-peer discovery mechanism is the preferred approach for the reasons of privacy, decentralization, performance and reduction of impact on existing transaction workflows.

6.6 Optimization of the Network

If sending VASPs do not want to trust their customers to declare that funds are being sent to another VASP or a personal wallet, then they need to query other VASPs to confirm if they control the receiving address and associated account. If done randomly, then we can expect each sent transaction to require an API call to 50% of the VASPs. With over 300 active VASPs, this would be inefficient.

Transaction analysis of hundreds of millions of transactions shows that there are trading clusters where exchanges tend to send and receive transactions between a small group of other exchanges. In fact, as much as 60% of transactions from one exchange can be with two other exchanges.

Sending VASPs can employ caching to optimize automated discovery of the receiving VASP without the input of the end user customer. This cache is simply the ordered list of the most frequent VASPs that receive funds. More elaborate caching can be performed on a per-user basis as well. In such a case, queries required prior to sending a transaction can be reduced by well over 90% for a typical exchange or hosted wallet provider.

Certificate authorities can further optimize the network by delivering VASPs a prioritized list of exchanges to query, based on transaction flows.

7. Security Concerns

Since the transaction identity sending and receiving services must be online and highly available (7×24), these services are particularly vulnerable to security breaches and attacks. A distributed denial of service (DDoS) attack could take a VASP’s entire transaction capability offline, and a large-scale attack on the transaction identity services of major exchanges could take the entire industry offline. Today, it is only possible to take a service’s user interface offline with a DDoS attack because back-end transaction processing that interfaces with blockchains is typically separated from the visible interface.

Once a VASP implements Travel Rule compliant data exchange and storage, it will have massively increased the amount of personal data it must protect from data breaches. Today, VASPs only store the personal data of their customers, and only in one location. That data can be stored offline and encrypted in extreme cases. However, with Travel Rule data requirements, every VASP will have originator and beneficiary data for every transaction that is above the jurisdictional Travel Rule threshold. This reality means that VASPs will find themselves storing the personal information not only of their customers but also of everyone who ever sends them funds that meet regulatory criteria.

7.1 Revocation and Blacklisting

Certificate Authorities must provide a revocation service to remove VASPs from the trusted counterparty list. The reasons for revoking a VASP can include bankruptcy, fraud, criminal activities, or sanctions. Both Certificate Revocation Lists (CRLs) and real-time Online Certificate Status Protocol (OCSP) lookups should be supported. OCSP lookups can be performed on a transaction level.

OCSP lookups can also provide blacklisting of malicious VASPs that are trying to data mine counterparty address information. For example, if a VASP decides to try to find which exchanges host every address on a blockchain, this lookup data can be reported to the CAs, and then used to create revocation data and update a blacklist.

7.2 Encryption of Transmitted Data

A solution in which data is encrypted during transmission between VASPs, using SSL/TLS connections, eliminates the further data encryption of originator or beneficiary information during transit. The onus for checking transaction identity data for sanctioned or suspicious persons or entities falls on both sending and receiving VASPs. Thus, they must access this information in plaintext. Naturally, once checked, VASPs should store the information in an encrypted database, but the data must remain accessible at any time for filing CTR and SAR, for audits, and for financial investigations.

8. Messaging Formats

TRISA defines a trust architecture and peer-to-peer model for compliance with the Travel Rule. In Version 4, TRISA did not define message formats for sending the actual compliance data (account number, name, geographic address, beneficiary name and account number). TRISA V5 defined message formats as follows. These are subject to review and modification based on collaboration with GDF and Digital Chamber.

The peer-to-peer exchange protocol is defined in two different layers:

The wire protocol itself, which defines the API to exchange Secure Envelopes
The payload of the Travel Rule compliance information, composed of two distinct parts:
1. Identity Information (IVMS 101)
2. Blockchain-specific data (transaction data)

All APIs follow a clear versioning paradigm to allow for future expansion and integrations. When integrating with TRISA, users can verify on the TRISA website which versions are current or deprecated. TRISA V9 (protocol v1beta1) uses IVMS 101 [12] as the message contents protocol. IVMS is an industry standard for exchanging Travel Rule information. See the appendix for more information. IVMS101 has been integrated with the TRISA source code as of June 1st, 2020.

8.1 Wire Protocol

The TRISA network protocol defines the peer-to-peer interactions between VASPs that are necessary to conduct compliance information exchanges. All TRISA members must implement all services described by the TRISA protocol to ensure that exchanges are conducted correctly and securely. The primary RPCs are Transfer and TransactionStream which allow VASPs to exchange compliance information before conducting a virtual asset transaction. The other RPCs facilitate Transfers, allowing address confirmations prior to a transfer and public key exchange so that transaction envelopes can be encrypted and signed.

service TRISANetwork {
    rpc Transfer(SecureEnvelope) returns (SecureEnvelope) {}
    rpc TransferStream(stream SecureEnvelope) returns (stream SecureEnvelope) {}

    rpc ConfirmAddress(Address) returns (AddressConfirmation) {}
    rpc KeyExchange(SigningKey) returns (SigningKey) {}
}

The peer-to-peer TRISA protocol is currently defined under proto/trisa/api/v1beta1. This whitepaper describes at a high-level the messaging and protocol data structures to describe how TRISA exchanges work. When implementing the TRISA protocol, please be sure to reference the latest message definitions in the TRISA repository and the TRISA Developer’s Guide.

8.2 Secure Envelopes

The wire protocol defines the RPC exchange endpoints and expected messages sent and received by the initiating VASP. The principal RPC is the Transfer (and optimized Transfer Stream) RPCs which exchange and synchronize Secure Envelopes. The Secure Envelope wraps the identity and blockchain transaction payload, applying additional encryption and digital signatures for verification as shown in Figure 8.

Figure 8: Secure Envelopes ensure compliance data is secure both in flight and at rest, digitally signed to support non-repudiation of an information exchange.

Secure Envelopes ensure that sensitive information is secured both in flight and at rest and guarantee that at the end of an information transfer, both the originator and beneficiary have identical compliance information for a transaction that can only be read by the two parties. Further, at some future time when the information must be supplied for compliance, both parties can provide cryptographic verification that the information has not been modified in the interim.

In flight, Secure Envelopes are exchanged over an mTLS encrypted channel created by the identity certificates issued by the TRISA network. Only TRISA members can communicate via this channel. At rest, the Secure Envelopes use a combination of asymmetric (public/private key cryptography using TRISA issued or peer-to-peer exchanged signing keys) and symmetric cryptography so that the VASPs can securely store the envelope at rest in a backend of their choice while maintaining full repudiation of the exchange.

message SecureEnvelope {
    // The transaction identifier generated by the Originating VASP. All
    // SecureEnvelopes related to a single transaction (including responses and 
    // asynchronous messages) must have the same envelope ID. 
    string id = 1;

    // Encrypted and digitally signed payload
    bytes payload = 2;

    // Encryption key used to encrypt the transaction blob. This key itself
    // is encrypted using the public key of the receiver.
    bytes encryption_key = 3;

    // The encryption algorithm used to encrypt the transaction blob.
    string encryption_algorithm = 4;

    // HMAC signature calculated from encrypted transaction blob.
    bytes hmac = 5;

    // The HMAC secret used to calculate the HMAC signature. This secret
    // itself is encrypted using the public key of the receiver.
    bytes hmac_secret = 6;

    // The algorithm used to calculate the HMAC signature.
    string hmac_algorithm = 7;

    // Rejection errors should be specified in the SecureEnvelope for correct
    // compliance processing. Transport layer errors are specified separately.
    Error error = 9;

    // When the secure envelope was sent formatted as a RFC-3339 timestamp at 
    // nanosecond resolution. Used to order SecureEnvelopes related to the same
    // transaction. Note this is not the same as the signed sent and received
    // timestamp in the encrypted and digitally signed payload. 
    string timestamp = 10; 

    // Meta information related to the public key encryption of the encryption 
    // key and hmac secret - this information indicates if the envelope is sealed
    // or not and if so, what public key was used to seal the envelope. 
    bool sealed = 11;
    string public_key_signature = 12; 
}

proto/trisa/api/v1beta1/api.proto

The Secure Envelope includes both the encrypted compliance information payload as well as unencrypted metadata. The Secure Envelope facilitates multi-message communication referring to the same transaction by requiring all messages related to the same transaction carry the same ID. The ordering of messages with the same envelope ID is established with a timestamp formatted as an RFC-3339 timestamp at the nanosecond scale. This is how both parties can correlate messages:

Originator VASP generates the envelope ID, usually as a UUID4 string, before sending the first secure envelope relating to a new transaction.
When the Beneficiary VASP validates the wallet and returns either the receipt or an asynchronous control message, it uses the same message ID received from the Originator, only modifying the timestamp.
Originator VASP correlates the original transaction using this TRISA envelope id to which the response belongs.
After putting the TX on the blockchain, Originator VASP sends an updated secure envelope with the same envelope ID as the original message and embedding the updated TX and TXID information into the transaction payload.
Beneficiary VASP again uses the TRISA envelope id to know to which message exchange this confirmation belongs.

Finally, the Secure Envelope also contains the algorithms used to digitally sign and encrypt the payload. Currently the TRISA open source implementation supports the following cryptographic algorithms:

AES-GCM [16] for symmetric encryption of the payload. This algorithm is widely adopted for its performance and throughput rates for state-of-the-art high-speed communication on inexpensive hardware. TRISA’s implementation uses a 32 byte key (e.g. AES 256).
HMAC SHA-256 for digitally signing the envelopes encrypted payload.
RSA OAEP SHA-256 for public key encryption of the encryption key and hmac secret.

8.3 Payload

The encrypted payload is a serialized protocol buffer message that contains generic identity and transaction data. The internal message types are purposefully generic to allow flexibility with the data needs of different exchanges. The payload message structure is as follows:

message Payload {
    google.protobuf.Any identity = 1;
    google.protobuf.Any transaction = 2;
    string sent_at = 3;
    string received_at = 4; 
}

proto/trisa/api/v1beta1/api.proto

8.4 Identity Messages

Identity messages should contain an IVMS101 data payload. For more on IVMS101 please see the documentation at intervasp.org. IVMS101 has two primary types, a Natural Person to define a human user and a Legal Person to define an organization or legal entity. These types are used to define both the originator and beneficiary account holder and VASP. The IVMS 101 message payload is defined as follows:

message IdentityPayload {
    Originator originator = 1;
    Beneficiary beneficiary = 2;
    OriginatingVasp originating_vasp = 3;
    BeneficiaryVasp beneficiary_vasp = 4;
    TransferPath transfer_path = 5;
    PayloadMetadata payload_metadata = 6;
}

proto/ivms101/identity.proto

8.5 Transaction Messages

In TRISA V8, transaction data was split into two sections: fields for the country and fields for the blockchain data. Based on community feedback, it was too difficult to maintain and parse multiple message formats for all combinations of blockchain and country. A single generic transaction payload was created in response to this concern and defined below. Geographic information has been moved primarily to the identity payload rather than the blockchain transaction payload.

message Transaction {
    string txid = 1; // a transaction ID unique to the chain/network
    string originator = 2; // crypto address of the originator
    string beneficiary = 3; // crypto address of the beneficiary
    double amount = 4; // amount of the transaction
    string network = 5; // the chain/network of the transaction
    string timestamp = 6; // RFC 3339 timestamp of the transaction
    string extra_json = 7; // any extra data as a JSON formatted object
    string asset_type = 8; // the type of virtual asset for multi-asset chains
}

proto/trisa/data/generic/v1beta1/transaction.proto

8.6 Pending

In order to support the provision for asynchronous transfers, pending messages are defined to provide an intermediate response during the transfer. Note that when sending a pending message, the counterparty should still include the identity payload.

message Pending {
    string envelope_id = 1; // the TRISA envelope ID for reference
    string received_by = 2; // name of the recipient or recipient VASP
    string received_at = 3; // RFC 3339 timestamp of the receipt of request
    string message = 4; // A generic message to respond with
    string reply_not_after = 5; // timestamp the response will be returned by
    string reply_not_before = 6; // timestamp that response won’t be sent before
    string extra_json = 7; // any extra data as a JSON formatted object
    Transaction transaction = 15; // The original transaction for reference
}

proto/trisa/data/generic/v1beta1/transaction.proto

8.7 Versioning Paradigm

Each message starts at v1beta1. When the TRISA community has vetted an API for prime time, it gets bumped to v1. If needed any intermediate version like v1beta2, v1beta3, etc. can be applied. TRISA is using gRPC which allows for compatible schema evolution as not all clients will get updated at once.

By decoupling the wire protocol from the messages TRISA can evolve much more easily, depending on the introduced changes.

9. Collaboration on Message Data Types and Message Protocols

The TRISA project is collaborating with other efforts to standardize data interoperability through message formats.

InterVASP IVMS101 is the recently ratified standard across the industry for message data formats for exchanging Travel Rule information. This standard has had the involvement of 100 companies and industry standard experts. It is a multilingual standard for sharing Travel Rule information between VASPS. The TRISA open source project integrated IVMS101 on June 1st, 2020, becoming the first Travel Rule regulations project to implement IVMS101.

TRISA participants are working with the Digital Chamber of Commerce on message format standardization in coordination with the Global Digital Finance (GDF) AML Working Group.

TRISA participants are working with Shyft on interoperability of VASP identity certificates.

TRISA participants are working with NetKi on how BIP 75 might be adapted to support Travel Rule requirements, and interoperability with the TRISA framework.

TRISA participants are working with Sygna Bridge.

TRISA participants are working with the OpenVASP Association on interoperation with their Travel Rule Protocol.

TRISA participants are working with the Coinbase-initiated “Group of 18,” previously known formally as the United States Travel Rule Working Group (“USTRWG”) and now renamed to TRUST (Travel Rule Universal Solution Technology).

9.1 Provision to Support Account and VASP Identifiers

TRISA supports interoperability between multiple protocols which can be TRISA, OpenVASP, Shyft, BIP75, PayID or others. The Travel Rule message standard can be one of these message formats.

TRISA supports the inclusion of multiple account and VASP identifiers. As of the date of this whitepaper, the TRISA team has worked to incorporate the OpenVASP VANN number as an identifier of the VASP and the account holder. OpenVASP VANN numbers are similar to IBAN numbers and require a customer to input the number when sending.

The TRISA community is working with other industry efforts that are defining payment IDs that can be tied to internet domain control and engage their own payment protocols once the identity of the counterparty is verified.

TRISA has been working with OpenVASP and other industry efforts to integrate these notions of a universal payment identifier that is not tied to cryptocurrency addresses.

9.2 Message Translation and Exception Handling

Multiple approaches have emerged to address travel rule obligations and the specific needs of individual geographies. A majority of solutions have embraced IVMS as a data standard for Travel Rule messages. Some have implemented ISO related standards. Several approaches have unique VASP identifiers.

9.3 Translation Layer Delivers Critical Interoperability

Figure 9: TRISA’s transaction protocol is designed to facilitate maximal interoperability with other Travel Rule compliance protocols.

Figure 10: The TRISA transaction protocol is further designed to serve as an intermediate protocol to facilitate information exchange between other non-TRISA protocols.

10. Open Source Project

The TRISA project is open source and relies on the voluntary contributions of members of the public to grow and evolve. Organizations who adopt the TRISA protocol are encouraged to direct their engineering teams towards the public code base and the developer documentation.

These resources contain the core RPC definitions in the form of protocol buffers for IVMS messages, natural and legal person identification, secure envelopes, and more. In addition, the code base contains a reference implementation of the TRISA protocol written using gRPC and Golang, utility code for performing cryptography and making mTLS connections, as well as a library intended to showcase similar implementations in other languages.

Contributions are welcome in the form of opening bug reports, feature requests, and pull requests.

The latest code can be found here: https://github.com/trisacrypto/trisa

For more information, get involved, or submit comments, connect to TRISA.

Website: trisa.io
Code: https://github.com/trisacrypto/trisa
Email: [email protected]
Twitter: @travelrule
Slack: trisa-workspace.slack.com

11. Glossary

11.1 FATF Definitions

11.1.1 Beneficiary VASP

Refers to the financial institution which receives the wire transfer from the ordering financial institution directly or through an intermediary financial institution and makes the funds available to the beneficiary.

11.1.2 Beneficiary

The meaning of the term beneficiary in the FATF Recommendations depends on the context:

In trust law, a beneficiary is the person or persons who are entitled to the benefit of any trust arrangement. A beneficiary can be a natural or legal person or arrangement.

11.1.3 Designated Categories of Offenses

Designated categories of offenses are:

participation in an organized criminal group and racketeering;
terrorism, including terrorist financing;
trafficking in human beings and migrant smuggling;
sexual exploitation, including sexual exploitation of children;
illicit trafficking in narcotic drugs and psychotropic substances;
illicit arms trafficking;
illicit trafficking in stolen and other goods;
corruption and bribery;
fraud;
counterfeiting currency;
counterfeiting and piracy of products;
environmental crime;
murder, grievous bodily injury;
kidnapping, illegal restraint and hostage-taking;
robbery or theft;
smuggling; (including in relation to customs and excise duties and taxes);
tax crimes (related to direct taxes and indirect taxes);
extortion;
forgery;
piracy; and
insider trading and market manipulation.

When deciding on the range of offenses to be covered as predicate offenses under each of the categories listed above, each country may decide, in accordance with its domestic law, how it will define those offenses and the nature of any particular elements of those offenses that make them serious offenses.

11.1.4 Originator

Refers to the account holder who allows the wire transfer from that account, or where there is no account, the natural or legal person that places the order with the ordering financial institution to perform the funds transfer.

11.1.5 Originator VASP

Refers to the VASP (financial institution) which receives the wire transfer from the ordering financial institution directly or through an intermediary financial institution and makes the funds available to the beneficiary

11.1.6 Risk

All references to risk refer to the risk of money laundering and/or terrorist financing. This term should be read in conjunction with the Interpretive Note to Recommendation 1.

11.1.7 Virtual Asset

A virtual asset is a digital representation of value that can be digitally traded, or transferred, and can be used for payment or investment purposes. Virtual assets do not include digital representations of fiat currencies, securities and other financial assets that are already covered elsewhere in the FATF Recommendations.

11.1.8 Virtual Asset Service Providers

Virtual asset service provider means any natural or legal person who is not covered elsewhere under the Recommendations, and as a business conducts one or more of the following activities or operations for or on behalf of another natural or legal person:

exchange between virtual assets and fiat currencies;
exchange between one or more forms of virtual assets;
transfer of virtual assets;
safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets; and
participation in and provision of financial services related to an issuer’s offer and/or sale of a virtual asset.

Source: Glossary of the FATF Recommendations

12. References

ISO, “Information Technology – Open Systems Interconnection – The Directory – Part 8: Public-key and Attribute Certificate Frameworks,” International Organization for Standardization, ISO/IEC 9594-8:2017, February 2017.
Housley, W. Ford, W. Polk, and D. Solo, “Internet X.509 public key infrastructure certificate and CRL profile,” January 1999, RFC2459. [Online]. Available: http://tools.ietf.org/rfc/rfc2459.txt
Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008, IETF Standard RFC5280. [Online]. Available: http://tools.ietf.org/rfc/rfc5280.txt
W Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain Technology Overview,” National Institute of Standards and Technology Internal Report 8202, October 2018, https://doi.org/10.6028/NIST.IR.8202.
R. Kuhn, V. C. Hu, W. T. Polk, and S.-J. Chang, “Introduction to Public Key Technology and the Federal PKI Infrastructure,” National Institute of Standards and Technology, NIST Special Publication 800-32, February 2001, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-32.pdf.
CA/Browser Forum, Guidelines for The Issuance and Management Of Extended Validation Certificates, Version 1.7.0, 2019.
Riegelnegg, “OpenVASP: An Open Protocol to Implement FATF’s Travel Rule for Virtual Assets,” Nov 2019. https://www.openvasp.org/wp-content/uploads/2019/11/OpenVasp_Whitepaper.pdf
Financial Action Task Force (FATF), “International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation. The FATF Recommendations,” February 2012, 14, https://www.fatf-gafi.org/publications/fatfrecommendations/documents/internationalstandardsoncombatingmoneylaunderingandthefinancingofterrorismproliferation-thefatfrecommendations.html
Malhotra, A. King, D. Schwartz, and M. Zochowski, “PayID Protocol,” June 2020 [Online]. Available: https://payid.org/trisa-whitepaper.pdf
Newton, M. David, A. Voisine, and J. MacWhyte, “Out of Band Address Exchange using Payment Protocol Encryption,” November 2015. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki
Joint Working Group on interVASP Messaging Standards, “interVASP Messaging Standards,” [Online]. Available: https://intervasp.org/wp-content/uploads/2020/05/IVMS101-interVASP-data-model-standard-issue-1-FINAL.pdf
interVASP Messaging: A New Standard for VASPs. interVASP Messaging. Retrieved February 4, 2022, from https://intervasp.org/
TRP, Pending, https://www.travelruleprotocol.org/
FATF, “12 Month Review – Revised FATF Standards on Virtual Assets and VASPs,” July 2020. Online: https://fatf-gafi.org/media/fatf/documents/recommendations/12-Month-Review-Revised-FATF-Standards-Virtual-Assets-VASPS.pdf
FATF, “FATF Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers,” June 2019. Online: https://fatf-gafi.org/media/fatf/documents/recommendations/RBA-VA-VASPs.pdf
Wikimedia Foundation. (2021, October 17). Galois/counter mode. Wikipedia. Retrieved February 5, 2022, from https://en.wikipedia.org/wiki/Galois/Counter_Mode