|
Eugene Ludwig warned in his Sept. 25, 1997 remarks that the banking industry is still in denial. He made these remarks before a risk management seminar attended by bankers.
Note his word, "catastrophe." This is not typical bureaucratic language. Neither is this phrase: "For banks, Y2K poses challenges of unprecedented urgency and complexity."
* * * * * * * *
When I first heard about the Year 2000 problem several years ago, I did not give it much thought. In those years I would have dismissed as alarmist suggestions that Y2K represented a serious potential threat to the safety and soundness of the banking system and to the global economy. To the extent that Y2K was a problem, it looked to me like a problem that the technical wizards who developed computers could easily handle.
That initial skepticism was misplaced. The Y2K problem is, if anything, more serious than we had imagined. We ought to be listening to the experts who hold seminars with titles like, "If You're Sleeping Soundly At Night, Then You Don't Understand the Year 2000 Problem." Because too many of us don't. Too many of us are still in denial. Too many of us continue to nourish illusions that the solution is right around the corner. Or that the real impact of the problem will be limited to a handful of businesses particularly susceptible to it. Or that software vendors will take care of it. Or that we have plenty of time left to deal with it. . . .
Ultimately, however, the responsibility for averting catastrophe rests with you. The actions you take -- or do not take -- in response will determine the extent of the disruption that will occur on that momentous day. . . .
One way of illustrating the seriousness of the problem is to hark back to a not nearly so momentous calendar anomaly -- February 29, 1996. That was a leap year day -- the day when the world got the first small hint of how calendar-related computer problems could disrupt the marketplace. This case involved just one stray day, as opposed to a millennium. The vast majority of the world's systems did not miss a beat. And yet . . . . The Brussels stock exchange had to shut down for the day, at a cost of more than $1 million in commissions. An aluminum factory in New Zealand likewise lost a day's production, worth another $1 million. The Arizona state lottery commission could not pay out winnings. Countless smaller events did not make the headlines but still involved significant losses for the firms involved. And this, remember, was an event involving a single day for which everyone thought they were prepared. Time has become the enemy as we advance toward the millennium. For anyone who thinks otherwise, ask yourself when you last heard of the introduction of a new software application that did not require additional days or weeks or months beyond the original schedule. But the changes required to prepare for Year 2000 allow for no slippage. January 1, 2000 will wait for no one. The truth is that all the system changes will have to be in place at least a year before then, to allow the minimum time necessary for testing. Yet Y2K has been accurately described as "the project that cannot be late."
Indeed, some analysts say that it is already too late for those firms that have not already identified their needs and made provision for the technical assistance they need to implement and test the changes their systems require. I don't happen to agree with such fatalistic prognoses. But certainly the time is growing perilously short. . . .
For banks, Y2K poses challenges of unprecedented urgency and complexity. Because the banking industry was among the first to adopt computer automation, banks today may well have more applications running simultaneously than any sector of the economy. Some big banks run thousands of applications, some superimposed on top of one another. Many have millions of lines of code, which have to be read to find which ones need modification. And then they have to be tested for interoperability -- not only with each other, but with the countless external systems, foreign and domestic, with which banks daily interact. Many experts tell us that the testing process will be the most difficult part of the whole process, because the fix adopted for one system may not be compatible with the fix adopted for another. . . .
Let me make this absolutely clear: every bank must meet its timetable for compliance, whether data processing is performed in-house or by an external vendor. It is the bank's responsibility to monitor vendors' progress and to know their schedules for compliance. In the event that a vendor cannot meet established deadlines, the bank must exercise a contingency plan and secure those services elsewhere. The risks associated with non-compliance -- credit risk, operational risk, reputational risk, strategic risk -- will be borne by the bank, not the vendor.
|