Banking Modernization & Regulatory Compliance

Part 3 covered the first forcing function — the retiring workforce. This part covers the second, which comes from outside the institution: examiners, auditors, and regulators. It is the one most often misrepresented in modernization sales pitches, so this part is built around getting it right. The honest version is less dramatic than “the regulator is making you modernize,” and more useful: the regulations mandate outcomes, not modernization — and a legacy core often cannot produce those outcomes. That gap is the liability. Modernization is one way to close it, not a thing the rule commands.

What the regulations actually require

The major frameworks bearing on a US bank’s core systems share a defining characteristic: they are outcome-based and technology-neutral. They tell you what risk you must manage and what outcomes you must demonstrate; they do not name a stack, and they do not order you to replace anything.

FFIEC and OCC cybersecurity expectations are supervisory guidance, not statutes. They ask institutions to manage IT and information-security risk to a level commensurate with their size and complexity. Notably, the FFIEC retired its Cybersecurity Assessment Tool on August 31, 2025, and pointed institutions toward frameworks like the NIST Cybersecurity Framework and the CIS Controls instead — there is no single mandated successor. The recurring examiner concerns are unsupported software, weak patching, and brittle change controls. (The exam-driven detail is in the FFIEC/OCC remediation guide.)

The GLBA Safeguards Rule is technology-neutral and outcome-based, but it does require concrete outcomes: a written information-security program, MFA, encryption of customer information at rest and in transit, monitoring and logging, and a designated qualified individual. Its major technical requirements became enforceable June 9, 2023, and a breach-notification amendment took effect May 13, 2024. (Detail in the GLBA remediation guide.)

NYDFS Part 500 is risk-based and allows CISO-approved compensating controls where a requirement is infeasible, but it requires a cybersecurity program, a CISO, MFA, encryption of nonpublic information, audit logging, asset inventory, and 72-hour incident reporting. The Second Amendment phased these in through November 2025. (Detail in the NYDFS Part 500 guide.)

Alongside these sit SOX IT general controls for public institutions — change management, access, and the auditability of financial-reporting systems — and PCI DSS wherever card data is in scope. Both, again, mandate outcomes and controls, not modernization.

The pattern is consistent. Every one of these says some version of: manage the risk, produce the outcome, prove the control. None says: modernize.

How a legacy core becomes a liability anyway

If none of them requires modernization, why does a legacy core keep showing up in findings? Because the outcomes they do require are exactly the ones an old core struggles to produce:

• Unsupported software. When a vendor stops supporting a platform version, patches stop. “We can’t patch it because it’s out of support” is a hard sentence to say to an examiner, and it maps directly to the recurring FFIEC/OCC concern. (See end-of-life software risks.)
• Encryption and MFA that won’t fit. GLBA and NYDFS expect encryption at rest and in transit and MFA at access points. Older platforms often cannot apply these without a wrapper or a redesign at the boundary.
• Audit logging that doesn’t capture what’s asked for. A system that does not log access and change in the way examiners expect cannot demonstrate the control, even if the underlying behavior is sound.
• Brittle change control. SOX ITGC and examiner expectations both want change that is controlled, tested, and reversible. A core where deployment is a manual, batch-window, all-or-nothing event is hard to evidence as well-controlled — and, not coincidentally, is the same brittleness that makes a big-bang cutover dangerous.

None of these is “you must modernize.” Each is a gap between a required outcome and what the system can produce. The finding is about the unmanaged risk; the legacy system is merely why the risk is hard to manage.

Remediate the gap, not the whole core

The trap here is to read a finding as a mandate for wholesale replacement. It usually isn’t. Most compliance gaps can be closed by modernizing the specific capability behind the finding while the rest of the core runs untouched:

• Add encryption and MFA at the boundary of the system holding customer information.
• Build the expected audit logging into a rebuilt slice as you modernize it.
• Replace the brittle, manual deployment path with controlled, tested, reversible delivery — which is the same incremental delivery model this series advocates for every other reason.
• Sequence the work by exposure and finding severity, so the riskiest, most-cited gaps close first. (The compliance-driven modernization roadmap covers this sequencing in depth.)

This is where progressive modernization and compliance align almost perfectly. Controlled, tested, reversible, slice-by-slice change is itself the operating model examiners want to see, and it produces evidence — parity results, deployment records, rollback capability — that a big-bang program cannot. Modernizing the way Part 1 and Part 2 describe does not just satisfy a finding; it improves the very control environment the regulators are assessing.

Match the remedy to the risk

Two honest cautions. First, modernization is not a compliance silver bullet. A modern stack badly governed can fail an exam as surely as an old one; the controls, not the vintage, are what’s assessed. Modernization makes the outcomes achievable; it does not guarantee them. Second, not every finding justifies a program. Sometimes the right answer to a gap is a compensating control — a wrapper, a boundary protection, a documented risk acceptance the CISO signs — not a rebuild. NYDFS and GLBA both explicitly contemplate compensating controls. The discipline is to match the response to the risk: remediate where remediation is warranted, compensate where it is sufficient, and reserve modernization for where the gap is structural and the system genuinely cannot produce the outcome. We would rather help you scope the minimum defensible change than sell the maximum.

Where this leads

Compliance and the talent clock both press on the core in general. But there is one part of the core where the stakes — uptime, fraud, real-time expectations, and regulatory attention — all peak at once: payments. Modern rails move money in seconds, around the clock, and a legacy payments path is where the gap between what customers expect and what the core can do is most visible. Part 5, Payments System Modernization, goes into the real-time payments shift, ISO 20022, fraud and resilience, and how to modernize the rails without dropping a transaction.