Retrieve bank transactions via API: PSD2, FinTS or EBICS?

If incoming payments are to be matched with open invoices automatically, the application first needs access to bank transactions. What looks simple in online banking is not quite as straightforward when it has to become part of a custom application.

In Germany there are several relevant options. The most important are PSD2 and Open Banking, FinTS and EBICS. The right interface depends heavily on the use case.

A prototype using your own account has different requirements from a production connection to a company account. The architecture changes again if customers of a software product are supposed to connect their own bank accounts.

For the functional workflow behind payment matching, see Incoming payments: match them to open invoices automatically.

Which data is needed for invoice matching?

An automatic payment matching system does not initially need particularly exotic banking data. A transaction could be represented internally like this:

{
  "id": "tx_123",
  "bookingDate": "2026-09-04",
  "amount": 539.00,
  "currency": "EUR",
  "debtorName": "Mueller Textilien GmbH",
  "debtorIban": "DE...",
  "reference": "RG 4402"
}

The most relevant fields are:

• booking date
• amount
• currency
• name of the payer
• payer IBAN, where available
• payment reference
• transaction references
• a unique transaction ID

The matching logic should not care where this data came from. A CSV import, FinTS, PSD2 and EBICS should all be translated into the same internal transaction model.

CSV
FinTS
PSD2
EBICS
  |
  v
Bank adapter
  |
  v
Normalised transaction
  |
  v
Matching engine
  |
  v
Open invoice

This keeps the banking integration separate from the logic that decides which invoice belongs to a payment.

Option 1: PSD2 and Open Banking

PSD2 provides the European framework that allows regulated third parties to access payment accounts. In practice, terms such as Open Banking and XS2A are commonly used around these interfaces.

Custom application
       |
       v
Open Banking interface
       |
       v
Bank
       |
       v
Accounts and transactions

At first this may look like an ordinary REST API. In practice, consent by the account holder, authentication and bank specific flows are part of the process.

PSD2 is not simply a permanent API key

With many web APIs, an application stores credentials once and can then retrieve data indefinitely. Bank account access is deliberately different.

The account holder has to authorise access. Depending on the bank and the flow, strong customer authentication may be involved. For software that connects accounts from many users, this creates more integration work than a typical business API.

This is why specialised Open Banking providers are often used. They combine many banks behind a more uniform API.

Custom application
       |
       v
Open Banking provider
       |
       + Bank A
       + Bank B
       + Bank C

This approach can be particularly useful for SaaS products because the application does not have to integrate every bank separately.

When does PSD2 make sense?

PSD2 and Open Banking are especially relevant when users of an application need to connect their own bank accounts.

• finance applications
• accounting software
• cash flow planning
• multibanking applications
• SaaS products with many customer accounts

Option 2: FinTS

FinTS stands for Financial Transaction Services and is the successor to HBCI. It has been used in German banking software for many years to communicate with banks.

Depending on the bank and the supported transaction type, it can be used to retrieve account information.

Private account
      |
      v
FinTS
      |
      v
Custom application
      |
      v
Transactions

FinTS is not a modern REST API. It uses its own dialogue logic, bank parameters and security procedures.

FinTS software products are also subject to product registration requirements. Anyone planning to use FinTS as part of a real product should review those requirements early.

Libraries exist for several programming languages and can abstract parts of the protocol. For a prototype, this is generally more practical than implementing FinTS from scratch.

When does FinTS make sense?

FinTS can be useful when a custom application needs to access German bank accounts and the banking connection should remain under direct control.

It can also be a practical option for a prototype with your own account. Whether it should become the production architecture is a separate decision.

Option 3: EBICS

EBICS stands for Electronic Banking Internet Communication Standard. While PSD2 is strongly associated with third party account access and FinTS comes from traditional online banking, EBICS is particularly important in corporate banking.

Companies use EBICS for automated data exchange between their own systems and banks.

ERP or custom application
          |
          v
        EBICS
          |
          v
         Bank

This makes EBICS a good fit for accounting, treasury and payment workflows.

Bank statements with camt.053

EBICS describes the communication with the bank. The account information itself is transferred in corresponding data formats.

ISO 20022 camt formats are particularly relevant for electronic account information. camt.053 is commonly used for booked account transactions, while camt.052 is used for intraday account information.

Bank
 |
 v
EBICS
 |
 v
camt.053
 |
 v
XML parser
 |
 v
Transactions
 |
 v
Invoice matching

The camt data can contain amounts, booking dates, names, account information, references and payment descriptions. These fields can then be translated into the application’s internal transaction model.

Is EBICS a REST API?

No.

Developers coming from web applications often expect something like:

GET /transactions

with a JSON response.

EBICS works differently. It has its own processes for authentication, keys and data exchange with the bank.

This makes the initial integration more involved than a conventional REST API, but the complexity can be encapsulated inside a dedicated adapter.

When does EBICS make sense?

EBICS is especially useful when company accounts need to be integrated permanently into automated business processes.

• automatic bank statement retrieval
• payment processing from ERP systems
• treasury systems
• accounts receivable
• automatic invoice matching
• multiple company bank accounts

PSD2, FinTS and EBICS compared

Use case	Typical approach
First prototype without a live bank connection	CSV or exported bank statement
Prototype with your own private account	FinTS or Open Banking
Own company account	Evaluate EBICS
Several own company accounts	EBICS
Customers connect their own accounts	PSD2 or Open Banking provider
Accounting integration inside a company	often EBICS

How I would build a prototype

For a first prototype of automatic invoice matching, I would not start with the bank integration.

The first question is whether the application can match bank transactions to open invoices reliably. An exported bank statement is enough to test that.

CSV file
   |
   v
Importer
   |
   v
Transactions
   |
   v
Matching engine
   |
   v
Open invoices

Once the matching logic works, the CSV import can be replaced by FinTS, PSD2 or EBICS.

This separates two different engineering problems: getting the bank data and deciding what the data belongs to.

How does a bank transaction become the right invoice?

Once the transactions are available, the interesting part starts.

A payment of 539 euros may contain the reference RG 4402. At the same time the ERP contains an open invoice for 555.67 euros with a three percent cash discount. The payer appears as Mueller Textilien GmbH on the bank statement while the customer is stored as Müller Textil in the ERP.

A simple amount comparison is not enough.

A matching engine can therefore combine invoice number, amount, cash discount, IBAN, payer name, booking date and the customer’s open invoices.

For the technical implementation of this logic, see Program invoice matching: automatically match bank transactions to open invoices.

Conclusion

There is no single correct banking API for every use case.

PSD2 and Open Banking are particularly useful when users need to connect their own accounts. FinTS can be relevant for German accounts and custom integrations. EBICS is especially useful for automated corporate banking processes.

For a prototype, the live bank integration does not have to come first. It is often better to import a few real or anonymised transactions, define a clean internal data model and test the matching logic first.

The banking interface provides the data. The automation begins with what the application does with that data.

If you want to integrate bank transactions into custom applications or finance processes and are not yet sure whether PSD2, FinTS or EBICS fits your system landscape, a small prototype is usually the most useful first step.

In 15 minutes we can clarify without obligation which architecture fits your accounts, data and interfaces. Book a first conversation.