# Presentation: 432839

## Common Record: CommonLine Initiatives

- Kristi Blabaum
- Kim Shiflette

**Session 26**

## 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 FFELP community, through NCHELP’s ESC and PESC, has invested heavily in the convergence effort
- 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 - continued

- 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, processing, and naming convention
- Create a cross industry data dictionary

## Key Differences

- New formats, new names
- Loan Period Start and End dates are now referred to as <**FinancialAwardBeginDate>** and **<FinancialAwardEndDate>**
- Words are used when possible to represent information. For example, US Citizen value (1) is now “Citizen”
- One student - multiple requests
- No trailer or reconciliation at the document level

## Key Differences - continued

- Records sorted by attending school
- All “Requests” can be sent in the same document
- Supports School Assigned ID - student/borrower

## CR:C Record 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 (disb. info)

## CR COD Document Structure

## CR:C 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
- Response Processing
- Disbursement Processing

## 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

- 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
- Loan Reallocation

## CR:C Change Request Process

- 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

## CR:C Change Request Process

- Combination Changes
- Loan Reallocation with Post-disbursement Cancellation
- Loan Reallocation with Loan Increase
- Guarantee Increase and Disbursement Addition or Disbursement Date Change

## CR:C Change Request Process

- 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

## 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

**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 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 with 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 Disbursement Process

- 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

## 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**

## CR:C 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**

## CR:C Documentation

**Implementation Guide development proceeded at an accelerated pace**
**Documentation published – July 2003**
**Version 5 has now been published**
**Documentation Includes:**
**Implementation Guide**
**Core Components Data Dictionary**
**Schemas**
**Instance Documents**

## CR:C 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**

## CR:C Next Steps for FFELP

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

## CR:C Test 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  -  Available now**
**Response – Available  now**
**School Certification – Available now**
**Disbursement – Available now**
**Change – November/December 2004**

## Data Transport Standard

**The FFELP Community has initiated a collaborative effort, managed under PESC, 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**

## Data Transport Standard

**Business requirements**
**Any process expectation (immediate, deferred, other)**
**Any data (XML, flat file, image, etc)**
**Any business process (transcripts, loan requests, loan counseling, inquiries, funding, updates, etc)**
**Any system (Java, .net, etc)**
**Any time (24/7)**

## Data Transport Standard

**Business requirements**
**Secure Data Transport**
**Guaranteed delivery**
**Ensure cost and technology not a barrier **
**Utilize open standards**
**Support interoperability – platform independence**
**NO set payload limits**

## Data Transport Standard

- A reference implementation has been accomplished
- Interoperability between .net and Java has been solved
- Security issues have been solved
- Other aspects of the standard are being addressed
- Expect to publish standard in December

## Implementation – 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 Late Fall ’04 and Spring ’05.

## Implementation – Lenders, Guarantors, Servicers

- 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.
- Known phase-ins appear to be over months rather than years

## 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 if more is scheduled

## 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

## Some Considerations for Schools

- Ask your vendors and service providers for the functions that you need
- Check your implementation options
- Determine which processes are important to you and find out which are supported
- What methods will be used to send and receive data files?
- What loans are automated

## Some Considerations for Schools

- What disbursement options are offered
- Look at the processing benefits that you can derive from CRC and factor them into your planning for the future
- Look closely at your expectations for change processing
- Move to CRC as soon as possible

## 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.pesc.org](http://www.pesc.org/)_
- Registry and Repository – Current schema, dictionary, etc.  _www.fsaxmlregistry.ed.gov_

## Technical Assistance

- We appreciate your feedback and comments.  We can be reached at:
- Kristi Blabaum
- 770-529-0220
- _[Kristi_](mailto:Kristi_blabaum@educaid.com)__[blabaum](mailto:Kristi_blabaum@educaid.com)__[@](mailto:Kristi_blabaum@educaid.com)__[educaid](mailto:Kristi_blabaum@educaid.com)__[.com](mailto:Kristi_blabaum@educaid.com)_
- Kim Shiflette
- 317-806-1212
- _[kshiflet@usafunds.org](mailto:kshiflet@usafunds.org)_

## We welcome your:

- ????????????????????????????????????????????????????????????
- ???????????Questions???????????
- ???????????Questions???????????
- ??????????????????????????????
- ??????????????????????????????