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

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

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

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

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

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

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

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

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

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

11. Record Type Overview Record Type Record Name
16 Lender/Lender-Servicer Change
17 Consolidation Loan Notification
18 Consolidation Loan Add-On/Increase Notification
19 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

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

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

14. CAM Implementation

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

16. 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)

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

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

19. Default Aversion and Claims

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

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

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

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

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

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

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

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

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

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

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

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

32. Transmission Protocols

33. 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
FTP
High performance channel

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

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

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

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

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

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

40. Questions and Answers