SRTP Clarification

Ein Beitrag von

Andreas Wegmann & AI friends

Veröffentlicht am

08.06.2026

Aktualisiert am

08.06.2026

Lesezeit

2 min

Das erste SEPA Request-To-Pay Scheme Rulebook wurde November 2020 veröffentlicht und wurde dann regelmäßig überarbeitet.

Am 13 Mai wurde nun ein Clarification Paper veröffentlicht mit dem Zweck als Leitfaden des European Payments Council (EPC) zu dienen, um eine einheitliche und fragmentierungsfreie Umsetzung des SRTP Rulebooks v4.0 zu gewährleisten.

Wesentliche Inhalte der SRTP Clarification

Das Dokument enthält detaillierte Klarstellungen zu folgenden spezifischen Themenbereichen des SEPA Request-to-Pay Rulebooks:
  • Zeitmodelle für Akzeptanz und Zahlung („Accept now/later & Pay now/later“): Wie mit Fristen zur Annahme der Zahlungsaufforderung und zur eigentlichen Zahlungsinitiierung umgegangen wird
  • Optionen des Zahlers: Die Bedingungen, unter denen ein Zahler (sofern vom Zahlungsempfänger autorisiert) einen abweichenden Zahlbetrag oder ein anderes Zahlungsdatum wählen kann.
  • Zahlungsgarantien: Der Umgang mit Anfragen für Zahlungsgarantien („Request for payment guarantee“), wobei der eigentliche Garantievertrag stets außerhalb des SRTP-Systems liegt.
  • URLs und Weiterleitungen: Die Handhabung von beigefügten Web-Links in der Nachricht sowie von „Return to merchant URLs“, die den Käufer nach der Transaktion automatisch auf die Webseite des Händlers zurückleiten.
  • Stornierungs- und Statusanfragen: Die geltenden Fristen für Stornierungen („Request for Cancellation“) oder Statusaktualisierungen. Diese können grundsätzlich nur bis zum Ablaufdatum (Expiry Date/Time) der jeweiligen SRTP-Nachricht gesendet werden.
  • Alternative Scheme-Modelle: Die Anwendbarkeit der Regelungen auf alternative, vereinfachte Architekturen wie beispielsweise das 3-Corner-Modell.
  • Unbekannte SRTP-Adressen: Zusätzliche Schritte und Redirect-Szenarien (Weiterleitungen) im E-Commerce oder am Point of Sale (POS), die greifen, wenn der Händler die genaue SRTP-Adresse des Zahlers vorab nicht kennt.
  • Währungsunabhängigkeit („Currency agnosticism“): SRTP-Nachrichten können in jeder offiziellen SEPA-Währung ausgestellt werden, sind jedoch pro individueller Nachricht stets auf exakt eine Währung beschränkt.
  • Gebühren und Verwendungszweck: Die Nutzung des optionalen Daten-Platzhalters für Gebühren (AT-S013) und die korrekte Einbindung von strukturierten oder unstrukturierten Überweisungsinformationen (Remittance Information) zur leichteren Zahlungszuordnung.
  • Enrolment und Activation (Registrierung & Aktivierung): Detaillierte Erläuterungen, Illustrationen und Umsetzungsrichtlinien für ISO-20022-Nachrichten (REDA) bezüglich der obligatorischen Registrierung beim jeweiligen Dienstleister und der gegenseitigen Aktivierung zwischen Sender und Empfänger.
  • Ratenzahlungen und Gutschriften: Die genaue Handhabung von Ratenzahlungsanfragen („Instalment payments“) sowie die Möglichkeit, Gutschriften über eine SRTP-Nachricht mit dem festgelegten Zahlbetrag von null abzuwickeln.
  • Zahlungsinitiierungsstatus: Die optionale Funktion zur Abfrage des aktuellen Status einer Zahlungsauslösung.
  • EPC Directory Service (EDS): Details zum zwingenden Beitrittsprozess (Adherence process), der verpflichtenden EDS-Registrierung und der fortlaufenden Pflege von Betriebs- und Erreichbarkeitsdaten, wie API-Endpunkten und Sicherheitszertifikatsdate.
  • SRTP-Systemoptionen: Eine Übersicht der wählbaren Scheme-Optionen (z. B. Anhänge, Ratenzahlung, Redirect), die die Teilnehmer unterstützen und zentral im EDS für andere sichtbar hinterlegen können.
  • Homologationsprozess (Zulassungsverfahren): Spezifische Erläuterungen zu den verschiedenen Zulassungsarten für Scheme-Antragsteller und technische Lösungsanbieter (Technical Solution Providers).

Schon ein flüchtiger Blick auf die SRTP Clarification genügt, um die Komplexität für die Umsetzung bei den kontoführenden Banken zu erfassen. Wenn Sie als Finanzinstitut Fragen zur SRTP Clarification haben, freuen wir uns auf Ihre Kontaktaufnahme.

Suchen Sie nach einer Lösung für den elektronischen Zahlungsverkehr?