1. Introduction

In the nascent area of cryptocurrency and transactions of virtual assets, a new type of entity is slowly emerging called the Virtual Asset Service Providers (VASP). The most common example of a VASP today is the cryptocurrency exchanges, which support end-users in delivering cryptocurrencies (e.g. Bitcoins) from one blockchain address (public-key) to another. There are a number of growing pains for VASPs, especially in the light of the long history of inter-bank wire payments (e.g. correspondent banking) and the body of regulations that govern these kinds of banking activities.

Currently, many VASP businesses face various technical, operational and legal challenges which need to be addressed before the cryptocurrencies and virtual assets sector can begin to grow and mature. Some example of these challenges include: scalable ways to identify VASPs at a global scale; methods to perform due diligence on a counter-party VASP (who may be located overseas); scalable ways to distinguish “accounts” at VASP from “raw addresses” (which today are simply cryptographic public-keys); methods to batch transactions that allow correct un-batching at the destination VASP; methods to ensure that information regarding customers are correct; methods to ensure privacy of other related information in the context of due diligence; and so on.

One key issue, we believe, is the need to address the data privacy requirements relating to customers, which may be persons or organizations. Thus, currently VASPs face a data problem: in order for VASPs to fulfill the regulatory requirements from the FATF and the Travel Rule, VASPs need access to truthful information regarding originators, beneficiaries and other VASPs involved in a virtual asset transfer. However, getting access to data or information – regarding individuals and institutions involved in the asset transfer – means that VASPs must also address the challenges pertaining to data privacy and privacy-related regulations such as the EU General Data Privacy Regulations (GDPR) [1] and the California Consumer Privacy Act (CCPA) [2]. On top of these issues, in the past few years there has been decreasing trust of consumers in institutions. Negative reports regarding incidents of attacks on crypto-exchanges (e.g. [3]) compound this diminishing consumer trust.

We summarize these challenges as follows:

• The Travel Rule for virtual assets: The FATF Recommendation 15 [4] requires VASPs to retain information regarding the originator and beneficiaries of virtual asset transfers. This includes (i) originator’s name; (ii) originator’s account number (e.g. at the Originating-VASP); (iii) originator’s geographical address, or national identity number, or customer identification number (or date and place of birth); (iv) beneficiary’s name; (v) beneficiary account number (e.g. at the Beneficiary-VASP).
  

• FinCEN compliance requirements: The FinCEN rules for anti-money laundering (AML) from 2014 [5] requires that customer due diligence (CDD) be performed for convertible virtual currencies [6].
  

• Decreasing trust of consumers in institutions: Over the last decade there has been a continuing decline in trust on the part of individuals with regards to the handling and fair use of personal data [7][8]. This situation has been compounded by the various recent reports of attacks and theft of data (e.g. Anthem [9], Equifax [10]).

• Emergence of data privacy regulations: The enactment of the GDPR [1] in Europe has influenced the discourse regarding data privacy in other nations (e.g. the state of California followed with the CCPA [2]). Given the prominent role of data in the new digital economy, the emergence of a US federal privacy act cannot be ruled out [11].

2. Virtual Assets and VASPs

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.

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 [4], 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 virtual asset.

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 and Countering Financing of Terrorism (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.

3. The Travel Rule and Customer Due Diligence

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. The implication of note [12] 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 Treasury Department’s Financial Crimes Enforcement Network (FinCEN). This rule was issued by FinCEN concurrently with the new 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 [13] [14]:

• 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. Proof of possession of the private key (e.g. using a challenge-response protocol, such as CHAP (RFC1994)) does not prove legal ownership of the public-private key.
  

• 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 which 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.

In the 2014 FinCEN Know Your Customer (KYC) requirements under the BSA [5], the proposed rules contained explicit customer due diligence (CDD) requirements and included a new regulatory requirement to identify “beneficial owners” of customers who are legal entities. It is worthwhile to note that the CDD requirements include conducting ongoing monitoring to maintain and update customer information and to identify and report suspicious transactions. Collectively, these elements comprise the minimum standard of CDD, which FinCEN believes is fundamental to an effective AML program.

The FATF definition of virtual assets means that VASPs – like traditional financial institutions – need to establish an effective AML and CDD program in the sense of FinCEN [5], [6]. We believe that VASPs must additionally obtain and retain the originator/beneficiary cryptographic key ownership information as a core part of monitoring the movement of virtual assets.

4. VASP Messaging: a Layered Architecture

The requirements coming out of the FATF and FinCEN with regards to the Travel Rule necessitates the development of a VASP messaging infrastructure that supports the compliance needs related to virtual asset transfers. The history of the Internet have taught us, scale, interoperability and reliability can be achieved only if infrastructures are built on sound design principles. The goal of the current work is to put forward some of core design principles pertaining to the VASP messaging architecture.

The overall goals of a VASP messaging architecture should be as follows:

• Interoperability: Achieve a high degree of protocol interoperability among VASPs at a global level – independent of the virtual asset type and independent blockchain type (public or private).
  

• Reliable delivery: Ensure the reliability of delivery of messages between VASPs, independent of geographic or physical location.

• Scale-up and survivability: Achieve speed and high-throughput of messages in the face of possible adversarial situations (e.g. partial network disconnections; system error; malwares and attacks).

We use the term “VASP messaging” to denote broadly the interaction between VASPs in the context of the delivery of subject (originators, beneficiaries and VASPs) information related to a virtual asset transfer. VASP messaging includes among others aspects of the following: (i) the definition of the data being transferred; (ii) the reliable delivery at the VASP application layer; (iii) the interoperability of the delivery layer (e.g. TCP/IP; intra-chain P2P delivery mechanism); (iv) external representation of identifiers and keys, and the legal identity of entities who own/control those identifiers and keys.

Figure 1 illustrates one possible logical layered architecture of VASP messaging. These are described as follows. Similar to the layered architecture of the Internet [15][16], one of the main goals of a given layer is to support the function of an upper layer by abstracting functions (hiding details of this layer) to the higher layer.

4.1 Terminology on VASP

We adopt the terminology for blockchain technology from NIST [17]. For definition of virtual assets, we adopt those defined by the FATF Recommendations [4], [12] and FinCen [6]. Additionally, we may introduce qualifications to the terms as a means to increase the clarity of discussion.

• Virtual Asset Service Providers (VASP): Virtual asset service provider means any natural or legal person who is not covered elsewhere under the FATF Recommendations 15 [4].
  

• Messaging protocol: The mechanism used to deliver a freeform message (e.g. bytes of any length) from one VASP to another.
  

• Subject: The person or organization (legal entity) involved in a virtual assets transfer event [6]. The subject (whose information is being delivered) can be the following: originator, beneficiary, Originator-VASP, Beneficiary-VASP.
  

• Claim (Assertions): A digitally signed statement from an entity that is attesting to the accuracy and truthfulness of the information contained. Several formats for claims or assertions have been standardized (e.g. [18], [19], [20]). The source of claims can be the VASP or it can be a third-party data source (Claims Provider).
  

• Claims Provider: An entity that issues signed assertions or statements regarding a subject (person or organization). By digitally-signing a claim, the Claims Provider is attesting to the truthfulness of the assertion. The assertion itself may be embellished by additional information

  (e.g. context indicator, trustworthiness score, date of issuance, expiration data, data-source indicators, algorithm identifiers, etc.).
  

• Address (blockchain-address): A short, alphanumeric string derived from a user’s public key using a hash function, with additional data to detect errors. Addresses are used to send and receive virtual assets [17]. A given VASP may have more than one blockchain-address.
  

• Virtual assets blockchain: The blockchain system within which the transfer of virtual assets occur between two entities (e.g. originator to beneficiary; Originator-VASP to Beneficiary-VASP; etc.).
  

• VASP messaging-address: The messaging-address used by VASPs to deliver information regarding a subject in a virtual asset transfer, as well as other VASP system related parameters. A given VASP may have more than one messaging-address.
  

• Transport address: The ephemeral address used at the delivery layer (e.g. IP address).
  

• Smart contract: A collection of code and data (sometimes referred to as functions and state) that is deployed using cryptographically signed transactions on the blockchain network. The smart contract is executed by nodes within the blockchain network; all nodes must derive the same results for the execution, and the results of execution are recorded on the blockchain [17].
  

• Legal Entity Identifier: The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code, to uniquely identify legally distinct entities that engage in financial transactions [21].

4.2 Subject Data and Claims Layer

The top-most layer of Figure 1 pertains to the information or data regarding subjects (originators; beneficiaries; VASPs) involved in a given virtual asset transfer. The goal of this layer is simply to communicate data and information from one VASP to another in a reliable and accurate manner following some “messaging operational rules” (operating protocols) such as OpenVASP [22]. Thus, for example, issues such as an asset transfer request/response and transfer-confirmations [22] or Invoice request and payment request [23] must be handled by constructs at this layer.

The syntactic definition of the data and information being communicated must be defined using a separate information lexicon and data model such as the InterVASP proposal [24]. Data or information obtained by a VASP from another source entity must be delivered in a standard assertions or claims format that is signed by that source. This allows the receiving VASP (e.g. beneficiary VASP) to know its origins/provenance and to assess the veracity of the signed claims or assertions.

4.3 Digital Identity and Legal Identity Layer

At the end-point of the transfer of subject data and claims are VASPs, which as legal entities are bound by certain legal regimes. For VASPs, two key questions (among others) that need to be addressed in this layer are: (i) identity-authenticity of the VASP entity at the opposite end of the messaging interaction; and (ii) the legal status of that VASP (assuming it has been correctly identified and authenticated).

At this layer, identity management protocols may play a crucial role in identifying and authenticating entities with whom a VASP interacts. Several identity management protocols have been standardized and are in wide deployment today (e.g. SAML2.0 [18], OpenID-Connect [25]). The association or binding between a digital identity and the owner of that identity in the legal context also occurs at this layer. Legal constructs, such as the Legal Entity Identifier (LEI) [21] are captured and represented at this layer.

4.4 Source authentication and Confidentiality Layer

The digital identity layer relies on cryptographic keys and protocols which allow entities to prove their digital identity. Thus, at this layer the management of private-public keys are crucial (e.g. see [26], [27], [28]). The protocols to negotiate mutual session-keys and establish secure end-to-end encrypted channels also occur at this layer (e.g. ECDH; TLS/SSL).

Mechanisms and protocols to prove legal ownership of public (private) keys correspondingly occur in this layer. These can be via certification performed by 3rd parties (e.g. Certification Authorities) who issue public-key certificates (e.g. X.509 standard [29], [30], [31]).

4.5 Message Delivery Layer

The bottommost of the layers architecture is the actual message delivery mechanism and protocols that underlie the VASP-to-VASP interaction. There a number of design principles that should be observed in the delivery of claims:

• Independence of VASP messaging from virtual asset transfer mechanism: The messaging mechanism (protocol) used between VASPs must not be dependent on any specific virtual assets blockchain. VASPs must be able to communicate directly (out of band) with other VASPs (pair-wise direct), without dependence on the asset blockchain system which they employ to transmit virtual assets. This ensures that as new blockchain technologies emerge/evolve, the VASP messaging services and infrastructures can support new blockchain systems.

• Default messaging channel: There must be a default mechanism by which two VASPs who wish to interact directly can establish pair-wise secure channel. VASPs must have the freedom to initiate and negotiate a pairwise secure channel with another VASP in an unmediated fashion. However, there are circumstances in which a common method cannot be found (e.g. both parties suggest incompatible protocols). To addresses such cases, a default mechanism must be defined to which both parties must resort (e.g. plain TCP/IP using TLS1.3).
  

• Default channel-protection negotiation mechanism: There must be a default mechanism by which two VASPs who wish to interact directly can establish security parameters to secure their shared messaging channel. We suggest using the standard key establishment protocols (e.g. ECDH protocol) regardless of the ensuing messaging protocol being used (e.g. Whisper in OpenVASP [22], SSL).
  

• Separation of VASP message addressing from blockchain asset addressing: The addressing scheme used for VASP messaging must be independent (abstracted) from the blockchain addressing scheme. The scheme use to identify and route messages from one VASP to another must be independent of the (public-key based) “addressing” (landing address) used on-chain. For example, in OpenVASP each VASP is associated with a VASP-Code, which together with the customer-specific number (of the VASP’s customer) can be concatenated to form a globally unique VAAN number.

5. Related Work: Identity Claims Model

The problem of customer identification, on-boarding and due diligence is not unique to VASPs, and has been a challenge for Internet service providers generally (i.e. online merchants) since the late 1990s. The promise of Internet-based services (versus traditional brick-and-mortar shops) was that of an increase in transaction efficiency, lower costs and better convenience for the user. However, as the past two decades of Internet services has shown, the problem of consumer identification and authentication is not trivial and is closely related to the problem of data and consent-based access [7],[32] to personal data pertaining to the consumer (data subject) [1].

5.1 Attributes in the SAML2.0 Model

Online services today employ Identity Providers (IdP) as means to provide mediated authentication of the user (subject) on behalf of the online Service Providers (SP), such as online merchants. The Service Providers are reliant on the authentication-event outcome of the IdP, and as such they are referred to also as the Relying Party (RP). This model of interaction is referred to as Web Single Sign-On (Web-SSO) model for browser-based user interactions [18]. The typical consumer-facing IdP issues an identifier (e.g. email address) and manages the credentials of the user (e.g. change password). When the user seeks to access services offered by the Service Provider, the user is temporarily redirected by the SP to the IdP for authentication. If the authentication is successful, the IdP issues an authentication-token (e.g. SAML2.0 tokens, Kerberos tickets) which can then be validated by the Service Provider. The IdP and the Service Provider typically have a business relationship that provides the foundation of trust between them.

Figure 2 illustrates the basic mediated authentication flows through the IdP in steps (a)–(c). After the IdP provides the Service Provider (Relying Party) with evidence of successful authentication in Step (c), the Service Provider now requires factual information or attributes (assertions or claims) about the user (subject). Here, one approach defined by the SAML2.0 specifications [18] is for the IdP to inquire to a special entity called the Attribute Provider (AtP) to furnish the IdP with attribute assertions or claims about the subject. In other literature (e.g. [33]), the Attribute Provider is also known as the Claims Provider (CP). Thus, in Step (1) of Figure 2 the subject provides consent or authorization for the Attribute Provider to release information to the IdP in Step (2). The IdP forwards the assertions or claims in Step (3) to the Service Provider. Alternative flows are possible, such as when the signed claims are delivered to the SP through the subject.

From the VASP perspective, the flows in Figure 2 provide the rudimentary mechanism for a VASP to obtain customer information in the form of signed claims. Thus, the VASP is the relying party because it is reliant on the Attribute Provider (Claims Provider) to furnish it with information about the subject seeking the services of the VASP (e.g. subject request transfer of virtual assets). Note, however, that the authentication-token paradigm of [18] does not address how information about a subject is to be obtained or derived by the Attribute Provider.

5.2 Authorization to Access Protected Claims in UMA2.0

The rise in mobile devices in the past decade required a different authorization model than the Web-SSO of the 1990s. In particular, many mobile applications (i.e. apps) require on-going access to the user’s online resources (e.g. calendar, photos, email account, etc.) that are distributed throughout the Internet at different service providers. Access to resources is needed even when the user is not currently using the mobile app (e.g. background sync of email, calendar, etc.). Thus, a token-based authorization model emerged based on the OAuth2.0 framework [34] which permitted the user to “authorize” mobile apps to continue to access the user’s online resources, and which provided an automatic “refresh” token that could be obtained by the mobile app from the authorization server without prompting the user.

The token-based authorization model of OAuth2.0 [34] was subsequently extended by the User Managed Access (UMA) architecture [35], [36] starting in early 2009. The UMA effort recognized from its start the reality that consumer data was dispersed throughout the Internet and that if a consistent consent-based approach (such as that proposed by the GDPR [1]) was to be implemented, a federated authorization model was required [32]. In this model, personal data, claims and other information about the user (subject) stored at various “resource servers” throughout the Internet could be accessed by a third-party only if the requesting party first obtained consent from the user through the UMA protocol. Thus, the UMA approach specifically recognized the reality that data about tens of millions of users are today in the possession of various data providers – financial institutions, telecom operators, health organizations, social media platforms, email providers, etc. – and that a protocol to implement decentralized consent management was needed.

5.3 Consent for Execution of Algorithms to derive Claims

An important aspect of the OAuth2.0 framework [34] and of the UMA architecture [35], [36] is the absence of any mechanism to express consent policies (access rules) on the part of the user. Both OAuth2.0 and UMA saw consent expression languages as out-of-scope for the technical design of the resulting protocols.

Given the prevalent practice in industry of re-selling consumer data to “data brokers” – what Tim Cook from Apple refers to as the “shadow market” [37] – we believe that a safer approach is needed that disincentives the copying (export) of consumer data from one institution to another. We refer to this approach as open algorithms (OPAL) based on a number of privacy-preserving principles (discussed further below in Section 6).

Following from the open algorithms principles, the work of [38] has proposed the notion of consent for the execution of algorithms from the user (subject). Here, when a subject provides consent, the default interpretation of “consent” is that of the data provider running a specific algorithm on the subject’s data (in the repository, without exporting it). The algorithm must be vetted by experts, published and explained in lay-language to the subject (i.e. informed consent [1]).

For VASPs as the relying-party, the open algorithms approach provides a way for VASPs to be alleviated from the need to maintain large amounts of raw data about a subject. Figure 3 summarizes the basic flow of information (signed claims) from a Claims Provider to the VASP. In Step (1) the subject (user) seeks the services of the VASP (e.g. transfer virtual asset). The subject must indicate to the VASP the identity of the Claims Provider(s) that can furnish the VASP with information about the subject. In Step (2) the subject indicates to the Claims Provider that the subject consents for the relevant vetted algorithms to be executed by the Claims Provider in order to yield information or insights sought after by the VASP. The resulting claims can be static attributes (e.g. “the user legally lives in city X in country Z”) or more dynamic insights based on a broader range/type of data over a duration of time (e.g. “the user’s credit card transactions range for X dollars to Y dollars over the past six month”). In Step (3) of Figure 3 the VASP requests the signed claims from Claims Provider, which are delivered to the VASP in Step (4). By signing the claims, the Claims Provider implicitly attests to the truthfulness of the statements inside the claims structure.

On the surface it may seem that static attributes may be of primary value for AML/KYC purposes. However, we believe that dynamic insights based on a broad range of data may be more useful in the long-term for an ongoing Customer Due Diligence (CDD) program as discussed in Section 3.

5.4 Linking Claims to Decentralized Identifiers on Blockchains

Although not directly relevant to the problem of deriving insights (claims) from data in a privacy-preserving manner, more recently there have been efforts to use blockchain technology to enable to the user to better control access to end-points on the Internet where signed claims may reside.

Referred to as Decentralized Identifiers (DID) [39], the basic idea is that the user would “register” to the blockchain a DID-record containing specific end-point configuration information (e.g. URLs and APIs) on the Internet where a requesting party can obtain information about the user (e.g. location of a store of signed claims). The record on the blockchain is digitally signed by the user, indicating that it is the user who self-declares the information about the service endpoint to be true. Since the user holds the matching private key, later if the user seeks to update the DID-record the user can simply replace it with a newer record (with a newer timestamp).

The idea of a DID as a persistent identifier follows from a long history of efforts on persistent and resolvable digital identifiers on the Internet. The most prominent of these identifier schemes is the Digital Object Identifier (DOI) [40], with its accompanying Handle resolver system [41]. Similar in protocol-behavior to the DNS infrastructure, the DOI and Handle provide for an efficient look-up of copies of files (e.g. library catalog entries) stored at repositories all over the Internet. Today the DOI and Handle system have been successfully deployed at a wide scale for over a decade (e.g. for publications and library records).

Following from Figure 2, an alternate flow using the DID/blockchain approach is shown in Figure 3 via Steps (3A) and (3B). Here in Step (1), in addition to the request to the VASP, the subject provides the VASP with a DID structure (either a public DID or pair-wise DID). The VASP resolves the DID value (via the blockchain or DID resolver) in Step (3A), which brings the VASP to the correct Claims Provider – who holds the subject’s claims – in Step (3B). As before the Claims Provider responds by delivering the signed claims in Step (4).

Although the DID/blockchain approach is useful for certain use cases (e.g. users self-managing their public keys), in the context of providing relying parties (i.e. VASPs) with truthful and accurate information about a subject in a privacy-preserving manner, the role of DIDs remain unclear [42].

5.5 Recent VASP Standardization Efforts

Since the issuance of FATF Recommendation 15 [4] there have been efforts to develop standards to support VASPs in complying to the FATF and Travel Rule in the context of virtual assets transfers.

The OpenVASP [22] effort borrows from existing modern payments standards, recasted for the context of cross-VASP exchanges of information. The goal of OpenVASP is to establish a shared communications protocol for VASPs to exchange virtual asset transfer information, as required by the FATP Recommendations. A related approach is the Travel Rule Information Sharing Architecture (TRISA) [43] which seeks to develop a peer-to-peer mechanism for complying with these regulations. Finally, several organizations in the nascent virtual assets industry are collaborating to create an InterVASP data model for use in the submission of required originator and beneficiary information by originator VASPs to beneficiary VASPs respectively [24].

A detailed analysis of these new proposals is out of scope for the current work.

6. Privacy-Preserving Claims: Open Algorithms

As mentioned previously, the customer due diligence (CDD) requirements defined by FinCEN include conducting ongoing monitoring to maintain and update customer information and to identify and report suspicious transactions.

Today, in order to fulfill the need for ongoing monitoring of a given subject (person or organization), data analytics can be performed in order to identify certain trends or to pinpoint certain anomalies. Extensive data analytics can be performed only of data is readily accessible. In reality, however, today data regarding a subject is typically stored (siloed) within different institutions across different sectors of industry (e.g. financial data, health data, social platform behavioral data, etc.). Furthermore, each of these data repositories may be operating under different regulatory jurisdiction that make it difficult to combine these data in order to derive better insights [44]. Thus, today we live in a kind of paradox: huge amounts of digital data are increasingly being accumulated, but usage for the betterment of individuals and communities are increasingly being hampered by various constraints.

It is with this backdrop the Open Algorithms (OPAL) [45] approach was first developed at MIT in the context of computational social science, which sought to obtain better understanding of communities in the modern digital world.

The open algorithms approach is based on a number of fundamental principles [46]:

• Data should never leave its repository.

• The vetted algorithms are instead transmitted to the data repository to be executed there.

• Only aggregate answers are returned, which do not permit the re-identification of individuals.

• Any algorithm execution yielding a response that goes deeper or finer-grained than aggregate results must first obtain explicit consent from the individuals concerned.

A key aspect of the OPAL approach is that subject consent by default means permission to execute an algorithm, which is different from the current industry interpretation of “consent” (typically meaning permission to export or copy data out of the repository). Algorithms that are designed to identify individuals (e.g. who satisfy certain criteria) can only be executed only after explicit consent has been obtain from the individual subject (per GDPR [1]).

The OPAL approach has been piloted in Colombia and Senegal in 2017-2018 in the context of preserving privacy related to research using mobility data in those countries [47]. A commercial implementation of OPAL for sharing of insights among financial industry entities is currently underway. An extensive discussion of OPAL is out of scope and has been treated elsewhere (e.g. see [38], [46]).

7. OPAL-Based Data Providers Trust Networks

In order for VASPs to develop a customer due diligence (CDD) program that satisfies not only FinCEN and FATF requirements, but also preserves the privacy of citizens – as required by current privacy regulations (e.g. GDPR and CCPA) and possible future regulations [11] – the open algorithms paradigm offers a promising starting point to derive useful insights that can be conveyed in the form of claims (or assertions).

More importantly, for many Data Providers (data holders) the open algorithms approach provides the most practical solution that does not require data providers to give up data – which is core to their business. In many circumstances, the requesting party (i.e. VASPS) simply need attributes and insights about a subject, and not raw data about the subject. As such, for many data holders the open algorithms paradigm may offer them new sources of revenue through the creation of algorithms to match the data in their possession, and by making these resulting insights available (e.g. as claims) to fee-paying customers (i.e. VASPs).

Greater effect is created when data providers from distinct industry verticals (e.g. banking & finance, health, telco, etc.) collaborate to achieve deeper insights about subjects. These deeper insights are what a customer due diligence (CDD) programs require in the context of virtual assets and VASPs. We refer to a coalition or consortium of cross-industry data providers as Data Providers Trust Networks (see Figure 4). Similar arrangements have been established in other industries (e.g. Identity Providers’ consortium) for specific purposes (e.g. share costs for mediated authentication services). For the nascent VASP industry, collaboration with these data providers trust networks may be crucial is order to obtain access to these insights based on the open algorithms approach. In this way VASPs can obtain insights and attributes based on data of high-provenance, without needing to resort to third party data brokers/aggregators [37].

Figure 4 illustrates the notion of data providers trust networks supplying insights and attributes in a privacy-preserving manner using the open algorithms approach. The interface to the VASP (as the requesting party) is the Claims Provider service. In Figure 4, before the VASP is permitted to engage the Claims Provider service, the VASP as a relying party must first be authenticated and be authorized by the Authentication Service (AS). This is shown in Step (1) of Figure 4. The VASP is permitted to choose only from a published list of vetted algorithms. In Step (2) the VASP submits a request to the Claims Provider. Responses coming back from the data providers are collated by the Claims Provider and packaged in the form of a claim or assertion using the relevant format (e.g. [18], [20]). The claims or assertions are digitally-signed by the Claims Provider, and then transmitted to the VASP in Step (3). A copy of all issued claims or assertions are also placed in the claims store of the subject located, for example, within the Personal Data Store (PDS) [48], [49] of the subject. The copies of signed claims in the subject’s PDS claims-store allows the subject to independently make use of the claims for other purposes – which is consistent with the recommendation of the 2014 WEF report on personal data [8].

An extensive discussion on open algorithms and the data providers trust networks can be found in [46].

8. The VASP Claims Messaging Networks

As mentioned previously, the Travel Rule requires VASPs to retain information regarding both the originator and beneficiaries of virtual asset transfers [4]. This situation can be challenging when the virtual asset transfer occurs between VASPs who are operating under differing legal jurisdictions (e.g. located in different countries).

To this end we believe that the lessons learned from the evolution of the Internet architecture may be beneficial in solving the scaling and interoperability issues related to VASPs and virtual asset transfers. More specifically, communities of VASPs need to form Claims Messaging Networks (CMN) for the purpose of (a) sharing of claims generated by local Claims Providers, and (b) sharing of key ownership information for customers’ public keys. These communities of VASPs which form claims messaging networks are akin to autonomous systems in classic IP routing, where routing domains within an autonomous system share route reachability information for the benefit of all the member ISPs.

Figure 5 provides an overview of the various relationships among the entities in a VASP claims messaging network, where each relationship is both at the technical level (e.g. APIs and protocols) as well as at the legal level (e.g. service contracts, practices statements, etc.). Relationship (1) of Figure 5 occurs between the Data Providers (data holders) with the Claims Provider based on the privacy-preserving open algorithms approach [45], [38], [46].

Relationship (2) in Figure 5 is between VASPs and Claims Providers (CP), where a VASP become a customer of the Claims Provider under a Service Level Agreement (SLA). An SLA could, for example, require that signed claims carry an indication (e.g. “score” value) of the provenance or lineage of the data used by the Data Provider in Relationship (1) with the Claims Providers. Such a provenance score acts as an communicable indicator of information quality within the data provider trust network.

Relationship (3) in Figure 5 is between VASPs and Certification Authorities (CA) as the sources of the key-ownership information regarding private-public keys. This entails a VASP dealing with multiple CAs in cases where the originators employ a different CA from that of the VASP (see [14] for a discussion as to whether a VASP should also be a CA).

Relationship (4) is between VASPs that may be located within different legal jurisdictions (e.g. different countries). One of the core ideas of a claims messaging network for VASPs is for the establishment of a common set of technical standards (e.g. messaging, key management), operating procedures, service agreements, and a shared legal interpretation of the members’ obligations and liabilities. This may include a shared agreement regarding the privacy and protection of data (claims) about originators and beneficiaries. Relationship (5) is between a VASP and its customer (originator or beneficiary).

There are several open challenges with regards to the establishment of a claims messaging network of VASPs. These are discussed below.

8.1 Assurance of information quality about subjects

The matter of the provenance of data becomes crucial when the origins of claims about a subject need to be traced back and ascertained. In the context of the open algorithms paradigm (Figure 4) this means the ability to log, audit and account for the algorithms and data-sets used by the data providers (in the data providers trust network) to derive information about a subject. The ability for a Claims Provider to account for each claim or assertion (about a subject) that it issues and signs reflects the degree of verifiability of this information.

8.2 VASPs operations across legal jurisdictions

The problem of data provenance and the degree of verifiability of information carried within signed claims is particularly acute in the case where originators (and Originator-VASPs) and beneficiaries (and Beneficiary-VASPs) are operating under or located within different legal jurisdictions. The establishment of global industry standards for information quality assurance for subjects in virtual assets transfers may have to evolve from national-level standards, and then later expanded to an international standard through the relevant standards organizations (e.g. ISO).

When transmitting originator (beneficiary) information or claims – namely personal data about a subject – VASPs face a number issues arising due to differing legal jurisdictions. These include (i) differing or “mismatched” data privacy regulations; (ii) the retention of claims according to local regulations; (iii) the protection of claims in transit and in storage (i.e. data-at-rest protection).

8.3 Unmediated decentralized claims messaging networks

One of the key value propositions of virtual assets (e.g. cryptocurrencies) is the decentralization of the means to transfer virtual assets [50]. Here we interpret “decentralization” to mean the ability of an originator (Originator-VASP) to transfer virtual assets to a beneficiary (Beneficiary-VASP) without reliance on a centralized party. Similarly, VASP claims messaging networks must allow VASPs to exchange claims with each other in an unmediated manner.

A fundamental requirement of claims messaging networks is the non-repudiation of an exchange of claims. That is, an Originator-VASP (Beneficiary-VASP) must not be able to deny or repudiate that it has transmitted claims about its customer (subject) to a Beneficiary-VASP (Originator-VASP).

Another fundamental requirement is the strong cross-correlation between information (claims) about a subject with the actual virtual asset transfer (e.g. crypto-currency transaction on a blockchain) belonging to the same subject. VASPs should not be exchanging claims about a subject in the absence of transactions by the subject.

8.4 Reuse of existing technical standards

The VASP communities should re-use existing standards in the area of public-key certificate management, notably the X.509 standard that is widely deployed today [29], [30], [31] (ISO/IEC 9594-8). This ensures that VASPs can more easily integrate new services into the existing security and digital identity infrastructures. VASPs should also develop their industry-specific Certificate Practices Statement (CPS) that provides the legal framework for VASPs to determine risks and liabilities (e.g. due to private-key loss, compromises, etc.). Various CPS statements exist today from different industries (e.g. [51], [52], [53]).

Similarly, VASPs should reuse standards around claims format (e.g. X.509 Attribute certificates [19], the SAML assertions [18], and the recent Verifiable Claims [20]).

9. Conclusions

VASPs face a data problem – they need truthful information regarding subjects, such as originators, beneficiaries and other VASPs involved in a virtual asset transfer – as required by the FATF Recommendations 15 and the Travel Rule. In the current work we have proposed the Open Algorithms approach that provides a way for data providers in various industry verticals (e.g. finance, healthcare, telecom, etc.) to make insights about subjects based on their data available in a privacy-preserving manner. These insights are derived based on the open algorithms principles, and are delivered via a Claims Provider to the VASP (as the relying party).

In order to scale services to a global level, we propose that VASP communities form claims messaging networks for the purpose of exchanging claims about subjects and key ownership information. We have discussed a number of challenges today to the establishment of such networks, including quality assurance about information contained in claims, cross-jurisdiction operations of claims messaging networks, and the need to reuse or to profile many of the existing technical standards.