The build versus buy discussion is often a category error. It treats whole systems as if they were single strategic bets, when they are really bundles of capabilities with very different risk, change-rate, and competitive value. In Chapter 8 of my book Rip Out the Core, I outline a slightly different perspective on this subject.
The modern sourcing decision is no longer just about cost and speed. Regulators are explicitly raising expectations on operational resilience, impact tolerances, and third‑party risk management, especially for cloud and other concentrated providers. Boards keep ultimate accountability, even when the capability is outsourced.
A simple model from my book that we will get to later helps you separate what genuinely makes the bank different from what simply makes it a bank, and help to evaluate the relevant posture for your future. That is the point where “borrow/consume”, “buy (configuration-led)”, “buy (engineering-led)”, and “build” become coherent postures.
Why “build or buy the core” is the wrong level of debate
The first trap is asking the question at “core system” level. “Core” is a label that collapses dozens of capabilities into one emotional decision at every bank. As I discussed in a recent post, that is how you end up with a different answer from every person you ask and ideology disguised as strategy.
In my book I open chapter 8 with a metaphor that is more accurate than it looks.
Getting pulled into an IKEA kitchen showroom and designing for the catalogue, not for the house you actually live in. Banks do the same. Vendor demos and platform roadmaps can make everything look clean and solved, while the real constraints sit behind the walls in data entanglement, fragile integration, and operating model reality.
A Business Capability-led frame changes the argument from “Should we build or buy the core?” to:
Which capability are we discussing?
Does it differentiate us, or is it hygiene?
How mature is the market for this capability (industry alignment)?
What risk and accountability do we retain regardless of sourcing?
This aligns with how supervisors increasingly want banks to think. Focus on important business services, identify dependencies, set impact tolerances, then invest where disruption would cause intolerable harm.
The 2×2 that makes sourcing decisions intelligible again
Please let me introduce a decision aid.
My 2×2 based on Differentiation and Industry alignment.
The value is not the grid itself.
The value is the discipline it forces.
Decomposing the estate into capabilities and putting each capability into a sourcing posture with eyes open.
Figure (from Chapter 8 in Rip Out the Core): Differentiation × Industry alignment, with sourcing quadrants
The four quadrants are the point where “build, buy, borrow” pick a side:
Consume (borrow) when the capability is widely standardised and does not differentiate you. The hidden work moves to governance, integration, monitoring, and exit planning.
Buy (configuration-led) when you want a fast, repeatable outcome and are willing to accept product constraints to get stability and compliance outcomes.
Buy (engineering-led) when the market provides strong primitives and a safe engineering framework, but your differentiation comes from how you design, compose, and evolve the capability. You are buying an engineering surface, which implies strong local engineering, product–tech co-ownership, and a platform operating model.
Build when differentiation is real and the market is not aligned to your intent. This is where you keep design authority and accept the full lifecycle responsibility.
I also make an important, slightly provocative distinction that banks often confuse “custom” with “clever”, and end up rebuilding generic capabilities just to feel in control. I argues that most banking capability is generic, and that build should be reserved for where differentiation is genuine.
Checklist: decision criteria focus and recommended posture by quadrant
Quadrant
What you are really optimising for
Criteria to weight highest (from the lens below)
What I would demand before approving
Recommended posture
Consume (borrow)
Speed and standardisation, while retaining accountability
Resilience/accountability; third‑party risk and exit realism; concentration/substitutability; lifecycle cost
A credible exit story (technical + contractual), evidence of monitoring/auditability, and a concentration risk mitigation plan
Consume (managed/SaaS/utility), but with hard governance gates
Buy (configuration-led)
Predictability and compliance through product boundaries
A realistic talent and operating model plan for 5–10 years, not a project plan; explicit non‑goals to avoid rebuilding generic plumbing
Build selectively, keep scope tight
Hybrid reality
Portfolio coherence
All criteria, but explicitly trade off
A joined-up sourcing map, reviewed periodically, not a one‑off decision
Mix and match with discipline
A weighted decision lens that surfaces trade-offs instead of hiding them
In the book I propose a criteria-based evaluation approach because it forces the organisation to stop smuggling preferences into decisions. It also explicitly calls out how “buy” can fail when banks bend products too far, crossing the line into expensive, brittle customisation they cannot upgrade.
To make the framework real, the decision lens needs to include criteria that have moved from “risk team detail” to board-level materiality:
Resilience and accountability: boards and senior management are expected to set impact tolerances and prioritise investment accordingly; outsourcing does not transfer accountability.
Third‑party risk and exit realism: outsourcing agreements and governance should support ongoing oversight, audit rights, termination, and exit strategies (including for critical/important functions).
Concentration and substitutability: supervisors explicitly reference risk concentration at service providers; cloud markets are described as highly concentrated, and regulators increasingly treat this as a resilience and stability issue.
As a reminder, the European Banking Authority outsourcing guidelines state that management body responsibility remains and that outsourcing must not turn an institution into an “empty shell”. They also flag supervisory attention to concentration at service providers and require exit strategies.
At the global level, Basel Committee on Banking Supervision has published principles for third‑party risk that explicitly treat concentration risk and supply chain dependencies as part of modern third‑party risk management.
And the European Central Bank has recently formalised supervisory expectations for cloud outsourcing, explicitly noting cloud market concentration and reiterating that management bodies bear ultimate responsibility for ICT risk under DORA.
Sample scoring worksheet (illustrative)
The numbers below are deliberately simple. The goal is not fake precision. The goal is making trade-offs explicit and comparable.
Example capability: Digital onboarding and first‑journey experience (not the entire lending stack)
Criterion
Weight (%)
Example score (1–5)
Weighted score
Notes on what drives the score
Strategic differentiation
20
5
1.00
A primary competitive surface; affects conversion and cross-sell
Regulatory exposure
10
4
0.40
KYC/AML, consumer duty, data integrity implications
If vendors used, exit must be credible and tested for key components
Concentration / substitutability
10
3
0.30
Avoid single points of failure; design portability where feasible
Total
100
3.75 / 5
Likely posture: Buy (engineering-led) or Build (selectively)
Why this tends to land in “buy engineering-led” or “build selectively” is consistent with my book: buy the generic processing engines and platforms where mature, but hold design authority over the experience and orchestration where differentiation lives.
A practical workshop runbook executives can actually sponsor
Chapter 8 in the book includes a concrete pattern for running sourcing decisions. A focused workshop that maps service domains and selects a posture without letting legacy constraints dictate future intent. It even warns against doing the exercise “to please the mainframe”.
The case example (NOIT Bank) uses three “anchors” per domain:
Strategic importance: is this a source of competitive advantage?
Architectural criticality: does it sit at a convergence point that shapes extensibility, reuse, or orchestration?
Executional ownership: do we need internal control over the logic, evolution, and experience?
It then adds directional guardrails that are very close to what good diligence should look like in real programmes: capability fit, configuration vs engineering posture, adopt vs adapt risk, architectural compatibility (API-first, event patterns, modular deployment), ecosystem fit, legacy constraints, regulatory constraints, cost of ownership, and time‑to‑market.
The critical addition, in 2026, is to formalise two artefacts as non‑negotiable outputs of the workshop:
Exit story: not a paragraph, a plan. Include data portability, cutover approach, fallbacks, and contractual termination support. This is strongly aligned with EBA expectations on exit strategies and termination rights.
Resilience story: “important business service” mapping and scenario testing implications for the capability and its third parties.
When sourcing choices become resilience events: four cautionary case studies
These are not morality tales about building or buying. They are reminders that the failure mode is usually governance, sequencing, and accountability.
TSB Bank plc: migration programme failure became a regulatory case
The FCA and PRA fined TSB a combined £48.65m for operational resilience failings relating to its IT upgrade and migration programme, citing inadequate organisation and control of the programme and failures in managing outsourcing risks with a critical third party. The operational disruption affected millions of customers and took months to fully stabilise.
Lesson: your sourcing posture is inseparable from your resilience posture. “We bought a platform” is not a control framework.
The Co-operative Bank: a stopped core replacement and a £148.4m write-down
In its interim report for the half-year ended June 2013, the bank disclosed a £148.4m write-down of IT assets previously under creation to replace the core banking platform, because the assets would no longer be implemented and were inconsistent with strategy.
Lesson: sunk cost is not strategy. Stopping is sometimes the grown-up move, but the write-down is the price of deferring clarity about posture and constraints.
Allied Irish Banks: vendor delivery risk, litigation, and opaque outcomes
Public reporting at the time refers to AIB alleging approximately €84m of “wasted expenditure” on a retail banking software programme, with the proceedings later settled after mediation and struck out in the Commercial Court; settlement details were not publicly disclosed.
Lesson: “buy” only reduces risk if the product boundary fits your reality and delivery governance is strong. When it doesn’t, you can end up with the worst of both worlds: high cost and low control.
Suncorp Group: impairment and a pivot to API-led delivery
Suncorp disclosed it impaired the deposit and transactions modules of its core banking platform and expected a circa $90m after‑tax impairment charge, signalling it was unlikely to roll out those modules in the near term and would instead rely on an API architecture to deliver its digital strategy with lower risk than full replacement.
Lesson: you can modernise without “big bang core replacement”, but only if you invest deliberately in orchestration and the integration architecture that makes a hybrid posture coherent.
What a sceptic will say (and why it’s worth hearing)
“Our bank is unique. Capability thinking will just commoditise us.” If “unique” means “bespoke process and brittle integration”, that is not differentiation, it is drag. Differentiation should show up in customer outcomes, risk intelligence, or ecosystem leverage, not in hard-to-upgrade plumbing.
“Buying reduces risk. Regulators like standardisation.” Regulators like evidence of control, resilience, and accountability. EBA guidance is explicit that management body responsibility remains and that outsourcing must not hollow out the institution.
“Borrowing (cloud/SaaS) is just swapping vendor lock-in for cloud lock-in.” Sometimes, yes. The ECB explicitly highlights cloud market concentration and dependency risks. The grown‑up answer is not “avoid cloud”, it is “design for substitutability where it matters, and govern the rest like a critical dependency”.
A final provocation from Chapter 8 that executives should take seriously: hybrid is the reality, but the discipline is to build less and orchestrate more. The job is to be the conductor, not the carpenter.
Stay tuned for more insights on this journey. In my book Rip Out the Core, A Practical Path to Coreless Banking, I dive deeper into the methods and real world examples of making this transition. Until then, keep questioning the old assumptions and imagine what your bank could do when it’s freed from the chains of a monolithic core.
