One of the crucial issues being faced by the nascent cryptocurrency industry today pertains to the management of the public-keys belonging to virtual asset service providers (VASP) and their customers. As a business entity, VASPs can operate under different configurations as viewed by the public-private keys which it holds, owns and operates. We use the term “key management” to include the various management phases of the cryptographic key lifecycle . For VASPs who may be holding not only their own public-private keys but also their customer’s public-private keys, there are several challenges. These include (i) the issue of the legal binding between a public-private key pair and its legal owner, (ii) the problem of “advertising” these public-keys to other VASPs (and their respective customers) – who may be operating in a different legal jurisdiction (e.g. different country), (iii) the problem of revoking the public keys which are compromised, (iv) associating public-private keys with internal VASP identification constructs (e.g. customer account number), (v) how to exchange customer information and claims between VASPs in a secure and interoperable manner, and so on.
In the current work we review the use of existing standards in the area of public key certificates and certificate management in the context of virtual asset service providers. There are several goals of the current work. The first goal is to review the existing methods and standards dealing with information pertaining to public keys, key ownership and key operators. More specifically, we discuss the use of the existing standards for public key certificates and the services used by certification authorities as a means to obtain originator and beneficiary information prior to the transfer of virtual assets, thereby providing a compliant solution for these new types of service providers. We also discuss the need for virtual asset service providers to exchange customer information using the existing standards for attributes or claims. The public key certificates of customers, as well as their attribute information should be communicated out-of-band (off-chain) between virtual asset service providers.
The second goal of the current work is to propose and discuss the notion of a trust network of VASPs as a way for the community of VASPs to exchange out-of-band relevant information regarding their customers and related keys (Section 8). The trust network should be based on a common operating rules which governs the daily running of the trust network.
Our third goal is to propose a number of areas of innovation for the nascent virtual assets industry. This includes new mechanisms to expand the discoverability and reachability of VASPs globally. This will allow better connectivity and information sharing among the various VASPs around the world—in much the same way that ISPs in the Internet share route and endpoint reachability information among the community of ISPs globally.
In October 2018 the Financial Action Task Force (FATF) provided a definition of virtual assets and their service providers, placing cryptocurrency exchanges under the category of VASP. One implication, among others, is that the existing FATF regulatory framework applies to these exchanges, and that exchanges must obtain and hold originator and beneficiary information in the case of virtual asset transfers. As background, the Financial Action Task Force (FATF) is an inter-governmental body established in 1989 by the ministers of its member countries or jurisdictions . The objectives of the FATF are to set standards and promote effective implementation of legal, regulatory and operational measures for combating money laundering, terrorist financing and other related threats to the integrity of the international financial system. The FATF is a “policy-making body” which works to generate the necessary political will to bring about national legislative and regulatory reforms in these areas.
The FATF has developed a series of Recommendations that are recognized as the international standard for combating of money laundering and the financing of terrorism and proliferation of weapons of mass destruction. They form the basis for a coordinated response to the threats to the integrity of the financial system and help ensure a level playing field. First issued in 1990, the FATF Recommendations were revised in 1996, 2001, 2003, 2012 and most recently in 2018 to ensure that they remain up to date and relevant, and they are intended to be of universal application.
With the emergence of blockchain technologies, virtual assets and cryptocurrencies, the FATF recognized the need to adequately mitigate the money laundering (ML) and terrorist financing (TF) risks associated with virtual asset activities. In its most recent Recommendation 15 , the FATF defines the following:
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.
Virtual Asset Service Providers (VASP): 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: (i) exchange between virtual assets and fiat currencies; (ii) exchange between one or more forms of virtual assets; (iii) transfer of virtual assets; (iv) safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets; and (v) participation in and provision of financial services related to an issuer’s offer and/or sale of a
In this context of virtual assets, transfer means to conduct a transaction on behalf of another natural or legal person that moves a virtual asset from one virtual asset address or account to another. Furthermore, to manage and mitigate the risks emerging from virtual assets, the Recommendations states that countries should ensure that VASPs are regulated for AML/CFT purposes, and licensed or registered and subject to effective systems for monitoring and ensuring compliance with the relevant measures called for in the FATF Recommendations.
One of the key aspects of the FATF Recommendation 15 is the need for VASPs to retain information regarding the originator and beneficiaries of virtual asset transfers:
“Countries should ensure that originating VASPs obtain and hold required and accurate originator information and required beneficiary information on virtual asset transfers, submit the above information to the beneficiary VASP or financial institution (if any) immediately and securely, and make it available on request to appropriate authorities. Countries should ensure that beneficiary VASPs obtain and hold required originator information and required and accurate beneficiary information on virtual asset transfers, and make it available on request to appropriate authorities. Other requirements of R.16 (including monitoring of the availability of information, and taking freezing action and prohibiting transactions with designated persons and entities) apply on the same basis as set out in R.16. The same obligations apply to financial institutions when sending or receiving virtual asset transfers on behalf of a customer” (Paragraph 7(b) of ).
The implication of note  is that cryptocurrency exchanges and related VASPs must be able to share the originator and beneficiary information for virtual assets transactions. This process – also known as the Travel Rule – originates from under the US Bank Secrecy Act (BSA - 31 USC 5311 - 5330), which mandates that financial institutions deliver certain types of information to the next financial institution when a funds transmittal event involves more than one financial institution. This rule became effective in May 1996 and was issued by the U.S. Treasury Department’s Financial Crimes Enforcement Network (FinCEN). This rule was issued by FinCEN concurrently with the BSA record keeping rules for funds transfers and transmittals of funds.
Given that today a virtual asset on blockchain is controlled through the public-private keys bound to that asset, we believe there are other information (in addition to the customer and account information) that a VASP needs to retain in order to satisfy the travel rule:
Key ownership information: This is information pertaining to the legal ownership of cryptographic public-private keys.
When a customer (e.g. originator) presents their public key to the VASP for the first time, there must be a “chain of provenance” evidence regarding the customer’s public-private keys which assures that the customer is the true owner. The point is that just because an entity can prove possession of the private key, it does not necessarily follow that the entity is the legal owner of the public-private keys. Proof of possession alone is insufficient to prove legal ownership. The ability to prove legal ownership of the public-private keys may be crucial in different types of applications of virtual assets (e.g. property ownership).
Key operator information: This is information or evidence pertaining to the legal custody by a VASP of a customer’s public-private keys.
This information is relevant for a VASP who adopts a key-custody business model in which the VASP holds and operates the customer’s public-private keys to perform transaction on behalf of the customer.
We believe that the travel rule provides the emerging VASP industry with opportunity today to develop competitive innovations around the correct identification of owners of virtual assets and provide them with user-friendly ways to transfers virtual assets at a global scale. Early attempts to use public key certificates for blockchain systems have been made (e.g. ) but more research and development need to be conducted. Rather than weaken the travel rule to satisfy the short-term needs of a small number of VASPs, governments and VASP businesses should direct research and development into future infrastructures for virtual assets, digital identities, public key certification and the safe management of customer keys. We discuss several possible areas for innovation in Section 9.
In recent years, two popular types of VASPs have emerged, namely centralized exchanges (CEX) and decentralized exchanges (DEX). A centralized exchange may or may not hold a customer’s private-key. In the case that it does, we refer to the exchange as a “custodial exchange” because it has legal custody of the public and private keys. In this case the CEX uses the customers public-private keys under legal custody to perform (sign) transactions sent to the cryptocurrency network.
In contrast, some centralized exchanges do not hold a customer’s keys. Instead, it simply creates an account for the customer in the traditional manner. Here the CEX has one or more public-private keys of its own which it uses to interact with the cryptocurrency network, and it is the CEX that controls these keys (not the customer). Furthermore, the CEX simply commingles (batch) all their customers’ funds or virtual assets into one consolidated fund. For the customer, the custodial CEX approach has the attraction of relieving the customer from having to manage cryptographic keys. It also relieves the customer from having to obtain on their own financial insurance over their virtual assets. The CEX could obtain insurance over the entire comingled funds.
The notion of a decentralized exchange (DEX) is one where the various functions (e.g. bid, ask, trade) related to trading is performed the blockchain system itself (e.g. smart contracts running on nodes of the blockchain). The user employs a wallet (hardware and/or software) which holds the user’s public-private keys and which performs the signing of transactions using the private key. Here the users trade directly from their wallets without having to trust a centralized entity.
Currently the VASP landscape is evolving and as a result there is a degree of confusion today with regards to the notion and functions of an exchange in the context virtual assets. As mentioned previously in Section 3, we believe that the travel rule will necessitate VASPs who operate as a centralized exchange to address the issue of retaining key ownership information and key operator information. This is particularly important for VASPs from a risk exposure management perspective and from the virtual assets insurance requirements . Figure 2 attempts to summarize relationships between VASPS, the originator/beneficiary and the location of keys used to perform transactions. Note that Figure 2 (a1), (b1) and (c1) are symmetrical in that there is an Originator-VASP and a Beneficiary-VASP. In contrast, Figure 2 (a2), (b2) and (c2) are asymmetrical in that there are no Beneficiary-VASP present.
An overview of the relationships shown in Figure 2 is as follows:
VASP mediated asset transfers: In this model the customer holds their public-private keys while the VASP holds a copy of the customer’s public key only (not their private key). This model may be suitable for customers who seek the mediation of the VASP in asset transfers (e.g. for legal purposes) but who may not wish to provide the VASP with the customer’s private key. This is represented in Figure 2 (a1) and (a2).
VASP key-custody asset transfers: In this model, the VASP holds custody of the customers’ public-private keys. Upon instruction from the customer, the VASP signs transactions on behalf of the customer using the customer’s private key. This is represented in Figure 2 (b1) and (b2).
VASP-key commingled asset transfers: In this model, the VASP uses its own public-private keys to perform virtual asset transfers. This is represented in Figure 2 (c1) and (c2).
Multiple asset transfers instances could be merge (batched) into a single transaction, thereby saving the Originator-VASP some transmission cost (e.g. “gas” fee in Ethereum ). The beneficiaries information must still be communicated by the Originator-VASP to the Beneficiary-VASP out-of-band.
Note that combinations of models represented by Figure 2 (a1), (b1) and (c1) can be achieved. For example, on the sending side the originator entity could be holding its public-private keys as shown on the left side of Figure 2 (a1), while on the receiving side the beneficiary entity could be using a key-custody service offered by the Beneficiary-VASP as shown on the right side of Figure 2 (b1). Although not shown in Figure 2, customers may be using other public-private keys to establish a secure and authenticated channel between the customer and the respective VASP. In the remainder of this paper we will not discuss these auxiliary keys, and focus solely on keys that are used to transfers virtual assets on the blockchain (i.e. the public keys that recorded on the confirmed transactions on the ledger).
One of the fundamental challenges of public-key cryptography since its inception in 1978  is that of proving ownership of a given public key. When two parties sign a contract or exchange signed messages, both parties need assurance that they are employing the correct public keys belonging to the respective parties (i.e. not stolen from another user). They also need the feature of non-repudiation, meaning that a signer must be deterred or prevented from cheating by way of claiming – after a contract has just been signed – that their private key was stolen before the contract was signed (e.g. thereby repudiating the signing of the contract). In the context of the travel rule (Paragraph 7(b) of ) VASPs will need to retain evidence of key ownership for compliance purposes. The existing standards pertaining to public key certificates may provide the basis for VASPs to record information regarding the ownership of public keys related to virtual assets.
In the late 1990s the computer industry developed the notion of public key ownership registration and certification . The idea of registration and certification is to unambiguously determine the legal ownership of a public key, and therefore provide the recipient of a signed contract or message with a degree of assurance – for business risk assessment – of the true identity of the signer (the owner of the public-private keys). The goal was to establish a public key framework  that allowed for legal interpretation to be created atop the framework, where roles, responsibilities and liabilities would be unambiguously identified and risks allocated. The notion of a public key framework paved the way for the eventual establishment of the e-Signature Act in year 2000 .
In contrast, around the same time some in industry sought to develop “self-certification” for public keys in which the key owner would self-declare their ownership to friends and family in a “web of trust” model (e.g. PGP ). However, in the context of business transactions self-certification came to be viewed as having little or no value, and as such the “web of trust” philosophy failed to gain adoption in the business community.
In order to understand why public key certificates are core to conducting business on the Internet, it is important to understand the notion of technical trust and business trust. In order for two transacting parties to obtain assurance of each other’s key ownership, a neutral trusted third party is needed to “ vouch” for key ownerships of the respective parties – by way of performing ownership registration and certification of public keys. This trusted third party is referred to as the Certification Authority (CA), and the result of certification is a data structure referred to as Public Key Certificates, typically employing the X.509 standard format. A certification authority issues an X.509 certificate by digitally signing the certificate using its own private key. By signing it, the certification authority legally attests to the truthfulness of its assertion that the public key listed in the X.509 certificate is owned by the subject (person or organization) listed in the same certificate (see Figure 3). One can therefore say that a certification authority “binds” a given public key to its owner (the subject). The overall goal of a certification authority issuing (signing) a public key certificate under a given public key framework is to support the correct identification of the subject and indirectly provide the basis for the chain of provenance of the public key. The standard protocols and formats related to public key certificates is the X.509 public key standard , ,  (ISO/IEC 9594-8). Figure 3 summarizes the typical X.509 public key certificate, while the JSON-based format has also been standardized recently.
The certification authority itself asserts the ownership of its public key in the form of a root certificate using the same X.509 certificate standard. The X.509 root certificate is typically self-signed by the certification authority using its private key (matching the public key stated in the root certificate). In order to prevent the certification authority from cheating by way of modifying the root public-private keys, the root certificate is typically made available to the broad community in numerous ways. This can be achieved, for example, by publishing the root certificate in newspapers and bulletins, by shipping copies inside browsers, by inclusion in hardware, and so on. In this way the certification authority is prevented from repudiating or falsifying its own self-signed root certificate.
As a neutral trusted third party, a certification authority operates services pertaining to the registration, certification and revocation of public-key ownership. As a legal business entity, a commercial certification authority must publish (e.g. on its website) a service level agreement (SLA) pertaining to these services. This service agreement is referred to in industry as the Certificate Practices Statement (CPS) . Prior to registering their public key to a given certification authority, a key owner (subject) must review the CPS document belonging to that certification authority and determine whether the terms of the service in the CPS (e.g. key management procedures, liabilities, warranties for key loss, etc.) are acceptable to the key owner. Some examples of CPS statements can be found in  (from Symantec/VeriSign Inc.) and  (from Apple Inc.).
Over the years there has been misunderstandings regarding the notion of the public key infrastructure (PKI) and regarding the expectations from such a service infrastructure. One recurring complaint has been the “centralized” nature of the certification authority. The fear is that a certification authority may have too much control over transactions between the subject (key owner) and the relying party, allowing it to revoke certificates without sufficient reason, thereby rendering the key owner powerless. We believe this main criticism misunderstands the role of the certification authority as a neutral trusted third party with legal and financial liabilities.
More specifically, both the subject (party) and the counter-party in a transaction must rely on the correct operations of the certification authority and on its legal underpinnings as a business. For risk management purposes, both parties require a single entity (i.e. the certification authority) to take-on legal responsibility and liabilities in the case that (i) errors exist in the public-key certificate; (ii) in the case where the certification authority fails to revoke within reasonable time a certificate corresponding to a stolen or lost private-key (leading to ambiguity of the status of a signed contract); and (iii) in the case that one or more of its services fails, impacting loss on the part of either party (e.g. a valid certificate was revoked by mistake). Thus, the certification authority represents centralized responsibility. Both parties in the transaction need this centralized responsibility in order to manage risks. They need assurance that “the buck stops” at the certification authority should certificate related errors or service failures occur.
Despite these misunderstandings the X.509 standard for public key certificates has been successful at a broad scale over the past two decades. This is because in the current age of the open Internet the public key infrastructure based on the X.509 standard addresses the acute need of business trust based on legal trust founded on the CPS contract (SLA), which is in turn built upon the technical trust afforded by the X.509 key management framework. Service contracts that carry monetary liabilities to the service operator can only be economically viable to the operator and acceptable to customers when the technical foundation of the services has been well understood and has been clearly defined by sound technical standards. Any effort to replace the X.509 standard will need to contend with these three aspects of trust (business trust, legal trust and technical trust).
Today X.509 certificates are ubiquitous across different markets, verticals and applications. The X.509 certificates are used extensively within banking and finance , in defense and military networks , in government and federal systems , and within many consumer electronic products (e.g. PC computers , , TPM hardware on laptops  , smartphones , USIM smartcards , cable-modems , etc.). They are used extensively within routers, VPNs and other network elements. Today in the networking industry the Virtual Private Network (VPN) sub-segment alone is forecasted to reach 70 billion dollars in the next few years. Most, if not all, websites today employ one or more X.509 certificates (of varying qualities) for SSL connections, and billions of SSL connections are made every day from the users’ browsers to the various certificate-enabled websites around the world.
In the context of VASPs and virtual assets bound to public keys, there are at least two approaches that VASPs can adopt with the regards to public key certificates as a means to prove key ownership (Figure 5):
VASP outsources customer public-key certification to a CA: In this approach, a VASP outsources the management tasks relating to its customer’s public key certificates to an external (commercial) certification authority. This approach allows a VASP to focus on its primary business, leveraging the expertise of the certification authority. All public key certificate management tasks, including certificate revocation, are performed by the external certification authority.
Here, when an entity (individual or organization) as the subject seeks to open an account at the VASP accompanied by its public key (see Figure 2 (a1) and (a2)), the VASP can redirect the entity to the external certification authority with whom the VASP has a business relationship. After the entity has been successfully issued with an X.509 certificate for its public key, the certification authority can provide a copy of this certificate to the VASP. A similar approach can be used for VASPs which adopt a key-custody model, in which the VASP request a public key certificate for each customer key in its custody.
Identification information collated by the external certification authority for the enrolling subject can be shared with the VASP, thereby aiding the VASP in its efforts to comply to the travel rule.
VASP becomes a public-key certification authority: In this approach, the VASP itself becomes a certification authority for its customer’s public key certificates. This approach may be attainable by a VASP depending on its business needs and on the size of its customer base. However, all the complex certificate management tasks must be performed by the VASP.
A third possible approach is a blend between the above, in which a hosted certification authority approach is used. Here the certification-related services are operated by a commercial certification authority (as a “white-labelled” service), but the issuance of the certificates and key management is under the full control of the VASPs as the legal issuer. In this case the VASP takes-on the legal liabilities as the customer-facing certification authority.
For virtual asset transfers, the travel rule requires that originating VASPs obtain and hold the required and accurate originator information, and the required beneficiary information. They are also required to submit this information to the beneficiary VASP and make it available upon request to appropriate authorities (see Paragraph 7(b) of ). Traditionally, this information includes the originator’s name, account number, address, the identity of the Originator-VASP, the amount, execution date, and the identity of the Beneficiary-VASP. Additionally, the side of the Beneficiary-VASP, for incoming asset transfers the VASP must obtain and hold information regarding the beneficiary’s name, account number, address and other beneficiary identifiers.
In the context of blockchain systems as the medium of transacting using public keys, the scope of information regarding the customer (originator and beneficiary) must now include their public key information – or what is referred to as the “address” in the blockchain colloquial terminology. As we suggested in Section 3, this account information must now include (i) key ownership information and (ii) key operator information for the customer’s public-private keys used on the blockchain. As further discussed in Section 4 and as illustrated in Figure 2, an Originator-VASP must retain key ownership information and key operator information for (a) the Originator-VASP itself, (b) the originator customer, (c) the Beneficiary-VASP, and (d) the beneficiary customer.
There are several aspects related to the collection of customer information in the context of public keys:
Customer information collected at the time certificate creation: Customer information must be collected prior to the issuance of their public key certificates. Certification authorities commonly require customers (subjects) – whether individuals or organizations – to submit the required information in the Registration phase of the certificate management lifecycle   . During this phase it is the main task of the certification authority to perform identity verification (of the subject) enrolling for the certificate.
Standardized certificate classes based on customer information provenance: Over the last two decade several certification authorities (CA) have develop the notion of class or grades of public key certificates that reflects the confidence in the accuracy and provenance of the information regarding the customer to whom the certificate was issued. The classes or grades of certificates issued by a certification authority is commonly described in the Certificate Practices Statement (CPS) of that certification authority.
As an emerging industry, VASPs can collectively define the notion of classes of certificates for their industry based on the required customer identification information and confidence level during the customer registration phase. A standard definition of certificate classes for the VASP industry allows VASPs to require (demand) that certification authorities fulfill the relevant customer identity verifications and report this information and level of confidence to the VASP as part of the service agreement.
VASP collation of customer identity information from the certification authority: In the case where a VASP outsources the issuance of certificates to an external certification authority (CA), the VASP must obtain a copy of the customer identity information from the certification authority and retain it as part of customer due diligence (CDD) for compliance to the travel rule.
Refusal of customers without certificates or uncertain identities: In order to comply to the requirements of the travel rule, a VASP should simply deny customer requests for virtual asset transfers when the customer does not possess a certificate issued by a known reliable certification authority, or when the issuing certification authority has only low-assurance (low confidence) information regarding the customer.
Certificate validation prior to virtual asset transfer: Prior to a virtual asset transfer, an Originator-VASP must perform certificate validation of the public-key certificates of (i) the originator customer (the customer of the Originator-VASP), (ii) the Beneficiary-VASP, and (iii) the beneficiary customer (the customer of the Beneficiary-VASP). This is discussed further in Section 7.
Customer information communicated out-of-band between VASPs: As mentioned in Section 2 and illustrated in Figure 1, VASPs should exchange customer information and customer certificates (and their own VASP certificates) out-of-band over a secure and authenticated channel. Here, the VASP industry can standardize the APIs and connection-endpoint definitions to allow inter-VASP exchange of customer information in a fast and efficient manner prior to the virtual asset transfer. This is discussed further in Section 8.
Standardization of customer attribute information: The VASP industry should define and profile the customer (subject) data-items required under the travel rule to be exchanged betweenVASPs as part of any virtual asset transfer event. We refer to these data items as the attributes
of the originator, beneficiary and their corresponding VASPs.
There are several standards in existence to represent attribute information of a subject (e.g. individual or organization) and protocols which support the delivery of these attributes securely in the open Internet of today. Examples include the X.509 Attribute Certificate , the XML Security Assertions Mark-up Language (SAML) , the OpenID Identity Token  and the recent JSON-based Verifiable Claims .
As we mentioned previously, an Originator-VASP needs to validate all relevant pubic key certificates prior to virtual asset transfer. This is because any errors related to the destination public keys or about the subject identities can have dramatic impact on the VASP from both an economic and regulatory compliance perspective.
Unlike wire transfers in correspondent banking, transactions on a blockchain systems such as Bitcoin  is “permanent” (or “immutable” as commonly stated) in the sense that once it is confirmed the transaction remains in the recorded blocks (ledger) of the blockchain system. This means that an erroneous asset transfer transaction cannot be canceled, reversed or removed from the ledgers of the blockchain system once the transaction has been confirmed. This lack of a multi-phase commitment scheme  means that a mistake or error in an asset transfer to a Beneficiary-VASP requires the Beneficiary-VASP to return the asset in a separate transaction on the blockchain. It is worth noting that currently most wallets and blockchain systems generally do not employ a phased commitment model in which a “pre-commit” phase is followed by a “final-commit” phase in the sense of classical transactional database system. New blockchain systems such as the Hyperledger Fabric  employ Orderers and Endorsers (i.e. special nodes) that create temporary read/write sets prior to finalizing the read/write set of transactions. However, this process occurs as part of the consensus-making cycle and is outside the control of the sender or receiver VASPs.
The implication here is that in order to avoid errors in virtual asset transfers, in addition to verifying user account information an Originator-VASP must validate the origin and destination public keys of the parties prior to broadcasting the transaction to the blockchain system.
However, there are other circumstances that may complicate this validation process :
Originator possesses only its own uncertified public-key: Many cryptocurrency users today employ a digital wallet (software and/or hardware) that holds only the user’s own public-private key and the public keys (“addresses”) of other users. As such, there are cases where the originator customer may not as yet possess a certificate for their public key. If the originator is a customer of the VASP, one possible course of action is for the VASP to redirect the customer to enroll for a public key certificate following the standard X.509 enrollment process.
Originator possesses public key certificate: In the case that the customer provides a copy of their public key certificate, the VASP must validate the certificate status to the issuing certificate authority. The X.509 standard has protocols to perform this validation in an efficient manner  .
Originator possesses only the uncertified public key of the beneficiary: Similar to the previous scenario, an originator customer of a VASP may only be in possession (i.e. in their wallet) of the public key of the beneficiary, without a corresponding certificate.
In this case, the Originator-VASP has the task of searching for the beneficiary’s certificate among other VASPs or certificate authorities. Typically, X.509 certificates can be fetched from the issuer service via a standardized endpoint (e.g. URI for certificates) .
Originator only knows the beneficiary account information: In this scenario, the originator customer may only be in possession of the beneficiary’s name and account number, and possibly the name of the destination Beneficiary-VASP.
In this case, the Originator-VASP has the task of locating and inquiring to the Beneficiary-VASP about the account of the beneficiary at that VASP using traditional means.
Figure 7 illustrates the case where an Originator-VASP obtains a copy of a certificate based on a beneficiary public key given by an originator customer. The originator customer does not possess the public key certificate of the beneficiary but only their public key (Step 1 of Figure 7). The Originator-VASP submits the beneficiary public key to the relevant certification authority (Step 2), who searches through its database of certificates. When a match is found, the certification authority return the certificate of the beneficiary customer to the Originator-VASP (in Step 3). The certification authority may also return additional known attributes of the customer as part of the response to the Originator-VASP. If the retuned certificate of the beneficiary is valid and the returned attributes contains sufficient information that allows the Originator-VASP to decide based on risk analysis, the Originator-VASP may proceed with the virtual asset transfer.
In order to prevent an Originator-VASP from querying every known certification authority in the world – an approach that is not only impractical but vastly inefficient – one potential solution is for the community of VASPs and their respective certification authorities to form a trust network that shares known good public keys and share certificate revocation lists. This topic will be discussed further in Section 8.
The Internet has been successful over the past three decades because of a number of sound architecture designs. One architecture design decision was to allow organizations to own and operate portions of the Internet as autonomous systems, allowing each autonomous system to runs its own interior routing protocol with its own network topology for their network elements (e.g. routers, bridges, etc.). Each autonomous system would be allocated unique identifier (i.e. AS number) and each autonomous system would represent independent networks (e.g. LANs, WANS, backhaul networks, etc.) owned and operated by various independent entities (e.g. ISPs, universities, governments, military, etc.). Thus, the Internet of today is in reality composed of numerous autonomous systems that are “stitched” together, presenting to the user end-to-end IP connectivity. Autonomous systems employ peering agreements or contracts among themselves in order to negotiate IP traffic volumes and routing patterns. These agreements permit each autonomous system to advertise routes that are available through that autonomous system, resulting in the reachability of (most) IP addresses globally.
Similarly, the SWIFT banking network that begun in the 1970s as a messaging network for sharing bank and account information has evolved over the past three decades into a global network that employs IP-based messaging (SwiftNet). Instead of employing pair-wise (bilateral) key exchanges, it has also adopted public key certificates as a more scalable solution for end-to-end entity authentication of members of the network  .
We believe that in order to solve the various issues around the travel rule and challenges in obtaining of originator/beneficiary customer information, it is in the best interest of VASPs to collectively establish a VASP trust network in a manner similar to the ISP community on the Internet.
Some of the fundamental requirements of a VASP trust network are as follows:
VASP-only network: The VASP trust network should allow the exchange out-of-band of relevant customer-related information as well as blockchain-transaction details. The trust network among others should include a technical public key framework, a common definition of services and interfaces and a legal framework (system rules definition) for all its membership.
The trust network could also deploy a VASP-only management-supporting blockchain system for solely the purposes of common audit and reporting. Depending on the design of this VASP-only management blockchain, hashes of the latest list of known good public keys (and pointers to their file locations) could be captured periodically on this blockchain.
Independence from asset transfer blockchains: The VASP trust network must be independent of any blockchain system as the medium of virtual asset transfers. Like the Internet routing autonomous systems, in the future there will be dozens to hundreds of blockchain systems operating around the world (e.g. for different types of virtual assets), presenting several challenges for blockchain interoperability . As an emerging industry VASPs must ensure that their trust network architecture can interoperate with any and all future asset transfer blockchains.
VASP-to-VASP secure channels based on VASP public key certificates: In order to have the ability to quickly establish secure and authenticated channel pair-wise between VASPs in the trust network, the members of the trust network should each possess public-private keys and a certificate solely for interacting on the trust network. The use of certificates simplifies the task of communicating the public keys of members of the trust network. In the case that the trust network employs a VASP-only management blockchain system, then separate public-private keys must be used for that blockchain system.
Some VASPs today are already employing X.509 certificates for protecting SSL connections from the customers browser to the VASP service platform. However, this minimal use of SSL certificates needs to be enhanced (e.g. end-to-end integration with customer wallets, validation of chains of certificates and attribute claims, cross-VASP certificate queries, etc.).
A trust network of VASPs enables and promotes virtual asset transfers globally in the following ways:
Synchronization of blockchain transactions to customer identity: The use of a trust network
running parallel to the asset-transactions blockchain allows an Originator-VASP to communicate to the Beneficiary-VASP ahead of the transaction on the blockchain. The tight synchronization between the customer information sent through the trust network and the asset transaction on the blockchain provides the foundation for (i) post-event auditing/reconciliation, and (ii) evidence for conflict-resolution and among VASPs who are members of the trust network.
For example, for commingled virtual asset transfers intended for multiple individual beneficiaries, the Originator-VASP can transmit a list of the intended amounts and beneficiaries (recipients) through the trust network. This provides some time (e.g. a few seconds) for the Beneficiary-VASP to validate that all the destined beneficiaries are known to the Beneficiary-VASP and are not on the list of suspect accounts.
Exchange of information about active and revoked customer certificates: VASPs who are members of the trust network can exchange with each other some minimal information regarding the public key certificates of their respective customers.
An example of this minimal information could be the serial numbers (of the certificates) or the public key themselves (without certificates). This list of known good serial numbers and public keys could be shared (broadcasted) securely with members of the trust network on a regular basis (e.g. hourly or overnight) based on a push/pull model (e.g. over a RESTful API ). This allows one VASP to query another VASP in the trust network, submitting only the serial numbers or the public keys over a point-to-point secure channel (e.g. SSL).
Thus, when an originator customers provides the Originator-VASP with a destination beneficiary public key (which the Originator-VASP may have never seen before), the Originator-VASP can search through its copy of the list of known good public keys in the trust network and query the corresponding VASP in the trust network that advertised knowledge of the matching certificate. Similarly, the trust network of VASPs should periodically (e.g. hourly, overnight) exchange the certificate revocation list (CRL) ,  among the members of the trust network using the existing X.509 standard protocols.
Exchange of signed assertions about customers: When an Originator-VASP queries another VASP in the trust network and obtains a valid copy of the public key certificate of a customer of that VASP, the Originator-VASP has the option to further query that VASP for additional account information regarding the customer of that VASP. There are several standard protocols that can be used to deliver customer information assertions or claims (e.g. SAML  and OIDC  are used extensively in various identity provider communities).
The point here is that the initial sharing of minimal information (e.g. serial number of certificate, or public key of a customer) among the VASPs in the trust network allows a VASP to focus subsequent deeper queries to a single (or few) specific VASP for obtaining the beneficiary customer information. This increases the efficiency of the network and the reduces the response time experienced by an Originator-VASP.
Global interconnection of multiple VASP trust networks: In order for the VASP industry to
scale-up their services towards a global customer base, the trust network of VASPs need to be interconnected in the same manner that autonomous systems are interconnected together based on ISP peering contracts. A global interconnection of multiple VASP trust networks allows a VASP in one trust network (domain) to obtain “clues” as to the existence of another VASP in different trust network (foreign domain) who may be in possession of information relating to a destination customer public key.
For example, in Figure 9, the VASP at point A in Trust Network 1 who is seeking to fulfill an asset transfer request from the originator in Trust Network 1 to a beneficiary in Trust Network 3 may obtain reachability knowledge about a remote VASP at point F within in Trust Network 3. The expectation is that the VASP at point F may possess the public key certificate and assertions regarding the beneficiary (who is expected to be a customer of that remote VASP).
This reachability information can be “advertised” from the VASPs in Trust Network 3 through Trust Network 2 into the VASPs at Trust Network 1. This can be achieved through the peering-point between the VASPs at point B and point C, and the peering-point between the VASPs point D and point E. That is, the Originator-VASP at point A hears about Beneficiary-VASP at point F because of the “route advertisements” – namely the summary list of public keys or serial numbers known in Trust Network 3 – was shared through the VASPs within at Trust Network 2.
There are several areas of innovation where VASPs as an emerging industry can take leadership and define the next-generation infrastructure for the global virtual assets commerce.
Following from the discussion of VASP trust networks in Section 8, one area of innovation for the virtual assets and VASPs industry is the development of a common set of operating rules suitable for the VASP industry.
Similar to other organizations (e.g. NACHA , Visa , OIX ) the operating rules for the VASP trust network describe a legally enforceable set rules and agreements that govern the day-to-day running of the trust network as a multi-party system established to achieve common purpose of its members. In the case of the trust network of VASPs, these common purposes include the sharing of: (i) VASP entity information, (ii) customer information, (iii) key ownership information, (iv) key operator information, and (v) VASP reachability parameters. These operating rules must be founded on a common set of business requirements and technical specifications. This in turn allows each member of the trust network to obtain assurance that each of the other participants will follow the same set of rules, defined for their particular role in the trust network.
A good operating rules for a VASP trust network provides its members with the several benefits. First, it provides a means for the members to improve risk management because the operating rules will allow members to quantify and manage risks inherent in participating within the trust network. Secondly, the operating rules provides its members with legal certainty and predictability by addressing the legal rights, responsibilities, and liabilities of the participants in the trust network. Because the operating rules is a legal agreement, it is legally enforceable upon all members. Thirdly, the operating rules provides transparency to the members of the VASP trust network by making the terms of the agreements, technical specifications (e.g. APIs, minimal performance delivery, etc.), and other member business rules – comprising the operating rules – accessible to all participants.
There are several business drivers for establishing a VASP trust network. Beyond the basic set of services that members must implement to be part of the trust network, each member is free to offer product/service differentiation in the market while complying to the operating rules. This in turn allows a VASP to broaden market adoption by enhancing these basic services with better features (e.g. faster response, richer customer information set, better privacy protection for customer information, etc.). From the cost-reduction perspective, standardizing the technical functions across all services of members of the trust network allows for reusability of components (e.g. share common set of APIs and software libraries) and more efficient compliance adherence, thus having the overall effect of lowering costs for all members and their respective customers.
An important part of the operating rules of the VASP trust network is the standardization of common technical solutions relevant to the shared goals of the trust network. For example, in relation to the questions of key ownership information and key operator information, the members should develop a common certificate practices statement (CPS) and certificate profile (CP) for the public key certificates within the trust network. The operating rules should define all aspects and phases of public-key management lifecycle for all members of the VASP trust network.
There are several technical decisions regarding the certificate features that can be defined or expressed through the certificate profile. For example, the certificate profile could narrow the permitted usage of the public-private keys to that of signatures only (not encryption). Additional VASP-specific extension could be defined that may limit usage of the public-private keys to only specific blockchain systems (e.g. can be used to sign transactions only for the Ethereum network).
Following from Section 8, there are several possible areas of innovation pertaining to the exchange of VASP-related information – within a trust network and across trust networks (inter-network as shown in Figure 9) – for the purpose of expanding the discoverability and reachability of VASPs. The ability for a VASP to broadcast a query to the trust network in search for a public key certificate of a beneficiary represents an innovative function that promotes scaling of VASP services. Queries should lead to responses that indicate whether an originator/beneficiary is associated with a VASP within the local trust network, or with a VASP in a different trust network.
Standard protocols exist today to allow access to certificate stores via a HTTP/SSL connection . However, additional technical extension need to be developed that allow VASPs in a trust network to exchange lists of serial numbers (or valid certificates) as well as list of public keys. These periodic exchanges or broadcasts in the trust network can be based on incremental changes – so called “deltas” (akin to Delta CRLs in ) – in order to minimize bandwidth consumption.
A given VASP may belong to multiple trust networks, or it may have a bilateral business agreement with another VASP in a different trust network. These VASPs could become “gateways” to allow certificate-related information to flow from one trust network into another trust network, thereby increasing the “reach” of the cross-network services as a whole.
Rather than employing the classical database-driven directory of VASP identities or VASP codes  — which is akin to white pages of Bank Routing numbers — blockchain technology could be used for VASPs to self-declare their public keys within records of the blockchain. Here, the ledger of the blockchain would record the binding between the VASP’s legal identifier (such as the LEI ) with its public-keys. If the VASP is active in several virtual asset blockchain networks, each of its public-keys for the respective blockchain network could be managed on the VASP Public-Key Directory Blockchain.
Using the more recent construct of Decentralized Identifiers , the VASP blockchain-based directory could also include one or more end-points (e.g. RESTful APIs) at which a caller can verify the X.509 certificate for the VASPs public-keys. For example, this could be the end-point at the Certification Authority (CA) who issued the X.509 certificates for the VASP’s public-keys.
It is important to note that a self-declared public-key on a permissionless blockchain does not constitute the same strength of trust as that of an X.509 certificate from a CA. This is because the CA is a business that operates under a legal framework which requires the CA to issues service level agreements, or warranties and contracts relating to key loss and other failures. Relying parties (counter-parties) can perform risk-assessments based on these service level agreements.
Currently, several industry efforts are seeking to solve the various challenges related to the issuance and management of VASP X.509 certificates , VASP identities/codes and account numbers , the precise semantics and syntax of customer information that needs to maintained and exchanged by VASPs , and others.
Further research and development should be devoted to a class of cryptographic schemes that support a capability which we refer to informally as anonymous but verifiable identities (public keys) with “selective disclosure” features. The basic idea is to employ cryptographic schemes that would allow an key-owner to possess a single private key bound to multiple public-keys in such a way that the public keys are unlinkable to each other when viewed by external entities. Thus, when these public keys are used on a blockchain system, it should be computationally difficult (infeasible) to deduce a mathematical connection among these public keys. The holder of such keys can prove it is a legitimate member of the group (i.e. member of the trust network).
This approach may be applicable to VASPs who are holding accounts or customers and are performing commingled or batch transactions. The amount of assets held or managed by a VASP may be visible in a permissionless blockchain network such as Bitcoin  if the public-keys of the VASP are known by all to legally belong to the VASP (e.g. listed in a directory somewhere).
By using a 1-to-many unlinkable identity scheme, where each “identity” is linked to a public-key the VASP can hold many of these special keys without being able to link them back to the same VASP. In order to satisfy the Travel Rule and other regulatory requirements, the ownership of these unlinkable keys can be disclosed to the government regulators.
We outline such an anonymous-verifiable scheme for blockchain systems in . There are several variants of anonymous-verifiable cryptographic identity schemes that can be used (e.g. , , ), but a discussion of this topic is outside the scope of the current work.
In order for the emerging virtual assets industry to develop and evolve services that are globally accessible, virtual assets service providers need to work collaboratively to create the next generation infrastructures that are not only compliant to the existing FATF regulatory framework but also provide innovative solutions to customers globally.
Virtual assets service providers need to develop a trust network following the principles of the Internet architecture, allowing the exchange of customer certificates and attributes that provide transparency into the movement of virtual assets. The use of existing standards for public key certificates provides a starting point for this trust network. These standards can be extended to incorporate features that are specific to virtual assets and to customers of the service providers. The overall goal is to enable originators and beneficiaries around the world to exchange virtual assets in user-friendly and seamless manner, compliant to regulations pertaining to combating money laundering and the financing of terrorism and proliferation.
As part of developing the next generation infrastructure the virtual assets industry should invest in research and development in several areas of innovation. These areas of innovation include the development of the operating rules of the VASP trust network, information sharing within the trust network and across trust networks, and development of new cryptographic schemes that solve the need of customer anonymity while complying to the requirements of the travel rule.