Bankumsätze per API abrufen: PSD2, FinTS oder EBICS?

Wer Zahlungseingänge automatisch mit offenen Rechnungen abgleichen möchte, benötigt zunächst Zugriff auf die Kontoumsätze. Was im Onlinebanking selbstverständlich aussieht, ist in einer eigenen Anwendung allerdings nicht ganz so trivial.

In Deutschland gibt es dafür mehrere Wege. Relevant sind vor allem PSD2 beziehungsweise Open Banking, FinTS und EBICS. Welche Schnittstelle sinnvoll ist, hängt stark vom Anwendungsfall ab.

Für einen Prototypen mit einem eigenen Konto gelten andere Anforderungen als für eine produktive Anbindung eines Firmenkontos. Noch einmal anders sieht es aus, wenn Kunden einer Software ihre eigenen Bankkonten verbinden sollen.

Wie die fachliche Zuordnung von Zahlungseingängen zu Rechnungen aussehen kann, wird im Beitrag Zahlungseingänge automatisch offenen Rechnungen zuordnen beschrieben.

Welche Daten werden für den Rechnungsabgleich benötigt?

Für einen automatischen Zahlungsabgleich werden zunächst keine besonders exotischen Bankdaten benötigt. Ein typischer Zahlungseingang könnte intern beispielsweise so aussehen:

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

Interessant sind insbesondere:

Buchungsdatum
Betrag
Währung
Name des Auftraggebers
IBAN des Auftraggebers, sofern verfügbar
Verwendungszweck
Referenzen der Zahlung
eine eindeutige ID der Banktransaktion

Aus diesen Informationen kann eine Anwendung anschließend versuchen, einen passenden offenen Posten zu finden.

Die eigentliche Matching Logik sollte dabei nicht davon abhängen, über welche Bankschnittstelle die Daten geliefert wurden. Ob eine Transaktion ursprünglich aus einer CSV Datei, über FinTS, über PSD2 oder aus einer EBICS Datei gekommen ist, sollte für die spätere Verarbeitung keine Rolle spielen.

CSV
FinTS
PSD2
EBICS
  |
  v
Bank Adapter
  |
  v
Normalisierte Transaktion
  |
  v
Matching Engine
  |
  v
Offene Rechnung

Damit lässt sich die Bankanbindung später austauschen, ohne die eigentliche Logik des Rechnungsabgleichs neu entwickeln zu müssen.

Möglichkeit 1: PSD2 und Open Banking

PSD2 bildet in Europa den rechtlichen Rahmen dafür, dass regulierte Drittanbieter auf Zahlungskonten zugreifen können. In der Praxis begegnet man dabei häufig dem Begriff Open Banking oder XS2A.

Vereinfacht sieht der Zugriff so aus:

Eigene Anwendung
      |
      v
Open Banking Schnittstelle
      |
      v
Bank
      |
      v
Konten und Transaktionen

Auf den ersten Blick klingt das nach einer gewöhnlichen REST API. In der Praxis gehören aber Zustimmung des Kontoinhabers, Authentifizierung und bankabhängige Abläufe dazu.

PSD2 ist keine einfache API mit dauerhaftem API Key

Bei vielen Web APIs hinterlegt eine Anwendung einmal Zugangsdaten und ruft anschließend dauerhaft Daten ab. Beim Zugriff auf Bankkonten ist das bewusst anders.

Der Kontoinhaber muss den Zugriff autorisieren. Je nach Verfahren und Bank sind dabei Schritte zur starken Kundenauthentifizierung erforderlich. Für eine Anwendung, die Konten vieler Nutzer anbinden soll, entsteht dadurch deutlich mehr Integrationsaufwand als bei einer klassischen Unternehmens API.

Deshalb werden häufig spezialisierte Open Banking Anbieter eingesetzt. Sie bündeln unterschiedliche Banken hinter einer einheitlicheren Schnittstelle.

Eigene Anwendung
      |
      v
Open Banking Anbieter
      |
      + Bank A
      + Bank B
      + Bank C

Für ein SaaS Produkt kann dieser Ansatz besonders interessant sein, weil nicht jede einzelne Bank separat integriert werden muss.

Wenn eine Anwendung Kontoinformationen fremder Nutzer verarbeitet, sollte neben der technischen Umsetzung auch die regulatorische Einordnung geprüft werden. Für einen internen Prototypen mit dem eigenen Konto ist die Ausgangslage eine andere als für einen Dienst, der Bankkonten von Kunden verbindet.

Wann ist PSD2 sinnvoll?

PSD2 beziehungsweise Open Banking ist vor allem interessant, wenn Nutzer einer Anwendung ihre eigenen Bankkonten verbinden sollen.

Finanz Apps
Buchhaltungssoftware
Liquiditätsplanung
Multibanking Anwendungen
SaaS Lösungen mit vielen unterschiedlichen Kundenkonten

Für ein einzelnes eigenes Firmenkonto gibt es dagegen häufig einen anderen etablierten Weg.

Möglichkeit 2: FinTS

FinTS steht für Financial Transaction Services und ist der Nachfolger von HBCI. Das Verfahren wird in Deutschland seit vielen Jahren von Banking Software genutzt, um mit Kreditinstituten zu kommunizieren.

Je nach Bank und unterstütztem Geschäftsvorfall lassen sich darüber unter anderem Kontoinformationen abrufen.

FinTS ist deshalb für Entwickler interessant, die zunächst mit einem eigenen deutschen Bankkonto experimentieren möchten.

Privatkonto
    |
    v
FinTS
    |
    v
Eigene Anwendung
    |
    v
Transaktionen

FinTS sollte allerdings nicht mit einer modernen REST API verwechselt werden. Das Protokoll bringt eine eigene Dialoglogik, Bankparameter und Sicherheitsverfahren mit.

Für FinTS Softwareprodukte gibt es außerdem Anforderungen an die Produktregistrierung. Wer FinTS nicht nur zum Experimentieren, sondern als Bestandteil eines eigenen Produkts einsetzen möchte, sollte diese frühzeitig prüfen.

In vielen Programmiersprachen existieren bereits Bibliotheken, die Teile des Protokolls abstrahieren. Für einen Prototypen ist das in der Regel sinnvoller, als FinTS selbst vollständig zu implementieren.

Wann ist FinTS sinnvoll?

FinTS kann interessant sein, wenn eine Anwendung auf deutsche Bankkonten zugreifen soll und der Banking Zugriff selbst kontrolliert werden soll.

Für einen Prototypen mit einem eigenen Konto kann es ebenfalls eine praktische Option sein. Ob daraus später die richtige Architektur für eine produktive Anwendung wird, sollte getrennt entschieden werden.

Möglichkeit 3: EBICS

EBICS steht für Electronic Banking Internet Communication Standard. Während PSD2 stark mit dem Zugriff durch Drittanbieter verbunden ist und FinTS aus dem klassischen Onlinebanking Umfeld stammt, ist EBICS vor allem im Firmenkundengeschäft relevant.

Unternehmen nutzen EBICS für den automatisierten Datenaustausch zwischen eigenen Systemen und Banken.

ERP oder eigene Anwendung
          |
          v
        EBICS
          |
          v
         Bank

Der große Vorteil liegt im automatisierten Austausch. EBICS passt deshalb gut zu Anwendungen in Buchhaltung, Treasury oder Zahlungsverkehr.

Kontoauszüge über camt.053

EBICS beschreibt den Kommunikationsweg mit der Bank. Die eigentlichen Kontoinformationen werden in entsprechenden Datenformaten übertragen.

Für elektronische Kontoinformationen spielen heute insbesondere die ISO 20022 Formate der camt Familie eine Rolle. Für gebuchte Kontoumsätze ist camt.053 besonders relevant. camt.052 wird für untertägige Kontoinformationen verwendet.

Bank
 |
 v
EBICS
 |
 v
camt.053
 |
 v
XML Parser
 |
 v
Transaktionen
 |
 v
Rechnungsabgleich

Eine camt Datei enthält nicht nur Beträge und Buchungsdaten. Je nach Zahlung und Bank können auch Namen, Kontoinformationen, Referenzen und Verwendungszwecke enthalten sein.

Diese Informationen werden aus dem XML Format extrahiert und anschließend in das interne Transaktionsmodell der Anwendung übertragen.

Ist EBICS eine REST API?

Nein.

Wer aus der klassischen Webentwicklung kommt, erwartet häufig einen Ablauf wie:

GET /transactions

und als Antwort ein JSON Dokument.

EBICS funktioniert anders. Das Protokoll besitzt eigene Abläufe für Authentifizierung, Schlüssel und den Austausch von Daten mit dem Kreditinstitut.

Deshalb ist die Integration zunächst aufwendiger als die Verwendung einer gewöhnlichen REST API. Technisch lässt sich dieser Teil aber sauber kapseln.

Eigene Anwendung
      |
      v
EBICS Adapter
      |
      v
EBICS Kommunikation
      |
      v
Bank

Die restliche Anwendung arbeitet dann weiterhin nur mit einem einfachen internen Datenmodell.

Wann ist EBICS sinnvoll?

EBICS ist besonders interessant, wenn eigene Firmenkonten dauerhaft in automatisierte Unternehmensprozesse eingebunden werden sollen.

automatischer Abruf von Kontoauszügen
Zahlungsverkehr aus ERP Systemen
Treasury Systeme
Debitorenbuchhaltung
automatischer Rechnungsabgleich
Anbindung mehrerer Firmenkonten

Für ein privates Testkonto ist EBICS dagegen normalerweise nicht der erste Weg.

PSD2, FinTS und EBICS im Vergleich

Anwendungsfall	Typischer Ansatz
Erster Prototyp ohne echte Bankintegration	CSV oder exportierter Kontoauszug
Prototyp mit eigenem Privatkonto	FinTS oder Open Banking
Eigenes Firmenkonto	EBICS prüfen
Mehrere eigene Firmenkonten	EBICS
Kunden sollen ihre Konten verbinden	PSD2 beziehungsweise Open Banking Anbieter
Buchhaltungsintegration im Unternehmen	häufig EBICS

Auch technisch unterscheiden sich die Ansätze deutlich.

Eigenschaft	PSD2 / Open Banking	FinTS	EBICS
Typisches Umfeld	Drittanbieter und Finanz Apps	Onlinebanking und Banking Software	Firmenkundengeschäft
Privatkonten	gut geeignet	häufig geeignet	normalerweise nicht relevant
Firmenkonten	möglich	möglich	sehr relevant
Viele fremde Konten	gut geeignet	eher aufwendig	nicht der typische Anwendungsfall
Automatisierte Unternehmensprozesse	möglich	möglich	sehr gut geeignet
Integration	API orientiert	eigenes Protokoll	eigenes Protokoll und Dateiformate

Die Tabelle ist bewusst vereinfacht. Welche Funktionen tatsächlich verfügbar sind, hängt bei allen Varianten auch von der jeweiligen Bank und dem konkreten Zugang ab.

Wie würde ich einen Prototypen aufbauen?

Für einen ersten Prototypen eines automatischen Rechnungsabgleichs würde ich die Bankintegration nicht an den Anfang stellen.

Die interessante Frage lautet zunächst: Kann die Anwendung Banktransaktionen zuverlässig mit offenen Rechnungen abgleichen?

Dafür reicht am Anfang ein exportierter Kontoauszug.

CSV Datei
   |
   v
Importer
   |
   v
Transaktionen
   |
   v
Matching Engine
   |
   v
Offene Rechnungen

Der Importer überführt die Daten in ein neutrales Format. Auf diesem Datenmodell kann anschließend die eigentliche Matching Logik entwickelt werden.

Erst wenn diese funktioniert, wird der CSV Import durch eine echte Bankanbindung ersetzt.

FinTS
PSD2
EBICS
  |
  v
Bank Adapter
  |
  v
Transaktionen
  |
  v
Matching Engine

Dieser Aufbau trennt zwei unterschiedliche Probleme voneinander.

Das erste Problem ist der Zugriff auf die Bankdaten.

Das zweite Problem ist die intelligente Zuordnung dieser Bankdaten zu offenen Rechnungen.

Beide Aufgaben können dadurch unabhängig entwickelt und getestet werden.

Und wie wird aus einer Banktransaktion die richtige Rechnung?

Sobald die Transaktionen vorliegen, beginnt der eigentlich interessante Teil.

Eine Zahlung über 539 Euro könnte beispielsweise den Verwendungszweck RG 4402 enthalten. Im ERP existiert gleichzeitig eine offene Rechnung über 555,67 Euro mit drei Prozent Skonto. Der Auftraggeber heißt auf dem Kontoauszug Mueller Textilien GmbH, während der Kunde im ERP als Müller Textil gespeichert ist.

Ein einfacher Vergleich des Betrags reicht hier nicht aus.

Eine Matching Engine kann deshalb mehrere Informationen gleichzeitig berücksichtigen:

Rechnungsnummer
Zahlungsbetrag
mögliche Skontoabzüge
IBAN
Name des Zahlungspflichtigen
Buchungsdatum
offene Rechnungen des betreffenden Kunden

Aus diesen Signalen lässt sich anschließend bewerten, wie wahrscheinlich eine bestimmte Zuordnung ist.

Wie eine solche Matching Logik technisch aufgebaut werden kann, zeigt der Beitrag Rechnungs Matching programmieren: Bankumsätze automatisch offenen Posten zuordnen.

Fazit

Wer Zahlungseingänge automatisiert verarbeiten möchte, braucht zunächst einen zuverlässigen Weg vom Bankkonto in die eigene Anwendung.

Dafür gibt es nicht die eine richtige Banking API.

PSD2 und Open Banking sind besonders interessant, wenn Nutzer ihre eigenen Konten mit einer Anwendung verbinden sollen. FinTS kann für deutsche Konten und eigene Integrationen relevant sein. EBICS ist dagegen vor allem für automatisierte Prozesse mit Firmenkonten interessant.

Für einen Prototypen muss die Bankintegration trotzdem nicht der erste Schritt sein. Oft ist es sinnvoller, zunächst einige reale oder anonymisierte Kontoumsätze zu importieren und daraus ein einheitliches Datenmodell zu erstellen. Sobald der Rechnungsabgleich darauf zuverlässig funktioniert, kann die Datenquelle durch FinTS, PSD2 oder EBICS ersetzt werden.

Die Bankschnittstelle liefert die Daten. Die eigentliche Automatisierung entsteht erst bei der Frage, was anschließend mit diesen Daten passiert.

Wenn Sie Bankumsätze automatisiert in eigene Anwendungen oder Finanzprozesse integrieren möchten und noch nicht wissen, ob PSD2, FinTS oder EBICS zu Ihrer Systemlandschaft passt, ist ein kleiner Prototyp meist der sinnvollste erste Schritt.

In 15 Minuten lässt sich unverbindlich klären, welche Architektur zu Ihren Konten, Daten und Schnittstellen passt. Zum Erstgespräch.

Zusammenarbeit

Individuelle KI- und Automatisierungslösungen, passend zu Prozess, Datenrisiko und Kosten.

Kontakt aufnehmen →

Blog

Neue Artikel per E-Mail. Keine Werbung.