March 9, 1998

Summary: This letter advises lenders in the Federal Family Education Loan (FFEL) Program of the potential impact of the "year 2000" problem and the importance of an aggressive approach to ensure that the FFEL program will continue unimpaired.

Dear Colleague:

The purpose of this letter is to reinforce the importance of your efforts to address data systems issues pertaining to the Year 2000 ("Y2K"). Your data systems should be able to correctly identify, manipulate, and calculate dates outside of the 1900-1999 year range. Unfortunately, few systems currently in use were designed with the ability to process dates later than 1999.

We encourage you to make certain that you have taken appropriate steps to ensure the continued functioning of the FFEL Program in light of Year 2000 information systems challenges. To avoid the potential of serious processing errors and disruption to FFEL access and accountability, it is vitally important that all of your data systems, procedures, and data exchanges be able to handle the upcoming change in the century. If you have not already done so, you should develop an aggressive strategy and action plan for

addressing this issue.

The attachment to this letter presents a general overview of how the Department will be dealing with the Y2K problem, and what we expect you will do to be Y2K-compliant. We expect that you will ensure Y2K compliance by having a plan comparable to the one outlined under the "DEPARTMENT'S Y2K Plan" heading in the attachment. Additionally, you should take appropriate steps to ensure that the organizations you interact with, such as guaranty agencies, loan servicers, and contractors, are taking similar actions, and are using similar milestones, to prepare their systems and validate that their data exchanges are Y2K-compliant. [Note: We recently sent "Dear Colleague" letter 98-G-306 to all guaranty agencies about this issue.]

Thank you in advance for your assistance in this important matter. If you have questions, please contact the Department's Guarantor and

Lender Oversight Service at (202) 401-2280 immediately.

Sincerely,

Diane Rogers
Acting Deputy Assistant Secretary
Student Financial Assistance Programs

Attachment

Overview

The Federal Acquisition Regulations at 48 C.F.R. Part 39 define Year 2000 compliance to mean information technology that accurately processes date/time data (including, but not limited to, calculating, comparing, and sequencing) from, into, and between the twentieth and twenty-first centuries, and the years 1999 and 2000, and leap year calculations. Further, Year 2000-compliant information technology, when used in combination with other information technology, must accurately process date/time data if the other information technology properly exchanges date/time data with it. Year 2000 information technology must accurately process date and time data. This means that systems must be able to store, process, and report date data in ways that differentiate between years prior to 2000 and Year 2000 and beyond. This issue is critical because many computer systems were not originally designed to accommodate a four-digit year; instead, they store and process date data using just the last two digits of the year (i.e., 1989 = 89). Such conventions are no longer sufficient as we move toward the new century. All data sent to and from FFEL participants and the Department of Education must include four digits whenever a data item is a year. In fact, current record descriptions in the EDExpress software, National Student Loan Data System (NSLDS), and Student Status Confirmation Report (SSCR) processing already require four digits for the year. Other systems will soon require the four-digit year.

Some data already being transmitted to the Department of Education from students, institutions, and FFEL participants contain dates that go beyond 1999. For example, the Free Application for Federal Student Aid (FAFSA) asks applicants for the date they expect to complete their academic program. Similarly, student loan applications require the submission of the borrower's anticipated graduation or completion date. Program completion dates are also sent from institutions to NSLDS in the SSCR and other enrollment tracking processes.

Complexity of the Problem

To emphasize that this problem is not always corrected easily, consider an organization that stores date information using only the last two digits of the year. It would use, for example, "77" to store a student's date of birth of 1977. The organization might decide that since the data record it receives from another party requires all four digits of the year, it will simply place "19" in the first two places and "77" in the last two. This process might work for an item like date of birth (at least for the next several years) because it would result in 1977 being correctly reported as the student's date of birth.

However, this same convention would not work when the date being asked for was the student's anticipated graduation date. In this instance, if the student was scheduled to complete the academic program in 2003, the organization would have stored "03" in its system. The data system would place the "19" in the first two places and erroneously report the student's anticipated graduation date as 1903 instead of 2003.

Systems Disruptions

Perhaps the most serious result of a data system not being able to handle the changeover to a new century is that the software in that data system (or a subsequent system that received corrupted data) would simply not execute. While, in some ways, this result might seem preferable to the creation of bad data, it is an occurrence that should be avoided at all costs. No FFEL participant should cause misreported data or loan access problems because its systems are unable to deal with the Year 2000.

Vendor Supplied Software and Third Party Servicers

If you use either vendor supplied software or the services of a third party servicer for any portion of FFEL processing, you must ensure that the products and services you obtain from those organizations will be able to store, process, and report date data in ways that differentiate between years prior to 2000, and Year 2000 and beyond. Remember, FFEL participants are responsible for compliance with all laws, regulations, and policies relating to the FFEL Program. The fact that a third party (e.g., a contractor, vendor, or servicer) made an error is not an acceptable excuse for non-compliance. We recommend that you contact the organizations you deal with if you have questions regarding the Year 2000 capabilities of any products or services you obtain from those parties.

What the Department Is Doing

We have created a Web site at www.ed.gov/y2k/ to provide regularly updated information on the Department's efforts to avoid Year 2000 data problems. If you have questions regarding Year 2000 issues that may affect your interactions with the Department, you may e-mail your inquiries to our Program Systems Service staff at: ope_y2k@ed.gov

The Department is in the process of ensuring that all of its computer systems and the interface between them and the systems of our trading partners are Year 2000 compliant. As part of this process, we must be certain that the FFEL Program will not be disrupted because of Y2K problems. The Department takes the Year 2000 issue very seriously. We intend to be aggressively proactive in ensuring that all Title IV participants are fully "Year 2000 compliant." The interests of students, parents, schools, and others (including the federal taxpayer) mandate that we not wait until January 1, 2000 to find out if FFEL participants can handle Year 2000 date changes. Therefore, before that date arrives, if the Department determines that an FFEL participant is unlikely to be Y2K-compliant, appropriate measures will be taken to preserve the viability and integrity of the FFEL Program.

The Department's Y2K Plan

Assessment of our critical computer systems has revealed fundamental changes were needed, and we are in the process of making these changes. Our process for ensuring that our internal systems will smoothly handle the transition to 21st century dates includes the following general steps and milestone dates:

Awareness: Understanding the problem and developing a detailed project or business plan for addressing the issue. Completed

Assessment: Complete an assessment of all systems, processes, files, etc., that are affected to identify date processing. Completed

Renovation: Making necessary changes to ensure that each system is Year 2000 capable. September 1998

Validation: Testing and risk analysis to ensure. successful Year 2000 capability. January 1999

Implementation: Moving renovated and validated. Systems into production. March 1999

Contingency: Assessing risk and developing. Appropriate contingency plans. Ongoing