# Presentation: 765717

## Presented by:

## Session 53

***CommonLine Release 5***
***Setting the Standard***

***Presented by:***
***Tim Cameron – NCHELP***
***Candy Pfeiffer – Great Lakes Higher Education Corp.***

## AGENDA

- Welcome
- CommonLine Defined
- Governance
- CommonLine Benefits
- Functionality & Release 5 Enhancements
- Implementation
- Data Exchange
- CommonLine and XML

## CommonLine Defined

- CommonLine is...A standardized format & delivery process for the exchange of origination & disbursement, and change transaction data between schools & their federal & private student loan service providers.

**Notes:**
NCHELP initiative – started in 1995
Developed collaboratively by schools and student loan industry service providers for federal and private student loans
Prior to CommonLine, communicating electronically with service providers involved supporting numerous proprietary software products, file formats, transmission methods and process flows.
Today a school can use one CommonLine compliant product to communicate electronically with all its CommonLine service providers.
For service providers it is much easier to implement new relationships in the industry since most agencies already support CommonLine.  
These CommonLine formats and processes are adhered to voluntarily by industry participants.

## CommonLine Defined

- Standard What?
- Data formats
- Process flows
- Data exchange mechanisms
- Expectations

**Notes:**
Standard Data formats supported by most lenders and guarantors in the industry
Standard Process flows so you can tell CommonLine participants how you want an application to process
Standard Data Exchange Mechanisms so only have to support one file transmission method to communicate with everyone.
All these add up to standard expectations!

## CommonLine Defined

- Standard Transactions:
- Application Send File
- Change Send File
- Response File
- Disbursement Roster

**Notes:**
App Send – typically where the process starts
Chg Send – if you need to change something on the loan after it is guaranteed
Response – service provider reporting back to you on status of the loan
Disbursement Roster – electronic roster detailing all the funds which were disbursed
Acknowledgement file between CDA & service provider

## CommonLine Defined

- Transmission Protocols:
- 	 Email
- FTP
- High Performance Channel

**Notes:**
Email transmissions with data encryption
FTP – directory structures, file naming
High Performance provisions – working toward real time processing and instantaneous transaction turnaround required by web-based and business to business processes

## Governance

- Electronic Standards Committee
- Advisory Teams
- Steering Committee
- School Advisory Group

**Notes:**
CL governed at several different levels
CL governed overall by ESC
ESC made up of advisory teams for each of the different aspects of the electronic loan delivery process
ESC guided by Steering Committee
School Advisory Group ensures that ESC continues to meet the schools’ needs in the continually evolving world of student loans

## Governance

- Mission – to create & maintain standard electronic data formats & data exchange mechanisms which support the loan delivery process (application, approval and disbursement) between schools & their federal & private student loan service providers and the account maintenance process between service providers.

**Notes:**
CommonLine started out in 1994 as an NCHELP Workgroup
In 2000 CommonLine joined several other electronic standards groups within NCHELP to come under the umbrella of the newly formed NCHELP Electronic Standards Committee
ESC is comprised of the primary stakeholders in the loan process
Schools
Guarantors
Lenders
Secondary markets
Service providers
FAMS providers
promote the timely development of electronic communication standards 
streamline the development of new standards as well as the maintenance of existing standards 
promote new and existing standards, and facilitate their implementation
focal point for standards information
Works to build awareness of the role of standards in the higher education loan community
Note:  The governance of the ESC encompasses the entire life of the loan from application initiation through repayment, payoff or default.

## Governance – ESC Advisory Teams

- CommonLine Origination & Disbursement
- Change Transactions
- General Common Account Maintenance
- Default Aversion & Claims
- Electronic Exchange
- Communications & Training
- Testing & Certification

**Notes:**
Currently Seven advisory teams reporting to the full committee
teams are responsible for recommending changes to the files as necessary due to regulatory changes, errors, or enhancements to processing
O&D
It is the initial point of contact for industry issues surrounding the CommonLine Origination and Disbursement process.  
Change Transactions
It is the initial point of contact for industry issues surrounding Change Transactions
Supports transmission of post guarantee changes
GAMAT – this group (and DACAT) works with the Common Account Maintenance (CAM) file formats for the exchange of data between service providers post guarantee.  Their work helps ensure that the data exchanged between service providers is standardized, timely and accurate.
DACAT – 
Electronic Exchange – ensure that the transmission methods supported within CommonLine are up to date, flexible and secure
Communications and Training – provide the industry with updates on ESC activities via the NCHELP website, the CommoNews newsletter and training sessions such as this.

## Governance – Testing and Certification Advisory Team

- Mission - To enable the maximum number of CommonLine participants to make a smooth, uniform, and on-time transition to Release 5 by providing a formalized interagency testing structure, clear compliance & implementation guidelines, & a common testing tool.

**Notes:**
With each implementation of CommonLine
industry participants have made modifications in the ways in which they do business to meet new industry standards. 
Issues with slightly differing interpretations of file specs
Agencies test with a few primary and encounter no problems but a new participant has problems with a code or data element which the others ignore.
Difficulties with testing with multiple agencies simultaneously 

Each of these scenarios has resulted in undesirable impacts to client schools. 

T&C formed in September 2000 by the Electronic Standards Committee with instructions to identify and resolve as many of these types of issues as possible prior to the implementation of CommonLine Release 5.  With these guidelines, T&C is developing file specifications for the CommonLine r5 File testing tool.

clearly define processing rules and expectations for the programmers of the T&C Testing Tool
resulted in tightening of the specs.  
System Specs for the Testing Tool have been finalized for the Application Send File and Response File.  ESC is being asked to give final approval to the System Specs for these file formats later this week.

workgroup is slated to become a permanent Advisory Team of the ESC to ensure the continued support of clear compliance and implementation guidelines of all ESC initiatives (can I say this at the Monday presentation or would I be jumping the gun?)

## Governance –ESC Steering Committee

**Notes:**
represents a mixture of individuals familiar with Operations, Technology and Marketing within the FFEL Program
represents a cross-section of the industry.  
many members are also members of the Electronic Standards Committee as overlap is necessary for open communication between the two groups. 

Mission – to strategically direct the Electronic Standards Committee as well as serve as a resource for the ESC for industry initiatives

## Governance –ESC School Advisory Group

- A mixture of individuals from various types of schools.
- A sounding board for the ESC and its Advisory Teams
- Membership includes representatives from schools that do their own programming for loan delivery as well as those that utilize third-party software.

**Notes:**
Membership on the committee represents a mixture of individuals from various types of schools.
Members are appointed by the NCHELP  Board of Directors. 
Serves as a sounding board for the ESC and its Advisory Teams
Membership includes representatives from schools that do their own programming for loan delivery as well as those that utilize third-party software.   
Several of the School Advisory Group members are active participants in other ESC Advisory Teams which helps to ensure that communication is open between this group & ESC.
ESC meetings are open to schools
welcome and encourage any schools who are interested in getting more involved, to do so.
The more school involvement we have, the more we can be sure we can support each school’s unique processing needs.
CommonLine has been built with the focus on the school as the customer since in most cases the school begins the whole process.
CommonLine built with the understanding that each school has specific relationships and processing flows that needs to be supported.  Some schools work with just a few agencies and communicate directly with the guarantor.  Others communicate directly with lenders.  Still others work with large numbers of different agencies using both a lender and a guarantor flow – depending on the specific service providers.  CL has been built to support all these diverse scenarios.

## CommonLine Benefits

- Standardization
- Flexibility
- Software Products
- Transmission Methods
- Alternative Loans
- Cost Savings
- Student Benefits

**Notes:**
There are many benefits for schools who use CommonLine
Standardization:  Schools can use one set of file formats for all service providers.  These formats include app send, response, changes and disbursement files
Flexibility:  Schools can decide who to work with, how to transmit data, and what CommonLine functionalities to use.  
Software Products:  There are many software providers who use CommonLine From FAMS vendor products to SBS.  Or a school could develop their own products
Transmission Methods:  Schools can choose to transmit using Email, FTP or in the near future, they will be able to use the High Performance Channel for near-real time processing (we will discuss later during the presentation)
Alternative Loans:  Remember, CommonLine supports many alternative loan programs in addition to FFELP loans.
Cost Savings:  By only supporting one set of file formats and one transmission method schools are able see a great cost savings over supporting multiple products
Student Benefits:  Included in CommonLine are functionalities that will provide student benefits as well.  For example, the school can receive regular status updates on their loans in order to provide the student with current information on their loans.  In addition, using the electronic methods can reduce the time it takes to process loans.  

## Functionality – Application Send File

- Generally begins the process
- School requests processing option
- Guaranty only
-  Guaranty & print
-  Print & guaranty
-  Print only
- Hold and Release
- Application Correction Process
- E-Sign indicator added

**Notes:**
Generally, the first step to processing a loan is the application send file.  

Included in this file is the school’s requested processing option for each loan.

Schools can request the the first step be to guaranty the loan only – this is especially beneficial to those schools who choose to print their own promissory notes. 

If the school wants the receiving organization to print the prom notes, they can choose whether to request to guaranty & print (in this case the promissory note will be printed only after the loan is guaranteed), or print and guaranty (in this case the promissory note will be printed, and after received the loan will be guaranteed).

Another option is to request that the loan not be guaranteed at all, that they only print the promissory note at this time.

Don’t forget about Hold and Release.

## Release 5 Enhancements Application Send File

- Credit only request
-  Credit & print request
-  Request more than 4 disbursements
-  Up to 20 is the standard
-  MPN processing
-  E-Sign

**Notes:**
With the exception of MPN processing, these changes are additional services and are optional for the service providers. Schools should check with their service provider before utilizing these options.

Schools can submit pre-approval credit requests for both Plus and alternative loan programs.  The response file will indicate whether or not the credit is approved, but no further processing will be done on the loan.  Schools then send an app send correction file to continue the processing of the loan.  This should help to eliminate the many proprietary forms to pre-approval credit processing schools currently use.

When a school requests a credit and print, a prom note will be printed and sent to the borrower only if the credit is approved.  Again the school would submit an app send correction file to complete the process.

Another service that is available through release 5 is the option of having more than 4 disbursements.  The standard is to offer up to 20 disbursements, but this is up to the individual service providers.This can be beneficial for schools with various delivery styles and distance education.

Have made some improvements that will enhance MPN Processing both for Stafford and the future MPN processing for PLUS loans.  Minimal changes will be needed for PLUS.

## Functionality – Response File

- Provides status information to the schools
-  Status of the loan
-  Approved loan & disbursement amounts
-  Approved disbursement dates
-  Error codes for rejected records
- Also used to begin the school certification request (SCR) process

**Notes:**
The response file provides the school with critical information about the loans they have requested

First it provides the status of the loan – guaranteed, ready to disburse, etc.

It also provides the approved loan amounts, disbursement amounts and disbursement dates.

If a record is rejected, the file will also provide an error code which helps the school know why the record rejected.

This file is also the beginning step for the school certification request processing option (this is where a student begins the process directly with the service provider and they, in turn, submit the response file to the school for certification figures.)

## Release 5 Enhancements Response File

- Loan status reporting is more detailed
- Replaced single loan phase code with multiple
- status codes
- Guarantor status
- Lender-servicer status
- Promissory note status
- Credit status

**Notes:**
Currently, there is one Loan Phase Code to determine the complete status of the loan.  This has caused confusion because the schools must interpret what the various codes mean based on who sent the file.  

This “rolled up” summary of the loan status has been replaced by 4 status codes to provide a more complete response to the schools. 

Under Release 5, there will be 4 Status Codes used to determine the status for the loan.
Guarantor Status
Lender/Servicer Status
Promissory Note Status
Credit Status

Having these 4 areas separated, allows multiple events to be reported in a single record.  For example, a school could receive a reject for prom note and a guaranty approval at the same time.

## Functionality – Change Transaction File

- Many types of changes can be requested (both pre & post disbursement)
- Loan period, grade level, anticipated grad date
- Loan cancellation
- Disbursement cancellation, change, reinstatement
- Reallocation between sub & unsub
- Loan increases
- E-mail information updates

**Notes:**
Using CommonLine Change Transaction Processing, schools can make many pre & post disbursement changes.  For example:

Loan Period
Grade Level
Anticipated Graduation Date
Cancel Loans
Cancel Disbursements
Change Disbursements
Reinstate Cancelled Disbursements
Reallocate funds between sub and unsub
Increase Loans
Give the servicer providers updated email information

## Release 5 Enhancements Change Transaction File

- Ability to send demographic changes
- Revised the records for post-withdrawal return/refund detail
- Revised the record to reverse post-withdrawal return/refund detail
- Redundant data eliminated from records
- Only one change type per record

**Notes:**
In the past, there has not been a simple method for schools to give updated demographic information to the service providers.
	Previously went through SSCR
	Or was individually sent to service providers via web or paper processing

With Release 5, schools can send demographic changes to their servicer providers using change transactions.  This can be major benefit to both schools and borrowers as we will be able to quickly and easily update addresses for our students.  This is an optional service for service providers.  Schools should check with their service providers to determine whether or not they offer this service.

In addition, the file formats have been changed for the Post-Withdrawal Return/Refund calculation to make these a disbursement-level change transaction rather than at the loan-level.  This helps the service providers know how to process the transaction.  

Much of the redundant data has been eliminated.  For example, schools no longer need to send much duplicate information in the borrower detail record and each change transaction record.  Also, schools no longer need to include old values in the change records; they simply indicate the new value for the changed fields.

Now each record will only include one type of change.  

## Release 5 Enhancements Change Transaction File

- Release 4 @7  single record
- Loan period change and/or
- Grade level change and/or
- Anticipated graduation date change
- Release 5 @7 multiple records
- @7A – loan period change
- @7B – grade level change
- @7C – anticipated graduation date change

**Notes:**
Previously the @7 record could include grade level, loan period and/or anticipated grad date changes.  

The Service Provider needed to determine what changes the school was requesting based on the data in the record.

Now there are 3 @7 records and the school will only send the appropriate record(s)
	@7A = Loan Period Change Request
	@7B = Grade Level Change Request
	@7C = Anticipated Graduation Date Change Request

The Service Provider can easily determine what changes the school is requesting based on the record type they are sending.

## Release 5 Enhancements Change Transaction File

- More detailed responses
- The response file will contain a copy of the record submitted & the status for requested change
- Processed
- Duplicate change request
- Forwarded to another provider for processing
- Pending
- Rejected (includes error codes)

**Notes:**
Now each requested change record can have it’s own response record returned to the school with the status for the response.
Processed
Duplicate change request
Forwarded to another provider for processing
Pending
Rejected (this will also include error codes to identify the reason for the reject)

The @6 response record has been modified to allow a detailed response to the requested change.  This record will be sent to the school showing the status of the change along with a copy of the change transaction record the school had originally submitted.  

Previously the school only received a snapshot of the record after the service provider received (and possibly processed) the change transaction. The school then needed to determine what fields had changed in order to know whether or not the change had been processed.  

Now the school will get a copy of the change transaction submitted along with a field indicating the status of the requested change.  Since each record includes only one change type, there is no risk that the service provider will only partially process the requested record.

For example, if the school requested a loan period change and an anticipated graduation date change, 
the grad date change record may be returned with a response indicating that it has been processed.
However, the loan period change may be returned with a status code indicating that it is in a Pending status (this may be necessary because of needing a revised guaranty).

## Functionality – Disbursement Information File

- Provides the school with detailed disbursement information
- What loans
- How much
- How funded (check, EFT, etc.)
- What lenders
- Provides the necessary information to reconcile the school records

**Notes:**
The Disbursement File provides schools with the necessary detail about the loan disbursements being given to the school.  

It includes what loans are being disbursed, how much, how they will be funded (eft, check, etc), and what lenders are included.

This information is necessary for the school to reconcile their funds and to know what students they should pay.

## Release 5 Enhancements Disbursement Information File

- Can be used for disbursement forecast file
- Provides a single file format for both disbursement forecast & disbursement roster files
- Remember, you can have more than 4 disbursements!

**Notes:**
In the past, the Disbursement File was only submitted when the funds were actually paid – as a disbursement roster file.

Now, the same file format can be used as a disbursement forecast file.

This allows schools to know what loans are scheduled to be disbursed in the near future so that they can make the necessary preparations to disburse the funds or send a change transaction to delay the disbursement.

Many schools have used a similar process, but in a proprietary format – now they can have this same functionality in a CommonLine format.

In addition, don’t forget that you can have more than 4 disbursements now with CommonLine.  The standard is up to 20!  Check with your service provider to see what they plan to offer.

## Implementation –School Decisions

- Determine desired process
- Set up guarantor/lender/vendor relationships
- Analyze system capabilities

**Notes:**
If CommonLine sounds like what your institution needs, you may be asking if it really could fit in with your institution’s unique processing methods
Schools with diverse system setups all participate in CommonLine – whether in batches of hundreds of certifications on on-line data entry batches of 1-2.
Batch methods
School mainframe to Service Provider
School mainframe to FAMS to Service Provider
School mainframe to FAMS to SBS to Service Provider
School mainframe to SBS to service provider
On-Line Data Entry
SBS to Service provider

Take a good look at how your institution processes and determine what setup would work for you
Take a look at your lender and guarantor relationships – they don’t need to change.  CommonLine supports the flow of your data directly to your guarantor or lender or any other combination you determine.

Even have different processing flows for different loan types, or different lender/guarantors
federal Stafford 
PLUS 
alternative

Linda to discuss additional benefits of CommonLine and the new functionality of CommonLine v5

## Implementation – Issue Reporting/Tracking

- Online submission
- Three sort options:
- By Issue Number
- By File Format Version
- By File Format Version – programming changes ONLY.

## Implementation – Compliance for 2002-2003

- Minimum provisions and expectations for April 1, 2002:
- Support of CommonLine 4 & 5
- Support of encrypted email
- Readiness Survey

**Notes:**
CL 95, 96, and R3 are eliminated with deployment of CLR5.  Use of CompuServe should already have been eliminated as among other reasons CompuServe never tested their products for Y2K compliance and refuse to do so and to meet school needs, CL migrated away from a private network to the internet (email).
Possible phased-in approach of CLR5 based on functionality.
Compliance is set to ensure compatibility across the industry.
Compliance for data exchange does not mean that your organization cannot use other transmission methods.  It means that of all methods your organization uses, encrypted email MUST be one of them.
FTP is optional.

## Data Exchange Requirements

- By April 1, 2002, support of Open PGP encryption RFC 2440
- By April 1, 2002, support of LZSS file compression
- By April 1, 2002, support of both active and passive FTP RFC 959 for those that support FTP
- Support of Secret Agent v 4.0 is eliminated by April 1, 2003

**Notes:**
More specific guidelines and requirments for data exchange.

## Data Exchange – The High Performance Channel

- Point to point (B2B & B2C) interface
- Data can be received, transmitted, processed, and responded to instantly and in real time or near-real time
- Open, using agreed-upon technology-based standards

**Notes:**
Focused on improving data exchange.
Once a night batch processing may not meet today’s needs.
Incorporate new technologies, but not so technically complex that it takes too long to build or costs too much.
Transmission protocols include HTTPS and SOAP.
Synchronous and asynchronous.

## CommonLine and XML 

- ESC and the Common Record
- ESC and PESC
- ESC CommonLine XML Workgroup

## www.nchelp.org	

- Electronic Standards Committee page
- Advisory Team Pages
- File Specifications
- Newsletters
- Issue Tracking and Reporting
- CommonLine Codes
- CommonLine/CAM Surveys
- Presentations

## CommonLine Release 5 Setting the Standard!

**CommonLine Release 5 Setting the Standard!**

**Notes:**
Remember the nchelp website...www.nchelp.org.