NCHELP CommonLine Network for FFELP And Alternative Loans. Reference Manual. Release 4 Processing

Transcription

1 NCHELP CommonLine Network for FFELP And Alternative Loans Reference Manual Release 4 Processing

2

3 Table of Contents CommonLine Release 4 Chapter 1 Introduction Chapter 2 CommonLine Overview Chapter 3 CommonLine Compliance Chapter 4 Application Send File CommonLine Introduction How to use this manual Chapter overviews How to obtain further assistance NCHELP contact information General information CommonLine benefits Advantages to schools CommonLine file formats Identifying applications and loans Transmitting files Testing and certification CommonLine compliance rules Application Send File and Response File Disbursement Roster File/Disbursement Roster Acknowledgment File Change Transaction Send File and Response File General information File structure Application processes Submitting applications (initial requests) Submitting applications (subsequent requests) Additional services Alternative loans Program type code Alternative student/borrower indicator code Reference information Supplemental borrower information Issued: 01/15/2009 i

4 Table of Contents CommonLine Release 4 Chapter 5 Response File Chapter 6 Disbursement Roster File/Disbursement Roster Acknowledgment File Chapter 7 Change Transaction Send File Chapter 8 School-Based Software Guidelines for Software Developers General information File structure Response processing Application responses Change transaction responses Additional services Special messages Alternative loans Reference information Supplemental borrower information Change transaction processing errors General information File structure Disbursement processes Submitting disbursement information Acknowledging disbursement information (CDA process only) Additional services Special messages General information Change Transaction Send File/Common Account Maintenance file relationship File structure Change transactions Change transaction flow Submitting change transactions Additional services General information Development and modification guidelines Data transmission/reception guidelines Software modification guidelines System setup guidelines Required SBS documentation statement Implementation example Guarantor table Lender table Electronic File Recipient ID table Recipient Exception table Implementation checklist ii Issued: 01/15/2009

5 Table of Contents CommonLine Release 4 Chapter 9 Transmitting CommonLine Files Chapter 10 Testing and Certification NCHELP Technical Manual Testing objectives Communication between partners Test data guidelines Test sequence and file pair guidelines Testing results and certification Implementation issue resolution Appendix A Glossary Issued: 01/15/2009 iii

6 Table of Contents CommonLine Release 4 THIS PAGE IS INTENTIONALLY BLANK iv Issued: 01/15/2009

7 Chapter 1 CommonLine Release 4 Introduction CommonLine Introduction The NCHELP (National Council of Higher Education Loan Programs) CommonLine Network for FFELP (Federal Family Education Loan Program) and Alternative Loans has become, in a few short years, the FFELP industry standard for electronic transmission of student loan data between schools and their varied service providers. From its beginnings as a vehicle for the electronic transmission of standard loan application data, it has developed into a full-service network, which includes standard file formats for FFELP and alternative loan application, disbursement, and change transaction data transmission and processing. As a result of these collective efforts, schools now have the ability to communicate electronically with all service providers via a standardized electronic format. This manual and the accompanying file descriptions are the result of a rigorous development and review process. They reflect the collective best efforts of FFELP participants, especially schools, to improve and clarify CommonLine file formats and processes. Considerable thought and care have been given to make the CommonLine Network easier to use and understand, with the goal of simplifying the student loan application, disbursement, and change transaction processes for both students and schools. If you are new to the CommonLine Network, this manual and the associated file descriptions provide you with the information you will need to get up and running with CommonLine. If you currently use CommonLine, they provide the latest version of CommonLine file formats and processes in an easily referenced format. The CommonLine Network represents a continuing cooperative effort in the FFELP community and our commitment is to improve and enhance its effectiveness for all participants. To that end we welcome your input and comments on this documentation and on the CommonLine Network itself. If you have any questions or comments regarding these file formats please submit an issue through the Electronic Standards Committee issue submission process at Issued: 01/15/

8 Chapter 1: Introduction CommonLine Release 4 How to use this manual The CommonLine Reference Manual is an implementation guide for CommonLine participants such as schools, lenders, guarantors, and servicers. It provides information about CommonLine compliance rules, processes, transaction types, and the functionality of and relationship between files. For first-time CommonLine participants, this manual provides the necessary startup information. For participants already familiar with CommonLine, this manual provides the information needed to transition to the most recent CommonLine release. Throughout this manual, references are used to point to related material in other sections of the manual. References are enclosed in parentheses and generally follow the chapter number and name, first subheading, second subheading format. The following examples illustrate the most common use of references: For references to the second subheading of a chapter other than the one containing the reference: (See chapter 2, CommonLine Overview, CommonLine file formats, Identifying applications and loans.) For references to the first subheading of a chapter other than the one containing the reference: (See chapter 4, Application Send File, General information.) For references to a chapter other than the one containing the reference: (See chapter 5, Response File.) For references to a second subheading within the chapter of the reference: (See Application processes, Additional Services.) For references to a first subheading within the chapter of the reference: (See Testing Objectives.) This manual may be reproduced, provided the reproduction does not add to or 1-2 Issued: 01/15/2009

9 Chapter 1: Introduction CommonLine Release 4 modify this content. CommonLine file formats (even parts of the documentation) are not intended to be placed into proprietary formats. Chapter overviews Chapter 1, Introduction, contains a CommonLine Introduction that describes the history and mission of the NCHELP CommonLine Network for FFELP and Alternative Loans. A brief overview of each chapter in the manual is also included. Chapter 2, CommonLine Overview, contains general information about CommonLine. It includes the benefits of using CommonLine, an overview of CommonLine processes, file formats, application and loan identification methods, file transmission methods and considerations, and a brief discussion of testing and certification requirements. Chapter 3, CommonLine Compliance, contains CommonLine compliance rules geared toward both those implementing CommonLine for the first time and current participants who are migrating to the latest release. Chapter 4, Application Send File, shows how to use the NCHELP CommonLine Network for FFELP and Alternative Loans Application Send File for Release 4 processing to initiate and update applications. It also discusses the files format and the types of additional services provided by the file. Alternative loans, reference information, and supplemental borrower information are also documented. Chapter 5, Response File, covers the processes involved in both application responses and change transaction responses. For application responses, it shows how the service provider uses the NCHELP CommonLine Network for FFELP and Alternative Loans Response File for Release 4 processing to let the school know of any errors in the Application Send File and the status of each loan or application. For change transaction responses, it shows how the service provider uses the Response File to let the school know about the status of a change transaction request as well as any errors in the request. It also discusses the files format and their capabilities to handle special messages, alternative loans, and reference information. Chapter 6, Disbursement Roster File/Disbursement Roster Acknowledgment File, shows the procedure for informing schools of disbursement information through CommonLine. In addition to an overview of the file format, it also discusses the processes that are unique to Central Disbursing Agents (CDA). Chapter 7, Change Transaction Send File, describes the processes involved in making both pre- and post-disbursement change transactions. Chapter 8, School-Based Software Guidelines for Software Developers, provides guidelines for service providers and schools who develop CommonLine-compliant software or modify software to accept CommonLine formats. Issued: 01/15/

10 Chapter 1: Introduction CommonLine Release 4 Chapter 9, Testing and Certification, provides general guidelines for the testing and certification process that must be used to ensure compatibility between CommonLine participants. Appendix A, Glossary, defines key terms and acronyms used throughout this manual. How to obtain further assistance Contact the Electronic Standards Committee s (ESC) Origination Standards Advisory Team (OSAT) to obtain assistance with the following topics: Obtaining the latest revision information about CommonLine file descriptions. Obtaining contact information for the OSAT. Contact the NCHELP central office to Submit proprietary record formats for registration (e.g., Unique Supplemental [@2] Detail Record layouts). NCHELP contact information The NCHELP central office can be reached using any of the following contact information: National Council of Higher Education Loan Programs, Inc Connecticut Avenue, NW Suite 1200 Washington, DC Phone: (202) Fax: (202) info@nchelp.org Web site: The NCHELP web site provides information of general interest to the FFELP community, NCHELP members and contains information about CommonLine. Visit the web site periodically to stay up to date on the latest NCHELP and CommonLine Network information. Additional information is available in some instances by contacting the NCHELP central office directly. 1-4 Issued: 01/15/2009

11 Chapter 1: Introduction CommonLine Release 4 THIS PAGE IS INTENTIONALLY BLANK Issued: 01/15/

12

13 Chapter 2 CommonLine Release 4 CommonLine Overview General Information The NCHELP CommonLine Network for FFELP and Alternative Loans represents the nationally-recognized standard for FFELP and alternative loan applications and disbursements. The term CommonLine is trademarked to ensure that it can only be used for student loan processing and is not the property of any one organization. In 1995, CommonLine participants established standard procedures and software to allow the electronic exchange of loan processing data for FFELP loans among schools and service providers. Many schools and service providers began changing their systems and procedures to take advantage of this technology. Schools were able to use the school-based software (SBS) of their choice to initiate applications and receive loan status updates from many service providers. In 1996, CommonLine was improved to support private, non-title IV (alternative) loans and to make electronic disbursement and loan adjustment data available to participants. In 1997, CommonLine was improved to provide transaction-based functionality for change transaction information and a more simplified response processing for communications back to school and between service providers. For Release 4, CommonLine was again improved based on industry comment and further attempts to provide standardized data processing formats.documentation updates are made as needed to accommodate legislative and regulatory changes. Issued: 01/15/

14 Chapter 2: CommonLine Overview CommonLine Release 4 CommonLine Benefits The CommonLine Network offers the following advantages: It simplifies the application, guarantee, disbursement, and change transaction processes. It facilitates communication among schools and service providers (guarantors, lenders, and servicers) through the use of common files and simplified processes. For example, a school submitting applications to many different guarantors can use a single file format for all communications. It enables participants to retain existing CommonLine-compliant School Based Software, while becoming part of a common data exchange. It enables participants to send key loan information electronically, through the use of an industry standard. The types of information that are being sent include applications, application updates, disbursement data, and change transactions. CommonLine compliance rules have been established for each CommonLine process. Participants must adhere to these compliance rules. (See chapter 3, CommonLine Compliance, CommonLine compliance rules.) Advantages to schools It offers flexibility by allowing schools and service providers to select the CommonLine processes they will implement. SBS is software which schools utilize to assist them in the processing and electronic exchange of student loan applications, disbursement data, and change transactions. 2-2 Issued: 01/15/2009

15 Chapter 2: CommonLine Overview CommonLine Release 4 Before common formats and common data transmission were established, one school could potentially have multiple SBS systems with multiple formats to transmit data to service providers (guarantors, lenders, and servicers). For example, a school might have SBS-A loaded on one PC to communicate with Guarantor A and SBS-B on another PC to communicate with Lender B. They might have to communicate with still other service providers using paper rather than electronic transmission. Although CommonLine allows participants to process disbursement and change transaction information, the following example shows only the loan origination process and how it has been simplified by CommonLine. Student loan origination before CommonLine Application Data Guarantor A School A Lender B Others Response Data The goal of CommonLine is to simplify the student loan process by: Establishing standard file formats and a simplified approach for the electronic exchange of student loan data. Allowing schools to use one SBS or Financial Aid Management System (FAMS) to communicate with all CommonLine participants. Enabling schools to initiate electronic communication with service providers with whom they currently communicate non-electronically. Issued: 01/15/

16 Chapter 2: CommonLine Overview CommonLine Release 4 Student loan origination using CommonLine Application Data Schools Service Providers (Guarantor, Lender, Servicer) Response Data Print only (PO) requests require submission of only a limited amount of data in order for the receiving organization to print and mail the application. Schools may use CommonLine-compliant products to submit a single electronic format for FFELP and alternative loans. The following are typical steps in the CommonLine loan-origination process: 1 The school certifies the loan. 2 The data, using the Application Send File format, is routed to the appropriate service provider. 3 The service provider processes the data for initial and subsequent requests 4 The service provider creates a Response File and sends it to the school. 5 The school uses the response data for further loan processing. 2-4 Issued: 01/15/2009

17 Chapter 2: CommonLine Overview CommonLine Release 4 CommonLine file formats When CommonLine was introduced in 1995, it was simply referred to as CommonLine. With the first set of revisions made in the subsequent year, the name was changed to CommonLine 96. The processing version was informally referenced as CommonLine Release 3 (being the third release of CommonLine file formats), with specific version numbers assigned to each of the file names. Beginning with the processing year, all files are referenced as CommonLine Release 4 and do not contain version numbers in the file names. The new file names for CommonLine Release 4 processing are shown in the following table, along with a brief description of the purpose of each file. Issued: 01/15/

18 Chapter 2: CommonLine Overview CommonLine Release 4 Release 4 file name Purpose For more information, see Application Send File Response File Disbursement Roster File/Disbursement Roster Acknowledgment File Change Transaction Send File Submits application data for initial processing (guarantee only, guarantee and print, print and guarantee, or print only). Also submits subsequent processing requests (correction requests, reprint requests, or terminate requests). May also be used for a school s response to School Certification Requests [SCR requests]). This file may also include alternative loan, reference, or supplemental borrower information, if applicable. Confirms application data was received; identifies errors, terminations, reports guarantee data, and modifications to previously-reported guarantees. Confirms change transaction data was processed and identifies errors. May also be used for SCR requests. This file may also include alternative loan, reference, or supplemental borrower information, if applicable. The Disbursement Roster reports disbursement data to schools and/or Central Disbursing Agents (CDAs). The Disbursement Roster Acknowledgment File confirms disbursement data was received and identifies errors. The Disbursement Roster Acknowledgment File can only be sent by CDAs to disbursing agents. Submits loan change transactions for guaranteed loans pre- or post-disbursement. Chapter 4, Application Send File Chapter 5, Response File Chapter 6, Disbursement Roster File/Disbursement Roster Acknowledgment File Chapter 7, Change Transaction Send File Please note that applicable files can be used for communication between service providers. See the chapters mentioned in the previous table or the file descriptions for more information. 2-6 Issued: 01/15/2009

19 Chapter 2: CommonLine Overview CommonLine Release 4 Identifying applications and loans via CommonLine Unique ID and Loan Sequence Number Because the CommonLine loan sequence number is assigned at the time of guarantee, it is not included in the Application Send File unless it is a Blanket Certificate of Guarantee (BCG) request. However, this field is included in all other CommonLine files. No CommonLine Unique Identifier is created or stored for a print only (PO) request. In addition, PO requests do not require guarantee processing and no Response (@1) Detail Record will be sent. Loans that originate under CommonLine are required to use the CommonLine unique identifier and CommonLine loan sequence number as detailed in this manual and the file descriptions. (See CommonLine file formats, Identifying applications and loans.) These two fields are designed as unique identifiers for the application and resulting loans. The CommonLine unique identifier and loan seuquence number (once guaranteed) are required to be used as the primary matching for CommonLine processing. Once the Loan Sequence Number is assigned it can not be modified, which means you cannot have more than one loan of the same type with the same unique id and multiple sequence numbers. All CommonLine files submitting information related to an application must include the CommonLine unique identifier, excluding print only requests in the Application Send File. The CommonLine loan sequence number is required, if known by the file creator per instructions in this section. While CommonLine is the primary focus, use of the CommonLine unique identifier and CommonLine loan sequence number is strongly encouraged between all business partners in processes outside of CommonLine. The CommonLine unique identifier is assigned at the application level. This code is assigned by the organization that transmits the first electronic record containing information about the application. Typically, this takes place when the Application Send (@1) Detail Record is submitted in the Application Send File. Please note that, for SCR requests, this number is typically assigned by the service provider in the Response File. However, there are cases in which the CommonLine unique identifier may not yet be assigned when other CommonLine files are created. When creating CommonLine files, it is the file creator s responsibility to confirm whether the CommonLine unique identifier has been assigned; if not, it is the file creator s responsibility to assign it. The CommonLine loan sequence number is assigned at the loan level and is used in conjunction with the CommonLine unique identifier to identify each loan. This number is assigned by the guarantor at the time of guarantee or the lender at the time of BCG. Typically, this takes place when the Response (@1) Detail Record is submitted in the Response File. Application Send File Application Response File The organization that transmits the first electronic record containing information about the application assigns the CommonLine unique identifier. The CommonLine loan sequence number does not appear in the Application Send File unless it is a BCG request, since this field is created when the loan(s) is guaranteed. This file contains both the CommonLine Unique Identifier and CommonLine Loan Sequence Number. When a loan is guaranteed the CommonLine Loan Sequence Number is in the Response File. Each loan is assigned a different loan sequence number. Once the Loan Sequence Number is assigned it can not be modified, which means you cannot have more than one loan of the same type with the same unique id and multiple sequence numbers. Issued: 01/15/

20 Chapter 2: CommonLine Overview CommonLine Release 4 When the Response File is created by an organization other than the guarantor, it is that organization s responsibility to obtain the CommonLine loan sequence number from the guarantor and populate the CommonLine Loan Sequence Number field after the loan is guaranteed. The guarantor has the option to delegate the responsibility of assigning the CommonLine loan sequence number to the lender. Disbursement Roster File/ Disbursement Roster Acknowledgment File This file contains both the CommonLine Unique Identifier and CommonLine Loan Sequence Number. Together these fields identify the application and loan for each disbursement reported in the detail records. Change Transaction Send File This file contains both the CommonLine Unique Identifier and CommonLine Loan Sequence Number. 2-8 Issued: 01/15/2009

21 Chapter 2: CommonLine Overview CommonLine Release 4 CommonLine unique identifier format The concept at the core of the CommonLine Unique Identifier is that it is a code uniquely identifying that application throughout the student loan industry. Failure to create codes that are unique invalidates this premise; therefore, it is critical that you follow this guidance to prevent creation of duplicate (invalid) values for the CommonLine Unique Identifier. The following table shows the format of the CommonLine Unique Identifier. The organization that transmits the first electronic record containing information about the application assigns this code. If the CommonLine unique identifier is not yet assigned by the school or another service provider, the file creator must assign it. This field may contain both numeric and alphabetic (uppercase only) characters; however, it should not contain spaces. Positions Meaning 1-6 Participant ID. WARNING The CommonLine Unique Identifier is to be used only to identify the application. Therefore, after it is created, the individual components of the field (e.g., positions 1-6, Participant ID) should not be relied upon to store meaningful data. Servicers or service bureaus that have not been assigned an ED number should contact the NCHELP central office to determine the appropriate 3-, 6-, or 8-character value. The unique identification code for the organization assigning the CommonLine unique identifier to the application. For guarantors, this is the 3-digit number as shown in Appendix A, Valid Guarantor IDs, of the file descriptions. For lenders and servicers, this is the 6-digit code assigned by the U.S. Department of Education (ED). For schools, this is the first 6 digits of the 8-digit ED-assigned school ID. The last 2 digits of the school ID will appear in positions 7 10 (Participant Branch ID). The participant ID must be right-justified and padded with zeros Participant Branch ID. If ED has assigned a branch ID: For schools, this is the last 2 digits of the 8-digit ED-assigned school ID. These 2 digits identify the branch campus assigning the CommonLine unique identifier. Issued: 01/15/

22 Chapter 2: CommonLine Overview CommonLine Release 4 If ED has not assigned a branch ID: The unique identification number (maximum of 4 characters) assigned by an entity other than ED to the branch office or campus assigning the CommonLine unique identifier. The participant branch ID must be right-justified and padded with zeros. If no branch ID has been assigned, fill positions 7 10 with zeros Issued: 01/15/2009

23 Chapter 2: CommonLine Overview CommonLine Release 4 11 System ID. A 1-character code indicating the computer system on which the original electronic application was created. The system ID is especially useful in environments where the same software product is loaded on multiple PCs Incremental Code. A unique identification code (maximum of 6 characters) assigned by the software to the application. An algorithm has been developed to help reduce the possibility of duplicate incremental codes. This algorithm is explained in the appendices of the Application Send File, Response File, Disbursement Roster File, and Change Transaction Send File descriptions. Use of this algorithm is strongly recommended for CommonLine processing. CommonLine Loan Sequence Number format The following table shows the format of the CommonLine Loan Sequence Number. This number is typically assigned at the time of guarantee. This data is required if the loan is guaranteed. Positions Description 1-2 A unique 2-digit identification number assigned at the time of guarantee. This number is used in conjunction with CommonLine Unique Identifier to identify the loan. The number must be unique for each new loan resulting from an application. Any 2-digit number (01-99) is valid if the loan is guaranteed. Once the Loan Sequence Number is assigned it can not be modified, which means you cannot have more than one loan of the same type with the same unique id and multiple sequence numbers. Issued: 01/15/

24 Chapter 2: CommonLine Overview CommonLine Release 4 Example of unique loan identification The following diagram shows the CommonLine Unique Identifier and CommonLine Loan Sequence Number that identify two loans resulting from a single application submitted in the Application Send File. The school participant ID is and its branch ID is CommonLine Unique Identifier SA00Z CommonLine Loan Sequence Number 01 CommonLine Loan Sequence Number 02 Transmitting files All participants are required to use a CommonLine-compliant data exchange for file transmissions. Please refer to the NCHELP Technical Manual for additional information. Testing and certification Without sufficient testing, the CommonLine process cannot be successful. NCHELP has provided guidelines for conducting testing of CommonLine file pairs. (See chapter 10, Testing and Certification.) Testing certification is where two organizations have agreed that the CommonLine file(s) tested can be transmitted between the two organizations in a production environment. Each organization agrees that: The trading partners have tested a file pair, and the trading partners are agreeable with the testing results, and the trading partners are willing to process production data. Production processing using the certified file pairs can commence upon successful setup and communication testing Issued: 01/15/2009

25 Chapter 2: CommonLine Overview CommonLine Release 4 Issued: 01/15/

26

27 Chapter 3 CommonLine Release 4 CommonLine Compliance CommonLine compliance rules An organization is said to be CommonLine compliant when it meets all requirements for the CommonLine processes it has chosen to implement. A CommonLine-compliant organization must fully support all required elements and processes for those files it is implementing. The compliance criteria for service providers and school-based software (SBS) differ and are explained in the following sections. Any organization exchanging data with a CommonLinecompliant organization is assured that the data will be processed correctly per CommonLine standards. In addition, some CommonLine files work as pairs and must be implemented as such. For example, if a service provider chooses to use CommonLine for loan origination, it must support the Release 4 version of the NCHELP CommonLine Network for FFELP and Alternative Loans Application Send File and the NCHELP CommonLine Network for FFELP and Alternative Loans Response File to be CommonLine compliant. It is acceptable for organizations to elect to implement the latest versions of the CommonLine files for some processes while continuing to use older versions for other processes. In general, organizations should format files in the CommonLine version appropriate to the file received (i.e., a Release 4 Response File should ackowledge a Release 4 Application Send File). This rule may be overridden by mutual agreements between CommonLine participants. Application Send File and Response File This section provides general processing rules for implementing the Application Send File and the Response File for CommonLine Release 4 processing. These files facilitate the loan origination process. To be considered CommonLine Release 4 compliant for application processing, both Release 4 of the Application Send File and the Response File, as it relates to application processing, must be supported. To be considered CommonLine compliant for application processing, the current version minus one must be supported for both the Application Send File and the Response File. Issued: 01/15/

28 Chapter 3: CommonLine Compliance CommonLine Release 4 Service providers are required to support all basic processing options in the Application Send and Response Files, with the exception of guarantee and print, and print and guarantee. A service provider is required to support either guarantee and print, or print and guarantee, but has the option of supporting both. All SBS is required to support all basic processing options and additional services. Additional services are optional for service providers to provide. (See chapter 4, Application Send File, Application processes, Additional services, and chapter 5, Response File, Response processing, Additional services.) If a service provider receives a request for a service it does not support (e.g., GP or PG), the record should be rejected and the appropriate error message returned. In general, service providers should format files in the CommonLine version appropriate to the file received (i.e., a Release 4 Response File should ackowledge a Release 4 Application Send File). This rule may be overridden by mutual agreements between CommonLine participants. To be fully compliant, service providers must be able to communicate with other service providers, as well as schools, using CommonLine file formats (for application processing only, not applicable to change transaction responses). All participants are required to use a CommonLine-compliant data exchange for file transmissions. Please refer to the NCHELP Technical Manual for additional information. Service providers and SBS must support the modification (M) record, which can only be sent post-guarantee. If a school does not submit an electronic change transaction request all changes to disbursement dates and amounts, including cancellations, must be reported in an M record. Service providers also have the option to report other post-guarantee changes via an M record. M records should only be submitted by a single entity for each loan. It is strongly recommended that this entity be the lender or a lender agent. All SBS must support the reprint response (N) record. However, the N record is optional for service providers to provide. Service providers and SBS are required to use termination (T) records, which are used prior to guarantee, for all termination requests received inside the CommonLine process. For those termination requests received outside of CommonLine (e.g., requests received via fax or telephone), use 3-2 Issued: 01/15/2009

29 Chapter 3: CommonLine Compliance of the T record is optional. All SBS is required to support Detail Record; however, the inclusion of this record type is optional in the Application Send File. All service providers who process alternative loans must support all of the Application Send and Response (@1) Detail Record(s) and the Alternative Loan and Alternative Loan Response (@4) Detail Record(s) required data elements for those alternative loan programs that require them. All SBS must support Detail Record formats for those alternative loan programs requiring them. All SBS must support all loan types (FFELP and alternative) in the Application Send File. Service providers must support all FFELP loan types that they offer and be able to provide, at a minimum, a reject error code in the Response File if they receive an alternative loan type they do not support. The School Certification Request (SCR) process is optional for service providers, but must be supported by all SBS. If a school receives an SCR request from a service provider in an Application Response (@1) Detail Record, it will transmit the certification information via an Application Send (@1) Detail Record with a Record Type Indicator Code (field 2) of C. All organizations who collect and process borrower reference information can submit that information in the Application Send File Reference (@5) Detail Record(s). If this record type is supported by the service provider, this information will be passed back in the Response File Reference Response (@5) Detail Record(s). Detail Records are optional. Service providers and SBS are not required to support these records. All SBS is required to support Detail Record; however, the inclusion of this record type is optional in the Application Send File. All organizations who collect and process supplemental borrower information can submit that information in the Application Send File Supplemental Borrower Information (@7) Detail Record(s). If this record type is supported by the service provider, this information will be passed back in the Response File Supplemental Borrower Information Response (@7) Detail Record(s). This record type is optional. Service providers are not required to support this record; however, SBS is required to support this functionality. If an organization receives an unsupported optional record type (e.g., Unique Supplemental [@2] Detail Record), the organization should ignore the record and should not produce a fatal error. A Response File contains one header record, one or more detail records, and one trailer record. The header and trailer records indicate the source (organization creating the Response File) and the recipient (organization that submitted the original Application Send File). The Response File should be submitted to the organization that created the Application Send Fileregardless of how many Issued: 01/15/

30 Chapter 3: CommonLine Compliance CommonLine Release 4 Disbursement Roster File/ Disbursement Roster Acknowledgment File schools were included in the detail record(s). The Response File may also be sent to interested third parties for initial and subsequent responses, depending on the agreement with each third party. An interested third party is considered an entity associated to the application which needs to receive updated information on the application. The entity maintaining the application may send updates of the application as needed to ensure data integrity between trading partners and interested third parties. This section provides general processing rules for implementing the NCHELP CommonLine Network for FFELP and Alternative Loans Disbursement Roster File/Disbursement Roster Acknowledgment File for CommonLine Release 4 processing. These files facilitate disbursement processing. To be considered CommonLine Release 4 compliant for disbursement roster processing, SBS must support the Release 4 versions of the Disbursement Roster File, Change Transaction Send File, and the Response File (as it relates to change processing). Service providers must support the Release 4 version of the Disbursement Roster File only; support of the Change Transaction Send File and Response File is optional for service providers. To be fully compliant, service providers must be able to communicate with schools using CommonLine file formats. All participants are required to use a CommonLine-compliant mail system for file transmissions. Please refer to the NCHELP Technical Manual for additional information. All CDAs receiving the Disbursement Roster File must be able to generate a Disbursement Roster Acknowledgment File consisting of one header record, one or more detail records, and one trailer record. The header and trailer records indicate the source (organization creating the Disbursement Roster Acknowledgment File) and the recipient (organization that submitted the initial file). This file is an acknowledgment of the entire Disbursement Roster File and should be submitted to the disbursing agent that created the initial Disbursement Roster File, regardless of how many schools were included in the detail records. 3-4 Issued: 01/15/2009

31 Chapter 3: CommonLine Compliance Rosters may be created to include all disbursement methods or to include only certain disbursement methods. Contact the service provider to discuss available options. To be CommonLine Release 4 compliant for disbursement processing, disbursing agents must support the following funds disbursement methods: Electronic Funds Transfer (EFT) Individual borrower check Master check If an organization receives an unsupported optional record type (e.g., a Unique Supplemental [@2] Detail Record), the organization should ignore the record and should not produce a fatal error. Please note that while some disbursing agents may support netting, schools are not required to perform netting transactions. When using the netting disbursement method, the school is still required to report cancellations, refunds, and reissues via the Change Transaction Send File. The netting process is optional for service providers but must be supported by all SBS. Netting is defined as a disbursement method in which funds that have been sent to the school electronically or via Master Check are reallocated for disbursement to another eligible borrower(s) instead of being returned. The disbursing agent then offsets (deducts) the adjusted amounts from the total dollar amounts on the next transmission of funds to the school. Netting is applicable only to EFT and master check disbursements. In the Disbursement Roster File, Record Type Indicator Code (field 2, Disbursement [@1] Detail Records[s]) contains A for adjusted disbursements (netting). Adjustment is defined as the full or partial cancellation of a previously reported disbursement where the funds distribution method is netting. To be CommonLine compliant, a service provider must support all disbursement methods, except netting. Netting is optional for service providers. At a minimum, a service provider must provide an error code indicating that netting is not a currently supported function. If a service provider rejects a netting transaction because it is not supported, the school must submit a new change transaction indicating a different funds return method, and must physically return the funds to the disbursing agent. Service providers that support netting must use a Record Type Indicator Code (field 2, Disbursement [@1] Detail Record) of A, and populate Total Deficit Amount (field 15, trailer record), if applicable, in the Disbursement Roster File for netting processing. To be CommonLine compliant, SBS must be able to support a Funds Return Method Code (field 32, Disbursement Notification/Change [@1-10] Detail Record, or field 27, School Refund [@1-11] Detail Record) of N in the Change Transaction Send File for netting processing. In addition, SBS must support adjustment (A) records and Total Deficit Amount (field 15, trailer record) in the Disbursement Roster File. Issued: 01/15/

32 Chapter 3: CommonLine Compliance CommonLine Release 4 Change Transaction Send File and Response File This section provides CommonLine compliance rules for implementing Release 4 of the Change Transaction Send File and the Response File. These files facilitate the change transaction process. Service providers are required to support all basic processing options. If the service provider does not process a transaction, the service provider is required to obtain additional information or obtain approval from other service providers before responding to the school. All SBS is required to support all processing options and additional services. Additional services are optional for service providers to provide. (See chapter 5, Response File, Response processing, Additional services, and Chapter 7, Change Transaction Send File, Change transactions, Additional services.) To be fully compliant, service providers must be able to communicate with schools, using CommonLine file formats for responses to change transactions. All participants are required to use a CommonLine-compliant mail system for file transmissions. Please refer to the NCHELP Technical Manual for additional information. All SBS is required to support the CommonLine change transaction flow rules to determine the recipient of Change Transaction Send Files. (See chapter 7, Change Transaction Send File, Change transactions, Change transaction flow.) 3-6 Issued: 01/15/2009

33 Chapter 3: CommonLine Compliance All organizations who receive change information via the Change Transaction Send File must support the change transaction response (R) record and the Change Transaction Error Detail Record in the Response File. The R record is a snapshot of the processor s database after processing the change. If errors exist in the original change transaction, information on these errors will be passed back to the originator via Detail Record. SBS and service providers are required to support these records. If an organization receives an unsupported optional record type (e.g., Unique Supplemental [@2] Detail Record), the organization should ignore the record and should not produce a fatal error. If the school has a relationship with a CDA, the CDA may act as an intermediary between the school and the appropriate guarantor, lender, or servicer when processing change transactions. In this scenario, the CDA may forward the Response File to the school. If the receiving organization cannot process the change transaction due to lack of authorization or lack of data, the receiving organization must route the change transaction to the appropriate service provider for processing via the Change Transaction Send File. Service providers who receive these routed files for processing should process the requests and may send the Response File back to the routing agent to forward to the school. Please note that while some disbursing agents may support netting, schools are not required to perform netting transactions. When using the netting disbursement method, the school is still required to report cancellations, refunds, and reissues via the Change Transaction Send File. The netting process is optional for service providers, but must be supported by all SBS. Netting is defined as a disbursement method in which funds that have been sent to the school electronically or via Master Check are reallocated for disbursement to another eligible borrower(s) instead of being returned. The disbursing agent then offsets (deducts) the adjusted amounts from the total dollar amounts on the next transmission of funds to the school. Netting is applicable only to EFT and master check disbursements. Issued: 01/15/

34 Chapter 3: CommonLine Compliance CommonLine Release 4 To be CommonLine compliant, a service provider must support all disbursement methods, except netting. Netting is optional for service providers; at a minimum, a service provider must provide an error code indicating that netting is not a currently supported function. If a service provider rejects a netting transaction because it is not supported, the school must submit a new change transaction indicating a different funds return method and physically return the funds to the disbursing agent. Service providers that support netting must use a Record Type Indicator Code (field 2, Disbursement [@1] Detail Record) of A, and populate Total Deficit Amount (field 15, trailer record), if applicable, in the Disbursement Roster File for netting processing. To be CommonLine compliant, SBS must be able to support a Funds Return Method Code (field 32, Disbursement Notification/Change [@1-10] Detail Record, or field 27, School Refund [@1-11] Detail Record) of N in the Change Transaction Send File for netting processing. In addition, SBS must support adjustment (A) records and Total Deficit Amount (field 15, trailer record) in the Disbursement Roster File. A Response File contains one header record, one or more detail records, and one trailer record. The header and trailer records indicate the source (organization creating the Response File) and the recipient (organization that submitted the original Change Transaction Send File). The Response File should be submitted to the organization that created the Change Transaction Send File, regardless of how many schools were included in the detail record(s). 3-8 Issued: 01/15/2009

35 Chapter 4 CommonLine Release 4 Application Send File General Information See the file description for the Release 4 version of the NCHELP CommonLine Network for FFELP and Alternative Loans Application Send File for detailed programming format information. CommonLine participants use the Release 4 version of the NCHELP CommonLine Network for FFELP and Alternative Loans Application Send File to initiate, print, correct, reprint, or terminate applications. Although this file is typically submitted by schools, it can also be sent by guarantors, lenders, or servicers. The Release 4 version of the NCHELP CommonLine Network for FFELP and Alternative Loans Response File is sent back to the creator of the Application Send File to acknowledge receipt of the file. (See chapter 5, Response File.) Please note "alternative" is used to indicate private, non-title IV loans. Application Send File School Service Provider Response File Schools using school-based software (SBS) often initiate the application process by downloading data from financial aid software to the SBS. Schools using in-house programs extract the same data and build the CommonLine files on their mainframe. Whether a school is using SBS or in-house software, the CommonLine process is the same. If the school sends the Application Send File to a guarantor, the guarantor notifies the school when the loan is guaranteed and forwards loan information to the lender. If the school sends the Application Send File to a lender or servicer, the lender or servicer acknowledges that the application is in progress while it obtains the guarantee. Issued: 01/15/

36 Chapter 4: Application Send File CommonLine Release 4 File structure The Application Send File may consist of seven record types. The header record, Application Send (@1) Detail Record(s), and trailer record are required for SBS and service providers to support and must be included in all Application Send Files. The Unique Supplemental (@2) Detail Record(s) are optional depending on the agreement with the service provider. SBS is not required to support Detail Record. Alternative Loan (@4) Detail Record(s), Reference (@5) Detail Record(s), and Supplemental Borrower Information (@7) Detail Record(s) are optional depending on the agreement with the service provider. All SBS must support Detail Records. Detail Record is optional for SBS to support. If organizations receive information for which they have no agreement to accept, they should ignore the information, and should not produce a fatal processing error. The following table provides summary information about each record in the Application Send File. Record name Record code These records... Header Describe the data that follows and identify the file as an Application Send File. Also identify the sender and receiver of the file. Application Send Detail Contain basic data elements used in processing the application. This record type is required and must be completed as described in the file description for correct processing. There must be Detail Record in the file for each application. Unique Supplemental Detail Are used by the service provider to address unique services it offers that are not standard to CommonLine. If organizations receive unique information for which they have no agreement to accept, they should ignore this information, and should not produce a fatal processing error. If included, Detail Record must immediately follow the corresponding Application Send (@1) Detail Record. 4-2 Issued: 01/15/2009