# Presentation: 828892

## CommonLine and the Common Record: The Building of Convergence

- Kim Shiflette, USA Funds
- Bob King, Citibank Student Loans

***Session 34***

## Session Objectives

- Understanding
- Convergence
- XML
- Common Record
- Common Record: CommonLine
- Benefits for Software Vendors
- Benefits for Schools
- Next Steps and Timing

## Convergence - An Evolution

- The FFELP community was pursuing implementation of its newest standard, CommonLine 5.0
- At the same time SIS and FAMS vendors and schools were understanding FSA’s new COD Common Record requirements

## Convergence - An Evolution

- Software vendors began meeting in late 2001 to consider the benefits of convergence of FFELP’s CommonLine and FSA’s Common Record requirements
- Consensus was reached by the vendors that striving for a single data standard was preferable to implementing two divergent standards

## Convergence - An Evolution

- The convergence proposal was brought to the NCHELP Electronic Standards Committee (ESC) for review and consideration
- The ESC, representing the FFELP community, concurred with the vendor’s proposal and has invested heavily in the convergence effort over the past year

## Convergence - An Evolution

- Common Data Dictionary across higher education
- Similar XML schemas
- Similar processing concepts
- Business rules as much the same as regulation and product function will allow

## Why Adopt XML?

- XML is **technology-neutral**, allowing trading partners to use different technologies in their own applications
- XML allows schools to use one **Common Record** between disparate databases or different systems
- XML allows users to **share information seamlessly**
- XML is **future-oriented**

## Why Adopt XML?

- XML can be used to support both **batch** processing and **real-time** processing
- XML provides **easy flexibility** between trading partners when needed
- Let’s you send **only the data needed** for the process being performed

## The Common Record

- Core Components Data Dictionary
- Common definitions
- Common values
- Schemas
- Common Record – COD
- Common Record – CommonLine
- Common Record – ISIR

## The Common Record

- Format is student-centric, showing data for multiple financial aid programs in one student complex element
- The entire common record or only those portions of the common record that changed can be transmitted

## The Common Record

- XML allows the Common Record to be easily changed (extensible)
- Format is human-readable, facilitating problem solving

## The Common Record Schema Structure

## CommonLine Reengineering

- Streamlining the application and disbursement processes
- All records sent in a single file
- Pre and post guarantee changes can now be sent together
- Routing is at the record level
- Moving from transaction based to end result based changes
- Support of real-time XML-based functionality

## CommonLine Reengineering

- Example – pre-disbursement cancellation
- In the CommonLine 5.0 process
- Change type code
- Loan Type Code
- Disbursement Identification Number
- Disbursement Date
- Cancellation Date
- Cancellation Amount
- Revised Disbursement Amount

## CommonLine Reengineering

- Example – pre-disbursement cancellation
- In the Common Record: CommonLine process
- LoanAmount		(new value)
- DisbursementNumber	(old value)
- DisbursementAmount	(zero)
- CancellationDate		(new value)

## CommonLine Reengineering

- CR:C supports the following:
- Loan Requests
- Certification Requests
- Disbursement Rosters, Acknowledgements, Forecasts
- Pre and post guarantee changes
- Pre and post disbursement changes
- Responses in three different models

## Common Record: CommonLine

- CommonLine converging and aligning with the Common Record
- COD standards with the flexibility of FFELP
- Supports all functionality available in CommonLine Release 5
- Supports FFELP and alternative loans
- Designed to meet the needs of
- Schools
- SIS/FAMS Vendors

## Convergence - An Evolution

- The reengineering of CommonLine to fit the Common Record model has been a highly cooperative collaboration
- NCHELP Electronic Standards Committee
- Postsecondary Electronic Standards Council
- Department of Education FSA

## Convergence - An Evolution

- Postsecondary Electronic Standards Council (PESC)
- Serves as an umbrella organization for all wishing to support electronic standards in higher education

## Convergence - An Evolution

- National Council of Higher Education Loan Programs (NCHELP) Electronic Standards Committee (ESC)
- Responsible for the creation and maintenance of standards for the electronic exchange of information for FFELP and alternative loans
- Diverse industry representation

## Common Record: CommonLine

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

## Common Record: CommonLine

- _Progress Report_
- Implementation Guide development has proceeded at an accelerated pace
- First draft for public review – May 2003
- Second draft for public review – June 2003
- Final documentation published – July 2003
- Review and updates to documentation - Ongoing

## Next Steps for FFELP

- Fine tune and finalize schema development
- Fine tune and update the documentation
- Review and resolve reported issues
- Develop a testing tool for CR:C
- Training, education, outreach

## Next Steps for FFELP

- CRC Training Sessions provide a detailed orientation and introduction to the CR:C standards
- Jacksonville on January 29-30
- Phoenix in February 23-24
- Additional as needed

## Next Steps for FFELP

- The ESC is initiating an effort in collaboration with the vendors and FSA to develop a standard transport for the transmission of batch and real-time data that could be employed across higher education for the electronic exchange of data.
- Particularly important because of the large data payloads enabled by XML

## The Implementation Schedule

- 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 Spring ’04.

## The Implementation Schedule

- Most lenders, guarantors, and servicers are planning schedules parallel to the vendor timelines.  AES is looking at Spring ’04
- 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
- Schools that do their own programming
- Access all of the documentation available online for your IT staff
- Submit questions and issues at www.nchelp.com for review and resolution by the NCHELP ESC

## Information Sources

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

## We’ll be happy to help

- We appreciate your feedback and comments, and welcome your questions.  We can be reached at:
- Kim Shiflette	317-806-1212
- 				kshiflet@usafunds.org
- Bob King		585-248-7140
- 			robert.l.king@citigroup.com