What counts as a premium bank API for treasury?

Anything a bank exposes above the PSD2 baseline that a treasury function would actually integrate. PSD2 opened three regulated services: account information, payment initiation and a funds check. Premium covers the treasury-grade layer on top, such as intraday balances, ISO 20022 bulk payments, virtual accounts, cash pooling, FX execution and payment tracking. It sits outside the regulation, so it is rarely standardized and varies at every bank.

Isn't real-time balance and bulk payment access already part of PSD2?

Partly, but only in a form that does not work for treasury. PSD2 lets a third party read balances and initiate single payments. The catch is that its consent and authentication flows assume one person approving from a phone, not a corporate mandate with several signatories and no human in the loop. Treasury needs a live intraday position on demand, batch ISO 20022 payment files, multi-entity access and payment tracking. Banks expose that treasury-grade layer as premium APIs outside the regulated scope.

Do all banks offer these treasury APIs?

No and that is the whole point. Most banks stop at the PSD2 baseline. Of the banks in our index, fewer than half expose any documented treasury premium API and the ones that do vary widely in how far they go. A long premium list is a strong signal that a bank has built a real corporate platform.

Why are these APIs so different from one bank to the next?

Because they sit outside PSD2, nothing forces a bank to offer them, name them the same way or design them like anyone else. Two banks offering the same service, such as virtual accounts or Confirmation of Payee, will often expose it through completely different APIs.

Premium bank APIs for treasury, explained

PSD2 never handed anyone an API. It told every bank in Europe what it had to open up, then left each of them to go build it: read a balance, move money, check the funds are there before you charge.

That is the floor and it is why every bank can say yes to “do you support open banking”.

The interesting part sits above the floor:

Next month’s payroll pushed as a single ISO 20022 file
Payment tracking
Virtual IBANs
The accounts your group holds at three other banks.
A cash position that keeps up through the day with nobody logging in to fetch it.

Banks build these because they want the corporate business, not because a regulation told them to, so no two build them quite the same way.

That layer is what treasury actually runs on and it is what people mean by premium APIs.

Short version: PSD2 forced banks to open up three regulated services. The APIs treasury runs on sit above that line and they fall into a handful of clusters, from intraday reporting to bulk payments to cash pooling. Premium APIs sit outside the regulation, so they are rarely standardized and vary at every bank. Which ones a bank offers tells you far more about its platform than “supports open banking” ever could.

Here is the map, grouped the way a treasurer thinks about it.

Where “premium” sits

The PSD2 baseline is three regulated services:

AIS for reading balances and transactions
PIS for moving money
CBPII for checking funds are there before charging

PSD2 bank APIs: AIS reads account information, PIS initiates payments, CBPII confirms whether funds are available

Every bank in scope offers those and shared standards mean they look broadly similar. They are also built for the consumer case:

One account
Single payments
Per-payment consent

Treasury needs more than that and the “more” is where banks differ. It is the intraday, multi-account, batch, multi-entity layer that a real cash operation depends on.

That layer is premium.

Premium Banking APIs

The six premium API categories for treasury: cash visibility, payments, liquidity, FX and risk, collections and fraud, and working capital

Group	API	What it does for treasury
Cash visibility	Real-time balances	Intraday value-dated position, pushed as it moves, read unattended
Cash visibility	Statement reporting	Structured statements (ISO 20022 CAMT.052 / .053 / .054)
Cash visibility	Multi-bank aggregation	Pull accounts held at other banks into one view
Payments	Bulk payments	Batch ISO 20022 (pain.001) for payroll and suppliers
Payments	Instant payments	Real-time credit transfers (SCT Inst)
Payments	Cross-border & high-value	International and RTGS payments
Payments	Payment tracking	Status (pain.002) and SWIFT gpi
Liquidity	Cash pooling & sweeping	Physical or notional balance concentration
Liquidity	Virtual accounts	Virtual IBANs for collections, reconciliation, POBO / COBO
FX & risk	FX & hedging	Currency rates, spot / forward execution, hedging
Collections	Direct debits & mandates	SDD collection and mandate management
Collections	Confirmation of payee	Verify a beneficiary before the money moves
Working capital	Trade finance	Guarantees, letters of credit, supply-chain finance
Working capital	Commercial cards	Issue and control commercial or virtual cards

Each API is broken down in the glossary at the end.

How we classify these

These were the three rules I used to determine what makes the list.

1. Premium means above the PSD2 floor. If a capability is part of the regulated baseline, it does not count. That floor is the same at every bank, so it tells you nothing.

2. It has to be a real API a treasury team would use. Not a product, not a portal, not a file feed. If the only way to get it is EBICS or a PDF or a relationship manager, it is not a premium API. That rule is why deposits and eBAM are not on the list. Treasurers use both, but almost no bank exposes them as a developer API today. They are delivered as ISO 20022 files over SWIFT, so they fail the test.

3. Grouped by the job, not the standard. The list follows what a treasurer is trying to do, see cash, move cash, optimize cash, manage risk, collect, fund working capital, rather than which API standard a bank happens to use.

Why the premium layer is so uneven

Because it sits outside PSD2, the premium layer gets none of the regulation’s flattening effect. A few things follow that are worth planning around:

No two look alike. Two banks offering the same service often expose completely different APIs, with different fields, flows and quirks.
Often bespoke. Premium is exactly where banks bolt on their own extensions, so they rarely carry over from one bank to the next.
Uneven by market. The same banking group can offer a premium API in one country and not in another.
Gated access. Some are open to any registered developer, others sit behind a contract or extra onboarding.

So a long premium list is a strong signal. It usually means a bank has built well beyond the regulatory minimum, which is exactly what a treasury team should be looking for.

Why this matters for treasury

If you are choosing which banks to integrate, the premium layer is where the real differences live. The PSD2 baseline tells you a bank is open.

A bank’s premium API offering tells you whether it can actually run your cash.

“Supports open banking” is the floor. The treasury premium layer is where you find out how high the ceiling goes.

Glossary

Cash visibility

The core and the first thing most teams automate.

Real-time balances commit to the intraday value-dated position and push it as it moves, rather than leaving you to poll for whatever figure the bank chose to expose.
Statement reporting delivers the structured statements your TMS and ERP want, usually ISO 20022 CAMT, so reconciliation stops being a manual chore.
Multi-bank aggregation pulls the accounts you hold at other banks into one place. That is the difference between a real cash position and a partial one.

Payments

Bulk payments are the workhorse: batch ISO 20022 pain.001 files for payroll, suppliers and tax runs, not the one-off payment PSD2 gives you.
Instant payments move money in seconds on real-time rails.
Cross-border and high-value covers the international and RTGS flows that sit well outside the domestic baseline.
Payment tracking tells you where a payment actually is, through pain.002 status or SWIFT gpi, so you are not chasing beneficiaries by email.

Liquidity

Cash pooling and sweeping concentrates balances across accounts, physical or notional, so idle cash works harder.
Virtual accounts give you virtual IBANs for collections-on-behalf, automatic reconciliation and payments-on-behalf structures.

These two separate a serious transaction bank from one that just ticked the PSD2 box.

FX & risk

FX and hedging exposes currency rates, spot and forward execution and hedging.

Cross-border money movement lives here. For any multi-currency operation it is essential rather than nice to have.

Collections & fraud

Direct debits and mandates cover SDD collection and the mandate machinery behind it.
Confirmation of Payee checks a beneficiary name against the account before the money moves, cutting misdirected payments and fraud.

Worth noting: in the EU, Confirmation of Payee is crossing from premium into the baseline, since the Instant Payments Regulation now mandates payee verification for euro transfers.

Working capital

Trade finance exposes guarantees, letters of credit and supply-chain finance.
Commercial cards cover issuing and controlling commercial or virtual cards for AP and expense.

Both map onto products banks already sell, so where they exist as APIs they tend to be deep.