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.

There is a lot of conversation in the industry about the inefficiencies of “traditional” rules-based monitoring systems, Alert-to-SAR ratios, and the problem of high false positive rates. Let me add to that conversation by throwing out what could be some controversial observations and suggestions …

Current Rules-Based Transaction Monitoring Systems – are they really that inefficient?

For the last few years AML experts have been stating that rules-based or typology-driven transaction monitoring strategies that have been deployed for the last 20 years are not effective, with high false positive rates (95% false positives!) and enormous staffing costs to review and disposition all of the alerts.  Should these statements be challenged? Is it the fact the transaction monitoring strategies are rules-based or typology-driven that drives inefficiencies, or is it the fear of missing something driving the tuning of those strategies? Put another way, if we tuned those strategies so that they only produced SARs that law enforcement was interested in, we wouldn’t have high false positive rates and high staffing costs.  Graham Bailey, Global Head of Financial Crimes Analytics at Wells Fargo, believes it is a combination of basic rules-based strategies coupled with the fear of missing a case. He writes that some banks have created their staffing and cost problems by failing to tune their strategies, and by “throwing orders of magnitude higher resources at their alerting.”  He notes that this has a “double negative impact” because “you then have so many bad alerts in some banks that they then run into investigators’ ‘repetition bias’, where an investigator has had so many bad alerts that they assume the next one is already bad” and they don’t file a SAR. So not only are the SAR/alert rates so low, you run the risk of missing the good cases.

After 20+ years in the AML/CTF field – designing, building, running, tuning, and revising programs in multiple global banks – I am convinced that rules-based interaction monitoring and customer surveillance systems, running against all of the data and information available to a financial institution, managed and tuned by innovative, creative, courageous financial crimes subject matter experts, can result in an effective, efficient, proactive program that both provides timely, actionable intelligence to law enforcement and meets and exceeds all regulatory obligations. Can cloud-based, cross-institutional, machine learning-based technologies assist in those efforts? Yes! If properly deployed and if running against all of the data and information available to a financial institution, managed and tuned by innovative, creative, courageous financial crimes subject matter experts.

For more, see “False Positive Rates”, below …

Alert to SAR Ratios – is that a ratio that we should be focused on?

A recent Mid-Size Bank Coalition of America (MBCA) survey found the average MBCA bank had: 9,648,000 transactions/month being monitored, resulting in 3,908 alerts/month (0.04% of transactions alerted), resulting in 348 cases being opened (8.9% of alerts became a case), resulting in 108 SARs being filed (31% of cases or 2.8% of alerts). Note that the survey didn’t ask whether any of those SARs were of interest or useful to law enforcement. Some of the mega banks indicate that law enforcement shows interest in (through requests for supporting documentation or grand jury subpoenas) 6% – 8% of SARs.

So I argue that the Alert/SAR and even Case/SAR (in the case of Wells, Package/Case and Package/SAR) ratios are all of interest, but tracking to SARs filed is a little bit like a car manufacturer tracking how many cars it builds but not how many cars it sells, or how well those cars perform, how well they last, and how popular they are.  The better measure for AML programs is “SARs purchased”, or SARs that provide value to law enforcement.

How do you determine whether a SAR provides value to Law Enforcement? One way would be to ask Law Enforcement, and hope you get an answer. That could prove to be difficult.  Can you somehow measure Law Enforcement interest in a SAR?  Many banks do that by tracking grand jury subpoenas received to prior SAR suspects, Law Enforcement requests for supporting documentation, and other formal and informal requests for SARs and SAR-related information. As I write above, an Alert-to-SAR rate may not be a good measure of whether an alert is, in fact, “positive”. What may be relevant is an Alert-to-TSV SAR rate (see my previous article for more detail on TSV SARs).  What is a “TSV SAR”? A SAR that has Tactical or Strategic Value to Law Enforcement, where the value is determined by Law Enforcement providing a response or feedback to the filing financial institution within five years of the filing of the SAR that the SAR provided tactical (it led to or supported a particular case) or strategic (it contributed to or confirmed a typology) value. If the filing financial institution does not receive a TSV SAR response or feedback from law enforcement or FinCEN within five years of filing a SAR, it can conclude that the SAR had no tactical or strategic value to law enforcement or FinCEN, and may factor that into decisions whether to change or maintain the underlying alerting methodology. Over time, the financial institution could eliminate those alerts that were not providing timely, actionable intelligence to law enforcement, and when that information is shared across the industry, others could also reduce their false positive rates.

Which leads to …

False Positive Rates – if 95% is bad … what’s good?

There is a lot of lamenting, and a lot of axiomatic statements, about high false positive rates for AML alerts: 95% or even 98% false positive rates.  I’d make three points.

First, vendors selling their latest products, touting machine learning and artificial intelligence as the solution to high false positive rates, are doing what they should be doing: convincing consumers that their current product is out-dated and ill-equipped for its purpose by touting the next, new product. I argue that high false positive rates are not caused by the current rules-based technologies; rather, they’re caused by inexperienced AML enthusiasts or overwhelmed AML experts applying rules that are too simple against data that is mis-labeled, incomplete, or simply wrong, and erring on the side of over-alerting and over-filing for fear of regulatory criticism and sanctions.

If the regulatory problems with AML transaction monitoring were truly technology problems, then the technology providers would be sanctioned by the regulators and prosecutors.  But an AML technology provider has never been publicly sanctioned by regulators or prosecutors … for the simple reason that any issues with AML technology aren’t technology issues: they are operator issues.

Second, are these actually “false” alerts? Rather, they are alerts that, at the present time, based on the information currently available, do not rise to the level of either (i) requiring a complete investigation, or (ii) if completely investigated, do not meet the definition of “suspicious”. Regardless, they are now valuable data points that go back into your monitoring and case systems and are “hibernated” and possibly come back if that account or customer alerts at a later time, or there is another internally- or externally-generated reason to investigate that account or customer.

Third, if 95% or 98% false positive rates are bad … what is good? What should the target rate be? I’ll provide some guidance, taken from a Treasury Office of Inspector General (OIG) Report: OIG-17-055 issued September 18, 2017 titled “FinCEN’s information sharing programs are useful but need FinCEN’s attention.” The OIG looked at 314(a) statistics for three years (fiscal years 2010-2012) and found that there were 711 314(a) requests naming 8,500 subjects of interest sent out by FinCEN to 22,000 financial institutions. Those requests came from 43 Law Enforcement Agencies (LEAs), with 79% of them coming from just six LEAs (DEA, FBI, ICE, IRS-CI, USSS, and US Attorneys’ offices). Those 711 requests resulted in 50,000 “hits” against customer or transaction records by 2,400 financial institutions.

To analogize those 314(a) requests and responses to monitoring alerts, there were 2,400 “alerts” (financial institutions with positive matches) out of 22,000 “transactions” (total financial institutions receiving the 314(a) requests). That is an 11% hit rate or, arguably, a 89% false positive rate. And keep in mind that in order to be included in a 314(a) request, the Law Enforcement Agency must certify to FinCEN that the target “is engaged in, or is reasonably suspected based on credible evidence of engaging in, terrorist activity or money laundering.” So Law Enforcement considered that all 8,500 of the targets in the 711 requests were active terrorists or money launderers, and 11% of the financial institutions positively responded.

With that, one could argue that a “hit rate” of 10% to 15% could be optimal for any reasonably designed, reasonably effective AML monitoring application.

But a better target rate for machine-generated alerts is the rate generated by humans. Bank employees – whether bank tellers, relationship managers, or back-office personnel – all have the regulatory obligation of reporting unusual activity or transactions to the internal bank team that is responsible for managing the AML program and filing SARs. For the twenty plus years I was a BSA Officer or head of investigations at large multi-national US financial institutions, I found that those human-generated referrals resulted in a SAR roughly 40% to 50% of the time.

An alert to SAR ratio goal of machine-based alert generation systems should be to get to the 40% to 50% referral-to-SAR ratio of human-based referral generation programs.