UK digital banking integration API
An engineering-first read of the same UK open banking flow: what your team builds against the digital banking API, what it does not, and which parts stay stable once the integration ships, leaving room for product innovation.
Technology supplier
viaBanking builds open banking software, licensed partners handle payment services
One contract to code
One digital banking API across UK providers and receiving accounts
Confirmed on the account
Credit matched to your reference, read-only
No licence claimed
viaBanking holds no AIS or PIS licence for financial services
Six pieces you get
The product-first read of the same UK build is on banking API UK for product teams.
API and data model
One request object, one status model and one identifier scheme covering every licensed UK open banking provider and every receiving account you connect. Your financial systems learn a single API and data shape and keep it as the estate grows.
Provider connections
We maintain the connections to licensed providers of open banking services to UK banks, including changes those providers make to their own APIs. Upkeep of bank APIs never lands in your codebase or your digital banking roadmap.
C2B account connectivity
We set up read-only API connectivity to your C2B account at the UK EMI or bank, plus the matching logic that ties an incoming credit back to your original payment reference and your financial data.
Callback infrastructure
Signed webhooks with retries, stable identifiers and repeat-safe delivery. Your side implements one handler rather than maintaining separate integrations for open banking service provider events and for credits arriving on your UK C2B account.
Dashboard and log access
Engineering, operations and financial services teams share one searchable record of API requests, provider responses and confirmations, which removes the internal payment viewer a fintech team would otherwise build during the project.
Sandbox and test data
A sandbox reproduces the production status model, including declines, timeouts and the authorised-without-credit case, so your test suite covers the financial states that matter before any real UK open banking traffic arrives.
Five stages
The account read side sits with bank account API in Europe.
- 01
Create the request
Your service posts amount, currency, reference and the customer's bank identifier to one open banking API endpoint. The response carries our transaction identifier and the authorisation link, and nothing provider specific reaches your financial data model.
- 02
Hand off for authorisation
The customer authorises at their own UK bank. SCA and the user's payment consent are handled by that bank, so your integration stores no bank credentials and implements no authentication of its own.
- 03
Receive the intermediate status
Our API callback reports that the open banking service provider saw an authorisation at the customer's bank. Your handler records it against the transaction and takes no irreversible action, because nothing has been credited yet.
- 04
Credit matching on the account
We read the C2B account through the bank API and match the credit to your reference. No work is required from your systems during this step, which is why fintech teams most often forget to model it.
- 05
Consume the final status
A second callback carries the confirmed result. Your handler moves the order forward, writes the identifiers into your ledger and financial systems and closes the record. Everything past this point is ordinary logic in your own banking service.
Who does what
| Participant | Function in the integration |
|---|---|
| Merchant or fintech | Builds the request call to the open banking API and the callback handler, and owns the financial and business rules applied to each status. |
| Licensed payment initiation service provider | Holds the licence for payment initiation services, connects to UK banks through their APIs and performs the initiation your request asks for. |
| 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. |
| EMI or bank holding the C2B account | A banking or e-money institution that holds the account receiving customer money and provides the bank API service we read to confirm credit. |
| viaBanking | Supplies the open banking API, routing, status normalisation, credit matching and callbacks as a software service, with no funds involved. |
Four backlog items handled for you
Provider specific adapters
Each open banking service provider has its own APIs, fields, error vocabulary and event order. Absorbing that difference in the routing layer means your fintech team writes one adapter instead of one per partner, and your systems stay simple.
Reconciliation you would otherwise own
Matching incoming credits on an account to UK customer payments is a financial data job full of edge cases and ongoing operational cost. It arrives finished, with unmatched items surfaced rather than quietly dropped.
Rework when partners change
Coverage moves, providers version their bank APIs and receiving accounts get replaced. Those changes land in configuration on our side, so a partner change does not reopen a completed project.
Duplicate work per market
Once the UK open banking integration exists, a further market becomes provider configuration rather than a second build. The same endpoints, statuses and handlers carry across without editing, which frees the roadmap for innovation.
- Bank APIsone build per bank or provider
- Data formatsdifferent for every API
- Status vocabularymapped by your team
- Change upkeeplands in your backlog
- Account credit confirmationa separate project
- Bank APIsbehind one integration
- Data formatsone data model
- Status vocabularynormalised for you
- Change upkeepabsorbed in configuration
- Account credit confirmationbuilt in, read-only
Digital banking teams at UK fintech and financial services firms usually start with direct bank APIs and meet the same wall: every new API adds data mapping, monitoring and support. Integrating one open banking API moves that work out of your systems, so innovation in your own financial product is not queued behind bank integration upkeep.
Six mechanics to plan for
| Area | What to plan for |
|---|---|
| Idempotency | Requests and callbacks across all APIs carry stable identifiers. A retried delivery must be safe to process twice, so key your handler on ours. |
| Status persistence | Store both events separately. Collapsing authorisation and confirmed credit into one field is the shortcut UK fintech teams regret later. |
| Timeout policy | You define how long an authorised payment stays open before review. Our open banking API service reports the state; the rule is yours. |
| Error vocabulary | Declines, bank timeouts and authorised-without-credit are separate codes. Mapping them onto one failure state loses the information support and financial teams need. |
| Reference design | Your reference is what credit matching works from. Make it unique per attempt and carry it into your ledger and financial data. |
| Environments | Sandbox and production share the API contract and differ in credentials. Promotion is therefore a credential change and not a code change. |
Four project shapes
Provider multiplexing detail is on open banking API providers UK.
Fintech adding a bank rail
A UK fintech product already live on other payment services adds an open banking transfer option behind its existing checkout abstraction, reusing current order states and adding confirmation as the gate before release.
Replacing a direct provider link
UK fintech teams tied to one open banking service provider and the single account it supports move that coupling to provider APIs into configuration, keeping live traffic on the current provider while the new routing is tested.
Platform serving merchants
A fintech platform integrates the open banking API once and offers bank payment services to its own merchants, with each merchant's provider and receiving account named in configuration rather than in code.
Systems with an existing ledger
Financial services systems that already reconcile against bank statements take the confirmation event as their entry point, which reduces the work to mapping identifiers and status transitions.
Three prerequisites
- 01
Contract with viaBanking
Your agreement with us covers the software service: API keys, routing configuration, environments, dashboard users and support. We take no part in the payment itself and never hold customer money or any financial balance.
- 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 and API credentials
A C2B account at a UK EMI or bank, with read-only API credentials issued to us. Onboarding with the EMI, a regulated banking or financial institution, is always direct between you and that institution.
Straight answers for engineers
What does a digital banking integration API UK project include on your side?
The open banking API, routing to licensed providers' APIs, credit matching against your C2B account, callbacks, dashboard, logs and a sandbox. On your side, in your own systems, it is one request call to the API, one webhook handler and the business rules you apply to each status.
Does UK bank coverage come from you?
No. Coverage belongs to the licensed open banking service provider accessed through viaBanking and it varies between providers. Running more than one provider behind the same integration is a configuration matter for us, not a second build for your fintech team.
Which institution carries the regulatory responsibility?
The licensed provider of payment initiation services for the initiation, the customer's bank for executing the transfer, and the EMI or bank for holding your C2B account. viaBanking supplies a software service and holds no AIS or PIS licence for financial services.
What part of the build proves a payment arrived?
Credit matching. We read your C2B account over read-only bank API connectivity and match an incoming credit to your reference. Authorisation at a customer's bank is reported earlier and proves only that the payer approved the transfer.
What usually takes the most effort?
Arranging provider access through viaBanking and obtaining C2B account credentials directly from your banking institution. On the engineering side, the status rules and the handling of authorised payments without credit take more thought than the API calls do.
Who should staff this project?
A fintech backend team with one engineer on payments and APIs, a product owner who can decide the status rules, and finance involved early on reference design and financial data reconciliation. No specialist open banking experience is required before the project starts.
How does one open banking API help digital banking innovation in the UK?
It takes bank APIs off your roadmap. Your fintech or financial services team integrates one open banking API, and new UK banks, providers and markets arrive as configuration. Innovation then goes into your own banking service rather than into keeping data adapters alive for each bank's APIs.
Which financial data does the integration API return?
Payment status, amount, currency, your reference, provider references and the credit seen on your C2B account. It does not return balances, statements or other account data from the payer's bank; those are account information services delivered by licensed AIS providers.
Can a UK fintech reuse the same API for open banking services in Europe?
Yes. The same open banking API, financial data model and webhooks carry across markets. Adding a European market means naming a licensed provider and a C2B account in configuration, not building another integration against new bank APIs.
How do open banking APIs differ from screen scraping?
Open banking APIs are the regulated bank interfaces licensed providers use, with the customer authenticating at their own bank. Screen scraping asked customers for their banking credentials. viaBanking works only with licensed providers of open banking services on open banking APIs, never with scraped credentials.
Send us your payment states
Send your current payment states, the provider available through viaBanking and the EMI holding your C2B account. We will return an open banking integration outline: API endpoints to call, callbacks to handle and the decisions your team has to make.
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: