Reading ISO 20022 Names: pain, pacs and camt Explained

Every ISO 20022 message name has three parts, and each part carries meaning. The four letter prefix names the business area. The prefix pain means payment initiation, and those messages live in customer to bank space. The prefix pacs means payments clearing and settlement, and those messages live in interbank space. The prefix camt means cash management, and those messages carry statements, reports and investigations. Once you know the prefix, you know which space the message belongs to, which parties exchange it, and roughly what it does, before you read a single field inside it. The three digit number after the prefix identifies the message within its business area. In the pain family, 001 is a customer credit transfer initiation and 002 is a customer payment status report, while 008 is a customer direct debit initiation. In the pacs family, 002 is a payment status report, 003 is a direct debit collection, 004 is a payment return, 007 is a reversal, and 008 is a customer credit transfer. In the camt family, 052 is a bank to customer account report, 053 is a bank to customer statement, 054 is a debit or credit notification, 056 is a cancellation request, and 029 is a resolution of investigation. The version number at the end of the name identifies the message definition version, and it matters because fields change between versions. The name pacs.008.001.08 means the pacs.008 message, variant 001, version 08. The name pain.001.001.09 means the pain.001 message, variant 001, version 09. A bank that expects version 09 will reject a file built to version 03, because mandatory fields may be missing or structured differently. When a business analyst writes a requirement, the full name with its version must be stated, or developers and testers may build against the wrong definition and fail certification testing. One business event can generate several message names across the spaces, and the worked example shows how. Loire Components sends a pain.001.001.09 to Meridian Bank Paris to start the EUR 48,250 payment. Meridian Bank Paris replies with a pain.002.001.10 status report, then creates a pacs.008.001.08 for the interbank leg to Harbour Bank Frankfurt. Harbour Bank Frankfurt may reply with a pacs.002.001.10 status report, and it will report the credit to Rhine Metals with a camt.053.001.08 statement. The same EUR 48,250 appears in four messages, but each message serves a different audience and a different purpose. Worked example with numbers: the EUR 48,250 payment from Loire Components carries four message names, and each one tells a different story. The pain.001.001.09 starts the payment in customer to bank space, the pain.002.001.10 reports the status back to the customer, the pacs.008.001.08 carries the payment between banks, and the pacs.002.001.10 reports the interbank status. A business analyst who reads the name pacs.008.001.08 knows at once that it is a payments clearing and settlement message, that it is a customer credit transfer, and that it is version 08 of the definition, and can therefore check whether the bank system supports that version before the payment is sent. Failure and recovery: message names fail when a bank uses the wrong version, and the failure is a rejection at validation. If Meridian Bank sends a pacs.008.001.02, an old version, to a clearing system that expects version 08, the message is rejected, because the fields have moved between versions, and the payment does not reach Harbour Bank. The recovery is a corrected message in the right version, but the payment has lost its exchange period, and the value date must be moved to the next business day. A bank must therefore check the message version for every counterparty before sending, and must keep a table of which version each clearing system and each correspondent bank accepts, because a version table that is out of date is a payment that will be rejected. For a business analyst, product owner or subject matter expert, the naming requirement must state the three parts of every message name, the four letter prefix, the three digit number and the version, and must give an example for each family, pain, pacs and camt. The requirement must also state that a business event can generate several message names across the spaces, and must map each one to the step it belongs to, because a requirement that names only the pacs.008 and forgets the pain.002 will leave the customer without a status update. The test pack must include a message with the wrong version and a message with a version the counterparty does not support. Source: ISO 20022 repository; EPC SCT Rulebook 2025; last reviewed 7 November 2026.