Open Finance
How to Use Transaction Data from Open Banking APIs
A practical guide to accessing and using bank transaction data through open banking APIs. Covers data types, enrichment, use cases, and integration patterns.
Transaction data is the most valuable dataset available through open banking APIs. Every payment, transfer, direct debit, and card purchase creates a transaction record — and with the consumer's consent, that data can power everything from personal finance tools to lending decisions to fraud detection.
This guide covers what transaction data you can access through open banking, how to work with it, and the most common product patterns built on top of it.
What Transaction Data Includes
When a consumer consents to sharing their transaction data, you typically receive:
- Transaction amount — the value of each transaction, positive for credits and negative for debits.
- Transaction date and time — when the transaction was posted to the account. Some APIs also provide the actual transaction date (when the purchase was made) versus the settlement date.
- Description / reference — the raw merchant or payer description as recorded by the bank. This is often messy (e.g., "SQ *COFFEE SHOP MELB AU") and typically needs enrichment.
- Transaction type — categories like direct debit, card purchase, transfer, BPAY, ATM withdrawal, interest payment, fee, etc.
- Status — whether the transaction is pending or posted.
- Balance after transaction — the running account balance after each transaction.
- Merchant details — where available, structured merchant information including name, category code (MCC), and location.
The data typically covers up to 2 years of history (the Australian Government has announced a reduction from 7 years to 2 years as part of CDR reforms), though the available history window varies by market and provider.
Raw Data vs Enriched Data
Raw transaction data from banks is functional but often hard to work with directly. The merchant description field is particularly problematic — it's a free-text string that varies between banks, payment networks, and merchants.
For example, a single coffee shop might appear as:
SQ *COFFEE SHOP MELBOURNE AUCOFFEE SHOP PTY LTDSQUARE COFFEE SHOP
Transaction enrichment solves this by processing raw descriptions into structured, consistent data:
| Raw Field | Enriched Output |
|---|---|
| Description | Clean merchant name ("Coffee Shop") |
| — | Merchant category ("Cafes & Coffee Shops") |
| — | Merchant logo URL |
| — | Merchant location (suburb, state) |
| Transaction type | Spending category ("Food & Drink") |
| — | Recurring payment flag |
| — | Subscription detection |
Enrichment is what makes transaction data usable for consumer-facing products. Without it, showing users a list of raw bank descriptions is confusing and unusable.
Common Use Cases for Transaction Data
Personal Finance Management (PFM)
The classic use case: aggregate a consumer's transactions across multiple bank accounts and credit cards, categorise spending, track budgets, and show trends over time. Transaction enrichment is essential here — users expect to see "Netflix" and "Woolworths", not raw payment references.
Income and Expense Verification for Lending
Lenders use transaction data to verify income (salary deposits, business revenue) and assess expenses (recurring obligations, discretionary spending). This replaces manual payslip collection and provides a more complete, harder-to-falsify picture of an applicant's financial position. Key patterns include:
- Identifying regular salary or wage deposits
- Calculating average monthly income over 3–12 months
- Detecting recurring obligations (rent, loan repayments, subscriptions)
- Flagging risk indicators (gambling transactions, frequent overdrafts, payday lending)
Affordability Assessment
Beyond income verification, transaction data enables detailed affordability modelling. By analysing spending patterns, categorising expenses as essential vs discretionary, and identifying committed expenditure, lenders can make more accurate lending decisions with lower default rates.
Accounting and Bookkeeping Automation
For small businesses, pulling transaction data directly from bank accounts into accounting software eliminates manual data entry. Enriched transaction data with merchant names and categories maps directly to chart-of-accounts categories, automating reconciliation.
Subscription Management
Detect recurring payments in transaction history to help consumers identify and manage their subscriptions. This requires pattern recognition across transaction dates and amounts — enriched data makes this significantly easier by normalising merchant names.
Fraud and Risk Detection
Transaction patterns reveal risk signals. Unusual spending patterns, transactions in unexpected locations, or sudden changes in financial behaviour can indicate fraud or financial distress. For platforms that manage funds or extend credit, transaction monitoring is a risk management tool.
Working with Transaction Data: Technical Patterns
Fetching Transactions
Open banking APIs typically provide transaction endpoints that support:
- Date range filtering — fetch transactions between specific dates
- Pagination — large transaction sets are returned in pages
- Account filtering — fetch transactions for a specific account
A typical integration fetches an initial batch of historical transactions (e.g., 90 days) at consent time, then periodically fetches new transactions to keep your local copy current.
Handling Data Quality
Transaction data from banks isn't always clean. Watch out for:
- Duplicate transactions — pending transactions that later appear as posted. Deduplicate based on transaction ID where available, or use amount + date + description matching.
- Delayed transactions — some transactions take days to settle. Build your logic around the posted date, not just the transaction date.
- Missing fields — not all fields are populated for all transactions. Handle nulls gracefully.
- Description variations — the same merchant can appear differently across banks and card networks. This is why enrichment matters.
Storage and Retention
Transaction data is sensitive personal information. Consider:
- Encryption at rest and in transit
- Access controls and audit logging
- Retention policies aligned with your consent terms and regulatory requirements
- Data deletion when consent is revoked
In CDR-regulated markets like Australia, data retention is capped at two years, and you must delete data when the consumer revokes consent or the consent period expires.
Choosing an API Provider
When evaluating open banking API providers for transaction data access, consider:
Bank coverage. How many banks does the provider connect to? In Australia and New Zealand, coverage across the major banks and key mid-tier banks is essential. Internationally, coverage requirements vary by market.
Data quality and enrichment. Does the provider offer enriched transaction data, or only raw bank data? Building your own enrichment pipeline is possible but requires significant investment in merchant databases and categorisation models.
Latency and reliability. How quickly does the API return transaction data? What's the uptime? For real-time use cases like balance checks before payment, latency matters.
Regulatory compliance. Does the provider handle the regulatory requirements (CDR accreditation in Australia, API certification in NZ, etc.) or do you need to manage this yourself?
Consent management. Does the provider handle consent collection, management, and revocation, or do you need to build this?
Fiskil provides open banking APIs with access to transaction data, enrichment, and account information across Australia and New Zealand. Explore our Banking API.
