Open banking works by letting your customer connect their bank directly: they pick their bank, authenticate in the bank's own app or website, and approve exactly what they are sharing. The bank then releases the agreed data, or carries out the payment, to an FCA-regulated provider through a secure API. The provider never sees the login, and nothing happens without the customer's approval.
The consent journey, step by step
From the customer's point of view it is a short, familiar journey. Here is what they actually see: they pick their bank, approve exactly what is shared at the bank, and come back connected. This is the account information (AIS) journey; a payment follows the same shape, with the customer approving an amount and payee instead of a data-sharing request.
We connect you securely to your banking app. No card details, no account numbers.
Credit Canary, through an FCA-authorised provider, needs your permission to access your account information once.
Accessed once, today. We never store your login. Withdraw anytime.
Your bank data is shared securely. Verified income and affordability flow straight into the decision.
What happens behind the scenes
In one paragraph: your provider is registered in the Open Banking Directory, so the bank can confirm it is a genuine, authorised party before trusting it. When the customer approves, the bank issues the provider a short-lived access token scoped to exactly what was agreed, signed and secured under the FAPI 1 Advanced profile used in Standard v4.0.1. The provider then calls the bank's API with that token to read the agreed accounts and transactions, or to submit the payment. The customer's credentials never pass through the provider at any point. For the detail, see the security profile and the Standard explained.
How long it takes
The customer-facing part is quick: choosing a bank, authenticating and approving usually takes under a minute, and most of that is the bank's own login. Data comes back within seconds of approval. A pay by bank payment is typically confirmed in near real time, which is one reason firms use it to collect. The slow part, if any, is never the customer; it is the quality of the data you get back and how well it is categorised, which is a provider question rather than an open banking one.
What the customer sees
- A clear request naming who wants access and why, and exactly what is being shared (which accounts, which data, for how long).
- Their own bank's familiar login or app, where they authenticate as usual.
- A confirmation, and from then on the ability to see and withdraw what they shared, both with the provider and in their banking app.
Because the request is specific and the authentication is the bank's own, the experience reassures customers rather than alarming them, which is why connection rates are high when the request is explained well.
What you receive
For an information request, you get structured data: accounts, balances, dated transactions, standing orders, direct debits and account holder details, depending on what was consented. A provider then enriches this into categories, detected income and an affordability view. For a payment, you get a status you can act on: initiated, accepted, completed or rejected. See what data you can get and open banking payments.
From the data consumer's side
If you are building this into a customer journey, two things matter more than the protocol. First, the ask: a short, specific explanation of why you need the connection lifts completion sharply, because the customer is approving a purpose, not a technology. Second, the fallback: some customers will not connect, so design a manual route rather than blocking them. Everything after approval, the tokens, the Directory check, the API calls, is handled by your provider; your job is the request and what you do with the result. Credit Canary gives you both the hosted connection journey and the decision that comes out of it.
How Credit Canary does it
Credit Canary runs the connection through a regulated provider, hosts the consent journey, and returns a decision rather than raw responses: categorised transactions, detected income, an affordability view and, where you need it, pay by bank collection, inside your platform alongside bureau and identity data. You do not operate tokens, Directory entries or API calls yourself.
Common questions
How long does an open banking connection take?
For the customer, usually under a minute: they choose their bank, authenticate as they normally would, and approve. Data is returned within seconds of approval. A pay by bank payment is typically confirmed in near real time.
Does the customer leave my website to connect their bank?
In the most common model they are redirected to their bank's own app or website to authenticate, then returned to you. A decoupled model lets them approve in their banking app without a redirect. Either way the authentication happens on the bank's side.
What happens if the customer does not finish the journey?
Nothing is shared. No consent means no data and no payment. The customer can abandon at any point before they approve, and can revoke afterwards.
How often does data refresh after the first connection?
For a one-off check, you take a snapshot and the connection ends. For ongoing access the customer consents to a period, and the provider can refresh within it, subject to the reconfirmation rules covered on the consent page.
Related pages
Primary sources
- openbanking.org.uk, What is open banking (checked 14 Oct 2026).
- Read/Write API v4.0.1 security profile (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.