Year 2000 Bridge Programs and Interfacing

Credit union data processing systems may consist of several individual programs that routinely share information and interface to process transactions and perform tasks. Each program individually must be able to process Year 2000 transactions at the turn of the century. It is equally important to ensure that these individual programs continue to work together, or interface, when processing Year 2000 transactions. Since there are several methods for making individual programs Year 2000 compliant (for example, date expansion, windowing (fixed or sliding), compression, etc.) credit unions are responsible for ensuring that the various individual programs, once compliant, continue to communicate as a whole, integrated system.

For years, most computer programs have used two digits to identify the year. A primary concern at the turn of the century is that computer programs will interpret “00” as the year 1900 rather than the year 2000. Programmers can use “date expansion”, “windowing”, “compression” or other techniques to correct this problem. A description of each is as follows:

1. Date Expansion - The date expansion approach requires re-coding dates with a four-digit year field, expanding the year field from 2 to 4 digits. This method would require changes to the source code and stored values, including historical data. This method, although considered a true fix, would take the most amount of time and resources to implement.
2. Windowing - The windowing technique uses an internal computer logic approach for interpreting dates. Based upon the 2 digit year, this approach assigns a century value (19 or 20) to the year value. As an example of this technique, two-digit year fields greater than 50 (pivot or base year) represent years in the 20th century – i.e., 84 refers to 1984; while two-digit year fields that are less than 50 represent years in the 21st century – i.e., 12 stands for the year 2012. Since there are no standards, 2 the pivot year can be any number the vendor selects. To compound this problem further, the window technique may be a fixed or sliding (the pivot year moves) window. A fixed window is one in which the pivot year, once assigned, does not change. A sliding window is one in which the pivot year will move forward 1 year for each year that passes. For example, assume an initial pivot year of 35 and starting date of January 1, 1998; the pivot years are calculated as follows:

   Pivot years

   Date	Fixed Window Pivot Year	Sliding Window Pivot Year
   January 1, 1998	35	35
   January 1, 1999	35	36
   January 1, 2000	35	37

3. Compression - The compression (sometimes called encoding) technique is an internal computer logic approach which may use an algorithm or formula to compress numbers into a tighter space than is needed to hold “human readable” values. This method expresses numbers in a form that is understandable by the software, but not easily understandable by the average person. Another method of the compression technique is to use an alphanumeric character to represent the century. For example, “A” may represent 1900 and “B” may represent 2000. Therefore, in this example, A97 would translate to 1997 and B25 would translate to 2025. As a final note, the compression technique would require date fields to be converted from a “date format” to another format (such as alphanumeric).

As individual programs used by credit unions’ systems become compliant, credit union officials must address the following concerns:

• A four-digit program may not be able to communicate with a two-digit program. For example, if a credit union’s mainframe uses a four-digit fix while a software vendor uses a windowing technique (2 digit fix), the credit union’s “integrated” system may fail to process Year 2000 transactions correctly.
• Since not every windowing technique uses the same pivot year for interpreting the century, programs renovated by this technique may be unable to communicate with each other. For example, assume a fixed window with a pivot year of 40 and a sliding window with a pivot year of 35, the following table demonstrates how to calculate the century for both methods:

  Fixed Pivot Year=40 Century Value

  How to calculate the century for both methods

  Date	2 Digit Year	Pivot Year	Century Value
  January 1, 1998	34	40	20 (2034)
  January 1, 1999	37	40	20 (2037)
  January 1, 2000	41	40	19 (1941)
  January 1, 2006	42	40	19 (1942)

  Sliding Pivot Year=35 Century Value

  How to calculate the century for both methods

  Date	2 Digit Year	Pivot Year	Century Value
  January 1, 1998	34	40	20 (2034)
  January 1, 1999	37	40	19 (1937)
  January 1, 2000	41	40	19 (1941)
  January 1, 2006	42	40	20 (2043)

  Italicized rows indicate where the two different methods result in different century results.

• Italicized rows indicate where the two different methods result in different century results.
• Depending on the type of fix, individual programs which are Year 2000 compliant may be unable to interpret or share credit union data with other compliant programs which were fixed using a different, albeit acceptable fix.
• Information or data provided by external sources must also continue to work with credit union systems. Examples of these external sources are credit card companies, ATM networks, ACH, Fedwire, Web pages (home banking), or other electronic data processing services.

Credit unions are responsible for testing compliant programs and for determining if these programs work as a whole. If these renovated programs are unable to work together, credit unions must find a solution. A solution for allowing non-compatible programs to communicate consists of building and installing bridges (also called interfaces). Bridges are conversion programs that create files in a format needed for destination programs to function. In other words, these programs allow a system that uses date expansion to solve the Year 2000 problem to talk to, and work with, a system that uses windowing to solve the Year 2000 problem. Since credit unions are ultimately responsible for ensuring that their systems operate as a whole, we expect credit union officials to coordinate the installation of bridges to allow communication between renovated programs.

The following diagram illustrates the flow between internal and external programs. As indicated by the arrows, programs based on different fixes for the Year 2000 must be able to exchange and process data as a whole.

In the illustration, if System A represents a credit union’s general ledger, System B runs their share and loan program, and System C processes wire transfers, officials will have to install the necessary bridges for the individual systems to communicate and share data correctly.

It is essential for credit union officials to identify and document the method used to fix each non-compliant program or system -- date expansion, windowing, compression, or other. If using a windowing approach, it is also necessary to identify the pivot year of each program using this technique and whether the window is fixed or sliding. When using the compression method, officials must determine the algorithm used.

Another concern management must address is building temporary bridges between systems that have been renovated, and are ready for testing, and those systems which have not been renovated or may not need renovation. These temporary bridges will allow the credit union to begin testing those systems which they believe are ready for testing, even though their entire computing environment may not yet be renovated.

Ultimately, credit union officials must identify the bridges needed to allow programs with different fixes to operate together. After installing these bridges, it is necessary to test the processing of all types of transactions to ensure that the system, as a whole, operates and shares data in a Year 2000 compliant manner, both internally and externally.
If you have any questions, please contact your examiner, regional office, or state supervisory authority, for state credit unions.