On July 3rd 2020, Malcom Wright, Co-Lead of Global Digital Finance’s working group for the travel rule (“Joint Working Group for interVASP Messaging Standards”), wrote this article about the Travel Rule. In it, he describes the “Travel Rule Discovery” problem. Basically, how can an originator VASP know which Travel Rule protocol the beneficiary VASP is using? In the article, the proposed solution is to build a “Global List of VASP” (GLoV) which is a centralized registry that maps a “Common Shared VASP Code” (or GLoV VASP Code) to some VASP information, mainly which Travel Rule protocols they support. This solution, in our view, has the problem of being centralized, which could make it difficult for all VASPs to be part of.
Our founding team at Notabene comes from the Self-Sovereign Identity industry, and believe a simple decentralized solution can be built under those principles.
1. Notabene's protocol-agnostic solution
In the article, Notabene is named as an alternative solution to OpenVASP, TRP, Shyft and Sygna. In fact, we do not offer our own protocol but take a “protocol-agnostic” view. We support (or will support) many of the protocols named. VASPs who use Notabene will be able to send and receive Travel Rule information using any of the available protocols, starting with OpenVASP and TRP.
Regarding a solution to the Travel Rule deadlock problem, we propose a decentralized solution using a DID for every VASP. Every VASP can then describe in its DID Document which protocol they support and the particular parameters for it. We also propose to use Verifiable Credentials (VC) as a standardized way to manage trust and knowledge information (KYV) between VASPs.
This decentralized approach can lead to faster adoption by VASPs, since VASPs can “onboard” to the system by themselves, without asking permission from anyone, apply to anything or pay any fee.
2. VASP DID as common shared VASP identifier
Our proposal is to use VASP DIDs as a commonly shared identifier for VASPs. DID stands for “Decentralized Identifier”. It’s a standard that is being developed by the W3C, and is currently being used by many organizations and financial service companies around the world including Microsoft and MasterCard. As described in the W3C standards,
DIDs are URLs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
Every DID can be created independently by any VASP, without the need for coordination. There are many DID methods available so VASPs can choose which one fits best for them. All of them are interoperable by design. Some examples of VASP DIDs can be the following:
did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
did:sov:CYQLsccvwhMTowprMjGjQ6
did:web:exchange-b.com
3. Implemented travel rule protocols on DID Document
Every DID “resolves” to a DID Document. The information on the DID document is controlled by the DID subject (the VASP in this case), and the way to define it and update it is specific to the DID method. The DID documents can have many “service” endpoints which describe services on how to interact with the DID subject. We propose to use this mechanism to describe which protocols a VASP supports and how to access them.
An example DID Document can be the following:
In this example, the VASP identified by the DID did:example:123456789abcdefghi has implemented the OpenVASP and TRP protocol. The DID also defines the end points used to interact with them. In the case of OpenVASP, it points to the OpenVASP’s VASP Code which can be used to get the keys and start a session. In the case of TRP, the endpoint is the base endpoint for the TRP /address-query and /transfer-notification. The public keys for TRP can also be published in the DID Document (there is a publicKeysection for it).
4. Proposed flow
The flow in Malcolm’s article would change to look something like this:
- Customer A of Exchange A wants to send Customer B of Exchange B 1 BTC
- Exchange A supports Sygna, OpenVASP, and TRP
- Exchange B supports Shyft, and OpenVASP
- Customer B provides their name and VASP DID to Customer A
- Customer A provides Exchange A with the VASP DID that resolves to a DID document to see which protocols Exchange B supports (and the parameters of the protocol, like encryption keys).
- Exchange A then asks Customer A to request any additional proprietary information from Customer B (such as an OpenVASP VAAN), or wallet address
- Customer B supplies the information to Customer A, who provides it to Exchange A
- Exchange A then uses the common protocol information (OpenVASP in this example) to transmit the required information on Customer A to Exchange B.
This flow does not require any central service or database. It still has the problem that Customer A needs to ask Customer B for information twice: first the VASP DID, then the proprietary protocol routing information. There are possible ways to solve this, but are out of the scope of this proposal.
5. Know your VASP (KYV)
The last point of Malcolm’s article is about the need for VASPs to trust each other. In the case that every VASP is identified by a VASP DID, then the W3C Verifiable Credential standard will help to create VASP Credentials that can be transmitted and shared to ease the bi-directional KYV process.
We will discuss this in the relevant GDF working groups.
