Purpose Code in ISO 20022: Bedeutung, Codeliste und Praxis in SEPA

Ein Purpose Code ist ein vierstelliger Code aus einer externen Codeliste von ISO 20022.

Er benennt den Zweck einer Zahlung: "SALA" für Gehalt, "SUPP" für Lieferantenzahlung, "TAXS" für Steuern. Er beschreibt die Zahlung, er steuert sie nicht.

Zwei Aussagen gelten gleichzeitig:

• In SEPA ist der Code nicht dafür vorgesehen, dass Banken ihn für die Verarbeitung auswerten. Keine Bank in der Kette ist verpflichtet, ihn zu berücksichtigen.

• In einzelnen Märkten entscheidet er darüber, ob eine Zahlung angenommen wird.

Daraus entsteht der größte Teil der Verwirrung um dieses Feld.

Was der Code technisch ist

Die Codeliste steht bewusst nicht im Schema. So lassen sich neue Codes aufnehmen, ohne dass eine neue Nachrichtenversion nötig wird. Wer die Liste nutzt, muss sich auf die jeweils aktuelle Fassung beziehen.

Die Kardinalität hat eine praktische Folge: Eine Datei mit 500 Positionen darf 500 verschiedene Codes enthalten, aber keine Position zwei.

Die Payments Market Practice Group (PMPG) stuft Purp als reines Inhaltselement ein. Der Code wird zwischen Zahler und Empfänger ausgetauscht, reist mit der Zahlung mit und soll dem Empfänger die Zuordnung erleichtern. Er ist nicht regulatorisch, und keine Bank in der Kette verarbeitet ihn zu regulatorischen Zwecken.

Drei Felder, drei Ausstiegspunkte

Eine Zahlung legt einen Weg zurück: vom Zahler zur eigenen Bank, über Zwischenbanken zur Bank des Empfängers, von dort zum Empfänger. Drei Angaben in derselben Datei steigen an verschiedenen Stellen aus. Keine kann die andere ersetzen.

Ergänzend:

• Category Purpose: löst eine besondere Verarbeitung durch eine beteiligte Bank aus. PmtTpInf kann auf Blockebene (PmtInf) oder auf Ebene der Einzelzahlung stehen; das EPC empfiehlt die Blockebene. Ob der Code über die erste Bank hinaus weitergegeben wird, hängt in SEPA von der Vereinbarung zwischen Auftraggeber und Auftraggeberbank ab.

• Regulatory Reporting: eigene Struktur mit zuständiger Behörde, Ländercode und einem Code, der nicht von ISO stammt.

• Purpose: fährt bis zum Ende durch, wenn ihn niemand vorher entfernt.

Die PMPG nennt die Verwechslung dieser drei Felder als Hauptgrund dafür, dass Zweckangaben im falschen Element landen, häufig im Verwendungszweck (RmtInf).

Folgen: verzögerte Zahlungen, weniger Automatisierung, Rückfragen der beteiligten Banken.

Wer den Code am Ende sieht

Im SEPA-Regelwerk gehört der Zweck zu den erweiterten Angaben. Für diese gilt eine Ausnahme: Die Bank des Empfängers darf sie weglassen, wenn der Empfänger eine Schnittstelle ohne ISO 20022 nutzt. Der Code kommt also bei der Bank an. Ob er den Empfänger erreicht, entscheidet dessen Bank.

Im elektronischen Kontoauszug (camt.053) existiert dafür ein Feld auf Transaktionsebene. Das Verhalten ist von Institut zu Institut verschieden:

• Manche Banken liefern den Code aus.

• Manche leiten daraus sogar den Buchungstext ab, etwa bei Spenden oder wiederkehrenden Zahlungen.

• Manche liefern das Feld gar nicht.

Es gibt keine Quelle, aus der sich das Verhalten pro Land und Bank ableiten ließe. Wer den Purpose Code auf der Empfangsseite auswerten will, muss testen:

1. Testzahlung mit gesetztem Purp/Cd auf das eigene Konto.

2. camt.053 abrufen und das Transaktionsfeld prüfen.

3. Ergebnis je Bank dokumentieren.

4. Nach jedem Formatwechsel wiederholen.

Wann sich die Pflege lohnt

Gründe dafür:

• Marktpflicht. Die Bank of England schreibt seit dem 1. Mai 2025 im Großbetragssystem CHAPS Purpose Codes vor, und zwar bei Immobilientransaktionen und bei Zahlungen zwischen Finanzinstituten. Die Pflicht gilt für Einreichungswege, die der jeweilige CHAPS-Direktteilnehmer kontrolliert.

• Weniger Rückfragen. Ein ausreichend genauer Code verhindert, dass eine nachgelagerte Bank manuell nachfragt. Das ist der eigentliche Nutzen im grenzüberschreitenden Verkehr.

• Asymmetrisches Risiko. Im Vernetzungsprojekt Nexus lautet die Empfehlung: im Zweifel einen Code mitgeben. Banken in Ländern, die keinen Code erwarten, dürfen eine Zahlung mit Code nicht ablehnen.

Gründe, die nicht tragen:

• Meldepflichten. Ein Meldecode in Purp erfüllt keine Meldepflicht und verhindert auch die Rückfrage nicht, die er verhindern sollte. Regulatorische Codes gehören in RgltryRptg.

• Steuerung der Verarbeitung. Dafür braucht es CtgyPurp und eine Vereinbarung mit der Bank.

Wann sich der Aufwand nicht lohnt: Eine deutsche GmbH, die im Inland Lieferanten bezahlt, gewinnt durch gepflegte Purpose Codes nichts. Die Zahlung läuft auch ohne, und der Informationswert liegt im Verwendungszweck mit der Rechnungsnummer. Jede zusätzliche Klassifizierung pro Zahlung ist dann Pflegeaufwand ohne Gegenwert. Relevant wird das Feld, sobald Zahlungen die SEPA-Grenze verlassen oder ein Empfänger den Code auswertet.

OTHR ist keine Antwort

OTHR steht für „sonstiger Zweck“ und ist der bequemste Weg, ein Pflichtfeld zu füllen, ohne sich zu entscheiden. In der britischen Konsultation zur nationalen Codeliste haben Marktteilnehmer gefordert, ihn gar nicht erst aufzunehmen. Begründung: Der Code sei so breit, dass er die Qualität der Zweckdaten insgesamt senke.

Das gilt allgemein. Ein Feld, das fast immer denselben Wert trägt, ist kein Datenfeld mehr, sondern eine Formalität. Wer eine Zweckklassifizierung pflegt, sollte sie auswertbar halten. Sonst bleibt das Feld besser leer.

Warum das Thema jetzt Bewegung bekommt

• Die Bank of England hat im September 2025 bestätigt, dass sie die Purpose-Code-Pflicht ab November 2027 auf alle CHAPS-Zahlungen ausweitet, weiterhin für Einreichungswege unter Kontrolle der Direktteilnehmer. Ihre nationale Codeliste hat sie im Juni 2026 um Codes für Gebühren und Entgelte erweitert.

• Der Ausschuss für Zahlungsverkehr und Marktinfrastrukturen bei der Bank für Internationalen Zahlungsausgleich (CPMI) hat harmonisierte Datenanforderungen für ISO 20022 veröffentlicht. Sie sind keine regulatorische Vorgabe, sondern eine Empfehlung; Marktteilnehmer sollen sich bis spätestens Ende 2027 daran ausrichten.

Entschieden wird das im eigenen Vorsystem, und zwar bei der ohnehin anstehenden Umstellung der Zahlungsformate. Wer den Formatbaum neu aufsetzt, legt dabei fest, ob es künftig eine Zweckklassifizierung gibt und woher sie kommt. Am Feld selbst ändert die Umstellung nichts, an der Gelegenheit schon. Hier erfahren Sie mehr zu Neue Zahlungsformate im Überblick.

Der npX Banking Connector prüft Zahlungsdaten aus dem ERP-System gegen die Regeln der jeweiligen Bank, bevor die Datei eingereicht wird. Was das umfasst, steht auf unser Produktseite.