ISO 20022 und JSON: Standardisierung und Flexibilität von APIs im Gleichgewicht

Die zunehmende Verbreitung von ISO 20022 und die gestiegene Nachfrage nach APIs haben zu zahlreichen Innovationen in der Finanzbranche geführt. Allerdings können die umfangreichen Datenstandards der ISO 20022 mit der Einfachheit und dem Minimalismus kollidieren, die JSON, das in APIs de facto verwendete Datenformat, fördert. Dieses Problem birgt die Gefahr, dass die Branche nicht in der Lage ist, die Vorteile der ISO 20022 zu nutzen.

In diesem Artikel untersuchen wir die Probleme, mit denen Entwickler und die Branche konfrontiert sind, wenn sie versuchen, die Flexibilität und Einfachheit von JSON mit dem Datenreichtum von ISO 20022 in Einklang zu bringen. Wir werden uns auch die laufenden Bemühungen ansehen, die versuchen, dieses wichtige Problem anzugehen.

ISO 20022 ist ein globaler Standard für den Datenaustausch zwischen Finanzinstituten und umfasst die Bereiche Zahlungsverkehr, Devisenhandel, Karten, Handelsfinanzierung und Wertpapiere. Der Standard ist umfassend, strukturiert und flexibel und stellt damit einen großen Fortschritt gegenüber den bisherigen globalen Standards ISO 15022 (SWIFT MT-Format) und ISO 8583 (verwendet für Kartenzahlungen und Konto-zu-Konto-Zahlungen) dar.

In der gesamten Branche wurden konzertierte Anstrengungen unternommen, die Einführung von ISO 20022 voranzutreiben, da die Vorteile am deutlichsten werden, wenn es von allen angewendet wird. Das Tempo dieses Wandels hat sich beschleunigt, da immer mehr Initiativen umgestellt haben – so nutzen mittlerweile viele automatisierte Clearinghäuser (ACH) weltweit das neue Format für Zahlungen mit hohem und niedrigem Wert sowie das grenzüberschreitende Zahlungssystem von SWIFT. Seine Verwendung ist noch nicht allgegenwärtig, da einige Systeme insbesondere für Massenzahlungen weiterhin ältere Formate unterstützen. Bei lokalen Echtzeit-Zahlungssystemen ist die Verwendung von ISO 20022 jedoch weit verbreitet.

Der Anwendungsbereich der ISO 20022 konzentriert sich auf den Informationsaustausch, der Hauptnutzen ergibt sich jedoch daraus, dass Institutionen das Datenwörterbuch (wird in einem neuen Tab geöffnet) zur Unterstützung ihrer internen Datenmodelle verwenden und somit im Wesentlichen eine gemeinsame Sprache einführen. Dies bedeutet beispielsweise, dass die Attribute, die eine Partei ausmachen (Name, Adresse, Geburtsdatum und -ort usw.), konsistent sind, wenn die Partei ein Schuldner in einer grenzüberschreitenden Transaktion oder ein Kontoinhaber in einem Kontowechselantrag ist.

ISO 20022 ist als Standard formatunabhängig, aber spezifische Nachrichtenschemata werden offiziell nur als XSDs (XML Schema Definitions) veröffentlicht und sind im Nachrichtenkatalog verfügbar (öffnet in neuem Tab). Dies hat dazu geführt, dass XML das am weitesten verbreitete Format für den Austausch von ISO 20022-Nachrichten ist.

Mit zunehmender Nutzung von ISO 20022 steigt auch der Bedarf an neuen Anwendungsfällen und neuen Wegen des Datenaustauschs. Ein prominentes Beispiel hierfür sind APIs, die von Finanzinstituten für zahlreiche Anwendungen genutzt werden, etwa für den Zugriff auf Kontoinformationen, die Auslösung von Zahlungen, Open Banking oder die Integration interner Systeme.

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 Anwendungsfälle für Finanznachrichten weltweit, was bedeutet, dass jede Nachricht viele Elemente enthält. Während die Schlüsselelemente, die für die Durchführung eines bestimmten Geschäftsnachrichtenaustauschs, beispielsweise einer Überweisung, erforderlich sind, weitgehend konstant bleiben (Name des Schuldners, Name des Gläubigers, Betrag, Währung usw.), gibt es Unterschiede in der Art und Weise, wie diese Elemente verwendet werden. In lokalen Clearingstellen wird beispielsweise in Deutschland ein Schuldneragent (Bank des Schuldners) über einen BIC (Business Identifier Code) oder eine Bankleitzahl (BLZ – abgeleitet von der IBAN) definiert, in Australien hingegen über eine BSB-Nummer (Bank State Branch).

Um dies zu ermöglichen, sind ISO 20022-Nachrichten so strukturiert, dass entweder das eine oder das andere angegeben werden kann. Diese Flexibilität führt jedoch zu größeren Nachrichten, als für den jeweiligen Anwendungsfall unbedingt erforderlich wären.

Wenn Entwickler APIs entwerfen und dabei Wert auf Minimalismus legen, beschränken sie sich oft auf die für ihren Anwendungsfall spezifischen Elemente. Befinden sie sich beispielsweise im Vereinigten Königreich, gibt es wenig Grund, die BSB-Nummer anzugeben, da alle Agenten über einen Sort Code identifiziert werden. Wenn ein Agent nur anhand einer Sortiernummer identifiziert werden kann, warum sollte man dann Teile der Struktur einer ISO-20022-Nachricht übernehmen, wenn der Elementname geändert werden kann? Das folgende Beispiel verdeutlicht dies:

So würden eine britische Bankleitzahl und Kontonummer in einer XML-basierten ISO-20022-Instanz aussehen:

</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“ kennzeichnet, dass es sich bei der Mitglieds-ID um eine „britische inländische Sortierkennung“ handelt; die ID/Other/ID enthält die Kontonummer.

Im Vergleich dazu würden dieselben Daten über die britischen Open-Banking-APIs wie folgt übertragen, die „unter Verwendung der ISO-20022-Nachrichtenelemente und -Komponenten, wo verfügbar, entwickelt wurden“3. Beachten Sie die geringere Größe, aber auch die Änderung der Elementnamen, Codes und der Struktur:

"CreditorAccount": {
"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) wurde gegründet, um API-Ressourcen zu registrieren, zu entwickeln und zu pflegen.
• 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 ständig weiterentwickelt, sind die fortgesetzte Standardisierung und Interoperabilität von entscheidender Bedeutung. Die Einführung von JSON-basierten Messaging-Diensten ist ein wichtiger Innovationsfaktor, birgt aber auch potenzielle Fallstricke, derer sich die Branche bewusst sein muss. Andernfalls besteht die Gefahr, dass ein Großteil der bisher geleisteten anspruchsvollen Arbeit zunichtegemacht wird.

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.