ISO20022 for TARGET2 and EBA STEP1/EURO1

The decision by the ECB (closely followed by the EBA) to migrate TARGET2 and EURO1/STEP1 from SWIFT MT to ISO20022 MX formats was perceived to be forward thinking and potentially driving the payments industry down the ISO20022 path for high value payments (long being the purview of the SWIFT MT category 1 and category 2 message types). The decision of go live in November 2017 also would give time (some 5 years or so) for the ECB, EBA and the participant banks to get their plans and interfaces together to make the migration as smooth as possible. Finally, to ease the pain, the ECB (and thus EBA) would maintain fields and formats in the cross over from MT to MX.

The first problem is that the rest of the high value payments market has not really reacted to follow the lead of the ECB/EBA – the silence on whether or not their is justification to migrate CHAPS in the UK has only enhanced the deafening silence – although I do understand that it is difficult to justify the business case and why fix what isn’t broken.

The next issue is that the change from MT/MX for the Euro transactions is to be made at a time when Banks across Europe are facing the challenge of European legislation for Ring Fencing (in whatever guise of Barnier or Vickers). The effect on most banks across Europe will be massive with large swathes having to split accounts, processing, memberships etc to meet these regulatory requirements.

In some respects, the ECB could take pity on the market players and provide some timely respite, but such kindliness is not known from Central Bankers and so headlong we go into the world of MX for High Value payments.

There is often, in such circumstances, a view by user banks that this means we have to change our entire messaging infrastructure from channels through to payment hubs to migrate from MT to MX – Payment System providers honey day – NOT SO FAST……

There are ways and means to leverage middleware type applications and functionality to preserve the MT formats from customer to Bank and then purely do the remapping at the connection to SWIFT gateway level into MX – we know that there will not be any truncation of data in the first iteration of MX for TARGET2 etc therefore the need to amend systems is not so large as could be expected.

What the ECB will demand, and which will cut across the swathe of change for RingFencing will be the testing required for TARGET2 and EURO1/STEP1 from the perspective of connection tests, fallback tests etc. These will take planning and involvement to ensure appropriate ECB/EBA certification (explicit or implicit) is duly received.

One advantage of such an approach is that the middleware approach will allow additional remapping to be supported and could allow channels to handle MX formats if required/desired.

Leave a comment

Your email address will not be published.