Structured addresses – or: the ostrich effect is rubbish

Time is running out, the next big IT challenge for the ISO 20022 formats is coming up. As often before, the first rules are already being tightened: As of November 2022, ISO 20022 payments submitted by the customer with unstructured address content of the Ultimate Creditor and Ultimate Debtor are rejected by the financial institutions.

Why were these two specifications in particular chosen? Quite simply – the fields that tend to be filled less frequently in the mass of payments are used as test subjects. Rather few transactions will be affected – therefore this issue can be approached from a small and calculated perspective.

"Not at all" does not work at all
For the applications and their developers, however, the small-scale approach is not a good one. There is a lot to be said for all or nothing – but the latter is not an option. If structured addresses are to be used, they should be used everywhere – including for the creditor, debtor and the other address details.

Too short-sighted
If you now think: "Oh, that's Switzerland, that doesn't affect me here in Germany or Austria", then you might be sorely mistaken. For the future SWIFT payments, too, only structured addresses are to be used as of 2025!
And anyone who believes that this does not affect the customer interface, i.e. the correct delivery of structured addresses by the many customer systems, is overlooking the fact that up to now there has been no system that can correctly break down any address delivered in an unstructured form and process it as a structured address. The diversity of international address data makes this impossible.

Needlework is needed
So now it’s up to all of us – customer product manufacturers as well as financial institutions themselves. Structured addresses have to be recorded everywhere and transported via the respective formats until they eventually end up in the SWIFT network. Records must be changed, database structures adapted and the content data must end up in a new place in the respective ISO 20022 format. Since, as already mentioned, an automatic and error-free migration/conversion of the previous unstructured address data to structured address data is not possible, we have to expect our customers and the employees in the financial institution to perform a manual check of the converted address data – thus a somewhat longer project. For Germany, this has already been defined for the new ISO cross-border payment in the ISO 20022 format pain.001.00.09, effective as of 2025.

Time periods are relative
Anyone who still believes that this change will somehow miraculously happen by itself is mistaken: time is of the essence! 3 years is a conceivably short time for software development, and the work is very extensive. Sticking your head in the sand may seem comfortable, but it leads to blindness in the short term. The early bird has budgets and orders in mind.

Author: Michael Schunk