What Open Banking Data Can and Cannot Reveal About Consumers

I spent about ten years on the account side of a personalisation platform, sitting in the reviews where a brand’s data was supposed to explain its customers. The failure I saw most often was neither sinister nor sophisticated. It was a company reading more into a record than the record could carry.

Most of that reading happened on behavioural data: page views, dwell time, scroll depth, the trail a person leaves while moving around a site. The trouble with a trail is that it is almost unique to whoever left it. That sounds like an advantage and behaves like the opposite, because when every pattern is particular, working out what any of them means becomes guesswork wearing the costume of analysis. Recorded payments sit on firmer ground, since a payment is a decision the customer actually completed.

Firmer is not the same as complete, and this is where open banking is routinely oversold.

Open-banking data describes financial activity visible in connected accounts. It can show that a payment was recorded, its amount and timing, the account involved, and whatever merchant or counterparty information the provider made available. Depending on the data and the analytical method, it can also support estimates of recurring commitments, income cadence, expenditure patterns, cash-flow pressure and differences between cohorts.

That does not make a transaction a record of intention. A card payment does not normally state why the purchase was made, whether the customer was satisfied, who in a household chose it, whether it was a gift, or whether the thing bought was ever used. A missing payment does not explain its own absence. A connected account is also not automatically a complete financial view, because other accounts, cash spending and activity outside the available period may all be missing.

The useful question is therefore not, “What does the data know about this person?” It is:

What was observed, what transformation produced the analytical output, how was it validated, and how much uncertainty remains?

This article explains that method. For the separate question of whether an insight should be allowed to change a message, offer or service, see responsible open-banking personalisation.

A note on the evidence below. This article draws on two kinds of support and keeps them apart. Claims marked with a superscript number, such as ^[1], come from published regulatory, standards, vendor or academic sources, all listed in full at the end. Passages headed “From the account side” are my own first-hand observations from client work. They are one practitioner’s experience rather than research, the organisations are described rather than named, and they carry no citation number.

What counts as an open-banking consumer insight?

An open-banking consumer insight is a documented analytical conclusion derived from authorised account information and, where appropriate, other research or first-party data.

A defensible insight has six parts:

1. Population: Which customers, accounts, providers and time periods are included?
2. Observation: Which source fields are used?
3. Transformation: Which cleaning, enrichment, categorisation or modelling steps are applied?
4. Output: What measure, label or pattern is produced?
5. Validation: How was the output checked against an appropriate reference?
6. Uncertainty: Which omissions, errors and alternative explanations remain?

“Thirty per cent of observed outgoing value in the connected current-account sample was categorised as groceries during the twelve-week study window” is an analytical statement. “These customers care more about healthy eating” is a motivational claim that the transactions alone do not establish.

What transaction data normally contains

Open Banking Limited describes account-information access as access to information from online payment accounts that the customer has authorised an Account Information Service Provider to access ^[1]. Its transaction resource retrieves records for a specified account or authorised set of accounts ^[2].

A transaction record will commonly include some combination of:

• a transaction identifier;
• credit or debit direction;
• amount and currency;
• booking date and, where available, value date;
• booked, pending or another status;
• the account context;
• a raw narrative, reference or bank transaction code;
• merchant or counterparty data when supplied;
• optional enriched fields produced by a provider or analytics service.

The exact fields differ by provider, account type, permission and status. Open-banking data clusters also distinguish basic transaction information from more detailed payer or payee information ^[3]. Merchant name, category and location should therefore not be assumed to be native, complete or equally reliable across sources.

What a connected account does not show

A connected account generally does not directly reveal:

• the customer’s motivation;
• satisfaction or dissatisfaction;
• whether a purchased product was used;
• who in a household made the decision;
• whether the payment was for the account holder, another person or a gift;
• the customer’s complete assets, liabilities, income or expenditure;
• activity in unconnected accounts or providers;
• expenditure paid in cash;
• why an expected payment did not occur;
• informal transfers of value or unpaid household activity;
• the context needed to interpret a sensitive transaction safely.

Research reviews of household transaction data explicitly identify cash and cheque limitations, as well as the fragmented sources from which transaction datasets are assembled ^[4]. The right response is not to abandon the data. It is to define the observable boundary before interpreting the result.

Data-access and coverage limitations

Coverage has several dimensions.

Account coverage

Record which accounts the customer connected, which account types are available and whether the service covers personal, joint or business accounts. Never translate “all authorised accounts in this connection” into “all of the customer’s finances”.

Provider coverage

Providers can differ in field availability, transaction descriptions, pending-data handling and refresh behaviour. Analyse missingness by provider rather than treating it as random.

Time coverage

A short window can misclassify annual costs, irregular income, school-term patterns or seasonal spending. State the observation period and whether it contains comparable calendar events.

Payment-rail coverage

Cash, paper cheques, some wallets, stored value and transactions routed through intermediaries may be absent or difficult to interpret. An ATM withdrawal shows access to cash, not what the cash was used for.

Consent and continuity

Authorisation can expire, be withdrawn or cover a reduced set of accounts. A time series may contain a connection break rather than a genuine change in behaviour.

Create a coverage table before analysis. At minimum it should report connected-account count, provider mix, earliest and latest valid dates, missing days, share of pending records, percentage of records with merchant or counterparty data, and the treatment of disconnected accounts.

From the account side. A large cosmetics group once wanted a single view of its customers across its stores and several separate online properties. Those systems had never shared a customer identity, so every time somebody bought through a channel the receiving database had not seen before, the purchase was filed as a brand new person. Category tracking had drifted just as far. The “most purchased category” export they sent over contained category names that meant nothing to anyone reading them. They eventually paid a CRM vendor a considerable amount to untangle it. None of that was exotic, and nobody involved was careless. Coverage and identity gaps are the ordinary condition of multi-channel data, and connecting a bank account does not repair them. It adds one more source whose boundaries have to be written down before anybody interprets what is inside.

Transaction cleaning and normalisation

Raw records should not move straight into insight reporting.

Input data: transaction identifier, amount, direction, status, dates, currency, account identifier and raw narrative.

Transformation: standardise signs and currencies; reconcile pending and booked versions; remove exact duplicates; retain a lineage key; normalise timestamps; flag reversals; and define rules for incomplete records.

Output: a canonical transaction table in which one economic event is represented once, with original fields preserved alongside transformations.

Validation: reconcile counts and values against account totals where available; inspect duplicate and pending-to-booked matches; compare provider-level exception rates; and manually review a stratified sample.

Known error sources: pending records can change; identifiers may not persist; foreign-currency purchases can contain multiple amounts; tips or incremental authorisations can alter totals; and connection retries can duplicate records. Vendor documentation likewise warns that pending transaction details can change before posting ^[5].

Appropriate use: producing stable analytical inputs and reproducible period totals.

Inappropriate use: silently overwriting raw records or deleting exceptions merely because they complicate the analysis.

Merchant enrichment

A bank narrative may contain a merchant, payment processor, location fragment, terminal reference or an abbreviated string. Merchant enrichment attempts to map that string to a recognisable entity.

Input data: raw transaction narrative, counterparty fields, payment method, location fragments, provider codes and sometimes external merchant directories.

Transformation: deterministic matching, alias tables, entity resolution and probabilistic classification may be used to identify a merchant and related metadata.

Output: an enriched merchant label, possible parent brand, confidence score, match method and provenance.

Validation: maintain a labelled test set across major providers and long-tail merchants; calculate precision and coverage separately; review false mergers and false splits; and monitor drift after provider-format changes.

Known error sources: payment facilitators can mask the underlying merchant; franchise names can differ from parent brands; small merchants may have sparse reference data; marketplace transactions may identify the platform rather than the seller; and location may refer to registration or processing rather than the customer’s physical presence. Plaid’s documentation, for example, describes merchant_name as an enriched field and allows it to be null, while TrueLayer includes an UNKNOWN transaction classification ^[5][6]. These are product-specific capabilities, not proof of universal accuracy.

Appropriate use: aggregate merchant trends, customer-facing transaction search with correction options, or low-risk research where uncertain matches are excluded.

Inappropriate use: treating every enriched merchant as ground truth, inferring a visit to a precise location from ambiguous metadata, or making a consequential decision from one uncertain match.

Transaction categorisation

Categorisation maps transactions into a defined taxonomy such as groceries, housing, transport or transfers.

Input data: cleaned transaction fields, enriched merchant, bank code, amount, direction, recurrence pattern and raw narrative.

Transformation: rules or a statistical model assign a category and confidence. A hierarchy may produce a broad category first and a detailed subcategory second.

Output: category, subcategory, confidence, model or rule version, and an explicit unknown or ambiguous state.

Validation: compare predictions with independently labelled transactions; report precision, recall and confusion by category; test across providers and customer groups; and track the share left unclassified. Accuracy should never be stated without the population, taxonomy, labelling procedure and metric definition.

Known error sources: general retailers sell many categories; marketplaces obscure basket composition; merchant category codes describe the merchant, not every item; transfers can resemble expenditure; and refunds can inherit inconsistent labels.

Appropriate use: broad aggregate expenditure analysis, customer budgeting views with editable labels, and cohort comparisons using stable high-level categories.

Inappropriate use: asserting the exact product purchased, diagnosing a sensitive condition, or interpreting a category as a motive.

Recurring-payment identification

Recurring-payment detection looks for repeated outgoings or income with similar counterparties, amounts and timing.

Input data: normalised counterparty or merchant, amount, direction, booking date, payment type and transaction reference.

Transformation: group likely related transactions; calculate interval regularity and amount variation; distinguish standing orders or direct debits where explicit codes exist; and score the probability of recurrence.

Output: candidate recurring series, expected interval, usual amount range, next expected window and confidence.

Validation: back-test whether an identified series recurs in a later hold-out period; compare with explicit payment-instruction data where available; and review false positives such as frequent shopping at the same merchant.

Known error sources: variable utility bills, four-weekly pay, holidays, skipped months, annual renewals, merchant-name changes, retries and one-off repeated purchases.

Appropriate use: subscription views, cash-flow planning, reminder services and aggregate analysis of regular commitments.

Inappropriate use: declaring a contract active solely because historical payments recur, treating a missed payment as cancellation, or assuming the account holder chose the commitment.

Income and expenditure estimation

Income and expenditure estimates are summaries of observed flows, not complete statements of a person’s finances.

Input data: credits and debits, counterparty or reference, recurrence, payment type, account balance where authorised, and declared information when available.

Transformation: separate transfers from external flows; classify likely employment, benefits, pensions, refunds and other credits; group expenditures; and calculate robust ranges rather than relying only on a single average.

Output: observed income cadence, observed expenditure distribution, volatility and confidence by component.

Validation: ask customers to confirm material sources and obligations when the decision requires it; compare estimates with declared information or documentary evidence appropriate to the purpose; and test performance for irregular earners, joint accounts and multi-account customers.

Known error sources: salary paid into another account; self-employment receipts mixed with turnover; reimbursements mistaken for income; internal transfers; shared bills; cash; annual expenses; and a short observation period.

Appropriate use: descriptive research, optional budgeting support, or an input to a wider process where the limitations are explicit.

Inappropriate use: claiming that transaction data alone proves disposable income, affordability, product eligibility or the customer’s full financial position. In regulated credit contexts, the FCA distinguishes affordability risk and requires proportionate consideration of income and non-discretionary expenditure, and a marketing estimate is not a substitute for the applicable assessment ^[7].

Cash-flow and seasonality analysis

Cash-flow analysis examines the timing and variability of observed inflows, outflows and balances.

Input data: dated credits and debits, balances where available, recurring-series labels, account coverage and calendar features.

Transformation: build a dated series; separate recurring and irregular components; measure volatility; and identify seasonal or calendar effects using a period long enough to contain them.

Output: observed cash-flow shape, timing risk indicators and seasonal patterns with confidence intervals.

Validation: compare predicted and actual future periods; test stability across providers and account types; and check whether apparent seasonality survives in an independent window.

Known error sources: paydays moving around weekends, transfers between accounts, temporary large purchases, refunds, annual bills and missing accounts. Research that links payment timing with behaviour commonly combines transaction records with survey measures rather than reading mental state directly from the ledger ^[8].

Appropriate use: optional customer planning tools, service capacity planning and aggregate research into timing effects.

Inappropriate use: treating a single low balance as proof of hardship, or using salary timing to apply commercial pressure.

Customer and cohort analysis

Cohorts compare defined groups over a common period or event.

Input data: validated transaction measures plus an explicit cohort definition such as connection month, product tenure or declared customer need.

Transformation: align observation windows; control for provider and coverage differences; calculate distributions rather than only means; and apply minimum sample rules.

Output: group-level differences, trajectories and uncertainty.

Validation: check sensitivity to cohort definitions, outliers and missing accounts; use pre-specified hypotheses where possible; and replicate the analysis in a later period.

Known error sources: selection bias in who connects accounts, survivorship bias, changing provider mix, small samples and confounding variables.

Appropriate use: generating hypotheses, service research and prioritising questions for further study.

Inappropriate use: treating a correlation as a causal effect or applying a group average as a fact about each member.

From the account side. A luxury fashion house told me its primary digital target was women over 40. That was the house profile, and it had been built on the clientele who walk into the boutiques. When we looked at who was actually completing purchases on the website, it was women roughly between 27 and 40, and men roughly between 25 and 35. Nothing in the underlying data was wrong. The cohort was. People who buy from you in a shop and people who buy from you online are not necessarily the same people, and a transaction dataset will happily return clean, confident averages for a group that was defined incorrectly before the analysis began.

For a broader framework for constructing and activating segments, use Herm.io’s guide to customer segmentation for personalised marketing. This page should stay focused on data provenance and analytical validity.

Transfers, refunds and internal movements

Transfers and refunds can materially distort expenditure and income estimates.

A practical workflow should:

• identify likely transfers using explicit codes, account ownership, matching amounts and close timestamps;
• avoid assuming every round-number payment is a transfer;
• link refunds to probable original purchases without deleting either record;
• treat chargebacks, reversals and reimbursements separately;
• report gross flows and adjusted external flows;
• preserve uncertain cases instead of forcing a label.

A transfer between two connected accounts is not new income or new expenditure at the customer level. A transfer to an unconnected account may be internal, external saving, a payment to another person or something else entirely. Report the classification rule and the uncertainty that survives it.

Joint, business and multi-user accounts

Account ownership changes interpretation.

A joint account records account activity, not which joint holder initiated or benefited from each transaction. A family card or supplementary card can contain activity by several people. A business account may mix expenses, tax, payroll, owner drawings and revenue. A sole trader may have blurred personal and business flows.

Before individual-level analysis:

• capture account type and known ownership structure;
• exclude or separately model accounts whose purpose differs;
• do not assign sensitive activity to one individual without reliable attribution;
• state whether the analytical unit is transaction, account, customer or household;
• avoid household-level conclusions when only one member has connected data.

Inferring motivation: where analysis becomes speculation

Transaction analysis can identify patterns. It rarely establishes why those patterns occurred.

Consider a payment to a pharmacy. The record may support the statement that a payment to a merchant classified as a pharmacy was observed. It does not establish whether the purchase was medication, toiletries, a gift, a prescription collected for someone else or a delivery fee. It cannot safely establish a diagnosis.

The same caution applies to:

• gambling merchants and problem gambling;
• donations and political or religious belief;
• maternity retailers and pregnancy;
• mobility aids and disability;
• debt payments and financial distress;
• luxury purchases and wealth;
• salary changes and job loss;
• travel spending and a permanent life event.

Use three labels in reporting:

• Observed: directly present in the source record.
• Derived: produced by a documented transformation.
• Hypothesised: one possible explanation requiring further evidence.

Only the first two should normally appear in operational datasets, and derived fields should retain confidence and provenance.

Combining transaction data with declared research

Declared data and observed transaction data answer different questions.

Declared research can capture goals, motivations, satisfaction, household context, expected changes and correction of ambiguous records. Transaction data can reduce recall burden and provide detailed timing for recorded financial events. Neither source is inherently more truthful. Each has measurement error, missingness and context limitations.

Useful triangulation methods include:

• asking participants to annotate a sample of their own transactions;
• linking survey responses to aggregate transaction measures with clear permission;
• conducting interviews after identifying an aggregate pattern;
• comparing transaction-derived estimates with customer-confirmed obligations;
• using service and complaint data to test whether an apparent pattern reflects a real need.

Academic work has combined transaction data with surveys to study payday effects, demonstrating the value of using direct measures of cognition or reported behaviour alongside financial records ^[8]. The principle is broader: do not ask the ledger to answer a question that requires the customer’s own account of their circumstances.

Validating an insight

Validation should match the intended use.

Technical validation

Test duplicates, missing fields, status transitions, currency handling and provider consistency.

Label validation

For merchant, category or recurrence labels, use independent human-labelled samples and report errors by class, not only one overall score.

Temporal validation

Fit or define the method on one period and test it on a later period. Seasonality and provider changes can make random record splits misleading. A method that validated cleanly last year is not automatically valid now, because customer behaviour, provider formats and merchant populations all move.

Population validation

Compare performance across providers, account types, income patterns and relevant customer groups. A method that performs well for salaried single-account customers may fail for irregular earners or joint households.

Construct validation

Ask whether the output actually represents the concept named. “Observed credits classified as salary” is not automatically “total income”, and “low balance” is not automatically “financial vulnerability”.

Decision validation

When an insight will influence a customer-facing decision, validation must also include fairness, customer understanding and harm tests. That governance belongs in personalisation decisions and guardrails.

Reporting confidence and uncertainty

Every material insight should be accompanied by a compact evidence statement:

Measure: median observed monthly grocery-category debit value. Population: customers with at least one continuously connected personal current account for six complete months. Coverage: connected accounts only, cash excluded. Method: cleaned booked debits, transfer-adjusted, high-confidence category labels only. Validation: category precision assessed on a stratified labelled sample. Uncertainty: general retailers and marketplaces may be under-classified or misclassified, and household attribution is unknown.

Where a score is used, publish the confidence bands and the action associated with each band. Do not use excessive decimal precision. Suppress results when sample size or coverage is insufficient.

From the account side. The question I was asked most often in client reviews was which single number to watch. There isn’t one, and the search for it is itself the problem. A conversion-rate uplift can sit directly on top of a fall in average order value, so the campaign looks like a clear win in the deck while doing nothing at all for revenue. Any statistic read in isolation will mislead you eventually. The same applies to an insight reported without its coverage and its error rate, because the number will travel through the business long after the caveats have been left behind in the original document.

Privacy-preserving aggregation

Aggregation reduces exposure but does not automatically make information anonymous. The ICO describes anonymous information as information that no longer relates to an identified or identifiable person ^[9]. Pseudonymisation replaces or separates identifiers, but pseudonymised personal data remains within data-protection law ^[10].

For insight work:

• minimise fields before analysis;
• separate identity and analytical keys;
• limit raw-data access;
• aggregate to the least granular level that answers the research question;
• apply minimum cohort thresholds;
• assess singling-out and linkage risk;
• avoid publishing rare merchant or location combinations;
• define retention and deletion rules;
• document who can re-identify records and for what purpose.

For broader organisational practice, see Herm.io’s guides on ethical use of consumer data and privacy-safe personalisation.

Insight-quality checklist

Before publishing or activating an open-banking insight, confirm that:

• the authorised accounts, providers and dates are defined;
• raw and enriched fields are distinguished;
• pending, duplicate, refund and transfer handling is documented;
• joint, business and multi-user accounts are considered;
• cash and unconnected-account gaps are stated;
• the taxonomy and model version are recorded;
• unknown and low-confidence outputs are retained rather than forced;
• validation uses an independent reference and reports class-level errors;
• correlation is not presented as motivation or causation;
• sensitive inferences are excluded or subjected to specialist review;
• aggregate reporting includes sample and uncertainty thresholds;
• the output has an owner, review date and permitted-use statement.

Frequently Asked Questions

Conclusion

Open-banking consumer insight holds up when the analytical chain stays visible. Start with the financial event, keep its account and provider context attached, document every transformation, validate the output against something independent and say plainly what is missing.

The discipline underneath all of it is straightforward, even if applying it under commercial pressure is not. A transaction is evidence that a recorded financial event occurred. It is not, by itself, an explanation of the customer. In ten years of client reviews I never once saw a programme fail because its data was insufficiently granular. The failures came from confident conclusions built on records that could not support them, and from teams who had stopped asking what the number left out. The strongest programmes use transaction data to ask better questions, bring in declared research when context is needed, and carry their uncertainty all the way through to the decision rather than dropping it somewhere between the analysis and the slide.

For wider market context, see the rise of open banking and its opportunities for marketers. For current developments, use open-banking trends for brand marketers. For customer connection and adoption, use open-banking opportunities for enhanced consumer engagement. For activation architecture, use enhancing marketing strategies with open-banking data.

Sources

1. Open Banking Limited. “Account Information Services.” Open Banking Standards: Customer Experience Guidelines. Published 18 March 2026. https://standards.openbanking.org.uk/customer-experience-guidelines/account-information-services/latest/ Classification: Official open-banking standard and guideline. Interest disclosure: Open Banking Limited operates and develops the UK Open Banking Standard. It is authoritative on its own standard, not independent evidence of consumer outcomes.

2. Open Banking Limited. “Transactions, v3.1.11.” Read/Write API Standards. Version 3.1.11, publication date not shown, accessed 28 July 2026. https://openbankinguk.github.io/read-write-api-site3/v3.1.11/resources-and-data-models/aisp/Transactions.html Classification: Official technical standard. Interest disclosure: Same institutional interest as above. Used only to define the resource and its scope.

3. Open Banking Limited. “Permissions and Data Clusters for AIS journeys.” Open Banking Standards: Customer Experience Guidelines. Version 3.1.9, date not shown, accessed 28 July 2026. https://standards.openbanking.org.uk/customer-experience-guidelines/account-information-services/permissions-and-data-clusters/v3-1-9/ Classification: Official technical and customer-experience standard. Interest disclosure: Same institutional interest as above. Used for field and permission distinctions.

4. Baker, Scott R. and Lorenz Kueng. “Household Financial Transaction Data.” Annual Review of Economics 14 (2022): 47 to 67. Published August 2022. DOI: 10.1146/annurev-economics-051520-023646. https://www.annualreviews.org/content/journals/10.1146/annurev-economics-051520-023646 Classification: Peer-reviewed review article. Interest disclosure: The authors review a research field in which they participate. No commercial vendor interest was identified in the source metadata reviewed.

5. Plaid Inc. “API, Transactions.” Plaid Docs. Continuously updated, accessed 28 July 2026. https://plaid.com/docs/api/products/transactions/ Classification: Official commercial product documentation. Interest disclosure: Plaid sells data-connectivity and enrichment products. Product capabilities must not be generalised into independent accuracy claims.

6. TrueLayer Ltd. “Transaction data reference.” TrueLayer Docs. Continuously updated, accessed 28 July 2026. https://docs.truelayer.com/docs/transaction-data-reference Classification: Official commercial product documentation. Interest disclosure: TrueLayer sells open-banking connectivity and data products. Used only to document possible field values and acknowledged unknowns.

7. Financial Conduct Authority. “CONC 5.2A Creditworthiness assessment.” FCA Handbook, Consumer Credit Sourcebook. Rules effective from 1 November 2018, current page accessed 28 July 2026. Official identifier: CONC 5.2A. https://handbook.fca.org.uk/handbook/conc5/conc5s6 Classification: Official regulator rulebook. Interest disclosure: The FCA is the UK conduct regulator. The source is authoritative for the cited rule, and is not legal advice for every product or case.

8. Carvalho, Leandro S., Stephan Meier and Stephanie W. Wang. “Poverty and Economic Decision-Making: Evidence from Changes in Financial Resources at Payday.” American Economic Review 106, no. 2 (February 2016): 260 to 284. DOI: 10.1257/aer.20140481. https://www.aeaweb.org/articles?id=10.1257/aer.20140481 Classification: Peer-reviewed empirical research. Interest disclosure: No commercial vendor interest was identified in the publisher metadata reviewed. The study population and design should not be generalised to all customers.

9. Information Commissioner’s Office. “Introduction to anonymisation.” UK GDPR Guidance and Resources. Current page accessed 28 July 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/introduction-to-anonymisation/ Classification: Official regulator guidance. Interest disclosure: The ICO is the UK data-protection regulator. Guidance may be updated and does not replace case-specific legal analysis.

10. Information Commissioner’s Office. “Pseudonymisation.” UK GDPR Guidance and Resources. Current page accessed 28 July 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/ Classification: Official regulator guidance. Interest disclosure: Same regulatory interest and limitation as above.