Von der Fragmentierung zur Bruchlinie: Der fehlende API-Standard des Firmenkundengeschäfts im agentischen Zeitalter

TL;DR. Das Privatkundengeschäft erhielt seinen API-Standard vor einem Jahrzehnt. Das Firmenkundengeschäft nie — und da KI-Agenten und das Model Context Protocol die Integration zu einer Laufzeitentscheidung gemacht haben, ist die Lücke zur Bruchlinie geworden.

Points clés

Zwei Bankenwelten, eine davon standardisiert. Betrachtet man das Privatkundengeschäft, ist das Bild zwar unordentlich, aber navigierbar.
Warum die Fragmentierung überlebte — und warum das endet. Zwanzig Jahre lang war dies erträglich, weil der Integrator menschlich und geduldig war.
Der Aufrufer hat sich geändert. Dieser Nutzer traf binnen achtzehn Monaten ein.
Die Diskrepanz, genau bestimmt. Reduziert man den Agenten auf das, was er von einer Bank-Gegenpartei tatsächlich braucht, ist die Liste kurz und unnachgiebig:.

Das Privatkundengeschäft erhielt seinen API-Standard vor einem Jahrzehnt. Das Firmenkundengeschäft nie — und 2026 ist dieses Versäumnis keine Lästigkeit mehr, sondern eine Bruchlinie geworden. ISO 20022 gab der Branche eine gemeinsame Grammatik; eine gemeinsame, agentenfähige Oberfläche gab es ihr nie. Nun hat sich der Aufrufer geändert. Es ist nicht länger ein Entwickler, der ein Quartal für die Integration aufwendet, sondern ein Modell, das Werkzeuge zur Laufzeit entdeckt und Geld innerhalb von Richtlinienbändern bewegt. Die Mehrdeutigkeit, die Firmen-Treasurer zwanzig Jahre lang stillschweigend aufgefangen haben, wird demnächst einer Software übergeben, die sie nicht auffangen kann — während die darunterliegende Datenschicht zwangsweise strukturiert wird, ob es den Banken gefällt oder nicht. Dies ist es, was die fehlende Richtung kostet, warum Agenten die heutige Fragmentierung unsicher statt bloß ineffizient machen, und was ein Firmenkunden-API-Standard vorschreiben muss, bevor autonomes Treasury skalieren kann.

Zusammenfassung für Führungskräfte

Das Firmenkundengeschäft hat die Grammatik, nicht die Oberfläche. ISO 20022 standardisierte die Daten; niemand standardisierte die API. Das war tragbar, solange ein menschlicher Integrator die Mehrdeutigkeit auffing — ein Modell zur Laufzeit kann das nicht.

Der Aufrufer hat sich geändert. MCP machte die Werkzeugentdeckung zu einer Laufzeitentscheidung. Ein Agent, der das M×N-Integrationsproblem abschaffen sollte, trifft es an der Bankgrenze erneut an, wo jedes Institut ein maßgeschneiderter Server mit eigener Semantik ist.

Fragmentierung bewegt Geld nun falsch, mit Maschinengeschwindigkeit. Eine Zeitüberschreitung, drei Banken, drei widersprüchliche Wahrheiten — eine Dublette bei A, eine feststeckende Anweisung bei B, ein stiller Fehlschlag bei C. Idempotenz und eine deterministische Fehlergrammatik werden tragend.

Jede Bank in einen MCP-Server zu hüllen, verlagert den Sumpf. Vierzig Server, vierzig Semantiken, kein gemeinsamer nichtfunktionaler Boden — und ein nichtdeterministisches Modell mit Schreibzugriff auf Zahlungsverkehrsschienen, klar ein Problem von SR 11-7 / DORA / EU AI Act.

Standardisieren Sie Ihre eigene Oberfläche oder werden Sie zur Handelsware. Die Banken, die jetzt eine ISO 20022-native, agentenfähige API veröffentlichen, werden zu den Standard-Gegenparteien für autonomes Treasury; die übrigen vermieten ihre Kundenbeziehung an denjenigen, dem der Adapter gehört.

Zwei Bankenwelten, eine davon standardisiert

Betrachtet man das Privatkundengeschäft, ist das Bild zwar unordentlich, aber navigierbar. Europa hat UK Open Banking und den NextGenPSD2 der Berlin Group, letzterer von mehr als drei Vierteln der europäischen Banken übernommen und in der Praxis als De-facto-Standard behandelt. Die Vereinigten Staaten haben den Financial Data Exchange, der inzwischen mehr als sechzig Millionen Verbraucherkonten umfasst. Australien hat das Consumer Data Right. Keiner davon ist global, und keiner dürfte global werden — aber jeder ist ein echter, versionierter, maschinell prüfbarer Vertrag, und wo die Verträge enden, fangen die Aggregatoren (Plaid, Tink, TrueLayer, Salt Edge) die Differenz hinter einer einzigen Schnittstelle auf. Fragmentierung im Privatkundengeschäft ist eine Steuer. Sie ist keine Mauer.

Das Firmen- und Wholesale-Geschäft hat kein Äquivalent. Ein multinationales Treasury erreicht seine Banken über Host-to-Host-Dateileitungen, ein Dutzend maßgeschneiderter Portale, ein Treasury-Management-System oder einen Aggregator — meist alle vier zugleich. Dies ist kein Strohmann: McKinseys eigene Transaction-Banking-Forschung katalogisiert dieses Erbe seit Jahren, beschreibt, wie Banken sich auf Host-to-Host- und SFTP-Dateitransfer stützen, listet die bekannten Fehlerbilder der dateibasierten Integration auf — sperrige ERP-Formate, die pro Firmenkunde angepasst werden müssen, eine Unfähigkeit, bedingtes Routing zu handhaben — und berichtet, dass über 85 % der Transaction-Banking-Führungskräfte in Cash-Management-APIs investieren wollen. Der Appetit auf APIs steht nicht in Frage. Was fehlt, ist der gemeinsame Vertrag, auf den sie zeigen.

Denn die üblichen Kandidaten sind es nicht. ISO 20022 wird regelmäßig für den fehlenden Standard gehalten, doch es ist eine Datengrammatik, kein API-Vertrag: pain.001 sagt Ihnen, wie eine Überweisung zu formulieren ist, nicht welcher Endpunkt eine erzeugt, wie sie authentifiziert, wie sie paginiert oder wie sie Ihnen mitteilt, dass sie fehlschlug. BIAN gibt der Branche ein gemeinsames semantisches Referenzmodell, keine durchgesetzte Schnittstelle. Swifts Payment-Initiation- und Instant-Cash-Reporting-APIs sind ein echter Schritt zur Standardisierung, doch sie sind netzwerkzentriert und noch im Entstehen, keine universelle Oberfläche. Das openFinance-Rahmenwerk der Berlin Group greift nach Firmenkunden-Anwendungsfällen — Kontoeröffnung, Handelsfinanzierung, dynamische wiederkehrende Zahlungen — doch es ist europäisch, früh und premium-per-Vereinbarung. Fügt man all das zusammen, hat man noch immer keinen verbindlichen, globalen Firmenkunden-API-Standard. Man hat Baumaterialien und keinen Bauplan.

Warum die Fragmentierung überlebte — und warum das endet

Zwanzig Jahre lang war dies erträglich, weil der Integrator menschlich und geduldig war. Ein Firmenkunde bündelte über Monate, mitunter Quartale, eine Handvoll Bankverbindungen. Jede war ein Projekt: Zertifikate ausgetauscht, ein Cent-Test durchgeführt, ein Mapping-Dokument durchgefochten. Die Kosten waren real, aber einmal pro Beziehung entrichtet und über Jahre nachfolgender Zahlungen amortisiert. Wenn die API einer Bank unterspezifiziert war — wenn ein Standard „den Rest dem umsetzenden Institut überließ", wie Banken es selbst beklagen —, las ein menschlicher Ingenieur das Portal, leitete die Absicht ab und überbrückte die Lücke. Mehrdeutigkeit war tragbar, weil ein Mensch da war, um sie aufzulösen.

Sie überlebte auch aus Gründen, die seltener laut ausgesprochen werden. Die darunterliegende Infrastruktur ist wirklich schwer zu ändern: Batch-Settlement-Fenster, Übernachtzyklen und Mainframe-Kerne, die nie dafür ausgelegt waren, eine Echtzeitfrage zu beantworten. Und Fragmentierung ist nicht nur ein Zufall — sie ist, im Stillen, eine Form von Lock-in. Jede maßgeschneiderte Host-to-Host-Leitung, die ein Treasurer aufbaut, ist ein Wechselkosten-Faktor, der dem Platzhirsch zugutekommt. Eine Bank, die schwer zu integrieren ist, ist, am Rande, eine Bank, die schwer zu verlassen ist. Nichts davon ist verschwörerisch; es ist gewöhnlicher Anreiz. Doch es erklärt, warum eine Branche, die sich auf eine Datengrammatik geeinigt hat, sich nie auf eine Oberfläche geeinigt hat — und warum die Oberfläche die letzte verbliebene nicht standardisierte Schicht ist. Der Grund, warum sie nicht länger halten kann, ist, dass die Schicht darunter fristgebunden zwangsweise strukturiert wird und die Schicht darüber gerade einen neuen, ungeduldigen Nutzer erhalten hat.

Der Aufrufer hat sich geändert

Dieser Nutzer traf binnen achtzehn Monaten ein. Das Model Context Protocol, das Anthropic im November 2024 quelloffen stellte und im Dezember 2025 gemeinsam mit Block und OpenAI der Agentic AI Foundation der Linux Foundation überließ, ist zur Standardart geworden, mit der KI-Systeme Werkzeuge und Daten erreichen. Anfang 2026 verzeichnete es rund siebenundneunzig Millionen SDK-Downloads pro Monat; zur Jahresmitte liefen nach einer richtungsweisenden Brancheneinschätzung etwa achtundsiebzig Prozent der KI-Teams in Unternehmen MCP-gestützte Agenten in Produktion, und mehr als ein Viertel der Fortune 500 betrieb MCP-Server, abgesichert über eine standardmäßige OAuth 2.1-Autorisierungsschicht. Es wird routinemäßig, und zutreffend, als USB-C für KI beschrieben: Es reduziert den M×N-Integrationsalptraum — jedes Modell von Hand mit jedem Werkzeug verdrahtet — auf M+N. Seine eigene Selbstbeschreibung ist die Zeile, die für Banken zählt: APIs sind für Programme; MCP ist für Agenten. Eine REST-API erwartet, dass der Aufrufer im Voraus weiß, welchen Endpunkt er mit welchen Parametern ansteuern muss. Ein Agent erwartet, die verfügbaren Werkzeuge zur Laufzeit zu entdecken und selbst zu entscheiden, wie und wann er sie nutzt.

Für das Treasury ist dies nicht hypothetisch. Das Muster ist 2026 bereits über die Treasuries von Firmen- und Investmentbanken hinweg konsistent: Ein Agent liest ISO 20022-Liquiditätsdaten, ruft ein begrenztes Werkzeugset auf und rebalanciert Liquidität innerhalb von Richtlinienbändern, umgeben von Kontrollen nach SR 11-7, DORA und EU AI Act. Die Datengrammatik ist dafür bereit. Die API-Oberfläche nicht.

Die Diskrepanz, genau bestimmt

Reduziert man den Agenten auf das, was er von einer Bank-Gegenpartei tatsächlich braucht, ist die Liste kurz und unnachgiebig:

Ein maschinell entdeckbarer Vertrag — eine OpenAPI-Beschreibung oder ein Werkzeugmanifest, das der Agent zur Laufzeit lesen kann, statt eines PDFs, das ein Mensch einmal liest.
Ein einziges Authentifizierungsmodell — ein finanzgerechtes OAuth2/mTLS-Profil (FAPI ist der naheliegende Anker), nicht ein anderer Handshake pro Bank.
Idempotenz als Garantie — eine eindeutige Anweisungsreferenz, die eine wiederholte Zahlung zum No-op macht, weil ein Agent es wiederholen wird.
Eine deterministische Fehlergrammatik — derselbe Fehlschlag bedeutet überall dasselbe, damit das Modell darüber schlussfolgern kann.
Semantische Versionierung und Fähigkeitsentdeckung — damit ein Agent erkennen kann, was eine Gegenpartei in diesem Quartal leisten kann, ohne einen menschlichen Release-Vermerk.
Strukturierte ISO 20022-Nutzdaten, Einwilligung und Berechtigungen sowie eine manipulationssichere Audit-Spur — die Substanz, die Erlaubnis und der Nachweis.

Setzt man dies dem Firmenkundengeschäft gegenüber, wie es existiert, zersplittert jede Zeile in N Dialekte — einen pro Bank. Der Agent, der das M×N-Problem abschaffen sollte, trifft es an der Bankgrenze erneut an, weil jedes Institut faktisch ein maßgeschneiderter Server ist mit eigener Grammatik für „Saldo", eigener Vorstellung von „Zahlungsstatus", eigenem Authentifizierungstanz und eigener Auffassung davon, was ein Fehler ist. Das Protokoll standardisierte die Agentenseite der Leitung. Niemand standardisierte die Bankseite.

Ein Fehlerbild, konkret gemacht

Machen wir es konkret, denn hier beißt die Abstraktion. Stellen Sie sich einen Liquiditätsagenten vor, der befugt ist, Zahlungsmittel über drei Banken hinweg zu bündeln, um jedes Konto innerhalb eines Zielbands zu halten. Er feuert drei nahezu identische Anweisungen ab und stößt, wie es in Netzen geschieht, bei jeder auf eine Zeitüberschreitung.

Bank A behandelt die Zeitüberschreitung als unbekannt — sicher zu wiederholen, also wiederholt der Agent, und die ursprüngliche Anweisung wird ebenfalls abgewickelt: eine Dublettenzahlung. Bank B behandelt dieselbe Zeitüberschreitung als eingereicht — nicht wiederholen, liefert aber nie eine Bestätigung, die der Agent parsen kann, sodass die Anweisung in der Schwebe verharrt, während der Agent, der keinen Erfolg sieht, eskaliert oder umleitet: eine feststeckende Zahlung und eine doppelt gebuchte Position. Bank C gibt ein munteres HTTP 200 zurück, mit einer im Nutzdatenkörper vergrabenen Ablehnung; der Agent liest den Statuscode, markiert die Bündelung als erledigt und fährt fort: ein stiller Fehlschlag, der erst am nächsten Morgen als Abstimmungsbruch auftaucht, den niemand erklären kann.

Drei Banken, eine Bedingung, drei widersprüchliche Wahrheiten — Dublettengelder aus der Tür bei A, eine eingefrorene Anweisung bei B, ein Phantom-Erfolg bei C. Ein menschlicher Treasurer hätte drei Kundenbetreuer angerufen und die Sache bis zum Mittag geklärt. Der Agent kann niemanden anrufen. Genau deshalb sind „Idempotenz als Garantie" und „eine deterministische Fehlergrammatik" keine architektonischen Annehmlichkeiten: Ohne sie bewegt dieselbe Fragmentierung, die zuvor bloß Menschenstunden kostete, nun echtes Geld fehlerhaft, mit Maschinengeschwindigkeit, über jede Gegenpartei zugleich.

Warum „jede Bank in einen MCP-Server hüllen" nicht die Lösung ist

Die reflexartige Antwort lautet, jeder Bank einen MCP-Server zu geben und fertig. Sie hält nicht stand, denn sie verlagert die Fragmentierung, statt sie zu beseitigen. Vierzig Banken werden zu vierzig Servern mit vierzig Semantiken, vierzig Authentifizierungsabläufen und keiner gemeinsamen Bedeutung — und, entscheidend, keinem gemeinsamen nichtfunktionalen Boden: kein gemeinsames Latenzbudget, keine vereinbarte Verfügbarkeitsstufe, keine vergleichbare Idempotenz-Garantie. Das obige Fehlerbild überlebt die Hülle unversehrt. Schlimmer noch: Der Aufrufer ist nun ein nichtdeterministisches Modell mit Schreibzugriff auf Zahlungsverkehrsschienen, was nicht bloß eine Integrationsfrage ist, sondern eine Frage des Modellrisikos und der operationellen Resilienz, die klar auf SR 11-7, DORA und den EU AI Act fällt. Die Human-in-the-Loop-Primitive von MCP — Elicitation zur Bestätigung, Sampling zur Schlussfolgerung — sind notwendig und willkommen, doch ein Bestätigungsdialog ist kein Ersatz für eine Gegenpartei, die sich vorhersehbar verhält. Man kann in großem Maßstab nicht steuern, was man nicht einheitlich beschreiben kann. Tausend maßgeschneiderte Server sind kein Standard; sie sind derselbe Sumpf mit einer JSON-RPC-Verkleidung.

Zwei Zukünfte und eine strategische Entscheidung

Wer dies auflöst, bestimmt, wem die Firmenkundenbeziehung im nächsten Jahrzehnt gehört, und es gibt nur zwei Kandidaten.

Im ersten Fall standardisieren Banken ihre eigenen Oberflächen. Sie veröffentlichen agentenfähige APIs, behalten die direkte Verbindung zum Treasurer und bleiben die Gegenpartei, die der Agent entdeckt und aufruft. Im zweiten Fall standardisieren die Aggregatoren sie für sie. Eine Handvoll Plattformen definiert den De-facto-Agentenvertrag, und Banken werden zu austauschbaren Endpunkten dahinter — nur noch über die Abstraktion eines anderen erreichbar. Dies ist keine Spekulation; es ist die Privatkundengeschichte, um ein Segment vorwärtsgespielt. McKinseys eigene Transaction-Banking-Arbeit von 2025 beschreibt Treasury-Management-Plattformen wie Kyriba und GTreasury sowie Office-of-the-CFO-Plattformen wie Bill.com, die sich mit einem einzigen, bankunabhängigen Blick auf die Position zwischen Kunden und Banken positionieren. Es ist genau die Schicht, die im Privatkundengeschäft im Stillen den Long Tail hinter Plaid und Tink verschwinden ließ. Dieselbe Forschung merkt an, dass Firmen-Treasurer ihre Banken inzwischen an den Standards ihrer Verbraucher-Apps messen und wechseln werden, wenn Onboarding, Berechtigungen und API-Integration enttäuschen.

Der strategische Gehalt der Entscheidung ist unverblümt. Eine Bank, die zu einem Endpunkt hinter dem Agentenvertrag eines Aggregators wird, gibt drei Dinge zugleich auf. Marge, da ihre Dienste zur Handelsware gemacht und über die Schnittstelle eines anderen zuerst nach Preis verglichen werden. Kundeneigentum, da die Beziehung, der Kontext und die Wechselkosten zur Plattform abwandern. Und Daten- und Analysemacht, da der Fluss, den sie einst durchgängig sah, nun von einem Zwischenhändler vermittelt wird, der mehr vom Kunden sieht als die Bank. Die eigene Oberfläche zu standardisieren ist kein technisches Hygieneprojekt. Es ist der Unterschied, ob man die Gegenpartei ist oder die Handelsware.

Was der Standard vorschreiben muss

Die fehlende Richtung ist nicht exotisch. Jede Komponente existiert bereits offen — ISO 20022 für Daten, Swifts Payment-Initiation- und Instant-Cash-Reporting-APIs für Referenzoperationen, BIAN für Semantik, das openFinance der Berlin Group für das Muster aus Einwilligung und Katalog, FAPI für finanzgerechte Authentifizierung, MCP für die Werkzeugbereitstellung, A2A für die Agent-zu-Agent-Orchestrierung. Was fehlt, ist der Akt, sie zu einem verbindlichen Vertrag für den Firmenkundenraum zusammenzufügen — und die Disziplin, zwei Böden zu spezifizieren, nicht einen. Die bestehende B2B-API-Literatur, McKinseys eingeschlossen, behandelt APIs weitgehend als Wachstums- und Erlebnischance. Sie sagt wenig über Determinismus, Fähigkeitsentdeckung zur Laufzeit oder standardisierte Nichtfunktionalitäten — genau das Versäumnis, das Agenten nicht tolerieren können. Der Standard muss also ausdrücklich beides festlegen: was die Schnittstelle ist und wie sie sich unter Governance verhält.

Der technische Boden

Ein OpenAPI-first-Vertrag mit einem kanonischen MCP-Werkzeugmanifest, das daraus generiert wird — nicht daneben von Hand geschrieben, damit die Werkzeuge, die ein Agent sieht, niemals von der API abweichen können, die die Bank betreibt.
FAPI-gerechte Authentifizierung und Einwilligung als einziger Handshake über die gesamte Oberfläche.
Idempotenz und eine deterministische Fehlertaxonomie — stabile Codes, eine Bedeutung pro Fehlschlag, im Vertrag selbst dokumentiert.
ISO 20022-native Nutzdaten, strukturiert und für hybride Adressen bereit.
Semantische Versionierung mit Fähigkeitsentdeckung zur Laufzeit — ein Agent kann fragen, was diese Gegenpartei heute leisten kann, und erhält eine maschinelle Antwort.

Der Boden für Governance und Resilienz

Veröffentlichte, durchgesetzte nichtfunktionale SLOs — Latenz, Verfügbarkeit, Durchsatz, Straight-Through-Processing und menschlicher Aufwand — ausgedrückt als reale Zeit-und-Bewegungs-Kennzahlen, nicht als Marketingsprache.
Berechtigungen, Einwilligung und eine manipulationssichere Audit-Spur, an den Ausführungspfad gebunden, nicht in einem Portal außerhalb des Bandes schwebend.
Kontrollen für Modellrisiko und operationelle Resilienz, ausgerichtet an SR 11-7, DORA und dem EU AI Act, sodass die Aufrufe eines Agenten gesteuerte Ereignisse mit einem Verantwortlichen sind, keine exotischen Grenzfälle.

Hier ist eine harte Lektion in der Privatkundenerfahrung verborgen. Ein Standard, den eine Maschine ausführt, muss präziser sein als einer, den ein menschlicher Integrator im Stillen reparieren kann; Unterspezifikation ist keine weiche, in Entwicklerstunden bezahlte Kostenposition mehr, sondern ein hartes Fehlerbild, bezahlt in fehlgeleiteten Zahlungen. Es ist bezeichnend, dass die maßgeblichste Harmonisierungsbemühung der Branche — die harmonisierten ISO 20022-Datenanforderungen von CPMI und PMPG, die Zahlungssysteme weltweit unter dem G20-Programm für grenzüberschreitende Zahlungen bis Ende 2027 übernehmen sollen, um genau diese Fragmentierung zu bekämpfen — nach ihrer eigenen Beschreibung weder eine Regulierung noch ein API-Standard ist. Sie harmonisiert die Daten. Die Schnittstelle ist noch immer niemandes Aufgabe.

Ein Zielbild

Der Aufbau ist weniger einschüchternd als die Diagnose, denn es sind drei Schichten, kein Programm. Eine kanonische Firmenkunden-API stellt Zahlungen und Liquiditätsberichterstattung über REST und OpenAPI bereit, mit ISO 20022-nativen Nutzdaten und FAPI-gerechter Authentifizierung — ein Vertrag, eine Grammatik, ein Handshake. Eine MCP-Brücke sitzt darüber und generiert das agentenzugewandte Werkzeugmanifest direkt aus diesem OpenAPI-Vertrag, sodass Entdeckung, Schemata und Berechtigungen aus der Oberfläche abgeleitet und nicht parallel dazu gepflegt werden. Und eine Richtlinien- und Resilienzschicht umgibt jeden Agentenaufruf mit den Kontrollen, die Autonomie sicher machen: Transaktions- und Gegenparteilimits, Segmentierung, Human-in-the-Loop-Auslöser (Elicitation bei risikoreichen Aktionen), Live-SLO-Überwachung und eine harte Notabschaltung. Keine Diagramme sind nötig, um den Punkt zu erfassen — der Standard ist keine neue Schiene, er ist eine disziplinierte Anordnung bereits existierender Schienen, mit dem Agentenpfad und dem Governance-Pfad, die vom ersten Commit an eingebaut und nicht nach dem Vorfall angeflanscht werden.

Was glaubwürdige Banken in den nächsten 24 Monaten tun

Wenn Sie akzeptieren, dass sich der Aufrufer geändert hat, ist die Arbeit konkret und gliedert sich in fünf Stränge.

Veröffentlichen Sie eine ISO 20022-native, OpenAPI-first-Oberfläche. Nehmen Sie einen hochwertigen Korridor — typischerweise grenzüberschreitende Zahlungen und Liquiditätsberichterstattung — und stellen Sie ihn über eine einzige, versionierte OpenAPI-Definition mit ISO 20022-Nutzdaten bereit, ausgerichtet an Ihren bestehenden CBPR+-Schemata statt an einer fünften erfundenen Grammatik. Machen Sie sie Kunden und internen Agenten zugänglich, mit einer Sandbox, und behandeln Sie Änderungen als Produkt-Releases. Der Erfolg im ersten Jahr ist nicht vollständige Abdeckung; er besteht darin zu belegen, dass ein Korridor durchgängig agentenadressierbar gemacht werden kann.
Standardisieren Sie Authentifizierung und Idempotenz darüber hinweg. Übernehmen Sie ein FAPI-gerechtes Profil als einzigen Handshake, schreiben Sie Idempotenzschlüssel bei jedem Schreibvorgang vor und machen Sie „dieselbe Anweisung wiederholen" zu einer im Vertrag dokumentierten Garantie — sodass aus „Agenten werden wiederholen" aus einem Risiko eine sichere Annahme wird.
Definieren Sie eine deterministische Fehlergrammatik und Fähigkeitsentdeckung. Geben Sie jedem Fehlschlag einen stabilen Code und konsistente Semantik, fügen Sie semantische Versionierung hinzu und stellen Sie einen Fähigkeitskatalog bereit, den ein Agent zur Laufzeit abfragen kann, mit expliziten Kennzeichnungen für Teilunterstützung, Veraltung und „noch nicht verfügbar".
Binden Sie Berechtigungen, Einwilligung und Audit an dieselbe Oberfläche. Verlagern Sie Einwilligungs- und Genehmigungsabläufe auf den API-Pfad, geben Sie für jede agenteninitiierte Anweisung eine manipulationssichere Spur aus — wer, was, wann, unter welchem Richtlinienband — und richten Sie sie ausdrücklich an SR 11-7, DORA und dem EU AI Act aus, damit die zweite Verteidigungslinie sie abzeichnen kann.
Veröffentlichen Sie nichtfunktionale Böden, dann führen Sie einen überwachten Agentenpiloten durch. Verpflichten Sie sich für den Korridor auf Ziele für Latenz, Verfügbarkeit, Durchsatz und STP und instrumentieren Sie sie; stellen Sie dann einen überwachten Liquiditäts- oder Cash-Sweeping-Agenten auf, der ausschließlich diese Oberfläche nutzt, mit harten Limits, Human-in-the-Loop-Kontrollpunkten und vollständigem Audit, für sechs bis zwölf Monate. Dies ist die Zwangsfunktion, die Sie selbst steuern — sie belegt, dass ein Agent Geld sicher innerhalb von Richtlinienbändern bewegen kann, wenn die Oberfläche vorhersehbar ist, und sie sagt Ihnen rasch, wo Ihr Standard noch Anspruch statt Tatsache ist.

Die Zwangsfunktion

Die Branche hat gerade bewiesen, dass sie sich bewegen kann, wenn etwas sie dazu zwingt. Swifts Umstellung auf strukturierte Adressen im November 2026 — nach der unstrukturierte Adressen im grenzüberschreitenden Zahlungsverkehr schlicht abgelehnt werden, ohne Notfallkonvertierung — hat einen widerstrebenden Markt zu strukturierten ISO 20022-Daten mit festem Datum gedrängt, verstärkt durch den Ende-2027-Vorstoß der CPMI für harmonisierte Datenanforderungen im gesamten G20-Zahlungsprogramm. Beachten Sie, was beide Bemühungen standardisieren: die Daten, nicht die Schnittstelle. Die Grammatik wird zwangsweise sauber gemacht. Die Oberfläche wurde dem Ermessen jeder Bank überlassen — genau das Ermessen, mit dem Agenten nicht arbeiten können. Für einen Agenten bedeutet das, dass die Nutzdaten endlich konsistent sein werden, während das Verhalten dahinter divergent bleibt — eine Umkehrung dessen, was eine Maschine tatsächlich braucht, nämlich vorhersehbares Verhalten zuerst und saubere Daten danach.

Dies also ist der unerzwungene Fehler, den es zu vermeiden gilt: auf ein globales Gremium zu warten, das einen Firmenkunden-API-Standard segnet, bevor man handelt. Die Banken, die jetzt eine ISO 20022-native, agentenfähige Oberfläche veröffentlichen — einen OpenAPI-Vertrag, ein daraus generiertes MCP-Manifest, finanzgerechte Authentifizierung und nichtfunktionale Böden, für die sie tatsächlich einstehen —, werden zu den Standard-Gegenparteien für autonomes Treasury. Ihre Werkzeuge werden diejenigen sein, die die Agenten entdecken, denen sie vertrauen und die sie ohne einen Menschen dazwischen aufrufen können. Die Banken, die warten, werden nur noch über die Abstraktion eines Aggregators erreichbar sein und ihre eigene Kundenbeziehung an denjenigen vermieten, dem der Adapter gehört.

Grammatik ohne Richtung ist kein Standard. ISO 20022 sagte dem Firmenkundengeschäft, wie es sprechen soll. Es sagte ihm nie, wohin es gehen soll. Die Agenten sind eingetroffen, fließend und ungeduldig, und die Landkarte ist noch immer nicht da. Sie zu zeichnen ist nun die folgenreichste Infrastrukturarbeit im Transaction Banking — und, ausnahmsweise, wird die Frist nicht von einer Aufsichtsbehörde gesetzt, sondern von den Maschinen, die bereits an der Schnittstelle warten.

Häufig gestellte Fragen

Ist ISO 20022 nicht der fehlende Standard? Nein. ISO 20022 ist eine Datengrammatik, kein API-Vertrag. pain.001 sagt einem System, wie eine Überweisung zu formulieren ist; es sagt nicht, welcher Endpunkt eine erzeugt, wie sie authentifiziert, wie sie paginiert oder wie sie einen Fehlschlag meldet. Die Grammatik ist für Agenten bereit. Die Oberfläche — die maschinell entdeckbare, einheitlich sich verhaltende Schnittstelle, die ein Agent tatsächlich aufruft — ist es nicht.

Warum nicht einfach jede Bank in einen MCP-Server hüllen? Weil es die Fragmentierung verlagert, statt sie zu beseitigen. Vierzig Banken werden zu vierzig Servern mit vierzig Semantiken, vierzig Authentifizierungsabläufen und — entscheidend — keinem gemeinsamen nichtfunktionalen Boden: kein gemeinsames Latenzbudget, keine vereinbarte Verfügbarkeitsstufe, keine vergleichbare Idempotenz-Garantie. Der Aufrufer ist nun ein nichtdeterministisches Modell mit Schreibzugriff auf Zahlungsverkehrsschienen, was ein Problem des Modellrisikos und der operationellen Resilienz unter SR 11-7, DORA und dem EU AI Act ist. Tausend maßgeschneiderte Server sind kein Standard.

Was ist der einzige nützlichste erste Schritt für eine Bank? Veröffentlichen Sie einen ISO 20022-nativen, OpenAPI-first-Korridor — typischerweise grenzüberschreitende Zahlungen und Liquiditätsberichterstattung — mit einem FAPI-gerechten Handshake, Idempotenz als dokumentierter Garantie und einer deterministischen Fehlergrammatik. Führen Sie dann einen überwachten Agentenpiloten ausschließlich gegen diese Oberfläche durch, mit harten Limits, Human-in-the-Loop-Kontrollpunkten und vollständigem Audit. Einen Korridor durchgängig zu belegen schlägt eine Roadmap, die alles abdeckt und nichts vorschreibt.

Wer löst dies auf, wenn die Banken es nicht tun? Die Aggregatoren. Eine Handvoll Treasury- und Office-of-the-CFO-Plattformen werden den De-facto-Agentenvertrag definieren, und Banken werden zu austauschbaren Endpunkten dahinter — und geben Marge, Kundeneigentum und durchgängige Daten zugleich auf. Es ist die Privatkundengeschichte, in der Plaid und Tink den Long Tail auffingen, um ein Segment vorwärtsgespielt ins Firmenkundengeschäft.

Quellen

Model Context Protocol — offizielle Dokumentation ⧉. [MCP im November 2024 quelloffen gestellt und im Dezember 2025 gemeinsam mit Block und OpenAI der Agentic AI Foundation der Linux Foundation überlassen; die Laufzeit-Werkzeugentdeckungsschicht, auf der die Analyse aufbaut. Die Übernahmezahlen im Text sind richtungsweisende Brancheneinschätzungen und als solche gekennzeichnet.]
Berlin Group — NextGenPSD2 und openFinance ⧉. [Der De-facto-europäische Privatkunden-API-Standard und seine Ausrichtung auf Firmenkunden-Anwendungsfälle — zitiert für das Muster aus Einwilligung und Katalog sowie den Kontrast zwischen Privat- und Firmenkundengeschäft.]
Financial Data Exchange (FDX) ⧉. [Der US-Standard für den Austausch von Privatkundendaten, zitiert für das Ausmaß standardisierter Privatkundenverträge, denen das Firmenkundengeschäft nichts Gleichwertiges entgegenzusetzen hat.]
McKinsey & Company — Einblicke in Financial Services ⧉. [Transaction-Banking-API-Forschung: Host-to-Host- / SFTP-Erbe, die rund 85 % Investitionsabsicht in Cash-Management-APIs und die Treasury-Plattform-Vermittlung. Zitiert für die Marktdiagnose; die Rahmung und die Schlussfolgerungen hier sind die des Autors.]
Bank für Internationalen Zahlungsausgleich (CPMI) — Harmonisierte ISO 20022-Datenanforderungen ⧉. [Der Ende-2027-Vorstoß zur Harmonisierung der Zahlungsdaten — nach eigener Beschreibung weder eine Regulierung noch ein API-Standard — zitiert für den Punkt „Grammatik ohne Oberfläche".]
Swift — ISO 20022 für Finanzinstitute ⧉. [CBPR+ und der Meilenstein der strukturierten Adresse im November 2026; Payment-Initiation- und Instant-Cash-Reporting-APIs zitiert als Referenzoperationen, nicht als universelle Oberfläche.]

Zuletzt geprüft im Juli 2026. Originalanalyse; Quellen sind zitiert, nicht reproduziert. Übernahme- und Marktzahlen sind richtungsweisende Brancheneinschätzungen — vor einer erneuten Veröffentlichung anhand von Primärquellen zu verifizieren. Lizenziert unter CC-BY-4.0.

Zuletzt überprüft 2026-07-08.

Diesen Artikel republizieren

Von der Fragmentierung zur Bruchlinie: Der fehlende API-Standard des Firmenkundengeschäfts im agentischen Zeitalter — Sebastien Rousseau

Das Privatkundengeschäft erhielt seinen API-Standard vor einem Jahrzehnt. Das Firmenkundengeschäft nie — und da KI-Agenten und das Model Context Protocol die Integration zu einer Laufzeitentscheidung gemacht haben, ist die Lücke zur Bruchlinie geworden.

Dieser Artikel ist lizenziert unter Creative Commons Attribution 4.0 International. Eine Republikation erfordert Attribution zur kanonischen URL.

Von der Fragmentierung zur Bruchlinie: Der fehlende API-Standard des Firmenkundengeschäfts im agentischen Zeitalter — Sebastien Rousseau

Das Privatkundengeschäft erhielt seinen API-Standard vor einem Jahrzehnt. Das Firmenkundengeschäft nie — und da KI-Agenten und das Model Context Protocol die Integration zu einer Laufzeitentscheidung gemacht haben, ist die Lücke zur Bruchlinie geworden.

Originally published at https://sebastienrousseau.com/de/2026-07-07-corporate-banking-api-standard-agentic-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER