Mit zunehmender Nutzung von ISO 20022 steigt auch die Nachfrage nach neuen Anwendungsfällen und neuen Wegen des Datenaustauschs, wobei ein prominentes Beispiel APIs sind, die von Finanzinstituten für zahlreiche Anwendungen genutzt werden, wie etwa den Zugriff auf Kontoinformationen, die Initiierung von Zahlungen, Open Banking oder interne Systemintegrationen.
API-Entwickler, insbesondere bei der Entwicklung von REST-APIs1, verfolgen oft einen minimalistischen Ansatz, bei dem die Effizienz im Vordergrund steht und nur die für eine bestimmte Anfrage und Antwort erforderlichen Daten übermittelt werden. Informationen, die über eine API ausgetauscht werden, werden üblicherweise im JSON-Format (JavaScript Object Notation) gesendet, das zwar XML ähnelt, aber einige geringfügige Inkompatibilitäten aufweist.
Da ISO 20022 keine JSON-Schemas veröffentlicht und es derzeit keine allgemein anerkannten Regeln für die Darstellung in diesem Format gibt, kann dies für API-Entwickler, die den Standard nutzen möchten, eine Herausforderung darstellen.
ISO 20022 unterstützt globale Anwendungsfälle für Finanznachrichten, was bedeutet, dass jede Nachricht viele Elemente enthält. Obwohl die wichtigsten Elemente, die für den Austausch einer bestimmten Geschäftsnachrichten, beispielsweise eine Kreditüberweisung, recht konsistent bleiben (Name des Schuldners, Name des Gläubigers, Betrag, Währung usw.), gibt es Unterschiede in der Verwendung dieser Elemente. Beispielsweise wird in lokalen Clearinghäusern ein Debtor Agent (Bank of the Debtor) in Deutschland mit einem BIC (Business Identifier Code) oder einer Bankleitzahl (BLZ – abgeleitet vom IBAN) definiert, in Australien jedoch mit einer BSB-Nummer (Bank State Branch) identifiziert.
Um dem gerecht zu werden, sind ISO-20022-Nachrichten so strukturiert, dass man entweder das eine oder das andere anbieten kann, aber diese Flexibilität führt zu größeren Nachrichten, als es für einen Anwendungsfall streng notwendig wäre.
Wenn Entwickler APIs mit Schwerpunkt auf Minimalismus entwerfen, beziehen sie oft nur die Elemente ein, die spezifisch für ihren Anwendungsfall sind; zum Beispiel gibt es wenig Grund, die BSB-Nummer anzugeben, wenn sie sich im Vereinigten Königreich befinden, da alle Agenten mit einem Sortcode identifiziert werden. Ähnlich gilt: Wenn ein Agent nur mit einem Sortencode identifiziert werden kann, warum sollte man dann einen Teil der Struktur einer ISO 20022-Nachricht einbauen, wenn der Elementname geändert werden kann? Das folgende Beispiel hebt dies hervor:
So würde ein UK-Sortencode und eine Kontonummer in einer XML-basierten ISO 20022-Instanz erscheinen:
</CdtrAcct>
<CdtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>GBDSC</Cd>
</ClrSysId>
<MmbId>080800</MmbId>
</ClrSysMmbId>
</FinInstnId>
</CdtrAgt>
<CdtrAcct>
<Id>
<Othr>
<Id>21325698</Id>
</Othr>
</Id>
</CdtrAcct>
Der Code "GBDSC" definiert, dass die Mitglieds-ID ein "UK Domestic Sort Code" ist; die ID/Other/ID enthält die Kontonummer.
Im Vergleich dazu würden die gleichen Daten über UK Open Banking APIs übertragen, die 'unter Verwendung der ISO 20022-Nachrichtenelemente und -komponenten, wo verfügbar' erstellt wurden. Beachten Sie die kleinere Größe, aber auch die Änderung von Elementnamen, Codes und Struktur:
"GläubigerKonto": {
"SchemeName": "UK. OBIE. SortCodeAccountNumber",
"Identifikation": "08080021325698"
}
Dieses Problem ist nicht auf Open Banking in Großbritannien beschränkt, sondern tritt branchenweit auf. Dabei werden auf ISO 20022 basierende APIs implementiert, ohne dass klare Richtlinien für bewährte Verfahren oder offizielle JSON-Schemas veröffentlicht werden. Das Risiko einer Fragmentierung des Ansatzes ist hoch, was zu Inkompatibilitäten zwischen den Implementierungen führen und dazu, dass einige der Vorteile, die durch die Standardisierung erzielt werden sollten, nicht realisiert werden. Die Branche hat dieses Risiko erkannt, und ISO 20022 hat einige Maßnahmen ergriffen, um es zu mindern:
- Die API SEG (Standards Evaluation Group) öffnet sich in einem neuen Tab und wurde eingerichtet, um API-Ressourcen zu registrieren, zu entwickeln und zu warten.
- ISO/TC 68/WG4 (Technisches Komitee 68/Arbeitsgruppe 4), die für die Verwaltung/Aktualisierung der Norm ISO 20022 zuständige Gruppe, hat untersucht, wie die Norm geändert werden kann, um die Einführung von JSON-basierten ISO-20022-Ressourcen zu formalisieren und eine Vorlage einzuführen, die Modellierern hilft, verschiedene Formate für die Veröffentlichung der Norm zu registrieren (d. h. JSON-basierte Ressourcen). JSON-Schema).
- Die ISO 20022 Technical Support Group (TSG) (öffnet in neuem Tab) plant, ihr Whitepaper zu Best Practices für JSON (siehe Fußzeile) zu aktualisieren und zu überarbeiten, um weitere Hinweise zur Modellierung von JSON zu geben.
Da sich die Finanzbranche weiterentwickelt, sind kontinuierliche Standardisierung und Interoperabilität entscheidend. Die Einführung von JSON-basierten Nachrichten ist ein wichtiger Faktor für Innovation, bringt aber auch potenzielle Fallstricke mit sich, der die Branche bewusst sein muss. Andernfalls besteht das Risiko, viele der herausfordernden Arbeiten zunichte zu machen, die zuvor gemacht wurden.
Mastercard ist aktiv an diesen Initiativen beteiligt und wird auch weiterhin mit der Branche zusammenarbeiten, um einen Rahmen zu schaffen, der die Einführung neuer Formate ermöglicht und gleichzeitig die für zukünftige Innovationen unerlässliche Standardisierung und Interoperabilität bewahrt.
