Open banking aggregator
Open banking aggregator: connect once
An open banking payment needs two things that rarely come from the same place: a licensed provider that can reach the user's bank, and an account that can receive the money. Most teams connect to each of them separately, per provider and per market. viaBanking is the aggregator in between, so you connect once and use any supported provider with any supported EMI or bank account, on one contract and one data model.
viaBanking is a software layer. It aggregates providers and integrations, not the data in a user's bank account. Regulated payment initiation belongs to licensed providers, and the account belongs to the issuer you use.
Definition
What an open banking aggregator is
The short version. What gets aggregated, what you connect to, and which data actually changes hands.
An open banking aggregator sits between a business and the licensed institutions that make open banking payments work. Instead of a separate integration for any provider, any bank list and any account issuer, a business connects once and the aggregation layer carries the rest. Teams get one contract to use, one data model to read, and one place to connect. What each licensed role is allowed to do is described on the open banking provider page.
- Once
Connect once, not once per provider
Each provider API ships its own endpoints, status names and bank list. An aggregator absorbs those differences, so the service you build uses one contract and one data model instead of learning a dialect for any provider you connect.
- Coverage
Coverage becomes configuration
When a provider adds a bank, the coverage lands on the integration you already use. No new data mapping, no new contract, and no release to get any of it.
- Scope
What actually gets aggregated
Providers, bank connectivity and account issuers. Not user data, and not a user's financial history. That distinction runs through every service here and decides which licence any step needs, so get it right before you connect anything.
The problem
The gap aggregators usually leave
Most aggregation stops one step too early, and the skipped step is the one that costs money. The information you get back is tidy; it is not the information you need.
- 01
The provider returns success
A licensed provider confirms the user authenticated at their bank and the payment was initiated. Real information, and where a lot of integrations stop reporting.
- 02
The money is still in motion
Funds move between the user's bank and your account issuer on bank rails. That timing belongs to the two banks involved, not to the checkout data the user started from.
- 03
Your account is the only proof
Until the credit shows on the account that receives it, a business acts on initiation information. At volume that is where the losses sit, and normalising provider data does not close it.
This is the gap. An aggregator that only normalises provider data hands you a tidier version of the same uncertainty: you still do not get to find out whether the money is on the account. Closing it is why the next two sections exist.
The core
Provider and account, decoupled
In most stacks the provider and the receiving account arrive as a bundle. You use the partner EMI your provider works with, or the account that provider happens to support, and a decision that belongs to your business gets made for you.
viaBanking separates the two. Use any supported open banking provider with any supported EMI or bank account, so a business picks the account that fits its market and its financial profile, then connects a different provider later without reintegrating. What a payment initiation licence covers is set out on the PIS provider page.
- Providers
Any supported provider
Coverage, pricing and risk appetite differ per provider API. Connect one where it is strong, use another elsewhere, and the service code you already use will not notice.
- Accounts
Any supported account
The C2B account that receives funds is yours, opened with a licensed EMI or bank you chose and connected to the service you use. It is not dictated by whichever provider you used first.
- Swap
Change without reintegrating
Adding or replacing a provider is a configuration change on our side. The contract and the data model your service uses do not move, so a commercial decision stays commercial.
The differentiator
Confirmed account credit, read-only
The step that takes aggregation past provider information and onto the account itself. It is the one service most teams assume they get, and do not.
- 01
Initiation runs at the provider
A licensed PIS provider initiates the payment at the user's bank, on that user's instruction. viaBanking routes the request through the provider API you connect to, and never initiates on its own account.
- 02
The bank moves the money
Authentication happens in the user's own banking app, and funds move on bank rails toward the account you use. No banking credential reaches the service you built.
- 03
The platform reads your account
Through a licensed AIS provider in read-only mode, the platform checks your own C2B account for the matching credit data. Read-only, your account, on your consent as the account holder, and used for nothing else.
- 04
Your service acts on the account credit confirmation
The confirmed account credit event is what your service uses to release an order, not the initiation callback from earlier in the flow. Your financial records follow the same event.
Note the direction of that read. The read-only access is to the account your own business owns, to verify money arrived. It is not access to a user account, and it is not an account information service sold to you under another name. No user data is collected, stored or resold anywhere in this flow.
The contract
One API, one data model
Your service calls one API. The platform resolves which provider to use, translates the call, and returns one data shape. Amounts, currencies, status names and error codes are normalised, so the financial reconciliation logic you use gets written once instead of once per provider API.
Every state change arrives as a signed callback carrying the same transaction information: a reference, an amount, status information and the confirmed credit event. That is the data an aggregator should hand over, and every field of it is data about payments your own service started. Finance teams get one financial record per payment.
The endpoint-level walkthrough sits on open banking for developers.
Who uses one
Who uses an open banking aggregator
Four shapes of business that end up using one, usually after pricing the direct route.
-
Early-stage products
A small team that needs bank payments working without a provider integration per market, and without a licence of its own. Sandbox first, so a developer can get moving.
-
Online businesses
Any shop or service taking money from a user's bank instead of a card, where the order gets released against confirmation that the funds landed, not on initiation information.
-
Platforms and financial services businesses
A financial services business with its own permissions still needs to connect across any provider and market. Aggregation is the financial connectivity layer teams use, not the licence.
-
Large organisations
Groups running payments across several markets, where provider choice, account choice and audit data have to survive procurement before anybody can use them.
Before going live
What you need in place
Three pieces, and only the third one is software. The bank connectivity you get behind them is described on open banking for banks.
- 01
A C2B account you own
The account that receives user payments is opened by your business directly with a licensed EMI or bank. It is your account, your balance and your financial agreement with the issuer you use.
- 02
An open banking provider agreement
Payment initiation is a regulated financial service, so it uses a licensed provider's authorisation, contracted directly or arranged through the network you connect to, where that provider is onboarded.
- 03
One integration
Sandbox keys first, production keys once the two agreements above are done. The API surface you use is identical in both, so you get live on a credential change.
Onboarding is three-sided today, and worth being plain about. The account is opened directly with the issuer, which runs its own checks on your business, and the licensed provider runs its own review. Aggregation removes the engineering work that multiplies per provider and per bank; it does not remove those contracts, and anyone offering one onboarding to the entire market is describing a direction of travel. Budget for the issuer review before you set a launch date.
FAQ
The questions that decide it
-
Is viaBanking an AIS or PIS provider?
No. viaBanking is a software company and holds no AIS or PIS licence. Payment initiation is performed by the licensed partner institutions you connect through, and the read-only credit check runs on a licensed AIS provider. We provide software and a data model, not financial services.
-
Do you aggregate account data?
We aggregate providers, bank connectivity and account issuers, not the data in anybody's bank account. The only account the platform reads is your own C2B account, read-only, to confirm a credit arrived. No product here collects, stores or resells user data, and no user data is used for anything beyond that one check.
-
Do you hold funds?
No. Money moves from the user's bank to the C2B account your business holds at a licensed EMI or bank. viaBanking never takes custody and never moves money, so the balance and the financial records around it are only ever yours.
-
Can we keep the provider we already use?
Often yes, where the provider you use is already in the network or can be onboarded. Scoping checks it early, because the pairing between a provider and an account issuer decides how much of the setup you already use carries over.
-
What happens when a provider has an outage?
Traffic can be routed to another licensed provider that reaches the same banks, and your integration does not change. That is the practical argument for keeping the provider you use outside your service code, and for reading one data model rather than several.
One contract, any provider, your account
Tell us which markets you sell into and which institution you would like to use for the account. We map that against live coverage, show which providers connect to it, and open a sandbox so the API integration gets built while the contracts move. Most teams use that review to decide which market goes first.
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 financial services, does not execute bank payments and does not hold or move funds.