Open banking · Integration
Open banking API integration
Integrate once with our software layer and reach open banking providers and C2B bank accounts across Europe. Ship payment initiation and information about the transaction being credited to the account on one open banking API, one data model and one contract, instead of building a new bank integration for every open banking provider, every account and every market.
viaBanking is a software provider; regulated open banking services are delivered by licensed partner institutions.
- One open banking API
- Pre-integrated providers
- AIS and PIS via providers
- Sandbox and live keys
- REST + JSON API
- Developer-ready
01 · Concept
What is open banking API integration?
Open banking is the practice of securely sharing financial data and enabling payment initiation through standardized APIs, with the explicit consent of the account holder. Open banking API integration is how a product team plugs into that ecosystem: instead of talking to each bank directly, a platform connects through licensed open banking providers that already speak PSD2 and equivalent frameworks. The result is a single technical surface that a developer can use to read financial data or initiate a payment, regardless of which bank the customer holds their account with.
viaBanking is that integration layer. Our platform gives you one open banking API, one data model and one set of developer tools that fan out to the open banking providers and issuers of C2B bank accounts we already connect to. You focus on your product; we normalise the differences between banks, providers and markets so your integration stays stable as coverage grows.
viaBanking simplifies the integration. While regulated open banking services, specifically AIS and PIS, are performed by licensed third-party providers, strong customer authentication is ultimately hosted and verified by the customer's account-servicing bank. That boundary is deliberate: we are a software and orchestration platform for open banking, not a bank, not a payment processor, and not a licensed AIS or PIS provider on our own account.
- Software layer One API over many providers
- Regulated calls stay licensed AIS and PIS run through partners
- SCA at the bank Credentials never touch viaBanking
- Coverage as config New bank or market, same contract
02 · Problem
The integration problem
Building open banking integrations bank by bank is expensive. Each bank provides a slightly different open API, with its own consent screen, error codes, throttling policy and change log. Each open banking provider layers its own SDK on top, with its own data model for accounts, transactions and payment status. A single European launch quickly turns into a dozen parallel integration projects, each with its own developer effort, its own QA matrix and its own on-call burden.
The cost is not only the first integration. Bank APIs change: endpoints move, fields are renamed, sandbox behaviour drifts from production, and PSD2 consent windows are extended or shortened by regulators. Every bank change becomes a ticket for your developer team. Every new market means a new bank list, a new provider contract and a new set of edge cases in your payment flow.
The pain scales with your product surface. A finance platform that supports account data on day one usually adds payment initiation next, then reconciliation, then payouts. Each new capability multiplies against the number of banks and open banking providers, and the possible integration costs add up as each new provider comes with its own commercial terms. Meanwhile, your customers do not care whether the underlying bank changed its consent screen; they care that the account data loads and the payment goes through. An open banking integration layer exists to absorb that complexity so your developer team can ship the actual product, not maintain a wall of bank connectors.
03 · How the layer works
How viaBanking's integration layer works
viaBanking sits between your platform and the open banking providers your customers rely on. Your backend calls one open banking API. viaBanking resolves the target bank, picks the appropriate provider connection, transfers the request into the provider's own API shape, and returns a normalised response in a single data model. Where a bank is reachable through more than one open banking provider, our routing layer chooses the healthiest path and can fail over if a provider degrades.
The orchestration is transparent to your developer workflow. Account data reads go through a common accounts contract regardless of which bank is behind the connection. Payment initiation requests use one payments contract regardless of which provider ends up initiating 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 retry logic is written once, not per open banking provider.
Critically, we orchestrate the connection. We do not replace your provider or your bank relationships. Consent is granted by the customer to the licensed provider that will access the account. Strong customer authentication happens on the customer's bank domain, using the bank's own login flow. The payment itself moves through the licensed payment initiation provider and the customer's bank; funds never sit on a viaBanking balance because we do not hold or move customer funds. viaBanking is the software and integration layer that stitches the API calls together and keeps the developer experience consistent across the whole open banking network.
Because the layer is API-first, coverage growth is a configuration change on our side, not a rebuild on yours. New open banking providers, new banks and new markets appear behind the same API contract your platform already integrated against.
Because the integration surface is a set of open banking APIs, adding new payments services or new account services to your platform later is a change of scope, not a new project. A financial service team can layer domestic payments, cross-border payments and account information services on top of the same open banking API integration. Each service keeps its own product logic; the underlying open banking APIs and the payment services they call remain the same. That is what an integration layer is for: keeping the developer team focused on the financial service on top, while the open banking APIs beneath keep every payment and every account request flowing.
04 · Scope
What you can integrate
The following open banking capabilities are available through the same API contract, the same authentication and the same data model. Each is delivered through a licensed open banking provider; viaBanking is the integration layer that normalises the developer experience across every bank and every market.
- AIS
Account data
Read account details, balances and transaction history from the customer's bank account with their explicit consent. The account data is delivered by the licensed AIS provider that holds the consent; viaBanking normalises the response into one data model so a developer treats every bank the same way. Use the same integration to power onboarding, reconciliation or account overview features inside your platform, without stitching a separate open API per bank.
- PIS
Payment initiation
Account-to-account payments initiation from the customer's bank account is conducted by a licensed payment initiation provider. Your platform issues one API call; viaBanking routes it to the appropriate provider, which coordinates with the customer's bank to authenticate the customer and initiate the payment. Your backend receives the payment status in one shape and one lifecycle, whether the underlying provider or bank uses a different one internally.
- Verification
C2B account credit verification
Verify that the bank account provided by the customer is indeed theirs by matching the account details available under PSD2 with the customer identifiers your platform already holds. This capability is provided through a licensed AIS access service provider and returns only the fields your workflow needs, in line with data-minimisation principles. Exact scope and customer-facing messaging are aligned with legal review at go-live.
- Metadata
Provider and status
Read the current list of pre-integrated banks and open banking providers, together with real-time availability, through a companion API. Your platform can use this to gate features per market, show only reachable banks in the customer UI, or route around a degraded open banking provider before your integration retries the payment or the account data call.
05 · Flow
Integration flow, step by step
A typical open banking API integration with viaBanking has five stages. Each stage is a small piece of developer work with a clear API contract, so your platform team can estimate the integration confidently.
-
Get API access
Reach out through the contact form; we open a workspace and issue sandbox and live API keys. Sandbox is free, does not need production data and behaves like the live open API, so a developer can start the integration the same day.
-
Wire consent and authentication
Your platform calls the consents endpoint with the target bank and the scope the customer agreed to. viaBanking routes the request to the licensed provider, which returns an authentication URL. You redirect the customer to that URL; the customer authenticates directly with their bank using the bank's own strong customer authentication flow. Banking credentials never pass through your platform or through viaBanking.
-
Send the data or payment request
Once the consent is active, your backend calls the accounts endpoint to read account data, or the payments endpoint to initiate a payment. Both use the same authenticated API session, the same data model and the same Bearer-token contract, so the developer experience is identical whether the customer is at a German bank, a Spanish bank or a Baltic EMI.
-
Handle the response and webhooks
For account data, responses come back as a normalised JSON payload. For payment initiation, viaBanking emits signed webhook events for every payment status change: initiated, authorised, settled at the bank, or failed. Your platform verifies the signature, updates the payment record and moves on. Retries respect Retry-After and use idempotency keys so a network hiccup never doubles a payment.
-
Go live and monitor
Swap sandbox keys for live keys, register the production webhook URL, and turn on alerting for consent expiry and payment failure events. From that point, adding a new bank or a new market is a configuration change on your side, not a fresh open banking integration.
06 · API conventions
Integration capabilities and conventions
viaBanking provides a modern REST API for open banking integration. The conventions are boring on purpose: a predictable integration layer is what lets a developer team focus on the digital product on top instead of the plumbing underneath.
- REST over HTTPS with modern transport, Bearer authentication and versioned endpoints.
- JSON request and response bodies with UTF-8 encoding across every open banking capability.
- Sandbox and live environments run separate keys and separate base URLs so the developer experience stays predictable.
- Idempotency keys on all payment writes so a retried API call never creates a duplicate payment.
- Stable error codes and a Retry-After header on rate-limit responses for intelligent back-off.
- Signed webhooks with exponential retry and a definitive API endpoint to re-fetch state.
- Consistent pagination, filtering and cursor conventions across every open API resource.
- Public OpenAPI description for code generation and typed client SDKs for a developer team.
Every open banking capability shares the same data model, so account data from one bank looks the same as account data from another bank in the response schema. Sandbox and live API endpoints behave identically, which keeps the developer feedback loop tight and the go-live risk low.
06a · Financial platform fit
How the open banking APIs land on a financial platform
Open banking APIs meet a financial platform at three points: onboarding, payments and account intelligence. Each is a distinct financial service, but all three share the same open banking API integration on your side, and all three run against the same set of open banking APIs.
At onboarding, the account APIs read the bank account the customer used to sign up. A financial platform confirms the account holder through a licensed provider, then keeps that verified financial data on file for later payment services. The developer wires one API call; the customer sees a familiar bank login; the platform gains a stable bank identity signal for its financial workflow, and the same financial data feeds every downstream service later on.
For payments, the payment APIs initiate A2A payments through a licensed payment initiation provider. Your financial platform sends one payment request through the open banking API and receives payment status through signed webhooks. The same payment services scale to recurring or on-demand payments as the underlying provider APIs allow, and the platform keeps a single source of truth for every payment across every bank, rather than one payment record per bank connector.
For account intelligence, the account APIs deliver balances and transactions on the customer's authorised bank account. A financial services team can build reconciliation, treasury or spend-analytics features on top of that account data, all fed by the same open banking API integration and the same developer contract. Account data, payment data and provider data land in a shared financial data model on your platform.
The developer surface is one open banking API. The financial data model is one. Your platform can add new payment services or new account services later without a second bank integration, without rewriting the existing services against a new bank API and without asking the customer to re-authorise the connection. The financial services team owns the product logic; viaBanking's open banking APIs handle the plumbing to every bank and every open banking provider behind the scenes, so a financial developer team only has to reason about the financial workflow, not the underlying bank differences.
06b · Developer resources
Developer resources for the open banking integration
viaBanking ships a developer console, an OpenAPI specification and reference examples so an integration team can move fast. The console lists the API keys per workspace, the pre-integrated banks per market, the open banking providers behind each bank and the live status of every provider connection. A developer can flip between sandbox and live open API keys without re-reading the integration guide, and every open banking API endpoint is documented next to a runnable example.
The reference examples cover the languages a financial platform typically runs (Node, Python, Go, Java, Ruby) and show a full open banking integration end to end: consent creation, authentication redirect, account data read, payment initiation and webhook verification. Copy-and-paste snippets keep the first developer experience frictionless and shorten the time from API key to first live payment. A financial developer team can therefore run a real open banking flow the same day, using the same open banking APIs the platform will call in production.
The console also provides access to financial telemetry that matters at go-live: API request latency per bank, payment success rate per open banking provider, consent renewal rate per market, and open banking API error rate per endpoint. A financial services team uses that telemetry to decide when to broaden coverage, when to switch the default provider for a bank, and when to raise a customer support ticket instead of a payment retry. Payment services are only as good as the observability behind them, and this surface makes every payment lifecycle event visible to the financial operations team.
Because everything is done through the same open banking APIs, a developer can automate the console with the same credentials the platform uses for production traffic. Continuous integration can gate deploys on live open banking provider health, and a finance team can pull payment-level reports on a schedule; no separate integration for internal tooling. For a financial platform that operates across markets, this developer surface is the difference between a stable roll-out and a firefight: one console, one open banking API, one set of APIs to teach a new developer, and one financial data feed the customer support team can trust when a payment stalls at a specific bank.
07 · Use cases
Use cases for open banking integration
Practical scenarios where the same open banking API integration unlocks new financial functionality inside a digital platform. Each scenario stays within the software-layer frame: viaBanking orchestrates the API calls; licensed providers and the customer's bank deliver the regulated open banking service.
-
A2A payments in checkout
Add account-to-account payments next to your existing payment methods and payment service providers. The customer picks their bank; your platform posts one API call; viaBanking routes it through the open banking APIs to the appropriate open banking provider; the customer confirms on their bank domain. Settlement to your merchant account is handled by the licensed provider or your existing payment service partner. viaBanking is the integration layer, not the payment processor. The same open banking APIs unlock instant A2A payments, batched payments and recurring payments as each provider conducts them, so your platform can extend its payments service without another API integration.
-
Reconciliation and finance operations
Read authorised open banking account data on your operating accounts to reconcile inbound transfers, categorise incoming payments and drive finance workflows. The data model is consistent, so a report written against one bank works for every other bank in the network without a rewrite.
-
Marketplace and platform payouts
Combine PIS payment initiation and AIS-shared account details to send payments to a verified seller or merchant account. The integration stays the same as your platform grows across markets, and adding a new bank list is configuration, not code.
-
Expanding into a new European market
Because coverage grows behind the same open banking API integration, launching a new country is a configuration change: enable the market, list the supported banks in your UI and start accepting open banking payments there. No new SDK, no new provider contract on your side, and no new developer sprint per bank. The same open banking APIs cover cross-border payments where each provider supports them, so a single service on your platform can offer domestic payments and cross-border payments through one payment API integration.
08 · Security & consent
Security, consent and compliance
Open banking is regulated. PSD2 in the European Union, its national transpositions and the emerging PSD3 framework set the rules around account access, payment initiation and strong customer authentication. viaBanking is designed to fit inside that framework rather than replace it, and the open banking integration is built to keep every party in its own regulatory lane.
Consent is always granted by the customer to the licensed open banking provider that will access the account. viaBanking does not receive banking credentials, does not display the bank's authentication screen, and does not hold or move customer funds. Strong customer authentication happens on the customer's own bank, using the bank's login and Two-Factor Authentication (2FA). In some cases the customer can revoke a payment consent as long as the funds have not yet left the bank; once the payment is out, the consent can no longer be revoked. Whether revocation is possible in a given moment depends on the bank's own processes; in practice, payments that route through correspondent accounts leave a window during which revocation is possible, while other bank configurations rule it out entirely. Consent duration itself follows the bank's PSD2 configuration. When a consent is revoked before the funds reach the merchant, viaBanking surfaces to the merchant that the money did not arrive in the C2B account, which protects the merchant from mistakenly delivering a service against a payment that will not settle.
Data minimisation is built into the integration. Your platform requests only the account data scopes the customer authorised, and the licensed provider returns only what that consent allows. Data in transit is encrypted with modern TLS; data at rest is encrypted inside our digital infrastructure in the European Union. Access to production API keys is restricted per workspace, per developer and audited.
viaBanking is a software provider and an integration layer for open banking. Regulated services, such as account information services, payment initiation services and any other licensed activity, are delivered by our licensed partner institutions. Statements about specific licensing or regulatory status are confirmed with legal review before they are surfaced in customer-facing contracts, so the compliance boundary between your platform, viaBanking and the licensed provider is always explicit.
Open banking APIs are one part of a broader digital financial service stack. Your platform likely runs its own core payment service, its own customer service tooling and its own analytics service; the open banking APIs plug in next to them, not on top. Every digital service that consumes account data or triggers a payment does so through the same open banking API, so the payment service, the reconciliation service, the reporting service and the customer-onboarding service all read the same financial data. That keeps a digital financial platform easy to audit: one payments feed, one account feed, one set of open banking APIs across every service.
09 · FAQ
Frequently asked questions about the integration
Short, direct answers about how the open banking API integration works, where the regulatory boundaries sit, and what a developer team can expect during a first integration with viaBanking.
-
How long does a typical open banking API integration take?
Most developer teams reach a working sandbox call the same day and a first end-to-end open banking flow within one to two weeks. Expanding to a new market after the first integration is usually a configuration change, not a rebuild, and coverage growth does not add another set of bank APIs for the developer team to learn.
-
What do I integrate with a single open API?
Both account data and payment initiation. The same open banking API contract, the same authentication and the same data model cover both, so your platform does not integrate twice.
-
Is viaBanking a bank, a gateway or a payment processor?
No. viaBanking is a software and orchestration layer for open banking API integration. We do not hold customer funds, we do not settle payments and we do not run a bank account.
-
Do you hold your own AIS or PIS licence?
No. Regulated open banking actions are performed by licensed third-party AIS and PIS provider partners. Specific regulatory statements are confirmed by legal review before we publish them for a given market.
-
How does consent work, and do you store banking credentials?
Consent is granted by the customer to the licensed provider. Strong customer authentication happens on the customer's own bank domain. viaBanking never sees or stores banking credentials, only the tokens the provider returns.
-
Do you offer a sandbox, and how do I go live?
Yes. Sandbox is free, keyed per workspace and behaves like the live open API. Going live means swapping sandbox keys for live keys, registering production webhook URLs and enabling monitoring; there is no separate open banking integration effort. Because viaBanking combines AIS, PIS and issuers of C2B accounts, this single integration gives you the opportunity to handle the whole process of accepting payments from your customers via open banking technology.
Ship open banking on one API
One integration layer for open banking across Europe.
Plug into pre-integrated open banking providers, ship account data and payments on one open banking API, and grow coverage without growing the developer backlog. Read the docs for the field-level open banking API reference, or schedule a demo to walk your platform team through a live integration.
viaBanking is a software provider; regulated open banking services are delivered by licensed partner institutions.