What happens to your data when you connect a bank account

A connected bank account produces some of the most revealing data a person can share with an app. A list of transactions can describe routines, work, travel, health, relationships and ordinary habits. Explaining where that information goes needs more detail than saying it is secure.

The exact legal record is the Privacy Policy. This article gives a readable map of the main data flow for the budgeting service. It does not replace that policy, and the policy remains the current source if a provider or retention period changes.

The connection starts at the bank

A user begins by selecting a supported bank and agreeing to the account information request. Authentication takes place in the bank's own app or website. The budgeting product does not receive the username, password, passcode or biometric information used to sign in.

The bank returns the information covered by the approved connection through open banking interfaces. Depending on the account and bank, that can include account identifiers, account type, balances, transaction dates, transaction amounts, descriptions and merchant information.

The connection is read-only. It is not used to initiate a payment, and JEMA Software Ltd does not hold the money shown in the account.

Finexer provides the regulated connection

Finexer Ltd is the FCA-authorised principal firm for the account information service. Its infrastructure communicates with supported banks, manages the regulated connection and returns the approved account information in a consistent format.

JEMA Software Ltd presents the service as Finexer's registered Account Information Services agent. The product receives the account information needed to provide the connected budgeting features. It does not receive a bank credential hidden inside the response.

Finexer and JEMA have different roles, but both are part of the path for connected account information. That is why both names appear in the regulatory and privacy explanations.

The product backend stores the working copy

The app needs a working copy of relevant account and transaction information to show history, categories, recurring activity and changes over time. Primary user data is stored using Supabase infrastructure configured for European Union servers where supported by the service configuration.

The stored record can include the original transaction fields returned through the connection and product fields added later, such as a category, a recurring-payment marker or a user correction. Keeping those fields separate matters because an interpretation made by the product is not the same as information supplied by the bank.

Database access is controlled so an authenticated user receives records associated with that account. Internal service access is limited to what is needed to operate, support and protect the product. No technical control turns sensitive data into harmless data, so access still has to be monitored and reviewed.

Other providers see narrower pieces

Not every service provider receives the full bank-data record. Different providers process different information for specific functions.

Supabase provides database, authentication and storage infrastructure. Finexer provides the open banking connection. Sentry receives error and diagnostic information used to investigate faults. RevenueCat and Apple process subscription and entitlement information, not bank card credentials held by Apple. Vercel serves the public website.

The optional assistant uses OpenAI to process a prompt and relevant context when a user chooses that feature. The amount of context sent depends on the request and product design. The assistant is not the default route for every transaction, and it is not the system that connects to the bank.

Service providers can have their own legal obligations. Contracts, data-processing terms and technical settings define how they act for the company where they are processors. The Privacy Policy lists the current providers and explains international transfers where they may occur.

What the company does not do with bank data

JEMA Software Ltd does not sell personal data. Connected bank data is not supplied to advertisers so they can target a user based on transactions. The account information connection is not used to move money, and the company does not store online banking credentials.

The product does derive information from transactions. Categorisation, recurring-payment detection and budgeting estimates all involve processing the source data. Those operations are part of providing the features, not a claim that the source description is always complete or that every inference is correct.

Website analytics are a separate system from connected app data. Visiting a public page does not give an analytics provider access to a bank account. The Privacy Policy and Cookie Policy describe the website technologies independently.

Retention is not one switch

An active account needs enough history for the features the user has chosen. Different records can have different retention needs. Account information, support messages, security logs and subscription records do not all serve the same purpose.

Disconnecting a bank stops future access through that connection. It does not necessarily delete historical information already received. Deleting the app account starts the deletion process described in the Privacy Policy. Some limited records can remain where law, fraud prevention, disputes or security require them.

Backups and operational logs can also follow controlled deletion cycles rather than disappearing from every system at the exact instant a button is pressed. Good privacy copy needs to describe that distinction instead of implying an impossible immediate wipe across all infrastructure.

What a user can control

The connection is optional. A user selects whether to connect, which eligible accounts to approve and whether the connection remains active. Open banking access can be withdrawn through the product or relevant bank controls.

UK data protection rights can include access, correction, deletion, portability, restriction and objection, depending on the circumstances and legal basis. Requests follow the contact route in the Privacy Policy. These rights concern the personal data held by the company, while disconnection concerns future collection from the bank.

The useful test for every data flow

For each provider and field, we ask four basic questions. Is this information needed for the feature? Which company receives it? How long is it retained? What control does the user have?

The answers are not made permanent by this article. Infrastructure changes and product scope can change. The commitment is to update the formal policy, keep the regulated roles clear and avoid collecting bank information simply because an API makes it available.

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