Identified at Delivery
Merchant and category resolved before the data reaches you.
Here’s what your bank actually hands your platform: AMZN MKTPLACE PMTS LUXEMBOURG REF 8A71F2. A person can decode that in a moment. Software usually can’t, and every engineer who has built a reconciliation feature knows exactly how much time that one line of text can quietly cost.
TL;DR: Transaction data is the record created whenever money moves into or out of a bank account, but not all of it is equally usable. This guide covers what a transaction record contains, where transaction data comes from, what a transaction data API should deliver and how transaction data enrichment turns a bank descriptor into something software can act on without a human translating first.
In this guide, in my capacity as Co-founder and CEO, Finexer, I, Ravi Ranjan, draw on Finexer’s work as an FCA-authorised (FRN 925695) Open Banking infrastructure provider delivering identified, categorised transaction data to UK platforms.
I believe, and have gone on record saying, transaction data creates value only when every payment record can be interpreted consistently. Engineering teams should spend their time building customer features, not decoding bank descriptors.
What a Transaction Record Contains
Every card payment, Faster Payment, Direct Debit, standing order, and refund produces a transaction record. What that record actually contains varies more between banks than most teams expect.
| Field | Purpose |
|---|---|
| Date | When the transaction was processed |
| Amount | Value entering or leaving the account |
| Direction | Credit or debit |
| Descriptor | The reference supplied by the bank |
| Running balance | Places the transaction in context |
| Merchant name / category (where available) | Identifies the business and spend type |
Banks don’t format these fields consistently. Two identical supermarket purchases from two different banks can arrive looking nothing alike, unless something standardises them first.
Each field serves a different team. Engineers use dates and balances to maintain account history. Finance teams reconcile against transaction values. Product teams need merchant identification and categorisation before a spending dashboard or budgeting feature can exist at all.
Where Transaction Data Comes From
| Source | Freshness | Structure | Audit trail |
|---|---|---|---|
| Consented Open Banking connection | Current | Consistent | Strong |
| CSV or PDF statement exports | Periodic | Varies | Moderate |
| Manual entry | Depends on the user | Inconsistent | Limited |
A consented connection delivers current records after customer authorisation, which is the difference between real-time bank data and a statement someone has to remember to export. Manual entry, by contrast, scales badly: different users record the same transaction differently, and automation has nothing consistent to work from.
The Real Problem: Descriptors vs Identified Data
A bank descriptor and an identified transaction are not the same output.
Standard Open Banking data: AMZN MKTPLACE PMTS LUXEMBOURG REF 8A71F2 After transaction data enrichment: Merchant: Amazon · Category: Retail · Type: Card payment
The payment hasn’t changed. Only the context has, and that context is what makes categorisation, reconciliation, and reporting possible without manual mapping rules. Commercial terms matter here too. Teams comparing providers on cost as well as data quality may find it useful to check yodlee pricing before settling on infrastructure.
What to Expect from a Transaction Data API
Bank coverage is only one part of evaluating a transaction data API. Structure and delivery matter just as much:
- Historical depth: supports onboarding, affordability checks, and reporting
- Refresh cadence: determines how current the data stays
- Pagination: handles large histories without performance loss
- Webhooks: flag new transactions instead of requiring constant polling
- Stable structure and clear documentation: reduce long-term engineering effort
Polling every few minutes looks harmless until it isn’t; webhook notifications react when data actually changes, with far less infrastructure overhead. For the architecture behind this, see our guide to api for bank transactions.
Enrichment Quality: What Actually Matters
Not all enrichment is equal. When comparing providers, three things matter more than a feature list:
- Merchant identification accuracy: how reliably a business is recognised across different banks
- Category consistency: whether the same merchant is grouped the same way over time
- Processing latency: how quickly enriched records become available
Finexer’s platform delivers merchant identification at 95%+ accuracy, enrichment latency under 100 milliseconds, and recognition across 100 million+ merchants, figures worth benchmarking any provider against. Teams building this evaluation into their own architecture can go deeper via our guides to data enrichment api and data enrichment tools.
Common UK use cases include automated reconciliation, accounting integrations, cash-flow monitoring, lending assessments and customer-facing spending dashboards. As platforms mature, transaction data stops being a standalone feature and becomes the infrastructure everything else sits on.
What Platforms Build With It
Identified transaction data doesn’t stay on the balance sheet. It shows up as customer-facing spending insights, affordability checks in lending journeys, and reconciliation engines that close the books without a finance team chasing descriptors line by line. The spending-insights side of this, building dashboards on top of enriched data, deserves its own evaluation and sits outside what this reference guide covers.
Where Finexer Fits
Most platforms don’t struggle to receive transaction data. They struggle to use it without building an entire descriptor-matching layer first.
Finexer Data addresses this directly: authorised account information, balances and transaction history delivered through a single API, with merchant identification and categorisation already applied. Platforms needing to move money rather than just read it can pair this with Finexer’s Payment Initiation Services over Faster Payments.
For this specific problem, what matters from Finexer Data is:
- A single API for authorised balances and transaction history
- Merchant identification and categorisation applied before delivery
- Verified accuracy and latency figures engineering teams can plan around
What should engineering teams compare first when evaluating a transaction data provider?
API stability, historical depth, webhook behaviour and merchant identification quality, in that order. These affect long-term engineering effort far more than bank coverage alone.
How is merchant identification different from merchant categorisation?
Identification answers who was paid. Categorisation answers what kind of business that is. Reporting and customer-facing features need both to work.
How can a team assess data quality before committing to a provider?
They could request sample API responses on real banking data, check merchant recognition across different banks and measure how much manual post-processing remains after integration.
Why does data consistency matter for financial products?
When identical transactions get classified differently over time, reconciliation, reporting and automation all become less dependable, regardless of how complete the raw transaction data is.
Finexer delivers enriched transaction data with merchant identification and categorisation applied at source, so teams build features instead of cleaning descriptors
Explore with AI
About the Author
Ravi Ranjan
Ravi Ranjan is Co founder & CEO of Finexer