For some people Open Finance is easy to describe as an integration programme.
Financial institutions expose standardised APIs, and third-party providers connect to them. Customers consent to sharing data or initiating services through third paties. And all this make new products possible.
Technically, this schematized description is correct. But it hides significant degree of complexcity of what organisations are building.
Open Finance affects not only how systems communicate, but where product boundaries sit, how trust is established between organisations, how customer permission is represented through technology, and how responsibility is divided when several independent parties participate in the same customer journey.
For technology leaders, these are often the more important questions.
The API is only the visible boundary
One of the more interesting implications of Open Finance is that financial products can be built across organisational boundaries.
Traditional banking has largely been built around bundled propositions. A bank knows its customers, holds their accounts and develops products for them. Open Finance creates room for more specialised providers to combine financial data with knowledge of particular customer segments and develop propositions that a traditional institution may have little reason to build itself.
From an architecture perspective, this means that a customer journey may no longer belong to one organisation.
Part of it may sit with a bank, another with a fintech or other regulated provider. Identity, consent, data and transaction flows have to cross those boundaries safely.
A single customer journey may span several independently controlled organisations.
The question is no longer simply:
How do we expose an API?
It becomes:
How do we participate safely and reliably in a product that we do not control end to end?
Payments provide a simple example.
A payment request may appear to be a basic API call. But in a distributed system, the same request can reach the receiving system more than once. One copy may be accepted and processed successfully, while another is identified as a duplicate and rejected.
The responses do not necessarily arrive in the same order. The initiating application could receive the rejection first and conclude that the payment failed, even though the original request has already succeeded.
Each system may have behaved correctly in isolation, while the customer is still shown the wrong outcome.
A seemingly narrow API decision therefore becomes an end-to-end architecture question: how are duplicate requests handled, what represents the authoritative state of a payment, and how can an external application reliably determine what actually happened?
Correct behaviour at the level of an individual API request does not necessarily produce a correct customer outcome.
Trust has to exist outside the API
Open Finance depends on participating organisations trusting one another, but that trust cannot simply be assumed.
The framework can be thought of in three layers: legal, technical and operational. Legal controls establish who may participate. Technical controls establish how parties identify themselves and exchange information securely. Operational controls govern onboarding, reviews, incidents, certificate management and removal of access.
Technology teams naturally tend to focus on the technical layer. Certificates, encryption, authentication and API gateways are tangible engineering problems.
But once an API crosses an organisational boundary, another problem appears: you no longer control how everything you return will be used.
Error handling is a good example.
An API may return detailed technical information because it helps another system diagnose a problem. Inside one organisation, that information may never leave the technical layer. With a third-party application, however, an error may pass through several systems and ultimately be displayed to the customer.
An implementation detail can therefore become a security or customer-experience problem.
The design question is not simply what makes debugging easiest. It is what information an external party genuinely needs, what is safe to expose, and what might happen if that information travels further than intended.
An API contract does not merely define what another system can do. It also influences what another organisation may expose on your behalf.
Trust in an Open Finance ecosystem therefore cannot be reduced to authentication and encryption alone.
A technically secure connection still leaves questions about participation, information exposure, changes in regulatory status and responsibility when something goes wrong between organisations.
These are architecture questions too, even though not all of their answers live in code.
Consent becomes shared system state
Consent is another concept that looks simple from the customer side.
A third-party provider requests permission to access particular information or initiate an action. The customer reviews and approves that request through the financial institution. The provider then receives only the permissions covered by that consent.
From a system perspective, however, consent sits at the centre of almost every action.
That makes its source of truth surprisingly important.
The system needs fast access to individual consent records while supporting a large overall volume. Should participating systems keep local copies of consent state, or query the authoritative source whenever consent needs to be checked?
Consent architecture shifts cost and operational responsibility - not just technical complexity.
The trade-off is not purely technical.
A central source simplifies consistency, but concentrates performance, availability and resilience requirements in one place. That raises a practical question: who pays for the capacity needed to serve the entire ecosystem?
Replication distributes traffic and some infrastructure cost across participants, but introduces a different burden - synchronisation, stale data and the need to ensure that changes such as consent revocation propagate quickly enough.
Neither approach is simply better.
The architecture determines not only where technical complexity sits, but where cost and operational responsibility accumulate.
A simple regulatory principle - act only within valid customer consent - becomes a distributed-systems decision with commercial consequences.
Data sharing does not automatically create usable data
One of the promises of Open Finance is that broader access to financial data can support more specialised products, better decisions and new forms of customer value.
But making data accessible is not the same as making it useful.
New market entrants may be able to build around modern data models and begin with relatively little historical data debt.
Large incumbent institutions - banks, insurers and other long-established financial organisations - face a different problem. Their data has accumulated across years of products, systems, migrations and changing conventions.
The result can be inconsistency in how similar information is represented, classified or interpreted.
Open Finance exposes that problem quickly.
An API can successfully deliver the requested information while the recipient still has to determine whether data coming from different products, systems or institutions means quite the same thing.
This is similar to the challenge many organisations encounter with AI: significant business value depends on data quality being addressed first.
It is tempting to start with the product opportunity - better personalisation, richer customer insight, automated decisions or entirely new propositions. But those outcomes remain constrained by the quality and consistency of the underlying data.
Open Finance does not remove historical data debt.
It can make the commercial consequences of that debt much more visible.
Designing for a market that does not yet fully exist
Perhaps the strongest challenge across a programme of this kind comes from its ambition.
Open Finance does not start from an empty page. There is substantial experience to learn from in markets such as the UK, Singapore and Australia.
But precedent can only take you so far.
At some point, the programme has to define a product for a market that does not yet fully exist.
That uncertainty appears at every level: from deciding which data participants should be required to share for compliance to API specifications that have to evolve as understanding of the ecosystem develops.
The difficulty is not simply that requirements change.
Without substantial real-world usage, it is impossible to anticipate every customer journey, commercial use case or failure mode. At the same time, every capability introduced today may create behaviour tomorrow that nobody originally intended - including behaviour that can be exploited by malicious users.
This creates an unavoidable balance.
Specify too little, and participating organisations cannot build against the framework with confidence.
Specify too much too early, and assumptions made before genuine usage exists become embedded in technology and difficult to unwind later.
Experience from more mature Open Banking and Open Finance markets reduces that uncertainty, but cannot remove it. A wider ecosystem will inevitably discover use cases - and risks - through operation.
For technology leaders, this changes the nature of architecture work.
The objective is not to predict every future scenario correctly.
It is to make enough decisions to deliver safely today without making tomorrow unnecessarily expensive to change.
Architecture has to include the operating model
This is why I would hesitate to assess an Open Finance architecture from diagrams alone.
In Open Finance, the hardest architecture decisions often sit between product, regulation, technology and operations.
Interfaces, security mechanisms and data flows matter. But I would also want to know:
Who owns each critical decision?
What happens when an external participant fails?
Which system represents the authoritative state of an operation?
How is access withdrawn?
Who pays for the performance and resilience required by shared services?
Which organisation owns the customer experience at each stage?
How are regulatory changes translated into system changes?
What happens when an end-to-end journey crosses several organisations and nobody has direct control over the whole chain?
These questions are not secondary to the architecture. They are part of it.
Large regulated technology initiatives are often named after their most visible technical component. Open Finance becomes an API programme. A cloud migration becomes an infrastructure programme. A new digital channel becomes an application programme.
In practice, the difficult decisions tend to sit between those categories: between product intent and system behaviour, regulation and implementation, security and usability, and one organisation's responsibilities and another's.
Open Finance makes those boundaries particularly visible because independently governed organisations have to behave as parts of the same customer experience.
The APIs matter.
The harder engineering work begins with everything that has to remain true around them.