Chase Manhattan Corp. expects to spend about $250 million on year-2000 systems conversions.
Such conversions are aimed at averting computer disasters that would be caused in 2000 by code identifying years with two digits instead of four. The problem with such code is that 2000 is represented as 00, which some computers would misinterpret as 1900 and others would not be able to process at all.
Chase joins First Union Corp. as one of the few banking companies to estimate publicly the cost of fixing the code. (First Union has estimated costs of $42 million.)
But virtually all financial institutions will have to deal with the problem. Those that do not risk having systems make inaccurate interest rate calculations or seizing up altogether when the calendar turns to 2000.
Though the price tag Chase has put on its project may shock some, experts said similar announcements from other banks can be expected as more try to communicate their expected costs to the investment community.
Chase's announcement is "unusual this year because I don't think a lot of banks have focused on it enough to really have an estimate of what it is going to cost them," said Keith O. Newton, regional director of assurance services for Grant Thornton LLP.
Brian D. Robbins, vice president of enterprise information technology architectures at Chase and manager of its year-2000 program office, said the bank has 1,500 to 2,000 software applications and 150 million to 200 million lines of code.
In addition to examining and converting software components, the bank is looking at its data center equipment, desktop environments, and general facilities for possible year-2000 glitches.
The impact of the year-2000 project on the bank's budget "is going to be minimal in terms of incremental costs," Mr. Robbins said.
A significant amount of funding for the project will come from the existing information technology budget. The bank's motivation for disclosing the estimate is to show "that we understand the issue, we have it under control," Mr. Robbins said.
Chase hopes to create a competitive advantage by taking what it considers a lead position in managing this problem. All applications are expected to be compliant by the end of 1998.
The bank's project has three stages: assessment, construction and testing. Assessment, which involves taking an inventory of applications, is about 10% of the total effort. This will be completed by the end of the second quarter, Mr. Robbins said.
To help this part of the process, "we will use vendors and their tools because it makes it much quicker and minimizes the time to get the assessment done ... makes it more accurate," Mr. Robbins said.
During the assessment, Chase will decide how to correct the date problem in different applications. There are two primary fixes, Mr. Robbins said.
"It's either, you expand the year field from two digits to four digits or you put in logic around the two-digit date field that says if it falls within this range, which is usually called a window, then it's going to be 1900, and if it falls beyond that it's going to be 2000," he said.
Wherever possible, the bank intends to extend the date field because "it makes it cleaner, it makes it simpler, and it reduces risk," Mr. Robbins said.
Construction, actually repairing the applications, makes up about 30% of the year-2000 effort. This stage excludes fixing software bought from third-party vendors.
Testing is expected to make up 60% of the effort. In addition to testing individual applications, Chase intends to test entire systems to insure that programs meant to work together actually do.
