ISO 20022

Veröffentlicht am

28.08.2026

Aktualisiert am

28.08.2026

Lesezeit

4 min

Definition

ISO 20022 ist der internationale Standard für den Nachrichtenaustausch im Finanzwesen. Entgegen der verbreitete Meinung „ISO 20022 ist ein XML-Format“ ist die ISO20022 syntaxunabhängig.

Der Standard ist kein einzelnes Format, sondern ein Verfahren, aus dem Formate entstehen. Er beschreibt nach eigener Definition „einen einheitlichen Standardisierungsansatz (Methodik, Prozess, Repository), der von allen Standardisierungsinitiativen im Finanzwesen genutzt werden kann“.

Die drei Bestandteile

Der Standard besteht aus drei Teilen:

  • Modellierungsmethodik – ein Verfahren, um Geschäftsvorfälle syntaxunabhängig zu beschreiben
  • Data Dictionary – ein zentrales Verzeichnis der Geschäftsbegriffe und ihrer Definitionen
  • Business Process Catalogue – die daraus abgeleiteten Geschäftsprozesse und Nachrichten

Data Dictionary und Business Process Catalogue bilden zusammen das Financial Repository, das öffentlich auf iso20022.org steht.

Aus dem Modell werden anschließend nach festen Regeln die technischen Schemata erzeugt (in der Praxis XML, laut Standard auch ASN.1). Ein Feld ist nicht deshalb definiert, weil es im XML-Schema steht, sondern weil es im Data Dictionary eine Definition hat.

Der Nachrichtenname

Jede Nachricht trägt einen vierteiligen Namen. Das Beispiel pacs.008.001.08:

BestandteilBedeutungim Beispiel
pacsGeschäftsbereichPayments Clearing and Settlement
008NachrichtendefinitionFI to FI Customer Credit Transfer
001VarianteGrundvariante
08Versionachte Fassung

Zwei Systeme können beide „pacs.008 sprechen“ und trotzdem nicht zusammenpassen, weil sie unterschiedliche Versionen erwarten.  „pacs.008″ ist keine ausreichende Spezifikation.

Die Geschäftsbereiche

Die ersten vier Buchstaben ordnen jede Nachricht einem Geschäftsbereich zu. Für den Zahlungsverkehr sind vor allem diese relevant:

KürzelGeschäftsbereichBeispiele im Glossar
painPayments Initiationpain.001pain.002pain.008pain.013/14
pacsPayments Clearing and Settlementpacs.002pacs.003pacs.004pacs.007pacs.008pacs.028
camtCash Managementcamt.029camt.052camt.053camt.054camt.056camt.110
acmtAccount Managementacmt.023acmt.024
headBusiness Application Headersiehe Header im Zahlungsverkehr
remtPayments Remittance AdviceZahlungsavise
redaReference DataStammdaten, Verzeichnisse
admiAdministrationtechnische Steuerungsnachrichten
authAuthoritiesMeldungen an Behörden

Daneben stehen die Familien für Wertpapiere (sesesetrseev), Sicherheiten (colr), Devisen (fxtr) und das Kartengeschäft (caaacatmcain und weitere).

Regel für den Zahlungsverkehr: pain läuft zwischen Kunde und Bank, pacs zwischen Banken, camt berichtet über Konten.

Die Nachrichten haben typischerweise Abfolgen im Rahmen des Geschäftsvorfalls beim verwendeten Scheme. Hier das Beispiel einer SEPA Überweisung:

pacs.008 in the SEPA Clearer — one payment, a whole conversationThe account holder instructs the debtor bank with a pain.001 and receives a pain.002 in return. The debtor bank sends a pacs.008 through the SEPA Clearer to the creditor bank. Only if the payment cannot be processed does a pacs.002 reject come back. After settlement the beneficiary is notified by a camt.054 and both customers see the payment on their camt.053 account statement. If the money has to come back, the account holder asks with a camt.055 and the debtor bank sends a camt.056 recall. The creditor bank then answers in one of two ways: variant A, a pacs.004 returns the funds and a camt.054 credits them back; variant B, a camt.029 rejects the recall with a reason code and the money stays with the beneficiary.Debtorthe account holderDebtor’s bankoriginator’s PSPSEPA Clearerthe CSM in betweenCreditor’s bankbeneficiary’s PSPCreditorthe beneficiary1 · the order2 · the paymentonly if something is wrongsettlement — the payment is final3 · the customers are informed4 · the recallpain.001 · the customer’s orderpain.002 · acceptedpacs.008 · customer credit transferpacs.008 · on to the creditor’s PSPpacs.002 · rejectpacs.002 · passed backcamt.054 · credit notificationcamt.053 · account statementcamt.053 · account statementcamt.055 · the customer’s recall requestcamt.056 · recall requestcamt.056 · on to the creditor’s PSPpacs.004 · accepted — funds returnedpacs.004 · the return arrivescamt.054 · credited backcamt.029 · rejectedcamt.029 · reason code says whyrecall window: 10 business days for a bank recall, up to 13 months for a customer request — answer due within 15 business days5 · one of two answersvariant A · the recall is acceptedvariant B · the recall is rejectedno return — the money stays with the beneficiaryIn the SEPA Clearer the pacs.002 is the reject. In SCT Inst the same message is the positive confirmation.An ISO 20022 message rarely travels alone — it is part of a sequence1 · The order: the account holder sends a pain.001 and gets a pain.002 back2 · The payment: a pacs.008 runs through the SEPA Clearer to the beneficiary’s PSPOnly if something is wrong: a pacs.002 rejects the payment — then it never settles3 · After settlement: a camt.054 notifies the beneficiary, a camt.053 reports to both4 · The recall: the account holder asks with a camt.055, the bank sends a camt.0565a · Recall accepted — a pacs.004 returns the funds, a camt.054 credits them back5b · Recall rejected — a camt.029 comes back with a reason code, and the money staysOne payment, up to ten message types — that is why ISO 20022 is a conversation, not a form
pacs.008 in the SEPA Clearer — from the account holder to the beneficiary, and every message in between

Wer den Standard pflegt

Zuständig ist das ISO-Komitee TC 68/SC 9. Darunter arbeiten drei Gremien:

  • Die Registration Authority (RA) ist „Hüterin des ISO 20022 Financial Repository“. Diese Aufgabe nimmt SWIFT wahr – ein Punkt, der oft übersehen wird: SWIFT betreibt das Repository im Auftrag der ISO, besitzt den Standard aber nicht.
  • Die Registration Management Group (RMG) überwacht den Registrierungsprozess und berichtet an TC 68/SC 9.
  • Die Standards Evaluation Groups (SEGs) prüfen neue Nachrichten aus fachlicher Sicht und genehmigen Änderungen. Sie sind nach sechs Domänen gegliedert: Payments, Securities, Cards and Retail Financial Services, Foreign Exchange, Trade Finance und API Resources.

Ergänzt wird das durch die Technical Support Group (TSG) für die technische Unterstützung.

Vom Standard zur Spezifikation: Usage Guidelines

Das Repository ist für die Praxis zu weit gefasst. Fast jedes Feld ist optional, fast jede Struktur mehrfach belegbar. Deshalb schnürt jede Nutzergemeinschaft ihr eigene Usage Guidelines, die einschränkt, welche Felder verwendet werden, welche verpflichtend sind und wie sie zu füllen sind.

RegelwerkHerausgeberAnwendungsbereich
SEPA-RulebooksEPCSCTSCT InstSDDSRTP
CBPR+Payments Market Practice Groupgrenzüberschreitender Zahlungsverkehr über SWIFT
HVPS+High Value Payments Systems PlusGroßbetragssysteme wie T2
Nationale und institutionelle Vorgabenu. a. Bundesbank, Berlin GroupSEPA Clearer, Schnittstellen

Quellen