(Version 0.7) This version has been publish for the first round of public review

TS 2020.012-20

Travel Rule

Attribute	Description
Version	0.7
Authors	Angus Brown (Centbee)
Reviewers	Bernhard Müller, Daniel Connolly, Delphine Forma, Marcin Zarakowski, Neil Samtani, Sam Azad
Tags and Categories	Regulations and compliance, FATF compliance
Publication Date	14 December 2021
Valid Until
Copyright	© 2021 Bitcoin Association for BSV. All rights reserved.
IP Generation	No intellectual property has been sought for this standard
Known Implementations
Applies To	VASP’s
BRFC ID
Acknowledgements	Jan Smit for the draft version. Delphine Forma for considerable edits around scope and technical definitions.
Status	Draft for public consideration
Visibility

Background

The primary purpose of this Travel Rule specification is to define a standardised protocol for VASPs on the BitcoinSV blockchain to collect and exchange the information required by the Travel Rule.

In May 1996, the US FinCEN introduced the “Travel Rule” requiring all financial institutions to send the originator and beneficiary information along with each financial transfer over $ 3,000 – hence the name “Travel Rule”. The objective was to enable AML / CFT and sanctions screening across jurisdictions.

In June 2019, the Financial Action Task Force (FATF) extended the Travel Rule requirements with Recommendation 16 (R16), full name “Virtual Assets and Virtual Asset Service Providers – Guidance for a  risk-based approach”,  to all global Virtual Asset Service Providers (VASPs). In a nutshell, the guidance subjects VASPs to the same requirements as financial institutions. 

In June 2020, the FATF published a 12 month review of the revised FATF standards on VAs and VASPs where it acknowledges gaps in global implementation and addresses stablecoins, the travel rule and unhosted wallets.

In September 2020, it published a report identifying red-flag indicators to help authorities, financial institutions and VASPs detect whether VAs are being used for criminal activity.

****In March 2021, the FATF published a draft updated guidance in which it clarifies the definitions of VAs and VASPs giving concrete examples on what is in scope. This draft has been criticized by the industry as it is very extensive including in scope almost all types of VA activities; especially Decentralized Finance (“DeFi”) which was not previously included.

In July 2021, the FATF published the “Second 12 month review of the revised FATF standards on VAs and VASPs” in which it found that gaps in implementation created vulnerabilities, pressed for implementation of the travel rule, and provided market metrics on peer to peer transactions.

The FATF published the final version in October 2021 where amongst other things, it confirms that “exchange or transfer services may (…) occur through” DeFi, and thus bringing them into scope. The FATF clearly confirms that as long as “creators, owners and operators” maintain “control or sufficient influence”, and the service provides “financial services”, then it falls under the definition of a VASP.

While the Travel Rule sounds similar to Know Your Customer (“KYC”), it has a few key differences. The first is that during KYC, the data collected is only used by the organization that collects it. With the Travel Rule, certain KYC information needs to be shared between VASPs. Secondly, KYC is an internal process while the Travel Rule is a process between entities. Thirdly, the Travel Rule is an event-triggered obligation (at time of sending/receiving), whereas KYC / AML is an ongoing activity for the duration of the service to customer. In this process, it is expected that the originator VASP has done KYC on the originator, e.g. its customer, and the beneficiary VASP on the beneficiary, e.g. their customer.

Crypto.com wrote an excellent introduction on the Travel Rule as well.

The implementation deadlines are set by the related jurisdictions. For example, US FinCEN director Kenneth Blanco says Recommendation 16 is already in effect (via the existing Bank Secrecy Act). FinCEN announced on 23 Oct 2020 that the US Bank Secrecy Act applies to crypto assets, and the threshold will move (date yet to be confirmed) to $250 for international transactions. In Canada, compliance has been expected since June 2021. The EU has issued a proposal for a regulation on transfer of funds and certain crypto assets. The UK has also issued a proposal to amend the MLR 2017 and apply the travel rule to crypto assets businesses. Recommendation 16 is said to be in force in Switzerland, Liechtenstein, Germany, Gibraltar, Singapore and South Korea as well.

Problem Statement

Entities processing BitcoinSV transactions need mechanisms to comply with Travel Rule obligations. Methodologies that are standardised will assist with compliance across national borders, and between different entities within the same country.

The parties affected by the FATF’s Travel Rule are not only VASPs but also outsourced Identity Services (“IS”) which may (i) provide and attest to user data based on KYC/KYB processes and (ii) perform checks of the entities involved on sanction lists.

Objectives

To provide entities impacted by the Travel Rule with a standardised mechanism to meet their compliance obligations. This would enable businesses to demonstrate regulatory compliance in both local and international jurisdictions; enabling end-users to have the full ability to send BitcoinSV to other users, and to spend their BitcoinSV freely.

Scope

Who is a VASP? The FATF defines “Virtual Asset Service Provider” as 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:

1. Exchange between virtual assets and fiat currencies;
2. Exchange between one or more forms of virtual assets;
3. Transfer of virtual assets; and
4. Safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets;
5. Participation in and provision of financial services related to an issuer’s offer and/or sale of a virtual asset. “

In October 2021, in its Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers, the FATF further extended and clarified the scope of its recommendations. The FATF clearly confirms that as long as “creators, owners and operators” maintain  “control or sufficient influence” and that the service provides “financial services”, then it falls under the definition of a VASP. 

The FATF gives examples of what it means by “control or sufficient influence”: creation and launch of a virtual asset, developing DApp functions and user interfaces for accounts holding an administrative “key” or collecting fees, or setting parameters. The notion of “providing financial services” is key. 

For safekeeping and administration, the “term control should be understood as the ability to hold, trade, transfer or spend the VA”.

FATF gives a set of indicia to determine who maintains control or sufficient influence:

• “who profits from the use of the service or asset
• who established and can change the rules
• who can make decisions affecting operations
• who generated and drove the creation and launch of a product or service
• who maintains an ongoing business relationship with a counterparty or another person who possesses and controls the data on its operations
• who could shut down the product or service”.

The FATF is pushing countries to implement the travel rule as soon as possible while also acknowledging that this might still be challenging; and allowing countries to “take a staged approach to enforcement of travel rule requirements”.

Are un-hosted transactions included? FATF defines as follows ” ‘Peer-to-peer’ (P2P) transactions are VA transfers conducted without the use or involvement of a VASP or other obliged entity, such as VA transfers between two unhosted wallets. P2P transactions are not explicitly subject to AML/CFT obligations under the FATF Recommendations. This is because the FATF Recommendations generally place obligations on intermediaries between individuals and the financial system, rather than on individuals themselves with some exceptions, such as requirements related to targeted financial sanctions.”.

Countries are encouraged to implement measures to bring greater visibility to P2P transactions, as well as to limit their jurisdiction’s exposure to P2P transactions. These measures may include:

a) controls that facilitate visibility of P2P activity and VA activity crossing between obliged entities and non-obliged entities (these controls could include VA equivalents to currency transaction reports or reporting of cross-border instrument transfers);

b) ongoing enhanced supervision of those VASPs and entities operating in the VA space which have features enabling unhosted wallet transactions (e.g., on-site and off-site supervision to confirm whether a VASP has complied with the regulations in place concerning these transactions);

c) denying licensing of VASPs if they allow transactions to/from non-obliged entities (i.e., private / unhosted wallets) (e.g., oblige VASPs via the ‘travel rule’ to accept transactions only from/to other VASPs);

d) placing additional AML/CFT requirements on VASPs that allow transactions to/from non-obliged entities – e.g. enhanced record-keeping requirements, enhanced due diligence (EDD) requirements; and

Recommendation 16 then establishes the domestic and international requirements for countries relating to wire transfers and related messages. In summary, countries should ensure that FIs include required and accurate originator information, and required beneficiary information on wire transfers and related messages. FIs should also monitor wire transfers to detect those which lack the required originator and/or beneficiary information and screen the transactions to comply with relevant UNSCR resolutions). Guidance is provided highlighting the importance of VASPs applying risk-based approach to dealing with customers that engage in, or facilitate, P2P transactions, supported by risk assessment, indicators or typologies publications where appropriate.

Are Dapps and multi-sig transactions included? A DeFi application itself (i.e. the software program) is not a VASP under the FATF standards, since the standards do not apply to underlying software or technology. However, creators, owners and operators, or some other persons who maintain control or sufficient influence in the DeFI arrangements, even if those arrangements seem decentralized, may fall under the FATF definition of a VASP. For example, there may be control or sufficient influence over assets or over aspects of the service’s protocol and the existence of an ongoing business relationship between themselves and users; even if this is exercised through a smart contract or in some cases voting protocols. Service providers who cannot complete transactions without a key held by another party are not disqualified from falling under the definition of a VASP; irrespective of how many parties are involved in signature construction, which party has control or how the signature is constructed.

Are merchant payments included? FATF has clarified (Paragraph 84 in the revised guidance: ‘The acceptance of VAs as payment for goods and services, as in the acceptance of VA by a merchant when effecting the purchase of goods, for instance, also does not constitute a VASP activity. A service that facilitates companies accepting VA as payment would, however, be a VASP’) that the acceptance of VAs as payment for goods and services, as in the acceptance of VA by a merchant when effecting purchase of goods, for instance, does not constitute a VASP activity. However, a service that facilitates merchants accepting VA as payment would, however, be considered a VASP.

What must a VASP do? All entities classified as VASP’s shall perform Customer Due Diligence (Know-Your Customer or KYC) before on-boarding a customer. They shall also perform various AML and CFT procedures on a regular basis to detect and report suspicious activity. Each jurisdiction will have licensing and operational requirements of a VASP, which is outside the scope of the Travel Rule standard itself. The requirements of Recommendation 16 apply to VASPs whenever their transactions, whether in fiat currency or VA, involve: (a) a traditional wire transfer, or (b) a VA transfer between a VASP and another obliged entity (e.g, between two VASPs or between a VASP and another obliged entity, such as a bank or other FI), or (c) a VA transfer between a VASP and an unhosted wallet (i.e. a non-VASP or non-obliged entity). For transactions involving VA transfers, countries should treat all VA transfers as cross-border wire transfers rather than domestic wire transfers. For transfers with unhosted wallets, the requirements of R.16 apply in a specific way. Information is collected from the customer but not sent to the unhosted wallet.

What about BSV-based stablecoins and tokens? FATF has clarified that stablecoins and tokens are defined as VA’s, and are within scope of the Travel Rule. Central-bank issued stablecoins are not considered VA’s, and are instead regulated under its fiat currency regulations. The scope of this Travel Rule standard is intended to include BSV-based stablecoins and tokens, to the degree this is technically possible.

What information must be collected? Recommendation 16 establishes the requirements for countries relating to wire transfers and related messages and applies to both domestic and cross-border wire transfers. In summary, countries should ensure that VASP’s include required and accurate (information that has been verified) originator information, and required beneficiary information, on wire transfers and related messages. VASP’s should also monitor wire transfers to detect those which lack the required originator and/or beneficiary information and screen the transactions to comply with relevant UN resolutions. The required information of originators and beneficiaries includes:

Art 114 of FATF R16 d.d. 2019	US FinCEN Guidance re Travel Rule d.d. 1997
i) originator’s name (i.e., the sending customer);	The name of the transmitter,
ii) originator’s account number where such an account is used to process the transaction	The account number of the transmitter, if used,
iii) originator’s physical (geographical) address, or national identity number, or customer identification number (i.e., not a transaction number) that uniquely identifies the originator to the ordering institution, or date and place of birth;	The address of the transmitter,
iv) beneficiary’s name;	The name of the recipient,
	The address of the recipient,
v) beneficiary account number where such an account is used to process the transaction	The account number of the recipient,

Figure 1 on page 54 (item 159) of the March 2021 Guidance Note is a useful reference for the requirements of both the ‘ordering’ and ‘beneficiary’ VASPS’s. In the VA context, ‘account number’ could mean the “wallet address” of the VA and the “public key” of the customer who is sending the VA transfer. Even though the US requires geographical addresses, most emerging markets have abandoned address as a required field, as it is exclusionary and impossible to verify reliably. Date-of-Birth is more widely-accepted in those countries. VASPs who don’t hold address data should consider blocking transfers to/ from US related entities (including VASPs).

How should the information flow? The FATF mentions the following in article 190 with respect to how VA transactions should flow:

184. It is vital that countries ensure that providers of VA transfers—whether VASPs or other obliged entities—transmit the required originator and beneficiary information immediately and securely.

185. “Immediately,” means that providers should submit the required information prior, simultaneously or concurrently with the transfer itself.

186. “Securely”, also in the context of INR. 15, paragraph 7(b), is meant to convey that providers should transmit and store the required information in a secure manner. This is to protect the integrity and availability of the required information to facilitate record-keeping (among other requirements), facilitate the use of such information by receiving VASPs or other obliged entities and protect the information from unauthorized disclosure.

187. The submission of originator and beneficiary information in batches is acceptable, as long as submission occurs immediately and securely as per the FATF Standards

As freezing options are limited, especially for non-custodial VASPs using a mnemonic with known  derivation paths, the receiving and sending entities should be able to conclude their due diligence before signing and sending their respective part of a binding transaction. This may mean, strictly speaking, that the Travel Rule information is sent before the transfer (e.g. during an invoice phase) and not simultaneously or concurrently. Traditional correspondent banking payments use a MT202 COVmessage to send the Travel Rule information.

Who should the information flow to? A VASP needs to undertake counterparty VASP due diligence before they transmit the required information to their counterparty. VASPs do not need to undertake the counterparty VASP due diligence process for every VA transfer, unless there is a suspicious transaction history indicating they should. Note that transactions may not necessarily start and/or end at a VASP. Note also that a VASP may also have customers in multiple jurisdictions and itself may have operating legal entities in multiple jurisdictions.

FATF writes:

203. The FATF recognizes that unlike traditional fiat wire transfers, not every VA transfer may involve (or be bookended by) two obliged entities, whether a VASP or other obliged entity such as a FI. In instances in which a VA transfer involves only one obliged entity on either end of the transfer (e.g., when an ordering VASP or other obliged entity sends VAs for or on behalf the originator to a beneficiary that is not a customer of a beneficiary institution but rather an individual VA user who receives the VA transfer to an unhosted wallet), countries should still ensure that the obliged entity adheres to the requirements of Recommendation 16 with respect to their customer (the originator or the beneficiary, as the case may be).

204. The FATF does not expect that VASPs and FIs, when originating a VA transfer, to submit the required information to individuals who are not obliged entities. VASPs sending or receiving a VA transfer to/from an entity that is not a VASP or other obliged entity (e.g., from an individual VA user to an un-hosted wallet), should obtain the required originator and beneficiary information from their customer. Countries should require their VASPs or other obliged entities to implement mechanisms to ensure effective scrutiny of such transfers, in particular to meet their STR and sanctions implementation obligations (see the discussion of Recommendation 20 below) and, as discussed above, may choose to impose additional limitations or controls on such transfers with unhosted wallets.

Are there thresholds? It should be noted that the FATF’s recommendation includes a low-value threshold:

191. Countries may choose to adopt a de minimis threshold for VA transfers of USD/EUR 1 000 in line with the FATF Standards, having regard to the risks associated with various VAs and covered VA activities. If countries choose to implement such a threshold, there are comparatively fewer requirements for VA transfers below the threshold compared to VA transfers above the threshold. For VA transfers under the threshold, countries should require that VASPs collect: a. the name of the originator and the beneficiary; and b. the VA wallet address for each or a unique transaction reference number.

192. Such information does not need to be verified unless there are suspicious circumstances related to ML/TF, in which case information pertaining to the customer should be verified.

The above low-value threshold implies that for all VA transactions processed by a VASP, that certain information about both sender and receiver are required and transferred. VASPs should confirm such processing requirements below the threshold in their jurisdiction.

FATF also provides (under the KYC requirements of Recommendation 10) a recommended treatment for ‘occasional transactions’ below $/EUR1,000; however, these need to be demonstrably once-off and that no ongoing ‘business relationship’ exists with the customer.

As each jurisdiction enacts local legislation to give effect to the FATF recommendations, each entity in the VA / blockchain domain should conduct their own analysis to determine their compliance obligations. The analysis contained in this document is intended as an overview, and not as legal opinion. The FATF has emphasised that a “functional approach” should be adopted by regulators to assess the true objectives and not the legal form of the transaction. FATF notes: “In addition, countries should aim to keep regulation and supervision for VASPs consistent with that which it uses for FIs that provide functionally similar services with similar ML/TF risks. As with FIs and DNFBPs, countries should therefore subject VASPs to AML/CFT requirements that are functionally equivalent to other entities when they offer similar products and services with similar risks and based on the activities in which the entities engage.”

The following statement from the FATF is perhaps the clearest statement of intent: ”Despite the many and frequently changing marketing terms and innovative business models developed in this sector, the FATF envisions very few VA arrangements will form and operate without a VASP involved at some stage if countries apply the definition correctly.”

Methods and Concepts

The approach taken was to attempt to use existing standards and protocols, rather than create an entirely new architecture to solve this problem. Essentially there are two parts to the proposed standard:

1. Data formatting standards for VASPs to exchange the relevant data 
2. Messaging flow standards to securely exchange this data 
   1. VASP to VASP
   1. IS to VASP

Data Formatting standard

In May 2020, a joint working group of 3 global standard setting bodies in the VA industry proposed the “interVASP Messaging Standard – IVMS101”. This standard details the data formats and minimal requirements for the data which VASPs need to share (and review) prior to completing a transaction. It does not specify how this data should be communicated between VASPs. Furthermore, the IVMS101 data model is yet to be ratified by the 3 global standard setting bodies. An update taking into consideration some small corrections and enhancements is anticipated in due course. The IVMS standard appears to be widely-adopted as a data-formatting standard. A software tool that can verify the compliance of messages to the IVMS standard has recently been released by the OpenVASP Association and can be useful for VASP’s: https://ivmsvalidator.com/ .

Messaging Flow standard

Transactions can be split into:

• Send from or Received by a Public key address: Typical use case is sending tokens to or from exchanges. 
• Send from and received by a Paymail address: This includes the following 2 subtypes:
  • Originator (sender) initiated: P2P Transactions
  • Beneficiary (receiver) initiated: BIP270 (Invoice-based Payments standard – TS 2021.014) for merchants

To exchange Travel Data between VASPs, the VASP of the payment initiator (initiator can be originator or beneficiary of funds) faces the problem of host discovery for his/her counterparty. Bitcoin SV has solved this problem with Paymail since the VASP identity is part of the user identity. Although chain agnostic Paymail-equivalents have emerged (e.g. PayID and FIO-protocol), most exchanges still use public keys and seem to resort to either:

1. “Bulletin Board” solutions: Proposed by USTRWG. The initiating VASP posts the public key of the counterparty on a bulletin board of the relevant chain and waits until a VASP indicates that particular key is hosted by them so a secure communication channel can be setup to exchange Travel Rule information 
2. “Brute force testing” solutions: Proposed by ING’s Travel Rule Protocol. Each VASP maintains a list of trusted correspondent VASPs and queries through a defined API whether they manage the beneficiary public key. Brute force can be avoided if the originator can identify the correspondent VASP beforehand.

Both these solutions obviously have scaling and/or UX concerns.

The main standard setting groups in the VA space for public key based transfers are currently:

• USTRWG: Notable supporters: Coinbase, BitGo, Gemini, Kraken and Bittrex (has BSV).
• Shyft’s Veriscope: Notable supporters: Binance, Bitfury, Huobi, Bitfinex and Tether. 
• OpenVASP/Travel Rule Protocol: Notable supporters: ING, Fidelity and Standard Chartered, BitcoinSuisse, Seba Bank, Sygnum Bank, Zodia.
• Sygna / CoolBitX: Notable supporters: BitMex
• NotaBene: A self sovereign solution. Plans to support all above standards
• 21Analytics: A self sovereign solution. Supporting OpenVasp/TRP.

To send or receive transactions from public keys, VASPs will need to decide individually which standards to adopt (i.e. which exchanges their users will be able to send tokens to or receive from).

Specification

The proposed standard is described below:

1. Data formatting standards: Defining the natural and legal person JSONs as per the IVMS101 standard par 5.2.1. These 2 JSONs can describe all 4 or 5 parties involved: 
   • Originator and OriginatingVASP
   • Beneficiary and BeneficiaryVASP
   • IntermediaryVASP (e.g. in case of central token issuer)
2. Messaging flow standards: 
   • BIP270 Invoice-based Payments Travel Rule enhancement
   • Identity Service – VASP Communication

For the data formatting standards, we recommend the IVMS101 standard and the Google Protocol Buffers derived by CipherTrace – used by the ING TRP working group. Note that a number of issues re IVMS101 listed on the interVASP website still need to be resolved. In addition, the authors of this spec have raised the following inconsistencies with the relevant people involved in IVMS101 and the TRP:

1. IVMS101 allows m-to-n transfers (multiple originators to multiple beneficiaries), but only 1 originatorVASP to 1 beneficaryVASP. We have recommended to only allow 1-to-1 txs. In case VASPs decide to combine multiple transfers in 1 tx, they should document the underlying transfers separately.
2. Multiplicity of “name” for a naturalPerson is defined as [1..n] (see table 5.2.2.1) but TRP JSON and CipherTrace protobuf do not define “name” as an array / repeated.
3. accountNumber is indented by TRP JSON at same level as Person. IVMS101 and protobuf define accountNumber at same level as originatorPersons / beneficiaryPersons.
4. The Travel Rule naturally assumed the existence of accounts as it predates Bitcoin. It is not clear how to populate accountNumber in case of multiple inputs and/or outputs for 1 Person. 
5. IVMS101 can handle multiple beneficiaries and originators but not multiple VASPs. It is not clear what to do about split payments (e.g. tipping for coffee).

Account Numbers

Logically, regulators request a link to an account number in order to have an efficient link to the ledger from where they can further analyse the money flow. To reproduce such a link for a UTXO-based-ledger, for each transaction the txid and inputs and outputs related to each originator and beneficiary should be stored (instead of an account number).

However, this raises the question of data storage. A VASP can maintain such a link in its system, but a more visible link may be preferable, and more useful to authorities wanting to scrutinise the data. Therefore, the Travel Rule Protocol group has come up with a method to store all relevant tx data as an “extension” to the IVMS101 handshake. See also the BIP270 JSONs further on. 

The BTC-extension is currently defined as:

{ "IVMS101": {},
  "extensions": {
    "deterministicTransfer": {
      "txId": "145856536837127631297866",
      "voutIndex": 1,
      "amount": 123    }}}

To accommodate output bills (i.e. multiple voutIndexes) we define the BSV-extension as follows:

{ "IVMS101": {},
  "extensions": {
    "deterministicTransfer": {
      "txId": "145856536837127631297866",
      "voutIndex": [1,2,3],
      "amount": 123 }}}

Customer Identification 

Note that Paymail addresses are transferable and therefore don’t uniquely identify a customer. 

VASP Identification

Note that the receiving VASP needs to provide information regarding its legal jurisdiction to the sending VASP. This is described in section 6 of the IVMS standard.

Information privacy

The principle adopted is that the minimum set of Personally Identifiable Information (PII) should be shared between the entities. VASPs need to indicate to each other which IVMS fields are required, and only share data for those fields. It is understood this is feasible via the technical implementation.

Transliteration Method

The “transliterationMethod” attribute (see p 39 of IVMS101) is added at the same level as “legalPerson” so it can be easily parsed and included in the “payloadMetadata” attribute later on. To avoid the transliterationMethod-complexity, a VASP can choose to avoid the use of “localNameIdentifier”.

Sanctions Check

Often Identity Services are expected to perform a check of this person against the relevant sanctions lists. The input data required to perform a Sanctions Check is typically the full name, nationality, DOB (or at least year of birth) and country of residence. The IS can store the outcome and add any matches to a watch list. Whenever the outcome changes (an IS typically keeps the person on  a watch list), the IS is expected to immediately submit the updated JSON to the VASP; thereby spurring the VASP to take action. Sanction check information is not part of IVMS101.

Summary

The data requirements following IVMS101 and the Travel Rule can be summarized in the following JSON. The colors indicate the following: 

• Mandatory by IVMS101
• Mandatory by IVMS101 if geographicAddress is supplied
• Mandatory by US Bank Secrecy Act (BSA) rule 31 CFR 103.33(g) (“Travel Rule”)
• Useful non-mandatory: 

Natural person 

IVMS101-natPer-JSON

{ "naturalPerson":{
      "name": {
        "nameIdentifier": [{
          "primaryIdentifier": "ERIKSSON",
          "secondaryIdentifier": "ANNA MARIA",
          "nameIdentifierType": "LEGL" }],
        "localNameIdentifier": [{
          "primaryIdentifier": "埃里克森",
          "secondaryIdentifier": "安娜·玛丽亚",

          "nameIdentifierType": "LEGL" }],
        "phoneticNameIdentifier": [{
          "primaryIdentifier": "eriksson",
          "secondaryIdentifier": "ˈænə məˈriːə",
          "nameIdentifierType": "LEGL" }]},
      "geographicAddress": [{
        "addressType": "GEOG",
        "department": "",
        "subDepartment": "",
        "streetName": "Potential Street",
        "buildingNumber": "24",
        "buildingName": "Weathering Views",
        "floor": "45",
        "postBox": "",
        "room": "4507",
        "postcode": "91765",
        "townName": "Walnut",
        "townLocationName": "",
        "districtName": "",
        "countrySubDivision": "California",
        "addressLine-1": "Weathering Views apt 4507",

        "addressLine-2": "24 Potential Street",

        "addressLine-3": "Walnut",

        "addressLine-4": "CA 91765",

        "addressLine-5": "", "addressLine-6": "", "addressLine-7": "",
        "country": "UT" }],
      "nationalIdentification": {
        "nationalIdentifier": "L898902C3",
        "nationalIdentifierType": "CCPT",
        "countryOfIssue": "UT" },
      "customerIdentification": "75101",
      "dateAndPlaceOfBirth": {
        "dateOfBirth": "1974-08-12",
        "placeOfBirth": "Acorn, Utopia" },
      "countryOfResidence": "UT" },

 

  "transliterationMethod": "hani",

  

  "sanctionsCheck": {

        "isPEP": true,

        "isSanctionsCurrent": false}}

ICAO9303-MRZ-JSON

To collect the above IVMS101 data for natural persons, an IS or VASP will generally request a copy of a passport and a proof of address. The passport contains very useful fields such as Nationality and Date of Birth, which are not required or mandatory in the IVMS standard. However, these fields are often required in an on-boarding process; e.g. a gambling or financially oriented app, and they are also useful for sanction list checks. For those reasons we define a separate JSON data structure which captures the Machine Readable Zone (MRZ) defined in ICAO9303 for Machine Readable Travel Documents (MRTDs). If the customer agrees to it, an IS can then give the ICAO9303-MRZ-JSON to a VASP in addition to the IVMS101-natPer-JSON for a marginal additional cost. Note that we expect Identity Services to allow users to choose which fields to populate – for example they may not want “sex” to be populated. 

For consistency in standards, we propose IVMS101 standards trump other standards: 

• Country codes: IVMS101 uses ISO-3166 Alpha-2 codes (ICAO uses ISO-3166 Alpha-3)
• Dates: IVMS101 uses “yyyy-mm-dd” (ICAO uses “yymmdd”)

The lines in bold in below JSON are additions to the IVMS101 standard.

{ "naturalPerson": {

     "name": {

      "nameIdentifier": [{  
        "primaryIdentifier": "ERIKSSON", 
        "secondaryIdentifier": "ANNA MARIA",
        "nameIdentifierType": "LEGL" }]},
    "nationalIdentification": {
        "nationalIdentifier": "L898902C3",
        "nationalIdentifierType": "CCPT",
        "countryOfIssue": "UT",   
        "expiryDate": "2012-04-15",
        "nationality": "UT",

        "sex": "F",

        "MRZ":"P<UTOERIKSSON<<ANNA<MARIA<<<<<<<<<<<<<<<<<<<L898902C36UTO7408122F1204159ZE184226B<<<<<10"

     },
    "dateAndPlaceOfBirth": {
      "dateOfBirth": "1974-08-12",

      "placeOfBirth": ""}},


  "sanctionsCheck": {
        "isPEP": true,
        "isSanctionsCurrent": false}}

Legal person 

IVMS101-Legal-person-JSON

{ 

  "legalPerson": {
      "name": {
        "nameIdentifier": [{
          "legalPersonName": "ABC Attorneys LLC",
          "legalPersonNameIdentifierType": "LEGL" }],

        "localNameIdentifier": [{
          "legalPersonName": "abc律师",

          "legalPersonNameIdentifierType": "TRAD"}],

        "phoneticNameIdentifier": [{
          "legalPersonName": "ˈeɪbiːˈsiː əˈtɜːniz",
          "legalPersonNameIdentifierType": "LEGL" }]},
      "geographicAddress": [{
        "addressType": "BIZZ",
        "department": "Finance",
        "subDepartment": "AR",
        "streetName": "",
        "buildingNumber": "",
        "buildingName": "",
        "floor": "",
        "postBox": "12345",
        "room": "",
        "postcode": "",
        "townName": "Dar es Salaam",
        "townLocationName": "",
        "districtName": "",
        "countrySubDivision": "",
        "addressLine-1": "Jangid Plaza 4th Floor",

        "addressLine-2": "Dar es Salaam",

        "addressLine-3": "",

        "addressLine-4": "",

        "addressLine-5": "",

        "addressLine-6": "",

        "addressLine-7": "",
        "country": "TZ" }],
      "customerIdentification": "12345",
     "nationalIdentification": {
        "nationalIdentifier": "239204",
        "nationalIdentifierType": "RAID",
        "registrationAuthority": "RA000553" },
      "countryOfRegistration": "TZ" },

 

  "transliterationMethod": "hani",

 

  "sanctionsCheck": {
        "isPEP": true,
        "isSanctionsCurrent": false}}

BIP270 / Invoice-based Payments Travel Rule enhancement

BIP270 is a draft working standard that evolved from the BIP70 payment protocol. The Invoice-based Payments Working Group is developing a new standard (internal designation TS 2021.014) which is intended to replace BIP270. Where the word “BIP270” appears in this document, reference is indicated to the latest Invoice-based Payments standard. The process flow depicted below remains relevant; however, implementors of this component of the Travel Rule standard should be aware of this update, and ensure they are using the latest issued protocols.

The comments added on the left and right of the below graph (BIP270 as implemented by HandCash) indicate where / when the TravelData should be made available. 

The enhancements per step are then as follows:

Serves URI (sent by Merchant / Vendor / Beneficiary)

No enhancements proposed for this step.

In a professional e-procurement process the KYB data of the vendor (beneficiary Travel Data) is provided here so the customer can include this information in its vendor due diligence before committing. For example, a customer may not be able to do business with Iranian vendors or certain PEPs (Politically Exposed Persons) owning the business. This data can alternatively be delivered by the vendor as part of, for example, a quote in pdf format outside of the BIP270 process. As the URI used in BIP270 at this step does not easily allow for communication of beneficiary Travel Data from vendor to customer, this standard does not include a proposal to share beneficiary Travel Data at this step in the BIP270 process.

Engages URI (sent by User / Customer / Originator)

As (i) a beneficiaryVASP may, for example, not want to receive funds from (legal) persons in certain black-listed countries, and as (ii) some beneficiaryVASPs are not able to return such funds as they are not custodial, a beneficiaryVASP needs to be able to complete DD before committing to receive funds (i.e. before sending the outputs in the “Serves tx template” step). This means that the originatorVASP needs to send the Travel Data of the originator to the vendor at the preceding “Engages URI” step. 

Before sending the Travel Rule information, the customer reviews (performs due diligence on) the merchant’s quote and his/her Travel Rule information. By “engaging the URI” the customer accepts the quotation and the VASP sends (together with a Purchase Order number) the originator’s and originator VASP’s Travel Rule information to the Merchant. It would be advisable for a VASP to warn a user that they are about to send their name and address details to the counterparty when “engaging the URI”. It is also recommended for an originatorVASP to indicate whether the beneficiaryVASP is known / trusted.

Example JSON for naturalPerson originator (with Purchase Order number): 

{ "customerData": {
    "POnumber": "PO2020-1904"},
  "IVMS101": {
    "originator": {
      "originatorPersons": [{
        "naturalPerson": {
          "name": {
            "nameIdentifier": [{
              "primaryIdentifier": "ERIKSSON",
              "secondaryIdentifier": "ANNA MARIA",
              "nameIdentifierType": "LEGL" }],

            "localNameIdentifier": [{

              "primaryIdentifier":"埃里克森",
              "secondaryIdentifier": "安娜·玛丽亚",

              "nameIdentifierType": "LEGL" }]},

          "geographicAddress": [{
            "addressType": "GEOG",
            "townName": "Walnut",
            "addressLine-1": "Weathering Views apt 4507",
            "addressLine-2": "24 Potential Street",
            "addressLine-3": "Walnut",
            "addressLine-4": "CA 91765",
            "country": "UT" }]},
        "accountNumber": [""]}]},
    "originatingVASP": {
      "originatingVASP": {
        "legalPerson": {
          "name": {
            "nameIdentifier": [{
              "legalPersonName": "HandCash Labs SL",
              "legalPersonNameIdentifierType": "LEGL" }]},
          "geographicAddress": [{
            "addressType": "BIZZ",
            "townName": "Madrid",
            "addressLine-1": "100 Esquela",
            "country": "ES" }]}}},
    "transferPath": {
      "transferPath": [{
        "intermediaryVASP": {
          "legalPerson": {
            "name": {
              "nameIdentifier": [{
                  "legalPersonName": "Tokenized Plc",
                  "legalPersonNameIdentifierType": "LEGL" }]},
            "geographicAddress": [{
                "addressType": "BIZZ",
                "townName": "London",
                "addressLine-1": "1 The Sands",
                "country": "UK" }]}},
        "sequence": 0 }]},

    "payloadMetadata": {
      "transliterationMethod": ["hani"]}}}

Tx template (sent by Merchant / Vendor / Beneficiary)

The parts in bold are additions to the existing HandCash implementation. The Purchase Order number submitted by the customer in the previous step is returned. At this step a vendor should also produce a (pdf-)invoice which can include the name and address of the customer. A JSON invoice could include very rich item level data (e.g. including product level EAN codes). 

{ "network": "bitcoin-sv",
  "outputs": [
    { "script": "76a91419e92fd0ec80a7bc8681e845d4575c28c38d052488ac",
      "amount": 1533906 },
    { "script": "76a91412811318c9cec427051555adadaf3343bb8a125588ac",
      "amount": 432145 }],
  "creationTimestamp": 1588222180,
  "expirationTimestamp": 1596222180,
  "paymentUrl": "http://142.93.157.92:3000/paid",
  "invoiceData": {
    "memo": "this is for coffee",
    "pdfInvoiceURL": "https://joescafe.tz/inv/983425.pdf ",
    "JSONInvoiceURL": "https://joescafe.tz/inv/983425.json " },
  "merchantData": {
    "avatarUrl": "https://bit.ly/3f1fMX7",
    "merchantName": "Joes Café"  },
  "customerData": {
    "POnumber": "PO2020-1904"},
  "IVMS101": {
    "beneficiary": {
      "beneficiaryPersons": [{
        "legalPerson": {
          "name": {
            "nameIdentifier": [{
              "legalPersonName": "Joes Operatingco LLC",
              "legalPersonNameIdentifierType": "LEGL" }],
            "nameIdentifier": [{
              "legalPersonName": "Joes Café",
              "legalPersonNameIdentifierType": "TRAD" }]},
          "geographicAddress": [{
            "addressType": "BIZZ",
            "townName": "Dar es Salaam",
            "addressLine-1": "Jangid Plaza 4th Floor",
            "country": "TZ" }],
          "customerIdentification": "12345" },
        "accountNumber": [""]},

      "naturalPerson": {
          "name": {
            "nameIdentifier": [{
              "legalPersonName": "Suzan the Waiter",
              "legalPersonNameIdentifierType": "LEGL" }]},
          ...     

          }}

    ]},
    "beneficiaryVASP": {
      "beneficiaryVASP": {
        "legalPerson": {
          "name": {
            "nameIdentifier": [{
              "legalPersonName": "CentBee Pte Ltd",
              "legalPersonNameIdentifierType": "LEGL" }]},
          "geographicAddress": [{
            "addressType": "BIZZ",
            "townName": "Johannesburg",
            "addressLine-1": "12 Garden Street ",
            "country": "SA"}]}}},
    "payloadMetadata": {
        "transliterationMethod": [] }},

 

  "extensions": {

    "deterministicValueTransfer": {

      "txID": "76a91412811318c9ce",

      "voutIndex": [0,1,2],

      "amount": 1533906 }, {

      "txID": "76a91412811318c9ce",

      "voutIndex": [3,4],

      "amount": 432145 }}}

Signed tx (sent by User / Customer / Originator)

Enterprise customers will at this stage complete 3-way matching of invoice, purchase order and delivery receipt. Private buyers are likely to check the amount requested and assess the likelihood they will receive the goods they asked for. Then the customer adds the required inputs, signs the tx and returns it to the vendor. 

Unchanged

{ "transaction": "01000000017189f...588ac00000000",

 

  "extensions": {

    "deterministicValueTransfer": [{

      "txId": "c21fc1872ccf9d8142694641af4a53b93f4f5f926560254520aa79cfe72f6548",

      "vinIndex": 0,

      "amount": 2000000 }]} }

IS to VASP communication

In case a VASP choses to outsource KYC/KYB services to an Identity Service, it can receive the required JSONs as follows. Paymail hosts (a.k.a. Wallets or VASPs) add the following capabilities to .well-known:

• Set IVMS101-natPer-JSON
• Set ICAO9303-MRZ-JSON
• Set IVMS101-legPer-JSON

{ "capabilities": {
    "6f1323c12341":"https://example.bsvalias.tld/api/set-natpers/{alias}@{domain.tld}", 
    "123423cddf31":"https://example.bsvalias.tld/api/set-MRZpers/{alias}@{domain.tld}", 
    "2ab34e23eee1":"https://example.bsvalias.tld/api/set-legpers/{alias}@{domain.tld}"

  }}

These URIs allow vetted Identity Services to send the related JSON.

An example process for an Identity Service could be:

1. User to select IS (from a list of ISs contracted by VASP). User to login with Paymail and pay for the chosen service (see below example list of services which an IS may offer).
2. IS to perform KYC/KYB analysis based on data supplied by the user (e.g. copy of passport, proof of address, live selfie, etc.). Note that generally the on-boarding of a customer is the legal responsibility and accountability of the VASP which can not be delegated, although they may outsource certain activities (and again that may be constrained by legislation). 
3. IS to populate relevant JSONs based on chosen service and send to Paymail host.
4. Paymail host to store hash on-chain and return Merkle proof for tx to IS.

Potential IS services list:

1. Natural persons (KYC)
   • a) Create IVMS101 record and send to VASP  (incl. Sanction List check)
   • b) Create MRZ record and send to VASP (incl. Sanction List check)
   • c) Attest IVMS101 and MRZ records on-chain
   • d) Store KYC docs on-chain (steganography encrypted) 
2. Legal persons (KYB)
   • a) Create IVMS101 record and send to VASP (incl. Sanction List check)
   • b) Attest IVMS record on-chain

Exceptions/ Exclusions/ Out-of-scope

• FAFT has clarified that Central Bank-issued digital currencies are not VAs. The FATF Standards however apply to central bank digital currencies similar to any other form of fiat currency issued by a central bank.
• As each jurisdiction has different specific requirements for compliance, it may be out of scope as to whether the specific information provided / shared is sufficient for full compliance. For example FAFT does not always require the full address of the beneficiary (and SWIFT messages only carry the full address of the originator, not the beneficiary), but the US Bank Secrecy Act requires addresses of both parties. Each VASP must determine which regulations it must comply with (i.e. if there is a US nexus, the US Bank Secrecy Act may apply). 
• Send from or Received by a Public key address: VASPs to decide individually which exchange-protocols to adopt. In the longer term VA exchanges may adopt BIP270 as well.
• Paymail based transactions initiated by originator: As Travel Rule data needs to be shared and reviewed before committing to a transfer (non-custodial VASPs using mnemonics and known derivation paths usually can’t freeze funds), the current flow of P2P Transactions (originator initiated process) needs to be extended and preceded by additional steps / handshakes (this does not necessarily affect the UX). However the current BIP270 (beneficiary initiated process) does already contain the required handshakes leading up to the transfer of funds.  
• Non-protocol tokens: The Travel Rule also applies when tokens (e.g. stable coins or securities) with a value in excess of $ 1,000 are transferred (note that in such cases the token issuer is potentially an “Intermediary VASP”). 
• Alternative use cases: The Travel Rule data may be useful in other (non-Travel Rule) use cases. For example:
  • Sharing KYC/KYB details for use on (BIP 270) invoices
  • On-boarding in financial Apps (e.g. exchanges)
  • On-boarding in any other App (e.g. over 18 flag) 
• Validation / Attestation: VASPs and Apps using the Travel Data may want it to be validated / attested by a trusted party before using it.
• Standards for on-chain storage of Travel Data:  Storing privacy sensitive data (encrypted) on-chain may have onerous legal implications and may not be preferred by users. Therefore, this standard does not mandate where the records are stored. The data structures should be stored by the VASP in a compliant way.

Glossary

Terms are defined in the document above.

Limitations

This Travel Rule Standard as well as information included in this document do not, and are not intended to, constitute legal advice; instead, all information, content, and described processes are only recommendations on how a standardised protocol for VASPs on the BitcoinSV blockchain may collect and exchange the information required by the Travel Rule. Regulatory requirements are continuously being revised and updated, hence the information in this Standard may also not constitute the most up-to-date legal or other information.

Implementation of the Travel Rule applicable to VASPs may differ among jurisdictions and may be subject to various legal acts and regulations.

Therefore, no party shall act upon this Travel Rule Standard without seeking legal advice from a professional knowledgeable and experienced in the applicable laws of the relevant jurisdictions.

History

Artefact	Description
Errata
Change Log	0.2 updated to 0.3 by Angus Brown flowing from comments received and the meeting on 14th June 2021 0.3 updated to 0.4 after technical review and publication of FAFT guidance 0.4 update to 0.5 after WG meeting 0.5 update references BIP270 to Invoice-based Payments standard 0.6 update provides some clarity on terminology and references 0.7 gramatical corrections
Decision Log

Relationships

Relationship	Description
IP licences and dependencies	This standard was created as an independent work under auspices of the Bitcoin SV Technical Standards Committee. Whilst best efforts have been made to ensure that this standard and its implementations do not infringe intellectual property rights of any third party, Bitcoin Association can offer no guarantee relating to third party intellectual property rights.
Copyright	© 2021 Bitcoin Association for BSV. All rights reserved. Unless otherwise specified, or required in the context of its implementation on BSV Blockchain, no part of this standard may be reproduced or utilised otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission of Bitcoin Association.
Extends
Modifies
Deprecates
Depends On
Prior Art
Existing Solution
References

Artefacts (optional)

In addition to the standards document, the Working Group should consider delivering the following artefacts when drafting a standard:

• Motivation, goals, benefits
• Flow/ sequence/ entity diagrams
• Test cases
• Security model, proofs
• Implementation guides
• Worked examples
• Code samples/ snippets
• Open implementation
• “Translations” by target audience, role, skill