RegTech Manifesto Comments

Photo by Wesley Tingey on Unsplash.

Banking regulation is at a pivot point, ready to jump into the digital age supported by innovation in Regulatory Technology (RegTech) and Supervisory Technology (SupTech). Last month, the Alliance for Innovative Regulation (AIR) published a request for comments on a RegTech Manifesto.

The manifesto is largely about regulators and banks — thinking through the policy and practice of what the world should look like, and how we should get there. My company comes at this as an implementer. We have supported the implementation of new technology for regulators such as FDIC and CFPB. Our perspective is about how to make this successful in the practical and tactical realm of implementation.

I have long felt that financial regulators should invest in hands-on digital innovation labs, and have been struggling how best to articulate how that would benefit government regulators. The manifesto does a better job of this than I could ever dream of doing — connecting broader policy goals and industry trends to the tactical path forward. The manifesto provides the inspiration, the framework, and the vocabulary to get us to concrete progress.

Overall Comment: An Important, Needed, and Well Articulated Vision

The manifesto included pointed questions to spur comment. The remainder includes responses to those questions.

Is there a compelling case for converting the system to digitally-native design? If so, what arguments are the most important? Which are least persuasive?

Key, compelling points of the manifesto include:

• The financial services industry is facing disruptive innovation. Data generated is increasing exponentially.
• If regulators cannot keep up with that pace, they risk a double-downside: stifling innovation and US leadership in the industry; and “accelerating backwards” in their ability to effectively regulate that industry.
• A typical linear cycle of policy analysis, legislation, and technology implementation won’t be effective.
• To shift to digitally-native RegTech, regulators must develop the capacity to rapidly experiment with new approaches in house, in collaboration with industry. Tech and product people must be “in the room where it happens.”

What kinds of entities should lead conversion to a new system and participate in building it? Are there valuable models to emulate regarding design and governance?

On the regulator side, government agencies will have to build up their digital services capacity. They need a cross-functional team with the likes of examiners and analysts, as well as technologists and digital product talent. Regulators should in parallel build up an in-house digital services team led by a qualified CTO and supplement that with consultants bringing similar hands-on technical talent.

What are the most practical strategies for converting to a digitally-native system, starting now and adopting change gradually over time?

A digital services innovation lab team supports a series of small experiments and quick wins is important. This allows the regulators to gain experience with the practical considerations of implementing RegTech as they develop the policies.

Comments by Section

Exploration 1 / The Problem

Is the case for regulatory modernization clear and compelling? If not, what arguments are unpersuasive? Which issues are most salient, and why?

The case is well made in terms of the need to not stifle innovation, and the threat of regulators not being able to keep up. It is generally compelling and well reasoned.

There is some content that veers into buzzwords or “hand wave” rhetoric that seems relatively hollow compared to the rest. Some specifics: any mention of AI, ML, NLP without a concrete example reads a bit like a marketing brochure. These are rather broad fields, and they tend to only make sense in the context of a specific application of those techniques (example: “ML to score loan applications”).

Exploration 2 — Regtech as the Solution

Are the regtech benefits outlined generally clear and persuasive? If not, which ones fall short?

The general case is very persuasive. For example, a digital structure for loan data (pg. 31) could indeed have greatly helped/avoided the 2008 crash.

Non-financial analogies, such as the photography example (pg. 30), can help. However, bank/FinTech use cases may be more direct and explanatory.

A few phrases seem to be “hand waving” explanations. This includes the last paragraph in page 30, which throws out AI/ML/NLP buzzwords without a concept of how, thus reading more like a sales brochure. Similarly on page 34, “use AI to detect patterns of emerging risk or biased decision making or misconduct”. Another example on page 40, “A modernized system could potentially reverse that ratio, reducing wasted time by 90 percent…” If we use numbers on outcomes, it’s more compelling to use those from real results of an experiment vs. hypothetical results.

The Modularity section is interesting and generally compelling — the idea of incremental changes and thinking in terms of discrete components. The ideas of a platform or the app store comparison seem a little off, or at least unexplained. The idea of a formal platform could be tricky and require lots of (slow) consensus on standards, etc. It’s tricky, and possibly a quagmire.

Are any major benefits omitted from the list?

The efficiency argument for examination or investigation functions could be brought out more. Agencies like FDIC maintain many field offices, and staff travel extensively. That is expensive and time-consuming. There would be real benefits of digital examination in terms of less wasted time and effort (and effectiveness) when examination activities are largely untethered from physical visits.

Do you know of research and data to amplify this outline of potential benefits, or that may counter it?

The point on the as-is mentality problem (pg. 26) is something we can 100% validate from “the ground”. The below quote certainly describes how many regulators approach “modernization” viewed only through the system/technology lens, and not the wider business/product lens.

…even if analog systems have been automated, they function with workflows that were originally designed on paper, decades or centuries ago, and that still bear the fundamental design of how information was transmitted in the past.

Exploration 3: Challenges in Designing a Regtech System

What should be the scope of financial regulatory standards? What is most needed? What existing standards are relevant and what are their scopes and strengths and weaknesses?

The key challenge is to design around the correct levers. Bank call report data is about wanting the same set of answers each time. If we simply reform that from pulling that same data on-demand vs. quarterly, it is hardly an innovation. However, the regulatory community will need to determine what type of queries must be supported by banks on what data elements. Example: must be able to query loan applications by amount, borrower zip code, borrower race/ethnicity, etc.

What are the main gaps or failures of existing standards with regard to efforts to build an interoperable system?

The security and authentication model for how banks and regulators connect to one another is “in the weeds” but quite important to sort out. There are well-established methods for secure data exchange, but it takes time to get an entire industry on board. Current means of sharing data are rather dated in technical design.

What are the key design challenges in addressing privacy and security issues?

This is certainly the crux of the issue beyond the basic technical implementation. Regulations and policy will have to address the rights of regulators to query data in aggregate, the rights to view record details or samples thereof, etc. This requires its own line of exploration and experimentation. For example, we’ve helped CFPB implement a privacy model to ensure that aggregated query results stay at an appropriate level of detail to protect anonymity.

What are the key obstacles to and risks of conversion to cloud computing, for both regulators and industry?

We’ve built some of the first cloud apps for regulators so are intimately familiar with this issue. Internal governance policy tends to get in the way — partially for valid reasons. The greatest barrier is simply organization structure and empowerment. Doing the work under the correct structure of executive support makes this fairly simple (more on that in other comments).

What should the roadmap be to build out this system over time?

As laid out elsewhere, hands-on technical innovation labs within regulators is a great place to start. Specifically, they can develop prototypes in-house and pilots with industry to inform policy.

Do you know of research and data to amplify this outline of potential benefits, or that may counter it?

I’ve personally been part of modernizing FDIC’s external data sharing to modern APIs. My company has similarly supported CFPB, USPTO, and SBA in modern data sharing and regulatory analysis applications. Regulators can implement modern cloud-based open source solutions.

Other comments:

The platform and interoperability language (pg. 46) seems less concrete than some other areas of the manifesto. The idea of platforms is interesting, but add to (at least my) confusion when reading it. Some of the language seems to veer into tech marketing speak:

A digitally-native regtech system would have to shift regulatory and compliance work from vertical technology stacks to horizontal platforms that enable interoperable and modular solutions.

Exploration 4: Principles and Attributes of a Regtech System

Are these principles and attributes clear? Are they valid and important to regtech design? Are some principles and attributes missing?

The need for labs and experimentation is spot-on and important. Regulators need that capability as much as policy analysis, and few have that capability today.

Blockchain is such a well-hyped term, that I’d recommend being extra clear. The usage on pg. 62 seems quite appropriate, but emphasis that the use cases are narrow, for things like AML with respect to cryptocurrency, may help government agencies from dumping money and effort into ill-conceived pilot projects.

Are the technology concepts covered described correctly? Can we improve how we explain them?

Some things come through well, like the summary of and emphasis on agile and design thinking approaches.

There are certainly some opportunities to speak more clearly about tech concepts.

• Use of the term ‘robotics’ is a little confusing. The industry definition is vague, and something less catchy like ‘automation of existing processes’ (perhaps something better than that) may be more correct and straightforward.
• Some of the language in the “AI” areas gets a little buzzword-heavy (example: bottom of pg. 54). There is great promise there, but AI/ML/NLP are such vague terms with so much tech marketing diluting them, they can lose resonance. The specific examples read better to me.
• Unclear why “open source” is in quotation marks at bottom of pg. 55.
• On page 56, suggest replacing:
  “They get basic tools from a well-vetted code repository like GitHub.”
  with:
  “They build tools from well-vetted open source libraries whose code is managed in public repositories like GitHub.”
  The edit may not be perfect, but the individual code libraries used are well-vetted or not. GitHub is a well-known host of public repositories, but houses horrible code as well as great code. There’s lots more technical weeds there. Companies don’t technically get the code from GitHub, but package management sites.
• Similarly, the phrasing “create the regulator version of GitHub, or sections in GitHub” comes off a bit awkward. “Presence in GitHub” could get to it. GitHub doesn’t have sections, it has organizations (like FINOS). The basic sentiment is great.
• Suggest replacing “open code” with “open source code” on pg. 56.
• The internet doesn’t really have source code, but standards/specs. “The internet’s open source code is maintained…” might be “The internet’s open standards and specifications are maintained…” (pg. 57)
• Not sure if “New methods of encryption will likely be needed…” holds true. Encryption technology exists. “Robust security, authentication, and privacy protection methods will be needed…” might be more accurate. This is not an area where entirely new technology needs to be invented, but that best practices need to be applied (pg. 58).

Do you have ideas on how to realize these concepts in a regulatory environment? For example, how can a regulatory system be converted to genuinely digitally-native design, while it is still operating in its traditional form?

In terms of adopting regulation, the path laid out in the manifesto makes sense: a parallel opt-in track. It may also be reasonable to mandate a timeline for larger“too big to fail” institutions. These large banks represent a great deal of the overall industry risk, and also have the resources to absorb regulatory burden.

Exploration 5: Strategies for Converting to Digitally-Native

What are the greatest barriers to practical implementation of a regtech system?

As well articulated in the manifesto, the culture and capability of most regulators and banks is lacking in digital product innovation. In other words, the capability to apply both a “from scratch” mindset and apply digital product development skills. Regulators must create a risk taking framework that doesn’t jeopardize their mission, but does allow them to experiment quickly.

What are the best ways to overcome these obstacles?
Of the strategies outlined in this section, are some particularly promising? Are some especially problematic? How could they be improved?

The “room where it happens” theme is 100% on-point. I would like to concentrate on the internal capability that regulators need to build, in terms of a digital services innovation lab. The manifesto does a great job of articulating why this is so important, and (in my opinion) can’t emphasize this enough. Such a lab is the key to success. There are ways this can go wrong or be ineffective. But, government regulatory agencies can and must build a true digital services capability (see below).

Digital services, in the broader government context, refers to a shift in how government services are delivered. Traditional services are a combination of people, paper and process to deliver a service. Modern digital government services are more akin to digital products. This concept is far different from IT modernization. Government regulators are very comfortable replacing older generations of technology with newer ones to do similar things. The digital services evolution is more in line with the recommendation of this manifesto — effecting innovation on how the mission is supported by way of digital products.

The good news is that this isn’t entirely new to government. Many government agencies have digital services teams within them aligned to the US Digital Service (USDS). Federal regulators can follow this pattern to bring in technical talent, which can be supplemented by private sector consultants to add capacity.

Does the section omit promising, practical strategies?

In addition to the strategies above to get talent in the door, there are other tools for government. Digital services teams typically use term hiring authority to recruit and hire more on pace with commercial industry. The Presidential Innovation Fellows program could be another talent avenue. Another is engaging 18F (‘in house’ consultancy of government employees).

There are some things that may be slightly off. For example, the Getting Started section (pg. 65) has great notes on team composition. However, I would de-emphasize “IT leaders.” Regulators tend to have IT organizations led by a CIO, and they are focused on a narrower lens of internal technology and information management, and don’t necessarily bring digital product management skills (with some exceptions). Such product innovation would be led by something like a CTO-led product organization.

Diversity is critically important in the team. I would suggest less focus in the language on “millennials” and more focus on diverse perspectives including generational. Examples: people who come from”unbanked” or “under-banked” communities would add great perspective, as do people with modern open source software development or commercial product management or data science.

Additional minor comments:

• “Robotics and AI…” on pg. 72 seems awkward, particularly “robotics”. “Automation and AI…” may read a little better to a tech audience.
• Playfully following on to the “millennials” comment above, Wired and Fast Company aren’t bad sources, but do hail from the 1990’s era. They are perhaps what boomers view as cutting edge sources.
• The usage of “tech sprint” seems off to me, starting on page 76. “A tech sprint is essentially a hackathon.” A hackathon or contest could be less confusing language. There are important techniques, such as design sprints, that could be applied but are far different from hackathon contests. As an additional comment, hackathons tend to be exciting, but often overhyped. They can inspire ideas but not provide the capability nor capacity needed by regulators.
• The “other experimentation strategies” on page 78 is interesting, but possibly confusing. Yes, they might be able to learn from those examples, but I’m not sure it helps the message of the manifesto.

Potential Roadmaps Section

There is some good material here. Some comments to help improve it:

• Echo comment above on millennials. (pg. 93)
• “Accelerate the transition to cloud computing” is actually not that important. Most regulators have the ability to host software in the cloud. I don’t think that the vast realm of internal IT moving to the cloud, even though a good thing, will help RegTech adoption. (pg. 93)
• The “moonshot” approach is valid, so long as driven through a product innovation lab path. Regulators are too tempted to create a perfect solution in one “big bang”, which won’t likely be successful. (pg. 95)

Originally published at https://pov.stsiinc.com on August 23, 2020.