Software Developers Conference

New York City, New York

March 31, 2004
 Welcome and Today’s Agenda

•Welcome and Opening Remarks

•Data Strategy Update
•Common Origination Disbursement (COD) Update
•Break
•Front End Business Integration (FEBI) Update
•Common Services for Borrowers (CSB) Update
•Panel of Experts/ Q and A
•Schedule Update and Wrap-up

Next Conference: August 19-20, 2004

Marriott Crystal Gateway
Arlington, VA
Data Strategy Update
 Data Strategy Purpose
Develop an overall approach towards data to ensure that accurate and
consistent data is available to and exchanged between FSA and our
customers, partners, and compliance and oversight organizations.
“The Right Data to the Right People at the Right Time”
11 12 1
10 2
9 3
8 4
7 6 5

§ Consolidation of Data § Enterprise Standard for § Integrated Student

into Shared Source Student Identification View
§ Focus on Data Quality § Integrated Partner § Integrated School
Management View
§ Enterprise § Foundation for more
Routing ID Timely and Efficient
Processing
§ Enterprise Access
Management
 Data Strategy
in the Press
“The Right Data to the Right People at the Right Time”
From the January 2004 issue of “The Greentree Gazette”

“FSA’s Data Strategy Initiative

is likely to have a significant
impact on FSA’s ability to serve
its customers. Its objectives
include an enterprise-wide
policy for managing and storing
data and an industry-wide
standard for publication and
dissemination. FSA staff
commonly refers to the critical
nature of ‘getting the right data
to the right people at the right
time.’”
 Data Strategy
Key Findings To Date
The Data Strategy teams have confirmed several key findings:
§ Data should be organized by business process, not by system.

§ Providing data access to business experts is the key component of

improving the enterprises’ ability to make informed business decisions.

§ Verified that using a Matching Algorithm with SSN, First Name, Last
Name, and DOB is the most flexible and tolerant way to identify
customers.

§ Need to develop a single Enterprise solution for all Trading Partner

Identification and Access.

§ “As-Is” Data Flow Discussions have facilitated a broader understanding of

End-to-End Business Processes across all FSA program areas.
 Data Strategy References
Aid Institution Institution

cy c le
Pha se
c yc le
Pha se

Aid Awareness & Application Delivery Servicing

Life -
Life -

Application Delivery Servicing Participation

Awareness Participation
/Borrow er
A pplic ant

/Borrow er
A pplic ant

Pr oc e s s
P roc e ss

Aid Education Submission Eligibility Repayment Consolidation Collections Aid Education Submission Eligibility Repayment Consolidation Collections

Students Portal Student Aid on the Web

Call Centers (Example - PIC) Call Centers
Ombudsman
Case Tracking Recommend Acquisition & EnterprisePerformance
Technology PIN (Ombudsman) PolicyChanges PlanningStrategy Enterprise Analytics and Research Management
Analytics
Enablers
NSLDS

Ente rpris e Sha re d

Ente rpris e Sha re d
Enablers Send/Receive from Matching Agencies Generate/Distribute ISIR/SAR Credit Check Audit History Transfer Monitoring Process Promissory Notes Servicing Reporting (FFEL & Campus Based) SSCR CDR
EAI
EAI
Enterprise
Common Data Architecture

Functions
Func tio ns
Application
Enterprise
Integration
Application NSLDS
Credit Integration
ITA FAFSA CPS Financial
Partners
Delinquent
Loan Management Students Trading FMS Warehouse/Data Marts
Enterprise
Content Metadata
Integrated
Data Mart Data Mart ITA Partners Repository
Technical
DataMart Transactions Management
Integrated
Architecture
Technical
Architecture Edit Checks SSIM Logic Match Against CDA (FAH) Distribute Eligibility Computation Edits - EFC RID Legacy Identifier Crosswalk Authentication & Access Management Partner Payment Calculation/PrePopulation
VDC
Virtual
VDC
FS A

Data Center
COD PEPS Virtual
Application Origination & Disbursement Common Services for Borrowers
DLCS Data Center

FSA
Establish Award & Disbursement School Aid Payments & Consolidate Recovery&
SSO Aid Person Aid Eligibility ServiceLoans CSB
Single Sign On
eZ- DLSS Authentication &
Awareness
Record
Determination Processing Funding Level Mgmt Loans Resolution
CDDTS Access Tools
Audit
SAIG
Student Aid
DMCS Application Partner Trading Partner Management Partner Eligibility Relationship
Internet
Business
Process Enrollment & Oversight Mgmt
Gateway
Intelligence
Tools
eCB Partner Payment State Agency
Payment Processing
Participation Admin Partner Payment Management Funding
Management
Ancillary
FMS Services
Process Funds & Internal External Financial GL
AR Managment
Payments Controls Financial Management Reporting
Budgeting
Accounting
SchoolsPortal

Financial Partners Portal

Help Desk (Example - NSLDS)
FSA Gateway
Schools Portal
Tra ding Pa rtners &

Financial Partners Portal

Schools ( School Servicer) Help Desk
Se rv ic e rs

State Agencies Lenders (LenderServicers)

Par tne rs &

Serv ic ers
Tra ding
Guaranty Agencies
State Agencies Schools ( School Servicer) Lenders (Lender Servicers) Guaranty Agencies
Other External Partners
Other External Partners
ED

Department of Education The Financial Aid

ED
FMSS Department of Education GAPS To-Be Financial
Partner Application Life Cycle Aid Life Cycle
Proc e s s
Trading
Pa rtner

Non-EAI Transfer High-Level Business View Partner Application

Proce s s
Pa rtne r
DRAFT

Tra ding
Internal Transfer Business Function
EAITransfer
External Transfer Origination & Oversight External Transfer High-Level Business View
Disbursement Origination &
Disbursement Oversight

The following Data Strategy Deliverables may be found on

the Library tab of the FEBI website under the Integration
Partner heading (http://www.febi.ed.gov/library.htm):
§ FSA As-Is Data Flows
§ To-Be Financial Aid Life Cycle Diagram
 Data Strategy 2.0
Institution

P has e
cycl e
Aid Awareness & Application Delivery Servicing

L if e-
Participation

Where We Are

/B orrow er
Ap pl ic ant

Proce ss
AidEducation Submission Eligibility Repayment Consolidation Collections

Student Aid on the Web

Call Centers

CaseTracking Recommend Acquisition& EnterprisePerformance

(Ombudsman) Policy Changes PlanningStrategy
Enterprise Analytics and Research Management
Analytics

E nt erpris eS hare d
Send/Receive from Matching Agencies Generate/Distribute ISIR/SAR Credit Check AuditHistory Transfer Monitoring Process Promissory Notes Servicing Reporting (FFEL & Campus Based) SSCR CDR

E nt erpri se Sha re d
Enablers

§ Gathered Business
EAI
Common Data Architecture

F unc ti on s
F unct i ons
Enterprise
Application NSLDS
Integration
Trading Enterprise
Students FMS Warehouse/Data Marts
Content
Metadata
Partners Repository
ITA Transactions Management
Integrated
Technical
Architecture EditChecks DistributeEligibility Computation Edits - EFC RID Legacy Identifier Crosswalk Authentication & Access Management Partner Payment Calculation/PrePopulation
SSIMLogic Match Against CDA (FAH)

VDC
Virtual
Data Center Application Origination & Disbursement Common Services for Borrowers

FSA
Establish School Aid Payments &
Aid AidEligibility Award & Disbursement Consolidate Recovery &
Person Service Loans CSB
Awareness Determination Processing FundingLevelMgmt Loans Resolution
Authentication & Record

Objectives
AccessTools

Application Partner Partner Eligibility Relationship

Process Enrollment
Trading Partner Management & Oversight Mgmt
Business
Intelligence
Tools
Partner Payment
Payment
State Agency
Processing
Admin
Partner Payment Management Funding
Ancillary
Services
Process Funds & Internal ExternalFinancial GL
AR Managment
Payments Controls
Financial Management Reporting
Budgeting
Accounting

§ Drafted Target Data Flows

FSA Gateway
SchoolsPortal

Financial Partners Portal

Help Desk

Part ne rs &
S ervi cers
T radi ng
State Agencies Schools ( School Servicer)
Lenders (Lender Servicers) Guaranty Agencies

Other External Partners

§ Created a Vision of “What it

ED
FMSS Department of Education GAPS To-Be Financial
Aid Life Cycle
Partner Application

Trad in g
Business Function

Proc ess
P artn er
InternalTransfer
DRAFT
External Transfer
High-Level Business View
Origination&
Oversight
Disbursement

ED/FSA

should look like”

Web Access (G2C & G2B) FSA Target Conceptual Architecture Guiding Principles InternalUsers

FSA Web Site 1. Shift to business process focus from system-based operation.
Student, FAA, 2. Consolidate data to a centralized storage environment.
& Financial Internet 3. Standardize interaction with external customers. Centralized
Partner Users Student Aid School
FP Services
4. Improve FSA architecture response to business change. Governance and
on the Web Services
Portal
5. Eliminate redundancy to promote the reuse of business functions.Management
Portal Portal

Borrower Trading Partner and Internal User

Access Management Access Management
System
Access
Management Web Applications Common Data Architecture
Analytics and
Research Tools
Integrated
Government System Access Views
Agency
Systems
(G2G & G2B)
Integration Services Query/ (Interacts with
Reporting all Business
Web Services Students
Trading FMS Capability
Partners OLAP /
Transactions
Analytics
Areas)
Real-Time Transfer
Knowledge/
Extract - Transform - Load
Discovery
School/Servicer
Batch Transfer
Systems EnterpriseAnalyticsand

F SA Gat eway
NSLDS Research
BusinessProcess
Enterprise Content
Management Warehouse/DataMarts Metadata Repository
Management
Internet
(Some Systems)

Enterprise Shared Functions

Technical Functions Business Functions
Capability Discovery Audit History PartnerPaymentCalculation/ Common Services for
Authentication & Access Mgmt. Pre-Population Borrowers
Data Tracing and Visibility CDR Process Promissory Notes
Computation Edits - EFC RID Legacy Identifier Crosswalk CSB
Data Transformation Credit Check Send/Receive from Matching Agencies
Distribute Eligibility Service Reporting (FFEL & Campus-
Lender/Servicer Data Validation Edit Checks based)
Systems
Generate/Distribute ISIR/SAR SSCR
ErrorHandling Match Against CDA (FAH) SSIM Logic
Transfer Monitoring
Financial Management

What We Need To Do
Guaranty
Agency/Servicer
Systems
Partner
Enrollment

TradingPartner Application Origination and Payment Partner

Management Disbursement Management
Security

§ Explore options for new questions raised during Target Vision

Discussions and Retreats
§ Implement XML Registry / Repository of Core Components to the
Internet
§ Enact the Data Quality Assurance Methodology for the Enterprise
 Data Strategy 2.0
Schedule
Jan Feb Mar Apr May June Jul Aug Sep Oct Nov
1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/1 3/8 3/15 3/22 3/29 4/5 4/12 4/19 4/26 5/3 5/10 5/17 5/24 5/31 6/7 6/14 6/21 6/28 7/5 7/12 7/19 7/26 8/2 8/9 8/16 8/23 8/30 9/6 9/13 9/20 9/27 10/4 10/11 10/18 10/25 11/1 11/8 11/15 11/22 11/29

Overall Data Strategy TO 152 - Data Strategy 2.0

Data Framework
Data Strategy Target Vision FFEL and Student Enrollment Data Flow Option Analysis 152.1.1 - Data Strategy Target Vision FFEL and Student
Enrollment Data Flow Option Analysis
FFEL and Student Enrollment
Data Flow Option Analysis

CSB Impact Analysis Data Strategy Target Vision CSB Impact Analysis 152.1.2 - Data Strategy Target Vision CSB
Impact Analysis

Data Strategy Target Vision

Functional Gap Analysis 152.1.3b - Data Strategy Target Vision
Data Strategy Target Vision Functional Gap Analysis Functional Gap Analysis (Final)

152.1.3a - Data Strategy Target Vision

Functional Gap Analysis (Draft)

152.1.4a -Data Strategy Target Vision Enterprise Analytics

Architecture Option Analysis (Draft)
Technical Strategies 152.1.4b - Data Strategy Target Vision Enterprise
Data Strategy Target Vision Enterprise Analytics Architecture Option Analysis Analytics Architecture Option Analysis (Final)
Enterprise Analytics Architecture
Option Analysis

Common Data Architecture Data Strategy Target Vision Common Data Architecture Operating Guidelines Options 152.1.5-Data Strategy Target Vision Common Data Architecture
Operating Guidelines Operating Guidelines Options

Website/Portals Consolidation and

Shared Services Implementation
Option Analysis Data Strategy Target Vision Website/Portals Consolidation and Shared Services Implementation Option Analysis 152.1.6 -Data Strategy Target Vision Website/Portals Consolidation and Shared Services
Implementation Option Analysis

XML Core Component Dictionary Release 2.0 152.1.7-XML Core Component Dictionary Release 2.0

XML Management
152.1.8-XML Registry/Repository
Core Component Dictionary XML Registry/Repository Production Readiness Review (PRR) Report Production Readiness Review
Release 2.0 (PRR) Report
152.1.9a -XML Registry/Repository Production
Production Registry / Repository Quarterly Report I

XML Production Support XML Registry/Repository Production Support

152.1.9b - XML Registry/Repository

Production Quarterly Report II

152.1.10a - Data Quality Management

Support Report I

Data Quality Management Data Quality Management 152.1.10b - Data Quality Management Support
Report II

Current
Date
Legend
Delivered on Schedule
Scheduled Delivery Date
 Data Strategy 2.0
Functional Gap Activities
ED/FSA
Web Access (G2C & G2B) Internal Users
Data Strategy 2.0 Functional Gap Analysis Activities
FSA Web Site 1. Option analysis for FFEL Loan and Student Enrollment Reporting
Student, FAA, 2. CSB award outcome impact analysis
& Financial Internet 3. Option analysis for Financial Transaction Processing Centralized
Partner Users Student Aid School 4. Enterprise Analytics Architecture Analysis and CDA Operating Governance and
FP Services
on the Web Services Guidelines. Management
Portal
Portal Portal 5. Web Consolidation and Shared Services Options

Borrower Trading Partner and Internal User

Access Management Access Management
System
Access
Management Web Applications Common Data Architecture Analytics and
Research Tools
5
Integrated
Government System Access Views
Agency
Systems (G2G & G2B) 4
Integration Services Query / (Interacts with
Reporting all Business
Web Services Trading 4 FMS Capability
Students OLAP /
Partners Areas)
Transactions Analytics
Real-Time Transfer
Extract - Transform - Load Knowledge/
Discovery
School/Servicer Batch Transfer
Systems Enterprise Analytics and
FSA Gateway

5
NSLDS Research
Business Process
Enterprise Content
Management Warehouse/Data Marts Metadata Repository
Management
4
Internet
(Some Systems)

5 Enterprise Shared Functions

Technical Functions
Capability Discovery Audit History
Authentication & Access Mgmt.
Data Tracing and Visibility CDR
Computation Edits - EFC
Data Transformation Credit Check
Distribute Eligibility
Lender/Servicer Data Validation Edit Checks
Systems
Generate/Distribute ISIR/SAR
Error Handling Match Against CDA (FAH)
Business Functions
Partner Payment Calculation/ Common Services for
Pre-Population Borrowers
Process Promissory Notes
2
RID Legacy Identifier Crosswalk CSB
Send/Receive from Matching Agencies
Service Reporting (FFEL & Campus-
based)
1
SSCR
SSIM Logic
Transfer Monitoring
Financial Management

Guaranty 3
Agency/Servicer
Systems Partner
Enrollment

Integrated Partner Origination and Payment Partner

Application
Management Disbursement Management
Security
 Data Strategy 2.0
XML Deployment
User Interface
A User Interface allows users access to Repository documents
and enables them to:

* Search for Documents

* View Documents
* Upload Documents
Registry Client * Delete Documents
* Edit Document Properties
* Classify Documents
* Associate Documents with eachother

Registry Repository

RDBMS

File System
A Registry contains meta-data about documents
stored in the Repository. Meta-data includes:
A Repository stores documents referenced by
a Registry. Documents Include:
* Ownership Data * XML Schemas
* Version Data
* Core Components
* Access Constraints Data
* Classification Schemes * Other Documents
* Associations

§ Deploy XML Registry / Repository to the Internet

– Makes FSA standardized Title IV Aid definitions and
Core Components available for both FSA and
Community usage
– Provides a vehicle to drive consensus on data
standards
 Data Strategy 2.0
Data Quality Deployment
Prioritization Assessment Improvement Oversight
Phase Phase Phase Phase

1.Verification of As -Is 1. Pre-Assessment 1. Solution Definition and 1. Enterprise Analytics

State and Quality Planning (As-Is) Assessment Stage Stage
Issues Stage Stage 2. Data Quality 2. Enterprise Audits
ST A

2.Determine Criteria 2. Initial Data Implementation Pilot (Financial) Stage

PRO UMMAR

for Ranking Stage Assessment Stage Testing Stage 3. Enterprise Quality

3.Rank Quality Issues
GE S

3. Pilot Testing Data 3. Data Quality Report Stage

Stage Assessment Stage Implementation • Transfer Report
CES

• Assign Project • Transfer to Production Stage results back to

Managers, request Improvement Phase • For pilot testing, Prioritization Phase
further research, or transfer back to
S&

transfer to Enterprise Assessment Phase,

Quality Assurance otherwise go to
program Oversight Phase
Y

• Quality Report • Develop Business • Brainstorming • Quality Report

• Failure Modes and Case, project plan, • Decision Matrix (High level
Effect Analysis (FMEA) and objectives. • Cost/Benefit providing
• Voice of the • Create a • Risk Assessment enterprise-wide
LS

Customer (VOC) communication plan. • Change Leadership quality health-with

• Quick Win
TOO

• Document Inputs and • Implementation Plan drill down for

Determination Outputs. • Pilot testing quality issue/or
• Cost of Poor Quality • Voice of Customer / • Control and Response system level)
Analysis Critical to Quality Plan • Best Practice
• Histograms, Pareto analysis and
Charts transfer
• Fishbone Diagram,
Failure Modes and
Effect Analysis
• “To-Be” Vision

§ Enact Data Quality Assurance Strategy

– Establishes Repeatable processes for identifying, correcting, and maintaining
data within the Enterprise
 Data Strategy Update - IPM

What is the Integrated Partner Management Solution (IPMS)?

IPMS is envisioned as the solution that enables FSA to successfully and easily perform oversight,
management and maintenance of its Trading Partners. The solution will provide a holistic view of the
information related to FSA Trading Partners and will enable FSA to overcome the current challenges of
managing information related to Trading Partner identification and their interactions via a combination of
PEPS and the Title IV delivery systems.

The solution should cover the following business areas:

•Enrollment Management
•Eligibility Management
•School On-Going Oversight
•Financial Partner On-Going Oversight
•Enterprise Routing Identifier (RID) Services
•Reporting and Auditing Services
•Profile and Demographic Management
•Access Management
•Customer Support
•Workflow Management
 Data Strategy Update - IPM

Integrated Partner Management Framework

(Schools, Guaranty Agencies, Lenders, Third Party Servicers, State Agencies, Software Developers and Auditors)

Enrollment Eligibility School On-Going Financial Partner On-

Management Management Oversight Going Oversight

§ Integrated § New Trading § Program Eligibility § Program Eligibility

Application Partner Oversight: Audits, Oversight: Audits,
Web and Applications financial statements, financial
Application Enrollment § Initial RID default rate calculations statements,
Interfaces Processing - Assignment § Compliance Reviews: § Compliance
Process § Re- Risk assessment, Reviews: Risk
Requests, certifications accreditation, student assessment,
Determine § Program complaints, funding referrals
Access Participation parameters, referrals § Appeals
§ Institution- Management § Appeals § Proactive Oversight,
Data Access Service

level System
Integrated View Services

§ Appeals § Proactive Oversight, Monitoring, and

Enrollment § Proactive Monitoring, and Support Support
and Single Eligibilty Enterprise
Sign Up Management
(SSU) Routing
§ Eligibility Identifier
Portals Actions (FPRD,
(RID)
Fines, LOC,
Services
LS&T,
Referrals)
§

Profile & Demographics Management

§ Demographics Management
FSA § Relationship and Affiliation Management
Gateway - Enterprise RID Management
Access Management

§ Individual User Access Management

§ Roles based Single Sign On (SSO)
§ Trading Partner Self-Administered Access
Customer Support
Workflow & Document Management
Reporting & Audit Services
Enterprise Analytics
FSA; Other Government Agencies

= User Access Points

 Data Strategy Update - IPM

IPMS Gap Analysis Timeline

Oct Nov Dec Jan Feb Mar
10/1 10/6 10/13 10/20 10/27 11/3 11/10 11/17 11/24 12/1 12/8 12/15 12/22 12/29 1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/1 3/8 3/15 3/22 3/29
Perform Case Management Gaps Analysis
(e.g., Schools Eligibility Channel Cohort
Default Rate Calculations)

Document Non-Case Management Requirements for Schools,

Borrower Services, CFO and OPE

Develop Financial Partner Eligibility & Oversight As-Is Flows

Document Financial Partner Eligibility & Oversight

Requirements

Key:
10/1 - Begin Date 3/12 - All Work Completed
Del 1 =

Del 2 =

Del 3 =
 NSLDS & Data Strategy
§ More detail on NSLDS will be available when
the NSLDS business functions have been
clearly mapped to the FSA target vision.
§ The following NSLDS upgrades have taken
place in an effort to position the system for
future re-engineering efforts:
– Upgraded the NSLDS mainframe system to Z900
in September 2003.
– Upgraded the operating system to Z/OS version
1.4 in January 2004.
– Upgraded to 64 bit Discovery Process.
 NSLDS Update
§ NSLDS announced a new operations
and maintenance contractor effective as
of March 8, 2004.
§ The contractor is Applied Engineering
Management (AEM), a small business
located in Virginia.
 NSLDS Update
Consolidation Loans & the
Aggregate Calculation
§ Working with the community through
NCHELP.
– FFEL community to provide further
breakdown of Consolidation Loans
– NSLDS to capture Outstanding Principal
Balance at time of loan closure or payoff.
 NSLDS Updates
Other NSLDS initiatives
§ To collect data on Total & Permanent
Disability Loans
§ To continue efforts to monitor
reasonableness of data reported in
summary on ED Forms to the loan level
detail reported on NSLDS
 Thank You!
Keith Wilson
Keith.Wilson@ed.gov
202-377-3591
COD Update
 In this session…
§ 2004-2005 Processing Changes
§ School Testing
§ Software Developer Feedback
2004-2005
Processing
Changes
 Summary of 2004-2005
Processing Changes
Pell Grant and Direct Loan Changes
§ Extended Full Participant deadline to 2005-2006.
§ Enhanced Message Class Options for Full
Participants.
§ Increased variable field length on the SAIG
Transmission Header.
 Summary of 2004-2005
Processing Changes
Pell Grant Changes
§ Verification Initiatives
– CPS Verification Indicator tag added to Common Record
Response
– Highest CPS Transaction Number tag added to Common
Record Response
– Pell Verification Status Report

§ Pell POP Report (Future Release)

 Summary of 2004-2005
Processing Changes
Pell Grant Changes cont.
§ Data elements no longer required for Pell Grant
processing:
– Academic Calendar Code
– Payment Methodology Code
– Weeks of instructional time used to calculate payment
– Weeks of instructional time in program’s definition of award
year
– Credit/Clock hours used to calculate payment
– Credit/Clock hours in this student’s program of study’s
academic year
 Summary of 2004-2005
Processing Changes
Direct Loan Changes
§ Anticipated disbursement information required when
establishing Direct Loan awards.
§ Automatic recalculation of anticipated disbursements
when Award Amount is decreased.
§ Automatic reduction of anticipated disbursements to
allow loan inactivation.
§ Pennies will not be processed in the Direct Loan
Program.
 Summary of 2004-2005
Processing Changes
COD Web Site Changes
§ Enhanced CPS applicant data search functionality.
§ Person Information pages allow filtering by award
year.
§ Award Amount Disbursed and Award Amount
Approved added to Person Information pages.
§ Batch Search screens allow filtering by Award Type
and Doc Type.
§ Batch Detail Information page split to display
information submitted to COD and information
returned by COD.
 Summary of 2004-2005
Processing Changes
COD Web Site Changes
§ Promissory note search by SSN, MPN ID, or First
Name and Date of Birth.
§ School Summary Financial Information screen
reflects information contained in the Direct Loan
School Account Statement.
§ Enhanced disbursement functionality to allow
creation of multiple anticipated disbursements when
originating an award.
§ Ability to select Award Year and Program for web
navigation.
§ GAPS Debit Date added to Cash Activity Screen.
 2004-2005 Processing
Changes Update
§ COD will no longer be instituting the following functionality
for the 2004-2005 award year:
– Campus-Based processing
– School Report Options via the COD web site

§ Campus-Based
– Due to feedback on the proposed Campus-Based functionality for the
2004-2005 award year, enhancements to Campus-Based functionality
are now being explored. The implementation of Campus-Based
processing has been postponed pending further discussion of
Campus-Based design requirements.

§ School Report Options

– COD will not be providing enhanced School Report Options. Current
COD processing will continue to allow for the selection of limited
report delivery, sort, and format options via the web and by contacting
Customer Service.
 2004-2005 Update
Current School Report Options
Pell Reports
§ The following reports can be requested via the Pell Data
Request link on the COD web site and will be delivered in
fixed-length file format via the school’s SAIG mailbox:
– ESOA
– MRR
– Pell Reconciliation
– YTD

§ The following reports can be viewed on the COD web site in

PDF or comma-delimited format by clicking on the Services
tab:
– Pending Disbursement List Report
– Funded Disbursement List Report
 2004-2005 Update
Current School Report Options
Direct Loan Reports
§ The following reports can be displayed on the COD web site
by clicking on the Services tab. These reports are
automatically sent to the schools SAIG mailbox:
– 30 Day Warning Report
– Pending Disbursement List Report
– Funded Disbursement List Report
– Duplicate Student Borrower
– SSN/DOB/Name Change Report

§ Format and delivery options for the above reports can be

modified by accessing the Report Selection link on the
School Summary Information Screen.
§ Format and delivery modifications for the SSN/DOB/Name
Change Report must be made by contacting Customer
Service.
 XML Schema Processing
Original Namespace Convention
§ For the launch of the 2004-2005 award year, COD had
planned to continue to return the latest XML Schema
version, 2.0d, in Common Record response documents
for all award years.
§ The XML Schema contains the validation rules of the
Common Record document, and also contains specific
version information in the “Namespace” attribute.
§ XML Schema validation is normally performed throughout
development and testing of a system to verify system XML
output. Typically, XML Schema validation is not
performed during production processing.
§ Since Schema validation is not performed during
production, the Namespace attribute should not be edited
during production processing. Therefore, updates to the
XML Schema Namespace should not influence production
processing.
 XML Schema Processing
Original Namespace Convention
§ Prior to the release of the 2004-2005 award year,
COD learned that some vendors were editing the
value in the Namespace attribute during production
processing.
§ As a result, some vendors would have had to update
their 2003-2004 award year software in order to
continue processing 2003-2004 responses returned
in 2.0d.
§ Therefore, COD has implemented a temporary
workaround to enable those vendors to continue
processing for the 2003-2004 award year.
 XML Schema Processing
Current Namespace Convention
§ COD is currently returning the highest Schema
version released during the award year of the data
contained in the Common Record document.
Batch Award Year Common Record Schema Namespace Value
2002-2003 http://www.ed.gov/FSA/COD/
2003-2004 http://www.ed.gov/FSA/COD/2003/v2.0c
2004-2005 http://www.ed.gov/FSA/COD/2004/v2.0d

§ If the Common Record contains multiple award

years, COD is returning the XML Schema version
that corresponds to the highest award year.
§ However, this temporary solution may cause
problems for those vendors that were expecting to
receive the latest XML Schema version for all award
years.
 XML Schema Processing
Proposed Namespace Solution
§ For the 2005-2006 release, COD is considering
returning response documents in the XML Schema
version submitted to COD. i.e. “Echo-ing” back what
was submitted to COD.
§ For system-generated responses, COD will return
Common Record documents in the latest version of
the XML Schema.
§ This solution will accommodate vendors that are
editing on the Namespace value regardless of the
value they were expecting to receive.
§ However, the best method is to not edit the
Namespace value.
School
Testing
 COD School Testing
§ Purpose:
– Provide schools, Third-party Servicers, and software
vendors an opportunity to test business processes and
system software in a low-volume, controlled test
environment thereby enabling simpler, faster, and less costly
issue identification and resolution
– Ease the transmission of production data
– Reduce the risk of production problems

§ School Testing Documentation:

– School Testing Guide
– Test Cases for both Full and Phase-In Participants
– COD 2004-2005 Technical Reference available on IFAP and
FSA Download
 Communicating about
School Testing…
§ COD has increased communication about School
Testing to the community using the following forums:
– IFAP
– COD Processing Updates
– Web Messages
– Conference Presentations

§ The School Testing Bulletin Board has been

discontinued due to lack of community interest.
 2003-2004 Lessons Learned
§ Based on school and vendor feedback, the following
enhancements were made to the 2004-2005 School
Testing Guide in the COD Technical Reference:
– Detailed Routing ID explanation
– Detailed explanation of ISIR files
– Further clarification of the fields contained in the Sign-up
Document
 2003-2004 Lessons Learned
§ COD is currently investigating whether or not it is
possible to provide sample Pell origination files and
acknowledgement files, and Direct Loan origination
and acknowledgement files.
§ COD is unable to provide a year round testing
environment with testing scenarios.
§ COD will allow for additional unstructured testing
after the COD testing window has closed.
 COD Unstructured Testing

§ COD is offering unstructured testing to a limited

number of 2004-2005 COD School Testing
participants.

§ Participants interested in unstructured testing must

participate in, and complete Phase II test cases
prior to participating in unstructured testing.
 COD Unstructured Testing
§ What can be done in Unstructured Testing?
– Update person data,
– Updates to awards and award amounts,
– Send batches and receive acknowledgements and
responses in proper format (Common Record or Fixed-
length flat files).

§ What are the limitations of Unstructured Testing?

– Unknown result expected by school,
– Unable to provide system-generated responses,
– Cannot provide COD “testing” web site access,
– Cannot provide COD reports.
 2004-2005 COD School
Testing Timeline

Phase Dates
Sign-up Dec. 1, 2003 – May 1, 2004

Phase I-Manual Jan. 1, 2004 – May 31,2004

Verification Testing
Phase II-Structured Mid-March 2004 - June 30,
Application Testing 2004
Unstructured Testing Mid-March 2004 - June 30,
2004
 COD Full Participants
As of March 1, 2004

22
1895

3537
5512

2002-2003 2003-2004
1490 All schools must be
Full Participant for
the 2005-2006 Award
Year.

3840
Phase-In Participants
Full Participants
2004-2005 (Projected)
Software
Developer
Feedback
 Contact Us!!
§ Email: CODSupport@acs-inc.com
§ Call the COD School Relations Center
– 1-800-4-PGRANT for Pell Grants
– 1-800-848-0978 for Direct Loans

§ COD Web Site (www.cod.ed.gov)

 Overview of FEBI-
Front End Business Integration

March 31, 2004

 Agenda
§ FEBI Objectives
§ Approach to FEBI
§ FEBI Accomplishments
§ Market Research
§ FEBI Procurement Timeline
§ Next Steps
 FEBI Objectives
§ Create a student-centric business model that supports the needs of the end-to-
end business process
§ Align products and services across the Front End and assure that they
effectively and efficiently serve customer needs
§ Integrate student/applicant customer service capability, including the capturing
of customer service data such that we can improve our products and services
§ Share services across the enterprise such as imaging and fulfillment
§ Operationalize ways to use technology to simplify the application process and
customer experience (e.g., warm transfer capability between customer
interaction centers, web services, and identity management)
§ Streamline and simplify of the application and origination and disbursement
delivery systems including reusable components that support FSA data strategy
§ Effectively provide technical help desk services
§ Simplify processes for business partners (improve interfaces with institutions
and other FSA systems such that schools can provide aid on our behalf)
§ Establish performance measures that ensure demonstrable outcomes
 Approach to FEBI
§ Identify front end business processes
§ Understand interdependencies between this
initiative and other integration activities in
FSA
§ Conduct market research
§ Develop Vision and Target State
§ Develop acquisition strategy
§ Release Statement of Objectives
FEBI sits within the broader
FSA and ASEDS goals
FSA Enterprise Goals

FEBI

Awareness/Outreach, Application,
Origination & Disbursement,
and Customer Service

Shared Services

Data Strategy
 FEBI Accomplishments
§ Defined FE business processes
§ Identified activities associated with the FE
– Focused on shared services and shared data
§ Synced up with Data Strategy efforts
– Validated common data between Awareness/Application and
Origination/Disbursement
§ Refined FEBI objectives
§ Developed FEBI market research strategy
§ Conducted market research sessions and developed
learnings/best practices matrix
§ Released draft Statement of Objectives to vendor community as
ongoing market research
 Market Research
§ Defined MR Objectives in the areas of Business Process,
Performance, and Technology for:
– Application, Origination, and Disbursement
– Customer Service
– Shared Services
§ Developed profiles for 51 organizations: 33 providers, 18 users,
41 commercial sector companies and 27 organizations that operate
in commercial and/or government
§ Developed a prioritization formula and refined weights until a
usable dispersion of company scores was achieved
§ Of the 21 organizations we contacted, we are able to conduct
interviews with 13
§ Conducted MR Sessions
§ Documented MR Learnings
 FEBI Procurement Timeline
2004
F M A M J

Front End Strategy and

Procurement Approach

Analyze Draft SOO Input 3/10-3/12

Determine # of Solicitations 3/19

Checkpoint- Determine # of parts 3/19

SOO Developed
Draft SOO Posted 2/27

Draft SOO Comments Received 3/8

Refine SOO based on Vendor Input 3/12-3/19

Sol 1 SOO Approach Defined 3/19

Solicitation 1
Sol 1 Released 3/31

Responses Due 4/15

Checkpoint

Down Select Review 4/15-4/29

Checkpoint- Define # Sol

Solicitation 2
Sol 2 Draft Released 4/30

Due Diligence 5/1-5/31

Checkpoint

Final Sol 2 Released 6/1

 Next Steps
§ Solicitation 1 – Release 3/31/04
§ Solicitation 2 – Release on or about
6/1/04
§ Award – 9/30/04
 Thank You!

Michele Brown
michele.brown@ed.gov
202-377-3703
 - CSB -
Common Services for Borrowers

Dwight Vigna
Acting Director, Direct Loan Servicing System
 Common Services
for Borrowers (CSB)
Agenda

§ CSB Overview
§ CSB – An innovative
contract method
§ Implementation
Approach
§ Benefits to Schools
§ Summary
 CSB Overview - Goals
CSB will modernize/integrate four legacy systems into 1
§ Direct Loan Servicing (DLSS)
§ Loan Consolidation (LC)
§ Debt Collection (DMCS)
§ Conditional Disability
Discharge Tracking (CDDTS)

Additionally, CSB will

include the Delinquent
Loan Data Mart (DLDM)
and other FSA data
mart functions
 CSB Overview - Goals
§ Integration will achieve the following:
– Reduce Delinquency and Default
• Performance based pricing
• Incentive based and
– Improve Customer Service and Increase Self-Servicing
• Additional Web access
• Improved IVR functionality
• Reengineered communications
– Integrate Systems and Data
• Less data redundancy and associated errors
• Improved auditability
– Create Adaptability and Flexibility in the CSB System
– Reduce Cost
– Achieve Contracting Goals
 CSB Contract Approach
§ A “performance-based” contract
– Focus on expected results/outcomes
– Comply with statute and regulations
– More flexibility for contractor
– Reduction in Reconciliation and System Balancing Point
– Reduce Staffing at Call Centers, Other Locations
– Reduce Infrastructure
• Consolidates 6 call centers into 1 Virtual Service Center
• Consolidates 6 inbound mailrooms into 1
• Consolidates 7 fulfillment (print and mail) centers into 4
• Consolidates 3 lockboxes into 1

§ Independent Government Cost Estimate:

- $1 Billion in savings to taxpayers -
 Approach to Integrate
Systems and Data
§ Leverage legacy assets and FSA investments
§ Migrate some
§ Reengineer some
§ Rewrite some

§ Minimize (prevent) impact on Trading Partners

§ Support FSA IT Standards
§ Hosted at the VDC
§ Compliant with FSA technology standards
§ Complements FSA data strategy initiatives

§ Eliminate data redundancy and reconciliation issues

§ Provide a single system of record
§ Use a phased integration approach
 CSB Transition Plan
Legacy systems will continue to operate until
implementation of the CSB Solution
2003 2004 2005
Months

Phases Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov

CSB Management
Planning/Project Startup 1.5 months
Phase 1
Loan Consolidation/ Phase 1 7 months
Common Database
Implementation
Phase 2
Servicing/Debt
Collection/Discharge Phase 2 15 months
Tracking Implementation

Phase 3
Additional Integration and Phase 3
Migration to the VDC 9
months

Transition Complete
 Create CSB Framework Common Services for Borrowers
Phase 1
Loan Consolidation
Ø Develop functionality in CSB CRM
Ø Incorporate into upgraded
Siebel CRM Loan
Consolida- Application Layer
tion
Common Database
Ø Move LC data and DLSS
demographic data to CSB Common Services

Data Mart EAI/Interfaces

Ø Establish CSB Data Mart
and move existing Servicing
data from CMDM and DLDM Common Database
Demographic |
Demographic
Ø Add data from DMCS and DataMart
CDDTS

LC DLSS DMCS CDDTS

CRM Application CRM Application CRM Application CRM Application

Interfaces Data Interfaces Interfaces Data Interfaces

Data
Data Data
Servicing Common Services for Borrowers
Ø Convert DLSS software to Phase 2
new hardware and
operating system CRM

Debt Collection Loan

Loan Debt Disability
Consolida- Application Layer Discharge
Ø Develop functionality in tion Servicing Collection Tracking

CSB using Quester as the

base product Common Services

EAI/Interfaces
Discharge Tracking
Ø Develop functionality in
CSB Common Database
Demographic |
Demographic Contact Financial
DataMart
Common Database
Ø Move remaining legacy
data to CSB DLSS DMCS CDDTS

CRM Application CRM Application

CRM Application

Interfaces Data Interfaces Data Interfaces Data

 Common Services for Borrowers
Phase 3
CRM
Additional eCRM (Siebel)
Integration Loan
Debt Disability
Loan
Consolida- Application Layer Discharge
– Web-based imaging tion Servicing Collection Tracking

– Web Chat
– Email Common Services

EAI/Interfaces
Phase 3 ends with CSB
hosted at the VDC
Common Database
Demographic |
Demographic Contact Financial
DataMart
CSB End-State Topology
 Data Strategy
§ Use incremental approach to conversion
– Phase 1 DLSS/LC Demographics and Data Mart
– Phase 2 CSB/DCS Demographics, Financial and Contact Data
– Phase 3 Move to VDC and additional Web enhancements
§ Build on existing DLSS schema
– Identify and correct issues or limitations
– Augment schema to accommodate CSB data
– Work with FSA Data Strategy Team
§ Clean and reconcile data
– Identify redundant data and “error” data
– Develop business rule and resolve conflicts
– Validate data integrity using independent teams (IV&V and QA/QC)
§ Implement Data Archiving
– Use separate partition for archived data to increase performance
 Impact on Independent
Software Developers
§ CSB will maintain all interfaces while the legacy
systems are operational
§ CSB will follow FSA Data Standards
– XML
– Common Record
– School ID
– Borrower ID
§ External interfaces will not be changed without
consultation will all trading partners
 Summary
§ CSB integrates processes, data and systems for
Servicing, Consolidation, Collections, and Disability
Discharge

§ CSB Contract Team comprised of familiar faces that

have been supporting FSA for a combined total of
over 30 years

§ CSB Solution supports FSA’s Performance Objectives

and IT Standards
§ CSB is a Performance-based contract which helps
ensure optimum results

§ CSB saves taxpayers money

Questions???

Thank You!
Dan Hayward
Dan.Hayward@ed.gov
202-377-3207
Questions and Answers
 Thank You!
Jerry Schubert
Jerry.Schubert@ed.gov
202-377-3009