pacs-Nachrichten erklärt

Diese Seite bietet eine detaillierte technische Referenz für die ISO 20022 pacs-Nachrichtenfamilie. Sie behandelt den vollständigen Zahlungslebenszyklus, die XML-Struktur, Abwicklungsmethoden, Begründungscodes, Parteiidentifikation, Überweisungsinformationen und End-to-End-Tracking.

Lebenszyklus einer Zahlung

Der vollständige pacs-Zahlungslebenszyklus umfasst sechs Phasen und mehrere Nachrichtentypen, die zusammenwirken.

Phase 1 — Initiierung. Die Zahlung entsteht im Kunde-Bank-Bereich (pain.001). Die Bank des Schuldners empfängt die Anweisung und überführt sie in den Interbankenbereich.

Phase 2 — Interbanken-Anweisung. Der Schuldner-Agent erstellt einen pacs.008 und sendet ihn an den nächsten Agenten in der Kette. Bei einem seriellen Ablauf wird der pacs.008 schrittweise über Intermediäre weitergeleitet. Bei einem Deckungsverfahren geht der pacs.008 direkt vom Schuldner-Agenten zum Gläubiger-Agenten, während ein separater pacs.009 die Finanzierungsseite über die Korrespondentenkette abwickelt.

Phase 3 — Statusberichte. Bei jedem Schritt kann der empfangende Agent einen pacs.002 zurücksenden, der die Annahme (ACCP/ACSP/ACSC), Ablehnung (RJCT) oder einen ausstehenden Status (PDNG) bestätigt. Bei CBPR+ ist der pacs.002 für jede Zahlungsstatuskommunikation obligatorisch.

Phase 4 — Verrechnung. Die Verrechnung erfolgt über ein Clearingsystem (CLRG), auf Korrespondenzkonten (INDA/INGA) oder über eine Deckungszahlung (COVE). Das Interbanken-Verrechnungsdatum und der Betrag bestimmen, wann und wie viel verrechnet wird.

Phase 5 — Gutschrift an den Begünstigten. Der Gläubiger-Agent schreibt dem Begünstigten den Betrag gut und kann eine Kundenbenachrichtigung senden.

Phase 6 — Ausnahmebehandlung. Wenn der Begünstigte nach der Verrechnung nicht gutgeschrieben werden kann, werden die Mittel über pacs.004 durch die Kette zurückgeführt. Wenn der Auftraggeber einen Fehler oder Betrug feststellt, wird pacs.007 durch die Kette weitergeleitet. Wenn der Status unbekannt ist, fragt pacs.028 den nächsten Agenten ab und die Antwort kommt über pacs.002 zurück.

Serielles Verfahren

Debtor Agent --(pacs.008)--> Intermediary Agent
Intermediary Agent --(pacs.002)--> Debtor Agent [status]
Intermediary Agent --(pacs.008)--> Creditor Agent
Creditor Agent --(pacs.002)--> Intermediary Agent [status]
Creditor Agent --> Creditor [credit notification]

Deckungsverfahren

Debtor Agent --(pacs.008)--> Creditor Agent [direct, with customer data]
Debtor Agent --(pacs.009)--> Cover Bank --(pacs.009)--> Creditor Agent [funding leg]

XML-Struktur von pacs.008

pacs.008 besteht aus zwei Hauptbausteinen: dem Gruppenkopf (GrpHdr) und den Überweisungstransaktionsinformationen (CdtTrfTxInf).

Gruppenkopf (GrpHdr)

Der Gruppenkopf erscheint genau einmal pro Nachricht und enthält:

• MsgId — Eindeutige Nachrichtenkennung, vergeben vom sendenden Agenten. Maximal 35 Zeichen, muss pro Absender eindeutig sein.
• CreDtTm — Erstellungszeitstempel im ISO-8601-Format.
• NbOfTxs — Anzahl der einzelnen Transaktionen in der Nachricht.
• SttlmInf — Verrechnungsinformationen einschließlich der Verrechnungsmethode (SttlmMtd) und optional des Clearingsystems und des Verrechnungskontos.
• IntrBkSttlmDt — Datum, an dem die Interbankenverrechnung stattfindet.
• PmtTpInf — Zahlungsartinformationen einschließlich Priorität, Servicelevel, lokales Instrument und Kategorie-Verwendungszweck.

Überweisungstransaktionsinformationen (CdtTrfTxInf)

Jede Transaktion enthält:

• PmtId — Zahlungskennungen: InstrId, EndToEndId, TxId und UETR.
• IntrBkSttlmAmt — Interbanken-Verrechnungsbetrag mit Währungscode.
• InstdAmt — Ursprünglich angewiesener Betrag (kann aufgrund von Devisenkursen vom Verrechnungsbetrag abweichen).
• ChrgBr — Gebührenträgercode (DEBT, CRED, SHAR oder SLEV).
• Dbtr / DbtrAcct / DbtrAgt — Name, Adresse, Identifikation, Konto und Agent des Schuldners.
• Cdtr / CdtrAcct / CdtrAgt — Name, Adresse, Identifikation, Konto und Agent des Gläubigers.
• IntrmyAgt1 / 2 / 3 — Bis zu drei Intermediär-Agenten in der Kette.
• RmtInf — Überweisungsinformationen, entweder unstrukturiert (Freitext) oder strukturiert (Dokumentreferenzen, Beträge, Daten).
• Purp — Strukturierter Verwendungszweckcode.
• RgltryRptg — Details der aufsichtsrechtlichen Meldung.

Zahlungskennungen

pacs-Nachrichten verwenden mehrere Kennungen, die verschiedene Rollen in der Zahlungskette erfüllen.

Zahlungskennungen und ihre Rollen

Kennung	Gesetzt von	Ändert sich in der Kette?
MsgId	Jedem sendenden Agenten	Ja — neu pro Nachricht
InstrId	Jedem anweisenden Agenten	Ja — kann sich pro Schritt ändern
EndToEndId	Auftraggeber (Schuldner)	Nein — darf nicht geändert werden
TxId	Erster anweisender Agent	Nein — darf nicht geändert werden
UETR	Schuldner-Agent	Nein — universelle Nachverfolgung

Verrechnungsmethoden

Das Element SttlmMtd definiert, wie die Interbankenverrechnung erfolgt.

• CLRG — Verrechnung über ein Clearingsystem wie TARGET2, EURO1 oder CHIPS. Am häufigsten für nationales und regionales Clearing.
• INDA — Verrechnung in den Büchern des beauftragten Agenten. Der Schuldner-Agent unterhält ein Nostro-Konto beim nächsten Agenten. Typisch für bilaterales Korrespondenzbanking.
• INGA — Verrechnung in den Büchern des anweisenden Agenten. Der beauftragte Agent unterhält ein Nostro-Konto beim sendenden Agenten. Seltener als INDA.
• COVE — Verrechnung über eine separate Deckungszahlung. Ein pacs.009 übernimmt die Finanzierungsseite, während der pacs.008 die Kundendaten direkt überträgt. Wird im grenzüberschreitenden Korrespondenzbanking eingesetzt.

Gebührenträgercodes

Das Element ChrgBr legt fest, wer die Zahlungsgebühren trägt.

• DEBT — Schuldner trägt alle Gebühren (MT103-Äquivalent: OUR). Der Gläubiger erhält den vollen Betrag.
• CRED — Gläubiger trägt alle Gebühren (MT103-Äquivalent: BEN). Die Gebühren werden vom Überweisungsbetrag abgezogen.
• SHAR — Gebühren werden geteilt (MT103-Äquivalent: SHA). Jede Partei zahlt die Gebühren ihres eigenen Agenten. Am häufigsten bei grenzüberschreitenden Zahlungen.
• SLEV — Gebühren folgen dem Servicelevel. Obligatorisch für SEPA. Keine Abzüge vom Überweisungsbetrag.

Feldzuordnung MT103 zu pacs.008

Wichtige Feldzuordnungen von MT103 zu pacs.008

MT103-Feld	MT103-Bezeichnung	pacs.008 XML-Pfad
20	Referenz des Absenders	GrpHdr/MsgId or PmtId/InstrId
23B	Bankoperationscode	PmtTpInf/SvcLvl
32A	Valutadatum / Betrag	IntrBkSttlmDt + IntrBkSttlmAmt
33B	Angewiesener Betrag	InstdAmt
50a	Auftraggeber	Dbtr + DbtrAcct
52a	Auftraggeberinstitut	DbtrAgt
57a	Kontoinstitut	CdtrAgt
59a	Begünstigter Kunde	Cdtr + CdtrAcct
70	Überweisungsinformationen	RmtInf/Ustrd or RmtInf/Strd
71A	Gebührendetails	ChrgBr (BEN→CRED, OUR→DEBT, SHA→SHAR)
72	Absender-an-Empfänger-Info	InstrForCdtrAgt / InstrForNxtAgt
N/A	UETR (Block 3, field 121)	PmtId/UETR

Status- und Grundcodes

pacs.002-Statuscodes

Transaktionsstatuscodes in pacs.002

Code	Bedeutung
ACCP	Akzeptiert — vorhergehende Prüfungen bestanden
ACSP	Akzeptiert — Verrechnung läuft
ACSC	Akzeptiert — Verrechnung abgeschlossen
RCVD	Empfangen — noch nicht verarbeitet
PDNG	Ausstehend — weitere Verarbeitung erforderlich
RJCT	Abgelehnt — mit Grundcode

Häufige Ablehnungs- und Rückgabegrundcodes

Häufig verwendete Ablehnungs- und Rückgabegrundcodes

Code	Name	Beschreibung
AC01	Falsche Kontonummer	Die Kontonummer ist ungültig oder existiert nicht
AC04	Geschlossenes Konto	Das Konto ist geschlossen
AC06	Gesperrtes Konto	Das Konto ist für Transaktionen gesperrt
AM04	Unzureichende Deckung	Unzureichende Deckung auf dem Schuldnerkonto
AM05	Dopplung	Doppelte Zahlung erkannt
BE04	Fehlende Gläubigeradresse	Die Adresse des Gläubigers fehlt oder ist unvollständig
CUST	Vom Kunden angefordert	Rückgabe oder Ablehnung vom Kunden angefordert
DUPL	Doppelte Zahlung	Doppelte Zahlung identifiziert
FOCR	Nach Stornierung	Aufgrund einer Stornierungsanforderung
FR01	Betrug	Betrugsverdacht
RC01	Falscher BIC	BIC ist falsch oder unbekannt
RR03	Fehlender Gläubigername/-adresse	Name oder Adressdaten des Gläubigers fehlen
TM01	Annahmeschluss	Die Annahmeschlusszeit ist überschritten

Postadressformat

Strukturierte Adresse

<PstlAdr>
  <StrtNm>High Street</StrtNm>
  <BldgNb>42</BldgNb>
  <PstCd>EC2V 8BX</PstCd>
  <TwnNm>London</TwnNm>
  <Ctry>GB</Ctry>
</PstlAdr>

Unstrukturierte Adresse (ab November 2026 für CBPR+ veraltet)

<PstlAdr>
  <AdrLine>42 High Street</AdrLine>
  <AdrLine>London EC2V 8BX</AdrLine>
  <Ctry>GB</Ctry>
</PstlAdr>

Wichtige Einschränkungen: StrtNm maximal 70 Zeichen (CBPR+), TwnNm maximal 35 Zeichen (CBPR+), Ctry im Format ISO 3166-1 Alpha-2, AdrLine maximal 70 Zeichen pro Zeile und maximal 7 Zeilen.

Parteienidentifikation

Parteien in pacs.008 unterstützen mehrere Identifikationsmethoden:

• BIC — Geschäftskennungscode gemäß ISO 9362. 8 oder 11 Zeichen (BBBBCCLL oder BBBBCCLLBBB). Verwendet in FinInstnId/BICFI für Agenten und OrgId/AnyBIC für Parteien.
• LEI — Kennung für juristische Personen gemäß ISO 17442. 20 alphanumerische Zeichen. Erscheint in OrgId/LEI für Parteien und FinInstnId/LEI für Agenten. Verbessert die Entitätszuordnung für aufsichtsrechtliche Meldungen.
• IBAN — Internationale Bankkontonummer gemäß ISO 13616. Verwendet in DbtrAcct/Id/IBAN und CdtrAcct/Id/IBAN.
• Organisationskennungen — Weitere schemabasierte Kennungen (Steuernummer, DUNS, Kundennummer) über OrgId/Othr mit einem Schemanamecode.
• Private Kennungen — Für natürliche Personen: Geburtsdatum und -ort, Reisepass (CCPT), Personalausweis (NIDN) oder Führerschein (DRLC) über PrvtId.

Überweisungsinformationen

Überweisungsdaten in pacs.008 verwenden das Element RmtInf mit zwei Formen:

Unstrukturiert — Freitext bis zu 140 Zeichen pro Vorkommen. Einfach, aber begrenzt den automatisierten Abgleich.

Strukturiert — Dokumentreferenzen mit Typcodes, Nummern, Daten und Beträgen. Häufige Dokumenttypen: CINV (Handelsrechnung), CREN (Gutschrift), SOAC (Kontoauszug). Unterstützt ISO-11649-Gläubigerreferenzen (RF + Prüfziffern + Referenz) über CdtrRefInf. Ermöglicht automatisierten Rechnungsabgleich und Multi-Rechnungszahlungen.

UETR und gpi-Tracking

UETR (Unique End-to-End Transaction Reference) ist eine UUID v4, die vom Schuldner-Agenten erzeugt wird. Sie erscheint in PmtId/UETR über pacs.008, pacs.009, pacs.002, pacs.004, pacs.007 und pacs.028 hinweg. Sie darf in der gesamten Zahlungskette nicht verändert werden.

SWIFT gpi nutzt die UETR zur Nachverfolgung von Zahlungen über eine cloudbasierte Tracker-Datenbank. Jeder Agent bestätigt den Empfang und die Verarbeitung, was eine durchgängige Transparenz ermöglicht. Das gpi-SLA für grenzüberschreitende Zahlungen zielt auf eine Gutschrift am selben Tag auf dem Gläubigerkonto ab.

Referenzen

• ISO 20022 message definitions catalogue
• ISO 20022 external code sets
• SWIFT CBPR+ ISO 20022 usage guidelines
• SWIFT CBPR+ migration roadmap PDF
• SWIFT gpi
• EPC SEPA Credit Transfer rulebook