What changes for banks, corporates and operations

For banks, ISO 20022 migration requires changes to payment engines, to screening systems, to reconciliation systems, and to customer channels. Payment engines must be able to parse XML, validate against the usage guideline, and generate pacs messages. Screening systems must be able to screen structured addresses and party data, not just flat MT fields. Reconciliation systems must be able to match on the new references and on the richer remittance data. Customer channels must be able to capture the additional data that ISO 20022 requires, such as a full structured address or a purpose code, without making the customer journey unacceptably long. Those changes are significant, and they require careful planning, testing, and training. For corporates, ISO 20022 offers benefits, but it also requires changes. A corporate that sends a bulk payment file as a pain zero zero one must be able to provide richer data, including structured remittance information and ultimate party details. That data may not be available in the corporate enterprise system today, and the corporate may need to change its own processes to capture it. The benefit is better reconciliation, fewer exceptions, and faster investigation when a payment fails. The cost is the effort to change internal systems and to train staff. Analysts who work with corporates must be able to explain both the benefit and the cost, and must help corporates plan their own migration. For operations teams, ISO 20022 changes the daily work. Repair queues will see different errors, because XML validation errors are different from MT format errors. Investigations will have more data to work with, but will also require new skills to read XML and to understand the new message types. Training is therefore a critical part of any migration programme. A bank that migrates its technology but does not train its operations team will see its straight through processing rate fall, not rise. The analyst role is to bridge that gap, by documenting the new flows, the new error codes, and the new procedures, and by ensuring that the business is ready for the change, not just the technology. Worked example with real numbers: a bank migrates 10,000 corporate customers from MT to ISO 20022, and the change touches the channel, the hub, the ledger, the reconciliation and the customer statements. The hub must create a pacs.008 with the correct version, namespace and market practice, and must map the MT fields to the MX fields, field by field, with truncation rules. The reconciliation must match the pacs.008 MsgId to the camt.053 entry, and the customer statement must show the structured remittance, so the customer can reconcile. If any one of these five is missed, the migration will pass its message tests and fail in production. Failure and recovery: a corporate customer that sends a pain.001. A bank that sends a pacs.008 in the wrong version will have the whole file rejected, and the recovery is to upgrade the version, which is a project change, not a data fix. A customer statement that shows only the ledger balance, without the value date, will cause the customer reconciliation to fail, and the recovery is to add the value date and the end to end identifier to the camt.053 mapping. An operations team that cannot read a pacs.002 rejection will escalate every rejection to the vendor, and the recovery is training, with annotated samples, as in ch6s8, so the team can find the field and tell the customer what to fix. For a business analyst, product owner or subject matter expert, the test is to write the impact assessment for a migration, with one row per stakeholder, corporate, bank, operations, treasury and finance, and columns for what changes, what stays the same, what the risk is, and what the test is. The corporate must change its ERP and its reconciliation, the bank must change its channel, hub and ledger mapping, operations must learn to read pacs.002 rejections, treasury must fund the same settlement, and finance must approve the same postings. A requirement that describes only the message change, without the stakeholder impacts, will be approved by technology and rejected by operations, because operations owns the failure handling, and the failure handling is where migrations fail.