What ISO 20022 is

ISO 20022 is an international standard for financial messaging that defines a common language for exchanging payment, securities, trade, and other financial information. It is maintained by ISO, the International Organization for Standardization, and it is developed through a community of financial institutions, market infrastructures, and vendors. Unlike SWIFT MT, which uses a fixed, compact text format, ISO 20022 uses XML, which is a structured, extensible format that can carry far richer data, including full addresses, detailed remittance information, structured purpose codes, and party identification. The standard is not a single message, but a catalogue of messages, each defined for a specific business purpose. The core idea of ISO 20022 is that business concepts should be defined once and reused across many messages. A debtor, a creditor, an amount, and a payment instruction are defined as business components in a central dictionary, and each message reuses those components. This means that a payment initiation message, a payment clearing message, and a payment status report all use the same definition of a debtor, so there is no ambiguity about what a field means. That consistency reduces the need for manual repair, improves straight through processing, and makes it easier to build systems that work across different payment schemes and different countries. For a business analyst, ISO 20022 is important because it changes how payment data is modelled. Instead of learning a separate field list for each MT message, you learn a business model with parties, accounts, amounts, and references, and you learn how that model is expressed in XML. The messages have long, descriptive names, such as pacs zero zero eight for a customer credit transfer, pain zero zero one for a customer payment initiation, and camt zero five three for a bank statement. Once you understand the naming convention, where pacs means payments clearing and settlement, pain means payments initiation, and camt means cash management, the catalogue becomes navigable rather than overwhelming. Worked example with real numbers: a corporate customer sends a EUR 25,000 payment to a supplier, and the bank must carry the full invoice data so the supplier can reconcile automatically. In MT the remittance was limited to 140 characters, so the supplier reconciled only part of the payment manually. In ISO 20022 the pacs.008 carries structured remittance with the invoice number, the invoice amount and the adjustment, so the supplier reconciles the full EUR 25,000 automatically, and the accounts team saves 30 minutes per payment. The standard is therefore a business change, and the analyst must quantify the benefit in hours and in errors avoided, not just in messages sent. Failure and recovery: an ISO 20022 message that fails schema validation is rejected as a whole, not just the bad field, so one missing mandatory element can stop a EUR 25,000 payment, and the recovery is to fix the field and resend with a new message identifier, because the old identifier is associated with a rejected message. A message that fails a business rule, such as an amount above a limit or a value date on a holiday, is rejected with a pacs.002 and a reason code, and the fix is in the business data, not in the XML. A message sent in the wrong version, because the namespace declares pacs.008.001.07 when the receiver expects 001. Each failure is reported in a pacs.002, and the operations team must be able to read it and tell the customer what to fix. For a business analyst, product owner or subject matter expert, the test is to read a pacs.008, a pain.001 and a camt.053, and to explain each element, its purpose and its format, without a dictionary. The naming convention is the map: pacs means payments clearing and settlement, pain means payments initiation, camt means cash management, admi means administration, and head means header, and the numbers after the dot are the message identifier. A requirement that describes a payment without naming the message, the version and the market practice, such as CBPR+, is incomplete, because the same message name can mean different field rules in different markets, and the difference must be stated. Pointer to the deeper lessons in this chapter: the fundamentals in this lesson are expanded in three lessons at the end of this chapter, ch6s8, ch6s9 and ch6s10. Lesson ch6s8 teaches ISO 20022 fundamentals with annotated XML samples, reading a pacs.008 line by line. Lesson ch6s9 teaches the MT versus MX worked comparison, the same USD 25,000 payment as an MT103 and as a pacs.008, field by field. Lesson ch6s10 teaches the Business Application Header, head.001, with the From, To, BizMsgIdr, MsgDefIdr, BizSvc and CreDt fields and the CBPR+ rules for when a header is required. Read those three lessons before writing a message requirement, because they carry the worked examples this lesson summarises.