How open banking works, without the marketing

Open banking is often described as if a bank account simply plugs into an app. The real journey has more parties, more hand-offs and more limits than that phrase suggests.

In the UK, open banking gives a customer a way to permit a regulated third party to access specified information from an online payment account. The bank keeps the account. The customer remains the bank's customer. The third party receives only the access covered by the consent journey and its regulatory permissions.

For this budgeting product, the service is account information only. It reads approved account information. It does not initiate payments.

The parties in the journey

There are usually four parties visible in the flow. The user chooses to connect an account in the budgeting app. JEMA Software Ltd presents the service as a registered agent. Finexer Ltd provides the regulated open banking service as the authorised principal. The bank authenticates its customer and returns the permitted account information.

There are also technical systems behind those parties. APIs carry structured requests and responses. Tokens represent an approved connection. Databases retain the information needed by the product. Monitoring records whether a request succeeded or failed. None of those components changes who holds the account or who controls the original bank credentials.

Consent comes before access

The journey begins when a user actively chooses to connect a supported account. The consent screen describes why access is requested, the categories of information involved and the period for which access is requested. The Open Banking Standard distinguishes this payment-services consent from the lawful bases used under data protection law, although both affect the overall handling of data.

Nothing about the connection is automatic. If the user leaves the journey or declines at the bank, the app does not receive a completed connection. If the user approves only certain eligible accounts, the connection covers those accounts rather than every financial relationship the person has.

The Open Banking consent guidance explains that the purpose, requested data and duration need to be made clear before agreement.

Authentication happens with the bank

After the consent step, the user is sent to the bank's app or website. The bank handles identity checks using its own authentication process. That may involve the bank app, a passcode, biometrics or another method chosen by the bank.

The budgeting app does not receive the username, password or passcode used in that process. It receives the result of the authorisation through the regulated connection. This redirect model is why a legitimate journey can move between the product and a bank without asking the user to type bank security details into the product itself.

When the bank has completed the approval, it returns the user to the open banking journey. A reference or token allows the regulated provider to request the approved information. The token is not a copy of the bank password and does not create wider access than the consent and permissions allow.

How the data reaches the product

Finexer's systems communicate with supported banks through open banking interfaces. Bank responses are converted into a consistent structure so the product can work with fields such as account identifiers, balances, transaction dates, amounts and descriptions across different institutions.

That standardisation is necessary because banks do not all describe transactions in exactly the same way. Even where the API shape is consistent, the text attached to a card payment can contain processor names, location codes or shortened merchant labels. The product still has to interpret and present what arrives.

The first successful connection can return account information and available transaction history within the scope of the consent. Later refreshes request newer information. The exact timing and history depend on the bank, the account type, service availability and the permissions active at that moment.

Why data can look late or incomplete

Open banking is not a live mirror of every internal bank system. A card payment may be pending before it becomes a completed transaction. A bank may be undergoing maintenance. A consent token may need renewal. Some account types or fields may not be exposed in the same way as others.

The product therefore has to show timestamps, connection status and gaps honestly. A value based on the latest available feed is not a guarantee that no newer bank activity exists. Reconnecting or refreshing can restore a connection, but it cannot make a bank publish information that its interface has not yet returned.

Disconnecting and expiring access

Access does not have to remain in place. A user can withdraw through the product where that control is provided, or through the relevant bank controls. The Open Banking consumer FAQ describes both routes.

Disconnecting stops future collection through that consent. It is different from deleting information already received. Retained data is handled under the product's Privacy Policy, including account deletion and legal retention rules. Keeping those two actions distinct avoids implying that a disconnected token instantly removes every historical record.

What open banking does not mean here

The app does not become a bank. It does not hold the connected balance. It does not receive bank login credentials. Its account information connection cannot be used to send a transfer or collect a payment.

Open banking is the regulated transport and consent framework that allows selected account information to move from a bank, through an authorised provider, into a service chosen by the customer. The useful part of the product begins after that transport, when the returned information is organised into understandable views. The infrastructure is important precisely because it keeps those roles separate.

For current service details, read the company's open banking explanation and Privacy Policy.