OCT Inst erklärt: Implementierungsanforderungen für OCT Inst

OCT Inst erklärt (Teil 3 von 4): Implementierungsanforderungen für OCT Inst

Abstract

Die Implementierung von OCT Inst baut auf bestehenden SCT-Inst-Funktionalitäten auf und erweitert diese für grenzüberschreitende Zahlungen mit einem Euro- und einem Nicht-Euro-Leg. Die wichtigsten Anpassungen betreffen die Auswahl von Partnern und das Routing, Währungsumrechnung und Liquiditätssteuerung, erweiterte Zahlungsdaten sowie das Exception Handling. Der konkrete Umsetzungsumfang hängt davon ab, welche Rolle der PSP übernimmt und welche Zahlungskorridore abgedeckt werden sollen. Während der Euro-Leg eine durchgängige Echtzeitverarbeitung ermöglicht, hängt die End-to-End-Abwicklung weiterhin vom Nicht-Euro-Leg ab. Die Definition der eigenen Rolle, eine Gap-Analyse und die Bewertung geeigneter Partner bilden daher die Grundlage für die Implementierung von OCT Inst.

Implementierungsanforderungen

OCT Inst basiert auf dem europäischen SEPA Instant Credit Transfer (SCT Inst) Scheme und erweitert dessen Logik auf grenzüberschreitende Zahlungen, bei denen ein Zahlungsweg in Euro und der andere in einer anderen Währung abgewickelt wird. Zahlungsdienstleister (PSP) auf der Euro-Seite können dadurch weiterhin die bestehende SEPA-Echtzeit-Infrastruktur nutzen. Die Verbindung zu Nicht-Euro-Zahlungssystemen wird, sofern verfügbar, über Entry und Exit PSPs hergestellt.

Gleichzeitig behält das Scheme einige bekannte Merkmale des grenzüberschreitenden Zahlungsverkehrs bei, zum Beispiel die Flexibilität bilateraler Vereinbarungen. Innerhalb des Euro-Legs definiert das Scheme maximale Ausführungszeiten von wenigen Sekunden. Dadurch können grenzüberschreitende Zahlungen deutlich näher an die Geschwindigkeit von Inlandsüberweisungen heranrücken, anstatt mehrere Tage zu dauern (European Payments Council, Rulebook 2025). Die Gesamtgeschwindigkeit hängt jedoch weiterhin vom Nicht-Euro-Leg ab.

Für die Umsetzung müssen PSPs daher einige zentrale Anpassungen berücksichtigen. Die folgende Tabelle zeigt die wichtigsten Handlungsfelder.

Erforderliche Anpassungen nach Themenbereich

Zeitmodell und Verfügbarkeit

OCT Inst reduziert für den Euro-Leg die Abhängigkeit von Geschäftstagen, Cut-off-Zeiten und sich überschneidenden Zeitzonen. Für PSPs verschiebt sich der Fokus damit vom Management von Cut-off-Zeiten hin zu einer kontinuierlichen Verfügbarkeit. Gerade bei Zahlungskorridoren zwischen Europa und Südostasien oder zwischen Europa und den USA, bei denen die beteiligten Parteien bis zu zehn Stunden Zeitunterschied haben können, führen klassische grenzüberschreitende Zahlungen häufig zu Verzögerungen. Gründe dafür sind unter anderem die Verarbeitungszeiten im Korrespondenzbankgeschäft und die jeweiligen Batch-Verarbeitungsfenster.

Durch die 24/7/365-Echtzeitverarbeitung des Euro-Legs über Infrastrukturen wie RT1 und TIPS verbessert OCT Inst die Geschwindigkeit und Planbarkeit der Abwicklung deutlich. Grundlage dafür sind die bereits in unserem vorherigen Artikel [Link zu Teil 2] beschriebenen Zeitvorgaben. Einschränkungen können jedoch weiterhin auf dem Nicht-Euro-Leg entstehen, beispielsweise durch lokale Zahlungssysteme sowie durch Devisen- oder Liquiditätsregelungen (European Payments Council, Reason Code Guidance 2026).

Echtzeitvalidierungen sowie eine Infrastruktur, die eine kontinuierliche Verfügbarkeit und Verarbeitung ermöglicht, sind für Zahlungsdienstleister bereits bekannte Anforderungen aus der Verordnung (EU) 2024/886, besser bekannt als Instant Payments Regulation (EBA Clearing, 2025). In diesen Bereichen sind daher keine grundlegenden Änderungen erforderlich.

Anders als bei klassischen Korrespondenzbankketten schreibt OCT Inst keine lange Abfolge von Intermediärbanken vor. Stattdessen wird das Routing über festgelegte Entry und Exit PSPs organisiert, die die Infrastruktur des Euro-Legs mit externen Zahlungssystemen verbinden, wie bereits in unserem vorherigen Artikel beschrieben. Der Euro-Leg wird dabei über etablierte Instant-Payment-Infrastrukturen wie RT1 oder TIPS abgewickelt. Entry und Exit PSPs fungieren als Schnittstelle zwischen dem europäischen und dem außereuropäischen Zahlungsverkehr (European Payments Council, Reason Code Guidance 2026).

Die Routing-Entscheidungen sind innerhalb des OCT-Inst-Schemes nicht fest vorgegeben. Die Teilnehmer können stattdessen ihre bevorzugten Euro Leg Exit PSPs auswählen. Kriterien können dabei unter anderem die Abdeckung bestimmter Zahlungskorridore, Preise, Verarbeitungskapazitäten sowie die Anbindung an das jeweilige Ziel-Zahlungssystem sein. Dadurch können Transaktionen auf dem Nicht-Euro-Leg effizient und kostengünstig geroutet werden (European Payments Council, Rulebook 2025).

Rollen

Wie hoch der zusätzliche Aufwand für die Implementierung von OCT Inst neben SCT Inst ausfällt, hängt davon ab, welche Rolle ein PSP im Scheme übernimmt. Eine Umfrage des CSM Iberpay deutet darauf hin, dass der zusätzliche Aufwand gering ausfällt:

• Euro Leg-Based Payee’s PSP: 5–20 %
• Euro Leg-Based Payer’s PSP: 5 %
• Euro Leg Exit oder Entry PSP: 10 %

^{Quelle: Iberpay, 2025.}

Die wichtigsten Implementierungsaktivitäten betreffen dabei:

• Onboarding von Partnern
• Compliance-Frameworks
• Routing-Funktionalitäten und korridorspezifische Konfigurationen
• Ausnahmebehandlung
• Währungsumrechnung

Bei der Währungsumrechnung können beispielsweise folgende Anpassungen erforderlich sein:

• Berechnung von Wechselkursen in Echtzeit
• Management der Liquidität
• Berechnung von Spreads und Gebühren
• Integration in Treasury-Prozesse und -Systeme
• Management von Risiken

Daten und Attribute

Auch wenn OCT Inst auf dem Nachrichtenstandard ISO 20022 basiert, definieren die Cross-Border Payments and Reporting Plus (CBPR+) Guidelines gemeinsame Vorgaben für die Nutzung von ISO-20022-Nachrichten im internationalen Zahlungsverkehr über das SWIFT-Netzwerk (SWIFT, o. J.). Dadurch kann dieselbe Nachricht, beispielsweise pacs.008, unter SEPA und CBPR+ unterschiedlichen Feldvorgaben und Pflichtangaben unterliegen.

Gemäß den CBPR+-Richtlinien verlangt das OCT Inst die Einreichung zusätzlicher Daten. Dazu gehören unter anderem die Währung und Art der Konten von Zahler und Zahlungsempfänger sowie gegebenenfalls zugehörige Proxy- oder Alias-Informationen (European Payments Council, Webinar 2025). Banken müssen daher prüfen, welche Attribute verpflichtend sind und welche zusätzlichen Daten von anderen beteiligten Akteuren, beispielsweise Clearing and Settlement Mechanisms (CSMs) oder anderen Zahlungsdienstleistern, benötigt werden.

Darüber hinaus sind detailliertere Informationen zum Zahler und Zahlungsempfänger sowie zu den jeweils zugehörigen Referenzparteien erforderlich. Gleiches gilt für die PSPs beziehungsweise Finanzinstitute von Zahler und Zahlungsempfänger, den Euro Leg Entry oder Exit PSP sowie mögliche zwischengeschaltete PSPs oder Finanzinstitute (European Payments Council, Webinar 2025).

Auch wenn viele Attribute bereits aus SCT Inst bekannt sind, müssen Finanzinstitute ihre Systeme an einigen Stellen anpassen. So müssen beispielsweise Transaktionsgebühren getrennt vom gutgeschriebenen beziehungsweise belasteten Transaktionsbetrag verbucht werden (European Payments Council, Rulebook 2025). Diese Änderungen und Implementierungen erfordern, dass Institute Abhängigkeiten zwischen ihren Systemen überprüfen, den Automatisierungsgrad erhöhen, entsprechende Tests durchführen und die beteiligten Mitarbeitenden schulen.

Exception Handling

Exception Handling ist erforderlich, wenn ein Teilnehmer innerhalb der Zahlungskette eine Transaktion nicht verarbeiten kann oder wenn der Zahler beziehungsweise dessen PSP einen Recall anfordert. Für diese Fälle gelten zusätzliche Anforderungen.

Zu den wichtigsten Anforderungen gehören:

• Je nach Grund, Empfänger der Nachricht und Zielland muss der passende OCT-Inst-Reason-Code für R-Transaktionen verwendet werden. Aus Datenschutzgründen sind einige Codes in bestimmten SEPA-Ländern nicht zulässig.
• Antworten auf Returns müssen unverzüglich übermittelt werden.
• Recall-Anfragen müssen innerhalb von 15 SEPA-Bankarbeitstagen beantwortet werden.
• Ein Inquiry muss sich auf eine OCT-Inst-Transaktion beziehen, deren tatsächliches oder angegebenes Belastungsdatum innerhalb der vergangenen 13 Monate liegt. Inquiries müssen innerhalb von 15 SEPA-Bankarbeitstagen beantwortet werden.

^{Quelle: European Payments Council, Reason Code Guidance 2026.}

Empfehlungen

Für die Implementierung können Institute folgende Schritte berücksichtigen:

1. Festlegen, welche Rolle das Institut innerhalb des OCT-Inst-Schemes übernehmen möchte.
2. Einen Zeitplan für die Implementierung aufstellen.
3. Eine Gap-Analyse auf Basis der bestehenden SCT-Inst-Landschaft durchführen.
4. Geeignete Partner und Zahlungskorridore bewerten und auswählen.

Der Implementierungszeitraum beträgt in der Regel sechs bis zwölf Monate, abhängig von der Größe der Institution, den verfügbaren Kapazitäten, der angestrebten Rolle und der bestehenden SCT Inst Landschaft (Iberpay, 2025, und Hathiramani, 2026).

Fazit

Für Zahlungsdienstleister, die SCT Inst bereits implementiert haben, ist die Einführung von OCT Inst eher eine Erweiterung der bestehenden Instant-Payment-Funktionalitäten als ein kompletter Neuaufbau. Die bestehende SCT-Inst-Infrastruktur weiterzuverwenden, ist dabei allerdings nur ein Teil der Umsetzung. Welche zusätzlichen Anforderungen entstehen, hängt vor allem von der gewählten Rolle des PSP, den beteiligten Partnern und den bedienten Zahlungskorridoren ab.

Routing, Währungsumrechnung und Liquiditätsmanagement, zusätzliche Zahlungsdaten sowie ein klar geregeltes Exception Handling müssen über den Euro- und Nicht-Euro-Leg hinweg zusammenspielen. Während der Euro-Leg eine durchgehend verfügbare Basis bietet, hängt die End-to-End-Abwicklung weiterhin von den Möglichkeiten und Rahmenbedingungen des Nicht-Euro-Legs ab. Eine erfolgreiche Implementierung erfordert daher sowohl technische Anpassungen als auch klar definierte operative Verantwortlichkeiten entlang der gesamten Zahlungskette.

Vor der Implementierung sollten Institute außerdem die Use Cases und Anforderungen ihrer Kunden genau betrachten. Sie bilden die Grundlage dafür, das passende Modell, die Routing-Logik und die Prioritäten für die Umsetzung festzulegen (Fannin, 2026).