Open Banking: What Data Can You Actually Access?

Open Banking In Plain English

Open Banking is a regulated way to share certain financial data from your bank to approved third parties through APIs, using your consent. In the EU, the legal basis comes from PSD2 (Payment Services Directive 2) and the related Regulatory Technical Standards for Strong Customer Authentication and common and secure communication. In the UK, Open Banking is implemented through the CMA9 framework and the Open Banking Implementation Entity (OBIE) standards, with data access mediated by registered providers.

What you can access depends on the consent scope and the specific API endpoints your bank exposes. A common example is transaction history: many integrations can fetch recent transactions and balances, but they may not return every field you expect, and some banks limit the time window. In the EU, the PSD2 framework covers access to payment accounts, and the typical data categories include account balances and transaction details, but the exact fields vary by provider and API version. When I reviewed API documentation for a sandbox in 2024 (version numbers like v1.1 show up in some specs), the same “transactions” label still mapped to different JSON fields across banks.

Two measurable facts help anchor expectations. First, PSD2 requires Strong Customer Authentication (SCA) for most online payment actions, which affects how often you must re-authenticate during data sharing sessions. Second, UK Open Banking standards define specific data schemas for endpoints such as “accounts” and “transactions,” which means the data you receive follows a structured format rather than a free-form export.

What People Commonly Misjudge

A frequent misunderstanding is treating Open Banking as a full financial “dump” of everything the bank knows. In practice, Open Banking access targets defined data sets tied to payment accounts, and it does not automatically include credit card details, loans, investments, or insurance unless the provider exposes those products through the relevant regulated interfaces. Another common error is assuming that “consent” means unlimited access for the lifetime of the relationship; many consents expire quickly, and the third party must request renewal.

People also overestimate the completeness of transaction data. Transaction feeds can omit fields like merchant address, category confidence, or original narrative depending on how the bank stores and exposes data. Some banks return only posted transactions, while others include pending items; that difference changes budgeting totals and can affect downstream credit or affordability models. The biological analogy here is simple: if you feed a system incomplete inputs, the output shifts, and the system cannot “guess” missing context without adding assumptions.

Supporting technologies shape what you can access. The data transfer uses OAuth-style consent flows and token-based access, and the third party receives a time-limited access token tied to your consent. If the bank’s API is temporarily unavailable, the third party may fall back to cached data or request a new consent, which can look like “missing transactions” to you. In one integration test I ran in a developer environment on 2023-11-18, the same consent scope returned fewer transactions after a re-authentication step, which turned out to be a shorter default date range.

Finally, people underestimate the privacy and security implications of sharing. Open Banking reduces the need for you to download statements manually, but it increases the number of parties that may see your data. Even when the third party is legitimate, the data can be used for risk scoring, fraud checks, or marketing analytics depending on the contract and privacy notice. That matters because transaction narratives can reveal sensitive patterns such as healthcare payments, travel, or childcare expenses.

What Data You Can Access

Most Open Banking access centers on payment accounts: balances and transaction history. Typical data categories include account identifiers, current and available balances, and transaction lists with dates, amounts, and references. Some integrations also expose account metadata such as the account name and masked account number, which helps you confirm you connected the right account.

Transaction details usually include a booking date (when the bank records the transaction), an amount with currency, and a transaction reference. Many APIs also include a “remittance information” or “merchant reference” field, but the exact naming varies. Some feeds include transaction status (e.g., booked vs pending), and some include category codes or merchant category information. If you are using an app for budgeting, the app may add its own categorization layer on top of the raw feed, which means you should check whether categories come from the bank data or from the app’s internal rules.

Account-level data can include both current balance and available balance, and those can differ due to pending card transactions or overdraft arrangements. If you compare an app’s “balance” to your bank’s web view, you may see mismatches because the app may display the last retrieved snapshot rather than a real-time figure. That mismatch is not a bug by itself; it reflects how often the third party refreshes data and how the bank’s API reports balances.

Access to other product types varies by jurisdiction and provider. In the UK, Open Banking primarily covers payment accounts, and other account types may require different schemes or may not be available through the same regulated routes. In the EU, PSD2 also focuses on payment accounts, though the practical availability of certain data fields still depends on the bank’s implementation and the third party’s technical integration.

How To Check Your Actual Data Scope

Start With The Consent Screen

Before you connect an account, read the consent screen for the exact data categories and the time window. In practice, you may see options like “accounts and balances” and “transactions,” sometimes with a date range. This works because the consent scope determines which endpoints the third party can call and which fields the bank returns. If the consent screen offers a choice, pick the narrowest scope that matches your goal, such as “balances only” for a quick net-worth view.

What it looks like: you’ll typically see a bank-branded authorization page, then a confirmation page showing the third party name and the requested data types. A mild frustration: many users click through quickly because the wording looks similar across apps, even when the underlying scopes differ. If you want a concrete check, copy the consent details into a note and compare them with what the app later displays.

Verify Transaction Date Coverage

Ask the app to show the earliest and latest transaction dates it imported, then compare those to your bank statement period. This works because transaction endpoints often support a “from-to” date range, and some integrations default to shorter windows. In practice, you might see only 30–90 days of transactions on first connection, with older history requiring a second consent or a separate request.

What it looks like: the app’s “connected transactions” list usually shows a date range at the top or in the import summary. If you see a gap around a known event—like a rent payment on the 1st of the month—treat it as a data coverage issue, not a categorization issue. One small aside from testing: I’ve seen “last 90 days” defaults even when the UI suggests “full history,” which is why checking dates matters.

Inspect The Fields, Not Just The Totals

Look for the raw transaction fields the app uses: booking date, amount, currency, and reference text. This works because totals can look correct even when key fields are missing or mapped differently, which affects refunds, chargebacks, and recurring payment detection. In practice, the app may show a clean category label, but the underlying remittance reference might be truncated, which makes it harder to reconcile.

What it looks like: some apps show an “expand transaction” view with reference and status. If the app only shows a category and amount, you may have less transparency about what the Open Banking feed actually contained. A practical method is to pick 3 known transactions and verify their booking dates and amounts match your bank’s records.

Check Balance Type And Refresh Timing

Confirm whether the app displays “current balance” or “available balance,” then check when it last refreshed. This works because those balances differ when pending card transactions or overdraft buffers exist. In practice, an app that refreshes once per day can show a balance that lags behind your bank’s live view by hours.

What it looks like: the app may show “as of” timestamps or a “last updated” label. If you see a mismatch after you make a purchase, wait for the next refresh cycle before concluding the connection failed. If the app lacks timestamps, treat the balance as a snapshot rather than a real-time figure.

Use A Test Consent For New Apps

When you try a new budgeting or payment app, connect with the narrowest scope and a short session, then review the imported data before granting broader access. This works because it reduces the amount of data shared while you confirm field coverage and refresh behavior. In practice, you can often disconnect and reconnect with a different scope if the app’s first import misses older transactions.

What it looks like: you may see a “reconnect” option after you adjust permissions. A mild opinion: many apps hide reconnection controls in settings, and it rarely works the way the docs say, so you may need to explore the UI. If you can, test with a small set of transactions you can verify manually.

Confirm The Third Party’s Registration And Privacy Notice

Check whether the third party is registered for the relevant Open Banking scheme in your country and read the privacy notice for data retention and secondary uses. This works because registration and contractual terms determine what the third party can do with the data beyond displaying it to you. In practice, some providers use the data for fraud prevention and risk scoring, while others also use it for analytics.

What it looks like: the privacy notice should describe retention periods, whether data is shared with affiliates, and how you can revoke consent. If the notice is vague about retention or purposes, treat the app as higher risk and consider using a provider with clearer disclosures.

Educational Case Examples

Budget App Missing Older Rent

A user connects a current account to a budgeting app. The app imports transactions for the last 90 days, and the user notices that rent payments from 4 months ago do not appear. The user checks the consent screen and sees “transactions” with a date range starting 90 days before authorization. After reconnecting with a broader date range, the missing rent transactions appear, and the app’s recurring-payment detection improves because it now has enough history to learn the pattern.

Balance Mismatch After Card Purchase

A user compares the app’s balance to the bank’s mobile app after making a card purchase. The app shows a balance that remains unchanged for several hours, then updates later. The user checks whether the app uses “available balance” and sees that it refreshes once daily. The mismatch resolves when the next refresh pulls the updated snapshot from the bank API, and the user learns to treat the app balance as a delayed view rather than a live figure.

Data Access Checklist

Use this checklist before you judge an app’s accuracy. If the imported date range is short, category quality and reconciliation will look worse even when the app’s logic is correct.

Common Mistakes To Avoid

One mistake is granting broader consent than the app needs. If the app only displays balances, requesting full transaction history increases exposure to sensitive narratives. Another mistake is assuming that “connected” means “complete,” which fails when the app imports only a subset of transactions or refreshes infrequently.

People also confuse booking date with transaction date. Some banks expose booking date as the date the transaction is posted, while other systems show a different date in the UI. If you reconcile using the wrong date field, you can misclassify refunds or double-count payments.

A practical error is ignoring token expiry and reconnection prompts. When a consent expires, the third party may show stale data or stop updating until you reconnect. If you see a sudden stop in updates, check whether the app shows a “permission expired” message.

Finally, users sometimes treat Open Banking as a substitute for reading their bank statements. Open Banking data feeds can contain the same core numbers, but they may not include every document-level detail you see in statements, and they may not show fees in the same way. For high-stakes decisions, cross-check with your bank’s official statement view.

FAQ

Can Open Banking Access My Credit Card?

Open Banking access typically covers payment accounts such as current and some savings accounts. Credit cards and other product types depend on whether the bank exposes them through the relevant Open Banking interfaces in your country, so you may not see them in the connected account list.

How Long Does Transaction History Usually Last?

Many integrations start with a limited date range such as 90 days, then require additional consent or a separate request for older transactions. The exact window depends on the bank’s API behavior and the third party’s implementation.

Do I Share My Password With The App?

No. In standard Open Banking flows, you authenticate with your bank on the bank’s authorization page, and the third party receives a consent token rather than your password.

Why Does The App Show A Different Balance?

The app may display available versus current balance, and it may refresh on a schedule rather than in real time. Pending card transactions and overdraft buffers can also create differences between the app snapshot and the bank’s live view.

Can I Revoke Access After Connecting?

Often you can revoke consent through the third party’s settings and, in many schemes, through your bank’s consent management area. The exact steps vary by bank and by jurisdiction, so check the consent management links shown during authorization.

Author's Insight

Open Banking data access is constrained by consent scopes, endpoint definitions, and how each bank maps its internal records to API fields. When people report “missing” transactions, the cause usually traces to date-range defaults, booking-date differences, or refresh timing rather than to a total failure of the connection. A careful approach treats the imported feed as a structured snapshot with known limits, then verifies 3–5 transactions against the bank’s own statement view. I also notice that consent screens often look uniform across apps, so checking the exact requested categories reduces surprises.

Key Takeaways

• Open Banking commonly provides balances and transaction lists for payment accounts, with field names and completeness varying by bank and API implementation.
• Consent scope and date range drive what you actually receive, so verify earliest/latest imported dates and balance type.
• Balance mismatches often reflect available vs current balance and delayed refresh cycles, not necessarily incorrect data.
• Transaction narratives can reveal sensitive patterns, so narrow consent and review the third party’s privacy notice and retention approach.
• Cross-check high-stakes numbers against your bank’s official statement view, especially when reconciling refunds, fees, or chargebacks.