Open Finance promises to give consumers a complete, connected view of their financial lives. Rather than data locked inside separate banks, insurers, pension providers, and investment platforms, the vision is straightforward: one person, one financial picture, shared through APIs with explicit consent. Yet despite billions of dollars in regulatory investment and 95 markets moving toward shared frameworks globally, the transition from Open Banking to Open Finance remains painfully slow.
So we put the question directly to five industry leaders across fintech, financial infrastructure, and enterprise solutions: Open Banking is evolving into Open Finance, where insurance, pensions, and wealth data flow through APIs alongside banking data. What is the biggest obstacle to making it work in practice?
Their answers converged around a clear theme. Essentially, the technology exists and the APIs work. What is missing is the governance infrastructure to make cross-sector data sharing safe, accountable, and trustworthy at scale.
Open Finance Needs a Common Data Language First
The most fundamental barrier is deceptively simple. Specifically, financial products outside of banking do not share a common vocabulary. Banking data is relatively uniform, involving credits, debits, and balances. Insurance policies, by contrast, carry hundreds of variables across coverage types, exclusions, and endorsements. Meanwhile, pension schemes involve projected benefits that shift based on contribution rates and market performance. On top of that, investment portfolios update continuously with different valuation methods depending on asset class.
This is not a theoretical problem. Banking has ISO 20022, which became the exclusive standard for SWIFT cross-border payments in November 2025. Insurance has ACORD, covering over 800 form types, but adoption remains largely voluntary. Conversely, pensions have no universal data standard at all. The UK’s Pensions Dashboards Programme published specific standards in March 2025 to connect approximately 40,000 pension schemes, many dating back to the 1960s. Similarly, wealth management has the nascent OpenWealth Association, though connectivity between custody banks and portfolio systems remains mostly proprietary.
As a result, two platforms can exchange information flawlessly at a technical level while still drawing completely different conclusions from the same dataset. Consequently, this makes integration debt a structural feature of Open Finance rather than a temporary growing pain.
Building a shared trust framework is one of the key barriers to practical implementations of Open Finance. As Open Finance begins moving beyond banking toward insurance, pension funds, and investments, it will rely heavily on interoperability standards; secure identity verification; and clearly-defined customer consent to allow broad participation throughout the ecosystem. The Bank for International Settlements (BIS) and Financial Conduct Authority (FCA) both note the foundational role of trusted data, secure technology, and interoperability as assets that can help overcome coordination and accountability challenges of coordinating large-scale systems, but they’re not limited only to these aspects.
In practice, organizations struggle to instantiate Open Finance, primarily because of inconsistent data across sectors; a lack of clear management of customer consent; and obscured responsibilities if there is either an error or misuse of customer data. Thus, Open Finance will require more institutions involved; more varied and complex data sets; and longer trust chains between data consumers, than did Open Banking. The organizations that will ultimately successfully drive Open Finance will be those that consider consent, interoperability and accountability core infrastructures, as opposed to considering the addition of AI-and-API layers to legacy systems to constitute transformation.
My work often involves evaluating how financial infrastructure and digital platforms shape market behavior, particularly where financial data, technology, and consumer access intersect. I also teach finance and economics at the City University of New York, where we examine how regulatory structures and financial data systems influence the practical functioning of markets and financial services.
Open Banking is evolving into Open Finance, where insurance, pensions, and wealth data flow through APIs alongside banking data. What is the biggest obstacle to making Open Finance work in practice?
Why does data standardization become such a challenge in Open Finance?
Financial products outside of traditional banking are inherently more complex in how they are structured and reported. Insurance policies contain underwriting variables, exclusions, and coverage layers. Pension products involve long term projections and regulatory reporting rules. Investment accounts involve portfolio level data that changes continuously with market conditions. When these datasets are exposed through APIs, the challenge is not simply sharing the information but ensuring that another platform can interpret it accurately. Without strong data standards across sectors, two platforms may technically exchange information while still interpreting the underlying data differently, which undermines the reliability of the system.
What role does consumer trust play in the adoption of Open Finance?
Consumer trust becomes central once financial data moves beyond traditional bank boundaries. In Open Banking the public gradually became comfortable allowing third party applications to access account balances or transaction histories. Open Finance expands that scope significantly, potentially including insurance coverage details, retirement savings projections, and investment holdings. Many consumers are understandably cautious about who can access that level of financial visibility. Unless the system clearly communicates data permissions, security safeguards, and revocation controls, adoption can stall because consumers perceive the system as exposing too much sensitive information.
- Dennis Shirshikov, Head of Growth and Engineering, Growthlimit.com
Legacy Infrastructure Was Never Built to Share Data
Even where standards exist, the underlying infrastructure often cannot support real-time API access. To put it plainly, the financial sector’s dependence on legacy systems is staggering: 92 of the top 100 banks worldwide depend on IBM mainframes, and an estimated 220 billion lines of COBOL code remain in production globally.
Insurance companies face especially severe challenges because of decades of mergers that produced incompatible systems. In fact, ninety percent of insurance businesses report being held back by outdated technology. Pension providers are similarly burdened, with many schemes operating on minimal digital infrastructure designed for quarterly reporting rather than real-time data sharing.
More importantly, simply wrapping legacy systems in API layers does not constitute transformation. Most of these systems process data in overnight batch cycles. Therefore, wrapping them in APIs creates the illusion of real-time access while the underlying data may be hours old. Since the EU’s FIDA regulation requires Open Finance data to be made available continuously and in real time, this gap between perception and reality becomes a compliance risk rather than just a technical limitation. Notably, this mirrors the supply chain finance problem, where outdated infrastructure creates bottlenecks across entire ecosystems.
Transitioning Open Banking to Open Finance is not only about scaling but semantic too. Banking has made progress with its standards such as ISO 20022; however, there still exist financial service sectors such as insurance or wealth management that operate in ‘silos’ of non-unified data schemas. The largest of these barriers is technical fragmentation, where legacy systems not built to be open are required to communicate through language that is not understood.
Practically, we see examples where even though there is an API to access some data, the data payloads are so inconsistent. For example, ‘customers’ in banking do not resemble ‘policyholders’ in insurance; and without a common cross sector/common schema to map and translate data in real-time, there is a massive tax placed on innovation due to the cost associated with data mapping. This results in brittle integrations that struggle to achieve and maintain the strict accuracy requirements of financial regulations.
Success will require creating an effective governance framework that addresses the inherent risks involved in sharing data across the various types of financial services. It is also important to remember that every API call is made on behalf of someone who wants their financial life to be easier, not branded. Solving the issues of trust and standardization before technical issues is essential for success.
- Sudhanshu Dubey, Delivery Manager, Enterprise Solutions Architect, Errna
The biggest obstacle is not the data itself. It is the absence of a shared language between the systems that hold it. Banking APIs have matured because the underlying data is relatively simple: money in, money out, balance. But insurance policies carry hundreds of variables across coverage types, exclusions, and endorsements. Pension schemes involve projected benefits that shift based on contribution rates, market performance, and regulatory changes. Investment portfolios update continuously with different valuation methods depending on asset class. When you try to pipe all of this through APIs alongside banking data, the receiving platform has to interpret what it is reading. Without cross-sector semantic standards, two platforms can exchange information flawlessly at a technical level while still drawing completely different conclusions from the same dataset.
This is where AI becomes central to the conversation rather than peripheral. At GiaAI, we see the translation layer between incompatible financial data schemas as one of the most valuable problems AI can solve right now. However, AI-powered data mapping only works reliably when governance frameworks define who is accountable if the translation gets it wrong. Consider a scenario where an AI model misinterprets pension fund data and a consumer receives inaccurate retirement projections through a third-party app. Who bears responsibility? The pension provider? The app? The AI layer in between? Until regulators establish clear liability chains across these longer trust relationships, most institutions will default to caution. They will protect their data rather than share it. So the real unlock is not better technology. It is better institutional trust infrastructure that gives every participant in the chain confidence that accountability is defined before the first API call is made.
- Callum Gracie, Founder, GiaAI
Why This Cannot Succeed as a Domestic-Only Solution
Most frameworks for cross-sector data sharing have been built nationally. The UK has its CMA Order. The EU has PSD2. Brazil built its own unified system. Each works well within its borders. However, the moment financial data needs to cross jurisdictions, none of these frameworks communicate with each other.
To address this, the BIS launched Project Aperta in October 2024 to prototype cross-border data portability. It brings together the central banks of the UAE and Brazil, the UK’s FCA, Hong Kong’s HKMA, and the Global Legal Entity Identifier Foundation. Together, they are testing harmonized security protocols and trust frameworks for consumer-consented, end-to-end encrypted data sharing across borders. Still, practical implementation remains years away.
On top of that, consent fatigue compounds the cross-border challenge further. Open Banking already requires managing consent across multiple providers. Naturally, expanding Open Finance to pensions, insurance, and investments multiplies those interactions dramatically. For instance, a consumer might need to grant separate permissions for their bank, mortgage provider, three pension schemes, two insurance policies, and an investment platform. Each requires valid, traceable, GDPR-compliant consent. Although the EU’s FIDA mandates permission dashboards for real-time monitoring of data sharing, implementing granular consent management at this scale, across sectors with different sensitivity levels and compliance requirements, is a significant infrastructure challenge on its own.
Cross-border freelancers already live inside the problem that Open Finance is trying to solve. A typical Remotify user might earn in US dollars, hold savings in euros, pay taxes in two jurisdictions, and need insurance coverage that follows them across borders. Their financial life is fragmented by design, not by choice. So when people ask what the biggest obstacle to Open Finance is, I would say it is the assumption that financial data sharing can be solved one country at a time.
Open Banking frameworks were built nationally. The UK has its CMA Order. The EU has PSD2. Brazil built its own unified system. Each of these works well within its borders. Yet the moment you introduce a freelancer invoicing clients in three countries while managing pension contributions in a fourth, none of these frameworks talk to each other. The BIS launched Project Aperta in late 2024 to prototype cross-border data portability, which is encouraging. Still, we are years away from a freelancer in Berlin being able to share verified income data from a US client with a Portuguese mortgage lender through a single consent flow.
The consent challenge compounds this further. DAC7 already requires platforms like Remotify to report seller income across EU member states. Open Finance would layer additional data-sharing permissions on top of existing tax compliance obligations. For a freelancer managing clients in multiple countries, consent fatigue becomes a genuine barrier to adoption rather than a theoretical concern. Each new jurisdiction adds another permission layer, another regulatory framework, and another potential point of failure. The path forward requires interoperability between national frameworks, not just better APIs within them. Until regulators prioritize mutual recognition of consent and trust frameworks across borders, Open Finance will remain a domestic solution trying to serve an increasingly borderless workforce.
- Hasan Can Soygök, Founder, Remotify
The Bottom Line: Open Finance Needs Governance Before Technology
Every expert we spoke with arrived at the same conclusion through different paths. The APIs exist. Cloud infrastructure is mature. AI can map data across schemas. Fundamentally, what is missing is the institutional trust framework: the rules, liability structures, dispute mechanisms, and consent infrastructure that make it safe for pension data to flow alongside banking data to a service that genuinely helps someone plan their financial life.
Brazil has already proven that the model works at national scale, with over 800 participating institutions and 96 billion monthly API calls. Meanwhile, the EU’s FIDA regulation is progressing through trilogue. In the UK, the FCA has declared this a five-year strategic priority. Deadlines are now concrete: large US banks must comply with CFPB Section 1033 by April 2026, and the UK’s pension dashboards connection deadline is October 2026.
Ultimately, the organisations that succeed will be those treating consent, interoperability, and accountability as core infrastructure rather than regulatory checkboxes. Because at the end of the day, every API call in this ecosystem is made on behalf of a person who simply wants their financial life to be easier.