IP/IP- und IPZip-Überweisungen

IP to IP (IPIP)

IP-zu-IP-Transfers bezeichnen einen Teil des Prozesses der Übertragung von Währungen oder Vermögenswerten, Verbindlichkeiten und Eigenkapitalpositionen aus Korrespondenzbankkonten bzw. von Daten zwischen verschiedenen Finanzinstituten oder Systemen unter Verwendung von Internet-Protokoll-Adressen (IP-Adressen). Im Kontext von Finanztransaktionen ist die IP-Adresse eine eindeutige numerische Kennung, die jedem mit dem Internet verbundenen Gerät zugewiesen wird und dazu dient, Informationen zwischen verschiedenen Systemen zu leiten. IP-zu-IP-Transfers im Bankwesen beruhen auf der direkten Kommunikation zweier Systeme über ihre jeweiligen IP-Adressen, um eine Finanztransaktion abzuwickeln. Zusätzlich kommen besondere Authentifizierungs- und Autorisierungsverfahren zum Einsatz, um die Integrität und Sicherheit der Informationen zu gewährleisten.

Es ist jedoch zu beachten, dass IP-zu-IP-Überweisungen im Bankwesen aus einer Reihe von Gründen, darunter Sicherheits-, Zuverlässigkeits- und Compliance-Bedenken, weder üblich noch empfehlenswert sind. Die folgenden Punkte geben hierzu einen Überblick:

1. Sicherheit: IP-zu-IP-Überweisungen können im Vergleich zu etablierten Banknetzwerken wie SWIFT oder ACH weniger sicher sein, da diese mehrere Sicherheits-, Verschlüsselungs- und Authentifizierungsebenen einsetzen. Die direkte Kommunikation zwischen zwei IP-Adressen kann sensible Informationen potenziellen Sicherheitsbedrohungen aussetzen, darunter Hacking, Phishing oder Man-in-the-Middle-Angriffe.
2. Zuverlässigkeit: Die Verwendung von IP-zu-IP-Überweisungen gewährleistet nicht die Zuverlässigkeit der Transaktion, da im Bankgewerbe keine allgemein anerkannten Standards oder Protokolle für IP-basierte Überweisungen bestehen. Dies kann zu Problemen bei der Transaktionsverarbeitung, der Nachverfolgung und dem Abgleich führen.
3. Compliance: Banken und Finanzinstitute unterliegen zahlreichen Vorschriften und Anforderungen, darunter den Richtlinien zur Geldwäschebekämpfung (AML) und zur Kundenidentifizierung (KYC). IP-zu-IP-Transfers erfüllen diese regulatorischen Anforderungen unter Umständen nicht, wodurch die beteiligten Parteien rechtlichen und finanziellen Risiken ausgesetzt sein können.

Anstelle von IP-zu-IP-Übertragungen bevorzugen Banken und Finanzinstitute etablierte Netzwerke wie SWIFT, RTGS oder ACH/Instant Payment sowie Nachrichtenstandards wie ISO 20022, um sichere, zuverlässige und regelkonforme Geldtransfers zwischen verschiedenen Instituten zu ermöglichen.

Die wesentlichen Unterschiede zwischen Kommunikationsservern und Hauptbuch-/Kontoservern in Banken

In der Bankentechnologie spielen Server eine entscheidende Rolle für den reibungslosen Ablauf von Finanztransaktionen und die Führung der Aufzeichnungen. Zwei Haupttypen von Servern, auf die Banken angewiesen sind, sind Kommunikationsserver und Hauptbuch- bzw. Kontoserver. Obwohl beide von wesentlicher Bedeutung sind, erfüllen sie unterschiedliche Zwecke und verarbeiten unterschiedliche Arten von Daten.

Kommunikationsserver

Kommunikationsserver bilden das Rückgrat des sicheren Datenaustauschs zwischen Banken und Finanzinstituten. Nachfolgend die wichtigsten Funktionen und Merkmale von Kommunikationsservern:

1. Sicherer Datenaustausch: Diese Server ermöglichen den sicheren Austausch von Daten und stellen sicher, dass sensible Finanzinformationen ohne Beeinträchtigung zwischen Instituten übermittelt werden können.
2. Protokolle und Standards: Sie nutzen standardisierte Protokolle wie SWIFT, SEPA oder ACH usw. für die Kommunikation zwischen Banken und gewährleisten so Einheitlichkeit und Zuverlässigkeit über verschiedene Plattformen hinweg.
3. Verschlüsselung und Authentifizierung: Zur Wahrung der Sicherheit setzen Kommunikationsserver fortschrittliche Verschlüsselungsverfahren und strenge Authentifizierungsprotokolle ein, die die Daten während der Übertragung schützen.
4. Transaktionsabwicklung: In erster Linie bearbeiten sie Transaktionsaufträge, Nachrichten und Anweisungen und fungieren als Vermittlungsstellen, die die für Transaktionen erforderlichen Informationen weiterleiten.
5. Keine Mittelbewegung: Diese Server bewegen keine Gelder und aktualisieren Kontostände nicht unmittelbar; sie ermöglichen lediglich die für solche Vorgänge erforderliche Kommunikation.

Ledger-/Kontoserver

Ledger-/Kontoserver hingegen sind die Verwahrer der Finanzdaten einer Bank. Ihre wesentlichen Merkmale sind:

1. Pflege der Finanzaufzeichnungen: Diese Server speichern und pflegen die zentralen Finanzaufzeichnungen der Bank und gewährleisten, dass jede Transaktion korrekt erfasst wird.
2. Transaktionserfassung: Sie erfassen sämtliche Transaktionen, einschließlich Soll- und Haben-Buchungen, und sind für die Aktualisierung und Aufbewahrung der aktuellen Kontostände zuständig.
3. Hauptbuchführung: Ledger-Server verwalten das Hauptbuch der Bank sowie die einzelnen Kundenkonten und vermitteln so ein vollständiges Bild der finanziellen Lage.
4. Datenintegrität: Die Sicherstellung der Konsistenz und Integrität der Daten ist unerlässlich, da diese Aufzeichnungen für eine zutreffende Finanzberichterstattung und die Einhaltung regulatorischer Vorgaben wesentlich sind.
5. Starke Sicherheitsmaßnahmen: Angesichts der Sensibilität der Daten setzen Ledger-Server in der Regel strengere Sicherheitsmaßnahmen ein, darunter zusätzliche Verschlüsselungsebenen und strikte Zugriffskontrollen.

Der Kommunikationsserver stößt Transaktionen an und unterstützt deren Abwicklung, der Ledger-Server hingegen erfasst und bildet diese Transaktionen nach ihrer Validierung letztlich in den Büchern der Bank ab.

In modernen Banksystemen sind diese Funktionen häufig integriert: Sichere bankinterne Kommunikationsprotokolle arbeiten mit Systemen zur Kontenführung zusammen. Diese Integration gewährleistet Aktualisierungen in Echtzeit und Konsistenz im gesamten Finanzsystem der Bank und erhöht so sowohl Effizienz als auch Sicherheit. Viele Banken nutzen eine Kombination aus lokal betriebenen und Cloud-basierten Servern, um Sicherheit, Compliance und Skalierbarkeit auszubalancieren.

Tatsächliche Übertragung von Vermögenswerten, Verbindlichkeiten und Eigenkapital: Übertragungen von Wertpapieren werden von Zentralverwahrern (CSDs) verbucht, die den rechtlichen Eigentumsnachweis führen; Kredite, Anlagegüter und andere Positionen gehen durch Abtretung oder Übertragungsvereinbarungen nach dem anwendbaren Recht über. Beides liegt außerhalb des Anwendungsbereichs der Kommunikationsprotokolle. Die Übertragung von Vermögenswerten und Eigenkapital wirkt sich zudem auf den Jahresabschluss der beteiligten Banken aus und verändert deren Verbindlichkeiten, Vermögenswerte und Eigenkapitalsalden. Die Berichterstattung an die zuständigen Aufsichtsbehörden und die erforderlichen Compliance-Aspekte übersteigen die Möglichkeiten der Datenübertragung durch die Protokolle und erfordern zusätzliche finanzielle und aufsichtsrechtliche Prozesse.

Im Kern sind Protokolle zwar unverzichtbar für den sicheren und effizienten Austausch von Informationen bei IPIP-Transaktionen, doch umfasst der gesamte Prozess weitere Systeme für die tatsächliche Bewegung von Währungen, Vermögenswerten, Verbindlichkeiten und Eigenkapitalpositionen, für deren Abwicklung, die rechtliche Erfassung und die Finanzberichterstattung, sodass die gesamte Transaktion im Einklang mit den aufsichtsrechtlichen Bankstandards ausgeführt wird.

IP-ZIP-Transfer

Sichere dateibasierte Übermittlung institutioneller Zahlungsanweisungen

Ein IP-ZIP-Transfer ist am besten als sichere, dateibasierte Methode zu verstehen, um strukturierte Zahlungsanweisungen und zugehörige Transaktionsdaten über ein Internet-Protokoll-Netzwerk unmittelbar zwischen authentifizierten institutionellen Systemen zu übermitteln.

Die Terminologie erfordert besondere Präzision.

Eine IP-ZIP-Übermittlung ist weder ein Clearingsystem noch ein Abwicklungssystem, noch ein Zahlungsweg oder ein eigenständiger Mechanismus zur Übertragung von Geldwerten. Das ZIP-Archiv ist ein Transportbehälter. Die IP-Verbindung ist der Kommunikationskanal. Die im Archiv enthaltenen Informationen stellen eine Anweisung, einen Datensatz oder eine Transaktionsnachricht dar.

Dementsprechend:

IP ZIP übermittelt Zahlungsinformationen und Zahlungsanweisungen. Für sich genommen wickelt es keine Gelder ab.

Konzeptionell ist dies mit der Unterscheidung vergleichbar, die für eine ISO-20022-Nachricht pacs.008 (FI-to-FI Customer Credit Transfer) gilt. Eine pacs.008 kann eine hochstrukturierte Überweisungsanweisung zwischen Kreditinstituten übermitteln; die Nachricht selbst darf jedoch nicht mit der endgültigen Bewegung und Abwicklung von Zentralbankgeld, Geschäftsbankengeld oder Salden auf Korrespondenzkonten verwechselt werden.

Dasselbe Prinzip gilt für eine IP-ZIP-Übertragung.

2. Die ZIP-Datei als sicherer Transaktionscontainer

Die ZIP-Komponente dient in erster Linie als Container- und Verpackungsmechanismus.

Anstatt einzelne Transaktionsbestandteile getrennt zu übermitteln, kann das auftraggebende Institut die maßgeblichen Dateien zu einem einzigen kontrollierten Paket zusammenstellen.

Je nach bilateral vereinbarter Spezifikation kann ein solches Paket Folgendes enthalten:

• strukturierte Zahlungsanweisungen;
• XML-Zahlungsnachrichten;
• ISO-20022-kompatible Datensätze;
• JSON-Transaktionsobjekte;
• CSV- oder Festformat-Transaktionsdatensätze;
• proprietäre Interbanken-Zahlungsdateien;
• Angaben zu Schuldner und Gläubiger;
• Angaben zum Konto des Auftraggebers und des Begünstigten;
• Transaktionskennungen;
• Angaben zu Währung und Betrag;
• gewünschte Ausführungs- und Valutadaten;
• Anweisungen der Korrespondenzbank;
• Angaben zur zwischengeschalteten Bank;
• Verwendungszweck;
• Informationen zum Abwicklungsrouting;
• Compliance-Dokumentation;
• KYC- oder KYB-Nachweise;
• Angaben zur Mittelherkunft;
• Transaktionsmanifeste;
• digitale Signaturen;
• kryptografische Hashwerte;
• Zertifikate;
• Zeitstempel;
• Abstimmungsdateien und
• Kontrollsummen.

Das Archiv kann daher sowohl die primäre Zahlungsanweisung als auch die ergänzenden Informationen, die zur Authentifizierung, Validierung, Verarbeitung und Abstimmung dieser Anweisung erforderlich sind, enthalten.

Die Komprimierung ist technisch von untergeordneter Bedeutung. Hauptzweck sind die kontrollierte Bündelung und Übermittlung.

Ein ZIP-Archiv darf daher niemals als Nachweis dafür betrachtet werden, dass die im Archiv dargestellten Mittel bestehen, verfügbar, unbelastet oder abgewickelt sind.

3. Strukturierte Zahlungsanweisung

Bei sachgerechter Ausgestaltung kann die in einem IP-ZIP-Paket enthaltene Zahlungsanweisung eine Funktion erfüllen, die der herkömmlicher strukturierter Finanznachrichten entspricht.

Beispielsweise könnte ein Institut eine XML-Anweisung übermitteln, die Felder enthält, die den Angaben entsprechen, die üblicherweise in einer ISO 20022-Nachricht pacs.008 enthalten sind, darunter:

• Nachrichtenidentifikation;
• Datum und Uhrzeit der Erstellung;
• Anzahl der Transaktionen;
• Abwicklungsinformationen;
• weisungserteilende Stelle;
• beauftragte Bank (instructed agent);
• Schuldner;
• Konto des Zahlungspflichtigen;
• Zahlungsdienstleister des Zahlers (Debtor Agent);
• Beauftragte Bank des Gläubigers;
• Gläubiger;
• Gläubigerkonto;
• angewiesener Betrag;
• Währung;
• Kostenträger;
• Zahlungsidentifikation;
• End-to-End-Identifikation; und
• Verwendungszweck.

Entscheidend ist, dass die Datenstruktur den Abwicklungsmechanismus nicht bestimmt.

Eine technisch gültige Zahlungsanweisung kann vom empfangenden System entgegengenommen, authentifiziert und akzeptiert werden, während die zugehörige finanzielle Abwicklung noch aussteht.

Somit:

Eingegangener Auftrag ≠ eingegangene Mittel

Authentifizierte Anweisung ≠ abgewickelte Gelder

Erfolgreich importierte Datei ≠ endgültige Gutschrift der Mittel beim Begünstigten

Serverbestätigung ≠ Abwicklungsbestätigung

Diese Unterscheidung ist für die Behandlung alternativer Übertragungsmethoden durch IFB grundlegend.

4. Übertragungsprotokolle

Übermittlungen institutioneller IP-ZIP-Dateien sollten ausschließlich in einer kontrollierten und authentifizierten Kommunikationsumgebung erfolgen.

Je nach bilateraler technischer Vereinbarung kann die Übermittlung über Technologien wie die folgenden erfolgen:

SFTP

Das Secure File Transfer Protocol über SSH bietet verschlüsselten Transport, Serverauthentifizierung und kontrollierte Benutzerauthentifizierung.

Für institutionelle Anbindungen sollte in der Regel die Public-Key-Authentifizierung einer reinen Passwortauthentifizierung vorgezogen werden.

FTPS

FTP kann mittels TLS geschützt werden, sofern dies aufgrund der Altinfrastruktur erforderlich ist, vorausgesetzt, es werden angemessene Zertifikatsprüfungen, Verschlüsselungsstandards und Zugangskontrollen implementiert.

HTTPS / REST API

Das Paket kann über einen authentifizierten HTTPS-Endpunkt oder eine API-Architektur unter Verwendung von TLS und geeigneter Authentifizierung auf Anwendungsebene übermittelt werden.

Mutual TLS

Für institutionelle Verbindungen mit höheren Sicherheitsanforderungen ermöglicht Mutual TLS (mTLS), dass sich beide Endpunkte gegenseitig mittels digitaler Zertifikate authentifizieren.

Dies bietet einen wesentlich stärkeren Schutz vor nicht autorisierten Endpunkten als eine einseitige Serverauthentifizierung allein.

VPN

Ein Site-to-Site-IPSec-VPN oder ein gleichwertiges VPN kann zwischen den beteiligten Instituten einen verschlüsselten privaten Tunnel einrichten, bevor die Übertragung auf Anwendungsebene erfolgt.

Dedizierte private Anbindung

Wo Transaktionsvolumen, Sicherheitsanforderungen oder institutionelle Risikoprofile dies rechtfertigen, kann eine dedizierte oder private Netzwerkanbindung die Übertragung über das öffentliche Internet ergänzen oder ersetzen.

Das genaue Protokoll muss vor der operativen Aktivierung bilateral vereinbart werden.

5. Endpunkt-Authentifizierung

Das empfangende Institut muss feststellen, dass die Übermittlung von dem Institut stammt, das zu vertreten sie vorgibt.

Zu den einschlägigen Kontrollen können gehören:

• institutionelle digitale Zertifikate;
• öffentliche und private SSH-Schlüsselpaare;
• gegenseitige TLS-Zertifikate (Mutual TLS);
• API-Zugangsdaten;
• IP-Allowlisting;
• VPN-Authentifizierung;
• Hardware-Sicherheitsmodule;
• Certificate Pinning, sofern angebracht;
• Multi-Faktor-Authentifizierung für administrative Zugriffe;
• kontrollierte Servicekonten;
• rollenbasierte Zugriffskontrollen und
• Trennung von Produktions- und Testumgebungen.

Eine IP-Adresse allein ist kein ausreichender Nachweis der institutionellen Identität.

Ebenso begründet der Besitz eines Endpunkts, eines Server-Logins, einer API-Zugangsberechtigung oder eines ZIP-Passworts kein Eigentum an den zugrunde liegenden Geldern.

6. Verschlüsselung

Die Vertraulichkeit sollte in der Regel auf mehr als einer Ebene sichergestellt werden.

Transportverschlüsselung

Der Kommunikationskanal sollte mit einem angemessen konfigurierten, zeitgemäßen Protokoll wie TLS oder SSH verschlüsselt werden.

Dies schützt Informationen während der Übertragung.

Verschlüsselung der Nutzdaten

Soweit erforderlich, kann zusätzlich das Transaktionspaket selbst verschlüsselt werden.

Dies schützt die Finanzinformationen unabhängig vom Übertragungskanal und kann das Risiko erheblich verringern, wenn Dateien vorübergehend gespeichert, über zwischengeschaltete Infrastruktur geleitet, archiviert oder asynchron verarbeitet werden.

Verschlüsselung ruhender Daten

Dateien, die auf ihre Verarbeitung warten, sollten in kontrollierten Speicherumgebungen mit angemessenen Zugriffsbeschränkungen und Verschlüsselung im Ruhezustand geschützt werden.

Verschlüsselung stellt jedoch Vertraulichkeit her. Sie begründet nicht die finanzielle Gültigkeit der Transaktion.

7. Kryptografische Integrität

Das empfangende Institut muss zudem in der Lage sein festzustellen, ob das übermittelte Paket nach seiner Erstellung verändert wurde.

Für das Paket oder die darin enthaltenen Dateien kann daher ein kryptografischer Hashwert erzeugt werden.

Zum Beispiel:

Ursprüngliches Transaktionspaket
→ kryptografischer Hashwert wird erzeugt
→ Paket wird übermittelt
→ empfangendes System berechnet den Hashwert unabhängig
→ berechneter Hashwert wird mit dem übermittelten oder signierten Hashwert verglichen

Eine Abweichung zeigt an, dass das empfangene Paket nicht kryptografisch identisch mit dem ursprünglich authentifizierten Paket ist.

Zur Integritätsprüfung können moderne kryptografische Hash-Algorithmen eingesetzt werden, etwa Verfahren der SHA-2- oder SHA-3-Familie, soweit für die jeweilige Implementierung geeignet.

8. Digitale Signaturen

Eine digitale Signatur erfüllt eine wesentlich andere Funktion als die Verschlüsselung.

Verschlüsselung schützt die Vertraulichkeit.

Hashing trägt zur Sicherstellung der Integrität bei.

Eine ordnungsgemäß implementierte digitale Signatur kann dazu beitragen, Folgendes nachzuweisen:

1. Authentizität – das Paket wurde mit dem entsprechenden privaten Schlüssel signiert;
2. Integrität – die signierten Daten wurden nachträglich nicht verändert; und
3. Zurechenbarkeit – die Signatur kann dem jeweiligen institutionellen Berechtigungsnachweis zugeordnet werden, vorbehaltlich der geltenden PKI- und Governance-Rahmenbedingungen.

Das empfangende Institut sollte die Signatur anhand des entsprechenden vertrauenswürdigen Zertifikats oder öffentlichen Schlüssels prüfen, bevor die Transaktionsanweisung in die Zahlungsverarbeitung eingeht.

Private Signaturschlüssel sollten angemessen geschützt werden, vorzugsweise durch eine institutionelle Schlüsselverwaltungsinfrastruktur und, soweit gerechtfertigt, durch Hardware-Sicherheitsmodule (Hardware Security Modules).

9. Schutz vor Wiedereinspielung und Duplizierung

Die Übermittlung von Finanzdateien erfordert Kontrollen, die verhindern, dass dieselbe gültige Anweisung mehrfach eingereicht wird.

Eine angemessen gestaltete Architektur sollte daher eindeutige Transaktionskennungen sowie geeignete Kontrollen vorsehen, wie beispielsweise:

• eindeutige Nachrichtenkennungen;
• eindeutige Transaktionskennungen;
• Zeitstempel;
• Sequenznummern;
• Dateikennungen;
• Erkennung doppelter Nachrichten;
• Idempotenzkontrollen;
• Register zum Bearbeitungsstatus; und
• Abgleich mit zuvor verarbeiteten Aufträgen.

Das empfangende Institut sollte doppelte Anweisungen gemäß dem vereinbarten Betriebsverfahren zurückweisen, in Quarantäne nehmen oder prüfen.

10. Dateivalidierung

Der erfolgreiche Empfang einer Datei sollte eine Validierung auslösen, nicht eine automatische Abwicklung.

In einer gesicherten Verarbeitungsumgebung kann das Paket mehreren aufeinanderfolgenden Kontrollen unterzogen werden:

Stufe 1 – Transportvalidierung

Bestätigung, dass das Paket über einen autorisierten Kanal eingegangen ist.

Stufe 2 – Endpunkt-Authentifizierung

Bestätigung des übermittelnden Systems und der institutionellen Legitimationsnachweise.

Stufe 3 – Kontrollen gegen Schadsoftware und zur Dateisicherheit

Prüfung des Archivs und seiner enthaltenen Dateien vor der Einspeisung in die Zahlungsverkehrsinfrastruktur.

Stufe 4 – Kryptografische Verifizierung

Validierung von Hashwerten, Signaturen und Zertifikaten.

Stufe 5 – Strukturelle Validierung

Bestätigung, dass die Dateien dem vereinbarten Schema, den Namenskonventionen, der Zeichenkodierung und der Datenspezifikation entsprechen.

Stufe 6 – Semantische Validierung

Bestätigung, dass die obligatorischen Zahlungsfelder vorhanden und in sich schlüssig sind.

Stufe 7 – Transaktionsvalidierung

Prüfung von Währung, Betrag, Konten, Routing-Informationen, Transaktionsreferenzen und Abwicklungsanweisungen.

Phase 8 – Compliance-Validierung

AML-, Sanktions-, KYC/KYB-, Transaktionsüberwachungs- und sonstige anwendbare Kontrollen.

Phase 9 – Validierung der Abwicklung

Bestätigung, dass tatsächlich ein Mechanismus besteht, über den der entsprechende Finanzwert abgewickelt werden kann.

Erst nach Abschluss dieser Kontrollen sollte ein Auftrag nach den jeweils geltenden Verfahren des empfangenden Instituts zur Ausführung gelangen.

11. Bestätigung ist keine Abwicklung

In einer IP-ZIP-Umgebung können mehrere technische Bestätigungen erzeugt werden.

Zum Beispiel:

ACK – Datei empfangen

Damit ist lediglich belegt, dass der empfangende Endpunkt das Paket erhalten hat.

ACK – Datei authentifiziert

Damit ist belegt, dass die Authentifizierungskontrollen erfolgreich abgeschlossen wurden.

ACK – Datei validiert

Damit ist festgestellt, dass das Paket die jeweils maßgebliche strukturelle oder technische Validierung bestanden hat.

ACK – Anweisung angenommen

Dies kann belegen, dass die Zahlungsanweisung in den Verarbeitungsablauf des empfangenden Instituts eingegangen ist.

Keiner dieser Zustände bedeutet zwingend:

ABGEWICKELT

Die Abwicklung erfordert ein gesondertes finanzielles Ereignis.

Die Unterscheidung ist vergleichbar mit der herkömmlichen Finanznachrichtenübermittlung, bei der die erfolgreiche Zustellung und Annahme einer Zahlungsnachricht von der endgültigen Abwicklung der zugrunde liegenden Geldverbindlichkeit unterschieden werden muss.

12. Abwicklung des zugrunde liegenden Geschäfts

Sobald eine IP-ZIP-Zahlungsanweisung authentifiziert, validiert, angenommen und autorisiert wurde, muss der zugrunde liegende Geldwert über eine geeignete Finanzinfrastruktur abgewickelt werden.

Je nach beteiligten Währungen, Instituten und Rechtsordnungen kann die Abwicklung erfolgen über:

• Korrespondenzbankgeschäft;
• Nostro-/Vostrokonten;
• Zentralbankkonten;
• RTGS-Infrastruktur;
• anerkannte Clearingsysteme;
• inländische Zahlungssysteme;
• Sofortzahlungsinfrastrukturen;
• Korrespondenz-Abwicklungsbanken; oder
• eine andere rechtlich und operativ anerkannte Abwicklungsvereinbarung.

14. Sicherheitsprinzip

IFB wendet auf alle alternativen Übertragungsmethoden eine grundlegende Unterscheidung an:

Eine sichere Übertragung belegt, dass Daten sicher übermittelt werden können. Sie belegt nicht, dass Geld abgewickelt werden kann.

• Verschlüsselung ist kein Nachweis über Finanzmittel.
• Eine digitale Signatur belegt keine Finanzmittel.
• Ein Serversaldo ist kein Nachweis über Finanzmittel.
• Eine Transaktionsdatei ist kein Nachweis über Finanzmittel.
• Die erfolgreiche Dateiverarbeitung belegt nicht das Vorhandensein von Mitteln.
• Eine technische Bestätigung ist kein Nachweis der Abwicklung.

Die entscheidende finanzielle Frage bleibt, ob das ursprüngliche Institut über verifizierte Liquidität und einen funktionsfähigen Abwicklungsweg verfügt, der den entsprechenden Geldwert über anerkannte Bankinfrastruktur liefern kann.

15. IFB-Akzeptanzrahmen

IFB kann die Übermittlung per IP-ZIP nur für genehmigte institutionelle Gegenparteien und akzeptierte Kunden in Betracht ziehen, und zwar nach zufriedenstellender technischer, rechtlicher und Compliance-Prüfung.

Bevor eine Produktivanbindung hergestellt wird, kann IFB den Nachweis folgender Punkte verlangen:

• das veranlassende Institut;
• institutionelle Befugnis zur Übermittlung der Transaktion;
• wirtschaftliche Eigentümer und Transaktionsparteien;
• Herkunft und Rechtmäßigkeit der Mittel;
• zugrunde liegender wirtschaftlicher Zweck;
• Sende- und Empfangsinfrastruktur;
• Eigentum an den Endpunkten;
• IP- und Netzwerkarchitektur;
• Authentifizierungsmethodik;
• Zertifikate und kryptografische Berechtigungsnachweise;
• Verschlüsselungsstandards;
• Dateiformat und Schema;
• Struktur der Zahlungsnachrichten;
• Methodik zur Identifizierung von Transaktionen;
• Bestätigungsprotokoll;
• Kontrollen gegen Duplikate und Wiedereinspielung (Replay);
• Ausnahmebehandlung;
• Abstimmungsverfahren;
• Korrespondenzbankbeziehungen;
• Abwicklungskonten;
• Liquiditätsregelungen; und
• der endgültige Abwicklungsweg.

Technische Interoperabilität allein reicht nicht aus.

IFB wertet die erfolgreiche Übermittlung eines IP-ZIP-Pakets nicht als Mittelerhalt. Die Transaktion ist finanziell erst dann abgeschlossen, wenn der entsprechende Gegenwert über die vereinbarte Bank- oder Abwicklungsinfrastruktur erfolgreich abgewickelt wurde und die Abwicklung unabhängig abgestimmt werden kann.

Grundprinzip

IP ZIP ist die gesicherte Übermittlung einer Anweisung. Die Abwicklung ist die Bewegung des entsprechenden Finanzwerts.

Die beiden Verfahren können Teil desselben Transaktionsablaufs sein, sind jedoch nicht dasselbe Ereignis.

In der Terminologie des institutionellen Bankgeschäfts:

Nachrichtenübermittlung → Authentifizierung → Validierung → Annahme → Ausführung → Abwicklung → Abstimmung

Erst mit dem Abschluss des maßgeblichen Abwicklungsprozesses steht fest, dass die Geldseite der Transaktion vollzogen ist.

Begriffe im Zusammenhang mit alternativen oder herkömmlichen Übertragungsmethoden sind im Kontext der Bankinfrastruktur auszulegen. Solche Begriffe können Kommunikationskanäle, interne Verarbeitungsmethoden oder historische Praktiken beschreiben, ersetzen jedoch nicht das Erfordernis regulierter Institute, anerkannter Zahlungssysteme und förmlicher Abwicklungsverfahren.

Jede Übertragung muss, unabhängig von der Bezeichnung, letztlich innerhalb des etablierten Finanzsystems verarbeitet, abgewickelt und abgestimmt werden.

Wenn Sie mehr darüber erfahren möchten, wie Sie Gelder oder Vermögenswerte auf Ihre Konten bei uns übertragen, wenden Sie sich bitte an Marie Mayer.