https://www.cryptolaw.one/fatfs_updated_guidance_on_virtual_assets_and_defi-2/

The Financial Action Task Force published its updated Guidance on ‘Virtual Assets (VAs) and Virtual Asset Service Providers (VASPs). Initially planned for June, the Guidance follows a period of public consultation and fierce criticism from the crypto industry. Although the Guidance is non-binding, it is still likely to be influential as a supra-national standard: regulators around the world are looking for greater legal clarity on how existing rules can be applied to cryptoassets in general, and decentralized finance (DeFi) in particular. Having a supranational standard, albeit non-binding, is therefore very likely to set the benchmark for further discussions on anti-money laundering (AML) and crypto.

Ransomware, crime and virtual assets

FATF found “large increase in the use of VAs to collect ransomware payments” and commit other types of crime in recent years and months. Without virtual assets, FATF said, those crimes “would be much harder to monetize.” Jurisdictional arbitrage and anonymity-enhancing tools increase the risk of cryptocurrencies being used for money laundering or terrorist financing purposes.

DeFi

One of the thorny issues on FATF’s plate was how its AML rules can be applied to peer-to-peer (P2P) networks – and if they should be applied in the first place. FATF received much pushback from the crypto industry, and DeFi participants in particular, for its expansive view of how AML rules should apply to DeFi.

Ultimately FATF toned done some of its initial proposals, although the language is still (purposefully) broad.

FATF’s views any transfer of VAs without the use of a virtual asset service provider (VASP) or other obliged entity as a P2P transaction. A transfer of virtual assets between two unhosted wallets, whose users are acting on their own behalf, is a clear example.

If there is no regulated intermediary (an ‘obliged entity’ under FATF’s AML rules), then do these AML rules apply at all?

FATF acknowledges that “P2P transactions are not explicitly subject to AML/CFT controls under the FATF Standards. This is because the Standards generally place obligations on intermediaries, rather than on individuals themselves”. Yet, it still warns about the risks that P2P transactions pose for money laundering and terrorist finance.

On the positive side, however, the transparency of P2P transactions on public ledgers (such as DeFi transactions) “might support financial analysis and law enforcement investigations, especially when combined with other information sources”, FATF acknowledges.

FATF took into account concerns over its vague language on persons merely “facilitating” certain DeFi transactions and now requires “active” facilitation for DeFi participants potentially to be covered by its guidance. FATF uses the concept of “control or sufficient influence” over VAs or a DeFi protocol: a DeFi application “is not a VASP under the FATF standards”, FATF’s guidance states, but “creators, owners and operators or some other persons who maintain control or sufficient influence in the DeFi arrangements, even if those arrangements seem decentralized, may fall under the FATF definition of a VASP where they are providing or actively facilitating VASP services”.

This increases the threshold, but still leaves open the important question of what control or sufficient influence is.

US-based Coin Center offered: this useful summary on DeFi, multi-sigs, governance and control:

“The guidance still has vague and inconsistent statements about multi-sig arrangements. It does now appear to exclude multi-sig wallets where the customer retains the exclusive ability to control their funds: “if a person maintains unilateral control of their assets at all times, this may indicate that the service provider is not providing a qualifying service.”

This would likely mean that wallet providers who retain mere back-up keys are not covered. However, the language waffles: “it could still fall under [the definition of VASP] where it actively facilitates the transfer.” We still don’t know what is intended by “actively facilitates.” This phrasing is perhaps better than the previous draft which was simply “facilitates” on its own, but the addition of “actively” merely gives us a slightly different flavor of uncertainty about who is meant to be included.

With respect to DeFi the new guidance remains overbroad. In particular “any party profits from the service or has the ability to set or change parameters” is still treated as potentially included in the definition of VASP.

Finally, there’s new language about “control of a VASP” that is “available for purchase to the public, for instance through governance tokens.” That’s an extremely vague and confusing sentence from a technological standpoint. The nature of the legal obligations and liabilities of governance token holders is, in most jurisdictions, as of yet utterly undefined in law. The new guidance does suggest that at least some “governance token” holders are not going to qualify as VASPs: “An individual token holder in such a scenario does not have such responsibility if the holder does not exercise control or sufficient influence over the VASP activities undertaken as a business on behalf of others.” However, “sufficient influence” is hardly a justiciable standard.”

Even if there is no person with “control” or sufficient influence, that’s still not the end of the matter for FATF. In such cases, countries “may consider the option of requiring that a regulated VASP be involved in activities related to the DeFi arrangement”. But how would that work? What would happen if a country requires a bank or payment processor somehow to be involved in transactions on MakerDAO or Uniswap?

The guidance is not clear how this would work in practice, but it’s clear FATF is unwilling to accept that even a DeFi network without any person in “control” could remain outside of the regulatory perimeter.

Developers of unhosted wallet software will rejoice: “software developers or providers of unhosted wallets whose functions are only developing and/or selling the software//hardware” will not normally be covered by the guidelines.