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 standardised 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, but balance access is capped at four unattended checks a day and scoped to consumer payment accounts. 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

Your bank supports open banking. So does every other bank in Europe. PSD2 made sure of that, which is exactly why the answer tells you nothing.

Try this instead. Ask whether you can pull an intraday balance at 3pm without logging into a portal. Ask whether you can push next month’s payroll as one ISO 20022 file. Ask whether you can see where a payment actually is, spin up a virtual IBAN, or reach the accounts your group holds at three other banks. None of that is PSD2. All of it is premium, and it is where banks stop looking alike.

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 standardised 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

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, prior-day data, 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.

The treasury premium map

Group	API	What it does for treasury
Cash visibility	Real-time balances	Intraday, on-demand balances instead of yesterday’s statement
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

Cash visibility

The core, and the first thing most teams automate.

Real-time balances give you an intraday position instead of a prior-day statement, so you can manage liquidity through the day.
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.

How we classify these

A quick word on where the lines are, because it is the part I get asked about most. Three rules decide what makes the list.

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.

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.

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

One nuance is worth spelling out, since it is the most common objection. Several of these look like things PSD2 already covers, but the difference is the treasury-grade version.

Take real-time balances. PSD2 does let a third party read your balance, but capped at four unattended checks a day and scoped to consumer payment accounts. That is fine for a budgeting app. It is useless for intraday liquidity, where you want a live position on demand, or pushed to you, across corporate accounts, as often as you like. The premium API removes the cap and the consumer scope. Same idea for payments: PSD2 gives you a single consented payment, the premium layer gives you batch ISO 20022 files for payroll. The baseline touches the capability. The premium version makes it usable for treasury.

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. Its treasury premium APIs tell you whether it can actually run your cash.

That gap is why I built the index this way. Every bank shows which of these premium APIs it exposes, alongside its API standard and a 1 to 5 maturity rating. You can filter for the capabilities you need: real-time balances, bulk payments, virtual accounts, whatever your operation runs on. Then you see at a glance which banks have built for treasury, before you commit to one.

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