Maintained for Historical Purposes

This resource is being maintained for historical purposes only and is not currently applicable.

(Federal Perkins Data Provider Instructions) Introduction

PublicationDate: 7/23/99
ChapterNumber:
ChapterTitle: Introduction
SectionNumber:
SectionTitle:
PageNumbers:


Introduction
Schools participating in the Federal Perkins Loan Program are required to report detailed loan information to the National Student Loan Data System (NSLDS). This operating manual explains reporting requirements and processes used to add or update Federal Perkins loans on NSLDS. The manual accompanies and explains how to use the new NSLDS DataPrep software. It is provided to data providers (schools and their servicers) with administrative responsibility for the Federal Perkins Loan Program.


About This Manual
This manual is intended to assist users with the data provider portion of the NSLDS update process as well as provide basic information about the entire process.

To make the instruction manual as easy as possible to follow, we have included icons that help you identify key points. The following icons are used:






Indicates a definition or explanation that you will need to keep in mind throughout the discussion.



Indicates a special note, suggestion, or comment that will assist you in running DataPrep or in providing insight into the NSLDS update process.



Indicates a warning of which you should take special note.




Data Provider Responsibilities
Data providers must provide information to NSLDS on Federal Perkins loans and regularly report on new loans and changes to existing loans. These reports must be submitted on an ongoing basis and on a regular schedule established between the data provider and the U.S. Department of Education (ED).

Data providers must:


· Meet all NSLDS reporting requirements as detailed in this operating manual.

· Report all Federal Perkins loans that were open or closed on or after October 1, 1989.

· Report new loans or updates to existing loans monthly and on a schedule established by NSLDS. Data reported must be current and not extracted earlier than shown on the established schedule for the data provider.

· Create an Extract file in accordance with the specifications contained in Appendix A. Data providers are responsible for coding and testing the software as needed to properly format the Extract file.

· Use the NSLDS provided DataPrep software to perform Extract Validation and create a Submittal file.

· Transmit the Submittal file to NSLDS on ED-provided communication lines in accordance with the established schedule.

· Retrieve the Load Process Error file for each submittal. Data providers must review errors and correct as many as possible before the next submittal. Data providers are responsible for the accuracy of data as well as the timely reporting of loan data to NSLDS.

· Work with other data providers [e.g., guaranty agencies (GAs), Direct Loan, Debt Management Collection System, and Pell Grant System] to resolve identifier conflict records.

· Receive and process reconciliation files provided by NSLDS. Reconciliation of loan data between NSLDS and the school’s system of record may be done voluntarily upon request from the school or mandated by ED if it is determined necessary to meet data quality standards.

In summary, data provider data must meet NSLDS reporting requirements and quality standards. All data submitted to NSLDS must be as complete and correct as possible. Schools that fail to meet their NSLDS reporting requirements are subject to the limitation, suspension, and termination regulatory provisions.


Data Privacy
Maintaining the confidentiality of the personal data supplied by those applying for and receiving loans is of paramount concern to NSLDS. Data providers must be constantly vigilant in assuring the security of data being prepared for, sent to, and received from NSLDS. Student loan data must also be protected against intentional or inadvertent disclosure or destruction. NSLDS data is subject to the protections of the Privacy Act of 1974, as amended.

Data security is the responsibility of both the data provider and NSLDS. Sensitive materials such as data, software documentation, operation manuals, and handbooks should be labeled as such and stored in a secured location. You are responsible for NSLDS data when it is in your possession.



Data Accuracy and Timeliness
The data provider’s role in supplying data to NSLDS is critical to its overall success. Therefore, reporting must be timely, complete, and accurate. To help ensure the best possible data quality, NSLDS monitors submissions in two ways:

1.
Submittal Tracking: NSLDS monitors late and missed submittals on a continuing basis.

2.
Error Tracking: NSLDS’ Error Tracking function calculates the percentage of records in a submittal that are in error. NSLDS maintains a record of all errors until the error condition is resolved. Error rates are monitored on a regular basis to ensure data accuracy.

NSLDS divides the number of loan records with errors by the total number of records extracted to calculate the error rate. If there is more than one error in a record, the system will only count this as one error. Thus, the total number of errors will not necessarily equal the number of records with errors.

Data providers falling short of expectations in either of these areas are subject to the limitation, suspension, and termination regulations of ED.



Perkins DataPrep Version 2
The DataPrep software and load process have been modified as follows:

1.
DataPrep now checks for file-level and file-formatting error conditions and rejects the entire file if errors are found. You are expected to fix all file-level errors before submissions. Previously, such errors were not detected until the Submittal file was processed by NSLDS. Thus, the change means you have immediate feedback. DataPrep also does domain checks (i.e., date fields are real dates or zeroes, numeric fields are numeric, identifier and new identifier fields are properly populated) and provides a report on domain error conditions. However, loans with domain errors may be sent to NSLDS so that a single complete error file can be generated after load processing.

2.
Delta processing has been removed from DataPrep enabling all loans to be transmitted to NSLDS every month. Therefore, you will see a significant reduction in the amount of time it takes to run DataPrep. Also, reporting of Outstanding Principal Balance can be changed from quarterly to monthly, thus simplifying the extract process.

3.
The Load Process Error Report has been changed from a print file to a data file. Capability has been added in DataPrep to view and print the Load Process Error Report. DataPrep also supports the printing of a report on domain errors.

4.
All First Level edits (except domain-level edits) have been removed from DataPrep, but will continue to be performed at NSLDS. This will enable NSLDS to change edits as needed without releasing a new software version of DataPrep. Domain errors have been added to the Load Process Error Report enabling you to receive a complete error report each month.

5.
The checking for duplicate loans (i.e., two or more loans with identical loan identifiers) has been removed from DataPrep and added to the Load Process. This will enable NSLDS to identify duplicate loans and treat them as errors. An error record for each duplicate loan will be added to the Load Process Error Report.

6.
You may now populate the Extract file with your own loan identifier that will also be returned on the Load Process Error Report. The 19 bytes of filler at the end of the existing Detail record are used for this purpose. This facilitates loan record matches and the identification of duplicate loans created by changing loan identifiers without using the identifier change process.

7.
The Year 2000 (Y2K) problem and reasonability edits have been added to protect NSLDS data from receiving non-compliant data. Edits were added to each date field to ensure the date is notbefore an allowable date for the field. Similarly, an edit will determine the latest date allowable for a date field. Reasonability edits to ensure compliance with Federal Perkins regulations have also been added.

8.
Capability has been added to view and print a reconciliation file. The format of the file will be the same as that of the Extract file. This gives you the capability of having a formatted printout of the content of your Database Extract file.

9.
In the current DOS version of DataPrep, servicers, or central collection offices servicing multiple campuses were required to do a separate extract for each campus. The Submittal files were then combined for submission to NSLDS. The new Windows-based DataPrep will support processing of multiple campuses in a single Extract file. Servicers should either modify their extract procedures to create a single Extract file with a separate header for each campus, or merge the individual campus Extract files into a single file before performing an Extract Validation using the new DataPrep.

10.
The process for nullifying Perkins loans has been simplified in version 2. Currently, under version 1 of DataPrep, a data provider may not know all the data on the loan and is, therefore, unable to report the loan to NSLDS in a CA status. In version 2 a loan can be nullified by reporting the loan identifiers, setting the loan status to CA, and setting the Loan Status Date to the date the loan was nullified. All other fields in the record can then be set to defaults or the current valid values that exist. In either case, the loan will be nullified and dollar values set to zero.


Extract Process Changes Needed by September 3, 1999
Although there are a number of changes to the Extract Validation process in DataPrep version 2 that impact how records are reported, the record format does not change. Therefore, the internal procedures you currently use to create an Extract file under DataPrep version 1 will still work with DataPrep version 2. Therefore, your institution can begin to use DataPrep version 2 before making the following changes to your extract procedures.

All data providers are expected to implement the new DataPrep version 2 by September 3, 1999. Submittal files created by DataPrep version 1 (i.e., DOS and MVS versions) will not be accepted after September 3, 1999.

In addition, you are also expected to make the following changes to your extract procedures by September 3, 1999.



Full Extract Submissions—Report All Loans Every Month
In the new version of DataPrep, there will no longer be First Level and Delta processing. Instead, a full extract of all loans in your database that is either currently open or was closed on or after October 1, 1989, will be processed through the new DataPrep software and submitted to NSLDS. Your extract will include all open loans and all loans not yet reported and loaded to NSLDS in a closed or assigned status.

You will have to modify your Extract file creation procedures so that you no longer extract closed loans already reported and successfully loaded to NSLDS. For example, a borrower makes the final payment on a loan in March 1999. You report the loan as paid in full (PF) with your April submittal. The record contains no errors and updates NSLDS. Thus, you would not extract this loan record again when you create future Extract files.



Loans Closed Prior to October 1, 1989
If you currently extract loans that were closed before October 1, 1989, discontinue extracting such loans. A new edit will reject any loan closed before October 1, 1989. You can prevent these rejects by not extracting such loans.

Report Outstanding Principal Balances Monthly
The Date of Outstanding Principal Balance will reflect the date of the most recent change in the principal balance. The Outstanding Principal Balance may change as a result of a disbursement, loan payment, or cancellation. Since all loans in your database will be submitted every month, the requirement to update Outstanding Principal Balance on a quarterly basis is eliminated. Instead, you must update the dollar amount and the date of the outstanding principal balance using the current remaining amount and the date of the most recent change in Outstanding Principal Balance. If you have been reporting the last day of the month regardless of when the balance changed, you must modify your extract procedure to provide the actual day when the balance changed.


Reporting Outstanding Principal Balances that are Less Than One Dollar
If a loan is reported with an open loan status, it must have a positive Outstanding Principal Balance. If the loan has a balance of less than one dollar, but not zero, you will report the Outstanding Principal Balance as one dollar. If the loan is being maintained in an open status because of a negative balance on the account (i.e., a credit balance), you will also report a balance of one dollar until the loan is closed.


Unique Data Provider Loan ID
You will be able to track a loan through the NSLDS process using your own unique Data Provider Loan ID if you so choose. The last field in the detailed loan record will be available to allow you to insert the unique loan ID that will be carried through the process and returned on the error records in the error file. The use of this new field is optional.


Changes Made to Trailer Record
In the past, positions 55-300 in the trailer record were filler. Now, positions 55-66 is the Total Amount of Loan, positions 67-78 is the Total Amount of Cancellation, positions 79-90 is the Total Amount of Outstanding Principal Balance, and positions 91-300 is filler.

Last Modified: 08/10/1999