Eine Bank anzubinden ist einfach. Vierzig am Laufen zu halten nicht.

💡 Kurzfassung: Kernaussagen

• Eine einzelne Bankanbindung kann technisch überschaubar sein. Schwierig wird es, dreißig oder vierzig verschiedene Verbindungen aufzubauen und bei Änderungen der Banken funktionsfähig zu halten.
• Die Türkei verfügt über regulierte, standardisierte Open-Banking-Infrastruktur. Die von uns angetroffenen fragmentierten Schnittstellen waren etwas anderes: proprietäre Dienste, die Banken ihren Firmenkunden für den Zugriff auf die eigenen Kontodaten anbieten.
• Ein Integrationsanbieter verkauft mehr als eine gemeinsame API. Er übernimmt einen großen Teil der Vereinheitlichung, Überwachung, Änderungssteuerung und Wartung über mehrere Banken hinweg.
• Dieser Komfort schafft eine zusätzliche Vertrauensgrenze. Umgang mit Zugangsdaten, Datenspeicherort, Zugriffsrechte, Vorfallmanagement und Ausstiegsweg gehören zur Entscheidung.

Wir betreiben ein internes Finanz-Dashboard, das Informationen aus Zahlungsdiensten und weiteren Finanzsystemen zusammenführt.

Irgendwann wurden wir gefragt, ob es auch die Transaktionen der Firmenbankkonten anzeigen könne. Unsere erste Reaktion war optimistisch. Open Banking existiert, also musste es doch einen Standard geben. Mehrere Banken sollten sich ungefähr gleich integrieren lassen. Falls das zu umständlich wäre, könnten wir stattdessen einen fertigen Dienst nutzen.

Nachdem wir die Dokumentation einiger Banken gelesen hatten, entschieden wir uns gegen das Labyrinth direkter Integrationen. Wir banden einen Anbieter für Bankintegrationen an, übernahmen die benötigten Daten und zeigten sie in dem bereits genutzten Dashboard an.

Die Überraschung kam später, als ich den Einstellungsbildschirm für die Konfiguration der einzelnen Bankverbindungen sah.

Eine Bank erwartete Benutzername und Passwort. Eine andere stellte ein Token aus. Manche nutzten einen OAuth-ähnlichen Ablauf, andere verlangten eine freigegebene IP-Adresse. Bei einer musste die Verbindung in der Mobile-Banking-App aktiviert werden. Das Formular einer Bank hatte zwei Felder, das einer anderen zehn.

Die gewünschten Informationen waren bei allen weitgehend identisch: Konten, Salden und Transaktionen.

Die Türkei hat einen Open-Banking-Standard

Bevor wir weitergehen, ist eine wichtige Unterscheidung nötig. Es wäre falsch zu behaupten, Open Banking in der Türkei habe keinen Standard.

Die Türkei übernahm 2019 die PSD2-Konzepte für Zahlungsauslösung und Kontoinformationsdienste in das Gesetz Nr. 6493. Die Zentralbank der Republik Türkei – auf Englisch meist CBRT, auf Türkisch TCMB – legte anschließend einen nationalen API-Standard für diese Dienste fest. Teilnehmende Institute verbinden sich über GEÇİT, ein vom Interbank Card Center (türkisch BKM) entwickeltes API-Gateway. Die Open-Banking-Mitteilung der CBRT von 2022 beschreibt den Start dieser gemeinsamen Infrastruktur.

In den englischen Veröffentlichungen der CBRT heißt der Rahmen Data Sharing Services in the Field of Payments, kurz DSSP; die türkische Abkürzung lautet ÖHVPS. Der Standard umfasst Kontoinformationen und Zahlungsauslösung durch autorisierte Anbieter. Er ist kein ruhendes Grundsatzpapier: Version 2.0.0 ging im März 2026 in Betrieb. Sie erweiterte Konto- und Karteninformationsdienste und ergänzte geplante sowie wiederkehrende Zahlungsauslösungen.

Die von uns angetroffenen Integrationen waren nicht diese standardisierten GEÇİT-Dienste. Es waren proprietäre APIs und Webservices, die Banken Firmenkunden bereitstellen, damit diese ihre eigenen Kontotransaktionen abrufen können. Der Unterschied ähnelt dem zwischen reguliertem Open-Banking-Zugang für Dritte und einem direkten Datenservice der Bank für Firmenkunden.

Diese direkten Dienste sehen nicht alle gleich aus. Die Ziraat Bankası beschreibt beispielsweise einen XML-Webservice, der Kontotransaktionen von Firmenkunden in deren eigene Software integriert. DenizBank veröffentlicht getrennte APIs für Konten und Unternehmenstransaktionen in ihrem API-Portal.

Auch die rechtliche Einordnung hängt von mehr als dem Protokoll ab. Der DSSP-Umsetzungsleitfaden der CBRT unterscheidet zwischen einem Kunden, der direkt einen Vertrag mit seiner Bank schließt und von einem Dritten nur technische Unterstützung erhält, und einem Dritten, der Verträge mit Banken schließt, um Kunden Kontoinformationen bereitzustellen. Vertragspartner und Datenweg sind entscheidend.

Der Rest dieses Beitrags ist daher keine Kritik am regulierten Open-Banking-Standard der Türkei. Es geht um die fragmentierten direkten Firmenkundendienste der Banken, die wir für unsere eigenen Konten nutzen mussten.

Warum die Integration einer Bank einfach aussieht

Für sich genommen ist eine Bank handhabbar.

Sie lesen die Dokumentation, erhalten einen Testzugang, setzen Authentifizierung und Netzwerkzugang um, ordnen Konten, Salden und Transaktionen Ihrem Datenmodell zu, behandeln Fehler, testen den Ablauf und veröffentlichen die Integration.

Die Bank kann eine alte oder ungewöhnliche Methode einsetzen. Das allein macht die Aufgabe nicht automatisch zu einem schwierigen Entwicklungsproblem. Ein kompetentes Team kann eine klar abgegrenzte Integration mit einer Bank in angemessener Zeit abschließen.

Die Wirtschaftlichkeit ändert sich mit der Zahl der Banken. Sie wiederholen nicht bloß dieselbe Aufgabe, sondern übernehmen die kleinen Entscheidungen und Ausnahmen jeder Verbindung in Ihr eigenes System.

Zugangsdaten laufen ab. Eine IP-Adresse ändert sich und muss erneut registriert werden. Das sind nur die sichtbaren Unterschiede. Feldbedeutungen, Fehlercodes, Seitennavigation, Wartungsfenster, Grenzen historischer Daten, Datums- und Betragsformate sowie Duplikaterkennung müssen ebenfalls für jede Bank geprüft werden.

Die erste Implementierung ist nur der Anfang. Jemand muss eine Dienständerung bemerken, die Ursache einer unterbrochenen Verbindung finden, den Adapter aktualisieren, mögliche Lücken in der Transaktionshistorie prüfen und die Korrektur veröffentlichen, ohne andere Banken zu beeinträchtigen.

Ein kleiner Wartungsaufwand für eine Bank wird bei dreißig oder vierzig Banken zu einer eigenen Betriebsfunktion. Koordination, Überwachung und Verantwortung wachsen schneller als die technische Besonderheit der Aufgabe.

Was ein Integrationsanbieter tatsächlich verkauft

Bei einem einzelnen Konnektor lässt sich leicht sagen: „Das könnten wir selbst bauen.“ Vermutlich könnten wir das.

Das Produkt ist jedoch nicht nur ein Endpunkt, der Banktransaktionen zurückgibt. Der Anbieter übernimmt außerdem einen großen Teil der individuellen Bankanbindungen, übersetzt unterschiedliche Datenmodelle in eine gemeinsame Struktur, verfolgt Zugangsanforderungen und stellt eine Verbindung wieder her, wenn eine Bank etwas ändert.

Die von uns geprüften Anbieter hatten eigene Berichtsoberflächen. Wir entschieden uns gegen deren Nutzung. Wir bezogen lediglich die Daten und stellten sie in unserem eigenen Dashboard dar. Der Wert lag für uns nicht in einer weiteren Finanzoberfläche, sondern darin, Bankdaten in die bereits vorhandene betriebliche Sicht einzufügen.

Damit wird der Wert des Anbieters klarer. Er steckt nicht hauptsächlich im Code eines Adapters, sondern in der betrieblichen Fähigkeit, das gesamte Adapterportfolio am Leben zu halten.

Was ein gemeinsames Profil für Firmenkundenzugänge verändern würde

Es wäre unrealistisch, von allen Banken identische Produkte und interne Systeme zu erwarten. Ein gemeinsamer Mindeststandard für direkte Firmenkundendienste könnte dennoch viel unnötige Arbeit beseitigen.

Ein gemeinsames Branchenprofil könnte mindestens Folgendes abdecken:

• Registrierung von Kunden und Anwendungen
• Autorisierung für schreibgeschützten Kontozugriff
• Datenmodelle für Konten, Salden und Transaktionen
• Fehlercodes und Wiederholungsverhalten
• Versionierung, Änderungsmitteilungen und Auslaufregeln
• Testumgebungen und Prüfungen des Verbindungszustands

Ein solcher Standard würde Banken nicht zwingen, intern dieselbe Technologie zu verwenden. Er würde einen gemeinsamen externen Vertrag für die Informationen schaffen, die Firmenkunden wiederholt benötigen. Banken könnten sich weiterhin dort unterscheiden, wo ihre Produkte tatsächlich verschieden sind; nicht mehr jeder Transaktionsabruf bräuchte ein neues Zugangsmodell und eigenes Vokabular.

Die regulierte DSSP-Infrastruktur der Türkei zeigt bereits, dass ein gemeinsames API-Profil über mehrere Banken möglich ist. Ein ähnlicher Mindeststandard für direkte Firmenkundendienste würde nicht nur die Entwicklung erleichtern. Er könnte Integrationskosten senken, erzwungene Abhängigkeit von Aggregatoren reduzieren und kleineren Anbietern sowie internen Teams die Teilnahme erleichtern.

Der Anbieter nimmt Arbeit ab und schafft eine Vertrauensgrenze

Die Entscheidung gegen direkte Integrationen beseitigt nicht die Sicherheitsverantwortung. Sie fügt eine weitere Partei zwischen Bank und eigenem System ein.

Das bedeutet nicht, dass ein Integrationsanbieter grundsätzlich unsicherer wäre. Es bedeutet, dass wir nun zusätzlich zu Bank und eigenen Systemen von den Zugriffskontrollen, der Datenverarbeitung und der betrieblichen Kontinuität des Anbieters abhängen. „Wie viele Banken unterstützen Sie?“ und „Was kostet es im Monat?“ reichen für die Entscheidung nicht aus.

Mindestens diese Fragen brauchen klare Antworten:

• Wer speichert die Bankzugangsdaten, wo und wie lange?
• Lassen sich Berechtigungen auf schreibgeschützten Kontozugriff begrenzen?
• In welchem Land werden die Finanzdaten gespeichert, wann werden sie gelöscht und wer kann darauf zugreifen?
• Werden Zugriffe und Datenübertragungen in prüfbaren Protokollen erfasst?
• Wie werden Sicherheitsvorfälle und Verbindungsausfälle gemeldet?
• Wie exportieren wir unsere Daten und übertragen die Verbindungen, wenn wir den Anbieter verlassen?

Geschlossene Software beantwortet diese Fragen nicht automatisch. Ebenso ist eine quelloffene Sammlung von Bankadaptern nicht grundsätzlich unsicher.

Open Source kann uns erlauben, den Integrationscode zu prüfen und zu verändern. Es entscheidet aber nicht, wer Änderungen bei dreißig oder vierzig Banken überwacht, Sicherheitsaktualisierungen veröffentlicht oder Verantwortung übernimmt, wenn eine Verbindung ausfällt. Code kann verfügbar sein, während tragfähige Zuständigkeit fehlt.

Selbst entwickeln oder einkaufen?

Eine direkte Integration kann für ein System mit einer oder zwei Banken, reinem Lesezugriff und wenigen Änderungen vollkommen sinnvoll sein. Kann das Team Entwicklung und Betrieb verantworten, erzeugt eine weitere Schicht womöglich mehr Komplexität, als sie beseitigt.

Mit einem größeren Bankenportfolio ändert sich die Entscheidung. Ist die Überwachung vieler Verbindungen keine Fähigkeit, durch die sich das Unternehmen unterscheidet, wird die Übergabe an einen spezialisierten Anbieter vernünftiger. Die Gebühr ist eher der Preis für kontinuierliche Wartung und Vereinheitlichung als für einen API-Aufruf.

Nachdem wir die Dokumentation mehrerer Banken gelesen hatten, entschieden wir, daraus kein internes Produkt zu machen. Die Arbeit war möglich. Bei der benötigten Zahl von Banken hätte sie jedoch ein Wartungsprodukt geschaffen, das wenig damit zu tun hatte, worauf wir unsere Entwicklungsaufmerksamkeit richten wollten.

Ich wünschte weiterhin, ein gemeinsamer Mindeststandard wäre bei direkten Firmenkundendiensten weiter verbreitet. Unternehmen hätten dann eine ausgewogenere Wahl zwischen eigenen Integrationen und einem Vermittler. Die fragmentierte Oberfläche macht den Vermittler für viele Organisationen zur Standardoption und fügt der Beziehung neben Entwicklungskosten auch eine dritte Partei hinzu.

Eine Bank anzubinden mag einfach sein. Das eigentliche Produkt besteht darin, vierzig Verbindungen heute und nach der nächsten Änderung funktionsfähig zu halten.

Wenn Sie mit APIs für Firmenbanking in der Türkei arbeiten und ich einen gemeinsamen Weg oder eine wesentlich andere Praxis übersehen habe, freue ich mich über eine Korrektur.