The Account and Transaction API is the open banking profile for reading account information with consent: balances, transactions, standing orders, direct debits, parties, statements and products. It is the data source behind income verification and affordability. A customer grants an account-access consent listing exactly which permissions apply, and the provider reads only what is allowed.
The consent resource and permissions
Access starts with an account-access consent. The provider creates a consent resource describing what it wants to read, the customer authorises it at their bank, and from then on reads are limited to those permissions. You request the least you need, both to lift consent rates and to satisfy data protection. An illustrative permissions request looks like this (the exact permission names come from the Standard):
{
"Data": {
"Permissions": [
"ReadAccountsDetail",
"ReadBalances",
"ReadTransactionsCredits",
"ReadTransactionsDebits",
"ReadTransactionsDetail",
"ReadStandingOrdersDetail",
"ReadDirectDebits",
"ReadParty",
"ReadProducts",
"ReadStatementsDetail"
],
"ExpirationDateTime": "2027-01-15T00:00:00+00:00"
},
"Risk": {}
}
For an affordability use case you typically need balances, transactions and the regular-commitment permissions; you would drop what you do not use. See open banking consent.
The endpoints, in plain English
Once consent is in place, the profile exposes a set of resources. In plain terms:
| Resource | What it returns |
|---|---|
| Accounts | The connected accounts and their identifiers. |
| Balances | Current and available balances. |
| Transactions | Dated credits and debits with descriptions and amounts. |
| Standing orders | Scheduled fixed payments the customer has set up. |
| Direct debits | Mandated recurring collections. |
| Parties | The account holder's details. |
| Statements | Statement periods and figures. |
| Products | Account type and terms, including overdraft details. |
Which of these you can call is governed by the permissions in the consent. See what data you can get for how this becomes income and affordability.
Pagination and history limits
Transaction history can be long, so responses are paginated: you receive a page of results plus a link to the next page, and page through until you have the window you need. History depth is set by the bank and commonly reaches up to around 24 months, though it varies and some return less. Your provider handles paging and assembles the full window; what you consume is the complete, ordered history, not the raw pages.
Business accounts
The profile covers business current accounts as well as personal, which matters for SME lending and commercial affordability. Business accounts can add complexity: multiple parties, multi-authorisation for related actions, and richer product data. If you serve SMEs, test behaviour on the specific business banks your customers use rather than assuming parity with personal accounts.
Common gotchas
- Over-requesting permissions. Asking for more than you need lowers consent rates and weakens your data protection position.
- Assuming uniform history. Depth varies by bank; design for the window you can reliably get.
- Raw descriptions. Transaction descriptions are cryptic; the value is in categorisation, not the raw field. See raw vs enriched.
- Reconfirmation. Ongoing access must be reconfirmed, so build for the 90-day cycle rather than assuming indefinite reads.
From the data consumer's side
You will not call these endpoints directly; your provider does and returns the enriched result. The useful takeaways are to request the minimum permissions for your decision, to expect bank-dependent history, and to judge a provider on how cleanly it turns these raw resources into income and affordability. The endpoint list is really a checklist for what your provider should reliably deliver.
How Credit Canary does it
Credit Canary consumes the Account and Transaction profile through a regulated provider, requests scoped permissions, pages through the available history, and returns categorised transactions, detected income and an affordability view, for personal and business accounts, inside your platform.
Common questions
What is the Account and Transaction API?
It is the UK open banking API profile for reading account information with consent: balances, transactions, standing orders, direct debits, parties, statements and products. It is the data source behind income and affordability.
What are permissions in the Account and Transaction API?
Permissions are the specific data types a customer grants in the account-access consent, such as ReadBalances or ReadTransactionsDetail. The provider can only read what the permissions allow, so you request the least you need.
How far back can the Account and Transaction API read?
History depth is set by the bank and commonly reaches up to around 24 months, though it varies. Requests are paginated, and your provider handles paging through longer histories.
Does the Account and Transaction API work for business accounts?
Yes, including business current accounts, though business accounts may add multi-authorisation and party complexity. Confirm coverage and behaviour for the business banks your customers use.
Related pages
Primary sources
- Read/Write API v4.0.1, account access permissions (checked 14 Oct 2026).
- Read/Write API v4.0.1 resources and data models (checked 14 Oct 2026).
Credit Canary provides open banking through fumopay limited, an FCA-authorised account information and payment initiation service provider (FRN 925689), of which Credit Canary is an agent. Underlying bank connectivity is also provided by fumopay limited. This page is an evergreen reference and is reviewed and dated; it is not regulatory, legal or financial advice.