For enterprise · Open banking
Open banking for enterprise, on one integration
Large organisations rarely fail at connecting to one bank. They fail at the tenth: a second provider contract, a different data shape, an audit trail across four systems. Teams here use one integration in front of the licensed providers and the account issuers, so the way payments are run stays one contract wide while open banking coverage grows underneath.
viaBanking is the software layer. Open banking payment initiation runs on a licensed PIS provider's authorisation, your account issuer holds the money, and we do not provide account information services of any kind.
The requirement
What enterprise needs beyond a bank API
A bank API answers one question: can this call reach that bank. A large buyer asks four others, and those decide whether the thing survives production.
-
Reliability that survives a bad Tuesday
One bank degrading should be a status on one route, not an incident across the payment estate. Every bank route is monitored on its own, so an operations team sees which bank is failing before customers tell them. That is the way an incident should surface, on one route.
-
Coverage that grows without a project
Every new open banking market opens a new bank list. When a licensed provider adds a bank, it lands on the integration already in production, so a coverage decision is not a release plan plus a new data mapping.
-
Manageability across teams
Payments, finance, risk and engineering all need a view of the same payment. One information model means four teams use one record, with one link between a payment and its credit, instead of arguing about which data export is authoritative.
-
An audit trail somebody can defend
Every state change is timestamped, signed and exportable, and each keeps a link back to the payment data it belongs to. When an auditor asks how a payment reached its final state, the answer is a record written at the time.
The shape
One integration instead of a provider stack
The usual pattern is a stack: one PIS provider for some markets, another for the rest, an account issuer chosen separately, and a reconciliation layer built in-house to make all three agree. Every edge in that diagram is a contract, a data mapping and a rota.
viaBanking decouples those choices. The provider that reaches a bank and the institution holding your money are separate decisions, neither hard-wired into your code. Use one provider in one market and another elsewhere: the payment data your systems read does not change shape either way.
- Providers
Provider choice stays open
Coverage, commercials and risk appetite differ per licensed provider. Keeping that choice outside your codebase means the provider you use can be replaced without a rebuild.
- Issuer
The account issuer is your decision
Your C2B account sits at a licensed EMI or bank you selected and contracted with. Large organisations usually have a firm view on which institution holds the money, and it stays intact.
- Model
One data model over both
Whichever provider routed the payment and whichever account received it, the record your systems read carries the same fields in the same shape, so one data model covers both.
The control
Confirmed credit, not just consent
The single control that matters most once payments run at volume, and the one most payment stacks skip.
- 01
Consent is not arrival
A payer who completes authentication at their bank has agreed to pay, which is not the same as money reaching you. Most integrations report that first event and never link it to what actually arrives.
- 02
The bank moves the money
Funds move on bank rails between the payer's bank and your account issuer. That timing belongs to the rails and the banks on them, never to your checkout, and there is no way to shorten it from an API.
- 03
The platform confirms the funds credited to the account
Through a licensed AIS provider in read-only mode, viaBanking confirms the funds landed on your C2B account. That is a different event from the initiation callback, and the one to use when releasing goods.
- 04
The two events stay linked
Every confirmed account credit keeps a link back to the payment that produced it. Finance reconciles a linked pair instead of matching two separate data feeds by hand.
This is a risk control, not a guarantee. Whether funds arrive, and how quickly, depends on the banks and the rails. What the platform removes is the blind spot between consent and money on the account, where losses concentrate once payments run at scale. The link that matters is the one between those two events. The same control written for an online store sits on the pay-by-bank for eCommerce page.
Operations
Visibility and control
What an operations team can see, and who is allowed to see it. The record itself is one payment, one shape, whichever bank answered.
- Record
One record per payment
Reference, amount, currency, the bank used, the full status history and a link to the confirmed account credit event. That single record is the payment information every team can use.
- Push
Signed callbacks, not polling
State changes arrive as signed webhooks in near real time. Systems that need the information pushed get it pushed; the rest pull the data on demand.
- Roles
Role-based access
Access is scoped per key and per role, so a finance analyst and an engineer each see the information their job needs and nothing beyond it. Nobody has to use a shared login to read a number.
- Export
Exports that survive review
Transaction and status data export in one shape for a date range, a market or a single bank, whichever cut a reviewer wants to use, and every row keeps a link to its payment data, which is the way an internal review usually asks for the information.
Evidence
Compliance evidence, surfaced not managed
A careful distinction, because vendors blur it. viaBanking surfaces information and evidence about your payments. It does not take on your regulatory obligations, and it does not hold the licences that make the regulated steps lawful in the first place.
What the platform surfaces
- A timestamped, signed history of every payment state change.
- The link between an initiated payment and the confirmed credit on your account.
- Which licensed provider routed each payment, and which bank answered.
- Exportable logs, with data retention settings your team can use and configure.
- A stable link from every export row back to the payment data behind it.
What stays with you and the providers
- The AIS and PIS authorisations, held by the licensed partner institutions.
- Your onboarding, KYC of your customers and risk decisions as a business.
- The account relationship and its terms, agreed with your account issuer.
- Your obligations to your own customers, including consumer terms and tax.
In short: use the evidence to answer questions faster, and every answer keeps a link back to the payment data behind it. The answers stay yours, either way. Anyone selling compliance as a platform feature on top of open banking payments is describing something other than a software layer. Where the licensed roles sit is set out on the open banking provider page.
Coverage
Coverage and reliability
The bank list behind open banking payments, and the data model over it, is the part somebody has to maintain forever. On this route that somebody is us.
- 2,500+Banks and EMIs reachable
- 31EU markets covered
- 99.99%Platform uptime target
-
Per-route monitoring
Each bank route carries its own health signal, so teams use one status view and a degraded bank shows up there, not as a rise in failed payments.
-
Bank changes absorbed here
When a bank moves an endpoint or renames a data field, the change is absorbed inside the connectivity layer and the API surface you use stays still.
-
Honest limits
Where no licensed provider covers a market yet, that market is not available on this route, and there is no way software changes that.
Delivery
What an enterprise rollout looks like
The honest version. Some of this runs through us, some of it does not, and the slowest counterparty sets the date.
- 01
Scoping
Markets, bank lists, expected payments volume and which institution should hold the money. Coverage gaps surface here, before anybody writes code.
- 02
Sandbox and integration
Keys in the same week. Engineering builds the payment flow, the callbacks and the reconciliation against the sandbox your teams use, while the contracts move in parallel.
- 03
Account issuer onboarding
Your C2B account is opened directly with the licensed EMI or bank. They run their own checks, on their own timeline, and we cannot shorten it.
- 04
Provider agreements
Payment initiation runs on a licensed provider's authorisation, contracted directly or arranged through our network where that provider is onboarded.
- 05
Go-live and expansion
Production keys against the same API surface you already use, then new open banking markets by configuration rather than by project.
Nobody should promise a single button. Onboarding is three-sided, the account issuer and the licensed provider each run their own review, and procurement usually sets the outer bound. What one integration removes is the engineering work multiplying by the number of banks, whichever way the commercials land, not the contracts. Teams wanting the endpoint view start on the developer page.
FAQ
What procurement asks first
-
Do you provide account information services or hold an AIS licence?
No. viaBanking does not provide account information services and holds no AIS or PIS licence. The read-only confirmation that a credit reached your C2B account runs through a licensed AIS provider, and it covers your account only: a link between your payment and your credit, nothing wider.
-
Do you hold funds at any point?
No. Money moves from the payer's bank to the C2B account your business holds at a licensed EMI or bank, and that is the only way funds travel here. viaBanking never takes custody, never nets and never settles. The account and its balance are yours, under your own agreement with that issuer.
-
How is compliance responsibility split?
The licensed providers hold the authorisations for the regulated steps. Your business keeps its regulatory position, customer terms and tax obligations. viaBanking supplies software and the evidence trail for your open banking payments, which is a supplier relationship, not a transfer of responsibility.
-
Can we keep our existing account issuer?
Usually, where the institution your teams already use can receive open banking payments and expose the confirmation data the platform reads. Scoping checks it first, because the answer shapes the rollout.
-
What happens if a provider relationship ends?
Routing moves to another licensed provider reaching those banks, and there is no way that shows up in your integration. Keeping the provider you use outside your codebase is the main reason a migration works that way: a configuration task rather than a rebuild.
Start with a coverage and control review
Tell us the markets, the bank lists and the volumes, and we map them against live coverage and the institutions that could hold the account, and send back the information a sign-off actually needs. Most teams use that review to decide which markets go first. The wider surface sits on the open banking platform page.
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 provide account information services, does not execute bank payments and does not hold or move funds.