We’ve had a number of people ask us about the FATF interpretive note that will be coming out this year and how it may change anti-money laundering (AML) law with respect to cryptocurrencies. Here’s what you need to know.

What is the FATF and what is happening?

The Financial Action Task Force (FATF) is an intergovernmental organization that has worked to harmonize AML laws around the world since its founding in 1989. Periodically the FATF issues new recommendations and interpretations to its member nations, and in this cycle they are going to include an interpretation of Recommendation 15 (new technologies) that will detail their preferred policy towards cryptocurrencies.

Good news: No major departure from current FinCEN policy

So far as we can tell, the interpretation will not call for any substantial departure from current US policy that has been in place since 2013. That policy was clarified this past April in guidance from FinCEN that, on the whole, we think is fair and clear. FinCEN rightly focuses its policy on custodial intermediaries and avoids extending surveillance obligations to persons who merely write software or contribute to network infrastructure. Therefore, to the extent the FATF interpretation matches FinCEN’s policies, we don’t perceive any meaningful threat or impediment to the continued vibrancy of cryptocurrency technology.

Middling news: A somewhat vague definition of who is regulated that should be narrowly interpreted

The FATF recommendations include a glossary of terms. Within those terms is a definition of Virtual Asset Service Provider (VASP). The recommendations urge member nations to regulate VASPs as obligated parties within a financial surveillance regime. Therefore this definition is consequential: if you fit the definition, then you have to surveil your customers, if you don’t, then you don’t. Think of it as the FATF equivalent to FinCEN’s distinction between “exchangers” and “users” of virtual currency. Only “exchangers” (FinCEN’s term) and “VASPs” (FATF’s) must register and collect customer information; users are not regulated.

Most of the definition of VASP focuses on trusted parties within cryptocurrency networks who safeguard or administer customer assets. The definition also, however, includes persons who “transfer” virtual assets. That’s a vague term. As we have done with FinCEN in the context of that agency’s definition of money transmission, we will continue to advocate that “transfer” only means to take actual custody of the asset (at least briefly) on behalf of a customer in order to send it to someone else. That way we can be sure that folks like miners and node operators are not within the scope of regulations and subject to burdensome and ill-fitting requirements.

Of course, we’d be more comfortable if “transfer” simply wasn’t in the definition of VASP at all, but the FATF has closed that definition and is no longer seeking private sector feedback on it; there’s little we can do until the next recommendation cycle and, as I just mentioned, it is not too concerning as long as it’s interpreted narrowly and reasonably.

Not news: The wire transfer rule is not an issue for the underlying protocol and basically seeks parity with the US travel rule

The FATF has sought private consultation on the so-called “wire transfer rule” portion of the interpretation. The wire transfer rule is equivalent to the “travel rule” here in the US. It deals primarily in what customer information one VASP would have to convey to another VASP during a transfer of cryptocurrency. As with the US travel rule, the wire transfer rule only applies to regulated entities (in this context, VASPs), so individual users of cryptocurrencies would not be bound by it.

Travel rule compliance is a non-trivial issue for custodial exchanges to figure out. For example, if exchanges are obligated only to send customer information to other exchanges, and a customer simply asks the exchange to send bitcoin to an otherwise unidentified Bitcoin address, then how does the exchange know whether that Bitcoin address is an exchange or an individual? How do they know whether to send customer information forward or not? It’s a rule that was clearly developed in a time before cryptocurrency networks and should be revisited. In the meantime, exchanges have been working on solutions to comply with this rule.

Two things stand out about the proposed wire transfer rule. First, it would only apply to custodial businesses, not to persons who are merely writing software, to persons providing non-custodial services, or to the network itself, which are the primary areas of focus for Coin Center. Our concern with laws and policies that affect custodial businesses is generally that they should be no different than what applies to non-crypto businesses, which is the case here. Second, this recommended rule is not really a new requirement, at least not in the United States. Exchanges in the US have been subject to the travel rule for quite some time now, and the FATF is simply recommending that such a rule be adopted by other countries. Given that the recent consultation was limited to discussion of the wire transfer rule, and given that affected members of the industry were already engaged on the issue with the FATF, we opted not to participate.

Bad news? The UK might be reading too much into the recommendations, Coin Center filed a comment



One thing that does concern us is that the United Kingdom’s HM Treasury, in a recent consultation on implementing the European Union’s Fifth Money Laundering Directive (5MLD), used the upcoming FATF recommendations as justification for potentially expanding the scope of AML regulation to non-custodial service providers and even open source software developers generally. We have no idea what in the recommendations would justify that. To us, the definition of VASP definitely does not extend that far, even though it is admittedly vaguer than we would like. If it did, then merely contributing code to the Bitcoin or Ethereum reference client repositories could earn you the obligation to know the names and personal details of everyone who uses those networks. That, of course, makes no sense practically, and, philosophically, such a policy would gravely damage innovation and the emergence of privacy protecting tools that can be a bulwark for liberty and a check against totalitarianism and corporate data exploitation.

Our filing in the UK consultation explains why regulating open source software developers and persons facilitating decentralized exchange would be an overreach and potentially in violation of the International Covenant on Civil and Political Rights (ICCPR) and the European Convention on Human Rights (ECHR). Being as all the FATF member nations are party to at least the ICCPR, the same arguments about unreasonably broadening the scope of AML laws in the United Kingdom would apply to any other country seeking to use the FATF recommendations as an excuse to regulate open source software development or non-custodial entities.