Open banking API providers

01 · Concept

What are open banking API providers?

Under PSD2 and equivalent frameworks, open banking is delivered by two roles. On one side, banks (the account servicing payment service providers, or ASPSPs) offer their bank data and their bank payment rails through standard APIs. On the other side, licensed open banking providers act as the AISPs and PISPs that use those bank APIs on behalf of a third party. An AISP is authorised to read bank account data with the account holder's consent; a PISP is authorised to initiate a payment from that bank account.

An open banking API provider therefore sits between a business and each bank, but every provider ships different bank coverage, different SDKs and different bank compatibility. viaBanking is not one of those providers. It is the software and orchestration layer that connects your platform to them, so a finance team can use many open banking API providers through one open banking API. The regulated open banking actions, such as bank account access, payment initiation and strong customer authentication, always remain with the licensed provider and the customer's bank.

03 · How the layer works

How viaBanking connects you to providers

viaBanking sits between your platform and the open banking providers your customers use. Your backend calls one open banking API. viaBanking resolves the target bank, picks an appropriate provider that reaches that bank in that market, translates the request into the provider's own bank API shape, and returns a normalised response in one bank data model. Where a bank is reachable through more than one open banking provider, the routing layer picks the healthiest path and can fail over if a provider degrades.

The orchestration is transparent to your platform. Account data reads use the same accounts contract regardless of which provider fulfils them. Payment initiation uses the same payments contract regardless of which open banking provider initiates the payment at the customer's bank. Webhooks arrive in one signed format across every provider. Errors are mapped to a stable set of codes so your platform writes retry logic once, not per provider.

Critically, we orchestrate providers. We do not replace them, and we are not a provider ourselves. The user's payment consent is granted by the customer to the licensed open banking API provider that will enable the payment initiation. Strong customer authentication happens on the customer's bank domain, using the bank's own login flow. Banking credentials never pass through viaBanking. Funds do not sit on a viaBanking balance because we do not hold or move customer funds; the licensed provider and the customer's bank do.

05 · Coverage & routing

Provider coverage and routing

Coverage across open banking providers is built up market by market. Each market has a list of banks a finance team cares about (the retail banks, the neobanks and the EMIs that hold the customer's bank account) and each of those banks is reached through one or more licensed providers. viaBanking maintains that mapping so your integration does not have to keep track of which provider covers which bank.

When your platform sends a bank request, the routing layer picks the provider that reaches that bank in that market and monitors provider health in real time. If the primary provider degrades, requests can fail over to a secondary provider that also reaches the same bank; if no fallback provider is available, the failure is surfaced with a stable error code so your platform can back off intelligently, retry the payment later or pay through an alternative provider. Adding a new market or a new bank behind an existing provider is a configuration change on our side, not a fresh open banking provider integration on yours. Precise coverage counts per market are shared with workspace users and are kept current inside the dashboard.

For a finance team, this is what one open banking API changes. Instead of asking which bank each provider covers in each market, the finance team asks which banks they need to pay into or pay out from, and viaBanking maps that to the right bank at the right provider. Add a new bank, pay a new supplier bank, use a new market; the finance workflow stays the same, and the underlying bank data lands in one financial format that the finance and product teams can use side by side.

A single financial workflow often touches several banks at once: the customer's home bank, the merchant's bank and any intermediate bank in the finance chain. Using one open banking API means your finance team reads all those banks the same way and pays them the same way. Coverage across banks grows as we onboard new providers or as existing providers expand their bank list; each new bank is a configuration change that shows up next to every other bank in the same list, with the same bank data schema, the same payment lifecycle and the same finance-grade audit trail.

Every supported bank behaves like every other bank in the same bank list. The bank name, the bank ID, the bank data payload for AIS and the bank payment payload for PIS all follow one bank data shape. Financial teams can pay across banks (retail banks, business banks, corporate banks and supported EMIs) without a per-bank branch in the code. Pay a supplier bank, pay a merchant bank, pay a payroll bank, or reconcile across many banks in one financial report; the same open banking API handles every bank the same way.

Each new bank in the bank list is a bank your finance team can pay from day one, using the same bank data feed and the same payment path. Pay in one currency, pay in another, or pay a batch across many banks; the underlying bank data model and the bank payment lifecycle stay identical. For a financial platform, that is the financial upside: financial workflows once fanned out to many banks now land on one bank data feed, one payment feed and one financial reconciliation queue. The underlying banks, the underlying payment rails and the underlying financial contracts stay with the licensed providers; your financial view stays one bank data feed wide.