Legacy banking modernisation in the AI era works best as a governed, incremental path: keep the core stable, place an event-driven coordination layer in front of it, and introduce agentic services only inside explicit policy envelopes. Governance moves to intent time, every action stays reversible and auditable, and legacy components retire only after parity is proven.
Legacy cores still clear most of the industry’s volume. They also block the real-time, agent-driven behaviour regulators and customers now expect. Full replacement remains a multi-year bet few engineering leaders will underwrite. Bugni Labs works from a more durable path: an incremental roadmap that adds governed agentic overlays without a big-bang cutover, moving from human-in-the-loop to semi-autonomous execution while preserving runtime integrity and audit evidence. This guide gives engineering leaders a sequence they can start next quarter, with the guardrails that make autonomy safe in a regulated bank.
What legacy banking systems actually are
A legacy banking system is a decades-old mainframe or monolithic platform that still runs core work such as account opening, transaction processing and loan servicing, as Cognizant’s glossary on legacy banking systems describes. The architecture is usually tightly coupled. Scaling a single product line means touching shared batch jobs, shared data stores and shared release trains. Change windows are long, regression surface is wide, and “small” product requests often become multi-team programmes.
That shape resists real-time channels and third-party integration. Mobile, open banking and instant payments expect low-latency, event-shaped interfaces. A monolith built for overnight batch and terminal workflows cannot meet those contracts without an outer layer that absorbs the mismatch. It also concentrates institutional knowledge in a shrinking pool of COBOL and mainframe specialists. Maintenance cost rises as those skills leave the market, while the business rules embedded in the code remain genuine institutional IP. The hard problem is not only technical debt. It is extracting, governing and reusing those rules without freezing the bank’s ability to change.
For AI-era work, those constraints matter more than cosmetic UI debt. Agents need clear boundaries, stable events and policy they can evaluate before acting. A monolith that hides rules inside procedural code gives them none of that. If you cannot name the bounded context, the policy version and the reversible action, you cannot safely hand work to a semi-autonomous system. Modernisation has to surface intent, policy and evidence as first-class artefacts, not treat the core as an opaque black box forever. Until those artefacts exist, any “AI on the core” programme is presentation-layer automation with uncontrolled blast radius.
Why incremental modernisation is now the only viable path
Full core replacement carries multi-year delivery risk and “bet-the-bank” exposure. Scope expands, dual-running stretches, and the cutover date becomes a single point of organisational failure. Incremental methods shrink that surface. They let teams ship value on a quarterly cadence while the ledger and critical batch paths stay stable. Engineering leaders can defend that posture to risk committees because each slice has a measurable exit criterion rather than a single irreversible go-live.
The strangler pattern is the practical shape most regulated programmes can defend. Red Hat’s guidance on modernising legacy banking shows how a modern façade sits in front of the legacy core so new services can replace functionality gradually, deliver return sooner and lower overall risk. Sidecar and abstraction layers follow the same idea: route new traffic through a coordination plane, leave the core authoritative until parity is proven, then peel capability away slice by slice. Adoption is already moving that way. Legacy Leap’s 2025 core banking modernisation analysis cites IDC projections that 40% of global banks will pursue sidecar approaches by 2026, rising to 70–80% by 2028.
AI agents change the economics of that path. Intelligent overlays can bridge legacy logic with modern interaction models without rewriting the ledger on day one. Cost pressure makes the case sharper still. Digital Bank Expert’s 2025 analysis of legacy banking IT costs reports that banks underestimate total cost of ownership of legacy systems by up to 80%, while proven incremental programmes have reduced TCO by up to 52%. Incremental is no longer a compromise posture. It is how you keep the bank safe while you change it, cut reliance on scarce legacy skills over time, and move from heavy customisation toward configuration without a single cutover that freezes the estate for years.
How AI agents alter the modernisation sequence
What changes when agents perform modernisation work is the order of control. In a classical programme, governance clusters around design reviews, change boards and deploy-time checks. With agentic overlays, evaluation has to happen at intent time. An agent should assess user or system intent against policy before any downstream tool call, data write or customer-facing action. That is not a cosmetic process tweak. It is a different control plane.
The industry is already treating agentic capability as a core strategy, not a pilot novelty. CCG Catalyst’s 2025 commentary on agentic banking notes that 75% of US banks with over $100 billion in assets are expected to fully integrate AI strategies by the end of 2025, with agentic AI embedding across front, middle and back offices. That scale only holds if the platform gives agents explicit trust boundaries. Event-driven architectures and domain-aligned services create those boundaries: agents subscribe to well-typed events, act inside a bounded context, and emit outcomes that other services can reject or reverse. Governance gates, human or policy-enforced, sit between every reasoning step and every external effect. Audit evidence is captured at each gate automatically, so the control story does not depend on someone reconstructing a trail after the fact.
Architecture & Governance Magazine’s treatment of agentic AI in legacy transformation describes how intelligent overlays can bridge legacy functionality with modern interaction paradigms without full replacement, while still demanding a governance framework for security, compliance and risk. This is where governed agentic overlays differ from bolting a chatbot onto a core API. The agent is a participant in the lifecycle, not a presentation layer. Humans retain responsibility for architecture, constraints and judgement. Agents accelerate mapping, routing, low-risk decisioning and evidence packaging inside envelopes the bank has already approved. The spectrum is deliberate: start human-in-the-loop, widen autonomy only where policy, telemetry and rollback are already boringly reliable.
The incremental roadmap: five governed stages
Engineering leaders need a sequence they can start next quarter, not a multi-year aspiration slide. Five governed stages keep the work ordered, auditable and reversible. Each stage produces artefacts risk and audit can inspect before the next stage widens autonomy.
Map bounded contexts and extract business rules into an auditable policy store. Name the domains that own account servicing, payments, credit and screening. Pull decision rules out of procedural code so agents and humans evaluate the same artefacts.
Domain-driven design is the practical method here: context maps, ubiquitous language and explicit ownership beat a single “core API” dump.
Introduce an event-driven coordination layer (a sidecar or façade) that routes requests through an initial human-in-the-loop gate. New channels talk to the layer first; the core remains system of record. Prefer an
event-driven sidecar with versioned schemas so every consumer, human or agent, sees the same contracts.
Deploy agentic services for low-risk, high-volume decisions inside explicit policy envelopes. Start where blast radius is small and volume justifies automation: classification, enrichment, narrative assembly, routine exception triage. Keep write paths to the ledger behind the same gates you used in stage two.
Expand agent scope with runtime integrity checks and automated rollback on policy violation. Widen autonomy only when traces, graders and rollback paths already run on every change. If a policy version, input snapshot or reviewer identity is missing, the action does not leave the envelope.
Retire legacy components only after the agentic path demonstrates parity and full audit coverage. Replacement is earned by evidence, not by programme calendar. Dual-run until metrics and audit samples agree; then decommission with a named owner and a reversible cut plan.
Stages two and three depend on an event-driven coordination layer built as modern platform engineering: domain-aligned teams, paved event paths, and defaults for policy gates and observability. Without that substrate, agents become brittle scripts against the monolith. Industry direction supports the same sequencing. Temenos’ 2024 discussion of sidecar systems in banking notes that by 2026, 40% of global banks are expected to have adopted strategies to run digital core banking alongside legacy, which is exactly the co-existence window stages two to four exploit.
Governance and runtime guardrails that make autonomy safe
Semi-autonomous systems are safe in a regulated bank only when the controls are non-negotiable and mechanical. Every agent action should be preceded by a synchronous policy gate that checks jurisdiction, PII handling, risk score and intent approval. If the gate fails, nothing downstream runs. There is no “best effort” path around the envelope. The gate is not a dashboard after the fact. It is a blocking step in the request path.
Traceability is mandatory. Each decision should carry the policy version in force, an input snapshot sufficient for replay, and the reviewer identity, whether that reviewer is a person or an automated policy engine. When risk exceeds defined thresholds, escalation to human oversight must be automatic. Agents never improvise outside the envelope to “be helpful”. Those requirements match the governance load that arrives once overlays leave the lab. Intelligent overlays over legacy systems introduce new governance and risk obligations that have to be designed up front, not bolted on after the first production incident, which is the same posture Architecture & Governance Magazine stresses for agentic legacy programmes.
Continuous evaluation harnesses close the loop. Before any production change to prompts, tools, models or policies, regression checks run against fixed cases that represent the behaviours the bank must preserve. A harness that nobody reads is theatre. Weekly review of audit trails and failed-gate patterns turns the same machinery into living evidence for risk, audit and engineering leadership. Practical minimums for a regulated path look like this:
Synchronous intent-time gate on every tool call and external write
Immutable decision record: policy version, inputs, outcome, reviewer
Automatic human escalation above named risk thresholds
Rollback or compensate paths tested on the same cadence as deploys
Weekly audit-trail review with an accountable owner and defect backlog
Autonomy expands only when those controls are dull, repeated and evidenced. That is the difference between a demo agent and a production participant in a bank’s control environment.
Common pitfalls and how to avoid them
Most programmes fail in predictable ways. Treating the sidecar as permanent without a defined exit path leaves the bank paying for two estates indefinitely. Write the retirement criteria when you introduce the façade: parity metrics, audit coverage and the owner who signs the cutover. Legacy Leap’s core banking modernisation guidance is explicit that a sidecar becomes permanent if an explicit migration path to full replacement is not defined at the outset, and that banks which skip that definition end up running two cores indefinitely.
Placing gates only at deploy time is the second failure mode. Bad intents compound through planning and tool selection long before a release checklist sees them. Move the gate to intent evaluation so rejected work never becomes a half-executed plan. Deploy-time review still matters for change management, but it cannot be the first time policy sees the request.
Under-investing in event schema governance is quieter and just as damaging. If agents cannot reliably interpret legacy outputs, they guess. Schema ownership, versioning and consumer contracts are part of the modernisation programme, not a side chore for a platform team later. Treat breaking schema changes like breaking API changes: version, dual-publish, and retire only when consumers have moved.
Finally, skipping weekly audit-trail reviews turns expensive controls into decoration. Schedule the review, assign an owner, and treat recurring gate failures as product defects. Autonomy expands only when the evidence says the envelope is holding. If leadership cannot see failed-gate trends, top rejected intents and rollback frequency on a weekly rhythm, the programme is flying without instruments.
How to measure whether the roadmap is working
Measure progress by reduced dependency risk, not by the number of services extracted. Track the lead time for a safe change, the proportion of critical flows covered by observable contracts, the time required to replay a failed decision, the number of manual approvals that can be bounded safely, and the retirement of duplicate interfaces. Each metric should relate to a business service and its impact tolerance. That keeps modernisation focused on operating capability rather than technology inventory.