Ask three vendors what "open banking" means and you will get four answers. Some will show you an API gateway. Some will show you a licensed platform. Very few will explain the difference - which is unfortunate, because the difference is exactly what regulators grade you on. The short version: an open banking API is a door. An open banking platform is the building with the guards, the cameras and the books. Regulators do not inspect doors.

What PSD2 actually requires

PSD2 - the second Payment Services Directive - obliges account-serving institutions to let licensed third parties access customer accounts with the customer's consent. Two flows carry the weight: AIS (account information services), where an aggregator reads balances and transactions, and PIS (payment initiation services), where a third party triggers a payment directly from the account. Both must run through interfaces that support strong customer authentication, and access must not depend on a commercial agreement between the parties.

Notice what the directive does not say. It does not say "expose an endpoint and you are done". Compliance is judged on whether the third party can actually deliver its service - reliably, with the right authentication and the right data.

The API alone: why it breaks

We have been asked to bolt an open banking API onto systems where the core could not back it up, and we decline those projects now. Not out of purity - out of arithmetic. The failure modes are known:

• Fresh balances. AIS is useless if the balance the API returns is an overnight batch figure. Third parties build products on your data; stale data breaks them, and the API layer cannot invent freshness.
• Consent enforcement. A consent given for one account scope must be enforceable where the data actually lives. A gateway checking permissions in front of a core that does not understand consent is theater.
• Payment finality. A PIS initiation that ends in "submitted, check tomorrow" is not payment initiation. Execution happens in the core, and the core must confirm in seconds.
• Dedicated interface. Regulators expect a dedicated API for licensed third parties, not a reskinned version of your web channel.

Each of these is a core banking function wearing an API costume. The gateway passes the request through; only the core can honor it.

Platform: where the obligations land

An open banking platform, in the sense we use the term, is the core plus the API layer plus the compliance machinery: consent records, SCA flows, access logs, reporting. The API is the contract surface; the platform makes the contract true. When an institution runs its open banking obligations on a proper platform - core, API, consent management as one system - the audit conversation changes shape. You show the regulator where consent is stored and how it is enforced at the ledger level, not a diagram of a gateway.

That is our position, stated plainly: an open banking API without a core behind it is a liability, not a product. It creates the appearance of compliance while moving the actual work - balance freshness, consent enforcement, payment execution - onto infrastructure that cannot do it. If a vendor sells you the door without the building, ask them who answers the regulator's questions.

How that looks in practice, module by module, is on our open banking API page. The core that stands behind it is described on the ABS Core page, and if you are weighing vendors, our running comparison table puts the criteria side by side.

The regulatory direction of travel

PSD2 set the floor; later instruments keep raising it. The instant payments regulation in the EU adds verification-of-payee obligations and removes the option of charging more for instant transfers. Open banking frameworks beyond Europe - Brazil's Open Finance, UK open banking standards - push the same logic further: standardized APIs, explicit consent lifecycles, and liability rules when data is wrong. The common thread is accountability. Each new requirement lands on whoever holds the customer data, not on whoever operates the gateway.

The direction is easy to read: interfaces will keep being standardized, and the institutions that already treat consent and data access as core functions will absorb each new rule as configuration. Institutions that treat them as a middleware project will keep rebuilding.

The compliance cost of the wrong choice

The practical consequence of an API-only setup shows up in incidents. Third-party developers file support tickets about data that was correct yesterday. Consent revocations take effect late because the core does not enforce them at the data layer. Incident reports describe the gateway as healthy while the underlying ledger was out of date for hours. Each of these is survivable on its own; together they form exactly the pattern that turns into a regulator's follow-up question.

There is also a slower cost. Institutions that start with an API skin eventually rebuild the same functions at the core level - consent storage, fresh balance access, payment status APIs - and pay for the gateway twice. We have watched this replay enough times that it is now our first question in any open banking conversation: what does the API sit on?

What to check before you sign

One question cuts through most vendor conversations: "Show me a PIS payment, end to end, from consent to ledger posting, with timestamps." Vendors with a real platform produce it in a demo. Vendors with a gateway in front of a batch core start talking about roadmaps. The distinction is not marketing. It is where your next audit will end up.