TO ALL FEDERALLY INSURED CREDIT UNIONS:

SUBJECT: Year 2000 Conversion

Virtually every financial institution relies on computers, either their own or a servicer's, to provide for processing and updating of records and a variety of other functions. Most institutions cannot survive without the use of computers. Because of this, all institutions are vulnerable to problems associated with the Year 2000.

All levels of management, including the Board of Directors, must understand the implications of this problem; specifically, the fact that all computer systems will be affected; the cost of the solution may be significant; and, because the deadline for compliance is an immovable date and fully implementing solutions may take years, management cannot delay action.

Many computer systems and programs may not be currently designed to handle the Year 2000 for a variety of reasons. The core problem is that a majority of the systems in use today have a two-digit field for the year. When the Year 2000 comes, the date will be reflected as "00", but many systems will mistake that for the year 1900, leading to numerous problems when calculations requiring the use of dates are performed such as:

• calculating interest;

• calculating truth-in-lending or truth-in-savings disclosures;

• determining a person's age; and

• determining amortization schedules.

Automated Teller Machines (ATMs) may also assume all cards are expired due to this problem. Errors caused by these miscalculations may also expose institutions and data centers to financial liability and risk of damage to customer confidence in the institution. If computer systems are not made Year 2000 compliant, systems and programs may fail.

For an institution or data center to prepare for the Year 2000, several steps must be taken. The hardware and software used by the institution and/or its servicers must be analyzed for compliance. Any system with a date function built into it may need to be made Year 2000 compliant either by being replaced or reprogrammed. If there are deficiencies, new software, and possibly hardware, which is compliant, will have to be identified and purchased in time for records to be converted; or massive reprogramming of existing software may be necessary. Due to the complexity of the issue, both options will be expensive and, in some cases, cost millions of dollars. Institutions and data centers that have begun to research how to address this issue are finding that the solution will take several years to define, test, and fully implement.

The Year 2000 problem is not limited to one type of software or hardware, critical or non-critical. Examples of affected critical systems include mainframes, personal computers (PCs), and networks. Other critical systems which could be affected include:

• telephones and PBX systems;

• audio voice systems;

• elevators;

• security systems (badge readers, surveillance systems, parking lot gates, vaults);

• time dependent controls (parking lot lighting, programmable thermostats);

• power management functions (heating/air conditioning controls, uninterruptable power supply systems, building lighting systems); and

• environmental safety systems.

Examples of non-critical systems that could be affected include:

• fax machines;

• electronic time clocks;

• vending machines; and

• landscaping systems.

In researching acceptable solutions, institutions and data centers will need to bear in mind the interrelationships between the various software systems they use, as well as any data received from or provided to outside sources, such as Automated Clearing Houses (ACH) or payroll servicers. Data from outside sources not compliant with the Year 2000 may corrupt an institution's or data center's files causing disruption in the institution or data center's ability to process transactions. Alternatively, institution data or files not compliant which are sent to outside sources may corrupt those outside sources leaving the institution with potential liability for any incurred losses.

The ability to adequately manage the time left to deal with the situation is critical. There are a finite number of companies and individuals capable of reprogramming existing systems. The longer institutions and data centers wait, the fewer of these companies or individuals will be available to assist them and the higher the price will be.

Institutions and data centers which purchase their software need to take a proactive approach to this situation. They cannot assume their software vendors are adequately addressing the problem. Situations have already arisen where institutions have contacted vendors and been informed that software products currently being used are not Year 2000 compliant, and the vendor does not intend to make them compliant.

It is imperative that management take an aggressive and proactive approach to this problem in order to meet the deadline. Institutions and data centers should inquire specifically as to what plans the outside software vendors have made and/or implemented to make their software compliant. Time frames should allow for any reprogramming to be accomplished, and full testing done, well before December 31, 1999. Institutions and data centers which do in-house programming of their software must make an assessment of the costs and time involved immediately so that reprogramming can be completed and fully tested well before December 31, 1999.

Institutions lacking the expertise to address this problem should seek help from outside resources such as trade organizations, EDP auditing firms, and Year 2000 resource firms.

To assist credit unions in this endeavor, we sent the enclosed letter to the major credit union vendors (listed in the attachment) inquiring about their Year 2000 compliance status. If your vendor is not on the list, we ask that you forward their company name, address, and contact person (if available) to: National Credit Union Administration, Examination & Insurance, 1775 Duke Street, Alexandria, VA 22314-3428. If you have access to the Internet, you may send this information to: eisupv@ncua.gov. We ask that you send this information by one method only. Periodically, we will make the vendor information available to assist you in obtaining knowledge of your vendor's status.

We have also enclosed an Appendix which discusses in more depth the complexity of the problem and viable solutions. Your examiner will be inquiring about your readiness and ability to handle the Year 2000 problem. Those credit unions not in compliance should expect to reach formal agreements with their examiner to ensure compliance by December 31, 1999.

If you have any questions, please contact your regional office or your state supervisory authority.

Sincerely,

/S/

Norman E. D'Amours

Chairman

EI

PROBLEM

Many computer systems may not recognize or process information with dates beyond December 31, 1999. Unless corrected, beginning January 1, 2000 computer systems worldwide will begin to fail and/or produce incorrect information. This issue is not just limited to financial institutions. It is pervasive among all computer systems including both government and private sectors. Also, the problem is not limited to large mainframe computers. Smaller computer systems, including local area networks (LANs) and personal computers (PCs), may be affected. Unless corrected, the Year 2000 problem could have a substantially negative effect on the financial institution industry worldwide.

Systems that use a YYMMDD format (year, month, day) to record dates will generally recognize the year 00 as 1900 rather than 2000 since they have no provision to reflect a century. Note that the year field contains only two positions; therefore, the YYMMDD date of 970704 translates to July 4, 1997. Computers which use the YYMMDD format automatically assume the century to be 19 (hence 1997). After the new millennium arrives, these computers would record July 4, 2000 as 000704 and interpret this date to be July 4, 1900. However, in some cases these systems may actually default to another year, such as 1980 (the beginning of time for PCs), 1984 (the beginning of time for DOS systems), or some other incorrect date.

Correction of Year 2000 problems will, in many cases, require a file conversion. Some institutions and data centers will not have available sufficient disk space or time to perform the conversion and run parallel to the old system for a period of time to ensure that all problems have been resolved.

If institutions do not have their converted systems in place by December 31, 1998, they may not have enough time to fully test and debug those systems by December 31, 1999. Also, as time passes valuable Year 2000 resources may become more scarce and/or costly thereby preventing the conversion of systems in time to meet the deadline.

SOLUTIONS

The Year 2000 problem has three basic software solutions:

• Rewrite: This solution requires re-coding date calculations where necessary with a four-position year field. The re-coding not only involves changing the program source code, but also changing the screen displays. This is a permanent solution but probably the most costly.

• Renovate: This solution calculates the date using a technique called "windowing." As an example of this technique, two position year fields greater than 50 are assumed to be in the 20th century. Those date fields that are less than 50 are assumed to be in the 21st century. Not every windowing technique, however, will use the same assumptions. This is not a permanent solution but will buy time in some situations for institutions unable to develop a permanent solution before the deadline.

• Replace: This solution may be the quickest approach, but also could be extremely expensive. Institutions that elect this approach must ensure that the new systems they purchase are Year 2000 compliant. Another benefit to the replacement approach is that it provides the opportunity for institutions to upgrade their aging systems. Of course, institutions may also take an approach that incorporates any, or all three, of the basic software solutions. Institutions must make this decision based upon their current systems, needs, and time available to accomplish the conversion.

The Year 2000 problem has two basic hardware solutions: upgrade or replace. In those institutions where the hardware is relatively old, replacement will most likely be a less costly approach than an upgrade. However, institutions must ensure that the upgraded equipment will interface with both existing software applications and hardware configurations.

Whatever solution an institution selects, it must also ensure that the solution addresses two basic components. First, financial institutions and other organizations must solve this problem with respect to their own internal systems. That is, assuring that their internal computer systems properly handle date-dependent transactions and computations in the new millennium. Second, financial institutions and other organizations (corporations, governments, and payment systems both domestically and internationally) must assure that they can exchange date-dependent information effectively and efficiently. Standards are necessary to facilitate this exchange of information for payment systems and general commerce. The National Institute of Standards and Technology (NIST) in FIPS Pub 4-1, dated March 25, 1996, recommends the use of a four-digit year element with a contiguous two-digit century element (e.g., 1999, 2000, etc.).

Over the next two and half years, the financial institutions industry will expend significant resources to address Year 2000 issues. Some experts predict that it may be one of the largest project management efforts the financial institutions industry has undertaken.

Most computer industry participants agree that the process firms will use to manage the Year 2000 efforts consists of the following basic phases:

• Awareness: Management at all levels must become fully aware of the Year 2000 issue and its impact on the institution and customers. Management must:

• define and explain the importance of achieving Year 2000 compliance;
• select an overall approach for structuring the institution's Year 2000 program;
• assess the adequacy of the existing information resource management infrastructures to support the Year 2000 effort; and
• mobilize resources, including the establishment of a Year 2000 committee.

• Assessment: The institution must assess the impact of the Year 2000 on both hardware and software systems. This process of identifying and ranking information systems should not be limited to a simple inventory of applications and platforms, but must also include assessment of the impact of information system failures on the institution's operations and processes. Institutions must also consider whether there are enough resources, skill, or time to convert or replace all of the affected systems. Therefore, institutions must determine which systems:

• are mission critical and must be converted or replaced;
• which systems support important functions and should be converted or replaced; and
• which systems support marginal functions and may be converted or replaced at a later date.

• Renovation: The renovation phase addresses the conversion, replacement, or elimination of the institution's various systems. Renovation either involves:

• conversion of an existing software/hardware system;
• replacement and/or development of a new software/hardware system; or
• elimination of an existing unneeded software/hardware system.

In all three of the above cases, the process must consider the complex interdependencies among applications, hardware platforms, databases, and any internal and external interfaces. This phase requires a high degree of coordination and adequate documentation due to the interdependencies of the various systems.

• Validation and Testing: The validation and testing phase may consume over half of the Year 2000 program resources and budget. The actual length of this process is directly related to the number of systems impacted and their complexity. Computer industry representatives anticipate that this phase will be the most difficult step comprising at least 50 percent of the project's time. As part of this phase, institutions will have to validate and test the interactions between the various platforms, operating systems, utilities, applications, databases, and interfaces. All converted or replaced systems must be fully tested to:

• uncover errors introduced during the renovation phase;
• validate Year 2000 compliance; and
• verify operational readiness.

• Implementation: Once converted or replaced and subsequently tested, Year 2000 compliant applications and system components must be implemented. Since not all systems will be converted or replaced simultaneously, institutions should expect to operate in a computing environment of compliant and non-compliant systems. The reintegration of the Year 2000 compliant systems in the production environment must be carefully coordinated to account for system interdependencies. Institutions will also need to consider parallel processing (running the old and converted systems concurrently) to ensure accuracy and reduce risk.

RISKS

Financial institutions are a technology sensitive industry. Nearly every aspect of the industry is automated and depends on computer systems for processing transactions and providing management information. If the computer systems financial institutions rely on cannot handle processing of transactions in the new millennium and/or their systems produce inaccurate information, financial institutions face the potential of failure.

There is an additional complication. Industry customers, vendors, and payment system partners must be able to handle Year 2000 date changes. There is thus the potential for a cascading effect from a payment system, network provider, major customer(s), or information processing vendors. Accordingly, financial institutions must develop comprehensive solutions to this problem and prevent unintentional consequences from affecting their systems and the systems of others.

A tremendous interrelationship exists between payment systems at the local, national, and international levels. Financial institutions must be able to exchange clearings at the local level, send and receive automated clearing house (ACH) transactions and clear checks at the national level, and send and receive wire transfers at the international level. All these systems are interdependent. And, loss sharing arrangements are in effect in case of any type of settlement failures.

The payment systems affected include CHIPS, SWIFT, Fedwire, Automated Clearing Houses, MasterCard, VISA, regional and national ATM switches, and Electronic Benefits Transfer (EBT) systems. In addition, beginning January 1, 1999, all transactions with the U.S. Government must be via ACH. These systems must be able to handle Year 2000 processing and communicate with each other to facilitate normal banking and commerce. Accordingly, financial institutions must make certain that their solution is consistent with their business and payment systems partners.

OTHER IMPLICATIONS

These Year 2000 issues will absorb resources and management's attention that would otherwise focus on other business issues. Solving the Year 2000 problem will generally not add value to the financial institution. Nor will it likely improve earnings or capital, provide new revenue sources, or reduce expenses. In addition, any new products and services must be Year 2000 compliant. Accordingly, financial institutions have to fix their old systems and develop new systems concurrently. Solving this problem will likely strain the financial institution's resources, yet it is absolutely necessary.

«FNAME» «LNAME», «TITLE»
«VENDOR_NAME»
«ADDRESS»
«CITY», «ST» «ZIP»

Dear «Surname» «LNAME»:

As you are probably aware, the Year 2000 concern is becoming a forefront issue. We are taking an active role in determining Year 2000 compliance in federally insured credit unions. We plan to assess the Year 2000 compliance status of every federal credit union by the end of this year and have a goal of achieving compliance by the end of 1998. We want to work with you and your credit union customers in a joint effort to ensure that credit unions are capable of transitioning into the new millennium. Consequently, our examiners will be discussing these issues with credit unions. We anticipate that your credit union customers will be contacting you about your systems' Year 2000 compliance status.

Specifically, we are interested in the following:

1. Your overall Year 2000 plan(s):
   1. explanation of the process;
   2. where you are in the process;
   3. how testing will be, or has been, accomplished;
   4. whether your plan requires compliance certification from an independent third party for each system/application you offer; and
   5. how you plan to share your systems' compliance status with your customers.

1. Year 2000 compliance information for each of your credit union systems as well as their current compliance status.

1. Any plans you have in place for Year 2000 customer support such as:
   1. how to determine if their systems are compliant;
   2. what they should do if their systems are not compliant; and
   3. whether there is an upgrade (if required) to their existing system.

1. The name of a contact person in your company who we may communicate with directly.

We would like to coordinate the dissemination of information concerning the status of your various programs/products/systems. We believe this would reduce the burden on credit unions and their vendors. We propose to share this information with our examiners, credit unions, and various state and federal agencies. By sharing this information, we will be able to educate our examiners on which systems are Year 2000 compliant thereby reducing the number of contacts and inquiries you may receive from your customers.

To accomplish this task, we ask that you complete the attached Systems Information Questionnaire for each credit union application program/system you offer. We also ask that you return the questionnaire to our office by May 30, 1997.

We would also be interested in holding a vendor's meeting in our central office (Alexandria, VA) to discuss Year 2000 issues and vendor concerns; specifically those that relate to credit unions and their systems. We would like to target a June or July 1997 date for the meeting. If you are interested in attending, please let us know.

If you have any questions, please do not hesitate to contact Roger Blake in our office at 703-518-6360.

Sincerely,

David M. Marquis
Director, Examination & Insurance

EI/RAB:rab
SSIC #13200

cc: Executive Director
Director of OTIS
NASCUS Representative

1. Name of your company: _____________________________________________

1. Name of Program/Application: ________________________________________

1. Version # (or other identifying product number): __________________________

1. Is this version fully Year 2000 compliant? _____Yes _____No

1. If yes, has this version been certified compliant by
   an independent third party? _____Yes _____No

1. If no, do you plan to have this version certified? _____Yes _____No

1. If no, do you plan to make this version compliant? _____Yes _____No

1. If yes, when do you expect to complete the process for this version?

______________________________________________________

1. If no, what action, if any, do you intend to initiate for customers with the non-compliant version?

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

Please return this questionnaire to:

National Credit Union Administration
Examination and Insurance
1775 Duke Street
Alexandria, VA 22314-3428

Americam Business Computers Inc.
3930 E. Apple Ave.
Muskegon, MI

AMI, Inc.
P.O. Box 167
Franksville, WI

Benchmark
17500 West Liberty Lane
New Berlin, WI

Benchmark Systems
P.O. Box 787
Mechanicsville, VA

Brick and Associates
2875 Northwind Drive, Suite 230
East Lansing, MI

C.U. Processing, Inc.
26200 Lahser Rd. Suite 100
Southfield, MI

CMC
2450 East 70 South
Salt Lake City, UT

CompuSource Systems, Inc.
3820 Ridge Lea Road
Amherst, NY

Computer Consultants Corp.
47 W 2nd St, Suite 200
Salt Lake City, UT

Credit Union National Association
P.O. Box 431
Madison, WI

CU Technology
151 Kalmus Drive - Suite F1
Costa Mesa, CA

CUSA, Inc.
969 E. 4800 South
Salt Lake City, UT

Datamatic
5545 Enterprise Drive
Lansing, MI

EDS Credit Union Services
2600 Technology Drive
Orlando, FL

EDS Credit Union Services
5400 Legacy Drive
Plano, TX

EDS Newtrend
2600 Technology Drive
Orlando, FL

EPL, Inc.
1225 Fifth Avenue North
Birmingham, AL

FedComp
7115 Leesburg Pike, Suite 200
Falls Church, VA

FIserv
P.O. Box 979
Brookfield, WI

FIserv
707 West Algonquin Road
Arlington Heights, IL

FIserv - Spokane
P.O Box 597
Spokane, WA

FIserv - Summit Information Systems
850 Southwest 35th Street
Corvallis, OR

FIserv / ADOL
6995 Tico Road
Titusville, FL

Fiserv / Minneapolis
5249 West 73rd Street
Edina, MN

FIserv Flint
3031 Airpark Drive North
Flint, MI

FIserv Galaxy 2000 CU Systems
5600 Crooks Road, Suite 101
Troy,MI

FiTECH Systems
3098 Piedmont Road, Suite 400
Atlanta, GA

Helvetya Delcaribe
P.O. Box 5174
Carolina, PR

IDC Financial Publishing, Inc.
PO Box 140
Hartland, WI

Innovative Technology, Inc.
4203 South 120th Street
Omaha, NE

Integrated Business Systems, Inc.
2205 West Wabash Ave., Suite 201
Springfield, IL

International Software Systems (ISS)
8101 College Blvd. Suite 290
Overland Park, KS

IPS, Inc.
14040 North Cave Creek, Suite 100
Phoenix, AR

Maine Credit Union League
P.O. Box 1236
Portland, ME

Modern Computer Systems
12224 Nicollet Avenue, South
Burnsville, MN

National Assoc. of Federal Credit Unions
3138 N. 10th Street, Suite 300
Arlington, VA

NCS
1250 East 223rd Street, Suite 119
Carson, CA

Pearless Systems
1212 East Arapahoe
Richardson, TX

Premier Systems, Inc.
P.O. Box 10361 - 1600 36th Street
West Des Moines, IA

ProfitStar, Inc.
11128 John Galt Blvd., Suite 350
Omaha, NE

re:Member Data Services
8900 Keystone Crossing Suite 1100
Indianapolis, IN

Share 1 Systems
2750 Colony Park Drive, Suite 10
Memphis, TN

Sheshunoff
505 Barton Springs Road, Suite 100
Austin, TX

SOS Computer Systems, Inc.
720 East Timpanogos Parkway
Orem, UT

Sunbelt Computer Systems, Inc.
223 Main Street
Fort Mill, SC

Symitar
5151 Murphy Canyon Road
San Diego, CA

Syntropy Inc.
P.O. Box 2215
Durango, CO

Systronics
9655 Lackman
Lenexa, KS

Total/1 Credit Union Services
1815 Coral
Houston, TX

Ultradata
5020 Franklin Drive
Pleasanton, CA

Users, Inc.
1250 Drummers Lane
Valley Forge, PA

WESCO
4695 44th Street Suite 180
Kentwood , MI

Western New York Computing Systems
2136 Five Mile Line Road
Penfield, NY

XP Systems
301 Science Dr.
Moorpark, CA