When Financial Data Starts Acting
Open finance is the subject of this series: a way for customers to let financial institutions share data with other providers, and in some arrangements to let those providers initiate actions on the customer’s behalf. This opening chapter focuses on the boundary between reading financial information and acting through a financial interface. That distinction gives us a practical way to judge what open finance can change, what the early evidence actually supports, and why consent becomes harder to manage when artificial intelligence can do more than produce a screen full of advice.
The basic promise is straightforward. A person’s financial life is usually scattered across banks, lenders, insurers, investment platforms, and payment services. The institution that holds one part of that picture may know more about the customer than a new provider can see. If customers can authorize a secure transfer of relevant information, another provider can compare accounts, assess a loan application, organise payments, or offer a service built around a fuller picture. The promise is not simply convenience. It is that control over information may loosen the grip of data-rich incumbents and give customers more choice.
Open finance is more than a larger data pipe
Open banking is the narrower idea: banks share customer-permissioned data with third parties. Open finance extends the possible scope to products such as insurance, mortgages, pensions, securities, and investments. The boundary is not identical everywhere, and a policy described as open finance in one jurisdiction may cover less than the term suggests in another. The useful common element is not the label or the product list. It is the customer-permissioned connection between a data holder and another participant in the financial system.
That connection can have two fundamentally different capabilities. Read access allows a service to view or analyse information. A budgeting tool might retrieve account balances and transaction history, then show the customer where money is going. A lender might examine permissioned cash-flow data as part of a credit assessment. The service observes and interprets; it does not, merely by reading, change the customer’s account.
Write access gives a service the ability to modify data or initiate a payment or other transaction. A provider might start a transfer from one account, move money into another, or submit a payment instruction. The customer may still have given explicit permission, but the nature of the permission has changed. An error in a read-only balance display can mislead. An error in a write-enabled service can move funds, create an obligation, or alter a financial position.
This is why consent cannot be treated as a single yes-or-no property. A meaningful permission has a purpose, a scope, an authorised actor, and a boundary around what can happen next. Permission to assemble a financial overview does not automatically mean permission to market a new product, train an unrelated model, or execute a transfer. The exact legal consequences vary by jurisdiction, but the practical distinction exists before anyone argues about legal terminology: observing a financial state and changing it are different kinds of authority.
The diagram is deliberately simple. It shows that an open-finance interaction is a relationship, not a pipe with no owner. The customer authorizes a connection; the financial institution controls data or account access; the third party supplies a service; and oversight has to account for what was requested, what was returned, and what was done. The more the service can do, the more important those distinctions become.
Why the old data arrangement mattered
Financial institutions generate and control large amounts of information about their customers. That information can improve existing services and help create new ones. New services can then generate still more data, reinforcing the advantage of the institutions that already have scale. When a provider cannot obtain permissioned information through a dependable route, it may struggle to compete even if it has a better product idea. Customers, meanwhile, face the cost of re-entering information, proving their identity again, or staying with an incumbent because switching is inconvenient.
Open finance is intended to interrupt that cycle by making data portable under customer control. The aim is not to make every financial record public. It is to let a customer authorize a specified use by a specified participant through a framework that is safer and more consistent than handing over online-banking credentials. If the arrangement works, a new provider can compete for a customer’s business without first having to recreate the customer’s entire financial history.
That possibility connects open finance to several practical outcomes. A person may compare products across providers more easily or transfer verified information during account opening. A small business may show a lender a more detailed and current picture of its cash flow. A financial-management service may bring several accounts into one view. In each case, data sharing is valuable because it changes a relationship: it reduces a barrier between the customer and a service that was previously difficult to provide.
But a right to share data does not, by itself, produce a functioning market. Participants need compatible technical interfaces, reliable identity and authentication, rules about who may receive data, and clear responsibility when something goes wrong. A customer can give permission and still encounter a service that is unavailable, incomplete, too difficult to use, or unable to act across institutions. The benefit therefore depends on both the permission and the infrastructure that carries it.
That infrastructure is shaped by public choices as well as private contracts. Some jurisdictions prescribe common standards and require institutions to participate. Others publish guidance and let banks and providers coordinate voluntarily. In market-led settings, bilateral arrangements may develop without a single common rulebook. The BIS review counted open-banking or open-finance policy frameworks in 95 jurisdictions by 2024, but those frameworks pursue different goals and sit at different stages of maturity. The number is evidence of a broad policy movement, not evidence that customers in all those places have the same rights or usable services.
The same caution applies to the word adoption. A registered user, a linked account, an active consent, a successful API call, and a completed payment describe different things. A person may authorize a connection once and never use the resulting service. An API may be called frequently by a small group of sophisticated users while most customers remain outside the system. If a framework is technically open but difficult to navigate, nominal permission can coexist with practical dependence on the incumbent. The question is therefore not only whether sharing is allowed, but whether the surrounding design turns that permission into a reliable choice.
The evidence already points to a further caution. Open finance may improve access for some people while leaving others behind. Users with limited digital access, lower financial literacy, less data history, or stronger privacy concerns may be less willing or able to share. A system that treats non-sharing as a sign of higher risk could make refusal costly. More information can reduce an information gap between a borrower and a lender, but it can also expose a customer to more profiling, more targeted pricing, or a larger breach if the information is poorly governed. In other words, the same connection that can make a market more contestable can also make the customer more visible to institutions and algorithms. Its value depends on who can use it, under what conditions, and with what ability to say no.
The question changes when software can act
Artificial intelligence gives open-finance data a new kind of leverage. With a broader and more timely financial picture, an AI system might identify patterns that a person or a conventional rule-based tool would miss. It could support credit assessment for a borrower with a thin formal file, personalise financial guidance, reconcile data from different providers, or update a fraud or risk assessment as new information arrives. These are potential benefits, not guarantees: the data still has to be accurate, representative, relevant to the purpose, and handled within appropriate controls.
The relationship also runs in the other direction. AI can help reconcile inconsistent records, identify gaps, and transform data into more usable formats. That can improve the utility of the shared infrastructure itself. Yet the same feedback loop creates new questions. If a customer’s data is used to improve a model, where is that use recorded? If the model produces an inferred profile rather than copying a transaction, does the original permission cover the inference? If the model is updated repeatedly, can a customer understand what continued use means or withdraw without losing every service that depends on it?
The distinction between reading and acting becomes decisive here. An AI system that reads a balance and suggests paying down a credit-card debt is making a recommendation. An agentic system—still a theoretical and experimental scenario in finance in the OECD’s analysis—could be given tools to check balances, plan a sequence, and execute a transfer after a defined authorization. That might help a customer avoid an overdraft or manage cash automatically. It could also act at the wrong time, pursue a goal that conflicts with the customer’s interests, use data for a purpose the customer did not understand, or make it difficult to determine who is responsible for the result.
This is the central tension that the rest of this series will examine. Open finance can make financial services more contestable, more personalised, and potentially more inclusive by allowing trusted providers to work with data that was previously locked inside institutional silos. AI can make those data flows more useful and more responsive. But the combination can also make a permission harder to see and a mistake harder to reverse. Consent must remain connected to purpose, scope, traceability, oversight, and redress even after data has entered a model and the model has begun to act.
The next step is to follow that permission through the machinery that is supposed to keep it bounded: authentication, standardised APIs, access controls, and the separate paths for reading information and initiating financial action. Only by seeing that mechanism clearly can we tell which protections belong to the interface and which still depend on institutions, incentives, and human judgment.