Payment data as an asset: what ISO 20022 data enables

ISO 20022 changed payment data from a constraint into an asset. Under the old MT messages, a payment carried a small number of fields, often in free text, and the data was hard to use. Under ISO 20022, a pacs.008 carries structured fields for the debtor, the creditor, the agents, the purpose, the remittance information, the charges, and the settlement, each with a defined format and a defined code set. The data is structured, which means a machine can read it, a machine can analyse it, and a machine can act on it. The payment is no longer just a movement of money, it is a data record. The richer data model enables three things that were not possible before. The first is better screening, because the structured debtor and creditor information can be matched against sanctions lists with far fewer false positives. The second is better reconciliation, because the end-to-end reference and the structured remittance information allow the beneficiary to match the payment to the invoice automatically. The third is better analytics, because the purpose code, the charge information, and the settlement details can be aggregated and analysed. Each of these is a business case for the migration, and each must be measured. The purpose code is a small field with a large impact. A pacs.008 carries a purpose code, such as SUPP for a supplier payment, SALA for a salary, or TAXS for a tax payment. The purpose code tells the receiving bank, the beneficiary, and the regulator what the payment is for, without reading the free text. A corporate treasurer can use the purpose code to categorise payments automatically. A regulator can use it to measure the volume of salary payments, or of tax payments, in the economy. The requirements must state which purpose codes the product supports, and how they are validated. Structured addresses are the other large change. Under MT, an address was free text, and the same address could be written in a dozen different ways. Under ISO 20022, an address is structured into fields: the street, the building number, the town, the postcode, and the country. The structured address can be validated, can be matched, and can be used for screening. The hybrid address, which combines structured and unstructured elements, is the transition, and the CBPR+ rule is that the address must be fully structured by November 2026. The product must therefore support the structured address, and must handle the transition. Remittance information is the data the beneficiary needs to reconcile. A pacs.008 can carry structured remittance information, with the invoice number, the invoice date, and the amount, in a format the beneficiary's system can read. An unstructured remittance carries the same information as free text, which a human can read but a machine cannot. The structured form enables straight-through reconciliation, where the beneficiary's system matches the payment to the invoice without human intervention. The requirements must state whether the product supports structured remittance, and how it is validated. The data must be governed, not just collected. A payment carries personal data, and the data must be protected under GDPR. It carries data that must be retained under anti-money-laundering law, and data that must be deleted when the retention period expires. It carries data that can be used for analytics, and data that cannot be shared with a third party. The data governance must state, for each field, who can see it, how long it is kept, and whether it can be used for analytics. A product that collects rich data without governing it will breach GDPR. A worked example shows the benefit in numbers. A supplier receives 500 payments a month, each carrying a pacs.008 with purpose code SUPP and structured remittance listing the invoice number and amount. The supplier system matches 475 of the 500 payments automatically, a straight-through rate of 95 percent, and 25 need manual matching at 10 minutes each, about 4 hours a month. Without structured remittance, the same supplier matches only 300 payments automatically, a rate of 60 percent, and 200 need manual matching, about 33 hours a month. The structured data saves about 29 hours a month of manual work, which is the business case for the migration. For a business analyst, the ISO 20022 data model is a mapping exercise. Each field in the pacs.008 must be mapped to the internal data model, to the screen, to the report, and to the analytics. The acceptance criteria must include a test where a payment is traced from the channel to the pacs.008 to the data warehouse, field by field, and every field is verified. Last reviewed 7 November 2026. Further reading: the ISO 20022 repository and message definitions; the SWIFT CBPR+ usage guidelines; the Bank for International Settlements work on ISO 20022 data; the European Payments Council SEPA message implementation guidelines.