What do bank examiners look for in non-core system infrastructure?

When an examiner flags your customer-facing fraud platform and nothing’s gone wrong, they just want the environment diagram, the ownership record, and the control log, not a verbal walkthrough of the reasoning behind it. But your team knows the system cold, even though the documentation hasn’t caught up to what they know. 

This is playing out at more institutions since January 2026, and it’s happening with systems nobody would have called core.

What shifted under OCC Bulletin 2025-24

Under OCC Bulletin 2025-24, the fixed examination checklist for community banks was replaced with risk-based supervision, effective January 1, 2026. Examiners no longer work a standard list top to bottom. They follow documented risk decisions across every system the institution runs, core or not.

As the ABA Banking Journal reported, that shift puts non-core systems squarely in scope. Any system that touches regulated data or affects operational continuity is fair game now: the customer portal, the fraud detection tool, and the fintech integration that went live two account managers ago.

The scope expanded again in April 2026, when the OCC, Federal Reserve, and FDIC published updated model risk guidance covering AI tools supplied by vendors. Every model the institution runs now needs documented governance on where it lives, who owns the environment, and how the institution proves control over something it didn’t build.

What examiners are evaluating

Examiners don’t open by asking whether a system is core or non-core. They ask whether you can answer, on the spot, why a flagged system lives where it does, who owns it when it breaks, and how it behaves at 2am on a Saturday when nobody senior is awake.

That third question is the one that trips people up. Ownership on a slide is easy, but ownership at 2am, when your fraud platform is throwing errors and three different vendors each think someone else is on call, is where the documentation usually runs out.

When workloads share an environment, and your runbook was written for one system but gets stretched to cover three, those questions stop having a clean answer. That’s the accountability gap shared cloud environments create in banking, and no policy memo fixes it after the fact.

Third-party risk is part of this now

Vendor integrations get their own scrutiny. When an examiner looks at your non-core system built on a vendor’s tooling, they’re not just checking whether the integration was approved. They’re checking whether anyone can point to the environment it runs in and say, in one sentence, who’s accountable for it.

Drop your fintech integration into the same environment as everything else and that sentence gets long. It turns into a paragraph, then a meeting, then a follow-up request. Examiners notice exactly where a straight answer turns into a research project.

A dedicated, isolated environment for vendor integrations keeps that sentence short: here’s the environment, who owns it, and how the vendor’s access is locked down.

What audit-ready documentation looks like

Institutions that move through examiner reviews cleanly usually share the same three habits. Every non-core system has a documented reason for living where it lives. Ownership sits with a named person or team, never a shared inbox. And controls are written for that system specifically, not inherited from a general policy binder nobody’s opened since the last exam.

The institutions that struggle are usually the ones whose documentation describes how a system was designed, not how it runs today. An examiner asking about a system that migrated 18 months ago, and never had its governance paperwork updated to match, finds that gap in about 10 minutes.

Cloud environments built for regulated financial institutions are structured so ownership, controls, and placement decisions get made per workload from day one. That’s what makes the documentation hold up when someone finally asks.

Core and non-core were never the point

Examiners don’t care whether a workload is labeled core or non-core. A well-placed, well-documented non-core system is easier to defend than a mission-critical one that ended up somewhere convenient. Knowing where a system belongs is the minimum. Being able to explain and defend that decision when someone is sitting across the table is the real test.