pain.013/14 ISO 20022 Nachricht
Veröffentlicht am
05.09.2025
Aktualisiert am
10.09.2026
Lesezeit
3 min
Stand: 10. September 2026
Die pain.013 ist die ISO-20022-Nachricht CreditorPaymentActivationRequest, ihre Antwort die pain.014 (CreditorPaymentActivationRequestStatusReport). Mit ihnen fordert ein Zahlungsempfänger den Zahler zur Zahlung auf und erhält Rückmeldung, wie dieser darauf reagiert hat. Im Markt läuft das Verfahren unter dem Begriff Request to Pay.
Eine Aufforderung, keine Zahlung
Der entscheidende Punkt steht am Anfang, weil er in der Praxis immer wieder verwechselt wird: Die pain.013 bewegt kein Geld. Sie ist wertneutral. Sie enthält, wer wie viel bis wann von wem möchte, und sie enthält typischerweise einen Verwendungszweck und einen Bezug zur Rechnung – aber sie löst keine Buchung aus.
Die Entscheidung liegt beim Zahler. Stimmt er zu, beauftragt er anschließend eine Zahlung, in aller Regel eine Überweisung oder eine Echtzeitüberweisung. Das unterscheidet das Verfahren grundlegend von der Lastschrift, bei der der Empfänger einzieht und der Zahler vorab per Mandat zugestimmt hat.
| Merkmal | Zahlungsaufforderung (pain.013) | SEPA-Lastschrift | Überweisung |
|---|---|---|---|
| Wer stößt an | der Zahlungsempfänger | der Zahlungsempfänger | der Zahler |
| Wer entscheidet über die Zahlung | der Zahler, in jedem Einzelfall | der Zahler vorab, per Mandat | der Zahler |
| Mandat erforderlich | nein | ja | nein |
| Geld fließt durch die Nachricht | nein – sie ist wertneutral | ja | ja |
| Was danach passiert | der Zahler löst eine Überweisung aus | der Betrag wird eingezogen | die Zahlung ist beauftragt |
| Nachricht | pain.013 mit Antwort pain.014 | pain.008 beim Kunden, pacs.003 interbank | pain.001 beim Kunden, pacs.008 interbank |
Ablauf im SEPA-Verfahren
Im europäischen Verfahren SEPA Request-to-Pay stehen zwischen Empfänger und Zahler zwei Dienstleister – je einer auf beiden Seiten. Der Empfänger übergibt seine Aufforderung an seinen SRTP-Dienstleister, dieser prüft sie, ergänzt Routing-Angaben und leitet sie an den Dienstleister des Zahlers weiter, der sie dem Zahler vorlegt. Die Statusmeldung läuft denselben Weg zurück.
Zwei Eigenheiten des Verfahrens sind für die Umsetzung wichtiger als der Nachrichtenaufbau. Erstens: Die Rollen der Dienstleister sind nicht zwingend Banken – jeder zugelassene Teilnehmer kann sie ausfüllen. Zweitens: Der Austausch zwischen den Dienstleistern erfolgt nicht dateibasiert, sondern über Schnittstellen. Das EPC veröffentlicht dafür eigene API-Spezifikationen samt Sicherheitsrahmen; pain.013 und pain.014 liefern in diesem Aufbau das fachliche Datenmodell, nicht den Transportweg.
Stand des SEPA-Verfahrens
Maßgeblich ist derzeit die Fassung 4.0 des SRTP-Rulebooks, herausgegeben Ende 2024 und wirksam seit Oktober 2025. Das Verfahren wächst über feste Zulassungsfenster: Das EPC führt mehrmals jährlich Homologationswellen durch, in denen neue Teilnehmer aufgenommen werden. Für 2026 ist zudem vorgesehen, den EPC-Verzeichnisdienst für SRTP-Teilnehmer zu öffnen – ein praktischer Schritt, denn ohne belastbares Verzeichnis ist die Erreichbarkeit der Gegenseite das eigentliche Hindernis.
Damit ist auch die nüchterne Einordnung verbunden: Das Verfahren ist verfügbar und geregelt, die Verbreitung baut sich aber erst auf. Wer heute plant, sollte die Erreichbarkeit der Zahlerseite prüfen, bevor er Anwendungsfälle darauf stützt.
Verwendung außerhalb SEPA
Die beiden Nachrichten sind kein europäisches Konstrukt. Der US-Echtzeitdienst FedNow führt pain.013 als Request for Payment und pain.014 als zugehörige Antwort in seinem Nachrichtenkatalog; die Rolle ist dieselbe wie im SEPA-Raum. Auch andere Echtzeitsysteme setzen auf dieselbe Grundnachricht. Die Regelwerke unterscheiden sich, das fachliche Modell nicht – wer die Nachricht einmal verstanden hat, findet sich in mehreren Märkten zurecht.
Bedeutung für Banken und Zahlungsdienstleister
- Zwei Rollen, zwei Projekte. Aufforderungen zu versenden und Aufforderungen entgegenzunehmen sind getrennte Fähigkeiten. Die Zahlerseite ist die aufwendigere, weil die Aufforderung dem Kunden verständlich vorgelegt und seine Entscheidung sauber zurückgemeldet werden muss.
- Die Zahlung ist nicht Teil des Verfahrens. Zustimmung und Zahlungsauslösung müssen im eigenen System verknüpft werden, sonst entsteht eine offene Aufforderung ohne nachvollziehbaren Abschluss.
- Schnittstellen statt Dateien. Wer aus dem klassischen Dateiverkehr kommt, plant hier eine andere Art der Anbindung – mit Verfügbarkeitsanforderungen, die eher denen des Echtzeitzahlungsverkehrs gleichen.