For fintech · Open banking
One open banking API for a fintech team
Instead of connecting to every bank and every licensed provider across Europe one by one, the fintech team integrates once with the viaBanking orchestration API. Payment initiation runs through a licensed third-party PIS provider. Credit into your C2B account is verified through a licensed third-party AIS provider. Coverage grows by configuration, not by another integration project.
Why build-your-own is expensive
Connecting to a single bank is not the hard part. Connecting to enough banks and enough licensed providers to serve a European fintech market is what compounds the engineering and commercial cost.
-
One integration per bank
Each bank has its own API surface, its own error taxonomy, its own consent screen and its own release cadence. A team that goes bank-by-bank ships one integration project per bank, and then maintains it.
-
Different payment consent flows
Every bank presents strong customer authentication in its own way. A user's payment consent flow that works at one bank breaks assumptions at the next, so QA and support work multiply with every new bank.
-
Integration cost is not fixed
Commercial terms differ per licensed provider: some are volume-tiered, some are free above a turnover threshold, some are per-call. The build-your-own path leaves those trade-offs on the fintech team.
What the fintech gets on one integration
The orchestration API takes on the connectivity work. Regulated open banking actions stay where they legally belong.
-
One open banking API
The fintech team wires a single orchestration API. viaBanking normalises the underlying data into one model, so the product code paths do not fan out per bank.
-
Routing to the right partner
viaBanking routes each call to the appropriate licensed third-party AIS or PIS provider for the target bank. New coverage becomes a configuration change on our side, not a rewrite on yours.
-
Regulated actions stay licensed
Payment initiation is performed by a licensed third-party PIS provider. Strong customer authentication is hosted and verified by the user's account-issuing bank. viaBanking never touches banking credentials or funds.
What the fintech ships on top of it
Three particular outcomes on the same integration. Endpoint-level detail lives on the developers page.
-
A2A payment initiation
The fintech's checkout initiates an account-to-account payment through a licensed third-party PIS provider. The user's payment consent is captured on the user's account-issuing bank; the payment is initiated by the licensed PIS provider on the merchant's behalf.
-
C2B account credit verification
Through a licensed third-party AIS provider, viaBanking checks in read-only mode that the payment has actually been credited to the merchant's C2B account. The merchant reads information about the transaction being credited to the account, not the user's own account statement.
-
New markets by configuration
Expansion into a new European market does not require a new integration project on the fintech's side. When viaBanking onboards a licensed provider for that market, the fintech's existing open banking API surface reaches the new banks.
Protecting the merchant when a user changes their mind
Payment consent is not always final. Whether a user can revoke it depends on the bank's own processes. viaBanking makes the actual outcome visible, so the merchant never delivers a service against a payment that will not settle.
- 01
The user starts the payment
The user picks the bank at checkout. viaBanking routes the request to the licensed third-party PIS provider that reaches that bank in that market.
- 02
Payment consent runs at the bank
The user's payment consent flow is orchestrated by the licensed PIS provider. Strong customer authentication happens on the user's account-issuing bank, using the bank's own login and 2FA. No credentials touch viaBanking or the merchant.
- 03
Revocation is bank-dependent
There are cases where the user can revoke payment consent while the funds have not yet left the bank. Whether revocation is possible in a given moment depends on the bank's own processes; some configurations rule it out entirely.
- 04
The merchant sees the actual result
viaBanking surfaces to the merchant whether the payment has actually been credited to the C2B account. If the consent was revoked before settlement, the merchant knows the money did not arrive and does not hand over the service against a payment that will not settle.
Where the software boundary sits
The single most important line on this page.
- Software
viaBanking is the software layer
The orchestration API is a software contract. viaBanking does not act as an AIS or PIS provider on its own account, and does not hold or move funds.
- Licensed
Regulated calls stay with partners
Payment initiation and account access are performed by licensed third-party AIS and PIS providers. Strong customer authentication is hosted and verified by the user's account-issuing bank.
- You own
You keep your own regulated status
Onboarding, risk and settlement decisions stay with the fintech team, on the fintech's own regulated licence per market.
One integration. Every supported bank.
Talk to sales about a European coverage plan for your fintech product, or head to the developers page for the endpoint-level view. The wider catalogue covers the surrounding services.
viaBanking is a software provider; regulated services are delivered by licensed partner providers.