The Financial Conduct Authority published new research on open finance infrastructure on 29 September 2026. Commissioned from Saïd Business School, University of Oxford, with Raidiam Services Limited as technical partner, it develops reference architectures for secure, trusted and scalable financial-data sharing. The models are intended for testing and future decision-making. They are not new rules.¹
That status gives enterprise teams a useful planning boundary. The national model remains open, while several capabilities appear necessary across every credible option. A CTO or CPO can define those requirements, test suppliers and shape a proposition without assuming that one operator, scheme or technical topology has already been chosen.
The research narrows the planning question
The research compares three model families: centralised, decentralised or federated, and hybrid. A centralised model coordinates trust, participation and access through a common control plane. A decentralised or federated model distributes those functions across authorities, standards bodies and firms. A hybrid model coordinates selected trust and assurance functions while firms and sectors continue to operate data custody, application programming interfaces (APIs), customer journeys and services.²
Each model carries a different balance. Central coordination can improve consistency, rapid revocation and accountability, while increasing dependency on common services. Distributed delivery can preserve flexibility and reduce reliance on one hub, while creating greater interoperability and coordination demands. The research identifies coordinated trust functions with distributed delivery as a credible proposition for further UK testing.²
The resulting enterprise question is specific: which functions require common evidence and coordination, and which capabilities should remain within the firm's product and operating model? That question supports current investment decisions without turning a reference architecture into a forecast.
Common capabilities give teams a stable starting point
The paper identifies foundations that remain relevant across the three model families. These cover:
- participant verification and authentication;
- delegated authorisation and permission evidence;
- secure APIs and client authentication;
- assurance, conformance and operational monitoring;
- credential lifecycle management and access revocation;
- cryptographic agility, including planned migration and rollback.
The infrastructure choice affects where those functions sit and who coordinates them. Their purpose remains consistent. Participants need to establish who is requesting access, which authority applies, what the service may do, whether that authority remains current and how access can be withdrawn.
This makes capability requirements a more dependable planning tool than a bet on topology. Teams can define the evidence their service will need at each boundary, then adapt the implementation when scheme design, participation and governance become clearer.
Define service requirements before choosing the trust model
Start with the customer or business outcome. Name the data required, the decision or service it supports, the parties that will rely on it and the harm that could follow from incorrect access or stale authority.
From that service definition, set requirements for five operating questions:
- how participant identity and current status will be verified;
- how a permission will express purpose, scope, duration and delegated authority;
- how status changes, incidents and revocations will reach every relying component;
- which evidence will support audit, redress and recovery;
- how the service will remain portable when a supplier, standard or trust arrangement changes.
The existing open banking consent management discipline provides a useful starting point for permission records and revocation evidence. Open finance broadens the data, product and participant set, so the same discipline needs portable identity, cross-sector trust and clear reliance rules.
Keep governance choices provisional
Several design decisions depend on future testing and policy. The final allocation of common and distributed functions remains open. So do the operating bodies, cross-sector trust relationships, assurance thresholds and responsibility model that would make those functions enforceable.
Enterprise plans should record these points as assumptions with owners and review dates. A supplier response can explain how its current service handles accreditation, trust metadata, consent, monitoring and revocation. It cannot prove that the same arrangement will become the national open finance model.
Contracts and architecture decisions should preserve room for change. Exportable permission records, stable identifiers, documented trust dependencies and replaceable integration boundaries give the buyer options as the model develops. The open banking provider RFP scorecard shows how to convert those expectations into dated evidence and acceptance criteria.
Agentic services increase the evidence requirement
The FCA research examines how infrastructure may support artificial intelligence services acting for consumers or firms. In that setting, the service may need to prove the operator's identity, the authority delegated to the service, the permitted actions and the route for monitoring or withdrawal.²
Those questions reach beyond API security. An authenticated client can still act outside the commercial or customer mandate intended for a particular task. A sound design therefore needs a separate record of delegated authority, a machine-readable scope and an enforceable path from proposal through permission to any resulting action.
The agentic payments architecture applies that separation to payments. Open finance infrastructure extends the same control question across data access, recommendations and actions involving several products or sectors.
The next FCA testing phase is expected to examine participant verification, permission journeys, trust metadata, monitoring, revocation, interoperability and the withdrawal of authority delegated to an AI-enabled service.² Enterprise teams can use those areas as test cases while preserving their status as research priorities.
Current Open Banking provides evidence for future design
UK Open Banking already uses common standards and trust services. Open Banking Limited describes its Directory as core infrastructure that lets participants request and grant access to financial data through secure, permissioned APIs.⁵ That provides useful operating evidence for participant status, certificates and access control.
Open finance will span a wider range of products, firms and potentially other smart-data sectors. The research therefore examines how trust could remain portable across several domains and how common assurance might work alongside distributed service delivery. The identity of future operators and the allocation of responsibilities remain subjects for later decisions.
Shared infrastructure also creates dependencies. Enterprise service owners still need to map how a common directory, trust service or monitoring function affects their customer outcome and recovery plan. The current critical third parties and Open Banking boundary offers a useful principle: oversight of a shared provider and firm-level service responsibility operate at separate layers.
Procurement should follow functions and evidence
Procurement teams can compare providers against the functions the research identifies. Ask how participant status is verified, how trust metadata is refreshed, how permission evidence is represented, how revocation propagates, which monitoring data is available and how the service behaves when a common dependency fails.
Require suppliers to separate current capability from roadmap commitments. Current capability should be demonstrated through working interfaces, exportable evidence, failure tests and named operating ownership. Roadmap items should carry dependencies, dates and contractual treatment appropriate to their uncertainty.
This approach keeps the buying decision useful across several possible policy outcomes. A provider may later connect through a central service, participate in a federated trust arrangement or use a hybrid structure. The buyer still needs dependable evidence of identity, authority, state, performance and revocation.
The next milestones will refine the decision
The FCA's April open finance roadmap set out a Q4 2026 discussion paper on the first open finance scheme and work with HM Treasury on options for a longer-term regulatory framework in 2027.³ The roadmap also places current emphasis on practical use cases and testing.
The mortgage policy sprint published on 3 September illustrates that evidence-led sequence. Participants highlighted trusted evidence, common infrastructure, safeguards, viable commercial arrangements and broad participation. The FCA states that these findings reflect participant work and do not establish a final design or confirmed policy.⁴
Enterprise teams should monitor whether later publications change the functions, participation model or timetable relevant to their proposition. A useful decision record links each architecture and procurement assumption to the source that supports it, the uncertainty that remains and the milestone that will trigger review.
The 29 September research gives firms a practical starting point. Define the trust, permission, monitoring, revocation and portability capabilities the service needs. Test those capabilities against a real customer outcome. Keep national governance choices provisional until the FCA's evidence and policy work settles them.
Footnotes
- Financial Conduct Authority, 29 September 2026. Powering open finance infrastructure
- Financial Conduct Authority, 29 September 2026. Powering open finance infrastructure research note
- Financial Conduct Authority, April 2026. Open finance: our vision for a smart data future
- Financial Conduct Authority, 3 September 2026. Mortgages and open finance policy sprint
- Open Banking Limited. Open Banking Directory