BitLicense 2.0: What The Latest Revisions Mean for Bitcoin Businesses

Marco Santori is a blockchain and bitcoin specialist who leads the FinTech practice at law firm Cooley LLP.

He is also the former chairman of the Bitcoin Foundation’s Regulatory Affairs Committee and author of CoinDesk’s series on bitcoin law (find parts 1, 2 and 3 here).

New York’s Department of Financial Services (DFS) published its original BitLicense proposal in July of 2014. That original proposal drew applause from those who valued regulatory certainty, and ire from those who faulted it for its imprecision and tendency toward over-inclusion.

In the intervening six months, DFS received thousands of written comments and met with countless industry members. I don’t think any commentator could accuse them of not listening to the community – but receiving information and acting on that information are two different matters entirely.

Let’s break down some of the most important changes to the BitLicense and whether they addressed the concerns of digital currency businesses, investors and consumers.

A more limited scope of licensure

The original BitLicense draft required licensure from just about every business, arguably including even software developers who wrote software that helped “secure” their user’s digital currency.

This element has been removed. Now, merely “securing” digital currency on behalf of users doesn’t subject a company to the licensure requirement. DFS also added an explicit carve-out for companies engaging in mere software “development and dissemination.”

“Still, businesses that “store”, “hold”, “issue”, “administer”, “exchange” or “control” digital currency on behalf of their customers require a license to operate.”

At minimum, this should be welcome news for client-side wallet developers. Multi-signature software providers, though, are probably left questioning just what “holding” and “controlling” means. Does knowing one or two of three private keys constitute control? What if all three keys are required to sign the transaction? Knowing just one might be enough “control” to trigger licensure – or maybe not. DFS hasn’t gone to this level of granularity.

Likewise, altcoin creators aren’t given much comfort. What does it mean to “administer” a digital currency? Under federal law, “administering” a digital currency has something to do with the power to remove it from circulation.

The BitLicense doesn’t tell us whether the same is true under New York law. Given the policy goals at play, though, it’s likely that this “administering” prong is meant to capture companies that run centralized digital currency systems, not your typical altcoin developer.

A carve-out for Bitcoin 2.0 apps

One of the most common comments DFS received on its original BitLicense proposal was its failure to account for non-currency uses of the Bitcoin protocol.

These so-called “Bitcoin 2.0” applications make token use of the Bitcoin protocol to effectuate non-financial transactions by moving specially-tracked bitcoins from one address to another. Even though they don’t effectuate any bona fide movement of money, they would have triggered licensure under the original BitLicense.

The new proposal adds an exclusion for businesses engaging in transactions for non-financial purposes and involve only a nominal amount of digital currency.

DFS acted decisively here, and it shows. This exclusion is a clear statement of intent not to regulate smart contract companies, chain of title products and other data verification implementations of the blockchain. It is a correct result if I’ve ever seen one, and it’s stated clearly.

An interim, “conditional license”

Late last year, DFS announced informally that it would consider adding some form of onramp licensing for digital currency businesses that couldn’t otherwise satisfy the BitLicense requirements.

The new proposal includes a “conditional license” that DFS may grant in its sole discretion and subject to any number of “reasonable” conditions it sets. This conditional license is valid for two years and may be renewed by DFS at its discretion.

The idea of an onramp license is excellent, I think, and demonstrates DFS’ commitment to a growing industry. From a statutory standpoint, though, all that’s really here is an idea. I think I speak for most commentators when I express my desire for more specificity.

On what terms might DFS grant this license? For what reasons might an application for a “conditional” license be denied? This revision doesn’t give us much indication.

A broadened definition of “permissible investment”

DFS drew more fire than most commentators expected when its original proposal prohibited a licensee from counting its digital currency holdings toward its minimum capitalization requirement. This is actually quite common among other licensing statutes, which require a licensee own assets sufficient to cover its outstanding obligations to consumers.

Those statutes typically limit the kind of assets that can count toward the requirement to stable, fairly uninteresting investments like cash equivalents and government bonds.

For a digital currency company, though, that would typically require keeping an additional dollar for every dollar’s worth of customer Bitcoin it held – simply not feasible on an exchange or wallet service budget. A regulation “specifically-tailored” to digital currency businesses should account for this.

The new proposal does account for it, and eliminates the prohibition on digital currency investments, so long as they are held in a ratio acceptable to DFS. Given the variability in digital currencies and digital currency business models, I can’t fault DFS for retaining broad discretion here. This is one place where DFS’ has clearly delivered on its promise of a “specially tailored” ruleset.

An identification requirement, eliminated

Perhaps the greatest criticism of the original BitLicense was its requirement that licensees identify parties on both sides of any transaction.

A hosted wallet, for example, would be required to record the name and physical address of both the recipient and sender of a transaction. Such a requirement would be largely untenable, since the wallet wouldn’t have any real way of knowing who, besides its own customer, was involved in the transaction.

The new proposal softens this requirement, only demanding that the licensee submit non-customer identities “to the extent practicable.” It isn’t clear just what is “practicable”, or to what kind of practicality standard the licensee will be held by a judge or jury interpreting this provision. Without more meat on this obligation, wallets and exchanges will be left guessing just what steps they should take to collect and record this information.

As with its original BitLicense proposal, DFS will accept comments, but only for thirty days in this round. At the expiration of those thirty days, DFS will likely prepare a final version and then publish it in the state Register. DFS extended the last comment period in response to industry outcries for more time. I doubt that there will be an extension granted, so if you plan to file a comment, it should be done quickly.

Who should file a comment? Altcoin developers might want the final rule to more clearly define what it means to “administer” a digital currency. Multisig developers might ask for a clearer definition of custody, “controlling” or “holding”. They might even argue for a specific exemption.

What would your comment say?

Marco Santori is a business attorney in New York City with Pillsbury Winthrop Shaw Pittman LLP. He is a lawyer, but he is not your lawyer, and this is not legal advice. You can reach Marco at marco.santori@pillsburylaw.com.

Image via Shutterstock