SWIFT

SWIFT-Überweisungen und Kommunikation mit MT- und MX-Nachrichten

SWIFT (Society for Worldwide Interbank Financial Telecommunication) ist ein gesichertes Nachrichtennetzwerk, über das Finanzinstitute wie Banken standardisierte Nachrichten zu Finanztransaktionen, etwa Zahlungsanweisungen und Bestätigungen, senden und empfangen können. SWIFT führt keine Konten und überträgt keine Gelder; es stellt lediglich eine sichere und zuverlässige Plattform für den Informationsaustausch bereit.

Reguläre SWIFT-Überweisungen verwenden eine Reihe standardisierter Nachrichtentypen, die als MT-Nachrichten (Message Type) bezeichnet werden. Diese Nachrichten haben vordefinierte Formate und Felder, sodass Finanzinstitute die darin enthaltenen Informationen leicht verstehen und verarbeiten können.

MX-Nachrichten (ISO 20022) sind ein neuerer Standard für Finanznachrichten auf Grundlage von XML (eXtensible Markup Language). Sie bieten ein reichhaltigeres und strukturierteres Format, das einen erweiterten Datenaustausch und eine verbesserte durchgängige Verarbeitung ermöglicht. MX-Nachrichten ersetzen im SWIFT-Netzwerk schrittweise MT-Nachrichten, mit dem Ziel, bessere Interoperabilität und Datenverarbeitungsmöglichkeiten zu bieten.

Obwohl herkömmliche SWIFT-Überweisungen seit Jahrzehnten das Rückgrat des internationalen Zahlungsverkehrs bilden, weisen sie einige Einschränkungen auf, darunter begrenzte Transparenz, langsamere Bearbeitungszeiten und unstrukturierte Daten.

Swift 103+ STP (Straight Through Processing)

Swift 103+ STP war das frühere MT-Format, das für die durchgängige Verarbeitung (Straight Through Processing, STP) optimiert war; seit dem Ende der Koexistenzphase wird seine Funktion von der STP-Nutzungsrichtlinie für pacs.008 übernommen. STP ermöglicht es, den gesamten Zahlungsvorgang von der Auslösung bis zur endgültigen Abwicklung ohne manuelle Eingriffe elektronisch durchzuführen.

Zusätzliche Merkmale:

1. Standardisiertes Format: Es erfordert die strikte Einhaltung eines standardisierten Formats, wodurch Fehler und Verzögerungen reduziert werden.
2. Automatisierte Verarbeitung: Transaktionen werden automatisch verarbeitet, was eine schnellere und effizientere Abwicklung gewährleistet.
3. Geringerer manueller Eingriff: Der Aufwand für manuelle Erfassung und Prüfung wird minimiert, wodurch das Risiko von Fehlern und Verzögerungen sinkt.
4. Schnellere Abwicklung: Transaktionen werden im Vergleich zu herkömmlichen Verfahren schneller abgewickelt.

Überlegungen zu STP:

1. Korrekte Dateneingabe: Die Daten müssen korrekt erfasst werden, um Verzögerungen oder Zurückweisungen zu vermeiden.
2. Einhaltung der Formatvorgaben: Banken müssen sicherstellen, dass die Formatvorgaben von 103+ STP strikt eingehalten werden.
3. Software und Systeme: Banken benötigen geeignete Software und Systeme, um Straight-Through-Processing (STP) wirksam umzusetzen

Es ist wesentlich, zwischen Nachrichtenübermittlung und Abwicklung zu unterscheiden. SWIFT übermittelt strukturierte Finanznachrichten zwischen Instituten, bewegt jedoch selbst weder Gelder noch führt es Salden. Eine SWIFT-Bestätigung, einschließlich einer pacs.008-Nachricht, ist nur dann gültig, wenn sie einer tatsächlichen Transaktion entspricht, die in den Banksystemen der beteiligten Institute verarbeitet und abgestimmt wurde.

Ein eigenständiges SWIFT-Dokument, ein Bildschirmfoto oder eine Nachricht, die ohne institutionelle Verifizierung vorgelegt wird, sollte nicht als Nachweis einer abgeschlossenen Abwicklung behandelt werden.

SWIFT-gpi-Überweisungen.

SWIFT gpi (Global Payments Innovation):

SWIFT gpi, 2017 eingeführt, ist eine Initiative, die die Einschränkungen herkömmlicher SWIFT-Überweisungen beheben und die Geschwindigkeit, Transparenz und Nachverfolgbarkeit grenzüberschreitender Zahlungen verbessern soll. SWIFT gpi nutzt die bestehenden Nachrichtenformate MT und MX, um Zahlungsdienste zu verbessern. Zu den wesentlichen Merkmalen von SWIFT gpi zählen:

• Schnellere Zahlungen: gpi vereinfacht Abläufe und etabliert engere Service-Level-Agreements (SLAs) zwischen Banken, was zu kürzeren Transaktionszeiten führt, häufig innerhalb von Minuten oder Sekunden.
• Zahlungsverfolgung: Der gpi Tracker ermöglicht die Echtzeitverfolgung von Transaktionen, verbessert die Transparenz und verringert manuelle Nachforschungen.
• Gebührentransparenz: Banken können ihren Kunden vorab Informationen über Transaktionsgebühren bereitstellen und so bessere Entscheidungen ermöglichen.
• Umfangreichere Daten: gpi unterstützt einen detaillierteren und strukturierteren Informationsaustausch, was den Abgleich und die Einhaltung regulatorischer Vorgaben erleichtert.

SWIFT gpi behebt die Einschränkungen herkömmlicher SWIFT-Überweisungen, indem es grenzüberschreitende Zahlungen durch durchgängige Nachverfolgung, schnellere Verarbeitung und umfangreichere Daten verbessert.

Zentrale Parameter für Teilnehmer ohne SWIFT gpi

Übermittelt ein Teilnehmer, der nicht an SWIFT gpi teilnimmt (z. B. eine Bank oder ein Finanzinstitut, das nicht unmittelbar bei gpi registriert ist), eine Zahlungsanweisung an eine gpi-Teilnehmerbank, kann die gpi-Bank diese in die erforderlichen SWIFT-Nachrichtenformate umwandeln (pacs.008 für Kundenüberweisungen, pacs.009 COV für Deckungszahlungen und pacs.009 für Überweisungen zwischen Finanzinstituten). Diese Umwandlung ermöglicht die Verarbeitung und Nachverfolgung innerhalb des gpi-Netzwerks, sofern die Anweisung ausreichende Daten zur Befüllung der Pflichtfelder enthält und die gpi-Regeln, etwa zur durchgängigen Nachverfolgbarkeit (End-to-End), eingehalten werden.

Teilnehmer, die nicht an gpi angeschlossen sind, übermitteln diese Parameter üblicherweise über inländische Zahlungsverkehrssysteme, APIs oder Altformate, und die gpi-Bank ergänzt die gpi-spezifischen Angaben (z. B. die Erzeugung einer UETR, falls keine mitgeliefert wurde; für Institute ohne gpi-Anbindung ist die Weitergabe optional). Die genauen Anforderungen können je nach Rechtsordnung, Währung und bilateralen Vereinbarungen variieren, die Kernparameter stammen jedoch aus den Leitlinien von CBPR+ (Cross-Border Payments and Reporting Plus) und den Standards von ISO 20022. Seit dem Ende der Koexistenzphase am 22. November 2025 werden grenzüberschreitende Zahlungsaufträge im Format ISO 20022 ausgetauscht; die nachstehenden Verweise auf Felder der MT-Nachrichten dienen lediglich der Orientierung.
1. Identifikation der Parteien (Angaben zu Zahler und Zahlungsempfänger)
Diese Angaben identifizieren den Auftraggeber und den Begünstigten und gewährleisten die Einhaltung der Anforderungen der FATF-Empfehlung 16 (Travel Rule).

• Zahlungspflichtiger/Auftraggeber: Vollständiger Name, strukturierte Adresse (Straße, Ort, Postleitzahl, Land) und Kontoidentifikation (z. B. IBAN oder Kontonummer). Im früheren MT103/MT202 COV entspricht dies Feld 50a; bei pacs.008/pacs.009 den Elementen <Dbtr> und <DbtrAcct>.
• Zahlungsempfänger/Begünstigter: Vollständiger Name, strukturierte Adresse und Kontoidentifikation. Entspricht dem Feld 59a der früheren MT 103/MT 202 COV; <Cdtr> und <CdtrAcct> in pacs.008/pacs.009.
• Abweichender Zahler/Zahlungsempfänger (Ultimate Debtor/Creditor, falls zutreffend): Sofern abweichend von den Hauptparteien, sind deren Angaben zur Erhöhung der Transparenz anzugeben (optional, aber empfohlen für das gpi-Tracking). Entspricht <UltmtDbtr>/<UltmtCdtr> in pacs.008/pacs.009.

Warum erforderlich: Ermöglicht ein korrektes Routing und aufsichtsrechtliche Prüfungen; unvollständige Angaben können zu Zurückweisungen oder Verzögerungen führen.

2. Angaben zu Agenten und Zahlungsweg
Bezeichnet die in die Kette eingebundenen Finanzinstitute.

• Debtor Agent: BIC (Bank Identifier Code) oder sonstige Kennung der sendenden Bank. Entspricht Feld 52a im bisherigen MT 103; <DbtrAgt> in pacs.008/pacs.009.
• Zahlungsempfänger-Bank (Creditor Agent): BIC der empfangenden Bank. Entspricht Feld 57a der früheren MT 103/MT 202 COV; <CdtrAgt> in pacs.008/pacs.009.
• Zwischenbanken (sofern bekannt): BICs aller Korrespondenzbanken (bis zu 3 Ebenen). Entspricht Feld 56a im früheren MT; <IntrmyAgt1-3> in pacs.008/pacs.009.
• Instructing/Instructed Agents: BICs des unmittelbaren Absenders bzw. Empfängers in der Kette. Optional, erleichtert jedoch die serielle Methode und die Cover-Methode.
• Vorherige beauftragende Institute (sofern zutreffend): Bei Ketten mit mehreren Zwischenstationen bis zu 3 vorangehende Institute.

Warum erforderlich: Gewährleistet die korrekte Weiterleitung über Intermediäre; für höhere Genauigkeit in pacs.009 COV sollte BICFI anstelle von Namen verwendet werden.

3. Transaktionsdetails
Zentrale finanzielle Elemente für die Abwicklung.

• Betrag und Währung: Interbanken-Abwicklungsbetrag und ISO-4217-Währungscode (z. B. USD, EUR). Entspricht Feld 32A der früheren MT 103/MT 202 COV; <IntrBkSttlmAmt> in pacs.008/pacs.009.
• Instructed Amount (sofern abweichend): Ursprünglicher Betrag vor Abzügen.
• Interbank Settlement Date: Valutadatum der Abwicklung. Entspricht einem Teil von Feld 32A im MT; <IntrBkSttlmDt> in pacs.008/pacs.009.
• Abwicklungsmethode: Angabe, ob über RTGS (CLRG), Cover (COVE) oder Agent (INDA/INGA). Kein direktes MT-Äquivalent, jedoch implizit enthalten.

Warum erforderlich: Legt die Wertübertragung fest; für alle Formate zwingend.

4. Referenz- und Nachverfolgungskennungen
Für die Rückverfolgbarkeit, insbesondere in gpi.

• Ende-zu-Ende-Identifikation: Eine Referenz, die die gesamte Kette verknüpft (z. B. Rechnungs- oder Transaktionskennung). <EndToEndId> in pacs.008/pacs.009.
• Instruction Identification: Referenz des Senders (im MT auf 16 Zeichen begrenzt). Entspricht Feld 20 im früheren MT; <InstrId> in pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): Eine UUID für die Nachverfolgung von Ende zu Ende. Sie ist in pacs.008/pacs.009 verpflichtend und in den früheren MT103/MT202 in Feld 121 anzugeben; liefert ein einreichender Kanal sie nicht, erzeugt die erste Swift-Bank in der Kette sie.
• Transaktionskennung: Zusätzliche interne Referenz.

Warum erforderlich: Ermöglicht die gpi-Nachverfolgung und Verknüpfung (z. B. pacs.008 mit pacs.009 COV); die UETR ist der Schlüssel für universelle Bestätigungen.

5. Zweck- und Serviceinformationen
Klassifiziert die Zahlungsart.

• Zweckcodes und Kategoriezweckcodes (Purpose/Category Purpose): ISO-Codes (z. B. SALA für Gehalt), die die Art der Transaktion angeben. In bestimmten Korridoren erforderlich; <Purp> und <CtgyPurp> in pacs.008.
• Service-Level-Code: Kennzeichnet den gpi-Service (z. B. G001 für eine gpi-Kundenüberweisung); Banken ohne gpi sollten gpi-spezifische Codes nur nach Vereinbarung angeben. Entspricht Feld 23E in der MT-Nachricht und <SvcLvl> in pacs.008/pacs.009.
• Local Instrument Code: Für bestimmte Verfahren (z. B. konzerninterne Übertragungen).

Warum erforderlich: Gewährleistet die Einhaltung aufsichtsrechtlicher Vorgaben und die vorrangige Verarbeitung; nach der ISO-Migration zunehmend verpflichtend.

6. Überweisung und zusätzliche Anweisungen

• Verwendungszweck: Unstrukturiert (bis zu 140 Zeichen) oder strukturiert (z. B. Rechnungsangaben). Entspricht Feld 70 des früheren MT 103; <RmtInf> in pacs.008/pacs.009.
• Anweisungen an Agenten: z. B. /REC/ für den Empfänger, /ACC/ für das Konto oder telefonische Anweisungen (PHOB). Entspricht Feld 72 der früheren MT-Nachricht; <InstrForNxtAgt>/<InstrForCdtrAgt> in pacs.008/pacs.009.
• Indikatoren für die Abwicklungszeit: Gewünschte Zeitangaben (z. B. CLSTm für die CLS-Zeit).

Warum erforderlich: Liefert Kontext und Bearbeitungshinweise; unerlässlich für Deckungsmethoden in pacs.009 COV.

7. Aufsichts- und Compliance-Daten

• Aufsichtsrechtliche Meldung: Codes oder Angaben (z. B. Steuer-ID, Meldekennzeichen wie CRED/DEB). Entspricht Feld 77B in MT-Nachrichten; <RgltryRptg> in pacs.008/pacs.009.
• Rückgabegrundcodes (sofern für Rückgaben anwendbar): z. B. AC04 für ein aufgelöstes Konto, in pacs.004 mit den ursprünglichen Nachrichten verknüpft.

Warum erforderlich: Erfüllt die AML/KYC- und Meldepflichten; in regulierten Zahlungskorridoren verpflichtend.

Als bewährte Verfahren sollten Teilnehmer, die nicht an gpi teilnehmen, ihre Daten so strukturieren, dass bei MT-zu-MX-Konvertierungen keine Kürzungen auftreten, und sich bei besonderen Anforderungen an die gpi-Mitgliedsbank wenden. Erfolgt die Zahlung im Wege von Deckungsverfahren, müssen die zugrunde liegenden Kundendaten in allen Nachrichten übereinstimmen (z. B. von pacs.008 zu pacs.009 COV).

Zahlungsnachrichten in SWIFT gpi

Im Rahmen von SWIFT gpi (Global Payments Innovation) gelten die ursprünglichen Zahlungsnachrichten (z. B. pacs.008 für Kundenüberweisungen oder pacs.009 COV für Deckungsüberweisungen) nach ihrem Versand als unveränderlich. Empfängerbanken können den Inhalt dieser Nachrichten nicht unmittelbar ändern, da SWIFT-Nachrichten so konzipiert sind, dass Integrität und Nachvollziehbarkeit entlang der gesamten Zahlungskette gewahrt bleiben. Änderungen, Korrekturen oder Stornierungen werden stattdessen über gesonderte Folgenachrichten, Statusaktualisierungen über den gpi Tracker oder spezielle Dienste wie gSRP (gpi Stop and Recall Payment) abgewickelt. Dadurch ist die durchgängige Rückverfolgbarkeit anhand der Unique End-to-End Transaction Reference (UETR) gewährleistet.

Empfangende Banken (typischerweise als Gläubigerbank oder Intermediär tätig) können jedoch auf Änderungsanfragen der absendenden Bank reagieren oder Maßnahmen einleiten, die faktisch zu Änderungen des Zahlungsergebnisses führen (z. B. Rücküberweisungen oder Sperren). Sie können unter bestimmten Bedingungen zudem Klarstellungen oder Änderungen von der absendenden Bank anfordern. Diese Prozesse unterliegen den Regelwerken von SWIFT, den Marktpraxisleitlinien (z. B. der Payments Market Practice Group – PMPG) und regulatorischen Anforderungen und räumen Automatisierung, Transparenz und Betrugsprävention Vorrang ein.

Voraussetzungen, unter denen empfangende Banken Änderungen verlangen oder ermöglichen können
Empfangende Banken können Änderungen verlangen (z. B. Berichtigungen von Angaben) oder Maßnahmen ergreifen, die einen Änderungsbedarf nahelegen, wenn die ursprüngliche Zahlung nicht wie angewiesen verarbeitet werden kann. Dies geschieht in der Regel über Anfragenachrichten (z. B. MT 195/199) oder Antworten auf von der sendenden Bank veranlasste Ersuchen. Zu den wesentlichen Voraussetzungen zählen:

• Fehler in den Zahlungsangaben: Bei Unrichtigkeiten wie einem fehlerhaften Empfängerkonto (z. B. aufgelöstes Konto – Code AC04), falscher Währung (Code CURR), fehlerhafter Leitwegangabe der Bank (Code AGNT) oder technischen Problemen (Code TECH) kann die empfangende Bank die Zahlung zurückhalten und den Auftraggeber auffordern, berichtigte Angaben zu übermitteln oder eine neue Zahlung zu veranlassen. Dies vermeidet eine endgültige Zurückweisung und ermöglicht zugleich eine Klärung.
• Zahlung kann nicht zugeordnet werden: Gemäß dem Code CUTA (Cancel Upon Unable to Apply) kann die empfangende Bank, wenn die Zahlung aufgrund von Abweichungen (z. B. Namens- oder Kontodiskrepanzen oder unzureichender Angaben) nicht gutgeschrieben werden kann, vom Absender Angaben zur Stornierung oder Änderung anfordern, um Abhilfe zu schaffen.
• Verdacht auf Betrug oder nicht autorisierte Transaktionen: Bei Betrug (Code FRAD) kann die empfangende Bank Auffälligkeiten selbstständig erkennen und ohne vorherige Anforderung des Absenders eine Rückführung der Gelder einleiten. Sie kann auf Rückrufersuchen des Absenders auch reagieren, indem sie die Gelder sperrt und eine Freistellung (Code INDM) verlangt, falls die Gelder bereits gutgeschrieben wurden, um das Risiko vor der Rückführung zu begrenzen.
• Doppelte oder ungerechtfertigte Zahlungen: Codes wie DUPL (doppelte Zahlung) oder UPAY (ungerechtfertigte Zahlung) ermöglichen es der empfangenden Bank, die Transaktion zu kennzeichnen und ihre Stornierung zu verlangen, wenn sie fehlerhaft oder ungerechtfertigt ist.
• Regulatorische oder Compliance-Probleme: Verstößt die Zahlung gegen lokale Gesetze, Sanktionen oder AML-Anforderungen (Code LEGL), kann die empfangende Bank sie zurückweisen oder zurückhalten und von der sendenden Bank zusätzliche Unterlagen oder Änderungen anfordern.
• Entscheidungen des Kunden oder Begünstigten: Lehnt der Begünstigte die Zahlung ab (Code CUST oder NOAS – keine Antwort des Begünstigten), kann die empfangende Bank sie zurückgeben und den Absender benachrichtigen, gegebenenfalls unter Anforderung einer Bestätigung von Änderungen.
• Ausstehende Klärungen: Bei offenen Fällen (Code PDCR), etwa bei ausstehender Belastungsermächtigung (RQDA) oder ausstehender Antwort des nächsten Agenten (PTNA), kann die empfangende Bank die Zahlung zurückhalten und weitere Weisungen oder Änderungen anfordern, um fortzufahren.

In allen Fällen müssen Anfragen für die Automatisierung strukturiert sein (z. B. unter Angabe der UETR, ursprünglicher Referenzen wie Feld 20/32A/50/59 sowie bestimmter Codes in Feld 79 der Nachrichten), um eine durchgängige automatisierte Verarbeitung (Straight-Through-Processing) zu unterstützen. Bilaterale Freistellungsvereinbarungen können erforderlich sein, wenn Gelder gutgeschrieben werden; die empfangende Bank ist nicht verpflichtet, Anfragen anzunehmen, muss jedoch dringende Anfragen (z. B. im Zusammenhang mit Betrug) vorrangig behandeln.

Beteiligte Prozesse

• Antwort auf vom Absender initiierte Rückrufe: Der Absender (Zahlungsdienstleister des Zahlers) initiiert einen Rückruf in der Regel über MT 192/292 (oder ISO-20022-Äquivalente wie camt.056) über den Dienst gSRP, der seriell oder direkt an die empfangende Bank gesendet wird. Die empfangende Bank muss den Eingang unverzüglich bestätigen und mit MT 196/296 (oder MT 199/299, sofern strukturiert) antworten, unter Verwendung von Codes wie CNCL (storniert), RJCR (mit Begründung abgelehnt) oder PDCR (ausstehend). Bei Annahme werden die Mittel über pacs.004 (Payment Return) zurückgeführt.
• Eigenständige Maßnahmen der empfangenden Banken: Wird intern ein Betrug festgestellt, kann die empfangende Bank die Gelder mittels pacs.004 mit strukturierten Angaben zurückführen und über den Tracker eine Echtzeit-Statusmeldung übermitteln.
• Änderungs-/Klärungsanfragen: Empfangende Banken verwenden Anfragenachrichten (z. B. MT 195/295), um Änderungen, etwa zusätzliche Angaben, anzufordern. Dies ist bei zurückgehaltenen Zahlungen üblich.
• Tracker-Integration: Alle Aktionen aktualisieren den gpi Tracker in Echtzeit; dieser ist über APIs oder eine grafische Benutzeroberfläche zugänglich und schafft Transparenz für alle Beteiligten. gpi-Mitglieder müssen die verbindlichen Regelwerke für gCCT (Customer Credit Transfer), gCOV (Cover) und gSRP einhalten.
• Einschränkungen und Erfolgsfaktoren: Änderungen sind nicht garantiert; der Erfolg hängt vom Zahlungsstadium (vor der Gutschrift einfacher), der Mitwirkung des Begünstigten und der Rechtsordnung ab. Wurde bereits gutgeschrieben, erfordert die Rückführung die Zustimmung des Begünstigten oder eine Haftungsfreistellung. Gesetzliche Vorschriften haben stets Vorrang vor Leitlinien.

Diese Verfahren gelten in erster Linie für gpi-Mitglieder; Banken, die nicht an gpi teilnehmen, können jedoch über Gateways teilnehmen. Aktuelle Einzelheiten entnehmen Sie bitte den offiziellen Regelwerken von SWIFT, da sich die Prozesse weiterentwickeln (z. B. mit der Migration auf ISO 20022).

Trennung von Nachrichtenübermittlung und Abwicklung bei SWIFT gpi

SWIFT gpi wickelt in erster Linie Zahlungsanweisungen und deren Nachverfolgung über Nachrichtenübermittlung ab (z. B. ISO-20022-Formate wie pacs.008 für Kundenüberweisungen, pacs.009 für Finanzinstitutsüberweisungen oder ältere MT103/MT202), die eigentliche Geldbewegung erfolgt jedoch gesondert auf der Abwicklungsebene. Die Abwicklung erfolgt typischerweise über Korrespondenzbankbeziehungen (Nostro-/Vostrokonten), bilaterale Verrechnung oder Clearing- und Abwicklungsmechanismen (CSMs) wie Echtzeit-Bruttoabwicklungssysteme (RTGS) (z. B. T2, ehemals TARGET2, in Europa, Fedwire in den USA oder CHAPS im Vereinigten Königreich). Der gpi Tracker bietet Echtzeit-Einblick in den Nachrichtenstatus, die Geldüberweisung selbst beruht jedoch auf diesen zugrunde liegenden Systemen.

Die Koexistenzphase für grenzüberschreitende Zahlungsaufträge endete am 22. November 2025: Zahlungsaufträge wie MT103 und MT202 wurden durch ISO 20022-(MX-)Nachrichten wie pacs.008 und pacs.009 ersetzt, während andere MT-Kategorien zu späteren Terminen eingestellt werden. Nachfolgend wird erläutert, wie Rückläufe und Freigaben von Sperren auf Konto-, Clearing- und Abwicklungsebene erfolgen.

Wie Gelder auf Konto-, Clearing- und Abwicklungsebene zurückgeführt werden
Rückführungen werden nach einer erfolgreichen Rückrufanforderung (über gSRP – gpi Stop and Recall Payment Service) oder nach eigenständiger Feststellung (z. B. bei Betrug oder Fehlern) veranlasst. Der gSRP verwendet camt.056 (Payment Cancellation Request) der sendenden Bank, beantwortet mit camt.029 (Resolution of Investigation). Nach Annahme erfolgt die Rückführung der Gelder durch eine neue Zahlungsanweisung, die den Zahlungsfluss umkehrt, das Konto der empfangenden Bank belastet und den Betrag entlang der Kette zurückbucht. Dies stellt keine Änderung der ursprünglichen Nachricht dar, sondern eine eigenständige Transaktion.

Wesentliche Abwicklungsverfahren und Rückgabeprozesse
Die Abwicklungsverfahren bestimmen, wie Rückgaben erfolgen:

• CLRG (Clearing über Marktinfrastruktur): Abwicklung über ein RTGS- oder CSM-System (z. B. über eine Zentralbank). Für Rücküberweisungen wird pacs.004 verwendet, um die Marktinfrastruktur anzuweisen, das Konto des empfangenden Agenten zu belasten und den Betrag dem Konto des vorherigen Agenten gutzuschreiben, häufig in Echtzeit oder am selben Tag.
• INGA (Instructing Agent Settles First): Der Absender stellt die Mittel vor der Nachrichtenübermittlung bereit. Rückläufe über pacs.004 belasten nach der Abwicklung das Konto des beauftragten Instituts.
• INDA (Instructed Agent Settles on Receipt): Der Empfänger wickelt bei Nachrichteneingang ab. Erfolgt keine Abwicklung, wird mittels pacs.002 abgelehnt (keine Geldbewegung); erfolgt die Abwicklung, wird mittels pacs.004 zurückgeführt.
• COVE (Deckungsmethode): Wird bei Großbetragszahlungen mit Deckungsüberweisung (pacs.009 COV) verwendet. Rückläufer folgen der umgekehrten Kette: pacs.004 vom Institut des Begünstigten über die zwischengeschalteten Institute zurück, wobei die Korrespondenzkonten entsprechend belastet beziehungsweise gutgeschrieben werden.

Schrittweises Rückgabeverfahren auf Abwicklungsebene

1. Einleitung und Annahme: Der Sender beantragt den Rückruf (z. B. mittels camt.056 mit UETR). Der Empfänger antwortet (camt.029) und akzeptiert, sofern die Mittel verfügbar sind bzw. dem Begünstigten noch nicht gutgeschrieben wurden (vor der Gutschrift einfacher). Wurden die Mittel bereits gutgeschrieben, kann die Zustimmung des Begünstigten oder eine Freistellungserklärung erforderlich sein.

2. Anweisung zur Rückführung der Mittel: Der Empfänger veranlasst eine pacs.004 (Payment Return) oder eine herkömmliche MT 103/MT 202 mit Rückgabecodes (z. B. RETN). Diese Nachricht enthält:

• Ursprüngliche Referenzen (UETR, End-to-End-ID, Instruction-ID).
• Vertauschte Rollen: Der ursprüngliche Gläubiger wird zum Schuldner; das ursprüngliche Institut des Schuldners (Debtor Agent) wird zum Gläubiger.
• Abwicklungsdetails: ursprünglicher Interbank-Abwicklungsbetrag/-Termin, Wechselkurs (sofern Fremdwährung beteiligt), Entgelte (sofern abgezogen).
• Rückgabegrundcode (z. B. AC04 für aufgelöstes Konto, FRAD für Betrug).
• Feld „Settlement Account“ (sofern in der ursprünglichen Nachricht enthalten) zur Angabe des Kontos für die Gutschrift.

3. Abwicklung der Zahlung:

• Die pacs.004 löst die Belastung des Nostro-/Vostrokontos der empfangenden Bank aus (geführt beim vorherigen Agenten oder MI).
• Die Gelder werden Schritt für Schritt entlang der Kette zurückgebucht, und zwar nach demselben Abwicklungsverfahren (z. B. RTGS-Überweisung in CLRG).
• Bei teilweiser Rückgabe ist „PART“ in den Zusatzinformationen mit dem anteiligen Betrag anzugeben.
• Der Tracker aktualisiert den Status (z. B. „Zurückgegeben“) in Echtzeit, einsehbar über API oder GUI.

4. Endgültige Gutschrift: Das Konto des ursprünglichen Auftraggebers wird gutgeschrieben, häufig abzüglich von Gebühren. Erfolgt die Abwicklung über ein CSM, ist die Abrechnung atomar; bei bilateralen Konstellationen kann ein Netting zum Tagesende erfolgen.

5. Benachrichtigungen nach der Rückgabe: camt.053/054 (Kontoauszug/Soll-Haben-Avis) verwenden, um die Buchungen im Hauptbuch zu bestätigen. Keine weitere pacs.004 für die „Rückgabe einer Rückgabe“: stattdessen Anfragen verwenden.
Rückgaben erfolgen nach Möglichkeit automatisiert, bei Compliance-Fragen oder wenn Gelder gesperrt sind, kann jedoch ein manueller Eingriff erforderlich sein. Eine Rückholung ist nicht garantiert; sie hängt vor allem davon ab, wie schnell der Rückruf versandt wird und ob die Gelder bereits gutgeschrieben wurden. Bei nicht abgewickelten Zahlungen (z. B. vor der Abwicklung zurückgewiesen) werden keine Gelder bewegt: stattdessen pacs.002 verwenden.

Wie zurückgehaltene Zahlungen auf Konto-, Clearing- und Abwicklungsebene freigegeben werden („Green-Light“)

Zurückhaltungen (Holds) entstehen, wenn eine Zahlung nicht unverzüglich verarbeitet werden kann (z. B. aufgrund von Fehlern, Compliance-Prüfungen oder ausstehender Klärung) und in einen Schwebezustand („pending“) ohne Abwicklung versetzt wird. Bis zur Klärung erfolgt weder eine Belastung noch eine Gutschrift. Der gpi Tracker zeigt Status wie „On Hold“ oder „Pending“ an (z. B. Code PDCR); die Klärung erfolgt mittels Anfragenachrichten (MT 195/199 oder camt.029).

Umstände, die zu Sperrungen führen

• Abweichungen (z. B. Abweichung zwischen Konto und Name – CUTA-Code).
• Regulatorische Prüfungen (z. B. Sanktionen – LEGL-Code).
• Warten auf Antwort des Begünstigten (Code NOAS) oder Belastungsermächtigung (RQDA).
• Offline-Zeiten oder Stapelverarbeitung bei der Bank des Begünstigten.

Freigabeprozess auf Abwicklungsebene
1. Hold-Benachrichtigung: Der Empfänger sendet eine pacs.002 (Statusmeldung) oder eine MT 199 mit Pending-Code und hält die Mittel auf einem Zwischen- bzw. Treuhandkonto zurück, sofern die Abwicklung nur teilweise erfolgt ist (z. B. bei Cover-Verfahren).
2. Klärung: Der Absender übermittelt Änderungen bzw. Klarstellungen (z. B. über eine MT 195-Antwort oder camt.029). Ist der Sachverhalt geklärt, gibt der Empfänger die Bearbeitung frei, indem er die ursprüngliche Anweisung verarbeitet.
3. Abwicklungsausführung:

• Die ursprüngliche pacs.008/pacs.009 wird aus der Sperre freigegeben.
• Die Mittel werden über das festgelegte Verfahren abgewickelt: Belastung des Kontos des Zahlers, Gutschrift auf dem Konto des Empfängers (z. B. über RTGS in CLRG), anschließend endgültige Gutschrift auf dem Konto des Begünstigten.
• Auf der Begünstigtenseite (von der empfangenden Bank zum Endkunden) kommt es häufig zu Verzögerungen, insbesondere in Märkten mit Kapitalverkehrskontrollen oder begrenzter Infrastruktur.
• Der Tracker wechselt auf „Gutgeschrieben“ bzw. „Abgeschlossen“, wobei pacs.002 (Payment Status Report) dies bestätigt.

4. Falls nicht freigegeben: Bei ungelöstem Sachverhalt (z. B. nach Ablauf der Frist) Rückgabe über pacs.004 wie oben beschrieben oder Zurückweisung mit pacs.002 (keine Abwicklung).

Die gpi-Regeln verlangen, wo möglich, eine Gutschrift am selben Tag; Swift berichtete 2018, dass nahezu 50 % der gpi-Zahlungen innerhalb von 30 Minuten und fast 100 % innerhalb von 24 Stunden gutgeschrieben wurden. Faktoren wie Kapitalverkehrskontrollen oder Betriebspausen der Banken können Zurückbehaltungen verlängern; gpi setzt jedoch auf Automatisierung, um diese so gering wie möglich zu halten.

SwiftNet Instant

SwiftNet Instant. Dies ist eine Echtzeit-Nachrichtenplattform mit geringer Latenz, die rund um die Uhr verfügbar ist und den sicheren Austausch von Sofortzahlungsströmen zwischen Clearing- und Abwicklungsstellen (Clearing and Settlement Mechanisms, CSMs) und deren Teilnehmern unterstützt.

Kunden können sich über ihre bestehende Swift-Anbindung und Sicherheitsinfrastruktur, einschließlich VPN-Boxen, Mietleitungen und Hardware-Sicherheitsmodulen, mit SwiftNet Instant verbinden. Die Integration in die IT-Umgebung der Bank erfolgt über das Alliance Gateway Instant (AGI).

Alle Beteiligten entlang der Sofortzahlungskette können AGI und die SwiftNet-Instant-Nachrichtenübermittlung nutzen. Anwendungsfälle sind die Zahlungsauslösung über einen Overlay-Service, die indirekte Kommunikation von Mitgliedern mit einem sponsernden Mitglied oder der Erhalt einer Zahlungsbestätigung durch ein Unternehmen.

SWIFT Instant verbindet sich mit nationalen Sofortzahlungssystemen und ermöglicht so die Transaktionsverarbeitung in Echtzeit, sowohl im Inland als auch grenzüberschreitend, auf Grundlage des Standards ISO 20022. Diese Systeme stehen für die fortlaufenden Bemühungen, die Zahlungsprozesse in der Finanzbranche zu modernisieren und zu vereinfachen.

SWIFT-Lastschrift

Das Lastschriftverfahren im SWIFT-System ist ein Zahlungsverfahren, das es Unternehmen und Privatpersonen ermöglicht, Gelder von Konten von Zahlungspflichtigen in mehreren Währungen und über Ländergrenzen hinweg einzuziehen. Anders als die SEPA-Lastschrift, die speziell für den SEPA-Raum konzipiert und auf Transaktionen in Euro beschränkt ist, hat die Lastschrift im SWIFT-System einen globalen Anwendungsbereich und unterstützt eine breite Palette von Währungen.

Die Einleitung einer Lastschrifttransaktion innerhalb des SWIFT-Systems umfasst in der Regel die folgenden Schritte:

1. Vereinbarung zwischen Gläubiger und Schuldner: Zwischen Gläubiger und Schuldner muss bereits eine Vereinbarung bestehen, die die Bedingungen für Lastschrifttransaktionen enthält. Diese Vereinbarung kann auch die Einrichtung eines Mandats oder einer Ermächtigung umfassen, die es dem Gläubiger erlaubt, Zahlungen vom Bankkonto des Schuldners einzuziehen.
2. Nachrichtenaustausch: Die Bank des Gläubigers initiiert die Lastschrift, indem sie eine SWIFT-Nachricht an die Bank des Schuldners sendet – in ISO 20022 eine pacs.003 (Kundenlastschrift) oder pacs.010 (Lastschrift zwischen Finanzinstituten), früher MT 104 bzw. MT 204. Diese Nachricht enthält die Einzelheiten der Transaktion, etwa Betrag, Währung, Kontoinformationen des Schuldners und alle weiteren erforderlichen Angaben.
3. Prüfung und Autorisierung: Die Bank des Zahlungspflichtigen prüft die Transaktionsdetails, kontrolliert die Verfügbarkeit der Mittel auf dem Konto des Zahlungspflichtigen und bestätigt die Autorisierung der Transaktion. Sind alle Voraussetzungen erfüllt, belastet die Bank des Zahlungspflichtigen den Betrag auf dem Konto des Zahlungspflichtigen.
4. Geldtransfer: Die Mittel werden zwischen der Bank des Schuldners und der Bank des Gläubigers über Korrespondenzkonten oder ein Clearing- und Abwicklungssystem verrechnet.
5. Bestätigung: Nach Eingang der Mittel sendet die Bank des Gläubigers dem Gläubiger eine Bestätigung und informiert ihn über die erfolgreiche Lastschrifttransaktion.

Die Voraussetzungen für die Einleitung einer Lastschrifttransaktion im SWIFT-System lauten wie folgt:

1. Bankkonten: Sowohl der Gläubiger als auch der Schuldner müssen Konten bei Finanzinstituten unterhalten, die dem SWIFT-Netzwerk angehören.
2. Vereinbarung und Ermächtigung: Zwischen Gläubiger und Schuldner muss eine bereits bestehende Vereinbarung samt Ermächtigung (Mandat) vorliegen, um Lastschriften zu ermöglichen.
3. SWIFT-Nachrichtenformate: Der Gläubiger und seine Bank müssen die jeweils geeigneten Nachrichtenformate verwenden: pain.008 zur Einreichung einer Lastschrift, pacs.003 oder pacs.010 zwischen den Banken.
4. Bankgebühren: Gläubiger und Schuldner sollten sich etwaiger Gebühren bewusst sein, die mit Lastschrifttransaktionen innerhalb des SWIFT-Systems verbunden sind, da diese je nach beteiligten Banken und Ländern unterschiedlich ausfallen können.

RMA im SWIFT-Interbanken-Nachrichtenverkehr

Im Bank- und Finanzwesen ist eine sichere und effiziente Kommunikation zwischen Banken unerlässlich. Hier spielt SWIFT (Society for Worldwide Interbank Financial Telecommunication) eine zentrale Rolle, über das der Großteil der internationalen Nachrichten zwischen Banken übermittelt wird. Eine entscheidende Komponente für die Sicherheit und Selektivität dieser Kommunikation ist die Relationship Management Application (RMA).

Was ist RMA?

Die Relationship Management Application (RMA) ist eine SWIFT-Softwareanwendung, mit der Finanzinstitute festlegen können, welche Gegenparteien ihnen SWIFT-Nachrichten senden dürfen, und die sicherstellt, dass die Kommunikation im SWIFT-Netzwerk auf authentifizierte Nutzer beschränkt ist. Die RMA ist eine grundlegende Sicherheitsebene im Management der Interbankenkommunikation, da sie nicht autorisierte Nachrichten herausfiltert und das Betrugsrisiko verringert.

Die Bedeutung der RMA

Für international tätige Banken wie IFB ist das RMA-Instrument unverzichtbar. Es stärkt nicht nur die Sicherheitsprotokolle, sondern gewährleistet auch die Einhaltung der globalen Bankenvorschriften. Indem Banken steuern, welche Institute ihnen Nachrichten senden dürfen, können sie unbefugte Informationsanfragen und Finanzanweisungen verhindern und so sowohl ihre eigenen Interessen als auch die ihrer Kunden schützen.

Funktionsweise von RMA

Das RMA-Verfahren umfasst mehrere wesentliche Schritte:

1. Aufbau von RMA-Beziehungen: Bevor zwei Banken über SWIFT Informationen austauschen können, müssen sie sich gegenseitig auf eine RMA verständigen. Diese Vereinbarung gleicht einem digitalen Handschlag und bringt Vertrauen und Einverständnis zur Kommunikation zum Ausdruck.
2. Austausch von Schlüsseln: Jede Bank sendet über die RMA-Anwendung eine RMA-Berechtigung, die von der Gegenpartei angenommen wird. RMA hat den früheren bilateralen Schlüsselaustausch (BKE) abgelöst; die Nachrichten selbst werden über die SWIFTNet-PKI (Public Key Infrastructure) authentifiziert.
3. Konfiguration der RMA-Einstellungen: Jede Bank nutzt das RMA-Tool, um Berechtigungen zu konfigurieren und festzulegen, welche Nachrichtentypen von der anderen Bank akzeptiert werden. Dies kann breit kategorisiert oder fein abgestimmt erfolgen und bestimmte Nachrichtentypen sowie Untergruppen umfassen.
4. Aktivierung und Überwachung: Sobald die RMA-Einstellungen konfiguriert und aktiviert sind, können Banken eingehende Nachrichten auf die Einhaltung der festgelegten Berechtigungen überwachen. RMA stellt zudem Werkzeuge bereit, um Berechtigungen zu ändern oder zu widerrufen, wenn geschäftliche Erfordernisse oder Sicherheitsbedenken dies verlangen.

Praktische Anwendungen

Für die IFB, die auf Anlage- und Vermögensverwaltung für vermögende Privatpersonen und Firmenkunden spezialisiert ist, bietet RMA mehrere Vorteile:

• Erhöhte Sicherheit: Durch die Kontrolle des Nachrichtenverkehrs kann IFB Kundentransaktionen und sensible Informationen gegen unbefugten Zugriff schützen.
• Operative Effizienz: Eine optimierte Kommunikation mit vertrauenswürdigen Stellen ermöglicht eine schnellere Bearbeitung legitimer Nachrichten und verbessert Reaktionszeiten und Kundenzufriedenheit.
• Einhaltung regulatorischer Vorgaben: RMA unterstützt die Einhaltung internationaler Bankenvorschriften, die eine strenge Kontrolle des Informationsaustauschs vorschreiben, um Finanzkriminalität wie Geldwäsche und Betrug zu verhindern.

RMA und MT799. Banken können eine MT799 verwenden, um eine RMA-Beziehung anzufragen oder abzustimmen, sofern der Kanal dies zulässt. Die RMA-Autorisierung selbst wird im RMA-System erteilt; eine MT799 allein aktiviert keine Berechtigung. Fehlt die für die MT799 erforderliche RMA-Autorisierung, kann sie nicht durch den direkten Versand einer MT799 umgangen werden. Die Einrichtung wird dann über die RMA-Kommunikationsfunktion des Relationship Management Portal von Swift, das der Abstimmung mit Gegenparteien vor dem Austausch von Autorisierungen dient, oder über einen anderen zulässigen Kanal vereinbart. „RMA per MT799“ kann daher die begleitende Bankkorrespondenz bezeichnen; die technische RMA-Autorisierung ist ein gesonderter Schritt.

Kurz gefasst

Für die IFB ist die wirksame Umsetzung von RMA nicht nur eine technische Anforderung, sondern ein strategischer Vorteil in ihrem globalen Geschäft. Sie unterstreicht das Bekenntnis der Bank zu Sicherheit und aufsichtsrechtlicher Konformität und steigert zugleich die Effizienz ihrer Kommunikationsnetze. Während sich das Umfeld der internationalen Finanzwirtschaft weiterentwickelt, bleiben Instrumente wie RMA unverzichtbar für Banken, die höchste Standards operativer Integrität und Kundenbetreuung wahren wollen.

RMAs bilden das Rückgrat einer sicheren und selektiven Kommunikation zwischen Banken und stellen sicher, dass jede über das SWIFT-Netzwerk ausgetauschte Nachricht höchsten Sicherheitsstandards genügt und vollständig authentifiziert ist. Für Banken wie IFB ist das Verständnis und die Verwaltung von RMAs entscheidend, um ihren Geschäftsbetrieb zu schützen und das Vertrauen ihrer weltweiten Partner zu gewinnen.

Swift Digital Blockchain Financial Instructions

Im September 2025 gab Swift bekannt, gemeinsam mit über 30 Finanzinstituten mit der Konzeption und Entwicklung eines gemeinsamen digitalen Hauptbuchs (Ledger) begonnen zu haben. Am 9. Juli 2026 erklärte Swift das Ledger für die erstmalige Nutzung bereit; 17 Banken bereiten Pilotversuche mit Live-Transaktionen tokenisierter Einlagen vor: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB und Wells Fargo. Die erste Anwendung wird sich darauf konzentrieren, Echtzeit-Anweisungen zwischen Banken im grenzüberschreitenden Verkehr rund um die Uhr zu ermöglichen – eine wesentliche Verbesserung der Grundlagen der internationalen Transaktionsabwicklung.

Der erste konzeptionelle Prototyp wurde mit Consensys entwickelt. Das Ledger ist als sicheres, unveränderliches Echtzeitregister von Finanzanweisungen zwischen Instituten konzipiert. Es soll Transaktionsnachrichten erfassen, sequenzieren und validieren und dabei operative sowie Compliance-Regeln mittels Smart Contracts durchsetzen. Interoperabilität ist ein zentrales Prinzip: Das Ledger wird mit bestehenden wie auch mit entstehenden Infrastrukturen verbunden sein und dabei die für Swift kennzeichnende Ausfallsicherheit, das Vertrauen und die Einhaltung regulatorischer Vorgaben wahren.

Javier Pérez-Tasso, Chief Executive von Swift, erläuterte:
„Die Verbindung eines gemeinsamen Hauptbuchs mit dem bestehenden Messaging, den APIs und ISO 20022 von Swift schafft ein noch leistungsfähigeres Konstrukt: eines, das Risiko-, Kontroll- und Compliance-Anforderungen von Anfang an in die Transaktionsabläufe einbettet und zugleich grenzüberschreitende Interbankenanweisungen in Echtzeit rund um die Uhr ermöglicht, mit demselben Vertrauen, derselben Sicherheit, Ausfallsicherheit, Skalierbarkeit und operativen Exzellenz, für die Swift bekannt ist. Dies entspricht dem Ansatz verantwortungsvoller Innovation, den wir stets verfolgt haben.“

Erweiterung der Infrastruktur

Das gemeinsame Hauptbuch ergänzt die bestehenden Zahlungsverkehrsinfrastrukturen von Swift; es ersetzt sie nicht. Es ist darauf ausgelegt, Orchestrierung und Interoperabilität auszubauen, damit Finanzinstitute Anweisungen schneller, mit größerer Planbarkeit und in wahrhaft globalem Maßstab austauschen können.

Auf der Sibos hob Pérez-Tasso diesen zweigleisigen Ansatz hervor:
„Finanzinfrastrukturen müssen unablässig auf die Grundlagen operativer Exzellenz, regulatorischer Compliance und Governance achten. Zugleich müssen sie sich auf die Zukunft vorbereiten. Bei Swift verfolgen wir den Ansatz, auf zwei parallelen Gleisen Innovationen voranzutreiben.“

Zusammenarbeit innerhalb der Branche

Finanzinstitute aus 16 Ländern waren von Beginn an an der Gestaltung von Konzeption, Governance und Entwicklungspfad des gemeinsamen Hauptbuchs beteiligt. Diese gemeinsame Anstrengung unterstreicht eine geteilte Erkenntnis: Der Ausbau der globalen Infrastruktur für Interbankenanweisungen erfordert Größe und Zusammenarbeit.

Ausblick

Das gemeinsame Hauptbuch ist die natürliche Weiterentwicklung der früheren Pilotprojekte von Swift mit digitalen Vermögenswerten und Teil eines umfassenderen Bekenntnisses zur Interoperabilität über öffentliche und private Netzwerke hinweg. Dadurch können regulierte tokenisierte Werte ebenso wie traditionelle Instrumente reibungslos zwischen den Systemen übertragen werden.

Pérez-Tasso fasste die Vision zusammen:
„Dies ist eine leistungsstarke Plattform für die Zukunft. Und sie kann in Zukunft noch transformativer sein.“

Häufig gestellte Fragen

Was ist das auf Blockchain basierende Shared Ledger von Swift?
Eine Blockchain-Infrastruktur, die ein gemeinsames Echtzeit-Protokoll von Finanzinstruktionen zwischen Instituten bereitstellt und eine kontinuierliche, regelkonforme grenzüberschreitende Abwicklung ermöglicht.

Für wen ist es gedacht?
Für Banken und Finanzinstitute, die schnellere und transparentere Zahlungsanweisungen bereitstellen und sich zugleich auf die digitale Zukunft vorbereiten müssen.

Welche Vorteile bietet das?

• Echtzeit-Transparenz und Abfolgesteuerung von Zahlungsanweisungen
• Automatisierte Compliance durch Smart Contracts
• Interoperabilität zwischen traditionellen und digitalen Netzwerken
• Sichere Abwicklung regulierter tokenisierter Wertströme

Wie fügt sich dies in die Plattform von Swift ein?
Es erweitert die bewährte Infrastruktur von Swift um digitale Instruktionsfunktionen und wahrt dabei Ausfallsicherheit, Sicherheit und Compliance.

Was ist der erste Anwendungsfall?
Interbankenzahlungsaufträge im grenzüberschreitenden Verkehr in Echtzeit und rund um die Uhr.

Wer ist beteiligt?
Über 30 Finanzinstitute aus 16 Ländern haben an der Konzeption mitgewirkt; 17 Banken erproben die ersten Live-Transaktionen im Pilotbetrieb.

Wann wird es verfügbar sein?
Swift hat das Ledger am 9. Juli 2026 für die erste Nutzung als bereit erklärt. Die Pilotbanken führen in einer kontrollierten Go-live-Phase erste Live-Transaktionen durch; die endgültige Abwicklung läuft weiterhin über bestehende Systeme. Funktionsumfang und Verfügbarkeit sollen anschließend ausgebaut werden.

Wenn Sie mehr darüber erfahren möchten, wie Gelder über das Korrespondenzbankensystem überwiesen werden, wenden Sie sich bitte an unseren Leiter Korrespondenzbankgeschäft, Herrn Amri Elarisse.