“Groundhog Day” – “Finextra”, the industry portal, draws an analogy to this classic film starring Bill Murray with reference to a cascade of postponements in European and international payment transaction projects. Since March 2020 alone, market participants have found themselves confronted with 13 postponed deadlines, some at very short notice, and all in connection with ISO 20022 and TARGET2.
The respective triggers leading to the necessary postponement differ on a case-by-case basis – but they can be traced back to a fundamental pattern: technical and functional challenges facing migration projects are underestimated and/or tackled too late due to the bank’s own resource scarcity.
The knock-on effect of this trend on procrastination in payment transactions: banks that have prepared in good time for the T2/T2S consolidation or the MT/MX migration at SWIFT, for example, must ensure – within a relatively short space of time – that no new function in their systems that has been integrated in the planned release, ends up going live at the originally planned time. This, in turn, leads to an increased testing effort.
It is, therefore, not surprising that some industry players are reacting with pronounced displeasure to the short-term postponement of payment transaction projects that have been the subject of long-term preparation. This was a recent headline in the “Börsen-Zeitung”: “Verschobene ISO20022-Migration erzürnt Marktteilnehmer” – “Postponed ISO 20022 migration enrages market participants”. The backdrop: The European Payments Council (EPC) was forced to postpone the migration of SEPA payment processes by four months just three weeks before the planned ISO 20022 version changeover.
It is not only after this event that payment service providers (PSPs) are beginning to ask us how they can prepare their own systems for these last-minute changes in deadline. Let’s get one thing clear: there is no one-size-fits-all approach here. However, based on our numerous years of experience with payment transaction projects, we have identified three strategies that financial institutions can adopt to reduce costs that are difficult to predict:
- Intelligent Release Management: if a bank’s payment transaction system offers the option of issuing individual releases, additional version updates can be scheduled at short notice as needed. Experience has shown that extensive and tailored advice is required here.
- Customised component solutions: depending on the system architecture of a PSP, new functions can be outsourced to separate components, meaning that there is one module for old and new versions. This can significantly reduce the amount of testing required.
- Integration of switch solutions: Here, the PSP anchors checkpoints in the processing lines of its own systems, in order to facilitate the switch between different regulatory requirements as required. The disadvantage characterising this solution is that the switches have to be removed in the foreseeable future, thereby entailing regression tests.
As a fundamental requirement, the following can be stated: Fallback options should now be considered as an integral part of a payment project. This is because: the next postponement in a payment transaction project is potentially on the horizon.
DPS supports banks, savings banks and other payment service providers in the development of customised strategies.
By the way: on our info page 20022.info, we’ll be sure to keep you up-to-date with the latest news on ISO 20022. There, you will also find the publications mentioned above.
