It’s easy to say that a problem is like Y2K, but it’s not generally true. With Y2K, technology people didn’t start to promote the use of a standard date format with a four-digit year that would work post-1999 until it was already too late. They didn’t get
early buy-in for fixing the problem from the business and from customers
Re-designing all existing software to deal with Y2K would cost money. Banks have a lot of software that was developed many years ago. I remember finding one UK bank that in 1999 was still running software based on using pounds, shillings and pence. Back
in 1971, when the UK decimalised, the bank left the changeover to the last minute and so stuck a quick-fix patch into all financial applications – a patch that converted decimal to £sd and back again. 28 years later, it still hadn’t got round to implementing
a permanent fix.
A key issue behind Y2K was that the IT department didn’t have earlier support from the business to get the problem fixed – the business didn’t budget and plan early for the change to be made. Y2K was 95% about technology and 5% about the business (the business
bit was that if you didn’t fix the technology it could blow up your business).
Euro implementation was not like Y2K – it was 90% business and 10% technology (the technology changes included converting all currency fields and implementing the “triangulation” rules). MiFID is not like Y2K – it’s 80% business and 20% technology.
But SEPA is very much like Y2K. The business didn’t want to pay to address a known problem earlier, and it’s been left till very late to address it. Without the support of the business in addressing the issue, IT’s hands are tied. And the business still
needs to get customer buy-in.