DEV Community: Derek Francis

One in Three UK Adults Now Use Open Banking. What Does That Mean for Banks?

Derek Francis — Mon, 09 Nov 2026 10:16:21 +0000

When open banking launched in the UK in January 2018, the country's nine largest banks had to start sharing account data and payment access with authorised third parties through APIs. For the first few years, most of the activity came from budgeting apps and lenders reading transaction histories. It was useful, but it hardly looked like a change in how people bank.

That picture has shifted. In July 2025, Open Banking Limited counted 15.1 million users, which it described as nearly one in three UK adults and a 34% rise in a single year. By July 2026, the ecosystem had passed one billion open banking payments and 100 billion API calls since launch.

Open Banking Limited counts users as connections to the brands that report them, not as unique individuals. So the true number of people is probably somewhat lower. Even so, the direction is hard to argue with.

From reading data to moving money

The more telling change is in what people use open banking for. In 2021, account information services made up 75% of users. By mid-2025, payment initiation users had become the majority, at 55%. In June 2026 alone, there were 40.16 million open banking payments, and variable recurring payments were growing month on month.

Variable recurring payments let a person give a provider permission to take payments within agreed limits, without approving each one. Today they are mostly used for moving money between a person's own accounts. Many in the industry expect them to compete with direct debits and stored card payments over time, though how quickly that happens is still an open question.

What this means is that money is increasingly leaving bank accounts on instructions that never pass through the bank's own app. A person might pay a utility bill, top up an investment account or move savings around without opening their banking app at all.

And yet the bank is still responsible for that account. It still carries much of the fraud risk, still handles the complaint when something goes wrong, and still has to answer the question "where did my money go?"

What banks need to get right

So how should a bank respond when it is no longer the only front door to its own accounts? A few areas stand out.

API performance now counts as service quality. In June 2026, the average provider response time for payment requests was 349 milliseconds. A bank whose APIs are slow or unreliable will see payments fail in someone else's app, and the person paying will usually blame the bank. The load is only growing, too. June 2026 saw 2.81 billion API calls, the highest monthly figure on record.

Consent needs to be visible. People should be able to see, in one place, which third parties can access their account and cancel that access easily.

Fraud monitoring has to cover account-to-account payments as closely as card payments, since open banking transactions move fast and leave little time to step in.

Banks can also use open banking themselves. Showing a person's accounts from other providers inside the bank's own app is one obvious example, and it gives the bank a fuller picture of that person's finances.

Good digital banking solutions treat all of this as one connected experience rather than a compliance project bolted on beside the app. The APIs, the consent screens, the fraud rules and the app itself have to work as a single system.

The front door has moved

Truth be told, most people using open banking don't know they are using it. They just know that paying a bill or linking an account was easy. For banks, the work is to make sure that holds up every time, including when the payment starts in an app they didn't build.

Author - Shefali Vasave

Shefali manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.

What the October 2025 AWS Outage Told Banks About Cloud Concentration Risk

Derek Francis — Mon, 09 Nov 2026 10:12:03 +0000

On the morning of 20 October 2025, people who bank with Lloyds Bank, Halifax and Bank of Scotland found their apps and online banking playing up. None of the three banks had a fault of its own. The trouble sat with Amazon Web Services, which pointed to a problem on some of its US servers. Services came back online later that day.

The outage took down a long list of apps and websites around the world, so banks were only one part of the story. But they are the part regulators care about most. GlobalData estimated that up to 25% of UK consumers hold an account with Lloyds or its subsidiary brands. That is a lot of people affected by a fault in another company's data centre on another continent.

So should banks be worried about the cloud? Not exactly. They should be worried about how they use it.

Concentration is the real exposure

Large cloud providers generally run more resilient infrastructure than most banks could build on their own. The issue is concentration. When a big share of the financial system relies on a handful of providers, and individual banks put critical services in a single region of a single provider, a local fault can become a national banking outage.

European regulators have been working on this for a while. The Digital Operational Resilience Act, better known as DORA, began applying in January 2025. In November 2025, the three European Supervisory Authorities published their first list of 19 critical ICT third-party providers to the financial system, and Amazon Web Services, Google Cloud and Microsoft were all on it. Those providers now face direct oversight of their governance, risk management and resilience.

That oversight helps. But it doesn't move accountability away from the banks. A bank still has to show that its own important services can keep going when a provider has a bad day.

Resilience is decided at design time

How a bank fares in an outage like this is mostly settled long before the outage begins. Where do the workloads run? How many regions do they span? What happens to the mobile app when one dependency stops responding?

A few design decisions make a real difference.

Spread critical services across more than one region, and test failover regularly instead of once a year. A failover plan that has never run under real load is closer to a hope than a plan.

Map dependencies properly. An app may run in several regions while quietly relying on an identity service, a database or a DNS setting that sits in only one.

Design for partial service. If a balance check works but a payment can't be made, the app should say so clearly. People cope much better with a limited service than with a screen that just keeps loading.

Consider multi-cloud only where it earns its cost. Running the same service across two providers adds complexity, and complexity causes outages of its own. For many banks, a well-built multi-region setup on one provider is a sounder place to start.

This is the kind of work that good cloud engineering services concentrate on. Moving workloads to the cloud is the easier half of the job. Building them so they degrade gracefully when part of the cloud goes dark is harder, and it matters a great deal more on a day like 20 October.

A better question for the board

After the outage, plenty of bank boards will have asked whether something similar could happen to them. The answer is almost certainly yes, so a narrower question is more useful. Which of our important business services would stop if one region of one provider went down for six hours, and how do we know?

If the answer comes from a recent test, the bank is in a decent position. If it comes from an architecture diagram, there is still work to do.

Author - Shefali Vasave

Banks Finished the ISO 20022 Switch. The Harder Work Starts Now.

Derek Francis — Mon, 09 Nov 2026 10:10:10 +0000

On 22 November 2025, Swift ended the coexistence period between its old MT message formats and ISO 20022 for cross-border payments. The industry agreed to adopt the standard back in 2018, and the coexistence window itself had been open since March 2023. Just before Swift announced the switch was complete, it saw 97% of payment instructions on its network being sent in ISO 20022.

So the migration is done. Or is it?

Sending a message in a new format is one job. Using the data inside it is another, and on that second job a lot of banks are still near the starting line.

Why the richer data matters

The old MT messages were designed around tight field limits and free text. Names, addresses and remittance details were often squeezed into a few lines, with little agreement on what went where. ISO 20022 replaces that with structured fields. An address can be split into street, town and country. The purpose of a payment can carry a code. Remittance information can hold far more detail than before.

When the switch was completed, Swift's chief operations officer Jerome Piens called this structured data "foundational to the future of payments". That is a fair description. Better-structured data should mean fewer false positives in sanctions screening and fewer payments stuck in manual repair queues. It should also mean easier reconciliation for corporate clients who want to match incoming money against invoices.

But none of that happens by itself.

Where the value gets lost

Many banks met the deadline by putting a translation layer in front of their existing systems. Messages arrive in ISO 20022, get converted into whatever format the core payments engine, the screening tool or the data warehouse already understands, and carry on from there. It was a sensible way to hit a hard date. It also means the richer data can be squeezed back into old field structures before anyone downstream gets to use it.

Swift itself offered a contingency service to convert remaining MT instructions into ISO 20022 after the cutover. That tells you how uneven readiness was across the network.

The result is a bank that speaks the new language at the edge and the old one everywhere else. Screening teams still look at truncated name fields. Analysts still can't query purpose codes because the warehouse never stored them. And the business case that justified years of migration work stays mostly on paper.

What fixing it involves

Most of the remaining work sits in the data layer rather than the messaging layer.

It starts with keeping the full message. Store the ISO 20022 payload in its structured form alongside whatever legacy record the core system needs, so nothing is thrown away at the point of entry. From there, teams can build pipelines that send specific fields to the systems that need them. Structured addresses go to screening, purpose codes go to analytics, and remittance details go to reconciliation.

Data quality checks belong at that same entry point. Counterparties will keep sending incomplete or badly populated messages for some time. It helps to know which correspondents do this before their payments land in a repair queue.

Banks without the in-house capacity often bring in specialist data engineering services for this groundwork. The tricky part is designing data models and pipelines that will still hold up as more domestic payment schemes adopt the same standard.

Does every system need rebuilding at once? No. A more practical route is to pick one use case with a cost you can measure, such as manual repairs or screening false positives, and work out which ISO 20022 fields would bring it down. Then make sure those fields survive all the way to the system that needs them.

The deadline was only the start

Swift's network links more than 11,500 institutions and corporates in over 200 countries and territories, and all of them now exchange payment instructions in the same structured standard. The banks that get the most out of it will be the ones that saw 22 November 2025 as the day their payment data finally became usable. Then they went and used it.

Author - Shefali Vasave

What UPI Taught Indian Account Holders to Expect From Their Bank

Derek Francis — Thu, 08 Oct 2026 09:42:13 +0000

On 11 April 2016, the National Payments Corporation of India launched the Unified Payments Interface under the oversight of the Reserve Bank of India. In its first full financial year, UPI handled about 2 crore transactions. In FY 2025-26, it handled more than 24,000 crore, which works out to roughly 241 billion payments. In May 2026 alone, it processed a record 23.2 billion transactions.

Numbers like these are easy to admire and move past. But they describe something more personal than a payments network. They describe a change in what millions of people now consider normal when they deal with money.

And that change lands squarely on banks.

The benchmark moved, and it moved outside the bank

A decade ago, most people judged their bank against other banks. Today they judge it against the experience of scanning a QR code at a vegetable stall and seeing the payment go through in seconds.

Much of that experience also happens outside the bank's own app. NPCI data shows that third-party apps such as PhonePe and Google Pay handle the majority of UPI volume. The account still sits with the bank, but the daily interaction often does not.

So what is left for the bank to own? Quite a lot, as it happens. It just looks different from what it used to.

Where account holders now notice their bank

People rarely notice their bank when a payment works. They notice it when something goes wrong. A debit that shows up without the payment reaching the merchant, a refund that takes days, a fraud alert that arrives too late or a login that fails during a festival sale are the moments that shape how someone feels about the bank that holds their money.

These are also the moments that expose the bank's back end. High availability during peak hours, clear status on every transaction and a dispute process that resolves quickly all depend on core systems, integration layers and operations teams working together. A polished mobile interface cannot hide a slow reconciliation process for long.

What digital banking has to deliver now

Good digital banking solutions start from these moments of friction rather than from a feature list. A few areas tend to matter most.

Reliability comes first. When a large share of a country's retail payments runs through real-time rails, every minute of downtime affects people buying groceries and paying rent.

Failure handling matters nearly as much. Account holders are far more forgiving of a failed transaction when they can see what happened and when the money will come back. A clear message and a firm timeline do more for trust than an apology email sent a week later.

Fraud controls need to be tight without getting in the way. Real-time payments leave very little time to intervene, so detection has to happen during the transaction and not after it.

Onboarding and servicing should work end to end on a phone, including for people who are new to formal banking and may not read English comfortably.

Personalisation is the area where banks still hold an edge over payment apps. Banks see the full financial picture, from salary credits to loan repayments to deposits. Used responsibly and with consent, that view can support genuinely useful services such as timely credit offers or savings nudges.

A decade in, the bar keeps rising

UPI turned ten this year. The expectations it created are not going to relax, and newer features keep adding to them. Banks that treat digital banking as a front-end project will keep feeling a step behind. The ones that fix what sits underneath the app are the ones account holders will stop noticing, which in banking is usually a compliment.

Author - Shefali Vasave

What the TSB Migration Still Teaches Banks About Transformation

Derek Francis — Thu, 08 Oct 2026 07:47:35 +0000

In April 2018, the UK lender TSB moved its operations onto a new IT platform as part of its separation from Lloyds Banking Group. The data itself migrated successfully. The platform did not hold up. Branch, telephone, online and mobile banking were all affected, and a significant share of TSB's 5.2 million account holders ran into problems.

The bank did not return to normal operations until December 2018. TSB paid £32.7 million in compensation, and in December 2022 the Financial Conduct Authority and the Prudential Regulation Authority fined it a combined £48.65 million. The regulators found that TSB had failed to organise and control the migration adequately, and that it had failed to manage the operational risks arising from its outsourcing arrangements.

Eight years later, the case is still worth studying closely. Why? Because most of the failures came down to planning, governance and risk decisions that any bank could make again.

Moving data is only part of moving a bank

The detail that the data migrated successfully is easy to skip past. It shouldn't be. It shows that a transformation program can hit its technical milestones and still let down the people it exists to serve. A migration plan that tracks records moved and test cases passed can look green right up to the moment account holders try to log in.

So the more useful question for any program is whether the bank can still serve its account holders on the first day, under real load, across every channel. That is a harder test to design. It is also the one that decides whether the program succeeded.

Third parties do not carry the accountability

TSB relied on a critical third-party supplier for the migration. The regulators found fault with how the bank managed that relationship. In 2023, the PRA separately fined TSB's former chief information officer for failing to take reasonable steps to oversee the outsourcing arrangement.

This is an uncomfortable point for many banks, because so much transformation work is now delivered through partners. A bank can hand the build to a supplier, but supervisors will still hold the bank responsible for what happens to its account holders. Boards need evidence that a supplier is ready. Assurances are not enough.

Concentrated risk needs a way back

Any cutover that moves everything at once concentrates the risk into a very short window. Phased approaches take longer and cost more to run, because old and new systems have to operate side by side for a while. But they let a bank find problems with a small group of users before those problems reach millions.

Where a single cutover is unavoidable, the rollback plan deserves as much attention as the go-live plan. Who decides to reverse the change, and on what evidence? If that question has no clear answer before the weekend starts, it will not get a good one during it.

What this means for transformation work today

Most banks are in the middle of some kind of change, whether that means moving workloads to the cloud, replacing a core banking system or rebuilding their digital channels. Sound digital transformation for financial services starts from the account holder and works backward. It asks what the bank must never stop doing during the change, and it plans the technology around that.

A few habits make a real difference. Test with production-scale volumes and realistic user behaviour, not tidy samples. Define rollback criteria before go-live and give a named person the authority to use them. Put supplier readiness under the same scrutiny as internal readiness. And report progress to the board in terms of service risk rather than delivery milestones alone.

The final notices from both regulators are public documents. They make better reading for a transformation steering committee than most slide decks do.

Author - Shefali Vasave

Thirteen Years After BCBS 239, Why Is Bank Risk Data Still So Hard to Trust?

Derek Francis — Thu, 08 Oct 2026 07:34:59 +0000

In January 2013, the Basel Committee on Banking Supervision published a set of principles on how banks should aggregate and report risk data. The document became known as BCBS 239. It grew out of an uncomfortable lesson from the 2008 crisis, when many large banks could not tell their own boards, quickly and accurately, how exposed they were to a single counterparty.

Global systemically important banks were expected to comply by 2016. When the Basel Committee published its progress report in November 2023, it found that only two of the 31 banks it assessed were fully compliant. No single principle had been fully implemented across all of them.

So what is going wrong? These are some of the best-funded institutions in the world. Money is clearly not the missing ingredient.

The problem sits underneath the reports

The Basel Committee pointed to fragmented IT estates, legacy systems and manual processes as the main reasons for slow progress.

A risk report is only the last link in a long chain. Data starts life in a loan origination system, a trading book, a card processor or a treasury application. Each of these systems was usually bought or built at a different time, for a different purpose, by a different team. They often define a borrower, a counterparty or an exposure in slightly different ways. And every time data moves from one of them into a central store, somebody has written a transformation that decides how those differences get resolved.

Multiply that by hundreds of source systems and a few decades of mergers. You end up with a data estate where nobody can say with confidence why a figure in a board pack differs from the same figure in a regulatory return.

Where the gaps usually show up

Banks that struggle with risk data tend to share a few patterns.

Lineage is missing, or it lives in people's heads. When an auditor asks where a figure came from, the answer depends on which analyst happens to be on leave that week.

Reconciliation is done by hand. Spreadsheets bridge the gap between systems that were never designed to agree, and each spreadsheet quietly becomes a small, undocumented system of its own.

Ownership is unclear. The business assumes technology owns data quality, while technology assumes the business owns the definitions. So nobody owns the outcome.

Timeliness suffers under stress. A report that takes days to assemble in normal conditions is of little use in a crisis, which is exactly when supervisors want it.

What good data engineering changes

This is where disciplined data engineering services earn their keep. It involves building pipelines that record lineage automatically, so every figure can be traced back to its source without a detective hunt. It means agreeing on shared definitions for critical data elements and enforcing those definitions in code rather than in policy documents that few people read.

It also means running quality checks at the point where data enters a pipeline, not at the end where a report fails. A missing counterparty identifier is cheap to fix at ingestion. By the time it reaches a capital calculation, it has already done its damage.

Does all of this require rebuilding the data estate from scratch? Usually it does not. A more practical route is to pick the handful of risk measures that matter most to the board and the supervisor, trace every input behind them end to end, and fix what turns up.

Why this matters beyond compliance

Banks now want to use machine learning in credit decisions, fraud detection and liquidity forecasting. Every one of those models depends on the same data that BCBS 239 was written to protect. A model trained on inconsistent and poorly traced data will produce decisions that are hard to explain, and supervisors are unlikely to accept that for long.

The groundwork BCBS 239 asks for turns out to be the same groundwork that any serious AI program inside a bank will need. Banks that have already done it will find the next few years a lot less painful than the ones that treated it as a reporting exercise.

Author - Shefali Vasave

Six Years In, Cloud Waste Is Still the Number One Job

Derek Francis — Sun, 06 Sep 2026 18:31:39 +0000

"First they asked us to fix cloud. Then fix the software mess. Now it’s fix the contract and license mess, now fix the data center."

That is a practitioner quoted in the FinOps Foundation’s State of FinOps 2026 report, and it is a fair summary of what has happened to the discipline. The survey behind it collected responses from 1,192 practitioners who together account for more than $83 billion in annual cloud spend, spread across EMEA, North America, Asia Pacific and South and Central America.

After six annual editions of tooling, certification, dashboards and vendor consolidation, the single top priority reported by those practitioners is still workload optimisation and waste reduction. The same thing it was in 2020.

That deserves a moment of honesty. If the top problem has not shifted in six years, the approach to it probably needs to.

Why waste keeps coming back

Why does the same problem survive six years of sustained attention? Because waste is not a one-time cleanup. It is a byproduct of how software gets built. Every sprint creates new resources and only some sprints remove old ones. An environment spun up for a load test in March is still running in September because nobody remembers whose it was, and the person who created it moved teams in May.

Dashboards make this visible. They do not make it stop. The organisations that genuinely bend the curve move the decision left, into the moment infrastructure gets defined rather than the moment the bill arrives. In practice that means budget limits enforced in the pipeline, mandatory ownership tags that fail a deployment when they are missing, and automatic expiry on anything created outside production.

Firms that bring in Cloud Engineering Services for this reason are usually not buying another cost report. They are buying the guardrails that make the report boring.

AI arrived faster than anyone planned for

Here is the most striking movement in the 2026 data. 98 percent of respondents now manage AI spend. Two years ago that figure was 31 percent.

Have you seen a cost category move that fast before? A line item that barely existed is now near-universal, FinOps for AI is the top forward-looking priority for the coming twelve months, and AI cost management is the skill practitioners most want to build.

AI spend also behaves differently from ordinary compute. It is bursty, it is often billed per token or per request rather than per hour, and the people generating the cost are frequently not the people who understand the pricing model. So the familiar playbook of reserved instances and rightsizing does not map cleanly onto it.

The remit keeps widening

The survey shows scope expanding well past public cloud. 90 percent of respondents now manage SaaS or plan to, up 25 points. 64 percent manage licensing. 57 percent manage private cloud and 48 percent manage data centre spend. 28 percent have been handed labour costs as well.

Is that scope creep or seniority? A bit of both. 78 percent of these teams now report to a CTO or CIO, up 18 points against 2023, and teams with VP-level engagement carry two to four times more influence over technology selection.

Where to start if you are behind

Pick your three largest cost centres and find out who owns each one by name. Then make one change in the pipeline instead of one more change in a dashboard. Ownership tags enforced at deploy time will do more for next quarter’s bill than any number of weekly cost reviews.

And if your AI spend is still landing on a general compute line, split it out now. You will want the history when someone asks why it tripled.

About Author

Shefali Vasave

Your Pipelines Got Faster. Your Checks Did Not.

Derek Francis — Sun, 06 Sep 2026 18:31:14 +0000

Two numbers from the same survey sit a page apart and tell opposite stories. 72 percent of data teams say they are prioritising AI-assisted coding in their development workflow. Only 24 percent say they are prioritising AI-assisted pipeline management, which covers testing, observability and everything else that tells you when a pipeline broke.

Both figures come from the State of Analytics Engineering report that dbt Labs published in April 2026, based on 363 data professionals surveyed between late 2025 and early 2026.

So the writing got faster and the checking did not. You can probably guess what happens next.

The same report found that 71 percent of data professionals named incorrect or hallucinated outputs reaching stakeholders as a top concern. That worry is rational. When a team triples the number of models it ships in a quarter without touching its test coverage, the failure rate per model stays flat while the absolute number of failures climbs.

Trust went up, which is the strange part

Here is the finding that complicates the story. Trust in data jumped from 66 percent to 83 percent year on year, the largest single-year rise the report has recorded, and speed as a stated priority climbed from 50 percent to 71 percent over the same period.

What do you get when you read those together? An organisation that is moving faster, feels better about its data, and has fewer people watching the pipes. That combination has a shelf life.

Ownership is the quiet failure

41 percent of organisations in the survey reported ambiguous data ownership. This is the one that rarely appears in a postmortem but sits underneath most of them.

Ask a plain question inside your own company. When the revenue dashboard is wrong on a Monday morning, who is expected to notice, and who is expected to fix it? If the honest answer is "whoever gets pinged first", you do not have an ownership model. You have a rota that happens to hold while nothing serious breaks.

Ambiguity here is expensive because it delays detection, not because it delays repair. Repair is usually quick. Detection is what takes three days.

The budget squeeze is real

One more pair of numbers from the report. 57 percent of respondents reported increased warehouse and compute spending, while only 36 percent reported increased team budgets. That means more data, more models and more compute handled by roughly the same number of engineers.

This is the pressure that has pushed a lot of organisations toward external Data Engineering Services for the unglamorous layer, meaning contracts and tests on critical tables, freshness monitoring, lineage a non-engineer can actually read, and ownership records that survive someone changing jobs.

What to do this quarter

Start with your five most-viewed dashboards and trace every table that feeds them. Put a test on each one. Nothing elaborate, just a not-null check, a row-count range and a freshness threshold.

Then name an owner for each of those tables. Name a person, not a team.

Lastly, measure how long it takes you to notice a break rather than how long it takes to fix one. Most teams have never measured the first number and are quietly shocked when they finally do.

None of this is exciting work. It does not demo well and it will never earn a slide in the quarterly review. But it is the difference between a data team that gets faster and a data team that only gets louder.

May your freshness checks fire before your CFO does.

About Author

Shefali Vasave

The 18 Percent Problem in Banking AI

Derek Francis — Sun, 06 Sep 2026 18:30:16 +0000

On 24 June 2026, Personetics published a survey of 902 banking professionals drawn from more than 30 countries. Close to 80 percent of them described fully operationalised generative AI as significant or transformational for their institution. Only 18 percent said the technology was actually running inside day-to-day operations.

That distance between belief and practice is the real state of AI in banking today. Almost everyone is convinced. Very few have shipped.

So what is holding the other 82 percent back? The same survey points at something far less interesting than model architecture. 56 percent named data silos between business lines as a major barrier, and 31 percent said their hardest challenge was keeping AI outputs accurate and compliant. Neither of those gets solved by a better model.

The bottleneck sits below the model

Consider what a single personalised offer has to touch inside a retail bank. Core banking, the card processor, the mortgage book, the CRM, the consent register and the marketing suppression list. Each of those systems was bought in a different decade by a different team working from a different definition of "customer", and none of them were designed on the assumption that a language model would one day need to read all six at once and then explain its reasoning to a regulator.

Personetics found that the average institution takes 12 weeks to move a personalised offer from concept to launch. Twelve weeks. That number has very little to do with AI capability and almost everything to do with how long it takes six systems to agree on who the customer is.

This is why the institutions doing well here look unglamorous from the outside. Teams that build Enterprise AI solutions for financial services that survive an audit tend to spend their first months on entitlements, lineage, retention rules and a single customer definition, long before anyone argues about which model to use.

The regulatory clock moved, but not by much

Europe handed out a small reprieve this year. On 6 May 2026 the EU institutions reached a provisional political agreement on the Digital Omnibus package, confirmed by member states on 13 May, which pushes compliance for stand-alone high-risk systems under Annex III of the AI Act from 2 August 2026 out to 2 December 2027. AI embedded in regulated products moves to 2 August 2028.

Does that buy banks breathing room? A little. But those changes only take legal effect once the Omnibus is formally adopted and published in the Official Journal, and 2 August 2026 remains live for the Article 50 transparency obligations, which is where most customer-facing banking use cases sit anyway.

Truth be told, sixteen extra months is not much when the obstacle is a data estate assembled over three decades.

What the leaders actually did

So what separates the institutions in production from the ones still demoing? Three habits keep showing up.

They picked one workflow and finished it. A narrow, well-instrumented use case in collections or complaint handling beats nine simultaneous pilots that all stall at legal review.

They wrote down what "wrong" looks like before launch. Accuracy is not a feeling. If you cannot describe the failure you are watching for, your monitoring will not catch it.

And they gave the work an owner with a budget. Innovation teams produce demos. Line-of-business owners produce systems that people actually use on a Monday morning.

Yes, none of this is new advice. It is roughly the same advice that applied to data warehousing in 2010 and to mobile banking in 2015, which is probably why it keeps getting skipped.

The 18 percent are not smarter than everyone else. They just started at the boring end.

About Author

Shefali Vasave

Modernizing Legacy Core Platform Without Disruption

Derek Francis — Fri, 07 Aug 2026 09:10:31 +0000

Core banking and payment platforms rarely die. That is the whole difficulty. A switch installed in the 1990s will keep authorising transactions long after the people who configured it have collected their pensions. It does not fall over. It just makes everything around it slower.

The tax that appears on no invoice

Legacy platform cost is mostly indirect, which is exactly why it survives budget season.

The direct costs are visible enough. Licences, specialised hardware, contractors who still know the language. Those get scrutinised every year and survive because replacing them looks expensive by comparison.

The indirect costs never appear as a line item. A new product takes eleven months instead of three because the core cannot represent the data model. A partner integration needs a custom file transfer because the platform has no usable API. Compliance reporting requires people reconciling extracts by hand because the system was never built to answer that question.

Each of those lands in someone else's budget. Added together they usually exceed the platform's running cost. Nobody adds them together.

Standards move whether you do or not

Then there is external pressure. Payment messaging standards have shifted toward richer, structured formats. Real-time settlement is now an expectation rather than a premium feature. Regulators increasingly ask for data that older schemas simply do not carry.

A platform that cannot represent structured remittance information or extended party detail does not fail a mandate loudly. It fails quietly, by requiring workarounds: mapping layers, truncation rules, manual exception queues. The workarounds become permanent.

Eventually they become the thing that has to be modernised too.

Why big-bang replacement keeps disappointing

The clean answer is to replace the platform outright. Buy or build something modern, migrate, decommission the old one.

Programs like this have a poor record, and not because the technology is hard. They struggle because the old system's behaviour was never fully documented. Twenty years of edge cases live in code nobody has read end to end. Every one of them was a real business requirement once. You find out which ones still matter during a cutover weekend, which is the worst possible time to find out.

They also outlast the organisation's attention span. Sponsors change. Priorities move. A four-year program with nothing visible until year three is a program waiting to be cancelled by someone who was not in the room when it was approved.

Phased, boring, effective

The approach that tends to work is considerably less dramatic. Put an API layer in front of the core so new products stop depending on its internals. Move the capabilities that change most often out first, running old and new in parallel until the new path has earned trust. Instrument everything, because you cannot safely change what you cannot observe.

Most platform modernization services follow some version of that sequence: assess and prioritise, design the target architecture, then migrate capability by capability instead of all at once. Slower on paper. Finishes more often.

The other benefit is optionality. Each phase delivers something usable on its own. If funding shifts or leadership changes, you are left with real improvements rather than a half-migrated estate and an awkward status report.

Start with the knowledge of the current system

If there is one thing worth doing before any of the engineering, it is capturing what the current system actually does. Not what the design documents claim it does. What it does, including the parts that look like bugs and turn out to be deliberate.

That work is tedious and gets no applause, and it is often the difference between a modernization that lands and one that gets written off. The people holding that knowledge are, in most institutions, closer to retirement than to their next promotion.
Ask them now, while asking is still an option.

About Author

Derek Francis

Derek manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.

Why Cloud Migration Bills Go Up Instead of Down

Derek Francis — Fri, 07 Aug 2026 08:33:21 +0000

Most cloud programs in banking begin with a savings number. Somebody models the current infrastructure spend, applies a percentage, and the business case gets signed. Two years later the workloads have moved and the monthly invoice is higher than the data centre it replaced.

Nobody lied in the business case. The math was just applied to the wrong variable.

Simply Moving Servers is Not Modernizing

The quickest way into the cloud is to pick up what you have and set it down somewhere else. Same application, same database, same architecture, different landlord. Projects that take this route usually finish close to schedule, which keeps everyone happy right up until the first full quarter of billing.

Here is the mechanic behind it. On premises, a server running at 12 percent utilisation at three in the morning costs nothing extra. You already bought it. The waste is invisible because it was capitalised years ago. In the cloud, that same idle capacity bills by the hour, every hour, indefinitely.

Autoscaling is supposed to solve this. It only works if the application can genuinely run on two instances overnight and forty at peak. A monolithic card management system written in 2004 cannot. It was designed for a world where scaling meant ordering a bigger box and waiting six weeks for delivery.

So a workload that was quietly inefficient in the data centre becomes an inefficiency you now pay for, line by line, on a statement someone in finance reads every month.

The Rising Bills Due to Unattributed Spend

Then there is the operating side. On-premises, a small number of people controlled provisioning, and getting new capacity meant asking them. In the cloud, a development team can spin up an environment on a Tuesday afternoon and forget it exists. Multiply that across forty teams and the rounding error stops being a rounding error.

Untagged resources are the usual culprit. If you cannot attribute spend to a team or a product, you cannot credibly ask anyone to reduce it. Finance sees one large number, engineering sees no signal, and the conversation goes nowhere for another quarter.
Storage tiering is the other one. Transaction logs that must be retained for seven years sit in hot storage because nobody wrote a lifecycle policy. That is a configuration choice, not a cloud problem, and fixing it is often worth more than any renegotiation with the provider.

Doing It The Right Way

The institutions that get this right tend to do three fairly unglamorous things.
They assess before they move. Which applications benefit from elasticity, which are fine where they are, and which should be switched off rather than migrated. A surprising share of most legacy estates consists of systems nobody has logged into in years.

Migrating those is pure cost transfer with extra project risk.

They pick refactoring targets deliberately. Not everything needs to become microservices. Usually a handful of components drive most of the compute cost and most of the release friction, and those are the ones worth breaking apart first. The rest can stay as they are until there is a reason to touch them. This sequencing is broadly why structured cloud modernization services open with a readiness assessment and a total cost of ownership model rather than a migration calendar.

And they give cost an owner. Someone reviews the number monthly and has the authority to turn things off. Without that, optimisation happens once, gets celebrated, and then decays over the following year.

The Uncomfortable Truth

Cloud economics only work when the software above them is built to take advantage of them. Elastic infrastructure underneath rigid applications gives you the cost profile of renting with none of the flexibility of owning.

That is a harder conversation than a migration timeline, because it means conceding the application portfolio needs work and not just the hosting arrangement. It is also the conversation that decides whether year two of the program reads better than year one.

Migration is a project. Cost efficiency is a habit. Programs that confuse the two end up explaining an invoice to a CFO who was promised the opposite.

About Author

Derek Francis

Why Reliable Software Can Still Slow Your Team Down

Derek Francis — Fri, 07 Aug 2026 08:25:15 +0000

Ask a payments team which of their applications causes the most trouble and you will sometimes get an odd answer. Not the one that breaks. The one that never breaks.
There is usually a system somewhere in the estate that has run without incident for years. It processes exactly what it is supposed to process. It has never caused an outage. And when a product manager asks for a modest change to it, the estimate comes back in months.

That gap between “it works” and “we can change it” is where a lot of engineering budget quietly disappears.

Reliability and changeability are different properties

Software can be extremely dependable and extremely rigid at the same time. It usually gets that way honestly. Every urgent fix, every regulator-driven patch, every acquisition whose data had to be mapped in over a weekend, all of it left a layer behind. None of those decisions were wrong at the time. The accumulation is the problem.

The symptoms are recognisable. A change to one module triggers regression testing across six others because nobody is confident about the coupling. Business logic lives in three places and the team disagrees about which one is authoritative. The test suite covers the paths that were easy to test rather than the ones that carry money.

None of this appears in an uptime report. It appears in the roadmap, as items that keep getting moved to next quarter.

The knowledge problem underneath

Then there is the human side. The people who built the system have moved on. What remains is documentation written for a version that no longer exists and two or three engineers who understand the thing by memory rather than by reading it.

This creates a bottleneck that compounds. Every change routes through the same small group. Onboarding a new engineer takes months because the knowledge is not written anywhere useful. And those engineers know they are indispensable, which is not a comfortable position for them either.

Teams often treat this as a staffing issue. It is an architecture issue wearing a staffing costume. Systems that are hard to reason about require specialists. Systems with clear boundaries and honest tests can be worked on by anyone competent.

So what’s the solution?

The instinct is to rewrite. Occasionally that is the right call. More often it becomes a two-year program that runs out of political capital in month fourteen, leaving you maintaining two systems instead of one.

The less satisfying alternative works more reliably. Find the parts of the codebase that change most frequently and improve those first. Wrap the stable parts in interfaces so callers stop depending on internals. Write tests around behaviour you are about to change rather than around everything. Extract one capability at a time and prove the pattern before scaling it across the estate.

That is the working logic behind most application engineering services engagements: concentrate effort on the code paths that carry delivery risk, and leave the rest alone until there is a reason to disturb it.

One more thing, frequently skipped: make deployment cheap. Teams instinctively avoid changing systems that are painful to release. Fix the release pipeline and some of the appetite for change comes back on its own, without anyone being told to be braver.

The metric that matters

Uptime tells you the system is running. It tells you nothing about whether the business can get what it needs out of it.
A better question for a quarterly review: how long does it take to get a small, well-understood change into production? If the answer is weeks, that number is your actual constraint, no matter how green the dashboards look.

Stable software that resists change is not an asset holding steady. It is an asset turning into a liability on a timeline nobody is tracking.

About Author

Derek Francis