Open-Banking-API-Integration: PSD2, PSD3 und Kontoaggregation 2026

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Entwickelt OAuth/SCA-Consent-Flows, Aggregator- und Direktbank-Integrationen fuer US- und EU-Fintechs

Kurzfassung — die wichtigsten Fakten auf einen Blick

Open Banking macht ein Bankkonto zu etwas, mit dem sich Ihre Software ueber eine API verbinden kann — mit der Einwilligung des Kunden und ohne jemals dessen Bankpasswort zu beruehren. Der schwierige Teil ist selten der erste API-Aufruf; es sind Consent, Reconciliation und das Konformbleiben, waehrend sich die Regeln verschieben. Das brauchen Fintech-Verantwortliche vorab:

• Zwei Faehigkeiten: AIS (Kontodaten lesen — Salden, Transaktionen) und PIS (eine Zahlung vom Konto ausloesen). Die meisten Produkte starten mit AIS; Zahlungen erhoehen die Compliance-Latte.
• Die Regeln sind in Bewegung. In der EU wurden PSD3 und die PSR im November 2025 politisch beschlossen, die finalen Texte erschienen im April 2026; in den USA ist Section 1033 umstritten, und der Markt stuetzt sich auf den FDX-Standard.
• Aggregator zuerst. Plaid, MX, Finicity, TrueLayer oder Tink decken Tausende Banken ueber eine API ab und gehen in 1–2 Wochen live; direkte Bankanbindungen dauern jeweils 4–8 Wochen.
• Auth ist OAuth + SCA. Weiterleitung zur Bank, Zwei-Faktor-Authentifizierung, ausdrueckliche, begrenzte Einwilligung, dann Access- und Refresh-Tokens. Sie speichern niemals Zugangsdaten.
• Kosten: reine Lese-Aggregation $25k–$60k; Produktion mit Zahlungen und Reconciliation $60k–$150k; eine regulierte Plattform $150k–$400k+.
• US-Zugang wird monetarisiert. 2025 begannen Grossbanken, Aggregatoren fuer den API-Zugriff zu berechnen — planen Sie fuer Kosten pro Aufruf und Anbieter-Fallback.

Was Open Banking tatsaechlich ist

Open Banking ist das regulierte, einwilligungsbasierte Teilen von Bankdaten und die Zahlungsausloesung ueber sichere APIs. Schaelt man den Fachjargon weg, gibt es nur zwei Dinge, die Sie tun koennen, stets mit der ausdruecklichen Erlaubnis des Kunden:

• Account Information Services (AIS) — Daten lesen: Kontodetails, Salden und Transaktionshistorie. Das treibt Personal-Finance-Apps, Kredit- und Leistbarkeits-Scoring, Buchhaltungsautomatisierung und Einkommensverifizierung an.
• Payment Initiation Services (PIS) — eine Zahlung direkt vom Bankkonto des Nutzers ausloesen, an den Kartenschienen vorbei. Das treibt Account-to-Account-Checkout, Rechnungszahlung und Auszahlungen an.

Die Akteure tragen Namen, die man kennen sollte, weil jede API und jeder Vertrag sie verwendet. Der ASPSP (kontofuehrender Zahlungsdienstleister) ist die Bank, die das Konto haelt und die API bereitstellt. Ein AISP ist ein lizenzierter Anbieter von Kontoinformationsdiensten; ein PISP ist ein lizenzierter Anbieter von Zahlungsausloesediensten. Entweder halten Sie eine dieser Lizenzen selbst oder, weitaus haeufiger, Sie integrieren ueber einen Aggregator, der sie fuer Sie haelt. Die Disziplin, dies gut zu tun, ist genau das, worauf unsere Fintech-Softwareentwicklungsdienste ausgerichtet sind, und sie steht neben der Zahlungsarbeit in unserem Leitfaden zur Zahlungsgateway-Integration.

Die regulatorische Landkarte: PSD2, PSD3/PSR, Section 1033, FDX

Open Banking sieht auf beiden Seiten des Atlantiks unterschiedlich aus, und die Geografie richtig zu erfassen ist die erste Scoping-Entscheidung.

Europa: heute PSD2, als Naechstes PSD3/PSR

PSD2 ist die EU-Richtlinie, die seit 2018 in Kraft ist. Sie verpflichtete jede Bank im EWR, sichere APIs bereitzustellen, damit lizenzierte Drittanbieter — mit Einwilligung — Kontodaten lesen und Zahlungen ausloesen koennen, und sie fuehrte die starke Kundenauthentifizierung (SCA) ein. Sie ist der Grund, weshalb die europaeische Open-Banking-Abdeckung breit und standardisiert ist (die Berlin-Group-Spezifikation plus nationale Schemata).

PSD3 und die begleitende Payment Services Regulation (PSR) sind die naechste Generation. Sie wurden im November 2025 politisch beschlossen, die finalen Kompromisstexte erschienen im April 2026; die endgueltige Abstimmung und die Veroeffentlichung im Amtsblatt werden fuer die zweite Jahreshaelfte 2026 erwartet, und die meisten Regeln duerften rund 21 Monate spaeter gelten — etwa 2028. PSD3/PSR behaelt das Modell bei, verschaerft aber API-Qualitaet und -Verfuegbarkeit, staerkt Betrugsschutz und SCA und standardisiert den Zugriff, sodass Drittanbieter zuverlaessigere Verbindungen erhalten. Die praktische Empfehlung fuer eine 2026-Umsetzung: jetzt auf PSD2 umsetzen und Ihre Consent- und API-Schicht so gestalten, dass die strengeren PSD3/PSR-Anforderungen eine Konfigurationsaenderung sind und kein Neubau.

USA: Section 1033 umstritten, FDX in der Praxis

Die USA entwickelten Open Banking marktorientiert zuerst. Aggregatoren — Plaid, MX, Finicity, Akoya, Yodlee — bauten die Konnektivitaet auf, und der FDX-Standard (Financial Data Exchange) fuehrt das Datenformat zusammen. Die CFPB erliess im Oktober 2024 eine Section-1033-Regel zu Rechten an persoenlichen Finanzdaten, doch ihre Umsetzung stiess auf rechtliche und regulatorische Turbulenzen, sodass Sie sie nicht als gesichert ansehen koennen. Zugleich verschiebt sich der kommerzielle Boden: 2025 begannen Grossbanken wie JPMorgan Chase, Aggregatoren dafuer zu berechnen, Verbraucherkontodaten ueber ihre APIs abzurufen. Die realistische US-Aufstellung 2026 ist hybrid — regulierter Zugang im FDX-Stil weitet sich neben kostenpflichtigen Aggregator-Vereinbarungen aus.

Aggregator vs. direkte Bankintegration

Es gibt zwei Wege, Bank-APIs zu erreichen, und die Wahl bestimmt den groessten Teil Ihres Zeitplans und Ihrer Kosten.

Ueber einen Aggregator

Ein Aggregator gibt Ihnen eine einheitliche API, die sich auf Tausende Banken auffaechert, die Eigenheiten je Bank handhabt und meist die AISP/PISP-Lizenzen haelt, sodass Sie es nicht muessen. Eine schreibgeschuetzte Kontodaten-Verbindung kann in etwa ein bis zwei Wochen live sein. Die Unterschiede zwischen den Anbietern sind real:

• Plaid — eine Konnektivitaetsplattform mit der breitesten Consumer-Fintech-Abdeckung und dem reibungslosesten Link-Erlebnis.
• MX — ein Datenunternehmen, stark in Datenbereinigung und Anreicherung sowie in Konnektivitaet.
• Finicity (Mastercard) — Verifizierungsinfrastruktur, die bei Einkommens- und Vermoegensverifizierung in Kredit- und Hypothekenflows glaenzt.
• TrueLayer / Tink (Visa) — starke europaeische PSD2-Abdeckung und Zahlungsausloesung.

Waehlen Sie nach Ihrem dominanten Anwendungsfall: Verbraucheraggregation, Kreditverifizierung oder A2A-Zahlungen. Viele Teams setzen einen Aggregator ein und ergaenzen spaeter einen zweiten fuer Fallback und Abdeckung.

Direkt zur Bank

Eine Direktintegration verbindet sich mit der eigenen API eines einzelnen ASPSP. Jede dauert in der Regel vier bis acht Wochen wegen Zertifizierung und Onboarding, sodass sie sich nur lohnt, wenn Sie eine bestimmte Bank benoetigen, die der Aggregator schlecht abdeckt, geringere Kosten pro Aufruf bei hohem Volumen wollen oder eine Partnerschaft dies rechtfertigt. Das ehrliche Muster ist hybrid: ein Aggregator fuer die Breite, eine Handvoll Direktanbindungen fuer die Banken, die Ihr Volumen tragen. Das ist gewoehnliche — wenn auch anspruchsvolle — individuelle Softwareentwicklung, und in grossem Massstab wird daraus die Art von API-Integration, die echte Verantwortung braucht.

Der Integrations-Flow: OAuth, SCA und Consent

Welchen Weg Sie auch waehlen, der Authentifizierungs- und Consent-Flow hat dieselbe Gestalt, und er ist der Teil, den Teams am haeufigsten unterschaetzen.

1. Initiieren & weiterleiten. Ihre App startet eine Autorisierungsanfrage und leitet den Nutzer zu seiner Bank weiter (oder zur Link-UI des Aggregators, die sie vermittelt).
2. Starke Kundenauthentifizierung. Die Bank authentifiziert den Nutzer mit zwei Faktoren — zum Beispiel ein Passwort plus Biometrie oder ein Einmalcode. Sie sehen diese Zugangsdaten niemals.
3. Ausdrueckliche, begrenzte Einwilligung. Der Nutzer genehmigt genau das, worum Sie gebeten haben: welche Konten, welche Daten, fuer wie lange, oder den konkreten Betrag und Empfaenger einer Zahlung.
4. Token-Austausch. Die Bank gibt einen Authorization-Code zurueck, den Ihr Backend ueber den OAuth-Authorization-Code-Flow gegen Access- und Refresh-Tokens eintauscht.
5. Nutzen & erneuern. Sie rufen die Daten- oder Zahlungsendpunkte mit dem Access-Token auf, erneuern es bei Bedarf und — entscheidend — verfolgen, wann die Einwilligung ablaeuft und erneuert oder erneut authentifiziert werden muss.

Das Detail, an dem naive Umsetzungen scheitern, ist der Consent-Lebenszyklus. Unter PSD2 ist die Einwilligung zum Kontozugriff zeitlich befristet und muss in der Regel periodisch erneuert werden; PSD3/PSR wird Consent-Dashboards und erneute Authentifizierung standardisieren. Sie muessen den Consent-Status speichern, vor Ablauf zur Erneuerung auffordern, Widerruf sauber handhaben und niemals stillschweigend ein vom Nutzer widerrufenes Token weiterverwenden. Machen Sie das falsch, brechen Verbindungen „auf mysterioese Weise“ ab oder, schlimmer, Sie ziehen weiter Daten ohne gueltige Einwilligung.

Architektur und Stack

Es gibt keinen einzelnen „Open-Banking-Stack“, doch produktive Integrationen laufen auf eine erkennbare Gestalt hinaus, aufgebaut um ein sauberes internes Modell, sorgfaeltige Token-Handhabung und strikte Auditierbarkeit.

Ein kanonisches Kontomodell

Normalisieren Sie alles — jeden Aggregator und jede Bank — in ein internes Modell, das Ihrer Anwendung gehoert: Konten, Salden, Transaktionen, Einwilligungen, Zahlungen. Das entkoppelt Sie vom Schema eines einzelnen Anbieters und macht das Hinzufuegen des naechsten Aggregators oder der naechsten Bank zu einer Mapping-Aufgabe statt zu einem Neubau. PostgreSQL ist ein verbreitetes System of Record; rohe Anbieter-Payloads lassen sich als JSONB sauber fuer Replay und Audit speichern, waehrend die kanonischen Entitaeten stark typisiert bleiben. Dieselbe architektonische Disziplin liegt unserer Neobank-Entwicklung und breiteren Fintech-Projekten zugrunde.

Token- und Consent-Service

Behandeln Sie Tokens und Einwilligungen als erstklassiges Subsystem, nicht als Spalte in einer Nutzerzeile. Verschluesseln Sie Tokens im Ruhezustand, begrenzen Sie den Zugriff eng, rotieren Sie Schluessel und betreiben Sie einen Scheduler, der Einwilligungen rechtzeitig erneuert oder ablaufen laesst. Jeder Zugriff sollte einer bestimmten, aktuell gueltigen Einwilligung zuordenbar sein.

Ereignisgesteuerte Ingestion und Reconciliation

Bankdaten treffen in Schueben ein, und Webhooks feuern asynchron, sodass eine ereignisgesteuerte Pipeline — eine Queue oder ein Stream — die Anbieter-Feeds von Ihrer Anwendung entkoppelt und Retries und Replay handhabbar macht. Bei der Zahlungsausloesung ist Reconciliation nicht verhandelbar: Jede ausgeloeste Zahlung muss bis zu einem finalen Status verfolgt und gegen Ihr Ledger abgeglichen werden. Das ist Backend- und Cloud-Arbeit; unser Cloud-&-DevOps-Service deckt ab, wie wir diese Pipelines bauen, und die Identitaetsseite ueberschneidet sich mit unserem Leitfaden zu KYC- und AML-Software.

Was eine Open-Banking-Integration 2026 kostet

Konkretes, mit dem ueblichen Vorbehalt, dass Zahlungsausloesung, die Zahl der direkten Bankanbindungen und die Tiefe der Consent- und Reconciliation-Arbeit die Zahlen erheblich verschieben. Diese Spannen spiegeln integrationsfertige Umsetzungen durch ein erfahrenes Team wider — nicht eine Demo, die ein Testkonto anbindet.

Dies sind gemischte Engagements, die Consent, Reconciliation, Monitoring und QA umfassen — nicht nur den sichtbaren Abruf. Wie die Kosten einer individuellen Umsetzung allgemein funktionieren, zeigt unser Leitfaden zur Fintech-App-Entwicklung, der die Compliance- und Stack-Entscheidungen dazu behandelt.

Wohin das Geld tatsaechlich fliesst

• Consent- & Token-Lebenszyklus (25–35 %): erfassen, erneuern, widerrufen, erneut authentifizieren, verschluesselte Speicherung — der Teil, der Verbindungen am Leben und konform haelt.
• Anbieterintegration (15–25 %): Aggregator-Einrichtung, etwaige direkte Bankanbindungen und die Link-/Consent-UI.
• Reconciliation & Betrieb (20–30 %): Zahlungsstatus-Verfolgung, Ausnahmebehandlung, Alarmierung und das Monitoring, das den Flow vertrauenswuerdig haelt.
• Datenmodell & Integration (20–30 %): das kanonische Konto-/Transaktionsmodell und das Landen der Daten im Rest Ihres Produkts.

Sicherheit, Compliance und Datenqualitaet

Open Banking bewegt einige der sensibelsten Daten ueberhaupt, daher sind Sicherheit und Compliance Grundvoraussetzung, kein Extra.

• Speichern Sie niemals Bankzugangsdaten. Der ganze Sinn sind OAuth-Tokens, keine Passwoerter. Verschluesseln Sie Tokens im Ruhezustand, begrenzen Sie sie eng und rotieren Sie Schluessel.
• SCA und Consent sind Pflicht, keine optionale UX. Starke Kundenauthentifizierung und eine ausdrueckliche, begrenzte, befristete Einwilligung sind erforderlich — bauen Sie Consent-Erfassung, -Erneuerung und -Widerruf von Tag eins an ein.
• PCI DSS und SOC 2, wo Zahlungen im Spiel sind. Zahlungsausloesung und jeder kartennahe Flow ziehen Sie in den PCI-Scope; eine KYC/AML-Schicht ist fuer regulierte Anwendungsfaelle meist erforderlich, und SOC 2 Type II ist Pflicht, um an Banken zu verkaufen.
• Datenqualitaet ist ein Feature. Banktransaktionsdaten sind unsauber — uneinheitliche Haendlernamen, schwebend vs. gebucht, Duplikate. Anreicherung und Deduplizierung machen die Daten erst nutzbar; hier zu wenig zu investieren ist die stille Ursache der meisten Beschwerden, „die Zahlen sehen falsch aus“.
• Auditieren Sie alles. Speichern Sie rohe Payloads und eine vollstaendige Consent- und Zugriffshistorie. Regulierer, Partner und Ihre eigenen Streitfaelle werden sie brauchen.

Nichts davon ist exotisch, doch Consent-Management oder einen Audit-Trail nachtraeglich in eine bereits gestartete Integration einzubauen, ist weit teurer, als von vornherein dafuer zu gestalten.

Wie Sie einen Integrationspartner waehlen

Allgemeine Softwarekompetenz ist notwendig, aber fuer Open Banking nicht ausreichend. Diese Checkliste trennt Partner, die eine produktive, konforme Integration liefern koennen, von jenen, die PSD2 auf Ihr Budget lernen.

1. Echte Open-Banking- und Aggregator-Erfahrung

Fragen Sie gezielt nach den Aggregatoren, die sie integriert haben (Plaid, MX, Finicity, TrueLayer, Tink), ob sie neben dem Datenzugriff auch Zahlungsausloesung ausgeliefert haben und wie sie den Consent-Lebenszyklus handhabten. Ein Team, das Einwilligungen in Produktion erneuert und widerrufen hat, spart Ihnen Monate.

2. Eine kanonische Modell-Denkweise

Misstrauen Sie jedem, der Ihre App direkt an das Schema eines Aggregators verdrahtet. Das funktioniert, bis Sie einen zweiten Anbieter oder eine Direktbank hinzufuegen, und bricht dann zusammen. Suchen Sie einen Partner, der zuerst das interne Kontomodell entwirft und jeden Anbieter als Mapping darauf behandelt.

3. Sicherheit und Compliance von Haus aus

Verschluesselte Token-Speicherung, SCA-korrekte Flows, PCI-Bewusstsein, SOC-2-Praktiken und ein echter Audit-Trail sollten von Tag eins an im Design stehen, nicht erst vor einem Enterprise-Sicherheits-Review angeflanscht werden.

4. Passung des Engagement-Modells

Open-Banking-Bestaende sind langlebig und wachsen mit jedem neuen Anbieter, jeder Bank und jeder regulatorischen Aenderung. Ein dediziertes Entwicklungsteam, das die Integration ueber die Zeit verantwortet, schlaegt fuer alles jenseits eines abgegrenzten Pilots meist eine einmalige Uebergabe.

5. Discovery-Disziplin

Bestehen Sie auf einer bezahlten Discovery, die die Anwendungsfaelle (Daten vs. Zahlungen), Anbieter, das Consent-Modell und die Compliance-Aufstellung abgrenzt, bevor eine Festpreis-Zusage faellt. Ein Partner, der nach einem Gespraech einen Festpreis fuer eine regulierte Open-Banking-Plattform nennt, bepreist das Risiko falsch — unser Leitfaden, wie Sie ein Softwareentwicklungsunternehmen waehlen, behandelt den vollstaendigen Pruefprozess.

FAQ

Was ist Open Banking?

Open Banking ist das regulierte, einwilligungsbasierte Teilen von Bankdaten und die Zahlungsausloesung ueber sichere APIs. Mit der ausdruecklichen Erlaubnis des Kunden kann ein lizenzierter Drittanbieter Kontodaten lesen (Account Information Services, AIS) oder eine Zahlung vom Konto ausloesen (Payment Initiation Services, PIS) — ohne Screen-Scraping oder das Speichern von Bankzugangsdaten. Ein Bankkonto wird zu etwas, mit dem sich Ihre Software ueber eine API verbinden kann.

Was ist der Unterschied zwischen PSD2 und PSD3?

PSD2 ist die EU-Richtlinie, die seit 2018 in Kraft ist und Banken verpflichtete, sichere APIs bereitzustellen, sowie starke Kundenauthentifizierung vorschrieb. PSD3 ist mit der Payment Services Regulation (PSR) die naechste Generation — im November 2025 politisch beschlossen, finale Texte im April 2026 veroeffentlicht, Anwendung etwa 2028 erwartet. Sie behaelt Open Banking bei, verschaerft aber API-Qualitaet, Betrugsschutz und SCA. Bauen Sie heute auf PSD2 und gestalten Sie fuer die strengeren Anforderungen von PSD3/PSR.

Ist Open Banking in den USA und der EU gleich?

Nein. Die EU ist regulierungsgetrieben: PSD2 zwingt Banken, APIs zu veroeffentlichen, sodass die Abdeckung breit und standardisiert ist. Die USA waren marktgetrieben ueber Aggregatoren (Plaid, MX, Finicity, Akoya, Yodlee) und den FDX-Standard; die Section-1033-Regel der CFPB vom Oktober 2024 ist umstritten, und 2025 begannen einige Banken, Aggregatoren fuer den Zugriff zu berechnen. Die praktische US-Aufstellung 2026 ist hybrid.

Sollte ich einen Aggregator wie Plaid nutzen oder Banken direkt anbinden?

Fuer die meisten Produkte beginnen Sie mit einem Aggregator: eine API deckt Tausende Banken ab und geht in 1–2 Wochen live. Direkte Bankintegrationen dauern jeweils 4–8 Wochen und lohnen sich nur fuer bestimmte Banken, geringere Kosten pro Aufruf bei hohem Volumen oder besondere Partnerschaften. Viele Teams fahren hybrid.

Wie funktioniert die Open-Banking-Authentifizierung?

Sie nutzt OAuth 2.0 mit dem Authorization-Code-Flow plus starker Kundenauthentifizierung. Ihre App leitet den Nutzer zu seiner Bank um, die Bank authentifiziert ihn mit zwei Faktoren, der Nutzer erteilt eine begrenzte Einwilligung, und die Bank gibt einen Code zurueck, den Sie gegen Access- und Refresh-Tokens eintauschen. Sie speichern die Bankzugangsdaten des Nutzers niemals, und die Einwilligung ist ausdruecklich und zeitlich befristet.

Wie lange dauert eine Open-Banking-Integration 2026 und was kostet sie?

Eine reine Lese-Aggregations-Integration kostet typischerweise $25k–$60k ueber 4–8 Wochen; eine produktive Umsetzung mit Zahlungsausloesung und Reconciliation $60k–$150k ueber 3–5 Monate; eine regulierte Plattform $150k–$400k+. Die groessten Treiber sind Zahlungen gegenueber reinem Lesezugriff, die Zahl der direkten Bankanbindungen und die Tiefe der Consent- und Compliance-Arbeit.

Zuletzt aktualisiert am 27. Juni 2026. Kosten- und Zeitspannen spiegeln integrationsfertige Umsetzungen fuer US- und EU-Fintech-Kunden wider und variieren je nach Umfang, Anwendungsfaellen, Anbietern und operativer Tiefe. Regulatorische Verweise (PSD2, PSD3/PSR, Section 1033, FDX) sind allgemeine Orientierung, keine Rechtsberatung — konsultieren Sie qualifizierte Rechtsberatung und Ihre Anbieter zu den aktuellen Anforderungen. Fordern Sie ein abgestecktes Angebot fuer Ihr konkretes Produkt an.