The plumbing is solved. The intelligence layer is not.

For most of the past seven years, conversations about open banking have been dominated by a single question: does the data flow work? Can a licensed third-party provider reliably pull a consumer’s transaction history from a tier-one European bank, in real time, in a standardised format, without the connection failing mid-call? This was the defining concern of the PSD2 era, and for good reason. The early implementations were genuinely broken. API uptime varied wildly between institutions, schema interpretations drifted across borders, and fallback mechanisms existed mostly on paper.

That conversation is winding down. PSD3 and the Payment Services Regulation will close most of the remaining gaps in connectivity and performance. By the time FIDA enters full effect, extending data-sharing obligations beyond payment accounts to investments, insurance, and pensions, the pipes themselves will no longer be the bottleneck. The question of can we get the data will have been replaced by something more consequential: what do we actually do with it once it arrives?

This is where the current generation of financial data infrastructure falls short. Most institutions that built PSD2 integrations treated the resulting data as a compliance output rather than an operational input. Transaction feeds were routed into reporting systems, retained for the regulator, and occasionally surfaced to risk teams as batch reports. The promise of real-time financial intelligence — the ability to make credit decisions, detect fraud, personalise offers, or flag anomalies within seconds of a transaction settling — remained mostly theoretical.

What is changing in 2026 is that a new layer is being added above the open banking stack. This layer is not regulatory, not protocol, and not particularly visible to end users. It is an intelligence layer, typically built on a combination of machine learning models, large language models, and agentic workflows, and its job is to transform the raw output of open banking APIs into decisions, predictions, and actions that genuinely improve how financial services are delivered. The institutions that have begun building it are not announcing it loudly. But they are spending real money, and the commercial outcomes are starting to separate the early movers from everyone else.

What the AI layer actually does

To understand why this matters, it helps to be concrete about what the AI layer is doing in practice. The use cases fall into four broad categories, each of which has moved from experimental to operational in the last 18 months.

Real-time credit decisioning. Traditional credit assessment for SME lending involved a customer submitting bank statements as PDFs, a credit analyst manually extracting key figures, and a decision arriving days or weeks later. Modern platforms now ingest transaction data directly via open banking APIs, pass it through classification models that categorise every transaction with better than 95% accuracy, feed the structured output into cashflow and risk scoring algorithms, and return a credit decision in under 60 seconds. Some European neobanks have pushed this further and now underwrite working capital loans based entirely on live transaction feeds, with no documentary submission at all.

Continuous fraud detection. The batch-based fraud systems of the early 2020s are being replaced by streaming anomaly detection models that score every transaction in milliseconds against the account holder’s behavioural baseline. The baseline itself is continuously updated using unsupervised learning techniques, so the system adapts as customer patterns evolve. The difference in operational outcomes is significant. Batch systems catch fraud hours after it occurs. Streaming systems catch it during the transaction attempt, in time to block it.

Personal and business financial management at scale. The generation of PFM apps that emerged in 2017 and 2018 aggregated bank data but struggled to turn it into anything genuinely useful beyond a pretty dashboard. Today’s systems can generate natural-language financial summaries, proactively surface cashflow risks before they become crises, and draft scenario analyses that compare actual spend against multiple hypothetical alternatives. The underlying shift is from visualisation to explanation — and explanation requires the reasoning capabilities of modern language models, not just SQL queries against a transaction table.

Regulatory and compliance automation. Anti-money laundering investigations, transaction monitoring, suspicious activity reporting, and KYC refresh cycles are all processes where open banking data feeds into case management workflows that have historically required substantial human judgement. The AI layer is automating the first-pass triage of these cases, reducing the volume that reaches human analysts by 60 to 80 percent while maintaining or improving detection rates. For institutions facing rising compliance costs and struggling to recruit qualified staff, this has quickly become less of a competitive advantage and more of a survival requirement.

The build-versus-buy problem is worse than it looks

For a bank or fintech deciding how to build this AI layer, the classic options look familiar: hire a data science team internally, license a vendor platform, or partner with a specialist consultancy. In practice, all three are harder than they appear, and the institutions that have succeeded are usually the ones that figured out how to combine all three in proportions that reflect their actual constraints.

Pure in-house builds run into a talent bottleneck that has been intensifying for the past three years. Experienced ML engineers with financial services domain knowledge are among the most contested hires in European technology recruitment. Even institutions that have the budget to compete on salary often struggle to assemble a complete team quickly enough to matter. The window for deploying a useful fraud model is measured in quarters, not years, and a team that takes eighteen months to hit productivity has effectively missed the market it was built to serve.

Vendor platforms address the speed problem but introduce a different one. The leading AI platforms for financial services were designed to be general-purpose and, as a result, require substantial customisation to fit any specific institution’s data schema, risk appetite, and regulatory posture. The promised time-to-value of six weeks routinely stretches to nine months once the integration work begins. More worryingly, institutions that rely too heavily on a single vendor discover that they have outsourced not just the tooling but also the capability to evolve their models as market conditions change. When the vendor updates its platform or shifts its commercial terms, the bank’s AI strategy is effectively at the vendor’s discretion.

Specialist consultancies have emerged as the pragmatic middle path for institutions that want both the speed of an external partner and the knowledge transfer of an internal build. The model that works is not the traditional “body shop” approach in which consultants bill hours to implement a vendor’s platform. It is a smaller, more technically senior form of engagement in which a consultancy works alongside the institution’s own engineers to design the AI architecture, build initial models against the institution’s data, and then progressively hand over operational responsibility as the internal team matures. Done well, this produces a capability the institution actually owns, rather than one it rents.

The Nordic financial services corridor and its AI consultancy ecosystem

The geography of this consultancy market is worth paying attention to because it is not evenly distributed. London remains the largest single market for financial services AI consulting in Europe, driven by the concentration of tier-one banks and the long-standing density of technical talent in the City and Canary Wharf. But the second tier is no longer what it used to be. Frankfurt, Paris, and Amsterdam have all built credible AI consulting communities over the past five years, and the Nordic region has emerged as an unexpectedly significant hub for a specific type of work: hands-on, deeply technical, mid-sized engagements where the client is a Nordic bank, insurer, or fintech and the need is practical rather than strategic.

Stockholm is the best-known Nordic location, anchored by Klarna’s headquarters, the broader Swedish fintech scene, and an unusual density of venture-backed financial technology startups. But for institutions building serious data engineering and ML infrastructure, Göteborg has quietly become an equally important centre. The reasons are mostly structural. Göteborg is home to Volvo’s financial services arm, to Skandia’s technology operations, to parts of SEB’s engineering footprint, and to a growing population of mid-sized fintech and insurtech startups that have chosen the west coast for its cost structure and engineering talent density relative to Stockholm. The city’s universities — Chalmers and Göteborg University — produce a steady flow of ML and software engineering graduates who tend to stay in the region, and the surrounding industrial economy has historically supported the kind of rigorous systems engineering culture that serious financial infrastructure work requires.

For financial services institutions in the region that need help building an AI layer above their open banking integrations, the local consultancy ecosystem has matured considerably. A handful of specialised firms now offer the kind of hands-on technical engagement described earlier — working alongside internal engineering teams rather than replacing them. An AI konsult i Göteborg who actually understands the data architecture of a modern retail bank is a different proposition from a generic management consultant, and the best local practitioners have increasingly carved out a reputation for practical delivery that competes directly with firms based in Stockholm or London. For institutions whose cultural preference is to work with technical partners who can meet in person and who understand the Nordic regulatory environment in detail, this matters more than it might seem from the outside.

None of this is to suggest that Göteborg has somehow leapfrogged the larger European hubs. It has not. But the pattern of financial services AI work being distributed across multiple secondary centres, rather than concentrated in London, is a material shift that has implications for how institutions approach their partnership strategy. The best AI consultancy for a Göteborg-based bank is often not the biggest name in London. It is the small team that can be on-site within an hour, has built similar systems for similar institutions in the region, and has the technical depth to engage credibly with the client’s own engineers on day one.

What a well-designed engagement actually looks like

For the benefit of institutional readers evaluating their options, it is worth describing what a credible AI consultancy engagement looks like in 2026. The market is full of firms claiming capability they do not have, and the most expensive mistake an institution can make is to hire a partner that cannot deliver on its promises.

A well-designed engagement begins with a discovery phase that is genuinely technical. The consultancy spends time with the institution’s actual data — not presentation decks about the data, but the data itself, accessed via a secure environment. This phase typically lasts two to four weeks and produces a written assessment of data quality, schema coherence, integration gaps, and the realistic constraints on what can be built. Institutions that skip this step almost always regret it, because the assumptions a consultancy makes about data availability in a proposal rarely survive contact with reality.

The second phase is a focused pilot against a single, well-defined use case. The pilot should take six to twelve weeks, should use production data (ideally in a sandboxed environment), and should produce a working model that demonstrates measurable improvement over the institution’s current approach. Good consultancies insist on defining success metrics before the pilot begins and walking away if the results do not meet them. The pilots that fail are usually the ones that never had clear success criteria in the first place.

The third phase is the one that distinguishes lasting engagements from short-term fixes. A serious consultancy uses the pilot results to design a longer-term architecture that the institution can operate itself, and then commits to transferring knowledge to the client’s engineering team throughout the build. This is where the traditional consulting model breaks down, because the commercial incentives of a hours-based engagement point in the opposite direction — the consultancy makes more money by staying longer and doing more. Firms that are prepared to genuinely hand over ownership are rarer than they should be, and they are worth paying a premium for.

The fourth phase is operational support, which is where many engagements quietly fall apart. A model that works on the day it is deployed will not necessarily work six months later, because the underlying data distributions drift, the threat landscape evolves, and the institution’s own business priorities change. A good consultancy establishes an operational framework for monitoring model performance, retraining on new data, and adapting to changes in the regulatory environment. A bad one declares victory on deployment day and moves on to the next client.

The broader pattern: AI is becoming a core part of financial data infrastructure

Step back from the tactical questions of engagement design and a larger pattern becomes visible. The financial data infrastructure stack is developing a new layer, and the institutions that build it thoughtfully will separate themselves from those that do not. This is not an optional enhancement. It is the difference between being able to compete on service quality, cost structure, and speed of decision-making in the next five years, and being relegated to the commoditised end of the market where margins compress and switching costs erode.

The institutions that are getting this right share a few characteristics. They treat the AI layer as infrastructure rather than as a feature. They invest in data quality before they invest in models. They build small, senior teams rather than large generalist ones. They partner with external specialists for specific capabilities while keeping strategic ownership internal. And they resist the temptation to announce their work publicly, because the competitive advantage is cumulative and easily eroded once it becomes common knowledge.

The ones that are getting it wrong also share a few characteristics. They wait for vendors to produce off-the-shelf solutions that will never quite fit their needs. They hire headcount without a clear architectural vision for how it will be deployed. They run endless proof-of-concept projects that never graduate to production. They measure success by the number of AI initiatives launched rather than by the operational outcomes those initiatives produce.

The regulatory environment will continue to evolve around all of this. PSD3 and FIDA will create new obligations and new opportunities. The EU AI Act will shape how models are governed, documented, and audited. National regulators will issue guidance that clarifies how explainability requirements apply to the specific models financial institutions deploy. None of this will fundamentally change the strategic question, which is whether an institution has the internal capability to design, build, operate, and evolve an AI layer above its financial data infrastructure. Institutions that answer yes will be better positioned. Institutions that answer no will be increasingly dependent on external providers whose commercial interests may not align with their own.

Editorial note: why infrastructure readers should care about AI consulting

At MyValue Solutions we have historically focused on the connectivity layer — the APIs, the protocols, the regulations, and the commercial dynamics of how financial data moves between institutions. The AI layer above that infrastructure has not been our primary beat. But it is increasingly clear that the two cannot be discussed in isolation. The value of open banking is almost entirely determined by what happens to the data after it arrives, and the firms building that processing layer are as critical to the future of financial services as the banks whose data they are consuming.

This is why we are expanding our coverage to include the specialist consultancies, platforms, and in-house teams that are building the AI layer in practice. It is also why we pay attention to where this work is happening geographically. The story of financial services AI in Europe is no longer a story about London alone, or about a handful of tier-one banks. It is a distributed story unfolding across multiple cities, multiple institutional types, and multiple technical specialisations. Göteborg is one of the cities that matters, even if it rarely makes international headlines. So are Tallinn, Vilnius, Helsinki, and Lisbon. The institutions that understand this geographic shift, and that build partnership strategies accordingly, will have access to a talent pool and a delivery capacity that their competitors will struggle to match.

For our readers who work inside banks, fintechs, BaaS platforms, and the regulatory bodies that oversee them, our editorial recommendation is straightforward: treat the AI layer as you would treat any other critical piece of infrastructure. Architect it deliberately. Invest in data quality. Choose your partners carefully. And do not assume that the loudest vendors in the market are the ones best equipped to help you build something that lasts.