What Open Finance Actually Lets a System Do
Open finance becomes understandable when we follow one permission all the way through the system. The question is not merely whether a customer clicked “allow,” but what purpose was stated, who was authenticated, which data or action was authorised, and what happens when the permission ends. This chapter traces that path from consent to an API request and then separates a service that reads information from one that can initiate a transaction. The result is a practical test for the difference between a well-bounded interface and a connection that is technically available but poorly controlled.
A permission is a bounded lifecycle
Imagine a customer using a financial-management service that promises to show balances and spending across several institutions. The service needs information held by a bank, but the bank cannot simply hand over every record because the customer has expressed a general interest in managing money. A meaningful request has to identify the participant seeking access, the data needed, the purpose for which it will be used, and the authority under which it is being requested. The customer then needs a way to understand and approve that request through the relevant authentication process.
This is the first important correction to the idea that consent is a button. The button is only the visible moment in a longer lifecycle. Before it, a service has to describe what it wants to do. During it, the customer has to be authenticated and the data holder has to verify that the request is associated with that customer and an eligible recipient. After it, the recipient has to use the data within the authorised purpose, preserve the relevant controls, and stop when the permission expires or is withdrawn. A system that records only the initial click loses the information needed to govern the rest of the relationship.
Open finance is commonly defined as the sharing and use of customer-permissioned financial data with third-party providers, other financial institutions, or developers. The scope may include bank accounts, but broader arrangements can reach insurance, mortgages, pensions, securities, and investments. A permission is therefore not just about a file moving from one bank to one app. It can connect several institutions and several categories of a person’s financial life. The wider the scope, the more important it is to make the boundaries legible.
The first boundary is read access. A provider may retrieve account balances, transaction history, or other authorised information and use it to display a consolidated view, assess a loan application, or provide analysis. The provider can be valuable without changing the underlying account. Its authority is primarily observational and interpretive, although the inferences it produces can still affect a decision such as whether to offer credit or how to present a product.
The second boundary is write access. In the reports’ terminology, this can allow a service to modify data or initiate a payment or another transaction on the customer’s behalf. A customer might bring money into an account from another institution, authorize a bill payment, or permit a service to manage a transfer. Write access does not necessarily mean unlimited control; it can be scoped to a particular action, recipient, amount, or time. But it does mean that the system has crossed from describing a financial state to changing one.
That difference changes the failure analysis. If a read-only budgeting service receives a stale balance, the customer may make a poor decision because the display is wrong. If a write-enabled service sends money to the wrong recipient or at the wrong time, the error can create a direct financial loss or an obligation that did not exist before. A permission that is adequate for account aggregation may therefore be inadequate for payment initiation, even when both are presented inside the same application.
A bounded permission must also distinguish possession from purpose. A third party may legitimately receive transaction data to provide account aggregation without being entitled to reuse the same data to market unrelated products or build a profile for an undisclosed purpose. The OECD describes this risk as function creep: data accessed for one reason can be repurposed for another, especially when AI can extract and reuse patterns at speed. Whether a particular use is lawful depends on the applicable jurisdiction and rules, but the design problem is general. The system needs to preserve the connection between the data, the stated purpose, and the actor using it.
This is also why reuse and withdrawal are part of the lifecycle. Financial data may be copied into a service, combined with other records, transformed into a feature, or used to produce an inference. A customer who withdraws permission may be able to stop future access, but the treatment of information already received or of derived outputs depends on the framework and the purpose. The more a system iterates over the data, the less adequate a one-time record of approval becomes. Consent must remain meaningful as the use changes, not only when the data first leaves the institution.
The lifecycle can be summarized as a set of questions:
- Purpose: What service is being requested, and is the requested data necessary for it?
- Identity: Which customer, data holder, recipient, and service are involved?
- Authority: Is the permission for reading, writing, or both, and what are its limits?
- Use: What may the recipient do with the data, including inferred information?
- Duration: When does access expire, need renewal, or become subject to withdrawal?
- Evidence: What record shows what was requested, approved, returned, and done?
- Remedy: Who can stop the flow, correct the result, investigate misuse, and help the customer recover?
These questions do not turn consent into a universal legal formula. They make the operational boundary visible. Without them, a customer may agree to “share financial data” without knowing whether the system will simply display an account, evaluate eligibility, train a model, or initiate a payment.
Why APIs change the failure surface
The mechanism carrying a permission matters because older forms of access made authority difficult to separate from credentials. Before formal open-finance frameworks, third-party providers commonly used screen scraping, reverse engineering, or bilateral file transfers. In screen scraping, a customer could consent to a provider logging in on their behalf with online-banking credentials and extracting information from a website. That approach might make a service possible, but it places a powerful secret in another party’s hands and ties the service to a presentation layer that was not designed as a stable data interface.
Reverse engineering creates a different version of the same problem. A third party analyses an existing interface or software behavior and tries to reproduce its access path without a documented, standardised contract. A small change to the institution’s website can break the connection. More importantly, it becomes harder for everyone to know which requests are permitted, how authentication is performed, whether a response is complete, and what should be logged when the connection fails. The customer may have given permission, but the technical route does not necessarily express the permission with precision.
An application programming interface, or API, supplies that missing contract. It defines how a request is made and how a response is returned. In an open-finance setting, the API can provide a standard path for a third party to ask for a specified balance or transaction set, while the financial institution retains control over authentication, monitoring, and access management. Standardisation reduces the amount of bespoke integration each participant must build. That lowers duplication and can make it easier for a smaller provider to connect to more than one institution.
The causal chain is important. A common request format does not create competition by itself. It reduces one technical barrier. If the data holder still refuses eligible connections, if the recipient cannot obtain authorization, if responses are inconsistent, or if the service has no useful customer proposition, the API will not create a market. But without a dependable interface, a potentially useful service has to spend its effort reconstructing each institution’s private connection. Interoperability is therefore an enabling condition, not the final outcome.
A typical read request follows a sequence like this. The customer chooses a service and is shown the purpose and requested scope. The customer authenticates with the institution that holds the data, rather than simply handing the third party a reusable password. The third party then sends a request through the standard interface. The data holder checks the identity, the authorization, the requested scope, and whatever eligibility or access rules apply. It returns the permitted response—or refuses or limits the request. The third party uses the response for the service, and the relevant actors retain enough information to establish what happened.
A write request adds another decision point. The provider may prepare a payment or other action from the data it has read, but preparation is not the same as execution. The system needs to check that write authority exists, that the intended action falls within its scope, and that the customer’s authentication and any required confirmation are still valid. The institution or payment rail then accepts, rejects, or holds the action according to the applicable controls. The customer should be able to distinguish the original permission to read from the later authority to change a financial state.
The sequence separates three things that are often blurred together: the customer’s decision to permit access, the data holder’s authorization of a particular request, and the service’s later attempt to use the result. The API is the communication mechanism between those decisions; it is not itself the customer’s intention. This is why an API can improve consistency and auditability without settling every question about whether the requested use is appropriate.
The interface also changes what can be observed when something goes wrong. A standard request can be recorded with its scope and result. A refusal can be distinguished from an outage. A write request can be separated from a read request. A revocation can stop later requests rather than relying on a provider to remember a customer’s preference. These records support investigation and accountability, although a log does not guarantee that an actor behaved properly after receiving the data.
Several important risks remain outside the protocol. The data may be inaccurate or out of date. A provider may use a permitted record for an unsuitable purpose. A model may infer a sensitive attribute that was not explicitly shared. A customer may be steered toward a product even though the data transfer was technically authorized. A third party or infrastructure provider may be compromised. A person may not understand the difference between approving a read and approving a payment. None of these failures is cured merely because the request used an API instead of screen scraping.
Nor does standardisation eliminate all coordination costs. Different institutions may implement a common rule with different levels of reliability. A central directory or switching service can simplify participation while creating dependence on a central node; direct connections can distribute control while requiring more coordination between participants. Those architectural choices affect resilience, entry, and accountability. They are part of the wider system behind the permission, not a detail that can be ignored once the endpoint is documented.
The strongest conclusion is therefore narrower than “APIs make open finance safe.” APIs make it possible to express and enforce parts of a permission more consistently: who asks, what is requested, how the request is authenticated, and what response or action follows. They reduce the need to share credentials and can lower integration barriers. But appropriate use, fair treatment, data quality, security, and recourse still depend on the institutions and rules around the interface.
The permission path is now visible. Its reliability, however, depends on choices about who must participate, how shared infrastructure is governed, whether connections are centralised or bilateral, and whether participants share data on reciprocal terms. Those choices determine whether an API is a route to genuine contestability or merely a cleaner entrance to a system that remains closed in practice.