Most people who are active in the use or application of blockchain technology, or who have lived through the development of the activity in the space, are more and more aware of the development of regulatory infrastructure intended to support this. However, many are not fully aware of the developments that are occurring in different parts of the world, how this is intended to, or may capture, the activity of a business or some of the complexities also developing within these frameworks.
Historically the trend in respect of the regulatory consideration points can be summarised in a few short sentences. Firstly, the starting point for many is that technology should be agnostic from a regulatory perspective. The ‘decentralised’ tag, or DeFi principle should mean that there is no centralised control point, and by building a business based on the concept of decentralisation, there will not be any regulatory triggers. Secondly, that almost all activity using the technology may be interpreted as falling within an existing or ‘legacy’ framework. That is, that by offering a form of interpretation of existing law, this can be applied to a new and emerging business regardless of the fact that it is built on new technology, and can be controlled in a way that fosters innovation. Thirdly, that so long as the virtual asset, token, or tool does not qualify as a transferable security, or financial instrument, then there will be no form of regulation that will apply to the business.
Unfortunately for many, all three of the above are incorrect. For some, the decentralisation or DeFi concepts or wording are used only with the concept of a ‘principle’ for decentralisation being understood. Adding the word ‘Defi’ or ‘DApp’ to a business or project does not make that business a public software platform, and publishing the underlying code of the platform on github does not automatically avoid all responsibility, regulatory or enforcement triggers. There are a number of complexities that can tie into a proper assessment of such a business and enforcement proceedings in some jurisdictions have already highlighted this. What is quite clear though is that any platform which calls itself a DEX or decentralised exchange, or any smart contract based exchange system built on the ‘code is law’ principle, does not bring itself outside of the scope of law or regulation. That is of course not to say that real decentralised concepts cannot exist, but the tests around this are significant and more than a simple branding exercise.
In respect of the development of legal infrastructure beyond the scope of legacy frameworks, this is already happening. Historically, certain exchange platforms may have been captured within payment services rules and regulations in certain jurisdictions (and not in others, despite the fact that the same European law had been transposed into all EU countries). Similarly in the USA, defining the concept of virtual currency as money, automatically triggered Money Services Business requirements, but are MSB laws built to deal with a cryptocurrency exchange or trading platform? Arguably not. Regardless of any of the above, and regardless of the virtual asset categorisation exercises that have helpfully taken place in a few jurisdictions, drawing distinctions between exchange, utility, and security or e-money/payment tokens, most are aware of the published Financial Action Task Force (FATF) Recommendations of June 2019. The specific amendments to the 40 recommendations adopted at the plenary last year include the requirement for countries to apply the relevant measures under the FATF Recommendations to virtual assets and virtual asset service providers (VASPs).
This includes the requirement for VASPs to be licensed or registered in the jurisdiction where they are created, and that they are subject to adequate regulation and supervision or monitoring for AML/CFT. But what does licensing or registration actually mean, and when does a global facing virtual asset based business trigger different licensing requirements in different jurisdictions? The FATF Guidance for a Risk-Based Approach to VASPs suggests that VASPs should be required to meet ‘registration criteria set by relevant authorities’ and also cites the fact that authorities should ‘impose such conditions on licensed or registered VASPs to be able to effectively supervise the VASPS. Such conditions should allow for sufficient supervisory hold and could potentially include, depending on the size, nature of the VASP activities , requiring a resident executive director, substantive management presence or specific financial requirements.’
These are of course very basic and there are other small jurisdictions, such as Gibraltar, who have built out regimes that go far beyond this for VASPs with principles relating to customer care and communication, adequate risk disclosure, specific suitability analysis in certain cases, regulatory capital adequacy requirements and financial and non-financial resources, business continuity, contingency and insurance requirements, specific governance arrangements, requirements around systems and security access protocols, including cybersecurity and IT vulnerability penetration testing, risk management, client asset protection and segregation, and specific financial crime provisions.
Will there be global standards for VASP licensing or Regulation moving forward? Or will there even be a global agreement on what actually triggers the definition of a VASP, which in certain circumstances may be open to interpretation? This is critical as one of the FATF Recommendations, namely Recommendation 16 applies the ‘Travel Rule’ concept that has existed in the fiat/swift network world since 1998 for the collection, retention and transmission of information on fund transfers, to virtual asset transfers between VASPs. This may sound simple but the base layers of understanding what constitutes a VASP, whether that VASP is registered or licensed as a VASP, and how to deal with transactions that are captured (VASP to VASP) which are not captured (VASP to private or unhosted wallet), and how to deal with the transmission of data between these entities is not simple. Locking personal or private data directly into an immutable public record simply does not work from a data protection perspective.
Referring to data protection or GDPR in a blockchain context has a number of other interesting points of consideration which cannot be covered here but it does highlight the third point originally raised in the context of applicable legal considerations to businesses and concepts using to take advantage of the technology. This goes well beyond GDPR to wider global payments infrastructures and networks such as Libra, or the different CBDC initiatives underway. Do all these concepts work within legacy frameworks or is it time for law and regulation to evolve at the same speed as the underlying tech.