1. CommonRecord: CommonLine Implementation Gary Allen David Steiner

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

3. 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.

4. 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

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

6. 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

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

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

9. 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

10. 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

11. 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.

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

13. End-Result Change Model  Comparison to CL4 Transaction Model Eliminates need to determine transaction type (@1-09, 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.

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

15. 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

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

17. Questions ?

18. Contact Information  Gary Allen Senior Product Manager, Oracle gary.x.allen@oracle.com 925-694-6197  David Steiner Project Manager, Foundation for Educational Services (FES) davids@fes.org 402-479-6970