What agentic delivery changes in banking core
A core banking platform is the least forgiving environment in commercial software: decades of accumulated logic, a change advisory board, and a ledger that regulators can ask about years later. Almost none of the standard advice survives contact.
There is a particular kind of engineering organisation where the phrase “move fast” has never been said sincerely, and core banking is the archetype. The system has been running for decades. Parts of it are in a language most of the team cannot read. The change advisory board meets weekly. And somewhere in the middle of it is a ledger whose history a regulator may ask about long after everyone who wrote it has retired.
The instinct in these organisations is that agentic development is for other people. I think that is wrong, but for a reason that has nothing to do with speed, and the speed argument is the one that will get the programme killed.
The throughput argument is the weak one
Start by conceding the obvious. If your releases are gated by a weekly advisory board, generating code ten times faster produces a longer queue and nothing else. Every argument in this series about verification becoming the constraint applies here with the additional twist that the constraint is not review capacity, it is a governance calendar that engineering does not control.
So leading with velocity in a bank is both unpersuasive and slightly alarming to the people you need. The stronger argument is about evidence.
A change advisory board exists because the organisation cannot otherwise establish that a change is safe. Every artefact it demands, the implementation plan, the test evidence, the rollback procedure, the sign-offs, is a substitute for information that does not exist in a machine-readable form. The board is expensive because it is doing manual verification of claims nobody can check automatically.
An agentic pipeline, built properly, produces exactly those artefacts as a by-product of doing the work. That is the argument: not that you will ship faster, but that the evidence the board currently assembles by hand can be generated, and generated more completely than a human assembles it.
What the board asks for today
- A written implementation plan
- Test evidence, usually a screenshot
- A rollback procedure nobody has run
- Sign-offs collected over days
- An impact assessment written from memory
What the pipeline can produce
- The ticket and criteria the work was built against
- Per-criterion evaluation with reasoning
- The revert path, with its last exercise date
- Independent approver identity, timestamped
- Every path the change actually touched
COBOL is not the obstacle people expect
The reflex assumption is that a mainframe ledger is where agents are useless. The reality is more interesting and more uncomfortable.
Agents read COBOL adequately. They are frequently better than the available humans at explaining what a program does, because the humans who could are few and busy, and the model has no fear of a 4,000-line program. For comprehension, documentation, dependency mapping, and generating a plain-language description of a batch job, this is genuinely useful work that nobody has time to do and that has real value independent of any code being written.
Where it degrades is exactly where you would want confidence: the program’s behaviour depends on operational context that is not in the source. Job control that runs it in a specific order. A dataset whose format is defined by a document from 1998. An assumption about the state left behind by the job that ran before it. The source is legible; the system is not, and the model cannot see the difference.
So the honest position is that agents are a strong comprehension tool and a weak modification tool in this environment, and the value is front-loaded into understanding rather than changing.
The ledger question, stated precisely
Banking has a requirement most domains do not: the ability to explain a number, years later, to somebody with statutory authority to ask.
That requirement has always been served by a combination of the audit trail in the system and the institutional memory of people who understood it. The second half is thinning everywhere, and an agentic pipeline thins it faster, because the volume of change outruns anyone’s ability to read it.
This is the strongest argument for a proof chain in this industry, and it is worth separating from any product claim. If a change altered how interest is calculated, the organisation needs to be able to say what changed, when, who authorised it, what business requirement it served, what was verified before it shipped, and who approved it independently. Not from memory. From a record that was produced at the time and cannot be quietly edited afterwards.
Most banks can produce some of that today, assembled by hand, slowly, with gaps. The gaps are the risk, and they widen with volume.
Interest calculation changed on 2026-03-11.
requirement RB-8842 “align accrual with revised T&Cs” criteria 4 stated, 4 evaluated, 0 unverifiable changed accrual/daily.cbl, accrual/posting.cbl approved independent approver, not the specifier reverted? no; revert path exercised 2026-02-04 recorded at the boundary, append-only
Where to actually start
Not in the core. The sequencing that works in a bank is the opposite of the one that gets proposed.
Start in the channels and the surrounding services: the mobile and web layers, the APIs, the internal tooling, the data pipelines that feed reporting. This is where most engineers are, where change is frequent, where the tests exist, and where a mistake is recoverable. It is also, usefully, where the advisory board’s grip is loosest, so a pilot can actually demonstrate something within a quarter.
Use that work to build the evidence machinery: criteria that mean something, a proof chain, reconciliation between the tracker and source control. Then take the machinery to the board and make the case that the artefacts it demands can be produced automatically for a class of change. That is a governance conversation supported by a working system, which is a much stronger position than a governance conversation supported by a vendor deck.
The core comes last, and it comes as comprehension first: documentation, dependency maps, test characterisation of existing behaviour. Modification of ledger logic is the final step and possibly never a fully automated one, which is a legitimate outcome rather than a failure.
Where this breaks down
The advisory board may not be movable, and it may be right not to move. Some of these controls exist because of a consent order, a regulator’s finding, or a past failure that cost the institution badly. Arguing that your evidence is better than their process is a technical argument against an organisational scar, and it loses. The productive framing is to make their existing process cheaper to satisfy, not to replace it.
Mainframe change is often not in git. Everything in this series about deriving ground truth from source control assumes the work lands there. A change managed through a vendor’s proprietary lifecycle tool, or through a process where the artefact of record is a change ticket rather than a commit, breaks the entire premise. Check this before anything else; it is a yes-or-no gate on the whole approach.
Tests characterising legacy behaviour assert the bugs too. Generating a test suite around a forty-year-old batch job captures what it does, not what it should do. That is genuinely useful as a regression net for a migration and actively misleading if anyone treats it as a specification.
The comprehension output needs verification and rarely gets it. A confident, fluent, wrong explanation of what a settlement job does is worse than no explanation, because it will be believed and cited. Anything produced this way needs a human who knows the system to confirm it before it enters the documentation, and those humans are the scarcest resource in the building.
And the skills problem is not solved by any of this. A bank with three people who understand its core has a succession problem that comprehension tooling mitigates and does not fix. Documentation is not the same as someone who can be paged at two in the morning.
The takeaway
In core banking the throughput argument is weak and the evidence argument is strong. The advisory board is expensive because it manually verifies claims that nothing can check; a pipeline that produces real evidence per change addresses the actual cost.
Start in the channels rather than the core, build the criteria and proof machinery where mistakes are cheap, then make the governance case from a working system. Treat agents in the legacy estate as a comprehension tool first, and be honest that modifying ledger logic may stay human for a long time.
If you take one thing into next week: find out whether changes to your core actually land in source control in a form something could read. That single answer determines which of the two paths above is even available to you.