On 17 September 2026 Akkuro and WislaCode ran a LinkedIn Live on one question: where should a bank configure a platform, and where should it build its own software? The session was called "Your bank is unique. Your software doesn't have to be." The recording is public at https://youtu.be/m8TFg-YxK1U, and my part starts at 15:33.

I went into that webinar with nothing to argue about. I draw the line between speed of development and customisation, and that is a different angle on the same problem. What people do not take into consideration is that nobody prices the seam between those components and the decisions. So the question I would like you to stay with is this: what has to stay cheap to change, and how do you price the seam between ready-made solutions and custom ones?

The research behind my half was several times bigger than the session. What did not fit is below.

Who owns the space around the platform

The usual answer is to buy the platform and build around it. Who owns that around? That is always a tricky question.

On the left side you have the platform: versioned, owned, supported by the vendor, and that is absolutely okay. On the right side the bank for sure owns its ledger, its data, its regulator requirements. In between I drew a dotted line on purpose, because the seam between them is usually something nobody understands who owns. So no contract, no dedicated developer for that, no line specifically for this in the budget, because in the budget we usually plan implementing the platform.

One migration of an RTGS solution in the United Kingdom ran out of budget by many millions of pounds, and the state auditor stepped into the programme afterwards and found 47 change notices to a single contract, the one with the technical delivery partner. Those changes added a net £45 million, 47% of that contract's original fixed price. That means a lot in there was not estimated, we do not have enough culture to estimate it, and this layer usually runs out of our budgets. Frankly speaking, there is no direct decomposition in that report, and I do not know which of those 47 are exactly about the layer. The standard components worked well, and the ledger logic was beautiful.

The National Audit Office still concluded that the way the Bank of England managed the programme "demonstrates value for money": the final cost of £431 million is 15% above the £375 million budget, an increase the auditor calls reasonable given the programme's size and complexity.

We went through that audit, the two UK regulators' notices on TSB's 2018 migration and the four seams they all point at in a separate piece in July: core banking transformation fails in the seams. What we could not find afterwards is a benchmark that would let a bank estimate this layer in advance. The audits, supervisory notices and court records we read take individual institutions apart line by line, and none of them gives a cross-industry sample of what a core implementation costs or how long it takes.

The fact that I am the CEO of a software development company does not mean I came to argue. We build that layer for a living, and I have sat on both sides of the table: I was selling and I was buying, and after that I used to live with the decision I made. In one lending platform we developed, we provided the facing layer once for two identity check providers, and after that we gave the client the possibility to add a third one without us. That is what I call proper management of the seam.

On air I put the question to Dimitry Oosthoek from Akkuro directly: when you work within a bank, who usually owns this layer? You do not want to take it, and probably the architect from the bank does not want it either. His answer is in the recording at 32:44.

What has to stay cheap to change

Those are two approaches I found, from Gartner and from Simon Wardley.

Gartner tells us that systems are split into different types. A system of record is the basis, something a bank runs on, and you have to buy it, of course. A system of differentiation is something like a lending scoring system: still basis, but it differentiates you in acceptance rates, in the data you use, in how your customers see the process. So I put it there to argue about it, and to argue every time, because every differentiation solution is different. And if you have systems of innovation, which are new ones, own them 100%.

Gartner announced this model, the pace-layered application strategy, in February 2012.

Simon Wardley showed it as an evolution of every component: genesis, custom-built, product, commodity. Every system moves through that evolution during its life cycle. A few years ago we had to develop identity checks and KYC checks on our own; now it is not yet commodity, but it is a product you can find on the market, and there is no need to invent the wheel. The core ledger is already commodity. There is no sense in building commodity, because you can buy it, and no sense in buying genesis, because nobody will sell it to you. But in between you always decide this balance.

And this evolution also gives us the trick. We have to understand that our decision, buy, argue or own, will also evolve, and we have to recheck and double-check it during the time. When that recheck lands on an old core, the options are in legacy core modernisation for faster delivery.

In May 2025 BCG reported that more than 60% of bank technology spend goes to running the estate rather than changing it. Next to that figure it names the drivers: rising vendor costs, vendor lock-in that makes a long tail of small contracts hard to cut, and redundant tools and licences left by weak central governance and by excessive customisation. The figure comes from Expand Research, BCG's own benchmarking team, and neither the article nor the report says how many banks or which regions it covers.

What you can take with you when you leave

For us, taking over the source code is no problem. Your own source code, you take it, you hire different people, you struggle for a quarter, and after that you are fine. But with ready-made solutions it is a tricky question, because on top of a ready-made solution you also have a lot of configuration, and configuration is difficult to move, or maybe impossible to move, to another solution, and you have to prognose it during the contract. You can own source code, but the configuration is the product, and it is difficult to move from one product to another. The same split runs through the in-house and outsourcing question, which we covered in in-house versus outsourcing software development.

And if you understand how to take custom-built software in-house, that is only part of the problem, because this software is integrated with other domains, and you have to understand how those will also be taken in-house or switched.

The EU's Digital Operational Resilience Act, DORA, puts that in writing: Article 28(8) requires exit strategies and transition plans for ICT services supporting critical or important functions, letting the entity remove the services and the data and transfer them securely and integrally to alternative providers or reincorporate them in-house; Article 28(4)(c) requires it to assess all relevant risks of the arrangement, including whether it reinforces ICT concentration risk.

A vendor has written its own rule against modifying the package it sells. SAP says a clean core is "up-to-date, documented, unmodified, consistent, efficient and cloud compliant", and its training material sets the principle "Apply a zero-modification policy". Working within SAP's standard, configuration included, counts as clean; modifying the standard is the deviation. In August 2025 SAP replaced its three-tier extensibility model with four levels, because the binary split into "clean core" and "not clean core", and the checks behind it, "were too restrictive and not applicable for systems with a lot of existing custom code". SAP is writing about ERP. A banking core is a different product, and we could not find a peer-reviewed study that links how deeply a package is modified or extended to what its upgrades then cost.

Previously this was a best practice, and now it is regulated, and the best practice here is to estimate before you sign. On air I said that regulators require, or rather recommend, and sometimes require, an exit plan, and that not all of them require you to price it before you contract (at 23:29).

Of the three instruments we checked, all three call for an exit plan, and only the two softer ones ask what the exit would cost. DORA Article 28(8) makes the plan mandatory for every ICT service supporting a critical or important function. It does not ask for a number, and neither does the exit article of the technical standard under it, Delegated Regulation 2024/1773. Paragraph 107(a) of the European Banking Authority's outsourcing guidelines asks for exit plans that are "where appropriate, sufficiently tested", and gives as an example "an analysis of the potential costs, impacts, resources and timing implications of transferring an outsourced service to an alternative provider". Those guidelines work on comply-or-explain, and the replacement the EBA published on 18 September 2026 does not apply yet.

The sharpest wording we found sits in a supervisory statement, the Prudential Regulation Authority's SS2/21, which binds less than a regulation. Its paragraph 10.17 tells firms to start their exit plans in the pre-outsourcing phase, so that they can "estimate the cost, resourcing, and timing implications of the proposed business continuity or exit plan in both stressed and non-stressed scenarios as part of the risk assessment".

One figure from HM Treasury reads against custom development at first sight: its optimism bias table sets the upper-bound uplift for equipment and development projects at 200% of capital costs, and for outsourcing projects at 41% of operating costs. Those sit on different bases, and 200% is an upper bound for the earliest stage of a business case. The table rests on a 2002 review of 50 projects by Mott MacDonald, which does not say how many of them fell into those two categories and warns that its sample is thin once split by project type.

Price the exit before you sign

If you are about to sign for a platform or renew one, we can go through the seams around it with you: what has to stay cheap to change, and what moving your configuration off it would take.

Talk to our team

I was wrong about the mobile bank

I have to confess that I was wrong (at 24:51). In my previous public presentations I always suggested building online and mobile banking solutions from scratch, because I believed this was part of the competitive advantage. It is not any more. Those are my words: mobile banking is something you have to build custom in 100% of times. Now I would like to change it, because in mobile banking there is also a split between ready-made solutions and custom ones. That is why I decided that "always" should be taken out of that phrase. But I still insist that you have to consider the value of mobile and online banking every time you make a decision like that.

For a credit union with 20,000 customers there is no need to build a mobile or online application from scratch, for sure. They will not be able to develop it, it is difficult to support on different platforms, security questions arise, and if they do not have enough speed requirements, there is no need to build it on their own.

In the Ipsos research it was not 100% clear to me how customers recommend banks, because there are a lot of parameters they take into consideration. I can speculate on the fact that Monzo and Starling, first and second in that research, build a lot by themselves and customise everything they build. But correlation does not mean causality, and I have to mention that.

The survey behind that table is one the Competition and Markets Authority makes the largest banks run. Ipsos asked 17,055 personal current account customers in Great Britain in the year to June 2026, and online and mobile banking is scored as its own category: Monzo 85%, Starling 83%, first direct 78%, Halifax 77%, Nationwide 76%, and 71% in tenth place. That is 14 points of spread inside the top ten alone.

Net switching on the UK Current Account Switch Service over the same period is led by Nationwide, fifth in that mobile banking table at 76%. It gained 41,450 accounts net in the third quarter of 2025, when its £175 switching offer ran only from 18 September, and 64,527 in the fourth, with the offer running throughout. In the third quarter Monzo, first in the app table, came second in net switching with 9,934.

Revolut bought first and then built

Revolut started on the market with buying things, and after that they moved to owning things. Owning everything. They started with Wirecard, decided to move out of third-party providers in 2019, and managed it before the terrible crash of Wirecard. They switched to their own development because of instability on one hand and lack of control on the other.

Wirecard filed for insolvency on 25 June 2020, and the next day the UK Financial Conduct Authority put restrictions on its British e-money subsidiary, lifted on 30 June.

So no decision can be made from day one and survive till the end of the strategy. You have to reconsider every time, and you have to be prepared to move this line during the life cycle of your products, without huge penalties and without huge investments.

Three signals that the line has to move

There are a lot of signals, and you have to consider all of them in your strategic sessions (at 29:01). What I can tell you is three dimensions. First is the market: KYC and identity solutions several years ago had to be built by banks themselves, and now it is not necessary, because the market evolved and we have products on the market. Second is the speed of development: in a ready-made solution you wait for the delivery maybe several months, and you need it in two weeks. Third is the seam signal. This integration layer lives its own life, and if your integration changes a lot, maybe every sprint, that is also a signal: maybe it is a good idea to take ownership of all the process and all the product.

Here is an example I prepared for the webinar and did not get to. Marqeta sits on a specific bank: more than 60% of volume settles through one bank. They have a very strict contract till 2029, and they cannot leave without penalty.

In its annual report for 2025 Marqeta discloses that 64% of its total processing volume, 382.5 billion dollars that year, settled through Sutton Bank. The current term of that agreement runs to 2029, and ending it early means paying termination fees. The share was 76% in 2023, 70% in 2024 and 58% in the second quarter of 2026. Total processing volume is Marqeta's own operating measure, and accounting standards do not define it.

Both lines are right

Both lines are right. My point is that you have to consider which strategy to choose with how often your components or your product change. In some organisations you have something stable, and software is not your product, and that is okay to buy a lot. But for a fintech company, an innovative company, a startup, owning the code and having the possibility to develop it on their own is part of the product. That is something they sell. That is something that they are.

It is not possible to answer this question without understanding the business, but the general approach is to take those parts which are differentiating you, which are customer facing and which change fast, into your own development, and the other parts can be considered as out-of-the-box solutions. And domain borders are fuzzy nowadays, so it is difficult to draw the line there as well.

If you are drawing that line right now, this is the work we do. The full recording, with the other side of the argument, is on YouTube.

Primary sources

Frequently asked questions
Where should a bank draw the line between buying a platform and building its own software?

By how often the thing changes. Gartner's pace-layered model sorts applications into systems of record, of differentiation and of innovation, which change at different speeds, and Simon Wardley's evolution axis says the same component moves from genesis to commodity over its life, so the answer has an expiry date built into it.

Does DORA require a bank to price the cost of leaving a vendor?

Not in the provisions on exit. Article 28(8) requires an exit strategy and a transition plan for every ICT service supporting a critical or important function and does not ask for a cost, and neither does the exit article of Delegated Regulation 2024/1773. Of the instruments we checked, the ones that ask what an exit would cost are paragraph 107(a) of the EBA outsourcing guidelines, as an example of how to test the plan, and paragraph 10.17 of the PRA's SS2/21, both softer than the Regulation.

Can a bank take its configuration to another vendor?

Source code a bank owns can move: you take it, hire different people, struggle for a quarter, and after that you are fine. Configuration sits on top of a ready-made product and is difficult, or maybe impossible, to move to another solution, so it has to be estimated when the contract is signed.