# Presentation: 432841

## Common Record: CommonLine Implementation for FFEL and Alternative Loan Schools

- Kim Shiflette, USA Funds
- Bob King, Citibank

***Session 2***

## Session Objectives

**Overview**
- Convergence/Benefits
- Business Requirements
- Key Differences from CommonLine
**CR:C Process**
- Loan Request
- Change Request
- Response
- Disbursement
**What’s Next  - Steps and Timing**

## CR:C Defined

- Common Record: CommonLine (CR:C)
- The new XML-based electronic data exchange standard for FFELP and alternative loan origination and disbursement processing

## Convergence – Historical Perspective

- FFELP was pursuing implementation of  CommonLine 5.0 - Flat and XML
- At the same time SIS and FAMS vendors were implementing FSA’s new COD Common Record XML requirements
- Late 2001, began to consider the benefits of converging CommonLine and Common Record
- Fall 2002, convergence proposal approved by the Electronics Standards Committee (ESC)

## Convergence – Efforts

- The FFEL community, through the ESC and PESC, invested heavily in the convergence effort over the past year
- Created a Common Data Dictionary across higher education
- Developed similar XML schemas
- Similar processing concepts where appropriate and possible

## Data Dictionary

- Defines names and characteristics of data to ensure common understanding

## XML Schema

- In ordinary English, definitions related to Schema include:
- A diagrammatic presentation
- The disposition of constituents in a pattern or according to a scheme
- A scheme or systematic arrangement
- In XML terms it describes and constrains the content and sequence of content of XML documents

## Benefits of XML and CR:C

- Allows schools to use one Record structure between disparate databases or different systems - COD, CL, Meteor, Transcripts, etc.
- Streamlines the automation of Application and Disbursement Processes
- Converts Change Processes from  Transaction-based to End Result-based
- XML is Human Readable

## Benefits – cont.

- Common Record: CommonLine can support **batch** and **real-time **data exchange
- CR:C’s XML record structure is **flexible**
- XML let’s you send **only the data needed** for the process being performed
- CR:C is designed to meet the **needs** of the **Schools** and **FAMS Vendors**

## Business Requirements

- Maintain current CommonLine 5 functionality
- Maintain flexibility of FFELP processing for our School customers
- Emulate CR:COD where applicable - structure, process and naming convention
- Create a cross-industry data dictionary

## Collaboration

- Reengineering required highly cooperative collaboration between organizations
**NCHELP Electronic Standards Committee**
- Responsible for the creation and maintenance of standards for the electronic exchange of information for FFELP and alternative loans
- Diverse industry representation
**Post-Secondary Electronic Standards Council (PESC) **
- Serves as an umbrella organization for all wishing to support electronic standards in higher education
**Department of Education FSA**

## Key Differences

- New formats, new names
- Loan Period Begin and End dates are now referred to as <**FinancialAwardBeginDate>** and **<FinancialAwardEndDate>**
- Words are used when possible to represent information. For example, US Citizen value is now “USCitizen”
- One student - multiple requests
- No trailer or reconciliation at the document level
- Records sorted by attending school
- All “Requests” can be sent in the same document
- Supports School Assigned ID - student/borrower

## CR:C Structure

**Record Structure - building block**
- Document (header info)
- Attended School (students are grouped by school)
- Student (personal data - name, ssn, address, etc.)
- Loan (application data - loan period, grade level,etc.)
- Award (loan data - certified amounts and dates, person information for borrowers who are not the student, co-signers, etc.)
- Disbursement (disbursement information)

## CR COD Document Structure

## CR CommonLine Document Structure

## CR:C XML Structure

- <CommonRecord>
- 	<DocumentInformation></DocumentInformation>
- 	<AttendedSchool>
- 		<Student>
- 			<Loan></Loan>
- 			<Award></Award>
- 				<Disbursement><Disbursement>
- 		</Student>
- 	</AttendedSchool>
- </CommonRecord>

## CR:C Supported Processes

- Loan Requests
- Loan Reprint Requests
- Loan Termination Requests
- Loan Certification Requests
- Pre-guarantee Correction Requests
- Post-guarantee Change Requests

## CR:C Supported Processes

- Change Requests
- Student Borrower Changes
- Address Change
- Phone Change
- E-mail Address Change
- Loan Changes
- Student Level Code Change
- Financial Award Period Change
- Graduation Date Change
- Guarantee Increase
- Loan Reduction

## CR:C Supported Processes

- Change Requests (cont)
- Pre-disbursement Changes
- Disbursement Date Change
- Full Disbursement Cancellation
- Partial Disbursement Cancellation
- Full/Partial Disbursement Increase and/or Reinstatement
- Add a disbursement
- Hold and Release Change
- Combination Changes
- Loan Reallocation with Post-disbursement Cancellation
- Loan Reallocation with Loan Increase
- Guarantee Increase and Disbursement Addition or Disbursement Date Change

## CR:C Supported Processes

- Change Requests (cont)
- Post-disbursement Changes
- Full Disbursement Reissue
- Partial Disbursement Reissue
- Full Disbursement Cancellation
- Partial Disbursement Cancellation
- Full or Partial Disbursement Reinstatement
- Post-withdrawal Return of Funds
- Post-withdrawal Return of Funds Correction
- Responses to Requests
- Snapshot
- Full
- Standard

## CR:C Loan Request Process

- Same Business Process - New Structure
- All requests are combined in one record
- no more @1, @4, @7, @8 records, etc.
- No more Record Type Indicators (A, C, R, T)
- “Request”: Loan Request (Reprints, Terminates and pre-guarantee corrections) and/or Post-Guarantee Change Requests
- “Application”: Loan Requests only
- “Change”: Change Requests only

## CR:C Loan Request Process

- Some Additional Features:
- Disbursement Day Override Indicator
- Ability to pass Credit Status data
- Minimal data for Pre-guarantee Corrections, Reprint and Terminates
- Disbursement Amounts can be passed for Stafford and PLUS requests

## CR:C Change Request Process

- New Business Process - New Structure
- Results oriented process
- Multiple updates with one record - no more @1-05, @1-07, etc.
- Only changed data elements need to be sent
- It is up to the recipient to determine the intent of the request.
- Only one change per element per student may be requested in each document.
- Intended to be easier for SIS and FAMS providers to design and program the change processes

## CR:C Response Process

- Same Business Process - New Structure and Formats
- Modified Error Codes to be more COD like
- Response format override capability -<FullResponseCode>
- Responses are associated to each individual block of the request document  - not to the record
- Service provider may accept one block of the student’s loan request, while rejecting other sections
- Unlimited error codes

## CR:C Response Formats

- There are 3 Response Formats now available
- Snapshot: An image of the student and loan data on the service provider’s system at the time the response is created plus response data
- Full: Data tags and values sent in the original change request plus response data
- Standard: Response data only
- Response Data includes:
- Processing Status of the request
- Any errors identified during processing of the request

## CR:C Process: Disbursement

- Same Business Process - New Structure
- Separate Document Types for Disbursement Roster,Forecasts and Acknowledgements
- Disbursement Acknowledgement contains response data and has it’s own schema

## Progress Report

- Collaboration continues to move us forward
- Schools, The College Board, Datatel, Oracle, PeopleSoft, SCT Corp., and Sigma Systems have all indicated their support of the new CR:C standard
- Lenders, guarantors, and servicers have also indicated their support and intent to implement the new standard

## Documentation

- Implementation Guide development has proceeded at an accelerated pace
- “Final” documentation published – July 2003
- Review and updates to documentation - On-going
- Documentation Includes:
- Implementation Guide
- Core Components Data Dictionary
- Schemas
- Instance Documents

## Documentation

- The Implementation Guide includes:
- Business rules
- Data definitions and valid values
- XML Document Element Layouts
- XML standards information
- Glossary
- Data Crosswalk documents
- Error Codes

## Next Steps for FFELP

- Fine tune and finalize schema development
- Fine tune and update the documentation  - version 1.03
- Review and resolve reported issues and questions
- Provide ongoing training, education, and outreach
- Encourage FFELP community transition to the new standard

## Training

- CR:C Training Sessions provide a detailed orientation and introduction to the CR:C standards
- Potential future dates:
- July - Portland
- October/November - TBD
- Training sessions are two full days each
- Session feedback has been very positive

## CR:C Testing Tool

- Verifies format, content and provide cross field validation
- Used to provide common validation of the interpretation and programming of the Implementation Guide and to certify participants
- Loan Request  - February 04
- Response - Spring 04
- School Certification - Spring 04
- Disbursement - Summer 04
- Change - Fall 04

## Data Transport Standards

- The ESC has initiated a collaborative effort with software providers, FSA, ELM, lenders, guarantors, and servicers to identify standard transport tools and protocols that can be employed as a standard across higher education for the batch and real-time electronic exchange of data.
- Particularly important because of the large data payloads resulting from the use of XML data structure

## Implementation Schedule - FAMS Vendors

- The Electronic Standards Committee has been in close touch with College Board, Datatel, PeopleSoft, Oracle, SCT, Sigma for their plans.
- All are in various stages of analysis and are forecasting production implementations between Fall ’04 and Spring ’05.  Sigma is looking for testing partners in Summer ’04.

## Implementation Schedule - Service Providers

- Most lenders, guarantors, and servicers are planning schedules parallel to the vendor timelines.
- Most are too early in analysis to determine if their implementation strategy will be all-in or phase-in.
- If phase-in, most would implement in lifecycle sequence

## What this means for Schools

- Schools with a FAMS system
- Stay in touch with your vendor for updates on their implementation plans and your options.
- Encourage your vendors to continue their development of CR:C functions
- Schools that do their own programming
- Access all of the documentation available online for your IT staff
- Attend training

## What this means for Service Providers

- Service providers will continue to support their current versions of CommonLine flat files
- Upgrade systems to support the CR:C XML process by:
- Developing a CR:C XML system
- Buying a system that supports CR:C
- Translating XML to flat file and back
- Data Crosswalks provided for translating

## Information Sources

- NCHELP - The CR:C Implementation Guide is available at www.nchelp.org
- IFAP – COD news, technical documentation, updates, etc. at www.ifap.ed.gov
- PESC – XML Technical Specifications, Data Dictionaries, Schemas, assistance and approvals, etc. at www.standardscouncil.org

## Technical Assistance

- We appreciate your feedback and comments.  We can be reached:
-     **Kim Shiflette****	****	****	****Bob King**
**Phone: 317 806-1212****	****	****	****585 248-7140**
**Fax: 317 806-1203****	****	****	****585 248-7515**
**Email: **_[Kshiflet@usafunds.org](mailto:Kshiflet@usafunds.org)_**  **_[robert.l.king@citigroup.com](mailto:robert.l.king@citigroup.com)_** **