Why we use read-only bank access and never touch payments

The product needs account information to build a connected budget. It does not need the ability to move money. That difference shaped both the regulatory setup and the technical architecture.

UK payment services rules separate account information services from payment initiation services. Account information is about receiving and presenting information from accounts a user selects. Payment initiation is about starting a payment from an account at the user's request. They are different regulated activities with different customer journeys and risks.

JEMA Software Ltd operates only as an Account Information Services agent for this product. The connection is read-only. We do not provide payment initiation services and do not hold client funds.

What read-only means in practice

Once a supported account has been connected with explicit consent, the service can receive fields made available through the bank connection. Those fields can include the account name or type, balances, transaction dates, amounts, descriptions and merchant information.

The product can process that information. It can place a transaction in a category, identify a repeated description, compare periods or calculate a budgeting estimate. Those are operations on a copy of account information held in the product's systems. They do not alter the bank account.

There is no instruction in the account information flow that sends money. The product cannot create a transfer, change a direct debit, withdraw cash or pay a merchant. If a user acts on something shown in the app, that action happens separately through the bank or the relevant service provider.

Why we chose that boundary

The first reason is product scope. The question we are working on is how to present everyday account activity clearly. Reading balances and transactions is necessary for that. Moving money is not.

The second reason is user expectation. A budgeting product sits close to sensitive information. A narrow permission is easier to describe accurately than a broad one. The user can understand that the app receives information but has no payment capability through that connection.

The third reason is operational focus. Payment initiation would introduce another regulated service, another set of user journeys and another category of incidents. Adding it simply because the infrastructure can support it would expand the product without answering the original budgeting problem.

Finexer Ltd, the principal firm, has wider capabilities as a payment institution. That does not mean every agent or product using its infrastructure uses every permission. The service presented through this app is limited to account information.

Bank credentials remain with the bank

Read-only does not mean the app receives a password and promises not to use it. The app does not receive the bank password in the first place.

During connection, the user is redirected to the bank's own app or website to authenticate and approve access. The bank returns an authorisation result through the open banking flow. The regulated provider uses a token to request the agreed information. A token is specific to the connection and permissions. It is not the user's online banking credential.

This distinction is visible in a normal connection journey. A screen asking for a bank passcode inside an unrelated budgeting form would not match the route described here. Bank security details belong only in the bank's own authentication experience.

Read-only does not mean risk-free

Account information is sensitive even when nobody can use it to send money. Transactions can reveal routines, income sources, medical purchases, travel, relationships and locations. A read-only architecture still needs access controls, encryption, retention rules, incident processes and careful support tooling.

It also needs honest interface copy. A delayed feed can produce an out-of-date view. A merchant can be categorised incorrectly. A pending transaction can later settle at a different amount. The product must not present a derived figure as certainty simply because the underlying connection is regulated.

Read-only is one control, not a complete security claim. It reduces the actions available through the bank connection. It does not remove the responsibility to protect the data that the connection returns.

What happens when access ends

A user can disconnect the account connection. That prevents further account information from being collected through that consent. Access may also expire or require renewal under the bank and open banking journey.

Historical information already received is a separate data-retention question. It is not silently kept forever, and it is not necessarily erased by the technical act of disconnecting. The Privacy Policy explains retention, account deletion and the circumstances in which limited records may need to remain.

The exact position

The wording in the site's regulatory disclosure is deliberate: JEMA Software Ltd is a registered Account Information Services agent of Finexer Ltd. Finexer is authorised and regulated by the FCA under the Payment Services Regulations 2017. We do not hold client funds and do not provide payment initiation services.

That boundary is not a temporary omission from a feature list. It is a decision about what the product is for. The app reads account information that a user has chosen to share, then organises it for budgeting. The money itself stays where it was.

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