Everyone talks about ISO 20022 like it is a date on a calendar. A deadline to clear, a box to tick, a project that ends.
From inside payment operations, it is not a date. It is a long list of small things that break quietly, and almost none of them break on go-live day. Here is what goes first, in my experience watching these migrations up close.
1. Field mappings
MT messages truncate. MX messages carry rich, structured data. Map one onto the other and somewhere a remittance detail gets cut, quietly, with no error. Nobody notices until a beneficiary's reconciliation fails days later and the trail leads back to a field that was always too small to hold what you tried to put in it.
2. Downstream systems
The payment engine speaks MX now. Good. The sanctions filter, the archiving system, the reporting job someone wrote ten years ago and then left the company? Still expecting MT. The migration was never one cutover. It is dozens of them, scattered across systems that were never designed to be changed together, and each one is somebody's quiet assumption that the format would never move.
3. Exception handling
The happy path gets tested for months. Demos, sign-offs, dry runs. The repair queue, which is where operations actually lives, gets tested in production. That is not a criticism of anyone. It is just how it always goes. The exceptions are infinite and the test window is not, so the real edge cases meet the real system on the first busy morning.
4. The first month
A migration is judged by its first month of exceptions. The go-live is the easy part. The month after is where you find out whether you actually understood your own pipeline.
I now run AI systems in production and hold them to the same clock. The demo always works. What tells me whether a thing was built properly is the first month of real exceptions.