Facing The Millennium
The Year 2000 is bringing some potentially serious problems for anything based on, using, or run by a computer. As a result of programmers thinking that 2000 was too far away to worry about, they decided to save space in computers by ignoring a few numbers in the dates they programmed. Back in the '60s and '70s this may have seemed reasonable. Then it became the way things were done. Recently, programmers started to think that soon they should do something about it. That "soon" is now.
In your next examination, your examiner will review your bank's process of preparing for the Year 2000. The Federal Financial Institutions Examination Council ("FFIEC") has developed and issued uniform examination procedures for the Year 2000. These will be used between now and the end of 1998 to assess the industry's preparedness and the status of each bank.
The FFIEC also published some guidance with the examination procedures. In addition to providing guidance for the specific project, the guidelines are applicable to many areas of compliance, and reveal what agencies expect in management commitment and staffing and resources for important compliance projects.
The agencies expect banks to work through a series of phases: Awareness, Assessment, Renovation, Validation, and Implementation. Each of these phases contains key steps or elements in Year 2000 readiness.
During the awareness phase, the bank should define the problem, gain executive level support, establish a team, and develop an overall strategy. Executive support and planning are key to this phase. It is important to begin this process with sufficient resources and commitment to do the job.
The assessment phase involves identification of everything that may be affected and what will be necessary to fix it. During this phase, it is important to think creatively and thoroughly. "Leave no computer chip unturned" should be the motto. Any computer function, from mainframe to chip, must be identified and evaluated. The FFIEC provides an extensive list, including ATMs, security systems, elevators, and vaults.
Also during the assessment phase, the bank should identify steps, procedures and time frames to resolve each problem. This includes testing corrective work. In fact, the traditional compliance regulations may provide a standard for this. Under Truth in Lending a creditor may be protected from liability if it relied in good faith on a calculation tool. However, that good faith reliance can only exist if the tool was tested - periodically. The creditor is not protected if it simply took a salesman's word for it. The same principle will apply here. The bank must test and establish to its own satisfaction that systems properly handle dates at the turn of the century.
Finally, the agencies expect banks to have contingency plans for responding to the unexpected. One change to correct may cause a problem in a different area. The bank should be prepared for this.
The renovation phase may include software and code changes, system replacements, or vendor changes. This is a good time to evaluate any vendors. Most important, remember that the bank is the customer. Never let the vendor tell you it can't be done, or its OK because that's the way other companies do it. Test it yourself, and hold out for what you need as the customer.
Validation is a process that should be familiar to anyone who has selected software, hardware, or compliance tools. Practices ranging from calculating APRs to developing credit scoring all require validation. The Year 2000 changes are no different. Every change identified in the assessment phase and worked on in the renovation phase must be tested in the validation phase. Testing should be rigorous and creative. Run lots of situations through the revised systems to make sure they work.
In addition to straightforward testing, you should test how systems interact. The FFIEC has raised concerns about vendor systems, interstate and international systems and information exchanges, and bank customer systems.
The bank's safety and soundness may be affected directly by its own systems. It may be adversely affected by failures of bank customers to comply with Year 2000. Therefore, in addition to reviewing and revising thebank's own systems, it is important to work with bank customers. A large commercial customer facing serious Year 2000 failures could put the bank at risk. This may be an area to provide service to bank customers. As long as the service - ranging from technical advice to education and training - includes support to small businesses and businesses located in low and moderate income areas, the effort should provide CRA credits.
ImplementationFinally, the implementation phase should put the work of several years to the test. And, it should be tested. You will want to implement Year 2000 changes well before the calendar changes. Throughout the implementation phase, the compliance program, including testing and re-evaluation, should be fully active. The compliance program itself forms a contingency plan by being ready to solve problems.The bank should establish a calendar that provides for each phase. Time allocations should be realistic. In fact, time schedules should allow for slippage and problems. This is, after all, an analysis and response to expected problems. Phases I and II, Awareness and Assessment, should be complete by September 30, 1997. Also by that date, the bank should set priorities. Testing of new or corrected systems should be "well underway" by December 31, 1998.
Copyright © 1997 Compliance Action. Originally appeared in Compliance Action, Vol. 2, No. 10, 8/97
First published on 08/01/1997