viaBanking

Bank connectivity · Open banking

Open banking for banks: one API to reach every bank

Every bank in Europe exposes its own open banking interface, and no two are alike. viaBanking puts one API in front of all of them. The connection, the normalised data model and the status feed are ours. Payments are initiated by licensed providers on that same open banking API, and the money moves on bank rails, so a new bank on our side never becomes a new integration on yours.

viaBanking holds no banking or PSD2 licence and does not provide banking services. The API layer provides access to banks; every regulated step stays with the banks and the licensed providers.

Background

Open banking and the bank connection

Neutral background on how an open banking connection to a bank works under PSD2, before the integration question. The directive itself is explained on the PSD2 open banking page.

  • The rule

    What PSD2 changed

    PSD2 obliged banks across the EU to provide a dedicated access interface, separate from the online banking screens a customer logs into, so a licensed third party can reach an account on the customer's instruction. That obligation is what makes open banking possible at all, and why open banking payments exist as a category.

  • The channel

    What a bank connection is

    A bank connection under PSD2 is an authenticated API channel into one bank. It carries a consent, a payment instruction and payment status data back out. The bank keeps control of the account and of strong customer authentication.

  • The licence

    Who is allowed to use it

    Only a licensed institution may use that bank channel for regulated payment actions. A software layer can orchestrate the API calls and provide access to them, but the AIS or PIS authorisation belongs to the provider making them.

PSD2 in one line: the bank must provide the access interface, the licensed provider is allowed to use it, and the customer decides with a consent. The roles are set out on the open banking provider page.

The cost

Why per-bank integration does not scale

Reaching one bank is a project. Reaching a market is a programme that never finishes.

  • Every bank API is its own API

    Each bank API ships its own endpoints, its own auth sequence and its own error taxonomy. Code written against one bank API tells you almost nothing about the next bank.

  • Formats drift apart

    Amounts, dates, references and status names come out differently at every bank. A product ends up carrying a payment data mapping file per bank, and every one of them rots quietly.

  • Endpoints move without warning

    Banks version and retire API endpoints on their own calendar. A release nobody planned for can take payments on that route out of service on a Tuesday morning.

  • Support scales with the bank list

    When a payment call fails, somebody has to work out which bank, which endpoint and which provider. That triage grows in a straight line with every bank added.

The contract

One API, one data model

Your systems call one API for every bank and every payment. viaBanking resolves which licensed provider reaches that bank, translates the call into the shape that bank expects, and maps the answer back into a single model. The bank-specific part never enters your codebase.

What comes back is platform data about the payment: a reference, an amount, a currency, a status history and the confirmed credit event. Identical fields whichever bank answered, so reconciliation is written once. It is not a copy of the customer's bank account statement.

The wider platform surface around this contract sits on the open banking platform page.

Coverage

Coverage kept live

Open banking coverage is the part somebody has to maintain forever, bank by bank and account by account. On this route that somebody is us. Teams running this at scale, with procurement and audit attached, should read open banking for enterprise.

  • 2,500+Banks and EMIs reachable for payments
  • 31EU markets covered
  • 1Contract, whatever the bank list does
  1. 01

    A new bank is our work, not yours

    When a licensed provider adds a bank, it appears on the API integration you already shipped. No release, no new mapping, no new contract on your side. Payments through that bank start working on the contract you already signed.

  2. 02

    Bank changes are absorbed here

    When a bank moves an endpoint or renames a data field, the change is worked out inside the connectivity layer. The API surface your code calls does not move.

  3. 03

    Every bank route is watched

    Each bank route is monitored on its own. A degraded bank surfaces as a status on that route instead of a payment quietly dropping out inside your checkout.

The boundary

Where the regulated steps sit

Banks provide the interface and licensed institutions provide the authorisation. The API layer moves instructions and payment data between them, and performs no regulated action. What a payment initiation licence actually covers is set out on the PIS provider page.

  • Licensed PIS

    Initiation

    The payment is initiated by a licensed PIS provider on the customer's instruction. viaBanking routes the request and never initiates payments on its own account.

  • The bank

    Authentication and funds

    Strong customer authentication is hosted and verified by the customer's account-holding bank, and the money moves on bank rails. No banking credential reaches viaBanking.

  • On top

    C2B account credit verification

    Through a licensed AIS provider in read-only mode, the platform confirms the credit landed on your own C2B account. That is the signal your systems act on, one per payment.

Mechanics

Direct bank APIs vs one connectivity API

What changes for your team when payments run through one connectivity API, and what does not.

Dimension Direct bank APIs One connectivity API
Integrations to build One per bank One, for every bank on the list
Payment data model One shape per bank One normalised model
Payment status Per-bank semantics One status feed for every payment
Adding a bank A new project on your side A configuration change on ours
Endpoint changes Your release cycle Absorbed in the connectivity layer
Failure triage Worked out per bank, by your team Per route, surfaced by the platform

This compares mechanics only. The regulated status of each action is identical on both routes: a licensed provider initiates, the customer's bank authenticates and moves the funds. Choosing a connectivity layer changes the engineering, not the licensing.

FAQ

Questions before the build

  • Does viaBanking hold a banking or PSD2 licence?

    No. viaBanking is a software company. The AIS and PIS authorisations belong to the licensed partner institutions the platform routes to, and the accounts belong to banks and EMIs. We do not provide banking or payment services and do not hold client funds.

  • What does the API actually access?

    Payment initiation through a licensed provider, the status of that payment, and read-only confirmation that the credit reached your own C2B account. It is not a feed of the customer's bank statement data, balance data or transaction history.

  • Do we still need our own agreements?

    Yes. The C2B account is opened by your business with a licensed EMI or bank, and payment initiation runs on a provider's authorisation, whether you contract that provider directly or reach it through our network.

  • What happens when a bank is not covered?

    That bank is out of reach on this route. Coverage grows as licensed providers add banks to their lists, and where no provider reaches a given bank, no API layer changes that fact.

  • How is this different from using one bank API directly?

    A single bank API reaches a single bank. This is one contract in front of many, with a normalised data model, a maintained bank list and one status feed across payments, on top of the same licensed providers.

One integration, the whole bank list

Tell us which markets and which banks matter first, and we will map them against live open banking coverage. The build path is described on open banking for developers.

viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold a banking, AIS or PIS licence, does not provide banking services, does not execute bank payments and does not hold or move funds.