Die Architektur des SWIFT-Zahlungsnetzwerks

SWIFT (Society for Worldwide Interbank Financial Telecommunication) ist ein Messaging-System, das Banken auf der ganzen Welt für Finanztransaktionen mit Banken in anderen Ländern verwenden. Es hat seinen Hauptsitz in Belgien und identifiziert die sendende und die empfangende Bank über einen 8- bis 11-stelligen Identifikator, den sogenannten SWIFT-Code.

Der SWIFT-Code wurde um 1975 zunächst in einem eigenen Format entwickelt, 1994 wurde dann mit ISO 9362 ein internationaler Standard definiert. Danach wurde er noch zweimal überarbeitet; die heute verwendete Fassung stammt aus dem Jahr 2014. Das konkrete Format lässt sich auf der folgenden Seite des estnischen Fintech-Unternehmens Wise (früher TransferWise) ansehen:

https://wise.com/gb/swift-codes/bic-swift-code-checker

Die ersten 4 Zeichen stehen für die Bank. Die nächsten 2 für das Land. Die folgenden 2 für die Region. Und schließlich optional 3 Zeichen für die Filiale. Wenn der SWIFT-Code zum Beispiel SMCOGB2LXXX lautet, bezeichnet er die Filiale XXX der Bank SMCO in der Region 2L im Vereinigten Königreich (GB). Grundsätzlich wird er Banken zugeteilt, doch da der häufigste Anwendungsfall Überweisungen sind, erhalten und nutzen auch viele multinationale Großunternehmen mit häufigem grenzüberschreitendem Zahlungsverkehr SWIFT-Codes. Andersherum gesagt: Wer aus dem SWIFT-Zahlungsnetzwerk ausgeschlossen wird, erleidet erhebliche Einschränkungen im Finanzverkehr. Im Fall von Iran und Nordkorea ist der Zugang zu SWIFT selbstverständlich(?) nicht möglich.

Dieser Beitrag beschreibt die technische Struktur des SWIFT-Systems, wie sie von Alex Xu, dem Autor von System Design Interview (deutscher Titel sinngemäß: „Grundlagen des Entwurfs großer Systeme anhand fiktiver Bewerbungsgespräche“), erläutert wurde.

1. Es gibt die Bank als Partei, die Geld sendet oder empfängt, den Regional Processor (RP), der Anfragen von der Bank entgegennimmt und verarbeitet, sowie den Slice Processor (SP), der von RP Anfragen entgegennimmt und die zugehörigen Überweisungsdaten speichert. Der Einfachheit halber nehmen wir an, es gibt eine Bank/RP/SP auf Seite A und eine Bank/RP/SP auf Seite B.
2. Bank A sendet eine Überweisungsanfrage an RP A, um Geld an Bank B zu schicken. RP A validiert die Anfrage und leitet sie anschließend an SP A weiter. SP A speichert die Anfrage, sendet an RP A eine Antwort, dass die Anfrage verarbeitet wurde, und übermittelt gleichzeitig die Überweisungsanfrage an RP B.
3. Nach Erhalt der Antwort sendet RP A an Bank A eine Rückmeldung, dass die Überweisungsanfrage angenommen (ACK) oder abgelehnt (NAK) wurde. RP B, das die Anfrage von SP A erhalten hat, speichert die Nachricht vorübergehend zwischen, vergibt dann eine eindeutige Nummer (MON) für die Nachricht und leitet sie an SP B weiter.
4. SP B prüft die Gültigkeit von MON, führt die Autorisierung durch und sendet anschließend an RP B die Nachricht: „Sende das Geld an Bank B.“
5. RP B übermittelt die Nachricht an Bank B. Bank B nimmt sie entgegen, speichert sie, zahlt das Geld tatsächlich aus und meldet den Erfolg oder Misserfolg (UAK/UNK) an RP B zurück.
6. RP B erstellt einen Report über das Ergebnis der Überweisung und übermittelt ihn an SP B. SP B speichert ihn und sendet eine Kopie an SP A. SP A speichert diese dann ebenfalls.

Obwohl das System um 1975 entstand, enthält es bereits alle Elemente moderner event-driven Microservices. SP speichert Überweisungsanfragen und Ergebnis-Reports in Form von Nachrichten, und RP stellt unter Nutzung von SP den Service für die Anfragen der Banken bereit. RP übernimmt nur die Rolle, Überweisungsanfragen von Banken entgegenzunehmen oder eingehende Überweisungsanfragen aus seinem Zuständigkeitsbereich an die Bank in eben diesem Zuständigkeitsbereich weiterzuleiten. Dadurch werden letztlich alle überweisungsbezogenen Anfragen sowohl im sendenden als auch im empfangenden SP gespeichert, jeweils zusammen mit Anfrage und Verarbeitungsergebnis. Aus Sicht der Bank ist SP überhaupt nicht sichtbar.