Zero is less that 99-it appears to be a simple truth. But where computerized date references are concerned, the statement's logic is thrown to the wind.
In older computer code, 00 can represent either the year 1900 or 2000, and rigging computers to make sense of this dichotomy could cost the financial services industry $21 billion between now and 2005.
Despite the seriousness of this issue, many top-level bankers still are not devoting full attention to fixing the so-called year-2000 programming glitch. Bank chief executive officers sound too comfortable about the issue, given that they have less than two years to make fixes.
What follows are some common management statements that need debunking:
"The fixes are pretty straightforward-just change the date field from two to four digits so that the year 2000 would be represented as 2000, not 00."
This is true for some systems. Those written in the last few years using modern programming tools, for example, could be fixed as simply as that.
However, banks still use a multitude of systems developed in the 1960s and 1970s, when both computer memory and disk storage were very expensive. These systems could require much more attention to fix.
"My data processing vendor is taking care of year 2000 for my bank."
Warning lights should be flashing brightly and frequently if you hear this statement. Even banks that use a single technology vendor will soon discover that many different products need attention. Every instance of data movement between systems must be examined to determine whether date problems exist.
One example is a download of data from a loan system to a spreadsheet. If the loan report is sorted in ascending maturity date order, the report on an unfixed system will sort loans with 2001 maturity dates before those with 1999 dates.
Will a single vendor examine the downloads and spreadsheet reports you've created over the years? Not a chance. Bank management is responsible for ensuring that these problems are examined and that a solution is thoroughly tested.
"There are only a few mission-critical applications that could cause damage."
Incorrect information created in one place can be transferred to other systems. The result is the failure of a mission-critical application caused by data from a source considered to be non-mission-critical.
"We put a plan in place, and I've assigned responsibility and accountability to my management information system executive."
Bank presidents and even board members are involved in large loan decisions made by a bank. One lending mistake has rarely caused a bank to fail, but year-2000 glitches could.
Your bank has only one chance with year 2000, and it cannot afford to delegate this responsibility.
"The regulators understand that our bank is working on this issue."
Despite a friendly regulatory environment, examiners may not be so nice about addressing the year-2000 glitch. The Federal Reserve and FDIC recently issued a cease-and-desist order to a Georgia bank because of its lack of planning for the year 2000.
One concrete statement from regulators on this point is that "program design and coding must be substantially complete and the bank must be testing the changes no later than Dec. 31, 1998."
Regulators are not going to take your word on this issue. They will be reviewing your bank to determine if you understand the problem, have identified all sources of problems, and have an implementation plan that is realistic.
"If all the pieces work, so will the sum of the pieces."
This statement is false for one simple reason: Systems need to share data and "talk" to one another.
To ensure that you have examined every possible trouble spot, you must create test scripts and expected results for each possible combination.
The number of components and combinations of interfaces make every single bank's year-2000 issues unique. Let's assume you have 20 different systems used by your bank. The possible number of combinations of flows of information between systems is 380. How many different systems does your bank use?
