The Risk Assessment Built for the Last Exam

At a Glance

• Legacy RCSA programs assessed risk by business unit, in silos, with no line of sight across connected processes
• Moving to an end-to-end view closes the ownership gaps that silo-based assessments consistently miss
• Non-core processes need to be included in your RCSA continuously, not just on a fixed cyclel
• The RACI model clarifies who owns a risk versus who runs the process where it shows up
• RCSA is a journey, not a destination. The institutions that treat it that way are the ones better positioned for what comes next

Your risk assessment program was probably built around the systems that process transactions. The ledger. Payments. Core banking operations. That made sense at the time. But the processes your customers move through today, account opening, underwriting, complaint handling, cross multiple business units and third-party relationships. When each unit assesses its own slice in isolation, no one owns the seams between them. That is where the risk lives.

That gap is what a session at the ABA Risk and Compliance Conference in Charlotte addressed directly. Presenters from TD Bank and First Carolina Bank, including Daniel Birbal, Charles Corbezzolo, and Bill Tucker, did not frame it as a future concern. They described what their own institutions found when they looked closely at what their RCSA programs were actually covering. And what they were not.

The session was titled “Updating Risk Assessments in the Current Environment: Modernizing RCSA—Turning Risk Assessments into Actionable Intelligence.” The real question underneath it was simpler: does your assessment reflect the bank you actually run?

The silo problem: when no one sees the whole picture

In older RCSA models, business units assessed risk independently. Digital ran its assessment. Retail ran its own. Each unit looked inward at its own processes, and the results sat in separate documents with no reconciliation between them.

The problem is that your customers do not experience your bank in silos. A single account opening touches digital onboarding, identity verification, underwriting, and fulfillment. Each of those may sit in a different business unit. Each unit may assume the adjacent team is handling the shared risk. Often, no one is.

Moving to an end-to-end view changes that. When account opening, underwriting, and fulfillment are assessed together under one scope, shared risks become visible. Consistent controls can be applied across channels. The gaps that fall between units stop falling through.

Ownership gaps are the risk the assessment was not finding

One of the sharper observations from the session was about accountability. In a silo-based model, ownership of a risk depends on where the process sits. But risk does not respect org charts.

The presenters described using the RACI model to address this directly. RACI stands for Responsible, Accountable, Consulted, and Informed. It is a framework for clarifying who owns a decision or outcome versus who executes the work where it shows up. In the context of RCSA, that distinction matters significantly.

In some institutions, product leaders now own the risk tied to their product, regardless of which operational team runs the process where the risk materializes. A deposits leader owns the risk associated with account opening, even if the fraud team, the digital team, and a third-party provider all touch that process. That accountability structure eliminates the assumption that someone upstream or downstream is covering a shared exposure.

Non-core processes need to be in scope, and they need to stay there

The scope problem is not only about what you assess. It is about when and how often.

Legacy programs assessed core processes on a fixed cycle, often every two years for high-risk areas. Non-core processes, including third-party tools, newer digital channels, and AI-assisted workflows, were either excluded entirely or reviewed only when someone thought to add them.

The session was clear on this point. Non-core processes need to enter the RCSA as they are added, changed, or developed, not on a fixed schedule that has no relationship to when the risk actually changes. A new analytics tool integrated mid-year carries risk from the day it goes live. Waiting for the next review cycle to assess it is not a governance posture. It is a gap.

When the assessment adapts to the pace of change in the business, including the deployment of new technology, new third-party relationships, and new AI tools, it produces intelligence. When it runs on a fixed calendar regardless of what has changed, it produces paperwork.

Turning the art of risk assessment into science

A consistent theme across the session was the need to make RCSA outputs more defensible. Not just documented, but quantifiable.

The presenters described a shift from qualitative assessments, where risk ratings depend heavily on the judgment of the assessor, to quantitative ones, where numeric values and calculations back up the rating. That shift matters for two reasons.

First, it makes the assessment more consistent across teams and cycles. When a risk rating depends on a formula rather than an individual’s interpretation, the results are comparable over time and across business lines.

Second, it makes the program more defensible to examiners. A risk rating backed by a calculation is easier to explain and harder to challenge than one backed by professional judgment alone. The goal, as the presenters framed it, is to turn the art of risk assessment into science.

What this means for your program

Examiners are no longer asking only what happened after an incident. They are asking whether your institution had documented awareness of its risk landscape before anything went wrong, and whether your governance around non-core and third-party processes is as deliberate as your governance around core systems.

An RCSA that covers only core processes, runs on a biennial cycle, and measures risk at the portfolio level cannot answer those questions. It can describe the past. It cannot show you were looking in the right places. The institutions that ran this transformation found more risk than they anticipated. They also walked into their next examination with documented answers ready. That starts with a question the session kept returning to: who owns this? For non-core systems, the answer is rarely as clear as it needs to be. When a customer portal or a third-party integration runs on shared infrastructure, ownership splits across teams and providers, and no one can explain it cleanly under scrutiny. Non-core systems hosted on dedicated, isolated infrastructure, where responsibility is explicitly defined at every layer, are systems your team can actually stand behind.

That is what a defensible RCSA requires. RCSA is a journey, not a destination. If yours is still running the way it was five years ago, that journey is overdue.

Kelly Goolsby attended “Updating Risk Assessments in the Current Environment: Modernizing RCSA — Turning Risk Assessments into Actionable Intelligence” (Session 1D) at the ABA Risk and Compliance Conference, Charlotte, NC, May 5–7, 2026. Presenters: Daniel Birbal, Risk and Controls Leader, TD Bank; Charles Corbezzolo, SVP, Consumer Business Controls, TD Bank; Bill Tucker, Chief Compliance Officer, First Carolina Bank.