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

Learn what bank examiners look for in non-core system infrastructure, including workload placement, ownership, controls, and audit-ready documentation.

4 minutes
The challenge institutions face

An examiner flags your customer-facing fraud platform. Not because something went wrong, but because they want to know why it lives where it does, who owns it, and what controls are in place. Your team knows the system well. The documentation tells a different story.

That’s the conversation more institutions are having 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. Examiners no longer work through a standardized list. They follow documented risk decisions across every system the institution runs, core or not.

As the ABA Banking Journal reported, this shift puts non-core systems squarely in scope. Any system that handles regulated data or affects operational continuity is now fair game: customer portals, fraud detection tools, fintech integrations.

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 your institution runs, including fraud detection, credit scoring, and customer analytics, now requires documented governance over where it runs, who owns the environment, and how the institution demonstrates control.

What examiners are actually evaluating

Examiners don’t come in asking whether a system is core or non-core. They come in asking whether the institution can clearly answer questions about any system they flag: why does it live where it does, who owns it when something goes wrong, and how does it behave under pressure.

When workloads share environments and documentation was written for one system but applies loosely to several, those questions get hard to answer cleanly. That’s the accountability gap shared cloud environments create in banking, and it’s not one you can fix with a policy update.

Third-party risk is part of this now

Vendor integrations deserve specific attention. When an examiner reviews a non-core system that relies on a third-party vendor, they’re evaluating whether the institution has clear accountability for the environment the vendor’s tooling runs in, not just whether the integration is approved.

If a fintech integration sits in the same environment as other workloads, the boundary of responsibility becomes difficult to define. Examiners will notice, and the conversation gets longer.

Dedicated, isolated environments for vendor integrations give the institution a clean answer: here’s the environment, here’s who owns it, here’s how the vendor’s access is controlled.

What audit-ready documentation actually looks like

Institutions that move through examiner reviews cleanly tend to have the same things in place. Each non-core system has a documented reason for its current placement. Ownership is assigned to a named person or team, not a shared function. Controls are system-specific rather than copied from a general policy.

The institutions that struggle are usually the ones whose documentation describes how systems were designed, not how they’re actually running. An examiner asking about a system that was migrated eighteen months ago and never had its governance documentation updated will find the gap quickly.

Cloud environments built for regulated financial institutions are structured so that ownership, controls, and placement decisions are defined per workload from the start, which makes the documentation straightforward when an examiner asks.

What examiners actually care about

Examiners don’t care whether a workload is labelled core or non-core. They care whether the institution can explain why it lives where it does, who owns it, what controls are in place, and how risk is managed.

A well-placed, well-documented non-core system is easier to defend than a mission-critical one that ended up somewhere convenient. Knowing where workloads belong matters, but examiner readiness is being able to explain and defend those decisions when someone is sitting across the table.