RCSA for Fintechs: How to Build a Risk and Control Self-Assessment That Actually Holds Up in an Exam

TL;DR

• The OCC found that more than half of large banks had weaknesses in their operational risk and control frameworks in 2024 — and outstanding operational risk findings are rising across institutions of all sizes
• An RCSA is not a checkbox: examiners are evaluating whether your controls actually work, not just whether you’ve listed them
• The four most common RCSA failures: scoring only residual risk, no control testing evidence, scope gaps that miss new products and vendors, and self-assessments without second-line challenge
• Since early 2026, OCC examiners no longer follow a fixed checklist — they follow the risk wherever it lives in your institution, including non-core systems and fintech partnerships

Most compliance teams understand the point of an RCSA in theory. In practice, the program ends up as an annual spreadsheet exercise where the first line rates their own controls effective, nothing gets tested, and the result says everything is fine until it isn’t.

That’s not what examiners are looking for. The OCC’s own findings make clear that the bar has risen: in 2024, more than half of large U.S. banks showed weaknesses in their operational risk and control frameworks. Operational risk findings — spanning governance, internal controls, IT and cybersecurity, and third-party relationships — are consistently among the most cited supervisory issues. That number should matter to community banks and fintechs too, because what examiners cite at large banks this year becomes examination guidance at smaller institutions within two or three cycles.

What an RCSA Actually Is

An RCSA is a structured methodology for evaluating whether the controls that are supposed to manage your operational risks are actually doing that work. It operates at the process level — not the enterprise level — and it produces a defensible, documented assessment of both inherent risk (before controls are considered) and residual risk (after controls are applied).

The core sequence:

1. Process identification. Map the processes you’re assessing — core business operations, product delivery, support functions, third-party dependent workflows.

2. Risk identification. For each process, identify what can go wrong: people errors, system failures, process breakdowns, fraud, regulatory non-compliance, third-party failures.

3. Inherent risk assessment. Rate the likelihood and impact of each risk before any controls are applied. This is the baseline — it answers “how bad would this be if we had no controls?”

4. Control identification. Document every control designed to mitigate each identified risk. Be specific: preventive controls, detective controls, corrective controls. Document who owns each control and how often it operates.

5. Control effectiveness testing. Actually test whether each control is working. Not asserting — testing. This means reviewing evidence: logs, reports, approval workflows, reconciliation records, exception reports. A control rated as effective without supporting evidence is an attestation, not an assessment.

6. Residual risk rating. Score the remaining risk after controls are factored in. The delta between inherent and residual should justify your control investment. If controls are rated effective but the residual risk is still high, you have a control gap that needs remediation.

7. Issues and remediation. Control gaps identified through RCSA should flow into your issues management system with owners, due dates, and remediation plans. This is how the RCSA connects to your program governance rather than sitting as a standalone document.

The Inherent vs. Residual Problem

The Basel Committee’s operational risk standards require banks to assess both inherent and residual risk. Many RCSAs skip inherent risk entirely — they go straight to residual, which makes the assessment meaningless for examining whether controls are doing anything.

If your RCSA says “fraud risk: residual = Low” but doesn’t document the inherent risk and the controls that reduced it to Low, an examiner cannot assess whether that rating is credible. More importantly, you can’t tell from year to year whether a residual risk is staying Low because your controls are working or because you’ve been lucky.

The Regulatory Expectation in 2026

The OCC’s FY2025 Bank Supervision Operating Plan organized supervisory priorities into three categories: financial risk, operational risk, and compliance risk. Operational risk — including governance, internal controls, IT and cybersecurity, and third-party relationships — is specifically called out as an area where outstanding supervisory findings are increasing.

In early 2026, the OCC updated its examination approach: examiners no longer follow a fixed checklist. They follow the risk wherever it lives in the institution. For fintechs and community banks, this means the examination scope is no longer bounded by what examiners have historically reviewed — it extends to non-core systems, new product lines, vendor-dependent processes, and fintech partnership activities.

The ABA’s 2026 Risk and Compliance Conference included a session specifically on “Modernizing RCSA — Turning Risk Assessments into Actionable Intelligence,” with a focus on expanding RCSA scope to include non-core processes and integrating continuous monitoring. The industry message is consistent with what examiners are seeing: traditional annual RCSA programs that treat scope as fixed are leaving risk blind spots that examiners will find.

The FDIC Risk Management Manual of Examination Policies, last updated March 2026, similarly reflects the expectation that institutions maintain continuous visibility into their operational risk environment — not a point-in-time annual snapshot.

The Seven RCSA Gaps Examiners Find at Fintechs

1. Scope That Doesn’t Follow the Risk

Most fintechs start with a scope that covers their core processes and leave it there. The problem: risk at fintechs concentrates in exactly the places traditional RCSA programs miss — new products, partnership-dependent services, vendor-reliant workflows, and rapid technology changes.

If your fintech launched a new payments feature in Q1, partnered with a new bank sponsor in Q3, and migrated to a new cloud provider mid-year, your RCSA scope should have expanded to cover those changes. An RCSA that looks identical year-over-year for an institution that changed significantly is a scope failure.

2. Control Testing That Isn’t Testing

Asserting that a control is “effective” without evidence is the most common and consequential RCSA failure. A control that hasn’t been tested is a hypothesis about risk management, not a fact.

Control testing requires evidence. For a transaction monitoring control: pull a sample of alerts and verify they were reviewed within the required timeframe, escalated appropriately, and that any false positives were dispositioned with documentation. For a dual-approval control on wire transfers: pull a sample of transactions and verify both approvals were obtained and logged. For a change management control: review the change request log and verify the approval workflow was completed before deployment.

The RMA’s 2024 guidance on refining RCSA programs specifically emphasizes the shift toward evidence-based control assessment — moving from attestation to validation. Institutions that continue treating control effectiveness as a judgment call without documentation are accumulating exam findings.

3. No Inherent Risk Score

If your RCSA rates residual risk without documenting inherent risk, you cannot demonstrate that your controls are reducing risk to an acceptable level. You’re just asserting an outcome.

Inherent risk rating involves: identifying the risk event, assessing the likelihood it would occur absent controls, and assessing the impact if it did occur. The inherent risk score × the control effectiveness score = the residual risk. That math is what makes the RCSA defensible — it shows the examiner exactly where your controls are doing work and exactly where you have residual exposure that you’ve either accepted or need to remediate.

4. Annual Cadence Without Event-Triggered Updates

Annual RCSA cycles work for stable, slow-changing programs. Fintechs don’t have stable, slow-changing programs. The expectation from regulators is that RCSA scope and assessments are updated when material changes occur — not held until the next annual cycle.

Material changes that should trigger an RCSA update:

• New product launches or material modifications to existing products
• New third-party relationships or material vendor changes
• Significant system migrations or technology changes
• New regulatory requirements affecting core processes
• Internal audit or exam findings identifying control gaps
• Significant headcount changes in key risk and control roles

The trigger-based update requirement is part of what makes RCSA continuous rather than periodic. Building those triggers into your new product approval process, vendor onboarding workflow, and change management procedures is how you operationalize it.

5. First-Line Self-Assessment Without Challenge

An RCSA where the first line rates its own controls effective, with no second-line challenge or independent validation, is not an RCSA — it is a self-attestation exercise. The value of the RCSA comes from independent evaluation of whether the first line’s assessment is credible.

The three-lines-of-defense model requires:

• First line: performs the RCSA, documents controls, rates effectiveness
• Second line (risk management): challenges the RCSA, validates ratings, identifies scope gaps, tracks issues
• Third line (internal audit): independently validates the RCSA process and control testing

Fintechs with small compliance teams often have the first line completing RCSAs with nominal second-line review that accepts all ratings without challenge. Examiners evaluate whether the second-line function is actually providing independent oversight — not just rubber-stamping the business line’s self-assessment.

6. RCSA Disconnected from Issues Management

Control gaps identified in the RCSA should generate issues in your issues management system. Issues should have owners, remediation plans, and due dates. RCSA findings that don’t flow into tracked remediation become dead letters — the RCSA identified the problem, but nothing was done about it.

When an examiner asks about a control weakness identified in your RCSA, the follow-up question is: “Where’s the issue tracking that shows what you did about it?” If the RCSA gap isn’t in your issues register, the program isn’t functioning as an integrated governance mechanism.

7. AI and Model Risk Left Out of Scope

The OCC updated its model risk management guidance in April 2026, extending formal governance requirements to AI tools — including vendor-supplied AI. Examiners are now asking whether AI and model-dependent processes are represented in the RCSA.

For most fintechs, this means: the credit decisioning algorithm, the fraud detection model, the customer service chatbot, the AML transaction monitoring system, and any vendor AI tools embedded in core processes need to appear in the RCSA scope with controls around model validation, bias monitoring, explainability, and ongoing performance review. An RCSA that was complete two years ago may have a material scope gap today.

Building an RCSA That Holds

The institutions that produce defensible RCSAs share a few characteristics:

Scope is dynamic. It’s updated when the risk environment changes, not held to the prior year’s template.

Inherent and residual risk are both rated. The math is transparent and shows controls doing work.

Control testing produces evidence. Each control rated effective has a corresponding test with documented results and a sample.

Second-line challenge is real. Risk management reviews ratings, questions outliers, and escalates disagreements.

Findings flow to issues management. Every RCSA gap has a tracking entry with an owner and a due date.

Scope explicitly covers vendor-dependent processes, new products, and AI. Examiners will look there.

For a pre-built RCSA template covering these elements — including inherent and residual risk scoring matrices, control testing documentation, and second-line challenge workflow — see the RCSA Template & Guide.

So What?

If your current RCSA program only covers the obvious processes, asserts controls as effective without testing evidence, and hasn’t been updated since your last product launch — start with the scope and testing gaps.

Audit your scope today. Pull last year’s RCSA and compare the processes covered to everything your institution launched, changed, or partnered on in the past twelve months. The delta is your scope gap.

Pull one control and test it. For the highest-rated control in your highest-inherent-risk process, ask: what evidence supports this effectiveness rating? If you can’t produce sample-based testing results, you have a testing gap.

Check the inherent risk column. If your RCSA has no inherent risk ratings — just residual — schedule time to add them. Start with your three highest-risk processes. The methodology isn’t complex; the work is in applying it.

Connect to issues management. Review the last three RCSA cycles. Identify any control gaps that were noted. Verify each has a corresponding issue in your issues tracker. Close the loop if they don’t.

For the full exam prep playbook including how OCC and FDIC examiners approach operational risk reviews, see Regulatory Exam Preparation Playbook: OCC, FDIC, and CFPB. For the KRI metrics your RCSA should be feeding, see Exam Readiness KRIs: Evidence Gaps, Repeat Requests, and Aging Findings. For how the OCC’s April 2026 model risk guidance changes what belongs in your RCSA scope, see OCC Bulletin 2026-13: What Changed from SR 11-7.

Sources: OCC FY2025 Bank Supervision Operating Plan · FDIC Risk Management Manual of Examination Policies (March 2026) · RMA: How Banks Are Refining RCSA Programs · OCC Spring 2026 Semiannual Risk Perspective · Forvis Mazars RCSA Best Practices 2024