The Strangler Fig Playbook for Core Banking

The safest core banking rewrite is usually the one that stops calling itself a rewrite.

I have watched large programmes begin with a familiar promise: replace the old platform, preserve the customer experience, simplify the estate, and finish inside a business case that looked reasonable in year one. The plan is logical on paper. It fails because the bank keeps operating while the plan is being executed.

Accounts keep opening. Payments keep moving. Risk policies change. Product teams need features. Regulators ask for evidence. The old core continues to hold business truth while the new core tries to catch up with it.

The strangler fig pattern works because it accepts that reality. It grows the new platform around live capability until the old capability has less and less work to do.

Start with the boundary

The first decision is not the cloud platform, the integration tool, or the vendor. It is the boundary.

A good boundary is a business capability that can be observed, routed, tested, and reversed. Customer onboarding. Limit setting. Statement generation. Payment enrichment. Eligibility assessment. Each has a recognisable input, a decision path, and a way to prove equivalence against the inherited system.

A poor boundary is a technical layer. Data access. Shared services. Middleware. Those slices look tempting because engineering can see them, but they rarely map to business accountability. They move complexity sideways.

In a core modernisation programme, I would rather replace one narrow capability end to end than replace one technical layer across everything.

Run old and new together

The strongest strangler programmes use parallel running as a discipline, not a ceremonial phase before go-live.

The new service receives the same event or request as the old core. It produces its answer. The old core still owns the official outcome. The platform compares both answers, records divergence, and tells the team where the new boundary is wrong or incomplete.

This is slow for the first slice. It is also how confidence becomes real. You are not asking a steering committee to trust a migration plan. You are showing them decision equivalence, exception handling, latency, rollback, and audit evidence.

Once the path holds, traffic shifts. A percentage first. Then a segment. Then the whole boundary. The old capability is retired only after the new one has operated under production signal.

Where AI belongs

AI can help this work, but only inside a governed engineering shape.

AI agents can read legacy behaviour, generate contract tests, propose mapping rules, and produce migration scaffolds. They can shorten the distance from intent to executable artefact. They cannot own the architecture. They cannot decide the risk boundary. They cannot be the reason a bank trusts a cutover.

That responsibility stays with human architects.

The useful pattern is AI-Native Engineering with hard constraints: domain language, approved interfaces, replayable tests, policy checks, and human review at material points. AI participates in the build. The platform proves the result.

The practical lesson

Core banking modernisation fails when it becomes a single act of replacement. It succeeds when it becomes a sequence of defended substitutions.

Each substitution removes one piece of dependency from the inherited platform. Each one leaves evidence. Each one makes the next substitution easier.

That is less dramatic than a big-bang rewrite. It is also more likely to reach production.

Why the pattern compounds

The strangler pattern also creates organisational learning.

The first boundary teaches the team how to route traffic, compare outcomes, monitor divergence, write rollback paths, and explain the change to operations. The second boundary starts faster because those patterns exist. By the third boundary, the modernisation programme has reusable evidence, reusable platform controls, and a delivery rhythm the business can understand.

This is why I prefer it to programme language about transformation. Transformation is too large a noun. It hides the work. A defended substitution is specific. It has an owner, a scope, a signal, and a retirement path.

The risk to watch

The risk is creating a new shell around an old core while the old core continues to own every meaningful decision.

That happens when teams move channels and APIs first but leave policy, state, and decision logic in the inherited platform. The new system looks modern from the outside. Inside, it still depends on the old release cadence and the old operational shape.

A real strangler effort moves ownership. It transfers decisions, events, and evidence into the new boundary. The old system becomes a source for comparison, then a dependency, then a retired asset.

The counter-argument is that this approach takes too long. I think that confuses calendar time with risk time. Big replacement programmes can look fast in planning and become slow in recovery. A defended substitution looks slower in planning and becomes faster because each step reduces uncertainty.

That progression is slower to describe and stronger to execute.