Common Account Maintenance (CAM) PESC Annual Conference May 9, 2002 Presented by: Kevin Woods & Dione Byars, Sallie Mae

CAM Agenda Introduction to CAM Implementation Default Aversion and Claim Records Transmission Protocol Questions and Answers

In the beginning… July 1997 – Creation of AMF workgroup March 1999 – Initial CAM records July 1999 – Default Aversion Assistance Request records July 2001 – Claim Records

Who? Collaboration of guarantors, lenders, and servicers NCHELP SLSA

How? Tools used Smaller Workgroups Change Control Group Current NSLDS requirements CommonLine Coordination

Why? Replaces proprietary formats Standardizes communication between trading partners: Edits Errors Field definitions Transmission methods

Why? Standardized electronic format Facilitates exchange of loan maintenance, default aversion, and claim information Same format used to send and receive data

What can be exchanged? Person level Loan level Disbursement level Address changes Loan level Loan status changes Disbursement level Partial loan cancellations

CAM Files Submittal, Return, Confirmation Return types: Acknowledgement Reject Informational Update Loaded, with errors Confirmation file = handshake

Record Type Overview Record Type Record Name 01 Header 02 Identifier Data 03 Identifier Data Change 04 Enrollment Status Data 05 Address/Phone Change 07 Loan Period/Grade Level Change 09 Pre-Disbursement Change 10 Post-Disbursement Change/Notification 13 Stafford Sub/Unsub Reallocation Decrease 14 Stafford Sub/Unsub Reallocation Increase 15 Loan Status Change

Record Type Overview Record Type Record Name 16 Lender/Lender-Servicer Change 17 Consolidation Loan Notification 18 Consolidation Loan Add-On/Increase Notification 19 E-Mail Notification 20 Consolidation Demographic Data 21 Guaranty Fee Invoice/Remittance 22 Paid Guaranty Fee Adjustment 24 Loan Increase 26 Principal and Accrued Interest Balance 27 Master Promissory Note (MPN) Information 28 Post-Withdraw Return 29 Post-Withdraw Return Reversal

Record Type Overview Record Type Record Name 40 DAAR Borrower Demographic Information 41 DAAR Employment/Deferment/ Forbearance/Borrower Contact Information 42 DAAR Reference Information 43 DAAR E/C/S Information 44 Loan-Level DAAR Information 50 Claim Borrower Demographic Information 51 Claim Employment Information 53 Claim E/C/S Information 54 Loan-Level Claim Information 55 Additional Information-Lender to Guarantor 56 Repayment Information/Requested Claim Amount 57 Collection Activity

Record Type Overview Record Type Record Name 58 Claim Recall Request 60 Claim Disposition 64 Loan-Level Claim Payment Information 65 Additional Information-Guarantor to Lender 94 Claim Payment Total 95 Guaranty Fee Totals 96 Record Totals, Series One 97 Record Totals, Series Two 99 Trailer

CAM Implementation

What is a “G-date”? “G” is the date that each guarantor sets for its own implementation “G + ?” is the date that guarantor’s trading partners are expected to implement Partial file or process changes are not allowed Sending entity monitors which trading partners can receive which CAM records

Here is an example… Guarantor A implements records, 01,02,03,04,05,96,99 on 01/01/1999 (G) Trading partners must implement by 12/31/1999 (G+12) Guarantor A implements all other CAM records on 07/01/1999 (G) Trading partners must implement by 06/30/2000 (G+12)

Where are we now? July 2000 – NCHELP Electronic Standards Committee created Integrated approach to CommonLine and CAM ESC Structure

Where can I find it? www.nchelp.org File Specs Documentation “CommonLine and CAM “Committees” – ESC File Specs Documentation Readiness Surveys Issues Log

Default Aversion and Claims

Default Aversion Records Record layouts published July 1999 Of the 36 Guaranty Agencies, at least 29 have implemented 7 Lender/servicers have reported implementing, but there are more

Why standardize DAARs… Lenders are required to request default aversion assistance from the guarantor when a loan is 60 to 120 days delinquent Guarantors need up-to-date account information to help prevent defaults Many proprietary processes in place both paper and electronic There is a very large volume of DAAR requests made daily in the FFELP industry and there is much information traded to make sure guarantors have the information needed to help prevent students from defaulting on their loans. Guarantors usually contact the borrowers by phone and letter and other means to counsel the borrower concerning their repayment options and it is essential that they have good account/loan data to assist with their counseling efforts. For example, a guaranty agency in Kentucky receives on average 11,000 DAAR requests each month.

Benefits Standardized process Reduces manual processes and paper Consistent and accurate data provided Better service to borrowers

Additional automation needs… Updates Payment due date changes Can update one loan at a time Cancellations Delinquency reduced Can cancel one loan at a time Rejects and errors Request for skiptracing assistance

DAAR Records Sets… 40 - Borrower Demographic 41 - Employment/Deferment/Forbearance 42 – Reference ** 44 - Loan-Level Information ** 43 - Endorser/Comaker/PLUS Student ** ** may receive multiple records in the same record set Use a combination of these records to make a DAAR Request. This will give the guarantor a complete picture of the loans that are delinquent and enough information to help accurately counsel the borrower. The CAM design allows for customization of the information. Multiple loans can be included in a single request and information about those loans is not limited by file size.

DAAR’s Process ed … DAAR’s received electronically Processed Acknowledgement/Rejects/Errors Returned Automated seamless process

Claim Records Record layouts published July 2001 Of the 36 Guaranty Agencies, so far at least 2 have already implemented No Lender/servicers have officially reported implementing to date The earliest a guaranty agency could implement the claim records was 1/1/02 and the latest to implement is 9/30/02 so we are still in the early stages of implementing these records.

Why standardize claims… Lenders file claims with guarantors for reimbursement of principal and interest on a loan when a borrower Defaults Dies Becomes totally and permanently disabled Files bankruptcy Schools closes + more Claim packages (paper, paper, and more paper) Proprietary and manual processes There is a very large volume of DAAR requests made daily in the FFELP industry and there is much information traded to make sure guarantors have the information needed to help prevent students from defaulting on their loans. Guarantors usually contact the borrowers by phone and letter and other means to counsel the borrower concerning their repayment options and it is essential that they have good account/loan data to assist with their counseling efforts. For example, a guaranty agency in Kentucky receives on average 11,000 DAAR requests each month.

More reasons to standardize Standardized electronic means to file claims CAM provides standard edits and processes Acknowledgements/Errors/Rejects Automated claim disposition Conversion to repayment errors Due diligence errors Miscellaneous errors Skiptracing errors Timely filing errors Claim Payments

Even more… Standardized claim payment information Detailed information at loan level Standardized recall process Standardized resubmission process

Claim Record Set 50 - Demographic information 51 - Employment information 54 - Loan-Level Information ** 53 - Endorser/comaker/PLUS student info ** 56 - Repayment Info – Requested Claim Amount 57 - Collection activity ** ** may receive multiple records in the same record set

Claim Packages All claim packages are maintained as originally submitted Can’t change or cancel a claim on one loan included in a package. All or nothing… Guarantors have some flexibility in packaging criteria Flexibility in the review process

Transmission Protocols

Transmission Protocols How is data exchanged in CAM? CAM uses same protocols as CommonLine Share technical resources to develop and maintain these protocols Data is transmitted over the Internet Protocols E-mail FTP High performance channel

Security of Data Encryption Digital signatures Restricts unintended recipients from viewing the data Digital signatures Contained within the message Prohibit altering the message or impersonating the sending organization Use software to encrypt and digitally sign CommonLine and CAM participants must be assured that transmissions sent and received over the Internet will remain secure. Adequate security is achieved through the use of encryption and digital signatures. Encryption restricts unintended recipients from viewing the data; the digital signatures prohibit altering the message or impersonating the sending organization. The encryption standards are common to both SMTP/POP3 and FTP. digital signature within the message. The digital signature protects against a third party impersonating the sending organization or tampering with the message. The SecretAgent product is owned by Information Security Corporation (a subsidiary of AT&T) which licenses and distributes the encryption product and upgrades. OpenPGP will be required as of 04/02/2002. SecretAgent will not be supported by the Electronic Standards committee (which includes the Electronic Exchange Advisory Team) after 04/01/2003. The OpenPGP protocol allows multiple encryption software vendors to compete to provide solutions using the same basic encryption protocols. Support for the OpenPGP protocol will be required as of 04/02/2002. SecretAgent will not be supported by the Electronic Standards committee (which includes the Electronic Exchange Advisory Team) after 04/01/2003.

Security Software SecretAgent OpenPGP Privately owned company which licenses and distributes products and upgrades A single vendor Supported through 4/1/03 OpenPGP Multiple vendors provide solutions for basic encryption protocols Support required by 4/1/02 The SecretAgent product is owned by Information Security Corporation (a subsidiary of AT&T) which licenses and distributes the encryption product and upgrades. A single-vendor solution and is prone to the limitations of dealing with one vendor. OpenPGP will be required as of 04/02/2002. SecretAgent will not be supported by the Electronic Standards committee (which includes the Electronic Exchange Advisory Team) after 04/01/2003. The OpenPGP protocol allows multiple encryption software vendors to compete to provide solutions using the same basic encryption protocols. Having multiple vendors from which to select an encryption product allows each organization participating in the CommonLine or CAM file exchange process to choose the encryption product that best meets its specific needs.

E-mail SMTP/POP3 - Simple Mail Transfer Protocol /Post Office Protocol 3 Files are transmitted through attachments to e-mails Optimal for file attachments that are less than 1 MB in size (post compression)

FTP FTP – File Transfer Protocol Optimal for transmitting larger files CAM files are often large “Push-Push” model Passive and active data connections must be supported as of 4/1/02 Must have FTP server “Push-Push” models of exchanging files require each institution to access the receiving organization’s FTP server and place the file in the sending organization’s designated directory. Support of both passive and active data connections for FTP will be required as of 04/02/2002.

High Performance Channel Protocol Real time/near real time transmission of data Still under development A technological roadmap for using HTTPS, XML, SOAP AND LDAP for secure communication. Implementation is written in JAVA and open source. Licensed under the LGPL http://www.gnu.org/licenses/lgpl.txt Real time/near real time transmission of data Working to finish specifications to document the encryption of the files The high performance channel protocol is effectively a technological roadmap for using HTTPS, XML, SOAP AND LDAP for secure communication. Implementation is written in JAVA and open source. Licensed under the LGPL license. http://www.gnu.org/licenses/lgpl.txt

More High Performance Run on any operating system that has a JAVA implementation “Drop and Run” Details, details, and more details eeat-hpcp.sourceforge.net Sourceforge.net/projects/eeat-hpcp “Drop and Run” can take the code already written and drop it into a web server, change two configuration files and it should run. Allows you to send and receive data but need to write plug ins to interface with systems.

Questions and Answers