- Posts Authored: 4
- Posts Contributed To: 0
September 7th, 2014 by wildjo
The BitLicense is getting a lot of attention these days because it is the first significant regulatory attempt by a US authority to proscribe activity in the Bitcoin space. Not surprisingly, this first attempt is fundamentally flawed.
Last week, I demonstrated that the regulations proposed by the New York Department of Financial Services (DFS) were unlawful because the DFS lacked the statutory authority to regulate Bitcoin. This week we tackle the constitutionality of the regulations and come to a similar conclusion: the BitLicense violates the Commerce Clause of the US Constitution and is, therefore, unlawful.Read More
4,454 viewsAugust 30th, 2014 by wildjo
There are a lot of reasons to dislike the BitLicense regulations proposed by Ben Lawsky and his New York Department of Financial Services (DFS). Two of the more potent arguments that have the greatest potential to strike down the proposed regulations, if they are not first withdrawn or extensively and materially modified, are: 1) lack of statutory authority, and 2) unreasonable interference with interstate commerce. Today, in this Part I, I discuss the issue of DFS statutory authority, or lack thereof, as it specifically relates to virtual currency and bitcoin.
In order for a state agency like the DFS to take any action, it must have authority to do so. Typically, such authority comes from state law. If the agency seeks to act outside its statutory authority, it does so unlawfully. That is precisely the situation we face with the DFS and its BitLicense scheme.
If you have read the proposed regulations, you may have noticed the phrase at the top (right after the table of contents and before the introduction); Statutory Authority: Financial Services Law, sections 102, 104, 201, 206, 301, 302, 309, and 408. This is a reference to the state law that the DFS believes gives it the power to propose the BitLicense. A closer look at this enabling legislation reveals that the DFS has been far, far too ambitious.
Under the flawed proposed regulations, the DFS prohibits any unlicensed Virtual Currency Business Activity (VCBA) that involves a New York resident. VCBA is defined as receiving or transmitting virtual currency; securing, storing, holding, or maintaining virtual currency on behalf of others; buying or selling virtual currency as a business; converting virtual currency to fiat or any other store of value; or, controlling, administering or issuing a virtual currency.
However, under its relevant statutory authority, the DFS has only been empowered to regulate financial products or services. We may, at first glance, assume we know what financial products or services means and conclude that virtual currency and VCBA sounds like it might fall within that assumed definition. However, state agencies lack the authority to assume. Instead, they must look to the exact language of their enabling statutes. So, what does this phrase financial products and services really mean?
Not surprisingly, the statue is too vague. The phrase is tautologically defined in Section 104 of the Financial Services Law as:
any financial product or financial service offered or provided by any person regulated or required to be regulated by the superintendent pursuant to the banking law or insurance law or any financial product or service offered or sold to consumers&
Clear as mud, eh?
Seeking clarification from New Yorks Banking Law is equally fruitless as it contains no definition of a financial product or a financial service. (it merely defines banks, bank-like institutions, and bank mechanisms such as demand deposits). It neither defines financial product or financial service nor mentions virtual currency or virtual currency business activity. Instead the statute is utterly silent.
A common tactic in statutory construction or interpretation is to refer to definitions contained in similar statutes to help define a term used in a law or regulation that is otherwise silent or vague. We dont have to look far to find a relevant definition of a financial product or service under federal law. Section 5481 of Title 12 of the United States Code contains the definitions relevant to federal banking law. Section 5481(15)(A)(i)-(xi) defines a financial product or service as (paraphrasing):
- extending credit and servicing loans;
- extending/brokering leases of real or personal property that are essentially purchase finance arrangements;
- check cashing, collecting, or guaranty services;
- providing real estate settlement services;
- providing appraisal services
- engaging in deposit-taking activities or acting as custodian of any financial instrument;
- offering stored valued instruments where the offeror controls the terms;
- providing payments or financial data processing products;
- providing financial advisory services; and
- engaging in consumer credit reporting activity.
In a nutshell, the definition describes a bank and traditional bank products and services. Since the definition defines the same phrase used in the New York statute and since both statutes regulate the banking industry, it is perfectly appropriate to assert that the DFS statutory authority is limited to this more specific definition. That is, the DFS is authorized to regulate certain traditional banking activity, and nothing more.
This assertion is also strongly supported by the statutory purpose contained in New Yorks Financial Services Law. Section 102 is long, but is worth reprinting in full here:
The legislature hereby declares that the purpose of this chapter is to consolidate the departments of insurance and banking, and provide for the enforcement of the insurance, banking and financial services laws, under the auspices of a single state agency to be known as the department of financial services and to accomplish goals including the following:
(a) To encourage, promote and assist banking, insurance and other financial services institutions to effectively and productively locate, operate, employ, grow, remain, and expand in New York state; (b) To establish a modern system of regulation, rule making and adjudication that is responsive to the needs of the banking and insurance industries and to the needs of the states consumers and residents; (c) To provide for the effective and efficient enforcement of the banking and insurance laws; (d) To expand the attractiveness and competitiveness of the state charter for banking institutions and to promote the conversion of banks to such status; (e) To promote and provide for the continued, effective state regulation of the insurance industry; (f) To provide for the regulation of new financial services products; (g) To promote the prudent and continued availability of credit, insurance and financial products and services at affordable costs to New York citizens, businesses and consumers; (h) To promote, advance and spur economic development and job creation in New York; (i) To ensure the continued safety and soundness of New Yorks banking, insurance and financial services industries, as well as the prudent conduct of the providers of financial products and services, through responsible regulation and supervision (j) To protect the public interest and the interests of depositors, creditors, policyholders, underwriters, shareholders and stockholders; (k) To promote the reduction and elimination of fraud, criminal abuse and unethical conduct by, and with respect to, banking, insurance and other financial services institutions and their customers; and (l) To educate and protect users of banking, insurance, and financial services products and services through the provision of timely and understandable information.
In other words, the main purpose of the Financial Services Law was simply to consolidate the banking department and insurance department into a single agency (the Department of Financial Services) and to help these industries remain competitive in the state.
Setting aside for now the cynical notion that the DFS just might be meeting these obligations by trying to kill bitcoin with the BitLicense, it is plain that the DFS authority extends only to the banking industry and bank-like financial products and services (as defined above). The authority to regulate virtual currency and virtual currency business activity outside the banking industry is found nowhere in the relevant New York statutes.
Even if, for the sake of argument, the DFS did have the statutory authority to enter this new sphere of virtual currency business activity, the proposed regulations still go too far.
Those who study bitcoin understand that its use as a virtual currency is only one of a multitude of actual and potential uses that are not inherently financial products or services (e.g. domain name registration, smart contracts, and notary services). Yet, the DFS does not distinguish between these non-financial uses of the technology. Instead, any business utilizing the blockchain could be found by the DFS to be engaging in the transmission of a virtual currency as defined in the proposed regulations.
For example, if a New Yorker uses a service that assists him/her in transferring a fraction of a bitcoin to establish proof of existence on the blockchain for some digital creation, they have engaged in a transaction that would require a BitLicense, despite the fact that nothing about the business arrangement is financial in nature. Taking the example a step further, suppose that digital creation was valuable and worth over $10,000.00 at the time the transfer was made. Under the BitLicense scheme, the DFS could argue that the transfer requires compliance under the anti-money laundering provisions of the regulations due to the value ostensibly transferred on the blockchain.
There are far more examples of this type of non-bank, non-financial use of bitcoin/blockchain technology than there are for virtual currency uses. Yet, the DFS, through its flawed proposal, is seeking to rake it all in.
The DFS cannot unilaterally extend its reach into the virtual currency sphere without the New York legislature first authorizing it to do so through new legislative action. The state agency does not have the subject matter jurisdiction that the BitLicense proposal, as written, would require. Simply put, the DFS is utterly without statutory authority to proceed in the proposed manner, and the BitLicense would be ultra vires and unenforceable.
Not only does the DFS lack statutory authority to issue BitLicenses, doing so would be an unreasonable interference with interstate commerce as every transaction on the blockchain is, by its very nature, an interstate activity. I will cover this argument next week in Part II.Read More
August 22nd, 2014 by wildjo
Editor and proofreader: Cheryl Copy of original:
Since the release of the proposed New York Department of Financial Services (DFS) BitLicense regulations on July 23, 2014, the crypto community has been concerned, but there hasnt been enough discussion of the specific implications such regulation would have. Its about time we put some flesh on those bones. Specifically, what would compliance with the regulations as written actually cost?
The goal of this post is to provide some answers, but, first let me tell you a quick story about how I started thinking about it.
The other night found me alone, sitting in my favorite chair, watching transactions in the bitcoin blockchain. It was a slow night, but my expectations were low.
I pulled up the Blockchain.info block explorer and focused my screen on the flow of current transactions. I have to admit, it was somewhat enchanting to watch the constant stream of bitcoin commerce. Satoshi really gave us something to marvel at here.
It wasnt long before the first large transaction rolled through. And they kept coming, and they kept getting bigger. After about an hour, I had seen everything from a $0.00 transaction with a $0.10 transaction fee to a $775,000.00 transaction with a $0.05 transaction fee.
The blockchain statistics indicate that $800.00 was the average transaction amount during the twenty-four hour period in which I was watching. This was far higher than I had previously assumed. Clearly, a lot of value is moving effortlessly (e.g. cheaply) through the blockchain, which is precisely why the DFS wants to get involved.
And this brings us to one of the meatiest and costliest parts of the proposed regulations.
Section 200.15 requires all regulated entities to implement a full Anti-money laundering (AML) and U.S. Treasury Office of Foreign Asset Control (OFAC) compliance program. In subsection (d)(2), the regulations require a licensed entity to report within twenty-four hours all transactions (whether individual or cumulative) that exceed $10,000.00 in a single day. Subsection (g)(4) goes further and requires that a licensed entity track single transactions that exceed $3,000.00, with the implication that such transactions are suspicious. Subsection (d)(3) requires the immediate reporting of any suspicious activity regardless of dollar amount. This may not seem that bad or that costly, but I assure you it is.
During my night in the blockchain, I conducted a very informal and unscientific test. I set my timer for three minutes and counted all the transactions greater than three thousand dollars during that time. After multiple rounds, the average was fifteen, with half of those being greater than $10,000.00. This would theoretically translate into a total of 7,200 transactions per day that could be subject of either a Currency Transaction Report (CTR) or Suspicious Activity Report (SAR). Thats well over two and a half million reports per year, and bitcoin is just in beta! Its a staggering amount of paperwork for bitcoin businesses to produce and for the regulator to actually make use of. But what would it cost?
There is very little detailed information in the literature regarding AML compliance costs. One 2005 study estimated that regulated entities in the United States spent $1.8 billion (yes, thats a b) in annual AML compliance costs.1 The Financial Crimes Enforcement Network (FinCEN), reports that there were 15.8 million AML compliance reports filed in 2005.2 Doing some simple math for a down & dirty estimate suggests that each report filed in 2005 cost regulated industry $114.00. That kind of makes you feel bad for the banks until you realize that they simply pass those costs on down to us, which is exactly what the bitcoin community would have to do with this potential $820,000 daily bill.
While possibly generating the greatest financial burden on the bitcoin space due to day in and day out application, Section 200.15 is not the only section to impose significant costs on BitLicensees.
Section 200.5 requires that each BitLicense applicant submit a nonrefundable application fee. The proposed regulations dont state any amount, leaving it up to the discretion of the DFS, but we can make an educated guess. Every other market-entry license issued by the DFS requires a $12,500.00 application fee. Its no stretch to assume that the BitLicense will cost an equal amount.
Section 200.4(a)(4) requires background checks for each Principal Officer and Principal Stockholder. In the New York market, these background checks run $650 a pop.
Sections 200.14(a) and (b) require the submission to the DFS of quarterly financial statements and audited annual financial statements. It is the latter one that is the most costly. I recently had a moderately sized corporate client contract for their first audited financial statement and the final bill was around $35,000.00. Recall that this would be an annual expense under the proposed regulations.
From here on out, estimating costs get a bit more speculative.
Section 200.8(a) requires that each BitLicensee be sufficiently capitalized to ensure financial integrity. The sufficient amount of capital is solely determined by DFS. It could be a little number. It could be a big number. Your guess is as good as mine, but only the DFS guess counts.
Section 200.9(a) requires that each BitLicensee maintain a bond or trust account in an amount acceptable to DFS. Again, it could be a little number. It could be a big number. Your guess is as good as mine, but only the DFS guess counts.
Section 200.13(a) requires that each BitLicensee submit to biannual examinations. It is not quite clear what this would exactly entail, but it is a safe bet that each BitLicensee will want to prepare, which means accountant and legal costs, as well as lost opportunity costs associated with staff devoted to compliance rather than engaged in direct market making activity.
Last, but not least, Sections 200.16(c) and (f) requires each BitLicensee to employ sufficient cyber security personnel, including a Chief Information Security Officer. Sections 200.16(d) and (e) require an annual cyber security audit by a qualified and independent third-party. The way these regulations read, one person isnt going to be able to be a jack of all trades and wear multiple regulatory hats. These regs require dedicated cyber security staff and third-party consultants, and both are expensive.
We have now covered all of the vaguely enumerated costs of compliance contained in the proposed regulations. These are big, daunting numbers: $12,500 just to apply; $35,000 annually for an outside audit; $114 for each AML report (and you better be liberal in your reporting so as not to miss something and risk being assessed a penalty); $650 for each background check of each executive staff or investor; obtaining sufficient capital; posting sufficient bond; and on and on. But, theres more to it.
Each applicant will necessarily incur the general consulting costs of developing all of the policies and procedures required under the proposed regulations, as well as preparing all of the disclosures, background information, business practices and strategy descriptions, marketing plans, advertising samples, etc., etc. that are also required to be disclosed with the application. In other words, there will be significant costs for simply putting the multi-layered application together. Lawyers and accountants will charge a lot of money for their guidance. Industry data shows that the average associate attorney in the New York market charges $400.00 per hour (with partners pulling in $1,000.00 or more). In a specialized field such as bitcoin licensing, you can assume that the fees are going to be above average. Even the smallest of the potential BitLicensees should plan on thousands of dollars to simply put the application together, with larger ventures approaching six figures. These will be sunk costs with no guarantee that the application will ever be approved.
It should be clear at this point that the proposed DFS regulations would not simply make business in the bitcoin space do a lot of unpleasant stuff; they are going to make businesses in the bitcoin space pay a whole lot of money to do Them. That will have two consequences: it will set up obstacles to entering the space that only the most resource rich players can afford; and, it will introduce financial friction into the system and increase transactions costs. There is a strong argument that these consequences are antithetical to the fundamental principles underlying the bitcoin protocol. The crypto community has cause for concern.
- Yeandle, Mark, et al., Anti-Money Laundering Requirements: Costs, Benefits and Perceptions, June 2005
- FinCEN Annual Report Fiscal Year 2005
Cover image courtesy of LittleShibe.Read More
5,376 viewsAugust 15th, 2014 by wildjo
For too many people, the answer to the question "What happens to your bitcoins when you die?" will include some variant of "lost." Of course, that does not have to be the case if we use the legacy estate law of our home jurisdictions. These legacy systems, however, have the same disadvantages of the financial system we are trying to make obsolete with cryptocurrencies: trusted third parties and gatekeepers.
There are alternatives within and on top of the Bitcoin protocol that can overcome these legacy estate law disadvantages. This article identifies two and suggests a mechanism in which they may be employed to provide simple estate-like planning in a decentralized, autonomous way without the time cost and monetary expense of traditional strategies.
[The above was written by the original author. I assume it was meant to be used as an excerpt/preview for the article. I made some minor edits.]
What happens to your Bitcoin when you die?
For some of us outliers in the U.S. cryptocurrency communitythat is, those of us who didnt grow up with a computer in the home and are old enough to have learned how to type on an actual typewriterthe twin certainties of death and taxes are on our minds more than others. In this regard, crypto presents unique challenges. How do we pass on our Bitcoin wealth and legally avoid unnecessary estate expenses, while also protecting our private keys while we are still alive?
The world of estate law (the law governing the management of a persons assets, with an eye to how they will transfer after he or she dies) has some ideas, but, not being crypto devotees, those ideas center around how to wrangle crypto into their non-crypto world.
For example, the proposed Fiduciary Access to Digital Assets Act (FADAA) would simply give trusted-third parties enhanced rights (and liability protection) to force a software or hardware company to provide anothers private information. That may be necessary in some situations, but Im sure the crypto community can come up with a better and more generally applicable decentralized and autonomous solution that minimizes the need for trusted third-parties and gatekeepers (and their associated privacy risks and fees).
Why is the status quo unsatisfactory? The main problem with legacy estate law is that it requires the disclosure of private keys to trusted third-partiesexecutors, trustees, agents operating under a power of attorney, conservators, and personal representativesso that they may access the decedents wallet and distribute the decedents digital assets. Thus, we reintroduce the trust factor back into an area of the cryptocurrency arena that was doing just fine without it. Not only must we trust that these third-parties wont access our wallets while we are living, but we must also trust that they will keep the private keys secure and provide continuity of care in the event they predecease us. Continuity of care requires the introduction of even more third-parties, but is necessary, if not required under some state professional responsibility codes, when attorneys and other professional fiduciaries are involved.
Another deficit of the legacy estate system is that it necessitates the inclusion of gatekeepersprobate courts/judges, magistrates, executors, attorneys, and state agencies (e.g. vital statistics departments). In even the simplest of situation where all the necessary information is known and all the heirs are getting along, these gatekeepers impose costs in terms of both time and money. Where information is absent and heirs disagree, those costs can be extraordinarily high. Sadly, the latter scenario is far too common.
Estate law is a required course in law school. I suffered through it and swore I would never practice it when I became an attorney because it can capture the human species at its very worst. The cases usually have the same last name on each side of the v., as in Jones v. Jones and Smith v. Smith, because some relative feels they got the short end of the inheritance stick and decides the only way to be vindicated is to blow up the family. These fights rage on because both sides are empowered by a legal system and legal profession that stands to profit from the dispute. Family relationships are devastated and family assets dwindle in the process. Insert the technological difficulties and relative unfamiliarity of crytpocurrency and you are simply adding heavy fuel to those fires; fires that can only be snuffed out with the loss of additional time and money.
No. Satoshi was right. We need to continue to keep trusted third-parties and gatekeepers out of our digital financial lives as much as possible, both during our lives and after our deaths. The problem is, however, that there is no clear way to accomplish this within the Bitcoin protocol. Or is there?
Im no coder, and my computer competency is just deep enough to make me dangerous. Still, we need to start considering this question, so allow me to kick it off and allow other, more sophisticated, members of the community to take it further.
In my view, what we are looking for is a mechanism that allows a wallet holder to send a percentage of their wallet balance, whatever that balance may be at some indeterminate time, to another wallet(s) upon the death of the first wallet holder. There are a couple elements here that we need to parse out.
First, the transaction needs to take place in the future. As I understand it, this function (or something very similar to it) already exists within the protocol. It is called LockTime and is a major feature of distributed blockchain contracts that allows a payment to be made from one address to another after the specified period (n) has passed. Without more, such a function could be used as a crude estate planning tool by selecting a date beyond which is the reasonable life expectancy of the initiating party. However, that means that the initiating party could never change their mind and that the beneficiary might have to wait years before they receive the asset. A lot could happen in that intervening period to make such a transaction unpalatable.
To make this function better for autonomous estate planning purposes, we would need to modify the LockTime functionor build on top of itto allow us to modify the transaction date repeatedly. If this were possible, we could set up transactions to our heirs on New Year's Day of each year to be distributed, for example, on January 1st of the following year. If we pass away within that period, then transaction propagates. If we dont, then we modify the transaction on New Years Eve to take place in another year, repeating the process until we are no longer around to do so and the transaction kicks in. In the meantime, this flexibility allows us to adjust who our beneficiaries are, the amount they would receive, or to suspend the transaction altogether at any time. In other words, it gives us the flexibility of the existing estate law system (e.g. rewriting a will) with the autonomy of the Bitcoin protocol.
The second element to address is the amount transferred. With the current LockTime function, the amount of the coin transferred must be specified and it is removed from the wallet. However, in the new estate planning space we are creating for ourselves, while we want our heirs to inherit what is left over, we might want to spend some of our Bitcoin in the meantime. Having to deplete our wallet balance, even if temporary, in order to make a contingent LockTime transaction, could be inconvenient. But, what if we could modify the function to allow for a percentage of the then existing wallet balance to be transferred? For example, I set a transaction to my daughter to be completed a year from today and the amount is set at twenty-five percent of the balance existing in my wallet at that specific time. I could then accommodate multiple heirs with set percentages and not have to worry about changing the transaction each time my wallet balance changed.
In this scenario, I could set up empty wallets for each of my beneficiaries, teach them how to use the technology, make sure the private keys were preserved (e.g. in a safe), and instruct them to get their own wallets and move their distribution out of that interim wallet and into their own, secure wallet upon my death. This prevents the private keys to my account from being compromised, while minimizing the period of time that the interim account is vulnerable (it will not be used except on the moment the contingent LockTime transaction is ultimately made and then transferred out to the beneficiaries' own wallet) while also ensuring that the LockTime transaction can be recovered (private keys kept in safe place known to me and relevant beneficiary). All of this accomplished autonomously, with only me and my beneficiaries playing an active role.
Another use of a system of this nature would be to safeguard wallets in the event of lost private keys. For example, on my birthday each year, I could create a TimeLock transaction that would transfer my balance (0-100%) to another address on my following birthday, unless I rescinded it at any time before that magical date arrives. In the interim, if I lost my private key, there is a contingency in place that would allow me to recover my balance in the new wallet and all I would need is a little patience.
Getting back to our estate planning use, an autonomous system of this nature is similar to the legacy estate planning systems pay on death (POD) or transfer on death (TOD) account. There, an account holder designates a beneficiary and informs the institution holding the account of their identity. During the principals life, the beneficiary has no right to the account, but title and right vests immediately with the beneficiary at the moment of the principals death. This allows the account to be distributed to an heir(s) (the designated beneficiary) outside of probate. The drawback, of course, is that the beneficiary has to obtain and present a certified copy of the death certificate to the bank in order to take possession. This can waste time and money.
A contingent TimeLock % balance transaction is clearly superior as it accomplishes everything a POD/TOD account does, while keeping the gatekeepers (in this case, the institution issuing the death certificate and the institution holding the account) out.
There are a lot of nuances to any given jurisdictions estate law and a lot of complexities that go into a persons estate plan. This discussion is, by no means, an attempt to cover any of that ground or to provide legal advice to the reader. Rather, the goal here is to kick off a discussion of a basic wallet/protocol function that could be one strategy in an overall estate plan, and, most importantly, one that minimizes the drawbacks of the legacy estate planning system and its trusted third-parties and gatekeepers.
In other words, Im hoping we can answer the question, What happens to your Bitcoin when you die? with, No worries. Its in the blockchain.Read More