14.8. Banking Protocols

This page collects information we have about banking protocols available around the world.

14.8.1. Open Financial Exchange (OFX) Direct Connect

OFX is widely used in the US. It defines a completely custom protocol (based on HTTP) and data formats (not based on ISO20022) for banking.

14.8.2. Electronic Banking Internet Communication Standard (EBICS)

EBICS is used primarily in Germany, France and Switzerland. Some banks (such as BNPParibas with their Global Ebics) also allow EBICS access to accounts in other countries.

EBICS is just a transfer layer for communicating with banks. Banks define what messages they support. In practice, EBICS is very often used to transfer ISO20022 messages.

German banks that are part of the German Banking Industry Committee all must offer EBICS access. Thus this protocol is a good choice for the German market.

14.8.3. FinTS / HBCI

German home-banking standard. FinTS is the successor of the Home Banking Computer Interface (HBCI), but older versions of FinTS are often still called HBCI.

The current version, FinTS 4.0, is not widely supported by banks yet. Starting with FinTS, XML is used as a data format. Previous versions used a custom text/binary format.

Only some banks allow authentication based on key pairs. Due to different interpretation of PSD2, other banks now only allow authentication methods that require interaction from the customer (SCA / Strong Customer Authentication).

Payloads these days can be ISO20022 messages.

Examples:

14.8.4. PSD2

PSD2 is not a technical standard, but high-level legal requirements on (amongst other things) APIs that banks have to offer.

There are many implementations of PSD2 APIs. The Berlin Group provides a framework that somewhat standardizes technical details, but the use of this standard is by no means necessary.

Unfortunately, it focuses on other parties accessing your bank account. It does not give customers access to their own bank account. Customers can manage third party access they give to their bank account in their online banking system. That mechanism is conceptually similar to OAuth2. In fact, some implementations of PSD2 even use OAuth2 directly.

PSD2 APIs usually use JSON as a data format. Often the schema and terminology is “inspired” by ISO20022 messages, but no actual ISO20022 XML message formats are used.

PSD2 requires two main services to be available via an API:

  • AIS (Account Information Service).
  • PIS (Payment Initiation Service).

Together, they’re often called XS2A (“access to account”).

An entity that wants to use AIS has to be registered with the financial oversight authority in its country (BAFIN in Germany). PIS has even stronger legal prerequisites.

On a technical level, using PSD2 APIs usually requires having an EIDAS certificate.

Examples (bank offerings):
Examples (standards):

14.8.5. Bank-Proprietary APIs

Some banks offer completely custom APIs to access services of the bank. These often include services not available via more standardized APIs, such as account creation.

Often banks frame PSD2 as just another API available in their portfolio of API offerings.

Examples:

14.8.6. Open Bank Project

The Open Bank Project provides a free software implementation of banking middleware that supports various APIs, including PSD2-compatible APIs (based on Berlin Group).

API Docs: https://github.com/OpenBankProject/OBP-API/wiki/Open-Bank-Project-Architecture

14.8.7. UK Open Banking

Open Banking is the (quite confusing!) name of a UK-based open banking initiative.

What’s nice about Open Banking is that their APIs are really close to ISO 20022, unlike many similar HTTP+JSON APIs.

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16385802/Specifications