_Regulators have become especially worried about third-party risk, i.e., the risk that activity performed for the bank or in the bank’s name by a supplier or other business partner will lead to operational or compliance failures on the part of the bank.

• In 2023, the US Federal Reserve, the Federal Deposit Insurance Corporation (FDIC), and the OCC issued interagency guidance on third-party risk management (TPRM), harmonizing pre-existing material across the agencies and emphasizing the applicability of the guidance beyond suppliers to all business partnerships, notably including fintechs.³‍
• Multiple recent regulatory enforcement actions have targeted banks, particularly small community banks, for failures to properly manage fintech partnerships. Thematic criticisms include⁴  inadequate know-your-customer controls for customers onboarded to the bank through fintechs and misleading claims regarding the applicability of FDIC insurance coverage for fintech customer deposits and/or failure to properly keep supporting records.
• Regulators outside the US share these concerns. The new EU Digital Operational Resiliency Act (DORA) requires that contracts for tech services explicitly address “at least” a substantial list of mandatory topics. While the US regulators identify a similar list, the US material is guidance and DORA is black letter regulation. DORA also includes a process for designating “critical” suppliers to the industry, requires critical suppliers to maintain an EU footprint, and mandates that banks exit relationships with critical suppliers who cannot or will not comply.

Regulatory concern extends across ORM with continued focus on cyber risk, resiliency, data governance, model risk, compliance, material errors, and financial crime. OCC Acting Chairman Hsu, for example, has spoken in recent months on operational resiliency and AI. Further, the OCC’s semiannual risk perspective notes operational risk as elevated for the industry and adds the potential for disruption related to product innovation, including crypto, to its list of traditional concerns.⁵

In the following sections, we will offer:

• Practical, cost-effective suggestions for third-party management that complement formal regulatory guidance.
• Opportunities to enhance the back-office control environment through automation and the strategic application of generative AI.

Shifting the Mindset on Third-Party Risk Management

The evolving third-party risk landscape

Technology is changing the level and nature of third-party risk management, especially for larger banks with significant in-house IT. Historically, banks primarily managed tech-related risk within their own data centers, protected from intruders by the bank’s cybersecurity team with other risks IT largely managed by internal IT. At many banks, legacy lending, deposit, and other core systems were somewhat of an exception, often outsourced to bank specialist providers, e.g., Fiserv, FIS, or Jack Henry. While not banks themselves, these firms have deep roots in bank processing and are overseen by the banking regulators. However, the increasing reliance on cloud-based services has introduced new complexities:

• Today, increasing percentages of bank workloads run on cloud or in “hybrid cloud” environments linking older, in-house bank systems with newer, cloud-based applications.
• Cloud service providers (CSPs) offer strong security, recovery, and resiliency capabilities, but they do not attempt to understand bank workloads and their specific risks, requiring the bank to choose the best options and integrate these with in-house and other cloud providers.
• Efficiency requires extra copies of data across hybrid cloud networks, increasing the cyberattack surface.
• The tech industry’s “winner-take-most” dynamics create concentration risks for cloud users, especially across the three major providers — AWS, Google Cloud Processing, and Microsoft Azure — a problem for which there are no easy answers today.⁶ The CloudStrike outage represents concentration risk related to CloudStrike’s widely used software and likely amplified by its use within Azure’s Microsoft 365 cloud suite. (To be fair, Microsoft’s scale may have also accelerated the fix for banks using its cloud.)
• Cloud concentration can increase cybersecurity risk, despite extensive CSP investments in cyber defense. CSPs have become extraordinarily high-value targets for hackers due to their massive scale, making them subject to very sophisticated attacks by hostile nation-states.⁷

Fintech partnerships further complicate the risk landscape. These partnerships, where applicable, can introduce new exposures if not managed carefully, especially if the partnership is between a tech startup with little understanding of bank compliance requirements and a bank lacking strong IT and TPRM skills.

Adapting to the new third-party risk environment

Despite the evolving risk landscape, many institutions have yet to adapt their thinking, ORM target operating model, or staffing accordingly. Initial steps require assessing the applicability of these trends to the bank’s specific circumstances and then realigning related priorities. While each institution is unique, three core actions can be applied broadly:

1. Update the bank’s third-party risk profile. If the bank’s tech or operational risk has shifted substantially into third-party relationships, but the organizational focus has not adjusted, the bank may be fighting the last war. Consider these questions and actions:
   • To what extent have the bank’s cyber, technology, business continuity, data governance, or general tech risk become third-party risk?
   • Have risk governance, oversight structures, leadership skills, resource allocations, controls, or board reporting been adjusted proportionately?
   • Develop and implement action plans addressing gaps shown by the review.
2. Review ownership responsibilities for IT suppliers. Commonly, lines of business execs “own” relationships with bank core processors and with software-as-a-service (SaaS) cloud providers, i.e., cloud providers who deliver a business application, such as Salesforce, ServiceNow, or Oracle Cloud Financials. Too often, line of business executives and teams lack needed IT risk knowledge, but IT is not involved in ongoing oversight, leaving tech risk uncovered. We see breaches where this is the clear root cause. Consider these actions:
   • Examine tech suppliers owned outside of IT and ensure appropriately-skilled oversight for the full range of applicable risks.
   • For all SaaS providers, specifically identify the availability and bank usage of companion software development tools. Identify any related violations of shadow IT policies, i.e., IT developed without proper IT supervision or standard IT controls.
   • Develop and implement action plans to close identified gaps.
3. Elevate and/or integrate third-party oversight with companion IT and ORM functions. We often observe IT and ORM teams in both the first- and second lines of defense to be focused almost exclusively on internal activity. Especially after initial due diligence is completed and the contract is signed, third-party risk monitoring may be happening but is often obscured within ongoing monitoring of contract service level agreements, staffed as a part-time role, and given limited executive focus. Cyber breaches or major incidents change the picture briefly, then things return to business as usual.
   • Review the stature of TPRM leadership and activity. Are talent and skill levels commensurate with the true level of risk? Is executive attention adequate and effective. For example, if audit or regulatory issues involve third parties, can the bank exert appropriate leverage to obtain timely remediation?  
   • Increase coordination or integration of third-party risk with companion internal functions, e.g., cyber, IT change, and compliance. For key cyber or compliance risks, do functional leaders have comparable line of sight to key third party and internal performance?
   • Develop and implement action plans to address identified gaps.

Operational Risk Management at the Speed of Operations

The manual control problem

For large banks, the only practical route to long-term reduction, or even containment, of operational risk is through substantially improved automation of the control infrastructure. The role of bank operations is to service whatever business the bank does, so reducing inherent operational risk is only possible by exiting customer segments, channels, or products, strategies that few institutions willingly consider. As a result, ORM becomes almost entirely a game of managing controls to reduce the consequences of a given set of risks.

Control structures today are not automated enough to keep up with an increasingly real-time world. Major components of cybersecurity, anti-fraud, and AML are heavily automated, but these are specialized functions. The bulk of bank operations are dedicated to product fulfillment, which relies on a mix of systems incorporating some automated controls supplemented by a welter of manual and hybrid controls based on spreadsheets and other desktop tools. Channel and product automation continuously accelerates the pace of execution, reducing the available time to detect and react to threat events or errors. As just one example, consider the shift in consumer payments to real-time mechanisms like Venmo and Zelle.

Information on control failures often becomes available long after the fact through customer disputes, compliance tests, audit findings, or regulatory criticisms. Even worse, evidence of this nature is incident- or sample-based, so finding all the instances of a flawed control requires a “lookback” project to reexamine a large number of transactions. Fully correcting a problem that involves customer restitution can take years. Little wonder that the OCC rates ORM below satisfactory at many banks.

Advocacy for comprehensive control automation is not controversial but execution has proven hard to accomplish. New or upgraded products are often produced under time pressure, and it is quicker and cheaper to tweak manual processes, especially when volumes are low, than to delay launch. Once a product is live, control automation, no matter how well-justified, takes a back seat to the next round of improved features.

Further, many banks struggle to know definitively what their controls even are, a prerequisite to better automation. Controls, i.e., discrete actions to prevent, detect, or correct problems, are rarely labeled as such within code or written procedures. Control libraries, a common form of control documentation in governance, risk, and compliance systems, are manually built and maintained, often incomplete, and inevitably out of date. Like other documentation, they are descriptive, not executable, and they are not connected to live data. They are mainly helpful as input to assurance professionals.

How AI can be the difference maker

ORM needs to happen at the speed of operations. Banks need ways to detect actual or potential control failures close enough to the transaction event so they can prevent or significantly limit adverse consequences.

Banks are making progress on control automation today, in many cases using a newer class of back-office tools known as no-code/low-code workflow or process mining. Banks are making progress but clearly not fast enough to satisfy their regulators. Our conclusion, from observation of prototyping and early-stage pilots, is that generative AI, even at its current state of maturity, can be a significant difference-maker in addressing two critical sticking points many organizations struggle with:

• Control Discovery. How do we identify our inventory of key controls at the operational level, i.e. concrete control actions within specific processes or systems?
• Control Monitoring. How do we identify threat events, errors, or other control exceptions in time to act?

The figure below illustrates the key concept in simplified form with the generative AI contribution shown in teal. Generative-AI-enabled bots, which can read documents and/or code, are used to identify both manual and automated controls. Bots are also used to generate and run test scripts against data in production or desktop systems to identify actual or threatened control violations.

Generative AI technology adds important new capabilities that significantly ease the problems associated with conventional technology solutions.

• Large language models (LLMs) can “understand” documents, code, and data, making it much easier to discover a complete and precise picture of how a business process is controlled.  
• Prompt engineering, essentially telling an LLM what to look for or do, is utilized by control professionals to guide the control discovery and the control test scripting processes in plain English and with a considerable increase in productivity. Our experience is that careful prompt engineering is essential to success.
• Repeatability of testing. When directed to perform a test, LLMs generate and then execute code to do this. The code can be saved and reused without going through the prompting process again. Control test automation is the key building block for automation.
• Pathway from control testing to continuous monitoring. After using AI to discover the full control map and automate testing, the resulting test code can be migrated from periodic second- or third-line assurance functions into first-line monitoring or direct transaction inspection, and statistical sampling can be replaced by 100-percent quality control. Back-office tool purveyors including Microsoft, Salesforce, IBM, and Celonis, are rapidly incorporating generative AI in various ways that will facilitate this.

All large banks have back-office control issues, and all banks have some form of generative AI pilot program. Our recommended strategy is to incorporate generative AI pilots into existing audit or regulatory remediation work plans. Applying generative AI can enhance existing problem-solving efforts and build skills and assets applicable to a wide range of similar problems.

Conclusion

The industry has a lot of work to do on ORM. While every large bank has its own unique challenges and opportunities, we see the shift of technology risk from in-house to third parties and the need for more and better control automation that keeps pace with accelerated transactions cycles as universally applicable themes.

To improve third-party risk management, the first and most important step is recognition of cloud migration’s impact on a bank’s risk profile as the prelude to refocusing attention, resources, and skills. In concert, banks should leverage cloud’s capability to improve resilience.

For control automation, banks that aggressively pilot generative AI now will be best positioned to exploit the tech industry’s massive and ongoing capital investments for faster, better, and less costly operational risk management.