When looking at the history of German banking IT, the conversion of xBorder and HVPS payment systems to the new ISO20022 standard is the first project to be overwhelmed by a pandemic that has all but brought daily life and work to a standstill across the globe. Also in the financial sector, it goes without saying that the participants’ focus is on protecting the employees’ health and maintaining the institutes’ operational readiness. Therefore, it is entirely understandable that all projects that are not absolutely necessary for the maintenance of business operations are currently being reviewed.
However, in the case of MT/MX migration, the central institutions, i.e. the Eurosystem (Target2), the EBA (EURO1) and SWIFT (xBorder), determine the timing parameters. And their planning is in motion: Already prior to the corona crisis escalation, SWIFT had announced a postponement of the coexistence phase by one year. On the other hand, to date, the ECB has confirmed that it intends to continue with the big bang migration in November 2021, despite opposition from the institutions and their associations.
Institutes now have to decide: Is it the right decision to slow down project work in order to prioritise other issues? In light of the new coronavirus, might it not even be the best strategy to leave things at the current MT processing stage and to convert messages only where absolutely necessary? Or should one follow SWIFT’s recommendation to aim at further integration of the new standard by the new starting date of the coexistence phase?
If one follows the comments received from the payment community, there seems to be a consensus that it would be better for institutions “not to lay off the gas pedal” and use the time gained for deeper integration and functional enhancements.
This article attempts to provide a somewhat differentiated view. We are convinced that, by taking into account the following aspects in a holistic way, the right strategy must be adopted individually for each institution.
1. xBorder (CBPR+) and Euro-Clearing (HVPS)
Should it be impossible to observe the starting dates for MX processing of Target2/EURO1 and SWIFT, the project plans definitely need to be adjusted. Because, in this case, institutions will have to convert messages from MX to MT between November 2021 and November 2022, which will be forwarded from the Euro Clearing System via SWIFT to a correspondent bank. We need solutions for this, while questions arise that are not easy to answer, such as how such a conversion can be carried out without losing data relevant for compliance checks. SWIFT has already announced specifications for a uniform conversion.
Moreover, with replanning, the question arises as to how synergies can be maintained, and extended time frames can be used at the same time.
In the back office, the Euro Clearing and xBorder processes share a number of commonalities, whose uniform processing also makes sense with different ISO20022 start dates. Furthermore, there are migration-related topics that need to be solved for xBorder and Euro-Clearing in equal measure, such as the processing of structured purposes with up to 9,000 characters in systems that, to date, have been based on 140 characters. Here, it would also seem better to solve the issue once and for all, and uniformly.
Conversely, specific challenges exist especially in the xBorder area, which may possibly be de-prioritised due to the SWIFT postponement. For instance, these include the adjustments to the front ends in the branches, which are currently facing particular corona-virus-related challenges (more on this later under 7.).
2. Complete conversion or converter solutions
To date, the institutes’ strategies can be divided into two basic categories: Those wishing to have all relevant applications converted to ISO20022 by November 2021, and those that initially would like to maintain the existing MT processing and convert incoming MX messages to MT for this purpose (in this regard, please also refer to our white paper).
Institutes that have focused on a complete implementation of ISO20022 right from the outset now have more time to achieve this goal, which alone is already quite ambitious. Institutes that, by November 2021, only wanted to be able to process incoming MX messages using a converter solution now have the opportunity to bring this strategy into question. Owing to the postponement, the SWIFT organisation itself hopes that more institutions will implement the extended capabilities of ISO20022 in end-to-end processing from the outset and that none will implement intermediate solutions that are simply reduced to messaging.
3. Extended services
The decision in favour of or against a rapid end-to-end implementation of ISO20022 does, however, also depend on the market positioning of the institute. It is to be expected that the extended possibilities of ISO20022 will generate significant added value, especially in the corporate banking sector. Institutions that have corporate customer support in their foreign business as one of their core competences are more likely to gain competitive advantages by an early adaptation to ISO20022 than institutions that are mainly active in retail banking.
Institutions that rely on extended end-to-end services in payment traffic are typically also participants in SWIFT gpi. Where evident, their SWIFT gpi plans remain unchanged for the time being. Therefore, in their project planning, participating institutions are still additionally bound by the gpi roadmap.
4. Legacy strategy
The respective institution’s strategy regarding the existing legacy systems is also decisive for the best possible handling of the changed timing parameters of the MT/MX migration. The argument in favour of a converter solution that is as simple as possible may be that the affected applications are to be replaced in the medium term anyway, thus a change to ISO20022 would lead to sunk costs. In light of the postponement, and especially since the end date for the coexistence phase (2025) remains unchanged according to current planning, this argument also remains relevant.
5. Including disruptive solutions
The payment community also assumes that the delayed introduction of SWIFT MX will offer opportunities for disruptive providers such as Ripple, allowing them to position themselves as an alternative.
Institutions already relying on such disruptive providers as Ripple in addition to SWIFT should consider a to what extent the postponement can be used as an opportunity to integrate the various networks in order to create a uniform, functional and cost-optimised service from the customer’s point of view. Today, numerous banking partners of DLT-based payment networks limit themselves to prototypical, isolated solutions that are not integrated into the mass business.
6. In-house solution or outsourcing
Bearing all these considerations in mind, it should not be forgotten that many institutions do not handle the processing of their xBorder and HVPS payment traffic themselves. Rather, they have already outsourced it or are planning to do so in the near term.
In connection with MT/MX migration, a major benefit of outsourcing is that specialised payment processing service providers have professional and technical know-how in the relevant banking IT disciplines that is otherwise hard to come by on the market . The possibility of mapping industry-wide standards in correspondingly standardised services creates synergies that have a positive impact on the overall costs of the institutions associated with MT/MX migrations.
The announced postponement may be a good reason for some institutions to review the make-or-buy decision taken to date.
7. MT/MX projects in coronavirus shock
In these times, it’s not possible to make a sound prediction of the challenges the coronavirus crisis will present to the financial sector. Here and now, most institutions are faced with the question of which change projects they should stop in order to concentrate on maintaining operations, and which projects they should better continue in order to avoid high restart costs and to maintain their own market position in the era of digitalisation.
This much is clear, though: Some departments of a great many institutions are now faced with enormous additional burdens, for instance brought on by the necessary processing of promotional loans, which, even in the absence of fully-digitalised processes, will tie up a considerable number of employees both in the front and back offices. The same applies to securities trading and the back office, which have to cope with high transaction volumes in times of extreme market volatility.
In payment transactions, such an additional burden does not necessarily exist to the same extent. In our own experience, the project work associated with MT/MX migration was already being executed in a disperseded manner and online in many cases, even prior to the corona virus crisis. The move to online co-working, which is now enforced by the crisis, may therefore affect ongoing MT/MX projects to a lesser extent than other projects of a comparable size and complexity. Therefore, there may be good reasons why MT/MX migration is one of those projects where it would make more sense to continue with the project work than to stop it until such time as the crisis is over.