4. The Year 2000 is particularly challenging because it is not just internal to a bank. Banks have many automated linkages and interdependencies with correspondents and customers. For larger banks that deal in multiple currencies and provide wide ranges of products in many countries around the world, the challenge is particularly great because many of these applications are interdependent. If applications are not able to work together properly, significant problems could develop. All of these interdependencies must be addressed and tested to assure that problems are not present. Similarly, banks rely on third party service providers or vendors for many applications. These applications not only need to be made compliant but also must be thoroughly tested within each bank to assure that they perform properly for the particular environment and application interfaces found in each institution.

5. Complicating the resolution of the Year 2000 issue on a global basis are the differing situations found in many markets and countries around the world. The scheduled introduction of the Euro is placing significant competing demands on scarce technical resources for institutions active in that market. Other new or modified financial trading or delivery systems are being introduced in other markets. In some countries, other policy or business objectives may divert technical resources from the financial sector. Even within the financial sector, there are differing priorities for banks, securities firms, and insurance companies. These and other factors lead to widely varying amounts of attention being devoted to Year 2000 issues by individual institutions.

6. Since the earliest days of electronic computers, programmers have used two digits to represent the year in date fields (YYMMDD). In the 1960s when this convention became standard, the two-digit representation made economic sense because it economised computer memory and saved storage space. Even in the 1980s, few believed that applications being developed then would still be running into the year 2000. Unfortunately, this belief was ill founded. While many newer applications are Year 2000 compliant, many older applications upon which compliant applications depend or interact continue to run. In addition, the environmental software and hardware on which an application runs may not be compliant. Assuming that any application is Year 2000 compliant without appropriate analysis and testing poses substantial risks.

7. The Year 2000 problem exists because a two-digit representation of the year will be interpreted in many applications to mean the year 1900, not 2000, unless the date or program logic is modified. Many calculations will either indicate that transactions have been open for nearly a hundred years or produce negative numbers. New files may not be recognised as the most recent data, causing current files to be erased or archived as old data. These and other logic issues have the potential for causing problems for debt collection, ageing of information, calculating interest rates, etc. and could significantly disrupt normal business operations. Also, when dates are compared, customer billings may change from charges to refunds and vice versa. Even building systems such as elevators or climate control systems may be affected because of embedded logic to facilitate maintenance and operations.

8. All of these factors make the Year 2000 a formidable challenge. Whether the banking industry has the ability to rise to this challenge and avoid serious problems as the date change occurs will be determined by the actions that individual banks and the banking community more generally take between now and the Year 2000. To delay work on the issue runs the risk that all of the code modifications, testing and other changes cannot be done in a timely manner. Unlike most projects involving technology, the time certain nature of 1999 becoming 2000 makes it impossible to delay the event and full implementation of corrective actions.