More On The Year 2000

The U.S. bank regulatory agencies are not the only ones concerned about the Year 2000. This is a major issue around the world. On September 8, 1997, the Basle Committee on Banking Supervision (a committee comprised of the central bank Governors of the Group of Ten countries: Belgium, Canada, France, Germany, Italy, Japan, Luxembourg, Netherlands, Sweden, Switzerland, United Kingdom, and United States) met and reviewed their priorities and concerns for the banking industry's preparedness for the Year 2000. The Group of Ten agreed that all participants in the financial markets should have their Year 2000 strategies and efforts well underway by this time.

The Group's paper includes some interesting observations on the nature and scope of the Year 2000 problem:
"Since the earliest days of electronic computers, programmers have used two digits to represent the year in date fields (YYMMDD). In the 1980s, few believed that applications being developed then would still be running in 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 significant risks."

The paper explains that the problem of identifying "00" in the year slot will cause programs to assume "1900" instead of "2000" unless the program logic is modified. The paper points out that limited time exists for converting systems and there can be no postponements because the century date is a "fixed reality." In fact, problems may begin on January 1, 1999 because the code "99" has been used in many software programs to indicate that a file should be saved forever or treated differently in some way. Small banks will need a plan for dealing with vendors, their equipment, and systems with embedded chips. The Group identified six key phases in an action plan for the Year 2000. The Group's action plan is familiar. It bears strong similarity to the recommendations of U.S. regulators. However, the action plan is followed by issues that have slightly more detail than the recommendations developed by U.S. bank regulators. It is therefore worth looking at for ideas and self assessment.

Action Plan
Develop a strategic approach. In other words, have an action plan that fits the bank and addresses the bank's known and possible problems.

Create organizational awareness. To be successful, the bank will need everyone's active and committed participation. This is a business objective that should be in the goals of every employee. The
Group's paper specifically identifies line management as essential participants and refers to line management developing "ownership" of the issue.
This phase has four objectives: creating visibility, ensuring commitment, identifying resources, and formulating specific strategic objectives at a business line level. The budgeting process is a vital point in establishing the Year 2000 project. The bank's success may depend on senior management's awareness of the issues and commitment to the solution. It will also depend on the commitment and participation of line management.
Assessing actions and developing detailed plans. In this phase, the bank should begin actions. The bank should develop detailed inventories of what must be done or developed. These inventories should cover centralized and decentralized hardware, software, and networks. They should also cover equipment that has computer chips or computer logic. In addition, the inventory should include all aspects of business line activities - both internal and external (such as commercial lending and commercial customer readiness for Year 2000).
The inventory should take into account the fact that some applications that do not appear to use dates actually do. For example, many operating systems use dates to play a role in file maintenance and performance. Thus, the review of inventory should be a top-to-bottom process. It might be useful to include a form or trial runs to flush out applications that use dates invisibly.
The inventory should also include hardware - particularly mainframes - that may have components from a variety of sources and periods. All ATMs and communication equipment should be checked and tested.

The Group points out that organizations should be past these three phases by this time.

Renovating systems, applications and equipment. This is the technical phase, where the computer experts and operations staff go to work. This is the "fix what has been found" phase. This work should already be well underway. The bank should also have contingency plans for things that go wrong or don't work.
Validating the renovation through testing. Hard as everyone has worked to get this far, testing may be the most important phase. Testing should be thorough and repetitive. Each application should be tested under different circumstances. For example, testing loan calculation software should be done using all types of loans, all types of date combinations (beginning in years 1998, 1999, 2000, and 2001) and using data imported from different systems. Plan what to test and set a schedule for testing.
The Group stresses that data flows, internally and from or through third parties, should be thoroughly tested. Both the sender and the receiver should simulate Year 2000 conditions. This test is critical. It is not enough to conduct an internal test, or accept the assurances of vendors. The flow of information must be tested. If your vendor doesn't want to do this, find a new vendor (or at least threaten to). This work should be completed no later than mid-1999, and that is running pretty late. Problems found in May or June, 1999 may be too late to fix.
Implementing tested, compliant systems. This phase is really the last chance to test. With the systems up and running, you have a last chance to identify any problems in interrelated applications. If you need examples of loans or deposits that haven't been made yet, make some up to use in future compliance training.

ACTION STEPS

Review your action plan. Compare it to the key steps and issues identified by the Group. Add steps that are not in your plan.
Evaluate the level of visibility in your program and audit procedures. Is the visibility as high as the Group recommends?
Is everyone involved who should be? Are your line managers involved in Year 2000? If not, get them in now.
Get your commercial lenders and customer relationship managers working with their customers to assess customer readiness for Year 2000.
Is someone responsible for security? It might be a good idea to designate someone whose primary responsibility is security rather than Year 2000. That way, their attention won't be derailed by problems in programming or the last minute rush.
Review all contracts with vendors. Better yet, have legal counsel review them. If the bank is not adequately protected, consider renegotiating contracts or inserting clauses that provide the bank with the ability to set standards and the necessary control over Year 2000 work.
If you are responsible for the Year 2000 budget, take a hard look at it. Is it adequate? Also, assume costs will go up over the next two years.
Begin planning now for the testing phase. This will take time - time when the bank's normal applications are not running. In fact, it means nights and weekends. Plan now to avoid the Christmas rush!

Year 2000 Issues

Certification of compliance
Banks should not rely on statements or certifications by vendors that their product is Year 2000 compliant. First, you are responsible for determining whether the product is actually compliant. This means testing to determine whether what the vendor represents is true. Second, and perhaps more important, is the possibility that the vendor's program may not run properly in the bank's environment. Banks should be testing all software and hardware in the ways they will be used to ensure that they function properly.
Vendors
Banks need to have a clear understanding of vendor's compliance plans. Most important, they need to hold their vendors accountable. It may be a good idea to review contracts with vendors to ensure that the bank has the contractual powers to ensure the vendor's compliance.
Target dates
These are critical. The Year 2000 is a massive project with as yet unidentified areas and absolutely no room for slippage. In particular, the Group recommends that banks coordinate schedules for testing with other parties - including vendors, correspondent banks and even customers. The Group notes that large, active customers should participate in the testing process.
Spillover business risk
This involves the bank's customers - and the bank's reliance on the economic health of those customers. The regulators acknowledge that, by and large, banks are working hard on Year 2000. However, their concerns are rising with regard to the customers of banks. Year 2000 can be a survival issue for customers. The Group is concerned that customer failures can lead to a loss of business and assets for the bank. For this reason, the Group strongly recommends that credit and relationship officers be aware of their customers' readiness, track their progress, and develop contingency plans should customers fail to become compliant.
Mergers and acquisitions
Year 2000 issues should be taken into account in merger activity, and in plans for mergers.
Satellite operations and foreign activities
A real concern in satellite operations is that there can exist departmental systems or applications that are not known about or reviewed and approved centrally. The Group observes that many of these applications are "essential risk monitoring and business decision tools." These must be identified, reviewed, corrected, and tested. This is an excellent example of why the Year 2000 team should include broad representation and participation throughout the bank.
Security issues
Security connotes safety, but will all of the components of the systems work when the Year 2000 comes? And what are the security systems on the programs and hardware you are reviewing? Turning security off and on for development and testing poses risk. The Group is concerned that the attention focused on Year 2000 will divert vigilance from security systems. But perhaps most important is the security check you should conduct on consultants and vendors. Working on calendar codes can take the programmer into the heart of your systems. Watch them closely.
Cost control
There are no choices about Year 2000. It is a project that must be done. Costs may fall on lines of business that did not anticipate or budget for the costs. If outside skills are needed, they may be expensive. For people with these skills, it's a seller's market. You can expect prices to go up as we get closer to 2000. And don't let cost concerns cause you to compromise on skills, integrity, or security.
Monitoring
Monitoring progress should be a top priority for every bank. The Group recommends that the bank clearly define the role of its auditors. Monitoring and findings should be visible at the bank's highest levels. The high stakes and tight schedule mandate close attention.
Potential systemic issues
Finally, the Group is concerned about the banking system as a whole. The existence of a single unprepared participant in the payments system may cause serious problems. Similar concerns exist with regard to credits. In particular, large banks should work to identify problems in payment chains and develop contingency plans for dealing with them.
Copyright © 1997 Compliance Action. Originally appeared in Compliance Action, Vol. 2, No. 14, 12/97