One Bank Asked the OCC to Have an “Agile Approach to Supervisory Oversight”

On September 27, 2019 the OCC published an Interpretive Letter answering an unknown bank’s request to make some innovative changes to how it files cash structuring SARs. Tacked onto its three technical questions was a request by the bank to do this innovation along with the OCC itself through something the bank called an “agile approach to supervisory oversight.” After qualified “yes” answers to the three technical questions, the OCC’s Senior Deputy Comptroller and Chief Counsel indicated that the OCC was open to “an agile and transparent supervisory approach while the Bank is building this automated solution” but he didn’t actually write that the OCC would, in fact, adopt an agile approach. This decision provides some insight, and perhaps the first public test, of (i) the regulators’ December 2018 statement on using innovative efforts to fight money laundering, and (ii) the OCC’s April 2019 proposal around innovation pilot programs. Whether the OCC passed the test is open to discussion: what appears settled, though, is that AML innovation in the regulated financial sector remains a perilous endeavor.

Regulators’ December 2018 Joint Statement on Innovative AML Efforts

On December 3, 2018 the five main US Bank Secrecy Act (BSA) regulators issued a joint statement titled “Innovative Efforts to Combat Money Laundering and Terrorist Financing”.[1] The intent of the statement was to encourage banks to use modern-era technologies to bolster their BSA/AML compliance programs. The agencies asked banks “to consider, evaluate, and, where appropriate, responsibly implement innovative approaches to meet their Bank Secrecy Act/anti-money laundering (BSA/AML) compliance obligations, in order to further strengthen the financial system against illicit financial activity” and “[t]he Agencies recognize[d] that private sector innovation, including new ways of using existing tools or adopting new technologies, can help banks” to do so.

The statement was a very positive step to encourage private sector innovation in fighting financial crime by testing new ways of using existing tools as well as adopting new technologies.

But it wasn’t the “green light to innovate” that some people have said it is. There was some language in the statement that made it, at best, a cautionary yellow light. And the September 27th OCC letter seems to clarify that banks can innovate, but the usual regulatory oversight and potential sanctions still apply.

The Agencies’ December 2018 statement included five things that bear repeating:

1. “The Agencies recognize that private sector innovation, including new ways of using existing tools or adopting new technologies, can help banks identify and report money laundering, terrorist financing, and other illicit financial activity by enhancing the effectiveness and efficiency of banks’ BSA/AML compliance programs. To assist banks in this effort, the Agencies are committed to continued engagement with the private sector and other interested parties.”
2. “The Agencies will not penalize or criticize banks that maintain effective BSA/AML compliance programs commensurate with their risk profiles but choose not to pursue innovative approaches.”
3. “While banks are expected to maintain effective BSA/AML compliance programs, the Agencies will not advocate a particular method or technology for banks to comply with BSA/AML requirements.”
4. Where test or implemented “artificial intelligence-based transaction monitoring systems … identify suspicious activity that would not otherwise have been identified under existing processes, the Agencies will assess the adequacy of banks’ existing suspicious activity monitoring processes independent of the results of the pilot program”
5. “… the implementation of innovative approaches in banks’ BSA/AML compliance programs will not result in additional regulatory expectations.”

Note the strong, unqualified language: “the Agencies are committed to continued engagement”, “the Agencies will not penalize or criticize”, “the Agencies will not advocate …”, “the Agencies will assess”, and “the implementation of innovative approaches will not result in additional regulatory expectations”.

The qualified “assurances” come in the paragraph about pilot programs (with emphasis added):

“Pilot programs undertaken by banks, in conjunction with existing BSA/AML processes, are an important means of testing and validating the effectiveness of innovative approaches.  While the Agencies may provide feedback, pilot programs in and of themselves should not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful.  Likewise, pilot programs that expose gaps in a BSA/AML compliance program will not necessarily result in supervisory action with respect to that program.  For example, when banks test or implement artificial intelligence-based transaction monitoring systems and identify suspicious activity that would not otherwise have been identified under existing processes, the Agencies will not automatically assume that the banks’ existing processes are deficient.  In these instances, the Agencies will assess the adequacy of banks’ existing suspicious activity monitoring processes independent of the results of the pilot program.  Further, the implementation of innovative approaches in banks’ BSA/AML compliance programs will not result in additional regulatory expectations.”

Here there are the qualified assurances (a qualified assurance is not an assurance, by the way): “should not” is different than “will not”; “will not necessarily” is very different than “will not”; and “not automatically assume” isn’t the same as “not assume”.  These are important distinctions. The agencies could have written something very different:

“… pilot programs in and of themselves will not subject banks to supervisory criticism even if the pilot programs ultimately prove unsuccessful.  Likewise, pilot programs that expose gaps in a BSA/AML compliance program will not result in supervisory action with respect to that program.  For example, when banks test or implement artificial intelligence-based transaction monitoring systems and identify suspicious activity that would not otherwise have been identified under existing processes, the Agencies will not assume that the banks’ existing processes are deficient …”

The OCC’s April 2019 Innovation Pilot Program

On April 30, 2019 the OCC sought public comment on its proposed Innovation Pilot Program, a voluntary program designed to provide fintech providers and financial institutions “with regulatory input early in the testing of innovative activities that could present significant opportunities or benefits to consumers, businesses, financial institutions, and communities.” See OCC Innovation Pilot Program. As the OCC has written, the Innovation Pilot Program clearly notes that the agency would not provide “statutory or regulatory waivers and does not absolve entities participating in the program from complying with applicable laws and regulations.”

Twenty comments were posted to the OCC’s website. A number of them included comments that innovators needed some formalized regulatory forbearance in order to be able encourage them to innovate. The Bank Policy Institute’s letter (BPI Comment), submitted by Greg Baer (a long-standing and articulate proponent of reasonable and responsible regulation), provided that:

“… the OCC should clarify publicly that a bank is not required to seek the review and approval of its examination team prior to developing or implementing a new product, process, or service; that unsuccessful pilots will not warrant an MRA or other sanction unless they constitute and unsafe and unsound practice or a violation of law; and that innovations undertaken without seeking prior OCC approval will not be subject to stricter scrutiny or a ‘strict liability’ regime. We also recommend that the OCC revisit and clarify all existing guidance on innovation to reduce the current uncertainty regarding the development of products, processes and services; outdated or unnecessary supervisory expectations should be rescinded.”

The American Bankers Association comment ABA Comment also asks for similar guidance:

“For institutions to participate confidently in a pilot, there must be internal agreement that OCC supervision and enforcement will not pursue punitive actions. In other words, the program should produce decisions that have the full support of the OCC and bind the agency to those conclusions going forward … One way for the OCC to accomplish this is to clarify that a participating bank will not be assigned Matters Requiring Attention (MRAs) if it acts in good faith as part of a Pilot Program. The nature of technological innovation means that banks must try new things, experiment, and sometimes make mistakes. The Pilot Program has been designed as a short-term limited-scale test to ensure that any mistakes made are unlikely to have an impact on the safety and soundness of an institution. Clarifying that MRAs will not be issued for mistakes made in good faith may help give banks the certainty they need to participate in a Pilot Program.”

And the Securities Industry and Financial Markets Association (SIFMA) comment letter SIFMA Comment Letter included the following:

“Relief from strict regulatory compliance is a vital prerequisite to draw firms into the test environment, precisely so that those areas of noncompliance may be identified and remediated and avoid harm to the consumers. Without offering this regulatory relief, the regulatory uncertainty associated with participating in the Pilot Program could, by itself, deter banks from participating. Similarly, the lack of meaningful regulatory relief could limit the opportunity the program provides for firms to experiment and innovate.”

So where did that leave banks that were thinking of innovative approaches to AML?  For those that choose not to pursue innovative pilot programs, it is clear that they will not be penalized or criticized, but for those that try innovative pilot programs that ultimately expose gaps in their BSA/AML compliance program, the agencies will not automatically assume that the banks’ existing processes are deficient. In response to this choice – do not innovate and not be penalized, or innovate and risk being penalized – many banks have chosen the former. As a result, advocates for those banks – the BPI and ABA, for example – have asked the OCC to clarify that it will not pursue punitive actions against banks that unsuccessfully innovate.

How has the OCC replied? It hasn’t yet finalized its Innovation Program, but it has responded to a bank’s request for guidance on some innovative approaches to monitoring for, alerting on, and filing suspicious activity reports on activity and customers that are structuring cash transactions.

A Bank’s Request to Have the OCC Help It Innovate

The OCC published an Interpretive Letter on September 27, 2019 that sheds some light on how it looks at its commitments under the December 2018 innovation statement.[2]  According to the Interpretive Letter, on February 22, 2019 an OCC-regulated bank submitted a request to streamline SARs for potential structuring activity (the Bank also sought the same or a similar ruling from FinCEN: as of this writing, FinCEN has not published a ruling). The bank asked three questions (and the OCC responded):

1. Whether the Bank could file a structuring SAR based solely on an alert, without performing a manual investigation, and if so, under what circumstances (yes, but with some significant limitations);
2. Whether the proposed automated generation of SAR narratives for structuring SARs was consistent with the OCC’s SAR regulations (yes, but with some significant limitations);
3. Whether the proposed automation of SAR filings was consistent with the OCC’s BSA program regulations (yes, but with some significant limitations).

The most interesting request by the Bank, though, was its request that the OCC take an “agile approach to supervisory oversight” for the bank’s “regulatory sandbox” initiative. Pages 6 and 7 of the OCC letter provide the particulars of this request. There, the OCC writes:

“Your letter also requested regulatory relief to conduct this initiative within a “regulatory sandbox.” Your regulatory sandbox request states ‘This relief would be in the form of an agile approach to supervisory oversight, which would include the OCC’s full access, evaluation, and participation in the initiative development, but would not include regulatory outcomes such as matters requiring attention, violations of law or financial penalties. [The Bank] welcomes the OCC to consider ways to participate in reviewing the initiative outcomes outside of its standard examination processes to ensure effectiveness and provide feedback about the initiative development.’”

NOTE: I had to read the key sentence a few times to settle on its intent and meaning. That sentence is “This relief would be in the form of an agile approach to supervisory oversight, which would include the OCC’s full access, evaluation, and participation in the initiative development, but would not include regulatory outcomes such as matters requiring attention, violations of law or financial penalties.”

Was the bank saying the relief sought was an agile approach to supervisory oversight that included the OCC’s full participation in the process and no adverse regulatory outcomes? Or was the bank saying the relief sought was an agile approach to supervisory oversight that included the OCC’s full participation in the process, but did not include anything to do with adverse regulatory outcomes?

I settled on the latter meaning: that the bank was seeking the OCC’s full participation, but did not expect any regulatory forbearance.

The OCC first reiterated its position from the December 2018 joint statement by writing that it “supports responsible innovation in the national banking system that enhances the safety and soundness of the federal banking system, including responsibly implemented innovative approaches to meeting the compliance obligations under the Bank Secrecy Act.” It then wrote that it “is also open to an agile and transparent supervisory approach while the Bank is building this automated solution for filing Structuring SARs and conducting user acceptance testing.” This language is a bit different than what the OCC wrote at the top of page 2 of the letter: “the OCC is open to engaging in regular discussions between the Bank and appropriate OCC personnel, including providing proactive and
timely feedback relating to this automation proposal.”

Notably, the OCC wrote that it is “open to an agile and transparent supervisory approach”, and “open to engaging in regular discussions between the Bank and appropriate OCC personnel”, but being open to something doesn’t mean you approve of it or agree to it. In fact, the OCC didn’t appear to grant the bank’s request. In the penultimate sentence the OCC wrote: “The OCC will monitor any such changes through its ordinary supervisory processes.”

How About Forbearance to Innovate Without Fear of Regulatory Sanctions?

As set out above, in June 2019 the BPI and ABA (and eighteen others) commented on the OCC’s proposal for an innovation pilot program. The BPI commented that “the OCC should clarify publicly that … unsuccessful pilots will not warrant an MRA or other sanction unless they constitute and unsafe and unsound practice or a violation of law”, and the ABA commented that the OCC should “clarify that a participating bank will not be assigned Matters Requiring Attention (MRAs) if it acts in good faith as part of a Pilot Program”.

The OCC seems to have obliquely responded to both of those comments. In its September 2019 Interpretative Letter, the OCC took the time to write that it “will not approve a regulatory sandbox that includes forbearance on regulatory issues for the Bank’s initiative for the automation of Structuring SAR filings.” Note that the OCC made this statement even though the bank appears to have specifically indicated that the requested relief did not include forbearance from “regulatory outcomes such as matters requiring attention, violations of law or financial penalties”. And the OCC letter includes a reference to both the Interagency statement on responsible innovation and the OCC’s April 2019 Innovation Pilot Program (see footnote 25 on page 7): “banks must continue to meet their BSA/AML compliance obligations, as well as ensure the ongoing safety and soundness of the bank, when developing pilot programs and other innovative approaches.”

So although the OCC hasn’t formally responded to the comments to its June 2019 innovation program to allow banks to innovate without fear of regulatory sanction if that innovation doesn’t go well, it has made it clearer that a bank still has the choice to not innovate and not be penalized, or to innovate and risk being penalized.

(In fairness, in its Spring 2019 Semiannual Risk Perspective Report, the OCC noted that a bank’s inability to innovate is “a source of significant strategic risk.” See OCC Semiannual Risk Perspective, 2019-49 (May 20, 2019)).

Timely Feedback – Is Seven Months Timely?

As set out above, the OCC wrote that it “is open to engaging in regular discussions between the Bank and appropriate OCC personnel, including providing proactive and timely feedback …”.  The bank’s request was submitted on February 22, 2019. The OCC’s feedback was sent on September 27, 2019. So it took the OCC seven months to respond to the bank’s request for an interpretive letter. In this age of high-speed fintech disruption, seven months should not be considered “timely.” What would be timely? I would aim for 90 days.

Conclusion

This unnamed OCC-regulated bank appears to have a flashing green or cautionary yellow light from the OCC to deploy some technology and process enhancements to streamline a small percentage if its SAR monitoring, alerting, and filing.  The OCC will remain vigilant, however, warning the bank that it “must ensure that it has developed and deployed appropriate risk governance to enable the bank to identify, measure, monitor, and control for the risks associated with the automated process. The bank also has a continuing obligation to employ appropriate oversight of the automated process.”

So the message to the 1,700 or so OCC banks appears to be this: there’s no peril in not innovating, but if you decide to innovate, do so at your peril.

[1] The Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation (FDIC), the Financial Crimes Enforcement Network (FinCEN), the National Credit Union Administration, and the Office of the Comptroller of the Currency. The statement is available at https://www.occ.gov/news-issuances/news-releases/2018/nr-occ-2018-130a.pdf

[2] https://www.occ.gov/topics/charters-and-licensing/interpretations-and-actions/2019/int1166.pdf

There is a lot of media attention around the need for a new way to tackle financial crimes risk management. Apparently the current regime is “broken” (I disagree) or in desperate need of repair (what government-run programs are not in some sort of state of disrepair?), or, at the very least, not particularly effective nor efficient. And there are a lot of suggestions from the private and public sectors on how to make the regime more effective and more efficient.  I’ll offer seven things to consider as we all work towards renovating our BSA/AML regime, to take it from its tired, dated (the last legislative change to the three statutes we call the Bank Secrecy Act was made in 2004) state to something that provides a more balanced, effective, and efficient regime.

I. Transaction Monitoring Systems

Apparently, current customer- and account-based transaction monitoring systems are highly inefficient, because for every 100 alerts they produce, five or fewer actually end up being reported to the government in a Suspicious Activity Report. The transaction monitoring software is often blamed (although bad data is the more likely culprit), and machine learning and artificial intelligence are often touted (by providers of machine learning and artificial intelligence) as the solutions. Consider the following when it comes to transaction monitoring and false positives:

1. If a 95% false positive rate is bad … what is good? Human-generated referrals will result in SARs about 50% of the time: that might be a good standard.
2. We have to stop tuning our transaction monitoring systems against SARs filed with law enforcement, and start tuning them against SARs used by law enforcement. I’ve written about this on many occasions, and have offered up something called the “TSV” SAR – a SAR that law enforcement indicates has Tactical or Strategic Value.
3. High false positives rates may not be caused by bad data or poor technology at all, but by regulatory expectations – real or imagined – that financial institutions can’t afford the audit, regulatory, legal, and reputational costs of failing to identify (alert on) something unusual or anomalous that could eventually be found to have been suspicious.

(I’ve written about this on a few occasions: see, for example, RegTech Consulting Article).

It may be that transaction monitoring itself is the culprit (and not bad data, outmoded technology, or unreasonable regulatory expectations). My experience is that customer- and account-based transaction monitoring is not nearly as effective as relationship-based interaction surveillance. Let’s parse this out:

• Customer versus relationship – focusing on a single customer is less efficient than looking at the entire relationship that customer is or could be part of. Bank’s marketing departments think in terms of households as the key relationship: credit department’s think in terms of parent and subsidiary entities and guarantors as the needed relationship in determining credit worthiness. Financial crimes departments need to also think in the same terms. It is simply more encompassing and more efficient.
• Transaction versus interaction – customers may interact with a bank many times, through a phone call, an online session, a balance inquiry, or a mobile look-up, before they will perform an actual transaction or movement of value. Ignoring those interactions, and only focusing on transactions, doesn’t provide the full picture of that customer’s relationship with the bank.
• Monitoring versus surveillance – monitoring is not contextual: it is simply looking at specific transaction types, in certain amounts or ranges, performed by certain customers or customer classes. Surveillance, on the other hand, is contextual: it looks at the context of certain activity compared against all activity of that customer over time, and/or of certain activity of that customer compared to other customers within its class (Whatever that class may be).

So the public sector needs to encourage the private sector to shift from a customer-based transaction monitoring regime to a relationship-based interaction surveillance regime.

II. Information Sharing

Crime and criminal organizations don’t operate in a single financial institution or even in a single jurisdiction. Yet our BSA/AML regime still encourages single entity SAR filers and doesn’t promote cross-jurisdictional information sharing.  The tools are available to better share information across a financial institution, and between financial institutions. Laws, regulations, and regulatory guidance all need to change to specifically and easily allow a single financial institution operating in multiple jurisdictions to (safely) share more information with itself, to allow multiple institutions in a single and multiple jurisdictions to (safely) share more information between them, and to allow those institutions to jointly investigate and report together. Greater encouragement and use of Section 314(b) associations and joint SAR filings are critical.

III. Classical Music, or Jazz?

Auditors, regulators, and even a lot of FinTech companies, would prefer that AML continue to be like classical music, where every note (risk assessments and policies) is carefully written, the music is perfectly orchestrated (transaction monitoring models are static and documented), and the resulting music (SAR filings) sounds the same time and time again regardless of who plays it. This allows the auditors and regulators to have perfectly-written test scripts to audit and examine the programs, and allows the FinTech companies to produce a “solution” to a defined problem. This approach may work for fraud, where an objective event (a theft or compromise) produces a defined result (a monetary loss). But from a financial institution’s perspective, AML is neither an objective event nor a defined result, but is a subjective feeling that it is more likely than not that something anomalous or different has occurred and needs to be reported. So AML is less like classical music and more like jazz: defining, designing, tuning, and running effective anti-money laundering interaction monitoring and customer surveillance systems is like writing jazz music … the composer/arranger (FinTech) provides the artist (analyst) a foundation to freely improvise (investigate) within established and consistent frameworks, and no two investigations are ever the same, and similar facts can be interpreted a different way by different people … and a SAR may or may not be filed. AML drives auditors and examiners mad, and vexes all but a few FinTechs. So be it. Let’s acknowledge it, and encourage it.

IV. Before Creating New Tools, Let’s Use the Ones We Have

The federal government has lots of AML tools in its arsenal: it simply needs to use them in more courageous and imaginative ways. Tools such as section 311 Special Measures and 314 Information Sharing are grossly under-utilized. Information sharing is discussed above: section 311 Special Measures are reserved for the most egregious bad actors in the system, and are rarely invoked. But the reality is that financial institutions will kick out a customer or not (knowingly) provide services to entire classes of customers or in certain jurisdictions for fear of not being able to economically manage the perceived risk/reward equation of that customer or class of customer or jurisdiction. But that customer or class or jurisdiction simply goes to another financial institution in the regulated sector, or to an institution in an un- or under-regulated sector (the notion of “de-risking”). The entire financial system would be better off if, instead of de-risking a suspected bad customer or class of customer or jurisdiction, financial institutions were not encouraged to exit at all, but encouraged to keep that customer or class, and monitor for and report any suspicious activity. Then, if the government determined that the customer or class of customers was too systemically risky to be banked at all, it could use section 314 to effectively blacklist that customer or class of customers. Imposing “special measures” shouldn’t be a responsibility of private sector financial institutions guessing at whether a customer or class of customers is a bad actor: it is and should be the responsibility of the federal government using the tool it currently has available to it: Section 311.

V. … and Let’s Restore The Tool We Started With

The reporting of large cash transactions was the first AML tool the US government came up with (in 1970 as part of the Currency & Foreign Transactions Reporting Act).  Those reports, called Currency Transaction Reports, or CTRs, started out as single cash transactions on behalf of an accountholder, for more than $10,000.  They have since morphed to one or more cash transactions aggregating to more than $10,000 in a 24-hour period, by or on behalf of one or more beneficiaries.  There will be more than 18 million CTRs filed this year, and apparently law enforcement finds them an effective tool. But there is nothing more inefficient: simply put, CTRs are now the biggest resource drain in BSA/AML. Because of regulatory drift, CTRs are de facto SAR-lites … we need to get back to basic CTRs and redeploy the resources used to wrestle with the ever-expanding aggregation and “by or on behalf of” requirements, and deploy them against potential suspicious activity. And forget about increasing the threshold amount from the current “more than $10,000” standard: $10,000 is almost 5,000 times the amount of the average cash transaction in the United States today (which is $22, according to multiple reports from the Federal Reserve), and no one can argue that having a requirement to report a transaction or transactions that are 5,000 times the average is unreasonable. And it isn’t the amount that causes inefficiencies, it is the requirements to (i) aggregate multiple transactions totaling more than $10,000 in a 24-hour period, (ii) to identify and aggregate transactions “by or on behalf of” multiple parties and accountholders, and (iii) exempt, on a bank-by-bank basis, certain entities that can be exempted (but rarely are) from the CTR filing regime. If anything, we could save and redploy resources if the CTR threshold was the same as the SAR threshold – $5,000.

VI. The Clash of the Titles

And remember the “Clash of the Titles” … the protect-the-financial-system (filing great SARs) requirements of Title 31 (Money & Finance … the BSA) are trumped by the safety and soundness (program hygiene) requirements of Title 12 (Banks & Banking), and financial institutions act defensively because of the punitive measures in Title 18 (Crimes & Criminal Procedure) and Title 50 (War … OFAC’s statutes and regulations). There is a need to harmonize the Four Titles – or at least Titles 12 and 31 – and how financial institutions are examined against them. BSA/AML people are judged on whether they avoid bad TARP results (from being Tested, Audited, Regulated, and Prosecuted) rather than  on whether they provide actionable, timely intelligence to law enforcement. Today, most BSA Officers live in fear of not being able to balance all their commitments under the four titles: the great Hugh MacLeod was probably thinking of BSA Officers when he wrote: “I do the work for free. I get paid to be afraid …”

VII. A Central Registry for Beneficial Ownership Information

At the root of almost all large money laundering cases are legal entities with opaque ownership, or shell companies, where kleptocrats, fraudsters, tax evaders, and other miscreants can hide, move, and use their assets with near impunity.  Greater corporate transparency has long been seen as one of the keys to fighting financial crime (the FATF’s Recommendation 24 on corporate transparency was first published in 1993), and accessible central registries of beneficial ownership information have been proven to be the key to that greater transparency. Yet the United States is one of the few major financial centers that does not have a centralized registry of beneficial ownership information. I’ve written that without such a centralized registry, the current beneficial ownership requirements are ineffective.  See Beneficial Ownership Registry Article. Two bills currently before Congress – the Senate’s ILLICIT Cash Act (S2563) and the House’s Corporate Transparency Act (HR2513) both contemplate a centralized registry of beneficial ownership maintained by FinCEN. But both of those bills – and FATF recommendations and guidance on the same issue – fall short in that they only allow law enforcement (or “competent authorities” using the FATF term) to freely access that database. The bills before Congress allow financial institutions to access the database but only with the consent of the customer they’re asking about and only for the purposes of performing due diligence on that customer. I have proposed that those bills be changed to also allow financial institutions to query the database without the consent of the entity they’re asking about for the purposes of satisfying their suspicious activity reporting requirements.

Conclusion – Seven Fixer-Upper Projects for the BSA/AML Regime

1. Shift from customer-centric transaction monitoring systems to relationship-based interaction surveillance systems
2. Encourage cross-institutional and cross-jurisdictional information sharing
3. Encourage the private sector to be more creative and innovative in its approach to AML – AML is like jazz music, not classical music
4. Address de-risking through aggressive use of Section 311 Special Measures
5. Simplify the CTR regime. Please. And forget about increasing the $10,000 threshold – in fact, reduce it to $5,000
6. As long as financial institutions are judged on US Code Titles 12, 18, 31, and 50, expect them to be both ineffective and inefficient. Can Titles 12 and 31 try to get along?
7. A central registry of beneficial ownership information that is freely accessible to financial institutions is a must have

“Organisations and individuals developing, deploying or operating AI systems should be held accountable for their proper functioning”

For all the upstart fintechs out there that are trumpeting their innovative Artificial Intelligence-based solutions that can solve a financial institution’s financial crimes problems! … note that you may be held accountable when that AI system doesn’t quite turn out like your marketing materials suggested. Legal responsibility for something you design, build, and deploy is not a new concept, but how that “something” – in this case, the AI system you developed and installed at a client bank – actually works, and reacts, and adapts, over time could very be new ground that hasn’t been explored before. But many smart people are thinking about AI developers’ accountability, and other AI-related issues, and many of those have produced some principles to guide us as we develop and implement AI-based systems.

On May 22, 2019 the OECD published a Council Recommendation on Artificial Intelligence. At its core, the recommendation is for the adoption of five complimentary “value-based principles for responsible stewardship of trustworthy artificial intelligence. The link is Artificial intelligence and the actual recommendation is https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0449#_ga=2.200835047.853048335.1559167756-681244095.1559167756

What’s the big deal about artificial intelligence?

The OECD recognized a number of things about AI that are worth including:

• AI has pervasive, far-reaching and global implications that are transforming societies, economic sectors and the world of work, and are likely to increasingly do so in the future;
• AI has the potential to improve the welfare and well-being of people, to contribute to positive sustainable global economic activity, to increase innovation and productivity, and to help respond to key global challenges;
• At the same time, these transformations may have disparate effects within, and between societies and economies, notably regarding economic shifts, competition, transitions in the labour market, inequalities, and implications for democracy and human rights, privacy and data protection, and digital security;
• Trust is a key enabler of digital transformation; that, although the nature of future AI applications and their implications may be hard to foresee, the trustworthiness of AI systems is a key factor for the diffusion and adoption of AI; and that a well-informed whole-of-society public debate is necessary for capturing the beneficial potential of the technology, while limiting the risks associated with it;
• Given the rapid development and implementation of AI, there is a need for a stable policy environment that promotes a human-centric approach to trustworthy AI, that fosters research, preserves economic incentives to innovate, and that applies to all stakeholders according to their role and the context;
• certain existing national and international legal, regulatory and policy frameworks already have relevance to AI, including those related to human rights, consumer and personal data protection, intellectual property rights, responsible business conduct, and competition, while noting that the appropriateness of some frameworks may need to be assessed and new approaches developed; and
• Embracing the opportunities offered, and addressing the challenges raised, by AI applications, and empowering stakeholders to engage is essential to fostering adoption of trustworthy AI in society, and to turning AI trustworthiness into a competitive parameter in the global marketplace.

What is “Artificial Intelligence”?

The recommendation includes some helpful definitions of the major terms:

Artificial Intelligence System: a machine-based system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments. AI systems are designed to operate with varying levels of autonomy.

Artificial Intelligence System Lifecycle: four phases which can be sequential but may be iterative:

(i) design, data and models – a context-dependent sequence encompassing planning and design, data collection and processing, as well as model building;

(ii) verification and validation;

(iii) deployment; and

(iv) operation and monitoring

Artificial Intelligence Actors: AI actors are those who play an active role in the AI system lifecycle, including organisations and individuals that deploy or operate AI.

Is an OECD Recommendation binding on a country that has adopted it?

OECD Recommendations are not legally binding but they are highly influential and have many times formed the basis of international standards and helped governments design national legislation. For example, the OECD Privacy Guidelines adopted in 1980 and stating that there should be limits to the collection of personal data underlie many privacy laws and frameworks in the United States, Europe and Asia.

So the AI Principles are not binding, but the OECD provided five recommendations to governments:

1. Facilitate public and private investment in research & development to spur innovation in trustworthy AI.
2. Foster accessible AI ecosystems with digital infrastructure and technologies and mechanisms to share data and knowledge.
3. Ensure a policy environment that will open the way to deployment of trustworthy AI systems.
4. Empower people with the skills for AI and support workers for a fair transition.
5. Co-operate across borders and sectors to progress on responsible stewardship of trustworthy AI.

Who developed the OECD AI Principles?

The OECD set up a 70+ member expert group on AI to scope a set of principles. The group consisted of representatives of 20 governments as well as leaders from the business (Google, Facebook, Microsoft, Apple, but not any financial institutions), labor, civil society, academic and science communities. The experts’ proposals were taken on by the OECD and developed into the OECD AI Principles.

What is the Purpose of the OECD Principles on AI?

The OECD Principles on Artificial Intelligence promote artificial intelligence (AI) that is innovative and trustworthy and that respects human rights and democratic values. The OECD AI Principles set standards for AI that are practical and flexible enough to stand the test of time in a rapidly evolving field. They complement existing OECD standards in areas such as privacy, digital security risk management and responsible business conduct.

What are the OECD AI Principles?

The Recommendation identifies five complementary values-based principles for the responsible stewardship of trustworthy AI:

1. Inclusive growth, sustainable development and well-being – AI systems should be designed in a way that respects the rule of law, human rights, democratic values and diversity, and they should include appropriate safeguards – for example, enabling human intervention where necessary – to ensure a fair and just society. And AI should benefit people and the planet by driving inclusive growth, sustainable development and well-being.

The actual text reads: “Stakeholders should proactively engage in responsible stewardship of trustworthy AI in pursuit of beneficial outcomes for people and the planet, such as augmenting human capabilities and enhancing creativity, advancing inclusion of underrepresented populations, reducing economic, social, gender and other inequalities, and protecting natural environments, thus invigorating inclusive growth, sustainable development and well-being.

2. Human-centred values and fairness – AI actors should respect the rule of law, human rights and democratic values, throughout the AI system lifecycle. These include freedom, dignity and autonomy, privacy and data protection, non-discrimination and equality, diversity, fairness, social justice, and internationally recognized labor rights. To this end, AI actors should implement mechanisms and safeguards, such as capacity for human determination, that are appropriate to the context and consistent with the state of art.

3. Transparency and explainability – AI Actors should commit to transparency and responsible disclosure regarding AI systems. To this end, they should provide meaningful information, appropriate to the context, and consistent with the state of art to foster a general understanding of AI systems, to make stakeholders aware of their interactions with AI systems, including in the workplace, to enable those affected by an AI system to understand the outcome, and, to enable those adversely affected by an AI system to challenge its outcome based on plain and easy-to-understand information on the factors, and the logic that served as the basis for the prediction, recommendation or decision.

4. Robustness, security and safety – AI systems should be robust, secure and safe throughout their entire lifecycle so that, in conditions of normal use, foreseeable use or misuse, or other adverse conditions, they function appropriately and do not pose unreasonable safety risk. To this end, AI actors should ensure traceability, including in relation to datasets, processes and decisions made during the AI system lifecycle, to enable analysis of the AI system’s outcomes and responses to inquiry, appropriate to the context and consistent with the state of art. And AI actors should, based on their roles, the context, and their ability to act, apply a systematic risk management approach to each phase of the AI system lifecycle on a continuous basis to address risks related to AI systems, including privacy, digital security, safety and bias.

5. Accountability – AI actors should be accountable for the proper functioning of AI systems and for the respect of the above principles, based on their roles, the context, and consistent with the state of art. Organisations and individuals developing, deploying or operating AI systems should be held accountable for their proper functioning in line with the above principles.

What countries belong to the OECD?

Australia, Austria, Belgium, Canada, Chile, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Israel, Italy, Japan, Korea, Latvia, Lithuania, Luxembourg, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Slovak Republic, Slovenia, Spain, Sweden, Switzerland, Turkey, United Kingdom, United States

Former Bank Cash Vault Manager Sentenced to 10 Years in Federal Prison for Stealing over $4 Million – Case Reveals Gaps in “Dual Control” Training

The RegTech, SupTech, and FinTech communities are focused on developing new technologies to speed up, simplify, and streamline financial institutions’ ability to implement new rules, regulations, and regulatory guidance. But there are two other stages of the regulatory life cycle that may be longer and more problematic for financial institutions than implementing new regulations: these are the time it takes for new regulations to be written and published (“Regulatory Lag”), and the time it takes to enforce those regulations (“Regulatory Drag”).

Time to Regulate – or “Regulatory Lag”.

This lag occurs where a new risk emerges, or a new product is introduced, or an existing product is used in new ways. There is always a lag between that new risk or product and the resulting legislative and/or regulatory response. In the meantime, institutions have to begin addressing the new risks when they first emerge – they can’t wait for new rules, regulatory guidance, and regulations to begin the multi-year people, process, and technology changes necessary to address the requirements of the regulation. Those early, pre-rule and pre-regulation efforts at building controls to address new risks can be expensive, and institutions run the risk of missing the mark and having to re-do much of what they’ve built. The best example of regulatory lag in the AML space is 9/11, which saw legislation passed in 45 days (October 2001), regulations published two years later (2003), and regulatory guidance in the form of the BSA Exam Manual two years after that (2005). Although it was only 45 days that financial institutions knew about the new information sharing provisions in section 314 of the USA PATRIOT Act, it was almost another four years before financial institutions knew how their regulators would examine their compliance with those information sharing provisions. It was this “regulatory lag” that led to my written statement (in December 2006) that “we’ll be judged tomorrow on what we’re building today, based on regulations that haven’t yet been written and best practices that haven’t been shared.”

Time to Enforce – or “Regulatory Drag”

Public enforcement actions (and prosecutions) drive a lot of compliance-related behavior in financial services. Yet there are multi-year delays between when the impugned behavior occurred and when a public enforcement action (and/or prosecution) makes them known to the industry. FinCEN’s December 2014 action against MoneyGram’s former BSA Officer is a good example: that action was made public in December 2014, and alleged violations of the Bank Secrecy Act that occurred from 2003 through May 2008, or more than 6 ½ years from the last day of the impugned activity and when the public action was taken.

What Can Technology Do To Address Regulatory Lag and Drag?

Regulatory lag and drag have been around for as long as there have been regulators. But with the world speeding up as much as it is, with new products and services, and new providers, being rolled out and created much faster than regulatory bodies can manage, there must be changes made in the entire regulatory life cycle.

FinTech providers and their customers demand a fast revolution. Regulators prefer a slow, deliberate evolution. There has to be a better way to identify new and emerging risks, to draft and communicate regulations to address those risks, and to implement the needed controls to manage those risks.

I’m not sure what can be done from a purely technology perspective to speed up regulators (and prosecutors), but the proponents of FinTech, RegTech, and SupTech solutions shouldn’t just focus on digitizing the implementation of new regulations, but on digitizing the entire regulatory life cycle: the regulatory lag between new risks and new regulations, the regulations themselves, and the regulatory drag from regulatory problem to public resolution.

Posted on LinkedIn on January 28, 2019 https://www.linkedin.com/pulse/regulatory-lag-drag-fintech-solutions-jim-richards/

The Commodity Futures Trading Commission (CFTC) recently published an excellent primer on Smart Contracts.

I’ve reproduced most of the primer here: it was a PowerPoint reduced to PDF, so some of the images are not included. But the main gist of it is here.

Notably, the CFTC notes that “a ‘smart contract’ is not necessarily ‘smart.’  The operation is only as smart as the information feed it receives and the machine code that directs it.”  This is a great quote, expressing a sentiment that I have repeatedly stated in the context of machine learning and artificial intelligence applications for financial crimes risk management … they are only as good as the data they receive!

CFTC’s LabCFTC “A PRIMER ON SMART CONTRACTS”

https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718_0.pdf

What is a smart contract?

Fundamentally, a “smart contract” is a set of coded computer functions. It may incorporate the elements of a binding contract (e.g., offer, acceptance, and consideration), or may simply execute certain terms of a contract. A smart contract allows self-executing computer code to take actions at specified times and/or based on reference to the occurrence or non-occurrence of an action or event (e.g., delivery of an asset, weather conditions, or change in a reference rate).

A “smart contract” is not necessarily “smart.” The operation is only as smart as the information feed it receives and the machine code that directs it. A “smart contract” may not be a legally binding contract. It may be a gift or some other non-contractual transfer, it may be only part of a broader contract. To the extent a smart contract violates the law, it would not be binding or enforceable.

Smart Contracts Leverage Blockchain/DLT

Smart contracts can be stored and executed on a distributed ledger, an electronic record that is updated in real-time and intended to be maintained on geographically disperse servers or nodes. Through decentralization, evidence of the smart contract is deployed to all nodes on a network, which effectively prevents modifications not authorized or agreed by the parties. Blockchain is a continuously growing database of permanent records, “blocks,” which are linked and secured using cryptography. Note: Distributed ledgers may be public or private/permissioned. See “A CFTC Primer on Virtual Currencies,” October 17, 2017, https://www.cftc.gov/LabCFTC/Primers/index.htm

Smart Contract Origins & Recent Explanations

The concept of a smart contract is not new. More than 20 years ago, computer scientist Nick Szabo stated the following:

“A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on the other promises…. The basic idea of smart contracts is that many kinds of contractual clauses (such as liens, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.” Nick Szabo, Computer Scientist Smart Contracts Building Blocks for Digital Markets 1996 ‡ See Nick Szabo, Smart Contracts: Building Blocks for Digital Markets, 1996, http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html

“A smart contract is a mechanism involving digital assets and two or more parties, where some or all of the parties put assets in, and assets are automatically redistributed among those parties according to a formula based on certain data that is not known at the time the contract is initiated.” Vitalik Buterin, Founder of Ethereum, “DAOs, DACs, DAs and More: An Incomplete Terminology Guide,” (May 6, 2014), available at https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incompleteterminology-guide/

“A smart contract is an agreement in digital form that is self-executing and self-enforcing.” Kevin Werbach, Professor of Legal Studies & Business Ethics, University of Pennsylvania, Wharton Business School, “The Promise — and Perils — of ‘Smart’ Contracts,” (May 18, 2017), available at http://knowledge.wharton.upenn.edu/article/what-are-smart-contracts/

“A smart contract is an automatable and enforceable agreement. Automatable by computer, although some parts may require human input and control. Enforceable either by legal enforcement of rights and obligations or via tamper-proof execution of computer code.” ISDA and King and Wood Mallesons, Smart Derivatives Contracts: From Concept to Construction (October 2018), at 5 (citing Clack, C., Bakshi, V., and Braine, L., “Smart Contract Templates: foundations, design landscape and research directions” (August 4, 2016, revised March 15, 2017))

Smart contracts can be viewed as part of an evolution to automate processes with machines and self-executing code. Increasing automation has long been a feature of our financial markets including: for example, Stop Loss (Conditional) Orders (“If the price falls below $X, then sell at market”), and trading algorithms and smart order routers (machines that direct orders for execution).  Increasingly, smart contract-like automation is a feature of everyday life. Common examples include ATMs, automatic bill pay, touch-to-pay systems, and instant money transfer apps.

Potential Benefits of a Smart Contract

The attributes of a smart contract give rise to potential benefits throughout an economic transaction lifecycle, e.g., formation, execution, settlement.

Examples of a Smart Contract

The article provided three examples of a smart contract, a self-executing insurance contract, transportation (bicycle rental), and a credit default swap.

Other Potential Smart Contract Use Cases

Smart Contracts may have potential uses in financial market operations, and likewise may be useful in a variety of other areas as well. Examples include:

• Financial Markets and Participants
  • Derivatives – streamline post-trade processes, real time valuations and margin calls.
  • Securities – simplify capitalization table maintenance (e.g., automate dividends, stock splits).
  • Trade Clearing and Settlement – improve efficiency and speed of settlement with less misunderstandings of terms.
  • Supply Chain/Trade Finance – track product movement, streamline payments, facilitate lending and liquidity.
  • Data Reporting and Recordkeeping – greater standardization and accuracy (e.g., Swaps Data Reporting, regulator nodes for real time risk analysis); automated retention and destruction.
  • Insurance – automatic and automated claims processing based on specified events; Internet of Things (IoT) enabled vehicles/homes/farms could execute claims automatically.
• Other sample applications:
  • Public property records – maintain a “gold copy” of ownership and interests in real property.
  • Loyalty and rewards – can power travel or other rewards systems.
  • Electronic Medical Records – improves security and accessibility of data, empowering patients to control their own records while improving compliance with regulations (e.g., HIPAA).
  • Clinical Trials – protects patients with timestamped immutable consent forms, securely automates sequences, and increases data sharing of anonymized data while ensuring patient privacy.

Potentially Applicable Legal Frameworks

Depending on the facts and circumstances, a Smart Contract can be a binding legal contract. Smart contracts may be subject to a variety of legal frameworks depending on their application or product characterization. Examples include:

• Commodity Exchange Act and CFTC regulations
• Federal and state securities laws and regulations
• Federal, state, and local tax laws and regulations
• The Uniform Commercial Code (UCC), Uniform Electronic Transactions Act (UETA), and Electronic Signatures in Global and National Commerce Act (ESIGN Act)
• The Bank Secrecy Act, USA PATRIOT Act, and other Anti-Money Laundering (AML) laws and regulations
• State and federal money transmission laws.

Existing law and regulation apply equally regardless what form a contract takes. Contracts or constituent parts of contracts that are written in code are subject to otherwise applicable law and regulation.

Smart Contracts: Operational Risk

Smart contracts may not include appropriate or sufficient backup / failover mechanisms in case something goes awry. Smart contracts may depend on other systems to fulfill contract terms. These other systems may have vulnerabilities that could prevent the smart contract from functioning as intended.

Some smart contract platforms may be missing critical system safeguards and customer protections. Where smart contracts are linked to a blockchain, forks in the chain could create operational problems.

In case of an operational failure, recourse may be limited or non-existent – complete loss of a virtual asset is possible. Poor governance is another operational risk: smart contracts may require attention, action, and possible revision subject to appropriate governance and liability mechanisms.

Smart Contracts – Technical Risks

There are a number of technical risks, including:

• Unintended software vulnerabilities
• Humans! – make mi$taak3s when K0diNg
• Technology failures – internet service can go down, user interfaces may become incompatible, or computers/servers can stop working
• Scaling or bandwidth issues
• Divergent/Forked Blockchains – such events can create multiple smart contracts where only one existed, or may disrupt the functioning of a smart contract
• Future proofing – unforeseen or unanticipated future events that shock and/or stress the technology
• Oracle (the oracle, not Oracle) failure, disruption, or other issues with the external sources used to obtain reference prices, events, or other information.