FinCEN’s new cryptocurrency guidance matches Coin Center recommendations

Today the Financial Crimes Enforcement Network (FinCEN) issued new guidance on how the Bank Secrecy Act (BSA) applies to cryptocurrencies and its users. Here’s our initial analysis of that guidance which, on the whole, we find thoughtful and on-the-mark (note: the PDF is on their website although there’s no press release yet). The guidance makes explicit several interpretations for which Coin Center has long advocated, such as clear statements that software wallet providers, multi-sig providers, decentralized exchanges, and other non-custodial services are not regulated as money transmitters.

Software Wallets and Multi-Sig Providers

First, let’s look at how the Guidance applies to software wallets and multi-sig providers. Section 4.2.1 states that software wallet providers (i.e., “non-custodial” or “unhosted” wallet providers) are not regulated as money transmitters. And section 4.2.2 states that multi-sig providers without the ability to (unilaterally) transact are also not regulated as money transmitters. Neither of these two conclusions are surprising, but it’s great to see them spelled out by FinCEN.

Coin Center has argued since 2014 that non-custodial wallet providers and multi-sig providers, because they do not have sufficient credentials to unilaterally execute or prevent transactions, are never able to accept or transmit currency or currency substitutes and therefore could not and should not be a “money transmitter” (a type of Money Service Business (MSB)) under the BSA’s implementing regulations, which require acceptance and transmittal. Today’s guidance is the first time FinCEN has made that interpretation clearly and explicitly in guidance.

Describing minority key-holders, the Guidance states: “the person participating in the transaction to provide additional validation at the request of the owner does not have total independent control over the value.” And if you develop the multi-sig wallet software and limit yourself to providing this “additional validation” (e.g., Bitgo’s multi-sig wallet product) then you are not an MSB. As the Guidance states:

If the multiple-signature wallet provider restricts its role to creating un-hosted wallets that require adding a second authorization key to the wallet owner’s private key in order to validate and complete transactions, the provider is not a money transmitter because it does not accept and transmit value.

On Privacy-Preserving Cryptocurrencies and Services

Next, let’s look at what the Guidance says about privacy-preserving cryptocurrencies like Zcash and Monero, as well as privacy-preserving services like tumblers. Section 4.5.1 states that mere developers of cryptocurrencies or protocols are not regulated as money transmitters. This section draws a critical distinction between those who provide services that can anonymize cryptocurrency payments and others who only provide software. In both cases the Guidance seems to be considering tumblers and mixers as well as dedicated privacy-preserving cryptocurrency networks. For example, one can imagine a mixer service provider (which receives coins from users, shuffles all the coins, and sends them back to its users) on the one hand, or one can imagine mixer software (which is merely a protocol that allows participants in a mix to move money to and from each other without any service provider in the middle e.g., TumbleBit protocol) on the other. Similarly, you could have privacy-preserving cryptocurrency software (e.g., Monero or Zcash) on the one hand, and on the other a centralized service (like Liberty Reserve or e-Gold) with no internal records kept of user transfers.

What’s significant about this distinction is that, according to the Guidance, service providers are money transmitters and software providers are not. Again, this is not a surprising interpretation and it is one for which Coin Center has long advocated, but it is excellent that FinCEN explains it all and offers clarity to mere developers of these highly significant privacy technologies. The Guidance states clearly:

An anonymizing software provider is not a money transmitter. FinCEN regulations exempt from the definition of money transmitter those persons providing ‘the delivery, communication, or network access services used by a money transmitter to support money transmission services.’ This is because suppliers of tools (communications, hardware, or software) that may be utilized in money transmission, like anonymizing software, are engaged in trade and not money transmission.

That said, Section 4.5.2 of the Guidance makes clear that developers of cryptocurrencies or protocols can be money transmitters if they engage in other activities like selling their coins to the public in order to help the public move money through their systems.

As we explained in our 2017 BSA report, drawing the line here is difficult. When Ripple Labs was selling XRP to the public in ongoing sales after the network was running, were they doing it on their own behalf? Or were they doing it to help others move money through the XRP protocol? When FinCEN brought an enforcement action, Ripple settled out of court. So this question was never litigated and we never learned what kind of factual indicia would indicate that you were transacting on your own behalf vs. onboarding folks onto a network whose software you helped develop. More generally, all trades are reciprocal and mutually beneficial, that’s just the nature of trade. So, how can we ever really know if you are merely selling a currency substitute on your own behalf and not as a service for your trading partner—thereby providing money transmission services?

This will likely remain a contentious area. However, merely selling some of your own Monero or Zcash in order to buy a wristwatch or to pay a software engineer whom you employ seems to be out (not money transmission), and that seems to be true even if you also happen to be one of the lead developers of the Monero or Zcash protocol software (or a corporate entity or legal person doing the same): you are not transmitting money for anyone else, but rather engaged in transactions on your own behalf.

Section 4.5.3 states that exchanges are not per se banned from using privacy-preserving cryptocurrencies but will need to comply with the same BSA regulations they comply with for typical cryptocurrencies. We believe that this is possible. Exchanges need to know their customers but they do not have a black letter law requirement to know the customers of their customers. In other words, a bank needs to know who you are but they are not obligated to know the name and address of people that you pay using cash you withdraw from your account.

Decentralized (i.e., Non-Custodial) Exchanges

Section 5.1 states that decentralized exchanges (DEXs, i.e., non-custodial exchanges) are not regulated as money transmitters. This is another interpretation of the rules for which Coin Center has long advocated, and are gratified to see that FinCEN is now offering very clear guidance:

[I]f a CVC trading platform only provides a forum where buyers and sellers of CVC post their bids and offers (with or without automatic matching of counterparties), and the parties themselves settle any matched transactions through an outside venue (either through individual wallets or other wallets not hosted by the trading platform), the trading platform does not qualify as a money transmitter under FinCEN regulations.

That is well-put.

Initial Coin Offerings

Section5.2 states that Initial Coin Offering (ICO) sales are probably money transmission but will be regulated by the SEC if they are sales of a security. This section is complicated, and I’m still a bit perplexed by it. What’s interesting is that FinCEN here creates a distinction between two types of ICO. One seems to be a description of a typical offer of new or soon-to-be developed tokens to the general public:

[C]onducting a preferential sale of [convertible virtual currency (CVC)] to a select group of buyers (sometimes referred to as investors) … The CVC and its application or platform may be already operational or it may be the seller’s purpose to use the value received from the sale, in whole or in part, to develop such CVC, application, or platform.

While the second type seems to be more like a so-called SAFT sale:

Raising funds by offering digital debt or equity instruments among a group of lenders or investors to finance a future project (which in turn may consist of the creation of a new CVC).

To me, the only distinction between these two activities is that in the second one the seller decided to transparently admit that the sale was a securities offering while in the first they just sell the tokens without any such identification as debt or equity. This raises a whole bunch of questions about the SEC’s jurisdiction and whether a given token sale is securities issuance or not. Mere formality is usually not particularly relevant to that determination; therefore, whether the seller called it “offering debt or equity” or “a preferential sale of CVC” may not matter and the seller might be subject to SEC jurisdiction in either case. For our purposes with the FinCEN Guidance, what are the implications of this distinction? In both cases, the act of running a pre-sale appears to be money transmission according to the Guidance. However, the Guidance makes clear that in both cases the seller may be exempted from the definition of MSB for two different reasons.

Persons in the second category (sold debt or equity) are exempted if they are regulated by the SEC or CFTC (as of course would be the case for someone selling debt, equity, or futures). Persons in the first category (preferential sale of CVC) might be exempted from the definition of money transmitter if the ICO was “integral to the sale of goods and services different from money transmission.” So if selling the token was integral to providing buyers with cloud storage services, for example, then the ICO might not be regulated as money transmission.

Further, this section says that resales of tokens by investors subsequent to the ICO “in general … does not create any BSA obligations” as a money transmitter. But, the Guidance stresses, there may nonetheless be other BSA obligations triggered under other regulatory frameworks like securities or commodities derivatives law.

DApps and Confusion

Section 5.2.2 states that decentralized application (DApp) developers are not regulated as money transmitters for “the mere act of creating the application, even if the purpose of the DApp is to issue a CVC or otherwise facilitate financial activities denominated in CVC,” but they may be regulated as money transmitters if they “use” or “deploy” it “to engage in money transmission.”

This section appears underdeveloped and confusing. If, for example, I develop DApp software that allows people to trade ERC-20 token pairs, then I have only developed software and I am not a money transmitter. That much is clear. If, however, I then “use” my DApp to trade some of my personal ERC-20 tokens (and the DApp connects me with someone who wishes to take the other side of the trade), am I a money transmitter? Surely not because I’m using it on my own behalf and not in order to move anyone else’s currency or currency substitutes. What if, instead, I help my friend Neeraj use my DApp? If I accept his ERC-20 tokens and then transmit them by exchanging them for other ERC-20 tokens and sending those tokens back to him, then, yes, I suppose I would be a money transmitter. But that is a strange hypothetical and I don’t think many DApp developers would ever do something like that. Why build a DApp if you intend to be the trusted intermediary that controls a user’s interaction with the DApp?

If I merely explain to Neeraj how he can use my DApp to exchange ERC-20 tokens, then surely I am not a money transmitter; all I did was tell him how to use some software. What if I “deploy” it to the Ethereum blockchain? That action alone is not money transmission; it’s just publishing code to a blockchain (it might just sit there unused). And when someone then uses my deployed DApp to transmit money, I have nothing to do with it; so clearly that cannot make me a money transmitter. When is “use” and “deployment” relevant?

All in all, I’m not certain how to read this section. Maybe this makes more sense in the limited context of DApps that power stablecoin services. If I create a DApp that controls issuance and movements of a stablecoin on the Ethereum blockchain, and users can either create or redeem these stablecoins by depositing dollars with me, or they can transmit stablecoins to and from each other directly on the Ethereum blockchain, then some of these DApp transactions are money transmission (the ones where I issue new stablecoins via the DApp in return for dollars) while others are not regulated as money transmission (any transactions where a user interacts with the DApp in order to transfer her stablecoins to someone else). That interpretation makes sense, however this section never mentions stablecoins and is rather difficult to parse in the abstract.

Regardless, it’s clear that mere DApp development is not money transmission, and we agree with and strongly advocate for that interpretation.

Miscellaneous: Merchant Services, Mining, Pre-Mining, Prediction Markets

Section 4.6 states that cryptocurrency merchant processors (like BitPay) are MSBs, and that’s nothing new.

Section 4.7 states that prediction markets are internet casinos (a type of MSB) but BSA regulations only apply “the moment the condition is satisfied [the predicted event happens or does not happen] and the acceptance or transmission takes place.” Therefore developers of prediction market software or DApps may not be MSBs because they never accept nor transmit; they build non-custodial services that allow individual users to place their own bets and receive contingent payouts. Note, however, that the Guidance returns to the topic of DApps later and, as we have seen, that discussion is confusing and therefore this area potentially remains fraught with ambiguity and liability.

Section 5.3 states that pre-mines will be treated like mining and therefore selling pre-mined cryptocurrency on your own behalf will not be regulated as money transmission.

Section 5.4 states that mining pool operators, when they pay their pool members for work, are not regulated as money transmitters. I’ll admit I’ve never even given this one much thought, but FinCEN’s interpretation makes perfect sense.

Conclusion

While today’s guidance did not change any existing policy, it represents the first truly clear statement from FinCEN that they have no intent to regulate non-custodial wallets, multi-sig providers, DEXs, and the developers of privacy-preserving cryptocurrencies. There are a few ambiguous sections that deserve further analysis and, perhaps, clarification, but Coin Center counts this as a good step forward toward sensible policies for which we’ve long advocated.