Over the past few weeks, I have found myself returning to the same discussion about why the build, buy and consume choices still matter in an agentic banking world. There seems to be a growing assumption that AI’s ability to generate code will make this discussion obsolete.
I disagree.
I think these choices are as important now as they have ever been, even if the economics and pressures surrounding them are changing. So let us explore the subject a little more deeply…
Few choices matter more to a bank than whether to build, buy or consume a capability. AI has made that choice look easier. In my view, it has made it easier to get things wrong.
This became one of the liveliest parts of the discussions at the launch of my book Rip Out the Core earlier this week. It carried on during the evening, long after the formal discussion had ended. That is usually a sign that a subject has touched a nerve.
This article is partly my attempt to formulate where I stand. I am not writing it with my banker, consultant or CTO hat on, or on behalf of any organisation. Those experiences inevitably shape how I see the problem, but this is my independent perspective on what makes sense for the industry, and as the author of Rip Out the Core.
The current discussion is becoming extreme. We are told that AI will write most, if not all software, make development dramatically cheaper and allow every bank to rebuild whatever it wants. From there, it is a short jump to the conclusion that the old sourcing logic no longer applies. If code is cheap, why buy anything? Why consume a capability from someone else when an AI coding agent can create it for you, in minutes?
Because creating code was never the whole decision.
A bank does not own code for the pleasure of having it.
It owns a capability, with all the responsibility that follows. It must understand it, secure it, test it, operate it, change it, explain it to regulators and keep it working at three in the morning. AI can reduce some of the effort involved in producing and maintaining software. It does not remove accountability, operational risk or the cost of getting the architecture wrong.
For me, this is critical because I am starting to see that the builders’ bias is about to return with considerable force.
A faster saw does not tell you which wall to remove
In Rip Out the Core, I argue that transformation must begin with the future bank the business wants to become. From there, the bank defines the capabilities it needs, shapes the target architecture and decides how those capabilities should be delivered. Only then does it turn back towards the legacy estate and work out the path from here to there.
AI does not alter that sequence.
It will influence IT modernisation. It can analyse old code, recover hidden logic, generate documentation, create tests, assist with data mapping and help teams develop new software faster. Used well, it can take cost and time out of some of the hardest parts of the journey.
But progressive transformation is still business-led. It is not a technology replacement exercise with AI added to the project logo. If the target business model is unclear, the capability boundaries are confused and the architecture is brittle, AI will help the bank reproduce that confusion at greater speed. It can translate yesterday’s design into newer code and still leave the bank with yesterday’s bank.
The kitchen renovation analogy from the book still works. A faster saw is useful. It does not tell you which wall is load-bearing, which cabinet is worth keeping or what kind of kitchen the family actually needs. Those are design choices. In banking, they are business and architectural choices.
AI changes the speed of the renovation. It does not change the fact that customers are living in the house while the work is under way.
AI coding is real. The silver bullet is not
There is a temptation to treat AI code generation as the holy grail of software development. Describe what you want, point the agent at the legacy estate and let it analyse, translate and rebuild. The old constraints disappear because the cost of producing code collapses.
Some of that promise is real.
AI can explore a codebase faster than a person approaching it for the first time. It can trace dependencies, explain unfamiliar routines, generate documentation and propose tests. It can create useful code very quickly when the task is bounded and the desired outcome is clear.
The evidence already shows this. In a controlled GitHub study, 202 experienced developers completed a defined API-development task. Those using Copilot were more likely to pass all ten unit tests, and the resulting code showed small but statistically significant improvements in readability, reliability and maintainability.
But a bounded API exercise is not the same as changing a mature banking platform.
METR’s 2025 randomised study looked at experienced open-source developers working in repositories they already knew. In that setting, the developers took 19% longer with the AI tools available at the time, even though they expected AI to make them faster. METR’s 2026 follow-up suggests the tools have improved and are probably producing speed gains for more tasks, but it also explains why the size of that gain has become difficult to measure reliably.
GitHub has a commercial interest in Copilot, while METR studied a particular kind of developer working in a particular setting. Neither result should be elevated into a universal truth.
Both findings can be true. AI can be very effective on well-specified work and much less predictable when it meets a large codebase, undocumented assumptions, local conventions and years of accumulated coupling. The models are improving at extraordinary speed. That still does not make every development problem solved.
The first challenge is skills.
People often call this prompt engineering. I think that is already too narrow. A good prompt helps, but the durable capability is context engineering. The agent needs access to the right architecture decisions, coding standards, current API contracts, data definitions, security policies and operational constraints. It needs to know which legacy behaviour is deliberate and which is an accident that should be left behind.
DORA now makes the same distinction. A prompt is an instruction. Context engineering assembles the information and controls that allow the AI to work against the organisation’s actual standards. That requires better documentation, accessible internal knowledge and strong engineering discipline. Many banks do not have those foundations today. Their important logic is distributed across code, process documents, people’s memories and manual workarounds.
AI can help uncover that knowledge. It cannot know automatically which version represents the bank the business wants to become.
Then there is the output itself. Generative models remain probabilistic. They can produce different implementations from similar instructions, invent a dependency, misunderstand an edge case or change something outside the intended boundary. Keeping an agent working until it gives the answer you expected may feel like progress. It can also become a form of confirmation bias. The fact that the code now looks right does not establish that it is right.
Nor does generated code have to be poor. That would be an equally lazy claim. It may be clean, elegant and better than code written under pressure by a human team. The point is that generation speed tells us very little about production fitness. The code still needs review, deterministic tests, security analysis, performance testing and clear ownership. The AI can help with every one of those activities, but it cannot remove the need to define what good looks like and prove that the result meets it.
NIST’s Generative AI Profile is useful here. It treats confidently wrong output as a specific generative AI risk, recommends that generated code be reviewed for validity and safety, and warns against extrapolating capability from narrow or anecdotal assessments. In other words, a successful demonstration is evidence that the demonstration worked. It is not proof that the system is ready for the conditions in which it will operate.
That brings us to the Christmas panic.
Will the generated service still behave correctly when transaction volumes spike, a downstream system slows and retries begin to queue? Will it preserve ordering and idempotency? Will it fail safely, recover cleanly and give the operations team enough information to understand what happened? Did someone test the awkward combinations that were absent from the prompt and the legacy documentation?
The Christmas peak is not a unit test.
Less effort may be spent typing code. More attention is needed in specification, context, review, integration, security, testing and operations. DORA’s research on generative AI in software delivery found that a 25% increase in AI adoption was associated with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability. One explanation was that faster code generation created larger batches that were harder to review and more likely to destabilise the system. DORA’s 2025 State of AI-assisted Software Development describes AI as an amplifier of the engineering organisation around it. Strong practices become more valuable. Weak ones become more visible.
This does not weaken the case for AI-assisted development. It tells us how to use it properly.
Where a capability differentiates the bank, taking on this work is exactly the right choice. The bank wants control, has a reason to build and should invest in the people and engineering system needed to own the result.
For the generic capabilities required simply to operate as a bank, the question is different. If a specialist provider can carry the development, security, scaling and operating burden across many institutions, why should each bank recreate the same pain for itself? The pain has not vanished for the ISV. It has been concentrated in an organisation whose product, skills and economics are designed to handle it, then spread across a client base.
The bank still owns accountability. Consuming a service changes the control model from owning all of the source code to governing contracts, service levels, auditability, resilience and exit. But it avoids confusing the new ability to generate code with a new reason to own commodity software.
The sourcing logic still holds
I wrote about this previously in Making the Build, Buy or Borrow Choices About Your Future. My view remains the same. The decision should be made capability by capability, based first on what differentiates the bank and then tested against architectural criticality, regulatory constraints, market maturity, total cost of ownership and the bank’s ability to own the result.
Differentiation is the starting point, not the only test.
The 2×2 from my book makes the basic logic visible. One axis looks at differentiation. The other looks at alignment with common industry capability. Where differentiation is high and industry alignment is low, there is a stronger case to build. Where a capability is highly aligned across the industry and offers little differentiation, consumption is usually the more sensible posture. Between those positions sit configuration-led and engineering-led forms of buy.
[Figure 8.1 (page 104) the Build Buy Consume quadrant, from the book Rip Out the Core, by Pål Krogdahl]
AI may lower the cost of engineering in each quadrant. It does not automatically move a capability from one quadrant to another.
Over time, the map will change. Capabilities will become commoditised, vendor markets will mature and a bank’s own strategy will evolve. Something that sits in build today may move towards buy or consume later. That is a reason to revisit the decision regularly. It is not a reason to abandon the framework.
A transaction ledger does not become a source of competitive advantage because a coding agent can help create one. A sanctions screening engine does not become unique because the bank generated the code itself. Rebuilding standard banking mechanics with AI may be faster than rebuilding them without AI, but it is still an investment in something the market has already solved.
The reverse is also true. Where a bank genuinely differentiates through its customer experience, product design, proprietary insight or orchestration, AI can make building far more attractive. It can shorten feedback loops, help teams experiment and reduce the distance between a product idea and working software. That is exactly where the bank should apply its own engineering capability and where it should retain control of the logic that makes it different.
This is the point that gets lost in the claim that AI makes build cheaper. Cheaper code does not mean cheaper ownership. Nor does it mean the bank has the skills, operating model or appetite to maintain what it has created. A useful prototype produced in days can still become a badly understood production dependency that remains for a decade.
The sensible default therefore remains familiar. Build where the bank differentiates and can genuinely own the capability. Buy where a mature product provides the right functional and architectural fit. Consume where speed, scale, resilience or ecosystem access matter more than ownership.
Build less. Orchestrate more.
Banks, consultants and software vendors will see this differently
AI creates different value for each participant in the banking technology market. It also exposes different commercial incentives.
For the bank, the prize is better customer outcomes, faster change and a lower cost of running the estate. The bank should use AI to improve engineering where it has deliberately chosen to build. It should also use it across the transformation itself, from discovery and legacy analysis through testing, migration and operations. The objective is not more code. It is a bank that can change more safely and with less structural complexity.
I keep saying that banks should focus on “building a better bank and not a better core”.
For systems integrators and consultancies, AI creates a more complicated tension. It can make their delivery teams much more productive. That is valuable to the bank, especially in legacy analysis, integration, migration and quality engineering. At the same time, a commercial model built around large programmes and engineering effort will naturally be attracted to a broader build agenda. If AI reduces the effort required for each piece of software, the temptation is to put more software into scope.
This is not a conspiracy and it does not describe every adviser. It is a structural bias, in the same way that banks have their own builders’ bias and software vendors naturally see more problems that their products can solve.
A good systems integrator should use AI to reduce the bank’s change burden, shorten coexistence and leave behind less bespoke complexity. If the result is a larger custom estate that the bank cannot operate without the same partner, productivity has improved but the bank’s position has not.
For independent software vendors and ecosystem partners, the economics are different. They can use AI to accelerate a capability that is shared across many banks. They can improve product development, testing, configuration, implementation tooling, regulatory updates and support, then spread that investment across their client base. A specialist provider can keep improving fraud detection, payments processing, ledgering or regulatory reporting while each bank benefits without funding the entire development lifecycle alone.
That strengthens the consume and buy cases for non-differentiating capabilities. If an ISV can use AI, domain expertise and the experience of multiple implementations to improve a standard capability faster than one bank can, duplicating that work inside the bank makes even less sense.
Banks should not be naive about the vendor side either. Some suppliers will put an AI label on an existing product and call it reinvention. Others will use proprietary models or data arrangements that make explainability, portability and control difficult. The usual questions about fit, openness, resilience, roadmap and lock-in still apply. AI creates new questions around data use, model risk and observability. It does not excuse weak product architecture.
The friction between these players is therefore predictable. The consultancy may argue that AI makes bespoke engineering viable. The ISV will argue that its AI-enabled platform offers greater leverage. Internal teams may prefer the option that protects their existing role. The bank must own the decision and return to the capability model whenever the debate becomes a contest between suppliers.
Agentic banking changes the front door
The strongest case for AI is not deep inside the transaction engine. It is in how the bank understands, serves and interacts with customers, and in how quickly it can turn that understanding into useful products and services.
Existing channels like web and mobile will not disappear overnight. They will, however, stop being the only front door. Customers will increasingly interact through personal agents and through services embedded in the journeys they already use. In some cases, the entity calling a banking capability will be an AI agent acting for a person or a business rather than a person navigating a screen. In that sense, AI agents will become a new class of customer.
This is where the move towards agentic banking becomes critical. The bank is no longer always the destination. Its capabilities need to be discoverable, understandable and executable through well-governed interfaces. Product features can become more contextual. Advice can become more continuous. An agent can assemble an outcome across several capabilities without forcing the customer to understand the bank’s internal product and channel structure.
That future depends on platform banking, clean capability boundaries and orchestration. An agent cannot safely navigate unclear ownership, hidden product logic, inconsistent data and brittle integrations. A bank that cannot expose a capability cleanly cannot give that capability safely to an AI agent.
AI does not sit on top of a broken bank. It exposes the limitations of the fragmented estate, which is why it increases the urgency of progressive transformation. It does not magically repair them.
Banks should use AI aggressively in the experience, insight and orchestration layers where it can improve relevance and accelerate product innovation. They should also expect their ecosystem partners to embed AI into the capabilities they provide. The bank’s role is to combine those capabilities into a coherent service and retain control over the customer promise.
Keep the nucleus small, deterministic and boring
There is a boundary here that I believe the industry needs to state much more clearly.
And I will stick with this.
The future of banking will be agentic and AI-powered.
BUT, the nucleus of the bank should remain deterministic.
Coreless banking does not mean a bank without a core. It means a much smaller core with clear boundaries. At its centre sits the contract and posting runtime, the contract subledger and the authoritative event trail. The general ledger and financial reporting consume controlled events from that nucleus. None of this should depend on a language model deciding what probably happened.
€1 must always remain €1. An account balance is not a prediction. A payment either posted or it did not. Interest was calculated according to the contract. Fees, limits and reconciliation must be explainable and repeatable. We do not want creativity, drift or hallucination in the commitment path for money.
This does not mean AI has no role near financial decisions. Banks have used statistical and machine learning models in fraud, credit and risk for years. Agentic systems can detect anomalies, gather evidence, recommend an action, explain a transaction or help resolve an exception. The important distinction comes when the bank commits money, contractual terms or a posting. Probabilistic intelligence can inform that moment. A controlled, deterministic service must execute it and record the resulting state.
The agent may make the request. Policy, permissions and limits determine whether it is allowed. The posting engine then performs an exact state change and records an auditable event.
That separation is not a brake on innovation. It is what allows the bank to use AI at scale without weakening trust in the books and records beneath it.
AI is the accelerator, not the sourcing strategy
AI will change how software is created. It will reshape customer interaction and allow product teams to move with a speed that was unrealistic only a few years ago. It will also allow vendors to improve shared banking capabilities faster and give systems integrators powerful new tools for transformation.
None of that removes the need for judgement.
The bank still needs to decide which capabilities define its future, which logic it must own and where it gains more by using the market. It still needs an architecture that supports coexistence while old and new operate together. It still needs to distinguish progressive transformation from the IT modernisation that enables it.
AI makes build possible in more places. It does not make build sensible in more places.
Use it where the bank differentiates. Let ISVs and ecosystem partners use it to accelerate the capabilities they can provide better at scale. Expect advisers to use it to shorten the journey and reduce bespoke complexity, then hold them to that outcome.
And keep the core-core small, deterministic and boring.
That is not an old-world constraint on an AI future. It is the foundation that makes the AI future of banking possible.
