The Sequencing Problem: Why 2026 Will Punish Misinvestment, Not Underinvestment

The biggest technology risk facing banks, financial services and insurers in 2026 is not moving too slowly. It is building on foundations that were never designed to carry the load.

Every bank and insurer is working through the same menu right now: AI copilots, real-time payments capability, forecasting platforms, reconciliation engines, workflow automation, and agentic tooling. The options have never been more numerous, and the pressure to act on them has never been higher.

The instinct is to treat this as a race, to worry about falling behind. But in regulated financial services, the more consequential failure mode runs in the opposite direction. It is misinvestment, not underinvestment: capable technology, correctly built, layered onto operational and data foundations that cannot support it. For institutions operating under regulatory scrutiny, with legacy core systems and decades of accumulated data debt, that distinction is not a nuance. It is the difference between technology spend that compounds and technology spend that has to be quietly unwound two years later, at a greater cost than if it had never been made.

Getting the sequence wrong is not a missed opportunity. It is automation that produces confident-looking outputs nobody can actually trust, sitting inside a control environment that looks modernised on a slide but isn't modernised in practice.

‍

Why 2026 Is the Year This Stops Being Theoretical

This isn't an abstract risk. In January 2026, the PRA published its final Basel 3.1 rules (PS1/26), confirming a 1 January 2027 go-live for UK banks. Insurers face their own version of this pressure through ongoing Solvency II reporting requirements and IFRS 17 implementation. The pattern is consistent across every regime: heavier, more granular reporting requirements landing on top of general ledgers, subledgers, and policy administration systems that were never built for this level of scrutiny.

Institutions now have to prove, not merely assert, that the numbers used to generate regulatory returns are traceable to their sources. A bank that has spent the past two years bolting forecasting and automation tools onto ungoverned data is about to find out, in a live regulatory context, whether that data can bear the weight. This is precisely why sequencing has stopped being a best-practice nicety and become a near-term operational risk.

‍

‍

The Sequencing Problem Is Bigger in Regulated Institutions Than Anywhere Else

Most industries can absorb a misjudged technology purchase. It gets shelved, written off, quietly replaced. Banks and insurers don't have that luxury. A reconciliation tool introduced before the underlying data is standardised doesn't simply underperform. It produces output that finance and risk teams can't rely on, which is arguably worse than having no tool at all. A forecasting layer built on fragmented general ledger or policy administration data doesn't accelerate decision-making. It automates the production of numbers that look precise but aren't.

We've seen this pattern directly: an insurer brought in a modern reserving and forecasting platform expecting faster quarter-end cycles. The rollout stalled for months, not because the software underperformed, but because premium was being defined three different ways across the systems feeding it, a discrepancy nobody had documented because each system's definition had made sense in isolation for years. The platform wasn't the problem. The absence of a single, owned, documented definition of premium was. No forecasting tool resolves that from above; it has to be fixed at the source before the tool goes anywhere near it.

This is what makes technology investment structurally harder to get right in financial services than almost anywhere else. The outputs of a misinvested platform don't stay contained to IT. They flow directly into regulatory returns, capital calculations, reserving, and board reporting. Getting the sequence wrong isn't a delay. It's exposure.

‍

‍

What "Data Readiness" Actually Means

Data readiness is one of the most used and least defined phrases in financial services technology conversations. In practice, for a bank or insurer, it means something specific:

• Transaction and policy data that carries consistent definitions across every system it passes through

• A general ledger that reconciles to the subledger without manual intervention

• Product, premium, and claims logic that is documented, rather than buried in code that predates most of the people maintaining it

• Integration between core systems and their downstream consumers that has actually been tested, not assumed

None of this is visible in a vendor demo, and it rarely produces a press release. But it's consistently the difference between an AI or automation investment that compounds and one that has to be quietly unwound eighteen months later. It's also where operational resilience is actually decided, not in the resilience testing exercise itself, but in whether data ownership is assigned rather than assumed, and whether business rules like interest calculation conventions and claims reserving logic are explicitly owned rather than silently inherited from one system generation to the next. An institution can run modern, well-architected systems and still be operationally fragile if the data moving through them depends on a small number of people who understand the exceptions.

‍

‍

Measuring Technology Returns Against the Right Baseline

The value of a technology investment in banking or insurance should be measured against the specific operational failure it was meant to fix, not against the platform's feature set. A reconciliation engine should be judged on how much it reduces unexplained breaks and how much faster the close reaches an auditable result. A workflow automation investment should be judged on cycle time and exception rates in the specific process it touches, not on activity volume. An AI or forecasting capability should be judged on whether the numbers it produces are ones the business is willing to act on without a manual sanity check first.

Institutions frequently struggle to answer this kind of question about technology they've already bought, which is itself a signal. If the measure wasn't defined before the purchase, the return can't be properly assessed afterwards, and the temptation is to justify the investment by its sophistication rather than its outcome. Defining the operational baseline before the vendor conversation starts is a small discipline with a large effect: it keeps the roadmap anchored to problems that are actually worth solving.

‍

‍

Automate the Repetitive Work First

The highest-value automation opportunity in most finance operations isn't the most visible one. It's the repetitive, rules-based work underneath it: transaction matching, data ingestion and normalisation, routine reconciliation, exception classification against known rules. Automating this layer well creates genuine capacity for the work that requires judgment: reserving decisions, scenario planning, risk assessment, and capital allocation.

When this gets inverted, when automation is applied to judgment-dependent decisions before it's been proven on the repetitive layer beneath them, the outcomes tend to fall into one of two failure modes. Either the technology produces outputs nobody trusts enough to act on, or it quietly removes human oversight from a decision that genuinely needed it.

‍

‍

What This Means for the Roadmap

None of this argues for moving slowly. Payment infrastructure, reconciliation platforms, and AI tooling are becoming genuinely interconnected in ways that create real advantage for institutions that sequence them correctly: cleaner data feeding more reliable forecasting, better reconciliation feeding a faster close, a faster close freeing capacity for higher-value analysis. That opportunity is real and growing. But it doesn't materialise without the groundwork underneath it.

For CFOs and COOs, the practical test heading into 2027 reporting cycles isn't how many AI pilots are running. It's whether every piece of technology spend can be traced back to a specific, measurable operational outcome, and whether the systems and data beneath it can actually carry the automation being layered on top. In regulated financial services, where the cost of getting the sequence wrong is an exposed control environment rather than a missed quarter, that discipline isn't optional. It's the entire job.

‍

About Digiata

Digiata is a financial technology partner with 25 years of experience in financial services transformation. Headquartered across Johannesburg, Cape Town, and London, we design and deliver reconciliation, data migration, and workflow automation solutions for banks, insurers, and wealth and asset managers. Our work starts where most technology roadmaps skip a step: getting the underlying data, definitions, and control frameworks into a state that can actually support the automation built on top of them.  

‍