Treasury Digital Assets Illicit Activity RFC Part 2: Some Others’ Comments

We previously discussed our own comment on the recent US Treasury RFC regarding illicit activity in digital assets. In that piece we mentioned that our focused differed marked from many other prominent commenters’ submissions. We chose to focus on one area in which we believe dramatic gains are relatively easy to realize politically, practically and even mechanically. Our proposal to expand False Claims Act processes to cover issues like OFAC sanctions violations seems like a simple win for everyone.

As most everyone else that submitted a comment focused on other areas we will briefly comment on their comments here. This is by no means exhaustive as hundreds of comments were submitted. Given the ongoing government shutdown there may well be a massive queue of unpublished comments. We have no clue. So here are our comments² on three comments submitted by prominent parties. While not exactly randomly selected from the set of all comments they are intended to reflect, broadly, the sorts of feedback we saw submitted.

Coinbase’s Comment

Original here

A surprising amount of Coinbase’s comment was focused on the use of APIs. APIs are common in traditional finance. We have personal experience of API use for trading, risk management, account verification and more functions going back decades. Now there is a request for:

issuing clear guidance that establishes safe-harbors within the BSA when financial institutions properly use APIs to satisfy their anti-money laundering and counter-terrorist financing (“AML/CFTˮ) obligations

As of now the guidelines are clear: it makes no difference what technology you use. A licensed financial services provider cannot shed their AML obligations and place them with unlicensed service providers independent of whether communications with that unlicensed secondary service provider are through an API, telephone, email or carrier pigeon. This should be pretty obvious. Coinbase’s proposed scheme would seem to enable something like the following:

  1. A licensed financial services business “F” has obligation “X” under some regulation.
  2. F finds a service provider “P” which offers software to help with X.
  3. F relies as much as possible P to not violate X.
  4. If F violates X it faces no penalty as long as the contract with F promises to solve X within the safe harbour’s parameters.

Does that make any sense? Let’s pretend for a minute that it does make sense and game out what is happening here. F is not going to face any penalty because of the safe harbour. That’s what a safe harbour is. So the only two choices are that P suffers or nobody is accountable.

If nobody is accountable then, well, this is unlikely to be a very compliant financial system. The entire point of penalties is to cajole compliance when everyone knows being non-compliant is often more profitable. Exhibit a: drug dealers make a lot of money.

It clearly makes zero sense to leave nobody accountable. The rules are pretty useless if nobody suffers for violating them. If you do not believe us then please go have children. On second thought: just go volunteer at a primary school for a morning and resume reading here.

So that leaves P. For P to be accountable under a safe harbour it is going to need a contract with F that conveys this accountability. P cannot just wake up and discover it is liable for AML violations by a SaaS client. That is an insane legal setup that no reasonable legal system would entertain or enforce.

But, sure, it is possible for P to need some kind of license or other legal structure to provide services for X to F in a way that fits within the safe harbour. This then leaves us with two choices. First, P has little-to-no money relative to the size of F’s business. In that case there is still no real incentive to comply because there is nobody actually paying the bill. If F has an X problem it will result in P going bankrupt and the regulator trying to collect on a claim from a dead software developer. Right. It is easy to see how to game this setup.

Alternatively, we need software service providers with immense capital bases or, maybe, wealthy owners that extend personal guarantees for violations committed by SaaS customer’s businesses. What? Who is going to do that?

This part of Coinbase’s proposal looks like a request to remove the teeth from enforcement by making nobody accountable. Or, maybe, dumping accountability on small lightly capitalized throw-away businesses that exist to bear these penalities and then fold. But it is fairly transparent and regulators should be able to see through this easily. Similar requests exist for AI and Digital ID later in the Coinbase comment. These all read like attempts to remove all accountability for problems.

And then we get to the big one: blockchain analytics. Coinbase requests that:

Treasury should publish supervisory guidance that explicitly recognizes and incentivizes the use of Know Your Transaction (“KYTˮ) screening and blockchain analytics clustering as a more effective means of enhancing AML/CFT compliance than is available in traditional finance. Legislation and guidance should also be updated to specifically list such technology as an example of proper, risk-based ongoing monitoring and sanctions screening.

Why should the government declare one technique or technology more effective than another? Why should certain methods be explicitly listed in the law — and, presumably, granted safe harbours —than a more generic technology-neutral approach based on principles and performance?

And that is before we deal with the lack of specificity in the term “blockchain analytics clustering.” Courts do accept certain specific techniques for DNA testing with certain specific lab conditions. Nobody would entertain a request to privledge “organic chemistry-based analysis” because that is insane. If Coinbase is proposing to bring science into the conversation and run lab tests on specific clustering software: great. So far the industry has resisted this and instead wants the equivalent of a court declaring that “biological analysis is a proper, risk-based ongoing monitoring too for identity verification.” Grow up.

In other parts of the comment Coinbase calls out “non-compliant banks, OTC desks and crypto exchanges.” Why not simply encourage enforcement against them and let good actors rely on good tools? And when a tool falls down the user suffers with an enforcement action and the tool provider looses business. This is how it has long worked in financial services. Do not make it easier to pass the buck — encourage more enforcement.

We expect the reason for Coinbase’s odd request is that these tools do not work as well as Coinbase and many others would have us believe. Both in theory — which we have written about extensively — and in practice. Coinbase was recently fined in Ireland for, and we are quoting here:

  1. configuration issues…which meant that the TMS failed to fully and properly monitor 30,442,437 transactions (the Non-Monitored Transactions) for Coinbase Europe for certain high-risk scenarios from 23 April 2021 until 29 April 2022
  2. As a consequence of the Non-Monitoring Issue, it was then necessary to rescreen the Non-Monitored Transactions…The completion of the above process took almost three years, undermining the efficacy
    of the STRs ultimately submitted as a result…The Non-Monitored Transactions accounted for approximately 31% of all Coinbase Europe transactions in the period 23 April 2021 to 29 April 2022 and were valued at approximately €176 billion.
  3. Although Coinbase Europe was responsible for ensuring proper transaction monitoring, it was unaware of the above issues for an extended period of time because Coinbase Europe’s systems and controls were, at the time, ineffective to oversee the work of
    Coinbase Inc…The first time that Coinbase Europe was provided with information that should have alerted it to the issues with the TMS was in February 2023 when Coinbase Inc. provided Coinbase Europe with a document that described the Non-Monitoring Issue. There was sufficient information in this document to alert Coinbase Europe to the fact that the TMS had not functioned properly for over a year and that the necessary rescreening had yet to be completed.
  4. By 2022, Coinbase Europe had commenced the application process for VASP registration. Coinbase disclosed the Backlog during the application process and explained that it was a consequence of surging customer growth…The assurances provided by Coinbase Europe in September and November were relevant to the Central Bank’s decision to grant Coinbase Europe’s VASP registration in December 2022.

That sure sounds like Coinbase lied to the Central Bank of Ireland. Certinly the Central Bank feels it was misled. And, well, it also sounds like they were basically kicked out of Ireland:

Coinbase intends to transfer the business of Coinbase Europe to a Coinbase Group entity in Luxembourg which has been granted authorisation under MiCAR to operate as a Crypto Asset Service Provider in that jurisdiction. Coinbase Europe’s registration as a VASP with the Central Bank will therefore lapse at the end of 2025 and Coinbase Europe will cease conducting business in Ireland.

There is a lot more in the document. Go read that piece and consider for yourself if these are people you should be deferring to. Their response, if anything, makes it sound worse. This comment in particular makes a strong case that Coinbase’s developers are competent at building the system they are told to, but the compliance staff are not so competent at operating it:

Coinbase identified these coding errors as part of its efforts to monitor and test its compliance systems. Once detected, Coinbase fixed the coding errors within two to three weeks. CBEL then ran all of the impacted crypto transactions back through the now fixed five TMS scenarios — this took a longer period of time to complete.

Part of the reason “this took a longer period of time to complete” is that the problem was hidden from the relevant CBEL staff for a long time.

We look forward to the inevitable Central Bank of Luxembourg settlement.

Coin Center’s Comment

Original here

Coin Center’s main concern in their comment is to ensure the current government surveillance regime does not grow dramatically and that individual rights are preserved. We have no problems with that. Excessive government surveillance is, by definition, excessive and therefore bad. The US has a long history of grappling with this and a rich legal tradition that can, at times, either clarify or stupefy. These are hard problems.

Coin Center seems to acknowledge this is hard writing about their own proposals:

We recognize that this sketch of a proposal demands significant investigation before it could become viable. National security concerns or the need to maintain investigative secrecy may make the degree of transparency suggested here difficult in practice. Similarly, the complications inherent in proving that one’s funds should be unfrozen are substantial. What if a user is an American, yet the government claims that the targeted property is jointly held, off-chain, with foreign persons or entities? Is there a zero-knowledge proof of nonforeign interest that would be both technically sound and legally sufficient? Questions such as these demonstrate that further research — technical, legal, and institutional — is essential before any automated freeze and unfreeze system can be responsibly deployed.

Our view is that Coin Center’s heart is in the right place but they do not understand the technical limitations inherent in decentralized, permissionless and powerfully programmable systems. The answer to their concerns in that paragraph is this paper which discusses what is technically feasible on the automated regulation front. What Coin Center seems to be slowly accepting is that there are hard limits on what sorts of compliance can be reliably automated due to math.

We commend them for being honest here. They want a certain set of properties and do not, as of yet, have in hand a design for a system that has all those properties. So they “recognize that this sketch of a proposal demands significant investigation before it could become viable.” We know that they cannot have everything they want and must compromise on some principles. There are a number of different ways they can compromise — but they do not have an entirely free hand there either.

The interesting question here is whether or not Coin Center will accept they must compromise or if it adopts a more Coinbase-like approach, as above, where they simply want to wave their hand and avoid the crux of the issue. Above the crux is that someone still needs to be reasonable for violations if a rule is to have any real effect. And here, with respect to the tension between surveillance and freedom, the tension is that completely free systems cannot accommodate completely reliably autoamated compliance. So you need to give up some freedom, some compliance or some reliability. It is perfectly fine to want to avoid that choice. And we look forward to seeing how Coin Center’s views on this evolve (i.e. whether they accept the choice or decide to hand-wave it away).

The Clearinghouse & Bank Policy Institute’s Comment

Original here (which we will refer to a BPI for brevity)

Our own views are broadly aligned with this comment so we will focus on those areas where we differ.

First, with respect to DeFi and the potential for regulatory issues the BPI states:

At the same time, DeFi technologies present opportunities for compliance innovation. The programmability of smart contracts could allow for the coding of automatic compliance controls, such as limiting the parties a digital asset can be transferred to, potentially reducing the burden on intermediaries. Treasury should direct FinCEN to study the feasibility of such approaches.

We do not believe the government needs to study this. Directing a regulator to study a technology in this fashion is asking for lobbying efforts to dominate substance and opens up myriad opportunities for corruption. Instread the government should simply clarify what the rules are and enforce them evenly.

We agree with BPI

that certain actors within the DeFi ecosystem…may qualify as DASPs and financial institutions under the BSA, depending on their role and the attendant risks they pose.

But determining the characteristics of a given financial services business has long been the province of standard regulatory and legal processes. Banks today run on software and bank management is responsible for ensuring the software as deployed within the bank complys with the regulations as written. DeFi raises few genuinely novel issues on this front. We view the scale of the innovation, in so far as it is difficult to work out precisely how a new protocol fits into the existing rules, as akin to regulating interest rate swaps as opposed to cash bonds. It is by no means trivial but it is also not such a massive disruptive change that new rules must be written from scratch.

In fact, the BPI comment seems to recognize this when they write that

While blockchain analysis makes it possible to identify all wallet addresses through which a token has passed, it would be unworkable to impose on regulated institutions an obligation to diligence or monitor for the entire historical chain of custody of every digital asset. More importantly, review of the complete historical record of a token would not be effective in preventing financial crime or transactions with sanctioned person.
Instead, regulations should recognize that most digital assets, including permitted payment stablecoins, are fungible assets similar to electronic funds in fiat and cash.

If the asset is similar and the characteristics and similar and the behaviour is similar…then it is not that different after all. BPI is, like Coin Center above, slowly realizing there is less here than many claim.

Then, later in the BPI comment, they come around to blockchain analytics. The approach here is strikingly different from Coinbase:

While blockchain analytics can be effective in detecting illicit finance activities, regulatory guidance is needed regarding the acceptable level of reliance on a financial institution’s own blockchain analytics tools and third-party providers of such tools to detect illicit activity. Different tools and providers apply varying methodologies, producing potentially divergent “risk ratings” for the same asset or wallet address. Treasury should provide clarity through regulation and guidance as to whether low, medium, or high assurance ratings from analytics tools are sufficient to meet supervisory expectations, and whether additional measures must be taken when asset or wallet ownership cannot be definitively established.

This is not a request to provide the conditions under which a financial institution can shed liability — which is what Coinbase wants — but instead a request for a framework within which the manage liability the financial institution cannot shed.

Here we differ from the BPI in that we do not think “clarity through regulation and guidance” is really needed. It is surely true that many institutions are unwilling to deal in digital assets because they are unsure how much of this analytics stuff is supposed to work. And how reliable it is.

But the solution to that is clarity and honesty about what the tools do and how they work. And more proper court cases resolving liability issues. The reason people are slowly coming around to recognizing these things are not so different, and not so difficult to integrate, is that in-depth tests via legal processes reveal what is really going on without all the web3 industry marketing and doublespeak.

Commonalities

These were not randomly selected comments. They show the range of feedback that was provided. At one end we have requests to provide clear, and relatively strong, safe harbours that would dramatically favour digital assets vis a vis other financial technologies by cutting compliance costs around certain database technologies for no clearly articulable reason. While we think these requests are ridiculous and should be rejected we do recognize it is a positive development for policy development that web3 businesses that want these outcomes are now willing to so clearly state that in writing.

Then, in the middle, we have a clear desire to protect and sometimes further personal privacy through technology. Alongside that desire we see people grappling with the challenges and limitations that naturally accompany programmable systems. Coin Center’s comment lays bare an advocacy group that seems to recognize some of their own goals are fundamentally incompatible with each other and compromises must be made. We believe this is a step forward mainly because it is true and recognizing true facts about reality is always a step forward whether or not they align with your goals or desires. Coin Center has historically adopted positions which are objectively incompatible for technical reasons. If this is the first step is moderating their positions to achieve internal consistency and compatibility that is surely a net positive.

Finally, we have the BPI comment and similar other submissions. These read like groups that are skeptical of the utility of a lot of new supposedly-innovative-and-compliant-but-also-still-scandal-plagued technologies. Further, it sounds like they are trying to extract a clear framework from their regulators within which BPI-and-similar members can avoid compliance pitfalls and problems. To this group we say: we feel your pain. And we think the most productive use of your time is to work through the details of the technologies you are considering with an eye towards unmasking how similar they are to what you already use. There is less here than meets the eye and many of your problems will dissolve upon careful inspection without any regulatory comments. For competitive reasons on the business side you probably should push for clarity even if such clarity is devoid of new substance and entirely redundant.

We have no idea what, if anything, will come from this process. But it is undoubtedly excellent to get everyone on the record like this. And we would encourage anyone with an interest in open web3 regulatory questions to read many more of these comments to get a more detailed sense of many parties’ positions.


Treasury Digital Assets Illicit Activity RFC Part 2: Some Others’ Comments was originally published in ChainArgos on Medium, where people are continuing the conversation by highlighting and responding to this story.

Medium
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments