How we think about privacy in a product that reads bank accounts

Privacy is not a settings screen added after a bank connection works. It is a set of product limits: which information enters the system, where it is copied, who can see it, how long it remains and what happens when a user leaves.

Account data makes those limits especially important. A transaction history can reveal far more than a single purchase. It can show routines, employers, travel, recurring commitments and sensitive personal activity. Read-only access prevents the product from moving money, but it does not make the information itself low-risk.

Our formal commitments are in the Privacy Policy. The principles below explain how we think about the product decisions behind it.

Collect for a named purpose

An open banking interface can expose many fields. Availability is not a reason to collect all of them.

The account information service requests data needed for connected budgeting features, such as account details, balances and transaction records. Each field needs a purpose that can be described to the user. A proposed feature that requires new information also requires a review of consent wording, storage, access and retention.

Purpose matters after collection too. Data received for a private budgeting view is not quietly reused as an advertising audience. JEMA Software Ltd does not sell personal data.

Keep the bank credential out of the product

The user authenticates in the bank's own app or website. The budgeting product does not receive the online banking username, password or passcode.

This removes an entire category of information from our systems. It also gives support a clear rule: nobody working for the product needs a customer's bank password to investigate a connection issue.

The connection uses tokens and identifiers issued through the regulated flow. Those still need protection, but they are scoped to the approved service rather than being a reusable copy of the user's bank sign-in details.

Separate source data from interpretation

The bank supplies fields such as an amount, date and description. The product can add a category, recurring-payment marker or budgeting estimate. Those layers are stored and presented differently.

That separation makes corrections possible. It also prevents an automatic interpretation from being mistaken for the original bank record. When a user changes a category, the product does not need to rewrite the source description.

Derived data can still be personal data. Calling something an insight does not remove privacy obligations. The same access, deletion and security questions apply to the interpretation as to the source record.

Limit internal access

Customer support sometimes needs enough context to understand a fault. Engineering needs diagnostics when a data import fails. Neither role requires unrestricted routine access to every account.

Systems are designed around authenticated user access and restricted service access. Internal tools and database permissions need a defined reason, logging and review. Sensitive values should not be copied into chat messages, issue titles or screenshots merely because those places are convenient.

No access-control system is infallible. The practical standard is to reduce access, monitor it and have an incident process for the cases where a control fails.

Treat optional features as optional data paths

The assistant is not the default processor for the whole transaction history. When a user chooses to ask it a question, the service can send the prompt and relevant context to OpenAI to produce a response. The feature can make mistakes and is separate from the open banking connection.

An optional feature should not become a reason to expand every other data flow. The interface needs to make the action clear and the Privacy Policy needs to identify the provider involved.

Website analytics and advertising technologies are also separate from app account data. Cookie choices on a public site do not authorise access to a connected bank account.

Retention needs more than one date

Different records exist for different reasons. Transaction history supports historical views. Security logs support investigation. Subscription records document access. Support messages provide continuity when a user contacts the company.

The retention schedule distinguishes those purposes instead of placing every record in one permanent archive. Account deletion triggers deletion or anonymisation within the period stated in the Privacy Policy, except where limited records have to remain for legal, dispute, fraud-prevention or security reasons.

Disconnecting a bank and deleting an account are different actions. Disconnection stops future access through that consent. Account deletion addresses the personal data already held by the product. Explaining that difference is part of privacy, because a button label should not promise an action the system does not perform.

Design for departure as well as arrival

Many product journeys are polished at sign-up and vague at exit. A bank-connected product needs a visible route to disconnect and a clear account-deletion process.

The user also has data-protection rights that exist independently of product buttons. Requests for access, correction, deletion, portability, restriction or objection follow the contact route in the Privacy Policy and depend on the relevant circumstances and legal basis.

Avoid absolute security language

Encryption, row-level access rules, monitoring and provider reviews are controls. They reduce specific risks. They do not justify saying that data is completely safe or that a breach is impossible.

Honest privacy language identifies what is protected, which company processes it and where limits remain. It also changes when the system changes. A policy that describes last year's architecture is not useful simply because it has a recent date at the top.

The core principle is restraint. Collect the information needed for the service the user selected. Keep credentials at the bank. Limit copies and access. Explain optional processing. Make disconnection and deletion distinct. Then revisit each decision when the product changes.

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