Secure open banking solutions for UK businesses
In this solution, payer credentials stay at the bank, the platform's account link is read-only, and every request, status and check is written down where finance and security can find it later.
Credentials stay at the bank
Authentication runs on the bank's own pages
Read-only account link
Account connectivity that cannot move money
Every step recorded
Every service request, status and check stored with timestamps
No card data involved
Bank transfer payments carry no card details
Six security controls
The read-only shape of the account link behind this secure service is documented on bank account API in Europe.
Scoped API credentials
Merchant keys for the payment service are issued per environment and can be rotated or revoked without a code change. Each key belongs to one merchant account and one registered set of callback endpoints.
Read-only account connectivity
Connectivity to the C2B account at the EMI or bank is read-only and secure by design. The platform establishes whether an incoming transfer credited, and has no route to instruct any payment or move any funds.
Signed callbacks
Status callbacks from the service carry a signature and reach only endpoints the merchant registered beforehand. Retries follow a fixed schedule, and an idempotency key per payment prevents a duplicate record in your financial ledger.
Status and event log
Each request, provider response, credit check and status transition is stored against the payment reference with a timestamp, so support and finance read the same sequence of events.
Role based dashboard access
Dashboard users are created per role: support sees the status of open banking payments, finance sees reconciliation records. Changes to access are recorded against the person who made them.
Separate environments
Sandbox and live use different credentials and different callback endpoints. Test traffic has no route to a live C2B account, and live keys for the service follow the first successful test run, while sandbox stays open for regression tests.
Five stages
The regulated context sits with PSD2 and UK open banking.
- 01
Request signed server side
The payment request is assembled on the merchant's own server and signed with a secret key held there. Sensitive data is not assembled in the payer's browser, and the reconciliation reference is set at this point.
- 02
Handoff to a licensed provider
Routing passes the request to the licensed open banking provider chosen for that bank and market. That provider holds the authorisation for payment initiation services and forwards the instruction to the payer's own bank.
- 03
Authentication on the bank's pages
The payer authenticates with their bank using any method that bank operates, then approves the transfer. Login details and second factor stay between the payer and the bank throughout.
- 04
Read-only credit check
Once the provider returns its status, the service queries read-only API connectivity to the C2B account until the incoming transfer appears against the reference, or until the configured waiting window closes without a credit.
- 05
Final status and stored record
One final status goes to the registered callback endpoint. The stored record holds the request, the provider response, the credit check result and the timings, which is what financial reporting or a later query needs.
Who does what
| Who | What they do |
|---|---|
| The merchant | Keeps its API secret server side, registers callback endpoints, manages dashboard roles and decides what a final status is allowed to release in its financial systems. |
| The licensed open banking provider | Holds the authorisation for payment initiation services, handles the bank interface and returns the authorisation status for each instruction the payer's bank accepts. |
| 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 incoming open banking payments under its own licence, credits the account and issues the read-only API credentials used for checking. |
| viaBanking | Runs the software service layer: signs and routes the request, stores statuses and logs, runs the read-only credit check and delivers one signed final status to the merchant. |
Four things a review can rely on
One audit trail across providers
Connecting a second open banking service provider does not create a second log to reconcile. References, status names and record structure stay identical, so an investigation follows one timeline.
A final status backed by the account
Release decisions rest on evidence from the C2B account rather than on an authorisation message alone, which keeps goods and services from leaving on payments that never landed.
Parties can change independently
Provider choice and account choice stay apart and open to change, so an objection raised against any one institution during review can be resolved without rebuilding the other side of a secure flow.
Review material ready in advance
Flow diagrams, stored field lists and retention detail exist already, so an assessment of the solution is answered from current documentation rather than a fresh discovery call.
Six questions with plain answers
| Question | Answer |
|---|---|
| Payer authentication | The customer's account servicing bank, on its own domain, using its own SCA method. |
| Account check output | Credit status, amount, currency and the matched reference. Balances, statements and transaction history stay out of scope for this solution. |
| Per payment retention | Request payload, provider response, credit check result, status transitions and timestamps, keyed to one reference. |
| Callback trust | Signatures on every payload, delivery only to pre-registered endpoints, retries and idempotency keys against double processing. |
| Merchant secret | Server side at the merchant. The key belongs in no browser, mobile bundle or callback payload. |
| Failure surface | Provider errors and missing credits come back as explicit statuses and codes, not as silence or a timeout, and the payment stays open until a final code arrives. |
Four kinds of buyer
The engineering-side view of the same UK open banking platform is on UK digital banking integration API.
Regulated UK businesses
Financial services firms with a formal vendor assessment process, who need each regulated step attributed to the institution performing it before an open banking solution is approved internally.
High value goods and services
Sellers releasing something costly or hard to recover, where acting on an authorisation message rather than a confirmed credit carries a real loss on bank payments.
Platforms with fraud operations
Teams already running fraud services, rules and manual review, who want one status model and one log to feed those rules from, whatever the payer's bank was.
Finance and audit functions
Departments that must show, months afterwards, what was requested, what the provider said, and what the C2B account actually received through each of its financial services.
Three prerequisites
- 01
Agreement with viaBanking
A service agreement for the software solution, covering API credentials per environment, dashboard users, callback endpoints and support. It includes access to licensed payment initiation 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 and read-only credentials
A C2B account at an EMI or bank, plus read-only API credentials for it. Onboarding for that account does not run through viaBanking; it runs directly with the EMI or bank providing the financial services behind it.
Straight answers for security review
What does the platform hold on our behalf?
Payment requests, provider responses, credit check results, status transitions and timestamps, together with dashboard users and their roles. Bank credentials never reach the platform at any point, and account data beyond the credit of a transfer is not read by the service.
Which banks can a UK payer choose for payments?
The choice comes from the licensed open banking providers connected and the banks each one supports in the UK. Coverage widens by adding a provider of payment initiation services rather than by changing the merchant integration, and each provider maintains its own bank list.
Which party is authorised to initiate the payment?
A licensed provider of payment initiation services, working under its own permission. The receiving C2B account belongs to an EMI or bank licensed for that. viaBanking supplies the software service and holds no AIS or PIS licence.
What makes a payment final in this flow?
Credit on the C2B account, confirmed through read-only API connectivity and matched to the reference. An authorisation returned by the provider describes what the payer approved at the bank, which is an earlier and separate event.
How long does a review plus go live usually take?
Integration work is typically days of engineering once sandbox credentials exist. A financial services security questionnaire is answered in parallel. The longer items are the licensed provider's commercial review and the EMI or bank that will open the C2B account.
Which businesses is this designed for?
UK merchants, platforms and financial services companies taking open banking payments at volume, with a security function that asks where data sits and an operations function that needs confirmed credit before anything of value is handed over.
What makes an open banking solution secure for a UK business?
Three properties: the payer authenticates only at their own bank, the platform's link to your C2B account is read-only, and every open banking service call is signed and logged. Any open banking solution that stores bank credentials or can move funds on its own fails a financial services security review.
Is viaBanking a payment service provider?
No. viaBanking is a software solution and service sitting in front of licensed open banking service providers and the EMI or bank holding your account. Payment initiation services and account information services are delivered by those licensed institutions, not by the platform, which never holds or moves funds.
Send your security questionnaire
Describe the open banking payments flow you intend to run. Our team answers against the design set out above, names which institution performs each regulated step, then we open sandbox credentials so your engineers can test callbacks and the credit check.
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: