No, FinCEN Policy is not Relevant to the Bitcoin Forking Debate
Are the developers of software that leads to a hard fork of the Bitcoin blockchain (like Bitcoin Classic) subject to regulation under the Bank Secrecy Act?
Are the developers of software that leads to a hard fork of the Bitcoin blockchain (like Bitcoin Classic) subject to regulation under the Bank Secrecy Act?
Some recent blogs posts have raised an interesting question: are the developers of software that leads to a hard fork of the Bitcoin blockchain (like Bitcoin Classic) subject to regulation under the Bank Secrecy Act? Do they therefore have an obligation to register with the Treasury Department’s Financial Crimes Enforcement Network (FinCEN) and comply with all its relevant rule? What about miners running the new software?
Interesting questions, but with a pretty straight-forward answer: no reasonable reading of the 2013 FinCEN guidance supports this conclusion. Decentralized Virtual Currencies, forked or no, do not have administrators for the purposes of FinCEN regulation, and therefore no protocol-level developer would need to register as an MSB. Let’s walk through all this with a careful, step-by-step, and well-hyperlinked description of what types of Bitcoin activities FinCEN does regulate, and put aside for now what it might regulate with respect to a fork.
What FinCEN does regulate—through their Bank Secrecy Act implementing regulations—are Money Services Businesses or “MSBs.” MSB, as a super-category of business, includes: dealers in foreign exchange, check cashers, issuers and sellers of traveler’s checks, providers of prepaid access, money transmitters, the US post office (yep), and sellers of prepaid access.
Thus far, FinCEN has insisted that virtual currency related businesses are not prepaid access providers or sellers, nor is a virtual currency exchange a “foreign exchange,” nor does it have (more obviously) anything to do with checks or the post office.
But according to the 2013 virtual currency guidance various activities relating to virtual currency are money transmission as defined in the implementing regs. Those activities are “exchanging” and “administering”—and so we can think of these two activities as two subsets of being a money transmitter utilizing virtual currency.
So, to be regulated by FinCEN a person performing some cryptocurrency-related activity needs to fall under the definition of a Money Transmitter as found in the BSA implementing regulations.
That definition of Money transmitter is as follows:
“(A) A person that provides money transmission services. The term “money transmission services” means the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means. . . .
(B) Any other person engaged in the transfer of funds.”
So, does a developer or miner fit this definition? First, what do we have here when it comes to miners?
In FinCEN’s own words: mining “involve[s] neither ‘acceptance’ nor ‘transmission’ of the convertible virtual currency and [is] not the transmission of funds within the meaning of the Rule.”
Notice, the implementing regs define money transmitters as those who both accept and transmitvalue. Even apart from FinCEN’s ruling above, acceptance has a legal definition in the payments context, and it is generally understood as: “the receipt of a check or other negotiable instrument by a bank or another drawee.” A bitcoin transaction message relayed to a miner is not a “negotiable instrument” because it is not an “unconditional promise or order to pay a fixed amount of money.” If I try to send you a bitcoin, but my transaction message doesn’t get relayed or included in a block, I am not in breach of any promise to pay you (assuming we don’t have any other agreements).
Take note: contrary to some commentary in the twitterverse, this reasoning does not rely on whether Bitcoin mining is sufficiently “decentralized.” Even if one miner had all the hashing power on the network, she still wouldn’t be “accepting” and “transmitting” and still would not be an MSB according to FinCEN.
If miners are not MSBs, then that means they are not Financial Institutions, and therefore they are not subject to FinCEN regulations, like the registration requirement, under the Bank Secrecy Act.
That said, FinCEN could decide to begin a new rulemaking, define cryptocurrency miners, and add them to the list of defined Financial Institutions in Chapter X. They have that power under the Bank Secrecy Act because the list of Financial Institutions in the statute includes: “any business or agency which engages in any activity which the Secretary of the Treasury determines, by regulation, to be an activity which is similar to, related to, or a substitute for any activity in which any business described in this paragraph is authorized to engage”
“By regulation” means that such a new regulation would have to be promulgated via the normal, APA mandated notice and comment process, which generally takes months, even years. So while this is all possible (although unlikely), it would be a slow, transparent, and notorious development. No midnight raids for miners.
Now, software development. Does hypothetical Bitcoin core dev XT or NG or WTF (or Dogecoin core for that matter!) need to register as an MSB? Again, the answer is no.
The same analysis above applies as well to developers as it does to miners: They neither accept nor do they transmit. To again quote FinCEN itself: “The production and distribution of software, in and of itself, does not constitute acceptance and transmission of value, even if the purpose of the software is to facilitate the sale of virtual currency.”
But here’s where it gets really interesting! Recall that in our earlier discussion FinCEN could probably succeed in having a rulemaking to add mining to the list of regulated Financial Institutions. It would be very difficult to do the same with a software developer.
First, you’d have to question whether a software designer “is similar to, related to, or a substitute for” a bank or financial institution. Personally I think that would be an absurd interpretation. A network of interconnected computers may be (miners, users, etc. taken as a whole) but a person who merely writes some C++, on her own, is no substitute for a bank. Is she “similar” to a bank? No. Is she “related” to a bank? It’s difficult to even know what that means in this context.
If you are familiar with administrative law, however, you’ll know that the agency gets a fair amount of leeway in interpreting statutes—it’s called Chevron Deference—but we’d only get the result after a lengthy court case on top of a lengthy rule-making. So maybe this could still go forward (but it’d require some serious will and political capital on FinCEN’s part—far different than issuing guidance). And yet there’s more.
Second, you’d have to question whether the software designer, under this new rule, is being restrained, in advance, from publishing source code. Mandating registration as a necessary condition to speak is something we frown upon here in the U.S. because it has been consistently found to be unconstitutional under the First Amendment. This even includes a case dealing with the publication of encryption source code and matters of national security.
If that analysis holds, then even congress could not make a law that forces developers to register!Next option is a constitutional amendment but we probably do not need to go there, this post is long enough.
Fork away, or don’t; but worry about the technical or community implications rather than the law; the regulatory landscape is indifferent.