CommonRecord: CommonLine Implementation Gary Allen David Steiner

Session Overview  Benefits of CommonRecord:CommonLine From School and Trading Partner Perspectives  Development and Implementation Pitfalls to Avoid

The Importance of Standards  Standards facilitate efficiency.  Standards make training and cross-training easier.  Standards reduce change for the sake of change.  Standards align processes with COD.

XML: the Technology Solution  Standard Language of E-Business and The Internet  Lets The Industry Describe Virtually Any Type of Data  Standardized Validation of Data Order and Content  Greater Interest in New Technology by Developers  Allows Easy Inclusion of Other Student Data in a Single File

Streamlines Schema Changes  Old XML Tags Remain The Same  Only Need to Add Code for New or Enhanced Data Elements

The Common Record  Consistent Data Packet Layout  Across Programs Pell, Direct Loans, FFEL, Campus- Based, Loan Counseling, Transcripts, etc.  Major Stakeholders FSA, CommonLine, Meteor, AACRAO, MYF

Reduces Double Entry  Reduces or Eliminates Data Entry into Multiple Systems  Reduces or Eliminates Manual Processing

School-Assigned Student ID  Trading partners have the tools necessary to help track student IDs.  Helps schools address privacy concerns.

Streamlines Loan Status Information  Four Independent Statuses Guarantee Status Promissory Note Status Credit Approval Status Lender Approval Status  Not Limited to One Loan Phase Code  Schools Have Fewer Interpretation Issues  Trading Partners Each Have Their Own Status to Update Independently

Flexible Disbursement Processing  More Than 4 Disbursements  Separate Disbursement Dates for Subsidized and Unsubsidized Loans  Ability to Indicate Disbursement Amounts  Ability to Override Disbursement Profiles

Real-Time Processing  Sets the Framework for Real- Time Processing It is up to individual trading partners to add support for real- time processing. The PESC DTS Workgroup is currently developing real-time standards.

Streamlines Alternative Loans  Consistent Process Between Stafford and Alternative Loans Eliminates Alternative Loan Addendum Records Alternative Loan Data Easily Incorporated Into XML Structure

End-Result Change Model  Comparison to CL4 Transaction Model Eliminates need to determine transaction type etc). Eliminates sending multiple transactions to achieve desired result. Only changed fields will be sent to your service provider.  Much Easier from School’s Perspective  Challenging for Trading Partners Most indicated it was similar to what they were doing with CL4 data already.

Implementation and Development Pitfalls  Schema Changes  Logic of Backward Compatibility  Combination of Loan Types in The Same Document

Pitfalls to Avoid con’t  Combination of Pre-guarantee and Post-guarantee Records in The Same Document  End Result for Corrections and Changes  Larger File Size

Pitfalls to Avoid con’t  Validation Issues with Documentation and Schema  Early Adopters – Trading Partners  School-Assigned Student ID Stored One Per Person

Questions ?

Contact Information  Gary Allen Senior Product Manager, Oracle  David Steiner Project Manager, Foundation for Educational Services (FES)