Open banking for fintech companies in the UK
Most fintech products meet open banking at the top up: money into a user balance without a card, on one integration whose later flows reuse the same wiring.
Top ups ship first
The open banking flow nearly every fintech product needs
More flows, one build
Later pay in cases reuse the same connectivity
Balance follows confirmed credit
Funds show after the account check passes
Licensed steps named
Initiation and the receiving account sit elsewhere
Six pieces on day one
The general product-team view of the same UK open banking flow is on banking API UK.
One API contract
A single request format covers every connected licensed open banking provider and every bank they support. Adding a second provider later is configuration work, not a second integration to maintain.
Routing per bank
Each request is routed to the licensed open banking provider that reaches the bank the user selected. Where two providers reach the same bank, routing rules decide which one carries that traffic and keep the other route open.
Normalised statuses
Open banking provider status names are mapped into one set of states with one meaning each, so your ledger logic is written once and does not change when the provider mix changes.
Account credit confirmation
Read-only API access to your C2B account at the EMI or bank establishes whether the transfer credited, matched to the reference your app sent with the request.
Callbacks into your ledger
Signed callbacks reach the endpoint you register, carrying the reference, amount, status and timing your ledger needs to post an entry without polling for it.
Sandbox with test cases
Approved, rejected and credited-late outcomes can be produced on demand in sandbox, so app behaviour for each branch is built and reviewed before real money is involved.
Five stages
Recurring open banking collections use the same wiring — see VRP.
- 01
Bank selection in your app
The user enters an amount and picks their bank from the list your app renders. Nothing beyond the amount, the bank identifier and your own reference leaves your backend at this point.
- 02
Request to a licensed provider
The request goes to the licensed open banking provider covering that bank. Regulated payment initiation belongs to that provider, which handles the bank interface and the technical dialogue behind it.
- 03
Approval at the user's bank
The payer is authenticated by their own bank and approves the transfer there, using that bank's app or web pages. Credentials pass between the user and their bank only.
- 04
Credit check on the C2B account
After the provider reports acceptance, read-only access to the C2B account is queried until the transfer appears against the reference, or until the open waiting window closes without any credit.
- 05
Ledger entry on final status
One final status arrives at your callback endpoint. Your service posts the balance entry from that status, so a user balance rises only after money has landed on the C2B account.
Who does what
| Who | What they do |
|---|---|
| The fintech | Renders the bank list in its open banking checkout, sets the reference, holds the C2B account contract and decides what a final status releases inside its own product. |
| The licensed open banking provider | Holds the payment initiation authorisation, forwards the instruction to the payer's bank and returns the status that bank gives it. |
| End user’s account issuing bank | Captures the end user’s payment consent, performs strong customer authentication and sends the authorised payment from the end user’s account. |
| The EMI or bank holding the C2B account | Receives the incoming transfer under its own licence, credits the account and gives read-only API access to that record. |
| viaBanking | Routes each request, normalises statuses, runs the read-only credit check against the C2B account and delivers one final status to your service. |
Four reasons
Launch without a permanent choice
The first open banking flow goes live with one licensed provider, and a second is added when volume or coverage calls for it. Neither move touches your product code, so provider choice stays open.
Your EMI stays your decision
Providers often steer merchants towards the one account they support. Pairing any connected provider with any connected C2B account keeps that negotiation in your hands.
No balance on an unarrived transfer
Approval at a bank and money on the account are separate events. Posting a balance entry on the second one removes the case where a user spends against a transfer that never arrived.
One reconciliation model as you grow
New flows and new banks land in the same data model and the same reference scheme, so finance keeps one process while the product surface widens.
Six mechanics
| Detail | How it works |
|---|---|
| Status set | Intermediate statuses report what the bank accepted. One final status per payment reports credited or not credited on the C2B account. |
| Idempotency | Your reference is the key. Repeated requests and repeated callbacks resolve to one payment record and one ledger entry. |
| Callback delivery | Signed payloads go to the endpoint registered for that environment, with scheduled retries until your service acknowledges receipt. |
| Reference matching | The reference set at request time is the field matched at the account, so reconciliation needs no fuzzy amount and date guessing. |
| Waiting windows | Each flow has a configurable window. While it is open the payment stays pending; when it closes with no credit, an explicit not credited status is sent instead of nothing. |
| Sandbox parity | Sandbox uses the same request format, statuses and callback structure as live, on separate credentials and separate endpoints. |
Four product shapes
Security review notes for the same flow live on secure open banking UK.
Wallet and balance apps
Products where a user funds a balance by open banking before spending it, and where the gap between an approved transfer and a credited one turns into support tickets.
Investment and savings products
Services funding a user position or pot by open banking transfer, where posting only against confirmed credit keeps the balance in step with money that actually landed.
Bill and repayment collection
Financial apps collecting a scheduled amount from a user's bank, where a transfer that fails needs to be visible in the same status feed as one that worked.
In-app checkout
Fintech products offering an open banking payment next to cards in their own app, wanting one status flow and one place to see what completed.
Three prerequisites
- 01
Agreement with viaBanking
A contract for the software layer, covering API credentials, sandbox and live environments, callback endpoints, dashboard users and support. Payment initiation is accessed through this agreement and performed by licensed providers; viaBanking does not execute payments or hold funds.
- 02
Provider access through viaBanking
Your agreement with viaBanking gives access to integrated licensed open banking providers without separate merchant contracts with them. We handle any required provider onboarding for your business; the providers retain responsibility for regulated payment initiation.
- 03
C2B account with API access
A C2B account at an EMI or bank, with read-only API credentials for it. Onboarding to open that account is always direct between your company and the institution.
Straight answers for fintech teams
What does a fintech team get on day one?
One API contract, routing across connected licensed open banking providers, a normalised status model, signed callbacks, read-only account credit confirmation on the C2B account, plus a dashboard with logs. Regulated initiation stays with the licensed provider throughout.
How many banks will our users see in the list?
The list reflects the banks supported by the licensed providers you connect, in the UK and in any other market you sell into. Coverage grows by adding a provider, with no change to your app.
Who is licensed for initiating the transfer?
A licensed payment initiation provider performs initiation under its own permission, and the receiving account belongs to an EMI or bank under theirs. viaBanking is software and holds no AIS or PIS licence.
What tells us a top up actually arrived?
The credit check against your C2B account, run through read-only API connectivity and matched on your reference. An open banking provider status only reports what the payer approved at the bank, which happens earlier and separately.
How quickly can top ups go live?
Engineering against sandbox is commonly a few days for a first flow. Live timing follows the open banking provider's review and the EMI or bank opening your C2B account, with viaBanking handling required provider onboarding and you arranging the C2B account directly with its institution.
Which fintech products fit this best?
UK financial products taking consumer money in through open banking at volume: wallets, funded accounts, collection flows and in-app checkout. Products whose economics depend on knowing money landed benefit most from the final status.
Do we need our own open banking licence?
Not for payment initiation through a licensed open banking provider, because the permission for that step sits with the provider. Read-only access to your own C2B account is granted by the EMI or bank holding it. Whether other parts of your product need a licence is a question for your own advisers.
Why do UK fintechs move top ups from cards to open banking?
Open banking moves money bank to bank, so a top up carries no card scheme fees, no chargeback window and no card expiry. Pricing for access to the open banking provider is covered by your agreement with viaBanking, and the confirmed credit on your C2B account gives finance a cleaner record than a card settlement file.
Describe your first flow
Describe the first flow you want live and which bank your C2B account sits with. Our team confirms the routing, maps our statuses onto your ledger states and issues sandbox credentials, so your engineers can build the top up path against real request and callback formats.
viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold an AIS or PIS licence, does not execute bank payments and does not move funds.
Updated: