Documentation

What is Veriscope? Why are we on this mission?

Veriscope is a blockchain-based solution powered by the Shyft Network. We aim to solve global regulatory compliance for Virtual Asset Service Providers (VASPs), including the FATF's Travel Rule. This will accelerate the global adoption of cryptocurrency throughout regulated markets and promote new products and services to enter the space.

Shyft Veriscope

This section is intended to provide an overview summary of the Verified Shyft Coalition Optimized Participant Exchange (Veriscope) system. Veriscope was designed as a smart contract mediated data coordination infrastructure, intended to provide a global discovery and validation ecosystem to solve regulatory guidance mandated through the Financial Action Task Force.

Heading

This past summer, the Financial Action Task Force issued a guidance requiring Virtual Asset Service Providers (VASPs) to share Personal Identifiable Information (PII) and Know-your-customer (KYC) data between transacting sender and receiver user before executing transactions.

This guidance, called the Travel Rule, is enforced in the traditional finance space between counter-parties such as banks who use SWIFT for both transaction settlement and identity data sharing.

Key Stakeholders

Financial Action Task Force: Intergovernmental organization that focuses on the development of policies to combat money laundering and terrorism financing. It monitors progress in implementing the FATF Recommendations through “peer reviews” (“mutual evaluations”) of member countries; it also maintains two lists of nations depending on their level of compliance or adherence to AML regulation and controls: FATF Blacklist and FATF Greylist.

VASPs: any entity engaged in digital asset custody such as;

Cryptocurrency exchanges
Non-custodial wallets
OTC desk
Brokerage firms

User Transactions To and From Exchanges Today

Alice is a VASP1-Ex user. Alice wants to send 1BTC to Bob. Bob is a TurkeyEx user. VASP1-Ex does not know that Bob is a TurkeyEx user, and TurkeyEx does not know that Alice is a VASP1-Ex user.
Alice inputs Bob’s TurkeyEx BTC address in VASP1-Ex, and initiates a withdrawal request.
VASP1-Ex processes the transaction on Alice’s behalf, and Bob receives BTC in his TurkeyEx BTC wallet.

Throughout this process, VASP1-Ex has no idea where Alice is sending BTC, and TurkeyEx has no idea where Bob is receiving BTC from.

Assuming TurkeyEx and VASP1-Ex are both using blockchain analytics services, such as Chainalysis, the two exchanges may be aware (read: able to identify) that their entities are exchanging BTC. But then again, maybe not — addresses are changed frequently, for example. The two exchanges are not required to collect destination/origination prior to processing transactions on behalf of their users.

Example of the problem: User Transactions To and From Exchanges Under the FATF Travel Rule Guidance

Alice is a VASP1-Ex user. Alice wants to send 1BTC to Bob. Bob is a TurkeyEx user. VASP1-Ex does not know that Bob is a TurkeyEx user, and TurkeyEx does not know that Alice is a VASP1-Ex user.
Alice inputs Bob’s TurkeyEx BTC address in VASP1-Ex, and initiates a withdrawal request.

VASP1-Ex is in a difficult situation as it’s now responsible for somehow discerning the following information:

Identifying the receiving VASP

Who is the receiving entity?
Is the receiving entity a VASP? How does VASP1-Ex validate that it is a real exchange?
If the receiving entity is a VASP, VASP1-Ex will be required to share and receive PII pertaining to users participating in this transaction. How can VASP1-Ex find out if the receiving entity is a VASP?

Establishing communications with the receiving VASP

Assuming VASP1-Ex identifies that the receiving address belongs to a TurkeyEx account, VASP1-Ex must now establish connecting with TurkeyEx. How?

Data sharing between VASPs

Assuming VASP1-Ex establishes a line of communication with TurkeyEx, the two exchanges will have to decide to share their users’ PII.

What channel will they use to share this data to ensure it isn’t vulnerable in the transfer process?
How does VASP1-Ex decide if TurkeyEx is trustworthy, and will take care to custody Alice’s PII securely? How does VASP1-Ex verify TurkeyEx’s compliance in international standards of AML, CDD, etc.?
Does Alice have any say in executing this transaction? Does she have a right to know how her data will be custodied, or to stop the transaction from occurring at this point?
Will VASP1-Ex be liable if TurkeyEx exposes Alice’s PII? Who will be liable?
Do VASP1-Ex and Alice have a say in how TurkeyEx uses Alice’s data? Is TurkeyEx allowed to reach out to Alice, attempting to onboard her as a user? Can TurkeyEx now sell Alice’s data to data markets?

The issues with coordination, user address discovery, VASP discovery, data security, and liability/risk presented by the FATF Travel Rule guidance are enough to put exchanges out of business.

The Shyft Network FATF Travel Rule Solution (Veriscope)

Veriscope acts as a coordination and discovery layer for global VASPs. Veriscope Network is partnering with the most trusted VASPs in the crypto space who will act as the first set of data custodians on the network; these VASPs will work together to:

Form and manage semi-trusted VASP coalitions
Pre-validate each VASP’s compliance and custody procedures
Pre-determine rules of doing business, such as which external, encrypted channels will be used to share user PII
Authenticate their users onto Veriscope, generating key-pair attestations against user PII, and giving users transparency into and consent over their PII flows
Whitelist exchange addresses and privacy-preserving individual PII data attestations on a shared registry internal to the coalition
Develop procedures for validating user compliance with KYC/AML standards
Leverage Shyft Network APIs to enable encrypted communication

Other, smaller exchanges that are not part of the initial Veriscope group of partners can also set up coalitions with their semi-trusted partners to comply with the Travel Rule. Coalitions can all communicate with each other, and set up the same business rules and procedures interoperably across coalitions.

Importantly, Shyft Network infrastructure does not hold or facilitate send/receive of any private or regulated data.

Also, current transaction systems don’t provide users the ability to see and control how their data moves post-required PII sending. Compliance with the FATF rule is one thing, but once that’s done, allowing exchanges that have been transferred to your PII to then sell it to data market brokers (ad agencies etc.) for example should be under the user’s direct consent requirements for further sharing. Veriscope is built with consent as a key pillar and the starting point of PII data transactions; users remain in control of who can access their data, and for how long.

Federated Coalitions

A Federated Coalition ('Syndicate', Strong Federation, or otherwise) is a set of independent operators that bind themselves to similar (or even equivalent) requirements (usually as a result of this, they have aligned incentives, or if not legal obligations). Under most conditions these actors require explicit trust guarantees with one another - without them, there are increasing costs (if not inability) to operate effectively.

By nature, the benefits of working within this system far outweigh the benefits of acting independently or nefariously. Federated coalitions on Shyft Network can be bound to regulatorily-enforced rule sets, and some are even used by government entities to enforce regulations.

An example of a Shyft Network federated coalition across the Veriscope Network:

A group of VASPs committed to determining, standardizing, and enforcing policies by way of trusted smart contracts, with opt-in input from local regulatory bodies, inspired on FATF recommendations, and adopted by qualifying industry participants.

Another example of a federated coalition across Veriscope:

Actors consenting (within a GDPR-compliant consent-registry framework) to “attestations” that have been placed on these public addresses by a Trust Anchor, which initiates a process that maps the Trust Channels in totality to the user’s accounts across the Federated Coalition. As a result, the transfer of assets from one actor to another has a complete provable history trail with all parties mapped and validated, while ensuring all regulatory requirements are met, and all information is transmitted and delivered privately between only the coalition of VASPs that were required in the process as set out by the rules on the Trust Channel.

Creating a Coalition

Coalitions are composed of VASPs whose users frequently transact with each other. As an example, for the Travel Rule, these exchanges now need to frequently share user identity data about the originator and beneficiary involved in transactions. Coalitions will collaboratively define standards around inter- and intra-coalition information sharing, business activities, and communication in the context of relevant global and local regulatory and jurisdictional requirements.

Creating and managing an administrator or group of admins:

Setting a primary admin
Promote an admin
Setting up the coalitions consensus voting rights for confirmation proposals
Revoke administrator
Coalition Proposals

Confirmation threshold to enable a proposal to change admins in a coalition
Viewing the admin confirmation threshold for a given coalition
Changing the current amount of admins in a coalition required in a Confirmation threshold
Request access as an admin

VASP Frequently Asked Questions

How does Veriscope Smart Contracts enable Travel Rule Compliance?

Veriscope has a set of smart contracts that were specially designed for meeting and exceeding the regulatory guidelines of the Travel Rule. Shyft provides developers with Contract API’s which are integration tools to enable utilizing the function calls in the contracts to configure VASP settings, create, attest, and exchange identity information with other VASPs on the network.

Is the Veriscope VASP Front-End using the travel rule Smart Contracts?

The Veriscope font-end portal that is used to demonstrate the Travel Rule Compliance solution made possible by the Shyft Network is using the Veriscope smart contracts through two developer tools that provide ease of use API function calls. The API tools can be found in the Developer Guide.

What can be done with the Contract API tools?

The purpose of the API tools is to test and integrate the Shyft Smart contract functionality within your VASP platform. All the necessary functionality is provided to create a new VASP account, onboard a VASP, verify VASPs, check if a VASP is verified, create users and assign them a Shyft ID, create attestations for user transactions between VASPs, verify attestations and more.

What’s the difference between the Veriscope Front End and the APIs?

The Veriscope Front End and APIs are different, as the Front End is used for demonstration purposes and has limited functionality compared to the APIs. As an example, the Front End has a fixed set of conditions that can be used for attestations about a user, when in fact, the possibilities are near limitless when using the API.

What are Attestations?

When a Trust Anchor (that is, an entity the network inherently trusts without the need to derive it) has data about a user that’s available for sharing, that data is kept confidential, and only an Attestation is published declaring that the information in question exists. The attestation is pseudonymous (attached to their network address rather than any more recognizable form of their identity), and generally restricted to metadata about the information it contains. Additionally, the metadata is encrypted with a user-controlled key, so that users can restrict access to the metadata, to entities that they consent to share it with. This degree of user control also makes it harder for an attacker to use social engineering or data mining attacks to obtain private information.

What are Coalitions?

Coalitions are structured by entities that participate in Veriscope, that share a common set of rules and administration mechanisms for governance of roles along with rights-based permissioning. An example of a Coalition in the case of VASPs could be a group of VASPs that have agreed upon a common set of rules for governing their VASP-to-VASP compliance procedures.
Formation of a new Coalition begins with a sponsor participant and an additional participant chosen by the sponsor. These two are the first peers in a Coalition and collectively can add additional members.
Composed of VASPs participating in data collection & sharing, which includes sharing sender and beneficiary information to solve the Travel Rule.
A VASP Coalition can create complex relationships that define how they communicate with one another based on regulatory, jurisdictional, reputational requirements, and nearly any other conditional requirements.
VASP Coalitions agree on and bind rules and requirements pertaining to business logic such as:
- Process within Coalition for communicating & sharing information.
- Types of information that can be shared based on regulatory & jurisdictional requirements.
Coalitions do not exclude VASPs outside of the coalitions from conducting businesses with external entities.
VASPs & non-VASPs can act across an infinite set of coalition arrangements and formations.

What is the current size of the Veriscope Alliance and who are your partners?:

We currently work with Binance and its affiliate partners
We also are in the process of onboarding the top VASPs in world, that collectively represent 70 percent global liquidity including tether & Bitfinex

Does Veriscope use a Certificate Authority to solve the Travel Rule?

Veriscope does not use a certificate authority model, and instead takes a novel approach of establishing trust between VASP counterparties using the powerful decentralized properties of the Shyft blockchain to enable discovery, communication and verification between VASPs. As Veriscope is an open blockchain, VASPs are able to freely communicate using attestations to the blockchain and can be identified and verified independently by other VASPs as a result of transactions being signed by their public/private key pairs.
With regards to VASP’s establishing themselves as a verified VASP in the first place, this can be accomplished with a federated muWith regards to VASP’s establishing themselves as a verified VASP in the first place, this can be accomplished with a federated multisig approach, where a group of VASPs in a coalition can create an n-of-m member approval process to onboard new VASPs to their coalition. Veriscope makes this possible using Trust Anchoring technology (the underlying Shyft Network infrastructure that supports the coalitions).

What are Trust Anchors, and are VASPs Trust Anchors?

A Trust Anchors is the Veriscope’s naming convention used to classify first-party services and data custodians. A first-party service could be a VASP that provides exchange services to users, or it could be a KYC service provider as another example. In any case, they are regarded as trusted entities that hold data that is highly regulated i.e. “hard” data.
Trust Anchors receive data from data owners, and maintain, review, read, write, confirm, and attest to this data’s validity and existence on behalf of data owners, with the consent of data owners, formulating the basis for digital identity. In the case of VASP’s, data owners are the users of the exchanges.
Trust Anchors are usually regulated entities, and are held responsible for their attestations, formulating the basis for cumulative credibility and reputations. Each Trust Anchor sets their own rules and is fully interoperable with other actors in the Shyft ecosystem.
App Builders may require more information from an end-user that wishes to use their smart app, or may require to see the attested data. To achieve this, Shyft Network will support the creation of a temporary, encrypted, off-chain communication channel between the app-builder and the Trust Anchor; Trust Anchors will then be able to share, release or transmit any data that the End-User has previously allowed, at a cost or fee independently set by the Trust Anchor.

How does Shyft Network mitigate centralization risks?

The Shyft Network is a public blockchain network, without any centralized party in control. Any entity can run a node, and the smart contracts on the network are accessible by everyone. Data attestations can be created by any entity, and relies on the public network to be broadcast and received by other entities on the network. Attestations can come from any member of a coalition, and are not routed through a single centralized member, and are instead broadcast to the blockchain for any entity to verify.

How does Shyft Network mitigate centralization risks?

The Shyft Network KYC Smart contracts were designed to support both the discovery of other VASPs in addition to enabling the data sharing requirements with regards to portable identity, credentials, and compliance with regulations required to meet a variety of standards.
The Veriscope API function calls can be used as endpoints that integrate with other systems and solutions, to create attestations on the Shyft Network as well as validate existing attestations from the Shyft Network for use in other systems. As an open-source solution, and an open blockchain network, the Shyft Network blockchain can be relied upon to query attestations and establish connection to other VASPs for meeting Travel Rule requirements.

How is Shyft Network interoperable with other blockchain solutions?

The Shyft Network achieves interoperability with other networks using a technology bridge known as Byfrost. Byfrost enables cross-chain asset transfer support. Byfrost operates as an internal network of servers, acting as an attestation engine to ensure data availability and synchronization. Byfrost enables interoperable, cross-chain asset transfer and management. Zero-knowledge proofs are utilized to enable secure transfers with minimal friction.
Byfrost allows for portable identity, credentials, and assets to bridge a layer of universality and settlement across all networks that interact with Shyft Network, and all applications that it interacts with. Through this system, Shyft binds web2.0 standards and systems with Web 3.0 infrastructure methodologies.
The bridge allows Shyft Network (and components such as ShyftID) to be useful for users across all networks they engage with. Byfrost is the core layer that enables collaboration and data aggregation and cross system representative consolidation of information and assets. Byfrost connects all data custodians and networks together, such that we can ensure data transportability and user-driven publicly verifiable consent can be guaranteed regardless of the use cases or the environments that Shyft Network is being relied on and used within.

Governance/Onboarding for Veriscope

Background

As you are aware, the Financial Action Task Force issued guidance in June 2019 requiring Virtual Asset Service Providers (VASPs) to share Personal Identifiable Information (PII) and Know-Your-Customer (KYC) / Customer Due Diligence (CDD) data between transacting Originator and Beneficiary “immediately” - that is, simultaneously or concurrent with the transfer itself. Specifically, the guidance stated VASPs should ensure that:

“…originating VASPs obtain and hold required and accurate originator information and required beneficiary information on virtual asset transfers, submit this information to beneficiary VASP or financial institution (if any) immediately and securely”.

The required information includes the:

originator’s name (i.e., the sending customer);
originator’s account number where such an account is used to process the transaction (e.g., the VA wallet);
originator’s physical (geographical) address, or national identity number, or customer identification number (i.e., not a transaction number) that uniquely identifies the originator to the ordering institution, or date and place of birth;
beneficiary’s name; and
beneficiary account number where such an account is used to process the transaction (e.g., the VA wallet). https://www.fatf-gafi.org/media/fatf/documents/recommendations/RBA-VA-VASPs.pdf

While such requirements have existed in traditional financial services for some time, there are numerous challenges brought about by introducing these to the virtual asset industry.

Veriscope powered by the Shyft Network was therefore designed to provide a decentralized solution for the crypto industry to fulfill global compliance standards, including the FATF’s Travel Rule policy.

Veriscope Onboarding Model

In conversations with key partners and stakeholders, it was recognized that part of the solution should account for the processes around the introduction of VASPs to the network and their interaction between participants. Specifically, what types of information must the network participants present to the network, as well as receive from their counterparts, as part of understanding and gaining comfort around one another such that they are willing to proceed with the exchange of information.

It is therefore important that there is strong and inclusive governance and processes for VERISCOPE to build trust amongst participants so that they are willing to transact information with one another.

With this in mind, the VERISCOPE Onboarding model is divided into two parts: the Governance Task Force and the Rules Framework.

While the Rules Framework represents the specific requirements for the VASPs wishing to participate in VERISCOPE, the Governance Task Force/Team is a smaller group which has the responsibility for defining and maintaining the Rules Framework.

This document contains both the Terms of Reference and the Rules Framework. Both governance documents were reviewed and approved by the participants of the VERISCOPE Governance Task Force at their inaugural virtual meeting in Q4 2020.

Governance Task Force

This section contains the Terms of Reference for the Governance Task Force of the VERISCOPE Onboarding Verification model.

Role of the Governance Task Force

The Governance Task Force has the responsibility for defining and maintaining the Rules Framework - i.e. the policies and processes outlining what information VASPs must provide at onboarding, and the rules of engagement related to VASPs verifying one another’s information held on the Discovery Layer. The Task Force effectively acts as the design authority for the Rules Framework.

Through the design of the Rules Framework, the Governance Task Force aims to:

Promote trust and transparency between participants on the network;
Foster verification of VASPs on the network and design processes that facilitate trust and transparency between VASP participants on the network in a safe and secure way;
Monitor and maintain the defined processes to respond to evolving policies, regulatory requirements and/or standards as applicable;
Act as a liaison for VASPs to raise questions and propose changes to the verification methodology as required on an ongoing basis;
Act as a decision-making authority for changes to policies and procedures related to the Rules Framework; and
Act as the kickstarter for the Rules Framework which the VASPs can begin to utilize.

It is anticipated that over time, the VASP participants will become more autonomous in terms of their interactions with counter-parties, and their requirements of each other relating to information presented on the Discovery Layer, but the Governance Task Force is the group which lays the initial foundations from which the VASPs can build over time and oversees and approves changes as needed, including to this Terms of Reference.

Composition of the Task Force

The Task Force consists of representation from the following key stakeholder groups:

Key VASP participants, including representation across the geographic footprint of Shyft’s network participants as well from larger and smaller participating VASPs;
Subject matter expert/Advisor representation in the areas of compliance and AML; and
Infrastructure and technology representation.

As of September 2020, the initial representatives of the Governance Task Force are (listed alphabetically):

Aave
Binance
Bitfinex
Bitmex
Bitsonic
CoinHako
Genesis block
HashKey Pro
Hodlnaut
Huobi
Local Bitcoins
OKex
Paycase Financial
Tether
TokoCrypto
Unocoin

The Task Force is chaired by Rick McDonell (Shyft Advisor) and Josée Nadeau (Shyft Advisor).

Shyft is acting as the Secretariat of the Task Force.

The Task Force may have up to 30 participants, in addition to the Chairs.

At this juncture, there are no set terms for representatives to stay on the Task Force. However, it is envisaged that some rotations and changes in the representation should be considered in due time as the composition of the VASP participants evolves and grows over time, with a view to maintaining a balanced representation (e.g., consider whether more structured regional representation is needed, regional consultative sub-groups or working groups on specific topics).

Communication

The Task Force will maintain regular contact at least on a monthly basis by emails or other medium and via virtual meetings when needed.

Decision-making and reporting

The Task Force will aim to make decisions on a consensus basis, seeking compromises acceptable to all representatives through effective dialogue. In the rare event of an absence of consensus, the Chairs will make a final determination in consultation with Shyft.

Decisions can be made during meetings or in writing on a non-objection basis.
Decisions at meetings require a quorum of 2/3 of the Task Force representatives.
Any decisions by the Task Force related to changes to the Terms of Reference and/or the Rules Framework will be recorded in writing.
The Chatham House rule will apply to the discussion and decision.
Documents approved by the Task Force will be provided to all VASP participants on a timely basis.

A Response by the VERISCOPE Secretariat & Shyft Network

Public Consultation on FATF Draft Guidance: A Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers

April 20, 2021

We appreciate the opportunity to provide comments on the Financial Action Task Force’s (FATF) draft guidance on a risk-based approach (RBA) to virtual assets (VA) and virtual asset service providers (VASP).

In principle, we support the FATF’s overarching objectives of updating its pre-existing Guidance in a manner that maintains a level playing field for VASPs, minimizes opportunities for regulatory arbitrage, and preserves the intended technological neutrality of the FATF Standards. However, in our view, further revisions are required to ensure that the updated guidance achieves these objectives without going beyond the requirements of the FATF Standards or introducing elements that will have undesirable or intended consequences. Our comments on the specific areas of focus identified in the consultation document are outlined below.

In addition, while outside the scope of this consultative process, we encourage the FATF to consider updating its 2015 ML/TF risk assessment before giving consideration to further updating the FATF Standards in relation to VAs and VASPs. An improved, common understanding of the inherent ML/TF risks of VAs and VASPs is fundamental for both the private sector and countries to effectively manage and mitigate ML/TF risks in the sector.

Does the revised Guidance on the definition of VASP provide more clarity on which businesses are undertaking VASP activities and are subject to the FATF Standards?

We appreciate the FATF’s efforts to clarify its ‘expansive’ approach to the definition of VASP to help better identify the regulatory perimeter for VASPs. While the draft guidance represents an improvement, a number of concepts would benefit from further refinement to assist countries and the private sector to better understand the scope of application of the FATF Standards to VASPs.

As per the expanded definition and attempt to clarify what a VASP may be, we see inconsistencies in the way in which a VASP is being presented. The overall guidance discusses at length the concept of key signers or holders of a private key who may be involved in the signing of messages on behalf of smart contracts that are responsible for the movement of assets or data. Paragraphs 61-63, as an example, should have greater clarification as in their current form seems to imply that Decentralized Autonomous Organizations (DAO’s) that have key signers would now place those key signers in the territory of being a VASP. Key signers in this role do not have explicit control over the decision making process, nor do they have an obligation to cease the transference of assets that are being transmitted from the DAO. Rather the role is to ensure security procedures of the smart contracts governance are being fulfilled at the request of voting threshold requirements of the smart contract’s community. This does not give the key signer explicit control to determine whether transmission of funds is acceptable, or allowed, and also does not place the key signer in a controlling position to which they have custodial rights over any of the assets that are placed in that smart contract on behalf of the decentralized community and its governance requirements. With this, we suggest a clarification over the definition of explicit control as to make a distinction between key signers that lack the ability to be a part of the governance decision to transmit assets, and smart contracts that are explicitly under the governance direction of the key signers (a custodial obligation).

We see unintended consequences from this that could move to eliminate key signers from these processes which can further lead to security vulnerabilities at the smart contract level (putting innocent users of these systems at risk), and could introduce innovative obfuscation techniques that further eliminate governance methods that are important roles in transparency and functionality.

It should be noted that in the case of social governance (ie. community run asset pools in protocols such as DEFI) the key signing entities do not have the ability to verify the destinations of fund transmission, and at times these signing parties, through randomization, are involved in blind transmission of assets through autonomous routes.

To apply requirements on parties where the assets move across autonomous, non-user controlled midpoint destination applications (ie. a smart contract like a DAO could have a function for key signers to be community-requested to transmit assets into a multitude of autonomous smart contracts that only after several hops, routes, and movements in and out of other use cases and dapps, eventually land in entirely unknown users wallets) eventually landing in a user’s control, where the key signers sole role is to act on behalf of a community that is requesting the initial hop into a new use case which then eventually end up in another application environment that is user controlled, would become an impossible measure to effectively prevent against, determine risks at the key signer level against, and would be impossible to determine the end destination with any accuracy prior to the end user gaining control or access to those assets. This type of situation is frequent in DeFi applications today and based on the current language and approach in these sections of the guidance, would lead to so much complexity in terms of who is responsible and how that VASP mitigates risks of that transaction that it would be nearly impossible to implement with any level of effectiveness.

We propose a review of the definition of control and the role of key signers entirely in the process of transmission in order to prevent confusion and layers of immense complexity that impedes effective regulatory implementation, other than outright attempts to ban - the level of complexity in practice that this, as demonstrated by the example above, would likely lead to, would likely make bans an easier practice for regulators rather then incentivizing the enablement of technological solutions from within the industry that can provide effective risk mitigation techniques native to the technology itself.

The FATF should look to work in collaboration with the industry at this stage to develop and deploy regulatory protocol infrastructure which can solve for the risks these new technologies pose. The industry has infrastructure that can enable solutions to these issues instead of only looking to add more regulations. With this, we would also propose to have the FATF allow us to demonstrate technology based solutions such as opt-in KYC and identity smart contract tooling that can create compliant liquidity pools and compliant smart contracts that would also allow us to better create effective methods of risk mitigation across the entire infrastructure that is, smart contract and key signer reliant.

The general view in relation to “developers” is very unclear, and the distinction between development companies in contrast to the open source software developers that are individuals, creates a broad view that this paper is set to capture all definitions of the term “developer”.

Oftentimes, individuals all come together to build software and deploy that software. Those individuals are often granted allocations of an amount of the assets upon the software’s deployment. It is unclear as to whether the allocation, which constitutes a financial reward in the future, would imply that even individual persons who have created a monetary benefit from the open use of that system would therefore be considered VASPs.

Through this concept, which is standard across nearly all projects in the industry (dating back to Satoshi Nakamoto), the FATF would capture all independent parties that are developers coming to work on aspects of an open source software project as VASPs in perpetuity as they are directly, or indirectly, apart of enablement of that system. It should be noted that in the event this were to be true, even public protocols that are being designed today to solve FATF guidance and travel rule requirements would therefore be VASPs. This would lead to a massive slow down in current timelines and the ability for the industry to utilize smart contract native systems in enabling effective methods of risk mitigation for regulatory purposes.

This leads to the question of whether or not effective implementation of the open source projects that are being designed to assist the FATF in its efforts to effectively implement these systems, would have the same impact in being effective.

We recommend a redrafting of areas that describe “developers”, in order to make a clear distinction between development companies and individuals who are paid on a transactional fee basis versus other methods.

We also note that the discussion in the draft guidance of the ‘level-playing field’ principle (para 22(c)) appears to contradict the initial risk assessment discussion (para 28). Paragraph 22(c) suggests that countries should treat all VASPs on an equal footing from a regulatory and supervisory perspective when they provide similar services regardless of the business model used. It also indicates that an assessment of risks, based on the nature of the products and services offered, should guide countries in imposing regulation and supervision.

In contrast, paragraph 28 notes that overall risk at a national level should be determined by individual jurisdictions through an assessment of the VASP sector and that different entities within the sector may pose a higher or lower ML/TF risk based on a variety of factors, including business models. This approach is consistent with the FATF Guidance on Risk-Based Supervision, which recommends that supervisors ensure supervisory strategies are kept under regular review to inter alia develop a better understanding of the ML/TF risk profiles of the business models used by regulated entities (para 76).
‍
What are the most effective ways to mitigate the money laundering and terrorist financing (ML/TF) risks relating to peer-to-peer transactions

We understand that peer-to-peer (P2P) transactions between unhosted wallets pose a unique challenge given the general approach in the FATF Standards of placing obligations on jurisdictions and intermediaries rather than individual users of financial products and services. While the FATF is concerned that P2P transactions could pose heightened ML/TF risks if used to circumvent AML/CFT controls placed on VASPs and other obliged entities, this is predicated on P2P transactions gaining widespread acceptance as a means of payment and/or investment.

In our view, the measures and controls in the draft guidance will do little to mitigate the ML/TF risks that may emerge should P2P transactions gain widespread acceptance. The majority of proposed measures would see additional obligations or restrictions placed on VASPs and other obliged entities, which would have minimal impact mitigating the ML/TF risks of P2P transactions between unhosted wallets.

We support the recommendation in paragraph 35 that countries should consider how ML/TF risks of P2P transactions may be mitigated through blockchain analytics and encourage the FATF to further explore with the private sector (e.g., through targeted consultations) how blockchain analytics and other innovative technological solutions can be used to provide greater visibility over P2P transactions between unhosted wallets and to incorporate relevant findings into this guidance. P2P transactions, unlike cash, have inherent features that can be used to mitigate risks and these mitigating measures do not have to be preventive and regulatory in nature, but rather could be in support of the development of financial intelligence and in investigations by law enforcement.
‍
Does the revised Guidance in relation to the travel rule need further clarity?

With respect to the travel rule, further clarity is required around the FATF’s expectations of VASPs when transacting with unhosted wallets. The current drafting of the guidance suggests that these transactions should be treated as higher risk without providing any supporting rationale.

As travel rule solutions go into effect, the risks and identification of non-custodial wallets will further decline as more visibility into the verified intermediaries that currently may be wrongly tagged by analytics tools occurs. As we continue to deanonymize and verify through travel rule obligations on intermediaries and onchain analytics we will have even greater insights into unhosted wallets and will be able to solve a vast majority of the issues present today surrounding the identification of transfer to unhosted wallets. It is our recommendation that we allow time for the industry to get verified and incontrovertible data into these wallets prior to making assumptions on the risk profiles of these wallet types.

We already know today that the vast majority of liquidity enters the ecosystem through the VASPs and then exits again through these onramps at a later date.

We also rely on VASPs today to properly act as the verifying entities of the largest amount of KYC’d users in the space. A change to the liquidity flows of these venues will lead to new methods of onboarding that may lack compliance controls and centralized data storage. This can lead to an inability for law enforcement and FIU’s to rely on the data and reporting of licensed VASPs as the primary onramps into the ecosystem.

We propose that the FATF allow time for travel rule solutions to work directly on unhosted wallet discovery as well as VASP discovery before determining risk profiles and mitigation methods that may inaccurately assume the risk and therefore hinder growth.

To add to the overall discussion of the unintended consequences of VASP to unhosted wallet interaction, we believe that we could face liquidity issues if restrictions on the deposit and withdrawal of assets were to be limited. To enable the blocking of liquidity deposits and withdrawals could lead to severe systemic risks in the underlying liquidity of spot venues that currently act as essential data services to things like ETF’s and other market functions. As institutional adoption has greatly accelerated over the last 12 months, efforts to block liquidity onramps could create unknown consequences that could cripple financial markets that are now relying on global, compliant, spot market liquidity flows.

The inability for spot market liquidity to properly move in and out of VASPs can lead to consumer protection risks in traditional capital markets, as well as will further lead to hurting consumers as liquidity imbalances reduce proper price discovery in markets. This would also further create the push towards less centralized vasp liquidity pool indexes, which would have very bad consequences in complaint liquidity pool regulation (this moves liquidity into dex’s as the primary spot market benchmark).

Moreover, a number of the possible mitigations proposed in the draft guidance do not seem appropriate or justified (e.g., denying licenses to VASPs that transact with unhosted wallets (para 91(c)), prohibitions on unhosted wallets (para 180)) and should not be implemented by jurisdictions before carrying out a thorough assessment of the inherent ML/TF risks as required under Recommendation 1 (as noted in the FATF’s various risk-based guidance including the recent guidance on risk-based supervision). Only once such an assessment has been completed should jurisdictions consider what mitigations are appropriate to address identified higher risks.

More broadly, we submit that the draft guidance places an over-emphasis on the use of preventive measures, in general, and relation to unhosted wallets, in particular, without giving full consideration to the full toolkit available to authorities (e.g., financial intelligence generated by the FIU and the role of law enforcement agencies) to address relevant ML/TF risks. Coupled with the severe nature of some of the proposed mitigations contained in the guidance, we are concerned that the FATF’s efforts may create perverse incentives for VA users to shift away from regulated entities and increase use of P2P transactions further limiting the line-of-sight authorities would have on illicit VA-related activities.
‍
Does the revised Guidance provide clear instruction on how FATF Standards apply to so-called stablecoins and related entities?

The revised FATF Guidance is generally helpful in confirming the applicability of VASP regulations to stablecoin issuers. However, when it comes to the specific details of comparing stablecoin issuers to other VASPs, particularly for the purpose of conducting an AML/CFT risk assessment, there are several aspects of the Guidance which appear to reflect a misunderstanding of how centrally administered stablecoins function. We believe that conducting an accurate risk assessment of stablecoins is contingent upon having a thorough understanding of how these products currently function, in practice.

a) Re: Purpose of Stablecoins (Box 1)

In the first sentence of “Box 1”, a suggestion is made that “stablecoins purport to overcome the price volatility issues associated with VAs by maintaining a stable value relative to some reference asset or assets.” This may be an accurate description of one of the features of stablecoins, but it is certainly not the purpose of stablecoins, nor the reason they exist. The reason for their growth and adoption is simple: relative to traditional cross-border banking, stablecoins offer a superior product (speed, reliability) at a much lower cost. By suggesting that the purpose of stablecoins is to address a problem with virtual assets, when in reality they were explicitly created to overcome problems with cross-border banking, the Guidance has relegated itself to a discussion only of the cons (risks).

b) Re: Characterization Stablecoin Issuers (Para. 72-73)

The Guidance suggests that multiple entities in any given “stablecoin arrangement” could be classified as a VASP and thus also have AML/CFT obligations. It is not clear at all why related entities other than the customer-facing entity, which collects customer data to comply with AML/CFT regulations and conducts transfers and services, should be considered a VASP for the purpose of this Guidance. For entities that perform stablecoin functions such as treasury management: (1) there are no comparable AML/CFT risks related to this activity; (2) most VASP responsibilities such as performing KYC, CDD, EDD, filing SARs, and documenting these processes are not pertinent; and (3) registration with a local regulator would serve no purpose with respect to transferring any information respecting AML/CFT risks.

In our view, it should only be necessary for the legal entity which performs compliance functions to be classified as a VASP and be registered with a pertinent authority. This would allow: (1) for all customers to be verified; (2) for all customers, transfers and counterparties to be risk rated; (3) for SARs to be filed when appropriate; (4) for these processes to be documented; and (5) for relevant information to be transferred between VASPs or pertinent authorities and for all other relevant FATF recommendations to be observed. Forcing irrelevant persons or entities to be labeled VASPs and therefore to register with pertinent authorities would amount to a waste of time and resources not only for the private sector, but for the public sector as well.

We believe that such a position is rooted in a misunderstanding of how existing centrally-administered stablecoins function today, particularly with regards to the “stabilization mechanism”.

c) Re: “Stabilization Mechanism” (Para. 122)

The revised Guidance distinguishes stablecoins from other virtual assets based on the existence of a “stabilization mechanism” and makes reference to the ML/TF risks associated with this mechanism. While we certainly agree that the distinguishing feature of stablecoins can be accurately described as a “stabilization mechanism”, the revised Guidance uses language that appears to reflect a misapprehension of how this process works in the context of currently operational and prominent centrally administered stablecoins. Since the Guidance requires that the “stabilization mechanism” be considered when performing an assessment of the risks associated with stablecoins, we believe it is important that this mechanism is adequately explained and understood. The following points will resolve the apparent confusion surrounding this concept:

First and most fundamentally, the Guidance describes the stabilization mechanism as a “technical feature” of stablecoins. This might be an accurate way to describe the “stabilization mechanism” of “algorithm-backed” stablecoins, but the stabilization mechanism of currently operational and prominent centrally administered stablecoins is a decidedly non-technical feature. Technology is undoubtedly involved, but the “stabilization mechanism” itself is not a mechanical process or set of rules, but rather a system of market-driven incentives that is generally known as “market-based price discovery”.

The “stabilization mechanism” of currently operational and prominent centrally administered stablecoins is best described by considering its two parts: (1) the ability to be issued and redeem tokens from the issuer (Primary Market), and (2) a decentralized, market-based system of incentives (Secondary Market). Strictly speaking, it is interactions between Primary and Secondary markets that keep prices stable in these latter markets, with the issuer’s peg being what keeps prices stable in the Primary Market. The Secondary Markets are where most trading occurs, but what keeps prices stable in these markets is the independent participation by Primary Market participants, who are incentivised to seek arbitrage profits.

Only prices in the Primary Market can be said to be “managed” by the stablecoin issuer (by processing issuances and redemptions at the pegged rate). But most trading occurs in Secondary Markets, where prices are kept stable by the arbitrage activity of Primary Market participants. This is neither a “managed” nor “delegated” process. It is a decentralized process that can be carried out by anyone who can participate in both markets (users who are KYC-verified with the issuer and thus can participate in the Primary, as well as Secondary markets). Importantly, there is neither coercion nor contractual reliance on any single Primary Market participant.

Since these users must all be KYC verified by the stablecoin issuer, this aspect of centralized stablecoins is already fully covered by existing AML/CFT laws. As such, the “stabilization mechanism” of centrally administered stablecoins does not require any special attention or additional consideration by domestic law makers who are working to address AML/CFT concerns. The reserve assets held by stablecoin issuers are analogous to those held by other VASPs. If anything they would be safer, due to the lower proportion of digital assets, and higher proportion of fiat assets, being held by the stablecoin issuer. As well, many stablecoin issuers offer varying examples of transparency of their reserves that no other VASPs or financial institutions offer.

Given this apparent misunderstanding of how the most popular existing stablecoins function, FATF is perhaps not in a position to make any more specific determination then that stablecoin issuers are VASPs. Moreover, the designation of stablecoin issuers as VASPs is sufficient to ensure that they adhere to AML/CFT controls outlined in the FATF Recommendations.

d) Re: Risk Assessment of Stablecoins (Para. 224 & Box 4)

The Guidance suggests that stablecoins may pose a higher risk than other virtual assets, but it is unclear as to why this might be the case. The only explanation offered for this heightened risk is the prospect of widespread adoption. While we agree with the general idea that should risk exist, it would be greater with more widespread adoption, this reasoning cannot substitute for an analysis and description of the risk itself. In the context of AML/CFT, there is nothing about stablecoins that would cause them to pose any greater risk than other virtual assets. The Guidance acknowledges that the stabilisation mechanism is the distinguishing feature of stablecoins but, as explained above, there are no additional AML/CFT concerns associated with this characteristic.

While we appreciate efforts by regulators to be forward-looking, we believe, as mentioned above, that the rule-making process should be primarily based on how the currently existing stablecoins function. Recommendations should not be designed to suit one hypothetical business model of a large technology, telecommunications or financial firm. While the business model highlighted in Box 4 might result in widespread adoption, it is not clear that this would happen in jurisdictions with modern financial service infrastructures. Importantly, this business model is not pertinent to currently operational and prominent centrally administered stablecoins, which is predominantly geared towards the trading of virtual assets.

Stablecoin issuer risks respecting AML/CFT are best mitigated by individual jurisdictions using a risk-based approach: creating more controls only when warranted by the risks posed by stablecoin issuers. We believe that proposing regulations for all stablecoins based on the hypothetical business model in box 4 is tantamount to regulating technology (by regulating a stabilization mechanism that is in actuality non-technical) and is inconsistent with both a risk-based approach and the principle of a level playing field.

Is the revised Guidance sufficient to mitigate the potential risks of so-called stablecoins, including the risks relating to peer-to-peer transactions?

Our position is that the risks of stablecoins and their issuers are analogous to the risks of VAs and other VASPs, and that prior guidance was already sufficient to mitigate these potential risks. New recommendations by the FATF necessitate an updated risk assessment of this sector. As for the risks related to peer-to-peer transactions, please refer to our response to Question 2 above.
‍
Further comments and specific proposals to make the revised Guidance more useful to promote the effective implementation of FATF Standards

Licensing or Registration of VASPs

In accordance with paragraph 3 of the Interpretive Note to Recommendation 15 (New Technologies), VASPs should be required to be licensed or registered in the jurisdiction(s) where they are created. Jurisdictions may also require VASPs that offer products and/or services to customers in, or conduct operations from, their jurisdiction to be licensed or registered in this jurisdiction.

Paragraph 119 of the draft guidance suggests that authorities may impose conditions on VASPs seeking a license or registration to be able to effectively supervise the VASPs. Suggested conditions, depending on the size and nature of the VASP activities, include requiring a resident executive director, a substantive management presence, specific financial requirements and/or certain disclosure requirements for marketing materials.

In our view, the suggested conditions proposed in the draft guidance are a mis-adaptation of prudential and market conduct requirements for traditional financial institutions and are not fit for purpose in an AML/CFT context for the VASP sector. Moreover, imposing residency requirements on VASPs does not maintain a level playing field with other AML/CFT-obliged entities, particularly, persons that provide money or value transfer services (MVTS). As with MVTS providers, VASPs may have no physical presence in the country where a transaction is sent or received.

In this scenario, rather than imposing residency requirements, the FATF Guidance on a RBA for MVTS encourages competent authorities in the host and home jurisdictions to liaise as appropriate to ensure any ML/TF concerns are adequately addressed. We believe that this would be a more appropriate approach in the VASP context that would ensure a more level playing field among AML/CFT-obliged entities and would reinforce the FATF’s principles of information-sharing and co-operation amongst VASP supervisors set out in Section VI of the draft guidance.

Assessing ML/TF Risks of VAs and VASPs

We note that the draft guidance reaffirms the FATF’s requirements under Recommendation 1 that both countries and private sector entities identify, assess and understand ML/TF risks and ensure that those risks are mitigated effectively. However, the relevant sections of the draft guidance (Initial Risk Assessment – para 28 onwards and Application of the Recommendations in the Context of VAs and VASPs) seem overly focused on the perspective of countries and on the mitigation of risks. It is also unclear at times whether the guidance is referring to inherent or residual risks.

At this stage, there is little new information in the guidance that would help the private sector (and competent authorities) to identify, assess and understand their ML/TF risks. In our view, the FATF’s 2015 ML/TF risk assessment in the context of Virtual Currencies no longer provides a sufficient basis and, as such, an expanded discussion of the inherent ML/TF risks of VAs and VASPs in the draft guidance would be beneficial for both the private sector and countries to be able to appropriately consider, develop and apply the mitigating measures described therein. This consideration is particularly important for the rapidly growing and evolving VASP sector, which, unlike the traditional financial sector, has not benefited from the development of effective controls taking place over several decades as countries’ and the private sector’s understanding of ML/TF risks matured.

Industry stakeholders are initiating a risk assessment exercise and would welcome dialogue with the FATF before the completion of new guidance or further requirements for the VASP sector.

Supplementary Views and Additional Points

As it pertains to the overall topic of DeFi, and the approach to effective regulation, we believe that the FATF will likely need a fundamentally different approach to regulation. When it comes to decentralized systems and smart contracts that do not, and cannot, centralize the data collection and compliance processes that traditional intermediaries hold, we need to look at new approaches to compliance and KYC verification.

Systems are being built today that allow us to decentralize or passport the identities and KYC data sets of users across smart contracts and noncustodial wallets. We believe that the only way to effectively enable compliance in this new realm is to allow for data-collecting centralized intermediaries, to be able to represent users and act as data custodians of that data, while allowing users to passport across decentralized applications. These systems can allow us to have source nexus points for user validation and onboarding, but still allow those users (represented by the public addresses they use today to move assets) to utilize smart contract applications while leveraging reliance on the source data stores and validating onboarding entities. This will be the future of how compliant opt-in systems work across this ecosystem, and can solve many of the largest risks and threats that are inherent from a AML/CFT perspective.

While this infrastructure is currently being developed in systems like Shyft Network among others, we believe that users should not be required to take on compliance or sanctions obligations directly. These systems, when they are solely in the non-custodial realm, are extensions of bearer instruments like cash, and effective regulation needs to focus its efforts on the on-ramps and off-ramps (like that of the traditional financial system) without requiring innocent civilians to take on compliance obligations and the responsibility of sanctions requirements.

Decentralized systems should be looked at largely as public utilities and enhancements to the utilization of digital bearer instruments that are designed to invoke user freedom and the betterment of individual choice, while still ensuring law enforcement has the ability to effectively address illicit activity. Our ability to ensure these networks do not unintentionally transition to deeper levels of obfuscation is critical in this current time to ensure we can maintain visibility and transparency into how these networks publicly function. Regulations can help maintain this visibility in collaboration with this technology, or hinder it if we do not act collaboratively and cautiously to nurture its benefits.

We welcome the opportunity to further discuss and demonstrate new technology solutions and methods being designed and developed that may offer technological supplements and alternatives to this guidance. New infrastructure coming into the market presently will help the FATF to mitigate the risks, while also ensuring the global economy can capture the benefits this new technology has to offer.

What is Veriscope? Why are we on this mission?

Stay informed and never miss a Shyft update!