DRAFT – FOR DISCUSSION PURPOSES ONLY

Implementation Guide

Overview
This Chapter provides assistance to Full Participants (Schools, Third Party
Servicers, and Software Providers) with implementing the COD System
for the 2002-2003 Direct Loan and Pell Grant Programs. It serves as a
companion to the 2002-2003 Overview of Changes, Appendix C -
Common Record Layout and Appendix E - Edit Comment Codes and
Descriptions contained in this Technical Reference and the XML Schema
available at www.ifap.ed.gov.

Note: Phase-in Participants are advised to refer to the Direct Loan

Technical Reference 2002-2003 and the Federal Pell Grant Technical
Reference 2002-2003 for changes that affect Direct Loan and Pell Grant
processing for the 2002-2003 award year. Please refer to Appendix N -
Glossary for complete definitions of a Phase-in Participant and a Full
Participant.

This Chapter is different from prior years as it presents process

information, setup instructions, business rules for Common Record
construction, and program rules for both the Direct Loan Program and the
Pell Grant Program. The Table of Contents on the following pages
identifies the functional areas and individual modifications that are
described and discussed in this Chapter.

As of April 29, 2002, schools should call the COD School Relations
numbers with any questions concerning the material in this document.
Staff is available Monday through Friday, 8 am –8 pm Eastern Time:
o 1-800-474-7268 for Pell Grant assistance
o 1-800-848-0978 for Direct Loan assistance

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-1
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Table of Contents

OVERVIEW ............................................................................................................................................ 1
FUNDING METHODS........................................................................................................................... 5
FUNDING METHODS ............................................................................................................................... 5
RELATIONSHIP BETWEEN DIRECT LOAN PROCESSING OPTIONS AND FUNDING METHODS .................... 11
RELATIONSHIP BETWEEN PELL PROCESSING OPTIONS AND FUNDING METHODS .................................. 12
SYSTEM SECURITY........................................................................................................................... 13
PRIVACY NOTICE.................................................................................................................................. 13
USER ID SETUP .................................................................................................................................... 13
RULES OF BEHAVIOR ............................................................................................................................ 14
SCHOOL PROCESSING OPTIONS.................................................................................................. 15
PROMISSORY NOTE PRINT OPTION ....................................................................................................... 15
PROMISSORY NOTE TYPE OPTION ........................................................................................................ 16
DISCLOSURE STATEMENT PRINT OPTION .............................................................................................. 17
ADMINISTRATIVE COST ALLOWANCE OPTION ...................................................................................... 18
PELL GRANT ERROR PROCESSING OPTION ........................................................................................... 19
RESPONSE RECORDS GENERATED BASED ON WEB ACTIVITIES ............................................................ 20
NUMBER OF FUTURE DAYS TO DISPLAY DISBURSEMENTS.................................................................... 21
GENERAL VALID FORMAT RULES .............................................................................................. 22
MAXIMUM LENGTH VALUES AND LEADING ZEROS .............................................................................. 22
EMPTY (BLANK) AND NILLABLE (NULL) TAGS .................................................................................... 23
DATA TYPES......................................................................................................................................... 25
DATE FIELDS ........................................................................................................................................ 26
YEAR FIELDS ........................................................................................................................................ 26
DATE/TIME FIELDS ............................................................................................................................... 27
DOLLAR AMOUNT FIELDS .................................................................................................................... 28
PERCENTAGE FIELDS ............................................................................................................................ 30
INTEGER FIELDS ................................................................................................................................... 31
STRING FIELDS ..................................................................................................................................... 31
BOOLEAN FIELDS ................................................................................................................................. 31
GENERAL DOCUMENT INFORMATION RULES ....................................................................... 32
DOCUMENT .......................................................................................................................................... 32
DOCUMENT SUBMISSION ...................................................................................................................... 32
DOCUMENT VALIDATION...................................................................................................................... 33
SEQUENCE OF DATA ELEMENTS REQUIRED FOR DOCUMENT PROCESSING ........................................... 34
DOCUMENTS MUST BE SUBMITTED BY A FULL PARTICIPANT ............................................................... 34
LOGICAL RECORD LENGTH LIMITATION ............................................................................................... 34
COD RECEIPTS .................................................................................................................................... 35
MINIMUM DATA ELEMENTS REQUIRED FOR DOCUMENT PROCESSING ................................................. 36
DOCUMENT ID REQUIRED FOR DOCUMENT SUBMISSION...................................................................... 44
DUPLICATE DOCUMENT IDS ................................................................................................................. 45
INABILITY TO PROCESS FUTURE-DATED DOCUMENTS .......................................................................... 46
DOCUMENTS SUBMITTED MUST CONTAIN AT LEAST ONE DETAILED RECORD ..................................... 47
GENERAL ENTITY INFORMATION RULES................................................................................ 48
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-2
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

COMMON SCHOOL IDENTIFIER .............................................................................................................. 48

ENTITY ID ............................................................................................................................................ 49
TOTAL NUMBER OF STUDENTS IN THE REPORTED SUMMARY COMPLEX ELEMENT............................... 55
TOTAL AWARD AMOUNT REPORTED IN THE REPORTED SCHOOL COMPLEX ELEMENT ......................... 56
TOTAL DISBURSEMENT AMOUNT REPORTED IN THE REPORTED SUMMARY COMPLEX ELEMENT ......... 57
GENERAL PERSON INFORMATION RULES............................................................................... 58
STUDENT IDENTIFIER ............................................................................................................................ 58
CHANGING STUDENT IDENTIFIER INFORMATION ................................................................................... 60
PERSON IDENTIFIER .............................................................................................................................. 62
SCHOOL USE ONLY FIELD .................................................................................................................... 64
UPDATING PHONE NUMBERS ................................................................................................................ 65
GENERAL AWARD INFORMATION RULES ............................................................................... 66
CPS TRANSACTION NUMBER ............................................................................................................... 66
STUDENT IDENTIFIER AND DATA ELEMENTS MATCHED AGAINST THE CPS ......................................... 67
DATA ELEMENTS PULLED FROM THE CPS ............................................................................................ 73
GENERAL DISBURSEMENT INFORMATION RULES ............................................................... 75
DISBURSEMENT SEQUENCE NUMBER REQUIRED ON ALL DISBURSEMENTS ........................................... 75
PAYMENT TRIGGER .............................................................................................................................. 76
GENERAL RESPONSE INFORMATION RULES.......................................................................... 78
RESPONSE DOCUMENTS ....................................................................................................................... 78
RESPONSE INDICATOR .......................................................................................................................... 80
COD MESSAGE CLASSES ..................................................................................................................... 82
DIRECT LOAN AWARD AND DISBURSEMENT PROCESS ...................................................... 83
UTILIZING LOAN KEY FOR SUBSIDIZED AND UNSUBSIDIZED DIRECT LOANS ........................................ 83
SUBMITTING DIRECT LOAN EDIT ONLY RECORD WITH DISBURSEMENT INFORMATION ........................ 87
GENERATING DISCLOSURE STATEMENTS.............................................................................................. 88
PERFORMING ANNUAL LOAN LIMIT EDITS ........................................................................................... 90
SUBMITTING DIRECT LOAN DISBURSEMENT INFORMATION AND PAYMENT TRIGGER ........................... 91
REPORTING PENNIES IN THE AWARD AND DISBURSEMENT AMOUNT DATA ELEMENTS ........................ 97
CALCULATING DIRECT LOAN DISBURSEMENTS .................................................................................... 99
DISBURSEMENT NET AMOUNT, DISBURSEMENT FEE AMOUNT, AND INTEREST REBATE AMOUNT
CALCULATIONS .................................................................................................................................. 103
UPDATING AND ADJUSTING DIRECT LOAN DISBURSEMENT AMOUNTS AND DATES............................ 106
INACTIVATING A DIRECT LOAN .......................................................................................................... 109
GENERATING DIRECT LOAN BOOKING NOTIFICATION RESPONSES ..................................................... 110
GENERATING PAYMENT TO SERVICING RESPONSES............................................................................ 112
DIRECT LOAN PROMISSORY NOTE PROCESSING ............................................................... 115
PROMISSORY NOTE PROCESSING ........................................................................................................ 115
SUBMITTING A PROMISSORY NOTE PRINT INDICATOR ........................................................................ 116
MASTER PROMISSORY NOTE .............................................................................................................. 118
MASTER PROMISSORY NOTE FEATURES ............................................................................................. 120
MULTI-YEAR MPN FEATURE............................................................................................................. 120
SINGLE-YEAR MPN FEATURE............................................................................................................ 121
GENERATING A MPN/PLUS PROMISSORY NOTE RESPONSE .............................................................. 122
DIRECT LOAN PLUS CREDIT CHECK ....................................................................................... 124

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-3
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

REQUESTING A PLUS CREDIT DECISION ............................................................................................ 124

GENERATING CREDIT DECISION OVERRIDE RESPONSES ..................................................................... 124
DIRECT LOAN REPORTS............................................................................................................... 126
DIRECT LOAN REPORTS OPTIONS ....................................................................................................... 126
SCHOOL ACCOUNT STATEMENT (SAS) .............................................................................................. 128
PENDING DISBURSEMENT LIST REPORT .............................................................................................. 130
FUNDED DISBURSEMENT LIST REPORT ............................................................................................... 131
30 DAY WARNING REPORT ................................................................................................................ 132
INACTIVE LOANS REPORT................................................................................................................... 133
DUPLICATE STUDENT BORROWER REPORT......................................................................................... 134
SSN/NAME/DATE OF BIRTH CHANGE REPORT ................................................................................... 135
DIRECT LOAN REBUILD PROCESS ............................................................................................ 136
DIRECT LOAN ENTRANCE/EXIT INTERVIEW........................................................................ 137
REQUESTING AN ENTRANCE COUNSELING FILE/REPORT .................................................................... 137
REQUESTING AN EXIT COUNSELING FILE/REPORT .............................................................................. 138
PELL GRANT AWARD AND DISBURSEMENT PROCESS ...................................................... 139
PELL CORRECTION EDITS TO BE TREATED AS REJECTS ....................................................................... 139
STORING OF REJECT RECORDS ........................................................................................................... 139
REPORTING PENNIES IN THE AWARD AND DISBURSEMENT AMOUNTS DATA ELEMENTS .................... 140
ESTABLISHING PELL GRANT AWARD INFORMATION ........................................................................... 141
REMOVAL OF ENROLLMENT STATUS EDIT ON AWARD AMOUNT ........................................................ 143
SUBMITTING PELL GRANT DISBURSEMENT INFORMATION AND PAYMENT TRIGGER........................... 144
CHANGING PELL GRANT DISBURSEMENT AMOUNTS AND DATES ....................................................... 149
PROCESSING SYSTEM-GENERATED PELL RESPONSES ......................................................................... 151
REPORTING VERIFICATION STATUS CODE .......................................................................................... 152
NEGATIVE PENDING RECORDS ........................................................................................................... 153
CONCURRENT ENROLLMENT .............................................................................................................. 154
PELL POTENTIAL OVERAWARD PROCESS (POP)................................................................................. 155
PELL ADMINISTRATIVE COST ALLOWANCE (ACA) ............................................................................ 157
PELL PAYMENT SCHEDULE ................................................................................................................. 157
PELL GRANT REPORTS ................................................................................................................. 158
PELL GRANT REPORTS OPTIONS ......................................................................................................... 158
DATA REQUEST RESPONSE ................................................................................................................. 158
ELECTRONIC STATEMENT OF ACCOUNT (ESOA)................................................................................ 159
MULTIPLE REPORTING RECORD (MRR) ............................................................................................. 160
RECONCILIATION REPORT .................................................................................................................. 161
YEAR-TO-DATE RECORD (YTD) ........................................................................................................ 162
SSN/NAME/DATE OF BIRTH CHANGE REPORT ................................................................................... 163
USER READINESS CHECKLIST ................................................................................................... 164

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-4
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Funding Methods

Funding Methods
For award year 2002 - 2003, schools continue to access cash through the
Grant Administration and Payment System (GAPS). Schools’ ability to
receive cash to fund their Pell Grant and Direct Loan programs is
contingent upon substantiating disbursements. Schools substantiate
disbursements by submitting actual disbursements (disbursement
information with a Payment Trigger = “true”).

Note: Refer to the section titled Payment Trigger for more information.

! There are five Funding Methods:

o Advance Pay
o Pushed Cash
o Cash Monitoring 1 (CM1)
o Cash Monitoring 2 (CM2)
o Reimbursement

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-5
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Advance Pay
Under the Advance Pay funding method, schools request cash through
GAPS for estimated disbursements to students/borrowers within three (3)
business days. In addition, schools may only draw down cash up to the
difference between the school’s Current Funding Level (CFL) and the
amount of funds previously sent to the school for a given award year and
program. The U.S. Treasury transmits funds to the school’s bank.

Business Rules:
! At the beginning of each award year, a school’s initial CFL amount
is calculated for Pell Grants and Direct Loans on the basis of the
school’s disbursement history.
! Each drawdown a school receives using the Advance Pay funding
method must be substantiated with actual disbursements submitted
and accepted by the COD System. Upon acceptance of an actual
disbursement, the CFL calculation is performed and uses the actual
disbursement to determine if the CFL needs to be increased.
! Actual disbursement records can be submitted with the following
parameters:
o For the Pell Grant Program, up to 30 calendar days prior to
the disbursement date.
o For the Direct Loan Program, up to seven (7) calendar days
prior to the disbursement date.
! Actual disbursements are applied to drawdowns on a first-in/first
out basis.
! The CFL may change throughout the year as the school transmits
actual disbursement information on a “timely basis” and the COD
System accepts the disbursements.
o A school’s CFL will be decreased unless the school submits
and the COD System accepts sufficient actual
disbursements.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-6
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pushed Cash
Under the Pushed Cash funding method, a school has cash deposited in its
bank account based on actual disbursements that are submitted and
accepted by the COD System and the CFL calculation.

Business Rules:
! Actual disbursements can be submitted up to seven (7) calendar
days before the disbursement date.
! The school does not have a CFL until the COD System accepts and
posts actual disbursements.
! If appropriate, cash is deposited in the school’s bank account by
the disbursement date of an accepted and posted actual
disbursement.
! The school must return cash when a downward adjustment to a
disbursement amount is made.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-7
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Cash Monitoring 1 (CM1)

A school can be placed on Cash Monitoring 1 (CM1) by FSA. Under the
CM1 funding method, a Direct Loan school may draw down cash through
GAPS or have cash deposited in its bank account based on actual
disbursements submitted to and accepted by the COD System. A Pell
Grant school may draw down cash through GAPS based on actual
disbursements submitted to and accepted by the COD System. If a school
is on CM1 at the beginning of the award year, it will not have access to
cash until it has accepted actual disbursements on the COD system.

Business Rules:
! For the Pell Grant Program, actual disbursements can be submitted
up to 30 calendar days before the disbursement date.
! For the Direct Loan Program, actual disbursements can be
submitted up to seven (7) calendar days before the disbursement
date.
! The school does not have a CFL until the COD System accepts and
posts actual disbursements. The school’s CFL will equal its net
accepted actual disbursements.
! Some documentation from the school is required.
! For the Direct Loan Program, the school requests the drawdown
from GAPS or, if appropriate, cash is deposited in the school’s
bank account by the disbursement date of an accepted and posted
actual disbursement.
! For the Pell Grant Program, the school requests the drawdown
from GAPS.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-8
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Cash Monitoring 2 (CM2)

A school is placed on Cash Monitoring 2 (CM2) by FSA. Under the CM2
funding method, a school has cash deposited in its bank account based on
actual disbursements submitted to and accepted by the COD System and
the CFL calculation.

Business Rules:
! Actual disbursements can be submitted on or after the
disbursement date.
! The school does not have a CFL until the COD System accepts and
posts actual disbursements.
! Documentation from the school is required.
! Case Management initiates the drawdown through GAPS upon
review of required documentation.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-9
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Reimbursement
Under the Reimbursement funding method, a school has cash deposited in
its bank account based on actual disbursements submitted to and accepted
by the COD System and the CFL calculation.

Business Rules:
! Actual disbursements can be submitted on or after the
disbursement date.
! The school does not have a CFL until the COD System accepts and
posts actual disbursements.
! Additional documentation from the school is required.
! Case Management initiates the drawdown through GAPS upon
review of required documentation.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-10
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Relationship between Direct Loan Processing

Options and Funding Methods

Advance Pay Cash Monitoring Pushed Cash Cash Monitoring Reimbursement

1 (CM1) 2 (CM2)

Receives an Receives no CFL Receives no CFL Receives no CFL Receives no CFL

Initial CFL > 0 prior to prior to prior to prior to
before submission of submission of submission of submission of
submission of actual actual actual actual
any actual disbursements disbursements disbursements disbursements
disbursements

School initiates School initiates Direct cash Case Case

drawdown drawdown payment pushed Management Management
through GAPS through GAPS to school’s bank initiates initiates
website website OR account based on drawdown drawdown
Direct cash accepted actual through GAPS through GAPS
payment pushed disbursements upon review of upon review of
to school’s bank required required
account based on documentation documentation
accepted actual
disbursements

Actual Actual Actual Actual Actual

disbursements disbursements disbursements disbursements disbursements
can be accepted cannot be cannot be cannot be cannot be
with or without accepted without accepted without accepted without accepted without
accepted accepted accepted accepted accepted
promissory notes promissory notes promissory notes promissory notes promissory notes

DL - Option 2
! Submits disbursements X X X
w/Payment Trigger = true up to
7 calendar days in advance
DL –Option 1
! Submits disbursements X X
w/Payment Trigger = true up to
7 calendar days in advance
DL – Standard Origination
! Submits disbursements X X
w/Payment Trigger = true up to
7 calendar days in advance
DL – Reimbursement
! Submits disbursements X X X
w/Payment Trigger = true on or
after disbursement date

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-11
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Relationship between Pell Processing Options and

Funding Methods
Advance Pay Cash Monitoring Pushed Cash Cash Monitoring Reimbursement
1 (CM1) 2 (CM2)

May receive an Receives no CFL Receives no CFL Receives no CFL Receives no CFL
Initial CFL > 0 prior to prior to prior to prior to
before submission submission of submission of submission of submission of
of any actual actual actual actual actual
disbursements disbursements disbursements disbursements disbursements

School initiates School initiates Direct cash Case Case

drawdown drawdown payment pushed Management Management
through GAPS through GAPS to school’s bank initiates initiates
website website account based on drawdown drawdown
accepted and through GAPS through GAPS
posted actual upon review of upon review of
disbursements required required
documentation documentation

Pell Standard (Account

type=Obligate only) X X
! Submits disbursements
w/Payment Trigger = true
up to 30 calendar days in
advance
Pell Pushed Cash (Account
type=Obligate/Pay) X
Submits disbursements
w/Payment Trigger = true up
to 7 calendar days in advance
1
Pell Just-In-Time (Account
type=Obligate/Pay) X
! Submits disbursements
w/Payment Trigger = true
up to 7 calendar days in
advance
Pell Reimbursement
(Account type=Obligate only X X
for 2001-2002 & after)
! Submits disbursements
w/Payment Trigger = true
on or after disbursement

1
Schools using the Pell Just-In-Time funding method are participants in a pilot program whereby they are
extended certain regulatory relief not provided to other schools.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-12
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

System Security

Privacy Notice
The COD System is a United States Department of Education computer
system, which may only be used for official Government business by
authorized personnel. Unauthorized access or use of this computer system
may subject violators to criminal, civil, and/or administrative action.

If you use this computer system, you must understand that all activities
may be monitored and recorded by automated processes and/or by
Government personnel. Anyone using this system expressly consents to
such monitoring. Warning: If such monitoring reveals possible evidence
of criminal activity, monitored records will be provided to law
enforcement officials.

This system contains personal information protected under the provisions

of the Privacy Act of 1974, 5 U.S.C. §552a - - as amended. Violations of
the provisions of the Act may subject the offender to criminal penalties.

User ID Setup
Schools and Third Party Servicers who wish to receive on-line access to
the COD website must identify personnel to serve as administrators.
Administrators will be able to establish additional users within their
individual organizations and provide access to the COD website. The
number of administrators is at the discretion of the institution, although it
is strongly recommended that the number be limited.

In order to establish an administrator account for the COD website,

organizations should submit an administrator request letter printed on
university or corporate letterhead to the COD School Relations Center at:
US Department of Education
FSA School Relations Center
P.O. Box 9003
Niagara Falls, NY 14302

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-13
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

This letter must include the following information:

1. Security administrator’s First Name
2. Security administrator’s Last Name
3. Keyword – Mother’s maiden name (used as an identifier if the user
forgets their password)
4. Work telephone number
5. Email address
6. OPE ID
7. School Name
8. Job Title
9. Work address
10. Work fax number
11. Security administrator’s signature
12. School approving authority’s name, title, and signature (e.g.,
Financial Aid Director).
13. Third Party Vendor Used (if applicable)

After the COD Relations Service Center has successfully processed the
administrator request, administrators will receive their User ID and
password through the email address provided in the response letter. An
initial email will contain the assigned User ID for the COD website, along
with instructions for accessing the website. For security purposes, the
password will be delivered in a separate email.

Rules of Behavior
Schools are encouraged, but not required, to establish Rules of Behavior as
part of their business processes related to the COD System. The Rules of
Behavior developed by the United States Department of Education are
available for reference. Please note that these rules have been established
for Department of Education employees. Your institution’s rules may be
different, but should cover all the areas covered in this example.

Note: Please refer to Appendix K - Rules of Behavior for more

information.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-14
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

School Processing Options

Processing of Common Records through the COD System requires the
following options to be established by a school:

Promissory Note Print Option

This processing option determines whether the COD System prints the
promissory notes or the school prints its own promissory notes.

Business Rules:

! The values for this option are “N” or “Y.”

! “Y” signifies that the COD System prints the promissory note.
! “N” signifies that the school prints the promissory note.
! The default for this option is based on the school’s Direct Loan
origination level.
! Direct Loan schools may update this option at anytime on the COD
Website.
! This option may be overridden by the <PromNtPrtInd> tag on the
Common Record.

Note: For more information on promissory note processing, please see the
Direct Loan Promissory Note Processing section.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-15
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Promissory Note Type Option

This option determines whether single-year or multi-year feature is applied
to a Promissory Note. Schools eligible to use the multi-year feature can
choose to issue single-year or multi-year promissory notes.

Business Rules:

! The values for this option are “single-year” or “multi-year.”

! “Single-year” signifies the borrower must submit a promissory note
for each academic year.
! “Multi-year” signifies the borrower does not submit a promissory
note for each academic year.
! Schools that are not eligible for the multi-year feature default to
“single-year.”
! Schools that are eligible for the multi-year feature default to
“multi-year”
! Direct Loan schools eligible for the multi-year feature may update
this option at anytime on the COD website.

Note: For more information on promissory note processing, please see the
Direct Loan Promissory Note Processing section.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-16
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Disclosure Statement Print Option

This processing option determines whether the school prints its own
disclosure statements or allows the COD System to generate the
Disclosure Statement upon receipt of the required information.

Business Rules:

! The values for this option are “N” or “Y.”

! “Y” signifies that the COD System prints the disclosure statement.
! “N” signifies that the school prints the disclosure statement.
! The default for this option is based on a one-time data feed from
DLOS.
! Direct Loan schools may update this option at anytime on the COD
website.

! This option may be overridden by the <DiscStmtPrtInd> tag on the

Common Record.

Note: For more information on Disclosure Statements, please see the

Generating Disclosure Statement section.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-17
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Administrative Cost Allowance Option

This processing option determines whether or not the school will receive
the Pell Administrative Costs Allowance (ACA).

Business Rules:

! The values for this option are “N” or “Y.”

! “Y” signifies that the school will receive the ACA.
! “N” signifies that the school will not receive the ACA.
! The default for this option is based on a one-time data feed from
RFMS.
! Pell Grant schools may contact FSA to update this option.

Note: For more information on the Administrative Cost Allowance,

please see the Pell Administrative Cost Allowance (ACA) section.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-18
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pell Grant Error Processing Option

This processing option determines whether the COD System rejects or
corrects certain Pell Grant data elements that do not pass edits.

Business Rules:

! The values for this option are “Rejected” or “Corrected.”

! “Rejected” signifies that the COD System will reject certain Pell
Grant data elements that do not pass edits.
! “Corrected” signifies that the COD System will correct certain Pell
Grant data elements that do not pass edits.
! The default for this option is “Corrected.”
! Full Participant Pell Grant schools may update this option at
anytime on the COD website.
Note: The appropriate edits are listed in Appendix E - Edit Comment
Codes and Descriptions, with an Error Type Edit Code of “C/R”.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-19
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Response Records Generated Based on Web

Activities
This processing option determines whether the COD System sends
Response Documents to the school’s SAIG mailbox based on activity
performed on the COD website. This activity includes processing a new
student, award or disbursement, or a change to any of these on the COD
website.

Business Rules:

! The values for this option are “N” or “Y.”

! “Y” signifies that the COD System will send a Response
Document to the school’s SAIG mailbox based on activity
performed on the COD website.
! “N” signifies that the COD System will not send a Response
Document to the school’s SAIG mailbox based on activity
performed on the COD website.
! The default for this option is “N.”
! Schools may update this option at anytime on the COD website.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-20
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Number of Future Days to Display Disbursements

This processing option determines the number of days into the future that a
school can view estimated disbursements on the COD website.

Business Rules:

! The values for this option are 1 - 999 days.

! The default for this option is 14 days.
! Schools may update this option at anytime on the COD website.
Note: There is no limit to the number of days in the past that a school can
view anticipated disbursements on the COD website.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-21
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Valid Format Rules

Maximum Length Values and Leading Zeros

XML does not require that the data occupy the maximum length specified
for a tag.

Business Rules:
! Do not include leading zeros and spaces to satisfy the maximum
length for a given tag.

Example:
In the example below, the student’s first name, John, is four (4) characters
long. Although the first name tag has a maximum length of 12 characters,
leading zeros or spaces are not necessary to occupy the maximum length
of the tag.
<FirstName>John</FirstName>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-22
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Empty (Blank) and Nillable (Null) Tags

The COD System differentiates between a tag being empty (blank) and a
tag being null in the database.

Business Rules:
! An empty tag is one in which content of the tag equals blank or
spaces.
! An empty tag is reported as:
o <LowTuitFeesInd></LowTuitFeesInd>
OR
o <LowTuitFeesInd/>
OR
o <LowTuitFeesInd> </LowTuitFeesInd>

! Tags not necessary or not applicable for the document submission

must be omitted, rather than reported as empty. See EXAMPLE #1.
! Tags that can contain blank as a valid value have <xsd:
enumeration value= “ “/> defined for them in the XML Schema.
! If a school reports blank for a tag that does NOT have blank as a
valid value defined in the XML Schema, the tag will reject with
error code 996.
! If a school reports blank for a tag that does have blank as a valid
value defined in the XML Schema, blank will override the data in
the COD database.
! A null tag is used to remove or delete content currently on the
COD database.
! An null tag is reported as:
o <LowTuitFeesInd xsi:nil=“true”>
! Tags that can contain null values have nil="true" attribute set for
them in the XML Schema.
! If a tag has a minOccurs greater than zero and the school has no
content to report in that tag, the school must report a null tag. See
EXAMPLE #2.

Example:
EXAMPLE #1
If a student does not have a middle initial, the Middle Initial tag should be
omitted from the Common Record, rather than reported as empty or blank.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-23
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<Name>
<FirstName>SUE</FirstName>
<LastName>SMITH</LastName>
</Name>

For Pell Grants, the Total Weeks of Instruction Time, <InstructWksUsed>,

is not applicable for Payment Methodology 1. In these cases, this tag
should not be included in the document, rather than reported as empty.

For Direct Loans, the Additional Unsubsidized Loan for Health

Professionals Flag, <AddtHPPA>, is not necessary if the student does not
qualify. In these cases, this tag should not be included in the document,
rather than reported as empty.

EXAMPLE #2
StateProv is a required tag in the Address complex element. StateProv has
a minimum length of 2 characters and therefore, the tag can not be
submitted as empty. Additionally, blank is not an enumerated value. If
reporting a foreign address where StateProv is not applicable, the
StateProv tag must be reported as null, rather than being omitted or
reported as empty or blank.

<StateProv xsi:nil='true'></StateProv>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-24
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Data Types
The Common Record includes the following data types:
! Date
! Date/Time
! Year
! Decimal
! Integer
! String
! Boolean
Note: Each of these data types is discussed in detail below.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-25
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Date Fields
All date fields on the Common Record use the following format: CCYY-
MM-DD.

Business Rules:
! The dashes must be included.
! The CC designates the Century.
! The YY designates the Year.
! The MM designates the Month.
! The DD designates the Day.
! A leap year is defined as one in which the value of YY is divisible
by four (4).
! In a leap year, the valid values for DD are “01 – 29” when MM is
equal to “02”.
Note: This leap year logic represents no change from prior years.

Year Fields
All year fields on the Common Record use the following format: CCYY.

Business Rules:
! The CC designates the Century.
! The YY designates the Year.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-26
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Date/Time Fields
All date/time fields on the Common Record use the following format:
CCYY-MM-DDThh:mm:ss.ff.

Business Rules:
! The punctuation marks (dashes, colons and decimal point) must be
included.
! The CC designates the Century.
! The YY designates the Year.
! The MM designates the Month.
! The DD designates the Day.
! The T is the date/time separator.
! The hh designates the Hour.
! The mm designates the Minutes.
! The ss designates the Seconds.
! The ff designates the hundredths of a second. This value may be
zero (00).

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-27
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Decimal Fields
Decimal fields on the Common Record are either dollar amount fields or
percentage fields. Each of these field types is described in detail below.

Dollar Amount Fields

Dollar amount fields on the Common Record use the following format: 0-
999999999999.99.

Business Rules:
! Leading zeros are not necessary to occupy the maximum length of
the field.
! Dollar amount fields may include two digits to the right of a
decimal point.
! If a dollar amount reported by the school does not contain a
decimal point, the COD System infers a decimal point and two
zeros after the last digit reported. See EXAMPLE #1 below.
! To report cents (partial dollar amounts), the school must submit a
decimal point and the digits to the right of the decimal point. See
EXAMPLE # 1 below.
! When reporting a positive dollar amount, the school must submit
amount fields without a sign indicator.
! When reporting a negative dollar amount, the school must submit
the amount field with the negative sign in the lead character, e.g.
FISAP Income Override. See EXAMPLE #2 below.
! Common Records may be returned to the source with a negative
sign in the lead character of a dollar amount field, e.g. Payment to
Servicer Amount. See EXAMPLE #3
! The following fields on the Common Record are dollar amount
fields:
o Total Award Amount Reported, <TotAwardAmtRep>
o Total Disbursement Amount Reported, <TotDisbAmtRep>
o Award Amount, <AwardAmt>
o Federal Share Amount, <FedShareAmt>
o FISAP Income Override, <FISAPIncomeOverride>
o Award Amount Requested, <AwdAmtReq>
o Cost of Attendance, <CostofAttend>
o Disbursement Amount, <DisbAmt>
o Disbursement Net Amount, <DisbNetAmt>
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-28
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o Disbursement Fee Amount, <DisbFeeAmt>

o Interest Rebate Amount, <IntRebateAmt>
o Payment to Servicer Amount, <PmtSvcrAmt>
o Booked Loan Amount, <BkdLoanAmt>
o Year to Date Disbursement Amount, <YrTDDisbAmt>
o Scheduled Federal Pell Grant, <SchedFedPellGrt>
o Total Amount Accepted, <TotAmtAcc>
o Total Amount Corrected, <TotAmtCorr>

Example:
EXAMPLE #1:
When reporting an amount of $2625.34:

1) Include the decimal point and two digits to the right: 2625.34
OR
2) Include the decimal point and two zeroes to the right: 2625.00
OR
3) Omit the decimal point and report the whole dollar amount only: 2625
Then, the COD System infers a decimal point and two zeros and stores
2625.00

DO NOT submit 262500 as the COD System infers a decimal and stores
this submission as 262500.00.

EXAMPLE #2:
The FISAP Income Override field can be reported with a negative value
for campus-based information.

FISAPIncomeOverride>-10000</FISAPIncomeOverrride>

EXAMPLE #3:
The Payment to Servicer Amount is returned with a negative sign as the
lead character in the amount field.

<PmttoSvcrAmt>-1000.00</PmttoSvcrAmt>

Note: Refer to the Generating Payment for Servicer Response section for
more information on the Payment to Servicer Amount.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-29
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Percentage Fields
Percentage fields on the Common Record use the following format: 0 –
999.999

Business Rules:
! Leading zeros are not necessary to occupy the maximum length of
the field.
! Percents must be reported as whole numbers or mixed numbers
without the percent sign.
! The following fields on the Common Record are percentage fields:
o Origination Fee Percentage, <OrigntnFeePct>
o Interest Rebate Percentage, <IntRebatePct>
o Total Eligibility Used, <TotEligUsed>

Example:
Three percent (3%) is reported as 3 or 3.0 and the COD System stores as
3.000
One and a half percent (1.5%) is reported as 1.5 and the COD System
stores as 1.500

Note: Please refer to Appendix C - Common Record Layout for more

information on valid values and formats on specific fields.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-30
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Integer Fields
Integer fields on the Common Record are non-dollar amount, non-
percentage, numeric fields.

! Integer fields contain whole numbers.

! Integer fields do not contain decimal points, dollar or percent signs.

String Fields
String fields on the Common Record are alphanumeric fields that can
contain a variety of characters.

! String fields can contain all ASCII characters.

Boolean Fields
Boolean fields on the Common Record are fields that have exactly two
values: true or false

! Boolean fields contain a value of ‘true’ or ‘false.’

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-31
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Document Information Rules

Document
An XML document is the vehicle through which data is transmitted. A
Common Record transmission is considered to be an XML document. A
Common Record transmission, or document, may contain multiple awards
and multiple disbursements for one or multiple students. It can be thought
of as a batch.

Document Submission
All documents submitted for the 2002-2003 award year must be submitted
via the Electronic Data Exchange.

Business Rules:
! All documents must be submitted via the Student Aid Internet
Gateway (SAIG).
! Each transmission must have a SAIG transmission batch header
(O*N05) and trailer (O*N95) record.
! Each transmission must have the SAIG transmission header
(O*N01) and trailer (O*N99) record.
! Only one Common Record can be submitted within each pair of
SAIG transmission batch header (O*N05) and trailer (O*N95).
! Multiple pairs of SAIG transmission batch headers (O*N05) and
trailers (O*N95) can be submitted within the SAIG transmission
headers (O*N01) and trailers (O*N99). See EXAMPLE below.
Note: For further information, please refer to the “SFA Host
Communication Guide”
http://www.sfadownload.ed.gov/mainframeguide.htm

Example:

N01 – Transmission Header

N05 – Transmission Batch Header
<CommonRecord>
</CommonRecord>
N95 - Transmission Batch Trailer
N05 - Transmission Batch Header
<CommonRecord>
</CommonRecord>
N95 – Transmission Batch Trailer
N99 - Transmission Trailer

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-32
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Document Validation
If a document does not validate against the XML Schema, the COD
System does not process the document.

Business Rules:
! The COD System contains a validation program that ensures that
the Common Record documents are well formatted and properly
structured.
! The COD System does not process a document if:
o The Document ID is missing or incomplete.
OR
o The document structure does not meet the rules of the XML
Common Record Schema.
OR
o More than one Common Record document is inserted
between a pair of SAIG Transmission Batch Header and
Trailers.
! When a Common Record is submitted with a missing or
incomplete Document ID, the COD System cannot return a receipt
or response to the sender.
! When a Common Record document does not meet the rules of the
XML Schema, the COD System returns a Receipt and Response
with an error code and message.
! When more than one Common Record is inserted between a pair of
SAIG Transmission Batch Headers and Trailer, the COD System
returns a Receipt and Response with an error code and message.
Note: This is not an issue if you use Edconn32.
Note: Please refer to the Document ID Required for Document
Submission, Sequence of Data Elements Required for Document
Processing, and Document Submission sections for more
information.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-33
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Sequence of Data Elements Required for Document

Processing
The sequence of data within the Common Record is dictated by the
sequence of data elements presented in the XML Schema.

Business Rules:
! Data elements submitted by a school must occur in the same
sequence as depicted in the XML Schema.
! A Common Record submitted with data elements out of sequence
will not validate against the XML schema, and will therefore be
rejected.

Documents Must be Submitted by a Full Participant

The COD System accepts Common Records submitted by Full
Participants. Phase-in Participants must submit records in the Direct Loan
or Pell Grant fixed-length record formats to the COD System.

Business Rules:
! XML Common Records submitted by Phase-In Participants are
rejected.
! Fixed-length format records submitted by Full Participants are
rejected.
Note: For information on the fixed-length record formats, refer to the
Direct Loan Technical Reference and Pell Grant Technical Reference
available on www.ifap.ed.gov.

Logical Record Length Limitation

For information on the 32 kilobyte file length limitation and
recommended solution, refer to Appendix J – Common Record
Physical Layout.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-34
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

COD Receipts
COD Receipts are generated for every document received by the COD
System. The COD Receipt indicates that the Common Record document
was received and can be read by the COD System.

Business Rules:
! One COD Receipt is generated per Common Record document
received by the COD System.
! The COD Receipt is generated after the COD System validates the
Common Record against the XML Schema, but before actual
processing of the Common Record.

Example:
EXAMPLE #1:
The following is an example of a COD Receipt without errors:

<CommonRecord>
<DocumentId>2002-03-18T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-03-18T09:20:01.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="12345678"/>
</Destination>
<Receipt>2002-03-18T09:21:00.00</Receipt>
</CommonRecord>

EXAMPLE #2:
The following is an example of a COD Receipt with errors:
<CommonRecord>
<DocumentId>2002-03-18T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-03-18T09:20:01.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="12345678"/>
</Destination>
<Receipt>2001-03-18T09:21:00.00</Receipt>
<Response>
<DocumentStat>R</DocumentStat>
</Response>
</CommonRecord>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-35
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Minimum Data Elements Required for Document

Processing
The COD System requires certain data elements for processing each
complex element of the document.

Business Rules
! The following data elements are required for processing a Direct
Loan Subsidized or Unsubsidized Award:
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<DLLoanInfo LoanKey=“”>
<OrigntnFeePct>
<IntRebatPct>
<GradeLevelInd>
<AwardBeginDt>
<AwardEndDt>
<AcYrBeginDt>
<AcYrEndDt>
<DLSub/Unsub>
<AwardYr>
<CPSTransNum>
<AwardAmt>
<LoanKey>
<LDefGOver>
<AppliesTo>
<Value>
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-36
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<AwardNum>
<AwardId>
<AwardCreateDt>

! The following data elements are required for processing a Direct

Loan PLUS Award:
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<DLLoanInfo LoanKey=“”>
<OrigntnFeePct>
<IntRebatPct>
<GradeLevelInd>
<AwardBeginDt>
<AwardEndDt>
<AcYrBeginDt>
<AcYrEndDt>
<PLUS>
<AwardYr>
<AwardAmt>
<LoanKey>
<LDefGOver>
<AppliesTo>
<Value>
<AwardNum>
<AwardId>
<AwardCreateDt>
<AwardAmtRqd>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-37
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<Borrower SSNum=“” DtofBirth=“” LastName=“”>

<Identifiers>
<FirstName>
<Contacts>
<Address>
<Addr>
<City>
<StateProv>
<PostalCd>
<CitznStatusInd>
<LdefGOver>
<AppliesTo>
<Value>

! The following data elements are required for processing a change

to a Direct Loan (Subsidized, Unsubsidized, or PLUS) Award:
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<DLSub/DLUnsub/PLUS>
<AwardYr>
<AwardID> (Optional)
<AwardNum>
! The following data elements are required for processing a Direct
Loan edit only disbursement (Payment Trigger set to “false”):
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-38
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<Source Entity ID=“”>

<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<TotDisbAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<DLSub/DLUnsub/DLPLUS>
<AwardYr>
<AwardID> (Optional)
<AwardNum>
<Disbursement>
<Disbursement Number =“”>
<DisbAmt> (if new disbursement)
<DisbDt> (if new disbursement)
<DisbNetAmt> (if new disbursement)
<DisbFeeAmt> (if new disbursement)
<IntRebateAmt> (if new disbursement)
<PmtTriggerFlg = “false”>

! The following data elements are required for processing an actual

Direct Loan disbursement (Payment Trigger set to “true”):
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-39
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<TotAwardAmtRep>
<TotDisbAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<DLSub/DLUnSub/DLPLUS>
<AwardYr>
<AwardID> (Optional)
<AwardNum>
<Disbursement>
<Disbursement Number=“”>
<DisbAmt>
<DisbDt>
<DisbSeqNum>
<DisbNetAmt>
<DisbFeeAmt>
<IntRebateAmt>
<PmtTriggerFlg = “true”>

! The following data elements are required for processing a Pell

Grant Award:
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<Pell>
<AwardYr>
<CPSTransNum>
<AwardAmt>
<CostOfAttend>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-40
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<AcCal>
<PmtMethod>
<InstructWksUsed> (Payment Methodology 2,3,4,5 only)
<IstructWksDefiningAcYr>(Payment Methodology 2,3,4,5 only)
<CrClockHrsinAwardYr> (Academic Calendar 5 & 6 only)
<CrClockHrsinProgsAcYr> (Academic Calendar 5 & 6 only)
<EnrollDt>

! The following data elements are required for processing a change

to a Pell Grant Award:
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<Pell>
<AwardYr>
<CPSTransNum>

! The following data elements are required for a Pell Grant edit only
disbursement (Payment Trigger set to “false”):
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-41
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<TotDisbAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<Pell>
<AwardYr>
<Disbursement>
<Disbursement Number =“”>
<DisbAmt> (if a new disbursement)
<DisbDt> (if a new disbursement)
<PmtTriggerFlg = “false”> (if a new disbursement)

<PmtPeriodStartDt> (if school ineligible)

! The following data elements are required for processing an actual
Pell Grant disbursement (Payment Trigger set to “true”):
<CommonRecord>
<DocumentID>
<CreatedDtTm>
<Source>
<Source Entity ID=“”>
<Destination>
<Destination Entity ID=“”>
<ReportingSchl Entity ID=“”>
<ReportedSummary>
<AwardType>
<SummaryYr>
<TotNumStuds>
<TotAwardAmtRep>
<TotDisbAmtRep>
<AttendingSchl Entity ID=“”>
<Student SSNum=“” DtofBirth=“” LastName=“”>
<Pell>
<AwardYr>
<Disbursement>
<Disbursement Number=“”>
<DisbAmt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-42
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<DisbDt>
<DisbSeqNum>
<PmtTriggerFlg = “true”>

<PmtPeriodStartDt> (if school ineligible)

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-43
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Document ID Required for Document Submission

The COD System checks to ensure the Document ID is present and is
properly formatted.

Business Rules:
! Document ID is an essential element for importing, storing and
tracking the data submitted in a Common Record Document by a
school.
! The COD System rejects documents that do not have a Document
ID.
! The COD System rejects documents that have an incomplete
Document ID.
! The COD System rejects documents that have an invalid
Document ID format.
! The entity ID listed in the Document ID must be the same entity ID
as the Source Entity ID.
Note: Please refer to Appendix C - Common Record Layout for
proper format of the Document ID.
! The COD System is unable to store a Common Record document
that has an invalid, incomplete, or missing Document ID.
! The COD System cannot return a receipt to a sender that submits
an invalid, incomplete, or missing Document ID.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-44
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Duplicate Document IDs

The COD System checks the Document ID for duplicates on the COD
database.

Business Rules:
! Document ID for Full Participants is defined as the DateTime
stamp and the Source Entity ID.
Note: Please refer to Appendix C - Common Record Layout for an
example of a Document ID.
! A duplicate document is defined as a document that has a
Document ID identical to one already established on the COD
System.
! The COD System rejects the document if the Document ID is
duplicate.
! The COD System generates a Receipt if the Document ID is
duplicate.
! The COD System generates a Response with error code and
message for documents with duplicate Document IDs. The
Response does not contain detail data elements.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-45
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Inability to Process Future-Dated Documents

The COD System confirms that the date portion of the Document's
Created DateTime is not greater than the System Date (This represents no
change from prior years).

Business Rules:
! If the date portion of the Document's Created DateTime is greater
than the System Date, the COD System rejects the document.
! The COD System generates a Receipt and a Response for future-
dated documents.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-46
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Documents Submitted Must Contain at Least One

Detailed Record
A detailed record consists of at least one Student Identifier and one Award.
A Student Identifier consists of the student tag and three attributes: Social
Security Number, Date of Birth, and Last Name.

Business Rules:
! The COD System rejects the document if it does not contain at
least one Student Identifier (Social Security Number, Date of Birth
and Last Name) and one Award tag.
Note: For more information on the Student Identifier, please refer
to the Student Identifier section. For more information on the
Award, please refer to the Minimum Data Elements Required for
Document Processing section.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-47
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Entity Information Rules

Common School Identifier

The Common School Identifier is an identifier assigned to Schools and
Third Party Servicers that is common across the Pell Grant and Direct
Loan programs beginning in the 2002 – 2003 award year.

Business Rules:
! The Common School Identifier is the Entity ID.
! The Entity ID is a randomly generated eight-digit number.
! Entity IDs are assigned to Schools, Third Party Servicers, and the
COD System.
! The Entity ID replaces the Pell Institution Number and Direct Loan
(E/G) School code.
Note: The Pell Institution Number is still used in data requests. The
Direct Loan (E/G) School code is still used in the 21 character Award
ID (Loan ID) and the MPN ID.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-48
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Entity ID
A valid Entity ID is required in the Source, Destination, Reporting School,
and Attending School fields.

Business Rules:
! A valid Entity ID must be reported in the following fields:
o Source Entity ID, <Source>
o Destination Entity ID, <Destination>
o Reporting School Entity ID, <ReportingSchlEntityId = “”>
o Attending School Entity ID, <AttendingSchl EntityId = “”>
o A valid Entity ID is the Common School ID (CSID) for the
school or 3rd Party Servicer.
! The Source Entity ID is the physical sender of the document
o The Source Entity ID must be the same Entity ID listed in
the Document ID.
o The Source Entity ID can be a school or 3rd Party Servicer.
o Since the Source Entity sends the Common Record
document to COD, the TG Destination Number reported in
the SAIG Transmission Header and Trailer is more than
likely for the same entity.
! The Destination Entity ID is the destination or recipient of the
document.
o If a School sends the document to the COD System, the
Destination Entity ID is “00000001” for COD.
o If the document is sent from the COD System back to the
Source, the Destination Entity ID is equal to the Source
Entity ID on the original transmission.
o The response file is sent to the TG Number reported in the
Transmission Header and Trailer.
! The Reporting School Entity ID is the school that sends and
receives data for the campuses or students it serves.
o The Reporting School Entity ID must be a school and
cannot be a 3rd Party Servicer.
o The Reporting School Entity ID does not have to be equal
to the Source Entity ID, but must have a relationship with
the Source Entity ID and the TG Destination Number.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-49
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! The Attending School Entity ID is the school or campus where

the student attends class.
o Attending School Entity ID can be equal to the Reporting
School Entity ID
OR
o Attending School Entity ID can be an additional location of
the Reporting School Entity ID.
! Multiple Reporting School Entity IDs and Attending School Entity
IDs can be submitted in the same Common Record.
! The COD System checks each Entity ID against the COD database
and rejects the document if the Entity ID cannot be found or is
invalid.
Note: The Reporting and Attending relationships reported in the
Common Record do not affect the funding process. Funding
relationships are controlled separately from the reporting and attending
relationships.

Note: Currently, if you have separate TG#s numbers for Pell and DL
and you wish to report both Pell and DL in one Common Record,
contact SAIG to complete paperwork to have one TG# (you may
select which number you want to use) that reports both Pell and DL.
This does NOT mean that every Common Record must have both Pell
and Direct Loan information. It simply means your school wants the
option to send both Pell and Direct Loan in the same Common Record
document sometimes. If your school decides to continue processing
sending Pell and Direct Loan information always in separate Common
Record Documents, your school can continue to process using separate
TG numbers.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-50
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:
EXAMPLE 1:
In this first example, a Common Record is submitted for both Pell and
Direct Loan programs for multiple schools using one TG Number for the
SAIG Transmission Batch Header. The Reporting Entity is sending the
Common Record and is reporting awards for two other schools.

School A:
! Reports for two additional locations – School B and School C.
Therefore, this Entity ID is used in the Reporting Entity ID tag.
! Sends the Common Record to COD. Therefore, this Entity ID is
used in the Source Entity ID and the Document ID.
! TG # = 99991. This TG # is used in the SAIG Transmission Batch
Header and Trailer.
! Entity ID = 11111111

School B:
! Has an attending relationship with School A. This Entity ID is
used in the Attending School Entity ID tag.
! TG # is not applicable because School A sends the Common
Record.
! Entity ID = 22222222

School C:
! Has an attending relationship with School A. This Entity ID is
used in the Attending School Entity ID tag.
! TG # is not applicable because School A sends the Common
Record.
! Entity ID = 33333333

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-51
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

SAIG Transmission Header Record

SAIG Transmission Batch Header Record (Header Destination # - TG #99991)
<CommonRecord>
<DocumentId>2002-08-29T09:09:09.0011111111</DocumentId>
<CreatedDtTm>2002-08-29T17:20:01.00</CreatedDtTm>
<Source>
<School EntityId="11111111" />
</Source>
<Destination>
<COD EntityId="00000001" />
</Destination>
<ReportingSchl EntityId="11111111">
<ReportedSummary>
</ReportedSummary>
<AttendingSchl EntityId="22222222">
<Student SSNum=”123456789” DtofBirth=”1985-01-01” LastName=”SMITH”>
</Student>
<Pell>
</Pell>
<DLSub>
</DLSub>
<Student SSNum=”987654321” DtofBirth=”1982-02-20” LastName=”JONES”>
</Student>
<DLSub>
</DLSub>
<DLUnSub>
</DLUnSub>
</AttendingSchl>
<AttendingSchl EntityId="33333333">
<Student SSNum=”456789123” DtofBirth=”1985-07-15” LastName=”CLARK”>
</Student>
<Pell>
</Pell>
<DLSub>
</DLSub>
<Student SSNum=”321654987” DtofBirth=”1983-05-25” LastName=”JONES”>
</Student>
<DLSub>
</DLSub>
<DLUnSub>
</DLUnSub>
</AttendingSchl>
</ReportingScl>
</CommonRecord>
SAIG Transmission Batch Trailer Record (Trailer Destination # - TG #99991)
SAIG Transmission Trailer Record

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-52
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

EXAMPLE 2:
In this second example, a Common Record is submitted for both Pell and
Direct Loan programs for multiple schools using one TG Number for the
SAIG Transmission Batch Header. A Third Party Servicer is sending the
records for multiple schools.

Third Party Servicer:

! Sends the Common Record to COD for Schools D and E.
Therefore, this Entity ID is used in the Source Entity ID and the
Document ID.
! TG # = 88888. This TG # is used in the SAIG Transmission Batch
Header and Trailer.
! Entity ID = 44444444

School D:
! Uses a Third Party Servicer to send records to COD; however, does
its own reporting for students that attend its campus. This Entity
ID is used in the Reporting School Entity ID and Attending School
Entity ID tag.
! TG # is not applicable because the Third Party Servicer sends the
Common Record.
! Entity ID = 55555555

School E:
! Uses a Third Party Servicer to send records to COD; however, does
its own reporting for students that attend its campus. This Entity
ID is used in the Reporting School Entity ID and Attending School
Entity ID tag.
! TG # is not applicable because the Third Party Servicer sends the
Common Record.
! Entity ID = 66666666

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-53
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

SAIG Transmission Header Record

SAIG Transmission Batch Header Record (Header Destination # - TG #88888)
<CommonRecord>
<DocumentId>2002-08-29T09:09:09.0044444444</DocumentId>
<CreatedDtTm>2002-08-29T17:20:01.00</CreatedDtTm>
<Source>
<ThirdPartyServicer EntityId="44444444" />
</Source>
<Destination>
<COD EntityId="00000001" />
</Destination>
<ReportingSchl EntityId="55555555">
<ReportedSummary>
</ReportedSummary>
<AttendingSchl EntityId="55555555">
<Student SSNum=”123456789” DtofBirth=”1985-01-01” LastName=”SMITH”>
</Student>
<Pell>
</Pell>
<DLSub>
</DLSub>
<Student SSNum=”987654321” DtofBirth=”1982-02-20” LastName=”JONES”>
</Student>
<DLSub>
</DLSub>
<DLUnSub>
</DLUnSub>
</AttendingSchl>
</ReportingScl>
<ReportingSchl EntityId="66666666">
<ReportedSummary>
</ReportedSummary>
<AttendingSchl EntityId="66666666">
<Student SSNum=”456789123” DtofBirth=”1985-07-15” LastName=”CLARK”>
</Student>
<Pell>
</Pell>
<DLSub>
</DLSub>
<Student SSNum=”321654987” DtofBirth=”1983-05-25” LastName=”JONES”>
</Student>
<DLSub>
</DLSub>
<DLUnSub>
</DLUnSub>
</AttendingSchl>
</ReportingScl>
</CommonRecord>
SAIG Transmission Batch Trailer Record (Trailer Destination # - TG #88888)
SAIG Transmission Trailer Record

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-54
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Total Number of Students in the Reported Summary

Complex Element
The COD System verifies the Total Number of Students reported in
Reported Summary complex element equals the total number of
students/borrowers in the document.

Business Rules:
! The COD System compares the Total Number of Students,
<TotNumStuds>, reported against the actual total number of
student tags in the document.
! The COD System determines the actual total number of students in
the Document by counting the number of Student Identifiers (SSN,
Date of Birth and Last Name) in the document.
Note: For more information on the Student Identifiers, please refer
to the Student Identifier section.
! The COD System sends a warning if the reported Total Number of
Students and the actual number of student tags are not identical.
The warning does not prevent the document from being processed
by the COD System.
! The Total Number of Students reported may be a duplicated count.
In the event that identical Student Identifiers are reported multiple
times within a document, the COD System counts them multiple
times.
! The Total Number of Students is reported by Award Year, by
Program (Pell, DL Subsidized, DL Unsubsidized, DL PLUS, and
Campus Based), and by Reporting School Entity ID.

Example:
<ReportingSchl EntityId="00123400">
<ReportedSummary>
<AwardType>DLSub</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>2000</TotAwardAmtRep>
<TotDisbAmtRep>1970</TotDisbAmtRep>
</ReportedSummary>
<ReportedSummary>
<AwardType>Pell</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>3700</TotAwardAmtRep>
<TotDisbAmtRep>3700</TotDisbAmtRep>
</ReportedSummary>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-55
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Total Award Amount Reported in the Reported School

Complex Element
The COD System verifies the Total Award Amount reported in the
Reported Summary complex element equals the actual total of all Award
Amounts contained in the document.

Business Rules:
! The COD System compares the Total Award Amount Reported,
<TotAwardAmtRep>, against the actual total of all Award
Amounts contained in the document.
! The COD System determines the actual total of all Award
Amounts by adding the values of all the Award Amount tags in the
document.
! The COD System sends a warning if the Total Award Amount
Reported and the actual total of all Award Amounts is not equal.
The warning does not prevent the document from being processed
by the COD System
! The Total Award Amount must be reported by Award Year, by
Program (Pell, DL Subsidized, DL Unsubsidized, DL PLUS, and
Campus Based), and by Reporting School Entity ID.

Example:
<ReportingSchl EntityId="00123400">
<ReportedSummary>
<AwardType>DLSub</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>2000</TotAwardAmtRep>
<TotDisbAmtRep>1970</TotDisbAmtRep>
</ReportedSummary>
<ReportedSummary>
<AwardType>Pell</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>3700</TotAwardAmtRep>
<TotDisbAmtRep>3700</TotDisbAmtRep>
</ReportedSummary>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-56
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Total Disbursement Amount Reported in the Reported

Summary Complex Element
The COD System verifies the Total Disbursement Amount Reported in the
Reported Summary complex element equals the actual total of all
Disbursement Amounts contained in the document.

Business Rules:
! The COD System compares the Total Disbursement Amount
Reported, <TotDisbAmtRep>, against the actual total of all
Disbursement Amounts contained in the document.
! The COD System determines the actual total of all Disbursement
Amounts by adding the values of the Disbursement Amount
(gross) fields, regardless of whether the Payment Trigger is “true”
or “false,” in the document.
! The COD System sends a warning if the Total Disbursement
Amount Reported and the actual total of all Disbursement
Amounts are not equal. The warning does not prevent the
document from being processed by the COD System.
! The Total Disbursement Amount Reported must be reported by
Award Year, by Program (Pell, DL Subsidized, DL Unsubsidized,
DL PLUS, and Campus Based), and by Reporting School Entity
ID.

Example:
<ReportingSchl EntityId="00123400">
<ReportedSummary>
<AwardType>DLSub</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>2000</TotAwardAmtRep>
<TotDisbAmtRep>1970</TotDisbAmtRep>
</ReportedSummary>
<ReportedSummary>
<AwardType>Pell</AwardType>
<SummaryYr>2003</SummaryYr>
<TotNumStuds>1</TotNumStuds>
<TotAwardAmtRep>3700</TotAwardAmtRep>
<TotDisbAmtRep>3700</TotDisbAmtRep>
</ReportedSummary>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-57
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Person Information Rules

Student Identifier
The COD Student Identifier is composed of the student’s current Social
Security Number, current Date of Birth, and current Last Name. Current is
defined as the value stored in COD as of the date of the transmission.

Business Rules:
• The Student Identifier is located in the Student complex element of
the Common Record, and is reported by the school.
• A Student Identifier is a required data element for all submissions
of a Common Record.
• A Student Identifier consists of the student tag and three attributes:
the student’s current Social Security Number, current Date of
Birth, and current Last Name.
o The Social Security Number portion of the Student
Identifier must contain nine digits.
o The Social Security Number portion of the Student
Identifier must be within the range of 001-01-0001 to 999-
99-9998.
o The Social Security Number portion of the Student
Identifier may or may not contain hyphens after the third
and fifth digits.
o The Date of Birth portion of the Student Identifier must be
in the CCYY-MM-DD format.
o The Date of Birth portion of the Student Identifier must be
greater than 1902-01-01 and less than 1994-12-31.
o The Last Name portion of the Student Identifier may
consist of upper case letters A-Z, numbers 0-9, spaces,
period, apostrophe and dash.
o The Last Name portion of the Student Identifier may be
blank.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-58
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

• All three attributes of the Student Identifier (current Social Security

Number, current Date of Birth, and current Last Name) are
required for processing by the COD System; however, only
current SSN is required on the Common Record Schema.
Note: The Common Record Schema is structured this way to enable
the FFEL community to use the schema structure without using Date
of Birth and Last Name as identifiers.
• The Student Identifier submitted by a school to establish the
student on COD is matched to data from the CPS.
o For Pell Grants, the SSN, Date of Birth, and first two
characters of the Last Name are matched with the CPS data.
o For Direct Loans, the SSN and Date of Birth are matched
with the CPS data.
Note: Please refer to the Data Elements Matched Against CPS
section for more information.
• If a match is found on CPS, COD accepts the student and
establishes the student identifier on COD. The student identifier
must be submitted in subsequent transactions for that student.
Note: Please refer to the Changing Student Identifier Information
section for more information on making corrections or updates to
the student identifier.
• If a match is not found on CPS, COD rejects the student and
returns an error code of 011.

Example:

<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-59
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Changing Student Identifier Information

In order to change Student Identifier information, the school must first
submit a correction to the ISIR, which will result in another transaction on
the CPS. After the correction has been submitted to the CPS, the school
must send a Common Record to the COD System reporting the student tag
with the current Student Identifier information and the changed data in the
corresponding simple element (Social Security Number, Date of Birth, or
Last Name).

Business Rules:
• The COD System either Accepts or Rejects changes that are
submitted to the Social Security Number, Date of Birth, or Last
Name simple elements.
• COD stores one Student Identifier for a student.
• COD does not store separate Student Identifiers for each award.
• Upon receipt of a changed Social Security Number, Date of
Birth, or Last Name simple element, the COD System attempts
to match the changed simple element against the CPS.
Note: Please refer to the Fields Matched Against the CPS
section for more information.
o If an identical change is found on the CPS, the COD
System accepts the changed simple element,
updates the Student Identifier, and sends a Response
to the school.
o If an identical change is not found on the CPS, the
COD System rejects the changed simple element,
and sends a Response to the school.
• Regardless of whether the changed simple element is
accepted or rejected by the COD System, the old Student
Identifier is returned in the Response.
• .
• If the changed simple element is accepted, the school must
submit the new Student Identifier combination in future
transmissions.
• If the changed simple element is rejected, the old Student
Identifier combination must be used in future
transmissions.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-60
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

• The COD System stores the Social Security Number

previously submitted to the COD System for query
purposes on the COD website.
• If the Social Security Number, Date of Birth, or Last Name
simple element is submitted with the same value that is
listed in the attribute on the COD database, no update takes
place and the submission rejects.
• If a combination of the current Social Security Number,
current Date of Birth, or current Last Name simple
elements are changed in the same submission, all changes
must be matched on the CPS.
o If all changes are not matched on the CPS, the COD
System rejects all changed simple elements and the
old Student Identifier is returned in the Response to
the school.

Example:
A student’s last name changes from Oldhat to Newburry. Once the
correction has been submitted to the CPS, the appropriate submission to
the COD System is:
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="OLDHAT">
<Name>
<LastName>NEWBURRY</LastName>
</Name>
</Student>

The COD Response contains the old student identifier:

<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="OLDHAT">

If the COD System accepts the change, subsequent transmissions by the

school must contain:
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="NEWBURRY">

If the COD System rejects the change, subsequent transmissions by the

school must contain:
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="OLDHAT">

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-61
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Person Identifier
The Person Identifier is used to submit parent borrower data when
processing a PLUS Loan.

The COD Person Identifier is composed of the parent borrower’s current

Social Security Number, current Date of Birth, and current Last Name.
Current is defined as the value stored in COD as of the date of the
transmission.

Business Rules:
• The Person Identifier is located in the Person complex element of
the Common Record, and is reported by the school.
• A Person Identifier is a required data element for all submissions
for a PLUS Loan.
• A Person Identifier consists of the person tag and three attributes:
the person’s current Social Security Number, current Date of Birth,
and current Last Name.
o The Social Security Number portion of the Person Identifier
must contain nine digits.
o The Social Security Number portion of the Person Identifier
must be within the range of 001-01-0001 to 999-99-9998.
o The Social Security Number portion of the Person Identifier
may or may not contain hyphens after the third and fifth
digits.
o The Date of Birth portion of the Person Identifier must be
in the CCYY-MM-DD format.
o The Date of Birth portion of the Person Identifier must be
greater than 1902-01-01 and less than 1994-12-31.
o The Last Name portion of the Person Identifier may consist
of upper case letters A-Z, numbers 0-9, spaces, period,
apostrophe and dash.
o The Last Name portion of the Person Identifier may be
blank.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-62
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

• All three attributes of the Person Identifier (current Social Security

Number, current Date of Birth, and current Last Name) are
required for processing by the COD System; however, only
current SSN is required on the Common Record Schema.
Note: The Common Record Schema is structured this way to enable
the FFEL community to use the schema structure without using Date
of Birth and Last Name as identifiers.
• The Person Identifier submitted by a school to establish the parent
borrower on COD is NOT matched with data from CPS.
• Changes to the Person Identifier as submitted use the same process
for updating a Student Identifier. However, the updates are NOT
matched to CPS data on file at COD.
• COD stores one Person Identifier for a person.
• COD does not store separate Person Identifiers for each award.

Example:

<Person SSNum="123456789" DtofBirth="1962-01-01" LastName="SMITH">

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-63
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

School Use Only Field

A School Use Only Field, <SchlUseOnly>, is included on the Common
Record in the Student, Award, and Disbursement complex elements. This
field can be used by the school for any purpose and is ignored during COD
processing.

Business Rules:
! Regardless of whether the school opts for a Full or Standard
Response, the School Use Only field is returned in the Response
complex element if the school submits the field in the Common
Record.
! The School Use Only field is returned in all COD system-generated
Response Documents if the field is populated on the COD
database.

Example:

EXAMPLE #1:
The school uses a unique identifier for the student in their system. The
school uses the <SchlUseOnly> field in the Student complex element to
record this unique identifier.

<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">

<SchlUseOnly>888888</SchlUseOnly>
</Student>

The COD Response complex element contains the <SchlUseOnly> field

with the content submitted in the Common Record:

<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">

<SchlUseOnly>888888</SchlUseOnly>
</Student>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-64
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Updating Phone Numbers

The COD System stores a maximum of three phone numbers for each
person.

Business Rules:
! The Common Record has a maximum occurrence of three phone
number tags per person.
! The COD System stores the first occurrence of phone number as
Home Phone.
! The COD System stores the second occurrence of phone number as
Alternate Phone 1.
! The COS System stores the third occurrence of phone number as
Alternate Phone 2.
! If the Common Record contains only one instance of phone
number, the COD System updates the Home Phone number.
! In order to update the Alternate Phone 1 or Alternate Phone 2, the
school must submit all occurrences of the phone number tag.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-65
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Award Information Rules

CPS Transaction Number

The CPS Transaction Number is a required field on the Common Record
for Pell Grant and Direct Loan (DL Subsidized, DL Unsubsidized)
processing.

Business Rules:
! The CPS Transaction Number is a required field on the Common
Record for Pell Grant and Direct Loan (DL Subsidized, DL
Unsubsidized) Award information.
Note: The CPS Transaction Number is not a required field for DL
PLUS loans.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-66
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Student Identifier and Data Elements Matched

Against the CPS
COD Performs two matches against CPS. The first match confirms that
the Student Identifier exists on the CPS. The second match validates
certain data elements for editing purposes. This match utilizes the CPS
Transaction Number submitted by the school. These edit data elements
are outlined in the next section entitled “Data Elements Pulled from the
CPS”.

Business Rules:

! COD stores one Student Identifier for a student. COD does not
store separate Student Identifiers for each award.
! CPS Transaction Number is stored at the Award Level.
! The COD System performs a match against the CPS when a
Common Record contains:
o A new student with an award (See Example 1)
o A change to the Student Identifier (See Example 2)
o A new award with a new CPS Transaction Number (See
Example 2)
o An existing award with a new CPS Transaction Number
(See Example 3)
! When a Common Record contains a new student with a Pell Grant
award,
o COD matches the SSN, Date of Birth, first two characters
of the Last Name, and the CPS Transaction Number with
data from CPS.
o COD uses the CPS Transaction Number submitted to pull
data elements from CPS for processing the award.
! When a Common Record contains a new student with a Direct
Loan award,
o COD matches the SSN, Date of Birth, and the CPS
Transaction Number with data from CPS.
o COD uses the CPS Transaction Number submitted to pull
data elements from CPS for processing the award.
! When a Common Record contains a change to the Student
Identifier,

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-67
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o COD checks that any CPS Transaction Number greater than

the CPS Transaction Number used to establish the student
exists in the data from CPS.
Note: CPS Transaction Number is used in the match against
the CPS for the Student Identifier on the initial submission of
the student only, not on changes/maintenance to the Student
Identifier.
o COD matches the changes SSN, Date of Birth and Last
Name with data from CPS. For Direct Loans this match is
only on the Social Security Number (SSN) and Date-of-
Birth.
! When a Common Record contains a new award,
o The Student Identifier needs to be the current Student
Identifier on file at COD.
o COD uses the CPS Transaction Number submitted to pull
data elements from CPS for processing the award.
o COD does NOT match the student identifier data elements
with the CPS Transaction number submitted in the Award
complex element.
! When a Common Record contains a new CPS Transaction
Number for an existing award,
o The Student Identifier needs to be the current Student
Identifier on file at COD.
o COD uses the new CPS Transaction Number submitted to
pull data elements from CPS for processing the award.
o COD does NOT match the student identifier data elements
with the CPS Transaction number submitted in the Award
complex element

Note: Please refer to the Data Elements Pulled from CPS section
for more information.

! COD matches the student identifier data elements in the following

order: SSN, Date of Birth, and Last Name.

Note: It is possible that COD will return error code 012 on SSN
even when a school submitted a change on Date-of-Birth or Name
if the Name and/or Date-of-Birth has not been updated on the CPS.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-68
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! When a new award is submitted with a CPS Transaction Number

already used by a previously accepted award for the same student, a
new CPS match is NOT performed.
! A later CPS Transaction Number submitted by a student or another
school does NOT affect a match performed using an earlier CPS
Transaction Number.
Note: The CPS Transaction Number is not a required field for DL
PLUS loans.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-69
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example # 1: New student and new award

A school submits a Pell Grant for a student (SID = 3188888881982-03-04

Jones) using CPS Transaction Number 01. There is a match at COD on
the CPS data. This establishes the student on the COD Database with a
student identifier: 3138888881982-03-04Jones .

CPS CPS AAF

SAR ID SSN DOB Last Pell EFC
Name Elig?
318888888Jo01 318888888 1982-03-04 Jones Y 0

Current Student Identifier = 3188888881982-03-04 Jones

COD SID Database
SID 318888888 1982-03-04 Jones

Pell Award
CPS Transaction# 01
$4000
Accepted

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-70
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example # 2: New award, New CPS Transaction Number and Change

to student identifier

The student gets married resulting in a Name change from Jones to Taylor.
The student also becomes a graduate student and is no longer Pell eligible.
These changes have already been reported to CPS resulting in a CPS
Transaction Number 03. The school submits a Direct Loan award using
CPS Transaction Number 03 and the current SID of 3188888881982-03-
04Jones, but also submits the name change of Taylor. The Direct Loan
award is accepted as there is a match with CPS data at COD for the new
name of Taylor and CPS Transaction Number 03. The student identifier is
updated to: 313888888 1982-03-04Taylor.

CPS CPS AAF

SAR ID SSN DOB Last Pell EFC
Name Elig?
318888888Jo01 318888888 03/04/1982 Jones Y 0
318888888Jo02 318888888 03/04/1982 Jones Y 250
318888888Jo03 318888888 03/04/1982 Taylor N 0

Current Student Identifier = 3188888881982-03-04Taylor

COD Student Identifier (SID) Database
SID 318888888 1982-03-04 Taylor
SID 318888888 1982-03-04 Jones

Pell Award DL Award

CPS Transaction# 01 CPS Transaction# 03
$4000 $7500
Accepted Accepted

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-71
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example #3: Maintenance to CPS Transaction Number on existing

award

The student EFC changes. The school submits an update to the Direct
Loan using CPS Transaction Number 04. The school submits using
student identifier: 318888888 03/04/1982 Taylor.

CPS CPS AAF

SAR ID SSN DOB Last Pell EFC
Name Elig?
318888888Jo01 318888888 03/04/1982 Jones Y 0
318888888Jo02 318888888 03/04/1982 Jones Y 250
318888888Jo03 318888888 03/04/1982 Taylor N 0
318888888Jo04 318888888 03/04/1982 Taylor N 500

Current Student Identifier = 3188888881982-03-04Taylor

COD Student Identifier (SID) Database
SID 318888888 1982-03-04 Taylor
SID 318888888 1982-03-04 Jones

Pell Award DL Award

CPS Transaction# 01 CPS Transaction #03
$4000 $7500
Accepted Accepted
CPS Transaction# 04
$7250
Accepted

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-72
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Data Elements Pulled from the CPS

The COD System pulls certain data elements from information provided
by the CPS for editing purposes only.

Business Rules:
! The COD System uses the CPS Transaction Number reported in
the Award complex element to pull certain data elements from
information provided by the CPS.

! For each Pell Grant award received, the COD System always pulls
the following data elements from the CPS:
o Expected Family Contribution (EFC)
o Secondary EFC (only in the case where the school has
indicated its intent to pay from the secondary EFC via the
<SecondaryEFCInd> field on the Common Record)
o Verification Selection
! The COD System determines if certain data elements are
transmitted in the Common Record or already exist for the student
and award year on the COD database. If neither is true, the COD
System will ‘pull’ these data elements from information provided
by the CPS.
o For each Pell Grant or Direct Loan award received, the
following data elements are pulled from the CPS
information when absent on both the Common Record
submission and the COD database:
! Address (Only if ALL fields are absent: Address,
City, State, Zip/Postal Code, Country)
! Loan Default/Grant Overpayment for student
! Citizenship status

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-73
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Note: Citizenship status cannot be pulled from the CPS for

PLUS loans and, therefore, is required on the Common
Record for PLUS loans.

o For each Direct Loan award received, the following data

elements are pulled from the CPS information when absent
on both the Common Record submission and the COD
database:
! Dependency Status

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-74
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Disbursement Information Rules

Disbursement Sequence Number Required on all

Disbursements
A Disbursement Sequence Number must be reported for all disbursements.
This is an indicator of a single transaction associated with a specific
disbursement number. This field is currently used in Direct Loan
transactions and continues under the COD System, but it is new for Pell
Grant transactions.

Business Rules:
! The Disbursement Sequence Number determines the order in
which the transaction must be processed for a given Disbursement
Number.
! The Disbursement Sequence Number must be reported in an
incremental, ascending order.
! The Disbursement Sequence Number valid values range from 01-
99.
o Disbursement Sequence Numbers 01-65 are reported by
schools.
o Disbursement Sequence Numbers 66-90 are reserved for
COD system-generated adjustments to disbursements.
o Disbursement Sequence Numbers 99-91 are reserved for
Direct Loan Payment to Servicer transactions (in
descending order).
! The Disbursement Sequence Number must be reported as “01”
when the Payment Trigger is set to “false”.
! Duplicate Disbursement Sequence Numbers for the same
Disbursement Number when the Payment Trigger is set to “true”
are considered duplicate disbursement transactions.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-75
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Payment Trigger
The Payment Trigger is used to identify disbursements that may change
the CFL.

Business Rules:
! Disbursement information with the Payment Trigger set to “true”
are actual disbursements that may change the CFL.
! Disbursement information with the Payment Trigger set to “false”
are treated as edit only and cannot change the CFL.
! For Pell Grant disbursements with a Payment Trigger set to “true”
where the current date exceeds 30 calendar days to the
disbursement date, the COD Systemrejects the record with error
code 051.
! For Direct Loan disbursements with a Payment Trigger set to
“true” where the current date exceeds seven (7) calendar days to
the disbursement date, the COD Systemrejects the record with
error code 051.
Note: The allowable timeframe for submitting actual
disbursements varies by funding method and program. Please see
the Submitting Direct Loan Disbursement Information and
Payment Trigger and the Submitting Pell Grant Disbursement
Information and Payment Trigger sections.
! If the Payment Trigger is absent from the disbursement
information, the COD System sets the Payment Trigger to “false.”
! If the Payment Trigger is set to “true,” the disbursement is
processed only if the required tags in the Disbursement Complex
Element are complete.
Note: For information on the required tags in the Disbursement
complex element, refer to the Minimum Data Elements Required
for Document Processing section.
! For Pell Grants, the Payment Trigger can be changed from “true”
to “false” between 30 and eight (8) calendar days before the
disbursement date.
! The Payment Trigger cannot be changed from “true” to “false”
within and including seven (7) calendar days before the
disbursement date or any time after the disbursement date.
! Disbursement information with a Payment Trigger set to “true” can
be used either to substantiate cash that has been drawn down, or
may lead to a change in the CFL.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-76
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! Disbursement information with a Payment Trigger set to “true”

will not change the CFL until seven (7) calendar days before the
disbursement date.
! To make an adjustment to an accepted and posted actual
disbursement, the Payment Trigger must be set to “true”.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-77
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

General Response Information Rules

Response Documents
For all Common Records received and processed by the COD System, the
COD System returns a Response document indicating the status of
Common Record processing, including any rejected data elements and
reason for the rejection.

Business Rules:
! The COD System sends one Response document for each Common
Record document submitted.
! A Response complex element is generated for each major complex
element reported on a Common Record document: Document,
Reporting School, Student, Award, and Disbursement.
! All Response complex elements are nested within the Response
document.
! Schools have an option to receive a Full or Standard Response to
Common Records processed by the COD System.
o A Full Response contains all the original tags sent by the
School and the rejected data elements and reason codes.
o A Standard Response contains only the rejected data
elements and reason codes.
! Schools can override this option on a record-by-record basis by
submitting the <FullRsFlg> tag on the Common Record.
o If the <FullRsFlg> tag is not sent, the option defaults to the
value set in the School Profile.
o Unless the school contacts the COD School Relations
Center to change this option, the School Profile will default
to a Standard Response.
! For Common Records transmitted via SAIG, the COD System
sends Response Documents to the school’s SAIG mailbox.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-78
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! For Common Records transmitted via the web, schools have an

option to receive a Response either via the web or via their SAIG
mailbox.
o Unless the school contacts COD School Relations Center to
change this option, the school will receive a Response via
the web. This option may be overridden on a record-by-
record basis.

School will receive: If the school sends the Common Record via:

SAIG Mailbox COD Website

Receipt Via SAIG Mailbox N/A
Response Via SAIG Mailbox Via SAIG Mailbox
OR
On COD Website

Example:
The following diagram illustrates a Response complex element is
generated for every complex element of data submitted on the Common
Record and the nesting of those complex elements within the Response
Document:

Common Record
Reporting School
Attending School
Student
Award
Award Response
Disbursement
Disbursement Response
Student Response
Attending School Response
Reporting School Response
Common Record Response

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-79
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Response Indicator
For each Response complex element returned, the COD System generates
a Response Indicator that indicates whether the complex element was
accepted, rejected, or corrected. The Response complex element and
Response Indicator is returned for each major complex element: Reporting
School, Student, Award, and Disbursement.

Business Rules:
! The COD System returns a Response complex element with a
Response Indicator of A (Accepted), R (Rejected) or C
(Corrected).
! A Response complex element with a Response Indicator of A
(Accepted) is returned to indicate that the complex element was
accepted.
! A Response complex element with a Response Indicator of A
(Accepted) may have a warning edit returned on the complex
element.
! A Response complex element with a Response Indicator of A
(Accepted) does not exclude another complex element in the
hierarchy from being accepted, rejected or corrected.
o If a Person complex element is Accepted, this does not
exclude the possibility that the Award or Disbursement
complex elements may be accepted, corrected, or rejected.
o If a Award complex element is Accepted, this does not
exclude the possibility that the Person or Disbursement
complex elements may be accepted, corrected, or rejected
! A Response complex element with a Response Indicator of R
(Rejected) is returned to indicate that 100% of the data elements in
the complex element are rejected.

! A Response complex element with a Response Indicator of R

(Rejected) is returned with at least one reject edit.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-80
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! A Response complex element with a Response Indicator of R

(Rejected) can result in other complex elements being rejected.

o If a Person complex element is rejected, then the Award

complex element is rejected, even if all data in the Award
complex element passed the edits, because the COD
System cannot accept an Award complex element without
an established Person.

o If an Award complex element is rejected, then the

Disbursement complex element is rejected, even if all data
in the Disbursement complex element passed the edits,
because the COD System cannot accept the Disbursement
complex element without an established Award.

o If all Award complex elements in the submission are

rejected, then the Person complex element is rejected,
because the COD system cannot accept a Person complex
element without at least one established Award.
Note: Please refer to the Documents Must Contain At
Least One Detailed Record section for more information.
! A Response complex element with a Response Indicator of C
(Corrected) is returned only when at least one data element within
the complex element has been corrected. Because the COD
System corrects only Pell Grant Award and Disbursement data for
schools that choose to have their data corrected rather than
rejected, an <RsInd> of C is returned only in these complex
elements.
! A Response complex element with a Response Indicator of C
(Corrected) does not preclude another complex element in the
hierarchy from being accepted, rejected or corrected.
o If an Award complex element is corrected, this does not
exclude the possibility that the Disbursement complex
element may be accepted, corrected, or rejected.
o If a Disbursement complex element is corrected, this does
not exclude the possibility that the Award complex element
may be accepted, corrected, or rejected.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-81
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:

Complex Element Processed with Edits Response Indicator

Person No A (Accepted)
Award No A (Accepted)
Disbursement No A (Accepted)

Complex Element Processed with Edits Response Indicator

Person No A (Accepted)
Award Yes (with corrections) C (Corrected)
Disbursement No A (Accepted)

Complex Element Processed with Edits Response Indicator

Person No R (Rejected) *Because
no Awards were
accepted
Award Yes R (Rejected)
Disbursement No R (Rejected) *Because
the Award was not
accepted)

Complex Element Processed with Edits Response Indicator

Person No A (Accepted) *Because
at least one Award was
accepted
Award No A (Accepted)
Award Yes R (Rejected)
Disbursement No R (Rejected) *Because
the Award was not
accepted)

COD Message Classes

For information on the message classes to be used by COD Full
Participants, please refer to Appendix M – COD Message Class Table.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-82
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan Award and Disbursement Process

Utilizing Loan Key for Subsidized and Unsubsidized

Direct Loans
The Loan Key is a shortcut to avoid multiple submission of tags where
data is consistent across loans for a single borrower.

Business Rules:
! There are two reference tags in the Common Record identified as
Loan Key:
o The first tag is an attribute for DLLoanInfo - <DLLoanInfo
LoanKey=”1”>.
o The second tag is a simple element - <LoanKey>.
! Both of these reference tags are required when submitting Direct
Loan Award information.
! These two reference tags link two sections of loan information
together expediting the reporting of similar data across subsidized
and unsubsidized loans for a single borrower.
! A LoanKey number is referenced once but can be used by multiple
subsidized and unsubsidized loans within the same submission.
See EXAMPLE #1.
Note: A PLUS loan within the same submission must have a
unique LoanKey number as some of the shared data elements in
DLLoanInfo always have different values for PLUS. For example,
the Origination Fee for PLUS loans = 4% and for subsidized and
unsubsidized loans =3%.
! It is permissible to send a unique LoanKey for each subsidized and
unsubsidized loan. See EXAMPLE #2.
! A LoanKey references the following data elements shared by
subsidized and unsubsidized loans:
o Origination Fee Percent, <OrigntnFeePct>
o Interest Rebate Percent, <IntRebatePct>
o Promissory Note Print Indicator, <PromNtPrtInd>
o Disclosure Statement Print Indicator, <DiscStmtPrtInd>
o Grade Level Indicator, <GradeLevelInd>
o Award Begin Date, <AwardBeginDt>
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-83
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o Award End Date, <AwardEndDt>

o Academic Year Begin Date, <AcYrBeginDt>
o Academic Year End Date, <AcYrEndDt>

Example:
EXAMPLE #1:
In this example, there is one LoanKey. The LoanKey = “1”can be used for
a subsidized and an unsubsidized loan. If this student submission also
included a PLUS loan, this same LoanKey = “1”could not be used for a
PLUS loan. The PLUS loan must have a unique LoanKey such as
LoanKey = “2.”

Note: This reference structure allows for more efficient transmission of

loan information. Loan information that could be reported for multiple
loans is “pulled up” to allow for a repeatable complex element.

Below is the content of DLLoanInfo and of the DLSub and DLUnsub

complex elements:

<DLLoanInfo LoanKey="1">
<OrigntnFeePct>.03</OrigntnFeePct>
<IntRebatePct>.015</IntRebatePct>
<PromNtPrtInd>S</PromNtPrtInd>
<DiscStmtPrtInd>Y</DiscStmtPrtInd>
<GradeLevelInd>1</GradeLevelInd>
<AwardBeginDt>2002-09-01</AwardBeginDt>
<AwardEndDt>2003-05-15</AwardEndDt>
<AcYrBeginDt>2002-09-01</AcYrBeginDt>
<AcYrEndDt>2003-05-15</AcYrEndDt>
</DLLoanInfo>
<DLSub>
<AwardYr>2003</AwardYr>
<CPSTransNum>4</CPSTransNum>
<AwardAmt>2625</AwardAmt>
<LoanKey>1</LoanKey>
<AwardNum>001<AwardNum>
<AwardID>123456789S03G12345001</AwardID>
<AwardCreateDt>2002-07-01</AwardCreateDt>
</DLSub>
<DLUnsub>
<AwardYr>2003</AwardYr>
<CPSTransNum>4</CPSTransNum>
<AwardAmt>1000</AwardAmt>
<LoanKey>1</LoanKey>
<AwardNum>001<AwardNum>
<AwardID>123456789U03G12345001</AwardID>
<AwardCreateDt>2002-07-01</AwardCreateDt>
</DLUnsub>

In this example, all of the LoanKey content equal one. Therefore, the
COD System knows the information in DLLoanInfo can be used for both
the DLSub and DLUnsub.
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-84
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

EXAMPLE #2:
In this example, there are two LoanKeys. The LoanKey = “1”is used for
the subsidized loan and the LoanKey = “2” is used for the unsubsidized
loan. If this student submission also included a PLUS loan, the PLUS loan
requires a unique LoanKey which could be LoanKey = “3.”

Below is the content of DLLoanInfo for a student receiving a subsidized

and an unsubsidized loan where a unique LoanKey is used for each loan.

Note: Submitting DLLoanInfo in this manner does NOT take advantage

of the short cut described in the previous Example #1 for transmission of
loan information. In this example, the same Loan information is reported
multiple times within the same submission.

Below is the content of DLLoanInfo for a student receiving a subsidized

and an unsubsidized loan where a unique LoanKey is used for each loan.

<DLLoanInfo LoanKey="1">
<OrigntnFeePct>.03</OrigntnFeePct>
<IntRebatePct>.015</IntRebatePct>
<PromNtPrtInd>S</PromNtPrtInd>
<DiscStmtPrtInd>Y</DiscStmtPrtInd>
<GradeLevelInd>1</GradeLevelInd>
<AwardBeginDt>2002-09-01</AwardBeginDt>
<AwardEndDt>2003-05-15</AwardEndDt>
<AcYrBeginDt>2002-09-01</AcYrBeginDt>
<AcYrEndDt>2003-05-15</AcYrEndDt>
</DLLoanInfo>
<DLSub>
<AwardYr>2003</AwardYr>
<CPSTransNum>4</CPSTransNum>
<AwardAmt>2625</AwardAmt>
<LoanKey>1</LoanKey>
<AwardNum>001<AwardNum>
<AwardID>123456789S03G12345001</AwardID>
<AwardCreateDt>2002-07-01</AwardCreateDt>
</DLSub>
<DLLoanInfo LoanKey="2">
<OrigntnFeePct>.03</OrigntnFeePct>
<IntRebatePct>.015</IntRebatePct>
<PromNtPrtInd>S</PromNtPrtInd>
<DiscStmtPrtInd>Y</DiscStmtPrtInd>
<GradeLevelInd>1</GradeLevelInd>
<AwardBeginDt>2002-09-01</AwardBeginDt>
<AwardEndDt>2003-05-15</AwardEndDt>
<AcYrBeginDt>2002-09-01</AcYrBeginDt>
<AcYrEndDt>2003-05-15</AcYrEndDt>
</DLLoanInfo>
<DLUnsub>
<AwardYr>2003</AwardYr>
<CPSTransNum>4</CPSTransNum>
<AwardAmt>1000</AwardAmt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-85
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

<LoanKey>2</LoanKey>
<AwardNum>001<AwardNum>
<AwardID>123456789U03G12345001</AwardID>
<AwardCreateDt>2002-07-01</AwardCreateDt>
</DLUnsub>

In this example, the DLSub and DLUnsub have unique LoanKey content.
Therefore, the DLLoanInfo cannot by “pulled up” and the DLLoanInfo
complex element is submitted twice with information for each loan.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-86
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Submitting Direct Loan Edit Only Record with

Disbursement Information
A Direct Loan Edit Only Record can be submitted to the COD System to
originate a loan and to determine the MPN Status. When disbursement
information is sent as part of the Edit Only Record, disbursement edits are
performed, the COD System can generate Disclosure Statements, when
appropriate, and estimated disbursements are reflected on the Pending
Disbursement List report.

Note: For more information, please refer to the Generating Disclosure

Statements section.

Business Rules:
! An Edit Only Record including Disbursement information with a
Payment Trigger set to “false” functions like an Origination Record
indicating estimated disbursements.
! The Response from an Edit Only Record for a subsidized or an
unsubsidized loan provides the MPN Status and MPN Indicator.
! An Edit Only Record is processed by the COD System and serves
as an early detection for any edit issues, which may cause the
record to reject at the time of disbursement. For example, the
student identifier match with the CPS is performed on an Edit Only
Record as well as edits on disbursements if submitted.
! Including disbursement information with a Payment Trigger set to
“false” as part of the Edit Only Record is recommended for the
Direct Loan Program to assist in the timely generation of
Disclosure Statements.
Note: If an Edit Only Record with disbursement information is not
submitted to the COD System, the Pending Disbursement List report
will not reflect the estimated disbursements. In this case, the school’s
system needs the ability to query or identify when a loan award needs
an actual disbursement submitted with a Payment Trigger set to “true.”

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-87
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Generating Disclosure Statements

Disclosure Statements are generated for subsidized and unsubsidized
loans.

Business Rules:
! Disclosure Statement Print Indicator is a data element on the
Common Record indicating whether the school or COD prints the
Disclosure Statement.
! The valid values for the Disclosure Statement Print Indicator are:
o Y = COD prints and sends to borrower
o R = COD reprint
o Defaults to option on school profile
Note: The Disclosure Statement Print Indicator does not have a
value for the school prints. If a school wants to print its disclosure
statements, this option must be set in the school profile and the
Disclosure Print Indicator field is not submitted in the Common
Record submission.
! If an award does not contain the Disclosure Statement Print
Indicator, the COD System defaults to the option on the school
profile when processing the award.
! Disclosure Statements printed by a school must be printed on the
approved Disclosure Statement form.
o For the approved Disclosure Statement form contact COD
School Relations.
o When printing the Disclosure Statement, it is recommended
to use Courier, 10 point, 12 pitch font.
! The party (school or COD) who is responsible for mailing the
Disclosure Statement is also responsible for printing and mailing
the Plain Language Disclosure Statement.
! Disclosure Statements must be given to the borrower before or at
the time of the first disbursement.
o If a school submits actual disbursements for a loan award to
the COD System after the first disbursement is made, the
school must provide the borrower with the Disclosure
Statement and the Plain Language Disclosure before or at
the time of the disbursement, unless a disclosure statement
was previously sent by the COD System through an edit-
only record with disbursement information.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-88
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! The COD System generates a Disclosure Statement for subsidized

and unsubsidized loans 30 calendar days before the disbursement
date whether the Payment Trigger is “false” or “true.”
! If the disbursement information is submitted to the COD System
less than 30 calendar days before the first disbursement date, the
Disclosure Statement is printed immediately.
Note: In order for the COD System to generate a Disclosure
Statement, disbursement information must be submitted and
accepted by the COD System. If you wait and submit
disbursement information seven (7) calendar days prior to the
disbursement date, the Disclosure Statement prints seven (7)
calendar days prior to the disbursement date.

Example: When a Disclosure Prints at COD

Disb. Info Date Disb. Payment Disb. Date Disclosure

Submitted Info Trigger Statement
Submitted Generated by
COD

More than 30 08-01-02 False 09-10-02 08-12-02

calendar days
prior

30 calendar 08-12-02 False 09-10-02 08-12-02

days prior

7 calendar days 09-03-02 true or 09-10-02 09-03-02

prior False

On Disb. Date 09-10-02 true or 09-10-02 09-10-02

False

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-89
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Performing Annual Loan Limit Edits

The COD System performs annual Loan Limit edits using Academic Year,
Student Grade Level and, when appropriate, the Additional Unsubsidized
Loan for Health Profession Programs flag.

Business Rules:
! To perform annual loan limit edits, the COD System selects
subsidized and unsubsidized loans with the following criteria to
pool with the incoming loan:
o Same borrower as the incoming disbursement AND
o Same grade level as the incoming disbursement AND
o Same academic year start and end date as the incoming
disbursement OR
o Academic year that contains the academic year of the
incoming disbursement OR
o Academic year that is contained wholly within the
academic year of the incoming disbursement
! The COD System does not perform loan limit edits on
disbursements with overlapping academic years.
! For disbursements with overlapping academic years, the COD
System transmits a warning to the school as part of the Response
Document. This warning indicates that another disbursement with
an overlapping academic year exists and that the school is
responsible for ensuring the student has not exceeded his / her
annual loan limits.
! The COD System performs loan limit edits on subsidized and
unsubsidized loans to ensure that a student does not exceed annual
maximum loan limits based on Student Grade Level and, if
appropriate, Eligibility for Additional Unsubsidized Loan for
Health Profession Programs.
! The Additional Unsubsidized Eligibility for Health Profession
Programs tag <AddtHPPA> is submitted to the COD System to be
used when performing loan limit edits.
! The Dependency Status and Additional Unsubsidized Eligibility
for a Dependent Student are factors not used when performing the
loan limit edits at COD.
Note: These factors must still be considered by a school when
determining a student’s loan limit.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-90
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Submitting Direct Loan Disbursement Information

and Payment Trigger
The COD System can accept Direct Loan Disbursement information in
advance, on or after the Disbursement Date.

Business Rules:
! The COD System accepts disbursement information in advance, on
or after the disbursement date.
! Disbursement Date is the date the money was credited to the
student’s account or paid to the student (or borrower, if PLUS
loan) directly for a specific disbursement number. Disbursement
Date is NOT the date of the adjustment transaction. The
Disbursement Date is submitted on a Disbursement transaction as
well as on an Adjusted Disbursement Amount transaction.
Note: In prior years, for an Adjusted Disbursement Amount, the
transaction date of the adjustment was submitted for processing.
For 2002-2003 adjusted disbursement amounts, Full Participants
must submit the Disbursement Date, NOT the transaction date.
! Disbursement information is submitted to the COD System with a
Payment Trigger equal to “true” or “false.”
o A Payment Trigger = “false” (submit disbursement
information for edit only). False indicates estimated
disbursement information and functions like an origination
record.
o A Payment Trigger = “true.” True indicates actual
disbursement information.
o If the Payment Trigger is omitted from the Common
Record, the COD System sets it to “false.”
! A Payment Trigger = “false” can be updated to “true” on a Direct
Loan disbursement.
! A Payment Trigger = “true” cannot be updated to “false” on a
Direct Loan disbursement.
Note: In this case, a school needs to adjust the disbursement to $0.
Details on adjusting disbursements to $0 are provided in the
Updating and Adjusting Direct Loan Disbursement Amounts and
Dates section.
! Payment Trigger can be updated and disbursements can be
generated, updated and adjusted on the COD website.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-91
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! The required data elements for an edit only DL disbursement are:

o Disbursement Number, <Disbursement Number= " ">
o Disbursement Amount (gross), <DisbAmt> (gross amount)
o Disbursement Date, <DisbDt>
o Payment Trigger set to “false,” <PmtTriggerFlg = “false”>
o Disbursement Sequence Number, <DisbSeqNum>
o Disbursement Net Amount, <DisbNetAmt>
o Disbursement Fee Amount, <DisbFeeAmt>
o Interest Rebate Amount, <IntRebateAmt>
! The required data elements for an actual disbursement are:
o Disbursement Number, <Disbursement Number= " ">
o Disbursement Amount (gross), <DisbAmt> (gross amount)
o Disbursement Date, <DisbDt>
o Payment Trigger set to “true,” <PmtTriggerFlg = “true”>
o Disbursement Sequence Number, <DisbSeqNum>
o Disbursement Net Amount, <DisbNetAmt>
o Disbursement Fee Amount, <DisbFeeAmt>
o Interest Rebate Amount, <IntRebateAmt>
Note: The COD System does not accept Direct Loan PLUS
disbursements with a Payment Trigger = “true” without an
approved credit decision on file.
! The calculation to determine whether or not to increase the CFL is
driven by:
o Disbursement Date,
o Payment Trigger set to “true,” and
o Acceptance of an actual disbursement.
Note: No longer does just the Disbursement Date and an accepted
promissory note (if COD prints and collects the note), drive the
calculation to determine whether or not to increase the CFL.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-92
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! Schools participating in Advance Pay can submit a Payment

Trigger = “true” up to seven (7) calendar days prior to the
disbursement date.
o When the current date is seven (7) calendar days or less
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System accepts the actual
disbursement whether or not the MPN or PLUS promissory
note is accepted. The COD System will not accept a PLUS
actual disbursement without an approved credit decision on
file.
! The CFL calculation is performed and uses the
actual disbursement to determine if the CFL needs
to be increased once the promissory note is on file.
! When the actual disbursement is accepted prior to
the disbursement date and the promissory note is on
file, the actual disbursement is booked on the
disbursement date and passed to Servicing.
o When the current date exceeds seven (7) calendar days
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System rejects the disbursement with
error code 051.
• Schools participating in Pushed Cash, can submit a Payment
Trigger = “true” up to seven (7) calendar days prior to the
disbursement date.
o When the current date is seven (7) calendar days or less
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System accepts the actual
disbursement if the MPN or PLUS promissory note is
accepted. If the MPN or PLUS promissory note is rejected,
the actual disbursement is rejected. In addition, the COD
System does not accept a PLUS actual disbursement
without an approved credit decision on file.
! The CFL calculation is performed and uses the
actual disbursement to determine if the CFL needs
to be increased.
! When the actual disbursement is accepted prior to
the disbursement date, the actual disbursement is
booked on the disbursement date and passed to
Servicing.
o When the current date exceeds seven (7) calendar days
prior to the Disbursement Date and the Payment Trigger is

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-93
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

set to “true,” the COD System rejects the disbursement with

error code 051.
Note: For schools participating in Pushed Cash, the
Pending Disbursement List report can assist in identifying
estimated disbursements and their disbursement date.
! Schools placed in Cash Monitoring 1 (CM1) by Case
Management can submit a Payment Trigger = “true” up to seven
(7) calendar days prior to the disbursement date.
o When the current date is seven (7) calendar days or less
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System accepts the actual
disbursement if the MPN or PLUS promissory note is
accepted. If the MPN or PLUS promissory note is rejected
the actual disbursement is rejected. In addition, the COD
System does not accept a PLUS actual disbursement
without an approved credit decision on file.
! The CFL calculation is performed and uses the
actual disbursement to determine if the CFL needs
to be increased.
! The CFL will equal the net accepted actual
disbursements. CM1 schools will not have any
money available to them until actual disbursements
are accepted by the COD System.
! When the actual disbursement is accepted prior to
the disbursement date, the actual disbursement is
booked on the disbursement date and passed to
Servicing.
o When the current date exceeds seven (7) calendar days
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System rejects the disbursement with
error code 051.
Note: For schools participating in CM1, the Pending
Disbursement List report can assist in identifying estimated
disbursements and their disbursement date.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-94
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! Schools placed in Reimbursement or Cash Monitoring 2 (CM2)

by Case Management can submit a Payment Trigger = “true” if the
current date is equal to or after the Disbursement Date.
o If the current date is equal to or after the Disbursement Date
and the Payment Trigger is set to “true” the disbursement is
reviewed and may be approved by FSA.
o When the current date is seven (7) calendar days or less
prior to the Disbursement Date and the Payment Trigger is
set to “true,” the COD System accepts the actual
disbursement if the MPN or PLUS promissory note is
accepted. If the MPN or PLUS promissory note is rejected
the actual disbursement is rejected. In addition, the COD
System does not accept a PLUS actual disbursement
without an approved credit decision on file.
o CFL is increased based on approvals by Case Management.
o Reimbursement Analyst initiates the drawdown through
GAPS.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-95
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example for Schools Participating in Advance Pay:

Date Disb Info Payment Disb Date Accepted RESULTS:

Submitted Trigger MPN/PLUS CFL Calculation is
Promissory Performed
Note
08-29-2002 true 09-06-2002 Yes or No NO
08-30-2002 true 09-06-2002 Yes or No YES
09-01-2002 true 09-06-2002 Yes or No YES
09-08-2002 true 09-06-2002 Yes or No YES

Example for Schools Participating in Pushed Cash or CM1:

Date Disb Info Payment Disb Date Accepted RESULTS:

Submitted Trigger MPN/PLUS CFL Calculation is
Promissory Performed
Note
08-29-2002 true 09-06-2002 Yes or No NO

08-30-2002 true 09-06-2002 No NO

08-30-2002 true 09-06-2002 Yes YES
09-08-2002 true 09-06-2002 No NO
09-08-2002 true 09-06-2002 Yes YES

Example for Schools Participating in Reimbursement or CM2:

Date Disb Info Payment Disb Date Accepted RESULTS:

Submitted Trigger MPN/PLUS Review by FSA
Promissory
Note
08-29-2002 true 09-06-2002 Yes or No NO
08-30-2002 true 09-06-2002 Yes or No NO
09-06-2002 true 09-06-2002 Yes YES
09-06-2002 true 09-06-2002 No NO
09-08-2002 true 09-06-2002 Yes YES
09-08-2002 true 09-06-2002 No NO

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-96
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Reporting Pennies in the Award and Disbursement

Amount Data Elements
The Award and Disbursement Amounts on the Common Record may
include pennies. In the Direct Loan Program, pennies CANNOT be
disbursed. Award and Disbursement Amounts must be reported as whole
dollar amounts or a decimal point with two zeros.

Business Rules:
! The data elements for Award and Disbursement Amounts on the
Common Record may include two digits to the right of a decimal
point.
! When the reported amount does not include a decimal point, the
COD System infers a decimal point and two zeros to the right of
the last digit reported. For example, if a school reports 1000, the
COD System stores as 1000.00.
! The Direct Loan Program does NOT calculate award or
disbursements amounts using pennies. (The method for calculating
disbursements has not changed and is included in the next section.)
! For the Direct Loan Program, schools must report dollar amounts
with a decimal and two zeros to the right of the decimal (3500.00)
OR
Report the whole dollar amount only (3500) and the COD System
infers the decimal point and two zeros and stores as (3500.00).
! The award and disbursement amount data elements are:
o Award Amount, <AwardAmt>
o Award Amount Requested, <AwardAmtRqd>
o Disbursement Amount (gross), <DisbAmt>
o Disbursement Fee Amount, <DisbFeeAmt>
o Interest Rebate Amount, <IntRebateAmt>
o Disbursement Net Amount, <DisbNetAmt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-97
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:
When reporting a Direct Loan Award Amount of $2625:
1) Include the decimal point and two zeros to the right: 2625.00
OR
2) Omit the decimal point and report the whole dollar amount only: 2625
Then, the COD System infers a decimal and stores 2625.00

DO NOT submit 262500 as the COD System infers a decimal and stores
this submission as 262500.00.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-98
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Calculating Direct Loan Disbursements

The current disbursement calculations and rounding logic used to process
Direct Loans in 2001- 2002 continues to be used for 2002-2003.

The next two sections discuss these calculations and provide examples.
This first section discusses Disbursement Amount (Gross) Calculations.
The next section discusses Disbursement Net Amount, Disbursement Fee
Amount, and Interest Rebate Amount Calculations.

Business Rules:
! The current method to calculate individual Disbursement Amounts
(Gross) and the current rounding logic remain as is. The variance
is still applied to the last disbursement. See Disbursement
Amount (Gross) Calculations below for steps and examples.
! Schools submit to the COD System the Disbursement Amount
(gross), Disbursement Fee Amount, Interest Rebate Amount and
Disbursement Net Amount for disbursements.
! The method to calculate the Disbursement Net Amount and
Disbursement Fee Amount and Interest Rebate Amount is a six
step process. See the next section Disbursement Net Amount,
Disbursement Fee Amount, and Interest Rebate Amount
Calculations for the calculations and examples.

Disbursement Amount (Gross) Calculations:

When determining disbursement amounts (gross) for a loan, dollar figures
are rounded to the nearest dollar and all disbursements are equal with the
exception of the last disbursement, in some cases. This is due to any
variance being applied to the last disbursement.

When computing gross disbursement amounts, use the following

specifications:
Step 1: Individual disbursement amount is Award Amount divided
by the total number of disbursements.
If necessary, truncate any positions that exist past 2 decimal
places.
Step 2: Round the individual disbursement amount. Rounding
occurs at the 1st and 2nd decimal places to the nearest
dollar.
• If the 1st and 2nd decimal places are 50 or greater,
increase the 1st digit to the left of the decimal sign by
one.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-99
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

• If the 1st and 2nd decimal places are less than 50, do
not change the 1st digit to the left of the decimal sign.
Step 3: To determine the amount of the last disbursement, multiply
the individual disbursement amount by the number of
disbursements.
• If the sum of the disbursements is greater than the Loan
Amount Approved, subtract the difference from the last
disbursement.
• If the sum of the disbursements is less than the Loan Amount
Approved, add the difference to the last disbursement.
The variance is applied to the last disbursement.

Example 1: Determining Gross Disbursement Amount for Two

Disbursements
Award Amount: $2625
Step 1: 2625 divided by 2 = 1312.5000
First truncate any positions that exist past 2 decimals as
rounding occurs at the 1st and 2nd decimal places.
Therefore, 1312.5000 truncates to 1312.50
Step 2: Round at the 1st and 2nd decimal places to determine the
individual disbursement amount.
• If the 1st and 2nd decimal places are .50 or greater,
increase the 1st digit to the left of the decimal sign by 1.
• If the 1st and 2nd decimal places are less than .50, do
not change the 1st digit to the left of the decimal sign.
Round 1312.50 to 1313. Therefore, all disbursement
amounts are 1313 except the last disbursement.
Step 3: To determine the last disbursement amount, multiply the
individual disbursement amount by the number of
disbursements.
Multiply 1313 by 2 = 2626
Since $2626 is more than $2625, subtract the difference of
$1. The last disbursement is equal to $1313–$1 or $1312.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-100
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Final Results:
1st Disbursement Amount (gross) = 1313
2nd Gross Disbursement Amount (gross) = 1312
Total Award Amount = $2625

Example 2: Determining Gross Disbursement Amount for

Three Disbursements
Award Amount: $1000
Step 1: 1000 divided by 3 = 333.3333
First truncate any positions that exist past 2 decimals as rounding
occurs at the 1st and 2nd decimal places.
Therefore, 333.3333 truncates to 333.33
Step 2: Round at the 1st and 2nd decimal places to determine the
individual disbursement amount.
• If the 1st and 2nd decimal places are .50 or greater,
increase the 1st digit to the left of the decimal sign by
one.
• If the 1st and 2nd decimal places are less than .50, do
not change the 1st digit to the left of the decimal sign.
Round 333.33 to 333. Therefore, all disbursement amounts
are 333 except the last disbursement.
Step 3: To determine the last disbursement amount, multiply the
individual disbursement amount by the number of
disbursements.
Multiply 333 by 3 = 999
Since $999 is less than $1000 you add the difference of $1.
The last disbursement is equal to $333 + $1 or $334.
Final Results:
1st Disbursement Amount (gross) = $333
2nd Disbursement Amount (gross) = $333
3rd Disbursement Amount (gross) = $334
Total Award Amount = $1000

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-101
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example 3: Determining Gross Disbursement Amount for Six

Disbursements
Award Amount: $22,167
Step 1: 22167 divided by 6 = 3694.5000
First truncate any positions that exist past 2 decimals as
rounding occurs at the 1st and 2nd decimal places.
Therefore, 3694.5000 truncates to 3694.50
Step 2: Round at the 1st and 2nd decimal places to determine the
individual disbursement amount.
• If the 1st and 2nd decimal places are .50 or greater,
increase the 1st digit to the left of the decimal sign by 1.
• If the 1st and 2nd decimal places are less than .50, do
not change the 1st digit to the left of the decimal sign.
Round 3694.50 to 3695. Therefore, all disbursement
amounts are 3695 except the last disbursement.
Step 3: To determine the last disbursement amount, multiply the
individual disbursement amount by the number of
disbursements.
Multiply 3695 by 6 = 22170
Since $22170 is more than $22167, subtract the difference
of $3. The last disbursement is equal to $3695–$3 or
$3692.
Final Results:
1st Disbursement Amount (gross) = $3695
2nd Disbursement Amount (gross) = $3695
3rd Disbursement Amount (gross) = $3695
4th Disbursement Amount (gross) = $3695
5th Disbursement Amount (gross) = $3695
6th Disbursement Amount (gross) = $3692
Total Award Amount = $22,167

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-102
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Disbursement Net Amount, Disbursement Fee

Amount, and Interest Rebate Amount Calculations
A 6-step calculation is used to derive the Disbursement Net Amount,
Disbursement Fee Amount and Interest Rebate Amount. This process
allows a school to start the calculation with either the gross disbursement
amount or the net disbursement amount and arrive with the same results.

Business Rules:
! An up-front interest rebate amount is calculated at the
disbursement level by the schools for each subsidized,
unsubsidized, and PLUS loan.
! The combined fee/interest is a field used to assist in the calculation
of the net disbursement amount. This field is for the calculation
only and is NOT a field sent to the COD System.
! When calculating the Combined Fee/Interest Rebate Amount and
the Loan Fee Amount, take all results out three (3) decimal places
to ensure consistent results and then truncate.
! When determining the Combined Fee/Interest Rebate Amount,
Disbursement Fee Amount, and the Interest Rebate Amount
truncate the result.
! Truncate means the cents are removed and the remaining whole
dollar is the amount to use. Do not round up or down.

! When calculating individual disbursement fee amount, interest rebate

amount, and disbursement net amount, use the following
specifications for all disbursements:

To calculate Net Disbursement Amount:

Step 1: Combined Fee/Interest Rebate Amount (go out to 3
decimal places) = Disbursement Amount (Gross) x
(Origination Fee Percentage – Interest Rebate Percentage)
Step 2: Truncate the Combined Fee/Interest Rebate Amount
Step 3: Disbursement Net Amount = Disbursement Amount
(gross) – Combined Fee/Interest Rebate Amount
To calculate Loan Fee Amount:
Step 4: Disbursement Fee Amount (go out to 3 decimal places) =
Disbursement Amount (gross) x Origination Fee
Percentage
Step 5: Truncate the Disbursement Fee Amount

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-103
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

To calculate Interest Rebate Amount:

Step 6: Interest Rebate Amount = Disbursement Net Amount –
(Disbursement Amount (gross) – Disbursement Fee
Amount)
To calculate from Disbursement Net Amount to Disbursement
Amount (gross) use the following calculation:
Disbursement Net Amount multiplied by 100 divided by 100
minus (Fee% - Rebate%)
OR
Disbursement Net Amount divided by .985 = Disbursement
Amount (gross) (truncated)
Then proceed with Step 4.

Example 1: Determining Combined Fee/Interest Rebate

Amount, Disbursement Net Amount, Disbursement Fee
Amount, and Interest Rebate Amount for three Disbursements

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6

Disb. Gross Combined Truncated Disb. Net Disb. Fee Truncated Interest Rebate
Number Disb. Fee/Interest Rebate Combined Amount Amount Disb. Fee Amount
Amount Amount Fee/Interest Amount
Rebate
Amount

1 $1167 1167x(.03-.015)=17.505 17 1167-17=1150 1167x.03=35.01 35 1150-(1167-35)=18

2 $1167 1167x(.03-.015)=17.505 17 1167-17=1150 1167x.03=35.01 35 1150-(1167-35)=18

3 $1166 1166x(.03-.015)=17.49 17 1166-17=1149 1166x.03=34.98 34 1149-(1166-34)=17

Totals $3500 $3449 104 53

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-104
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example 2: Determining Combined Fee/Interest Rebate

Amount, Disbursement Net Amount, Loan Fee Amount, and
Interest Rebate Amount for twelve disbursements

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6

Disb. Gross Combined Truncated Disb. Net Disb. Fee Truncated Interest Rebate
Number Disb. Fee/Interest Rebate Combined Amount Amount Disb. Fee Amount
Amount Amount Fee/Interest Amount
Rebate
Amount

1 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

2 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

3 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

4 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

5 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

6 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

7 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

8 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

9 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

10 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

11 $219 219x(.03-.015)=3.285 3 219-3=216 219x.03=6.57 6 216-(219-6)=3

12 $216 216x(.03-.015)=3.240 3 216-3=213 216x.03=6.48 6 213-(216-6)=3

Totals $2625 $2589 72 36

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-105
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Updating and Adjusting Direct Loan Disbursement

Amounts and Dates
Disbursement Amounts and Dates can be updated while the Payment
Trigger is set to “false.” Once the Payment Trigger = “true,” the
Disbursement Amount and Dates can be adjusted.

Business Rules:

Updating:
! Disbursement Amount and Disbursement Date can be updated
prior to a Payment Trigger = “true.”
! To update a Disbursement Amount and/or Disbursement Date, the
following data elements are required:
o Payment Trigger = “false”, <PmtTriggerFlg = “false”>
o Disbursement Number, <Disbursement Number “”>
o Disbursement Sequence Number of “01”, <DisbSeqNum>
o Disbursement Amount (gross), <DisbAmt>
o Disbursement Date, <DisbDt>
Note: When updating a disbursement, the disbursement amount
and date cannot be updated in the same submission.

Adjusting:
! Once a disbursement transaction with a Disbursement Sequence
Number of “01” is accepted with a Payment Trigger = “true,” the
Disbursement Amount and Disbursement Date can be adjusted.
! Disbursement Amount and Disbursement Date cannot be adjusted
in the same submission.
! A disbursement transaction to adjust a Disbursement Amount or
Date must have a unique Disbursement Sequence Number.
! Disbursement Sequence Numbers for a specific Disbursement
Number must be used in sequential order within the range of 01-
65.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-106
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! Disbursement Date is always the date the cash was credited to the
student’s account or paid to the student (or borrower, if PLUS
loan) directly for a specific disbursement number.
! Disbursement Date is submitted on an Adjusted Disbursement
Amount transaction.
Note: In prior years, for an Adjusted Disbursement Amount, the
transaction date of the adjustment was submitted for processing.
For 2002-2003 adjusted disbursement amounts, Full Participants
must submit the Disbursement Date, NOT the transaction date.
See Example below.
! Direct Loan disbursement amounts can be adjusted to $0.
! To adjust a Disbursement Amount, the following data elements
are required:
o Payment Trigger = “true”, <PmtTriggerFlg = “true”>
o Disbursement Number, <Disbursement Number “”>
o New Disbursement Sequence Number, <DisbSeqNum>
o New Disbursement Amount (gross), <DisbAmt>
o Disbursement Date, <DisbDate>
o New Disbursement Net Amount, <DisbNetAmt>
o New Disbursement Fee Amount, <DisbFeeAmt>
o New Interest Rebate Amount, <IntRebateAmt>
Note: When adjusting a disbursement amount, the disbursement
date CANNOT also be updated in the same submission. If you
submit the disbursement date, it must be the disbursement date
already on file on the COD database for this disbursement number.
! To adjust a Disbursement Date, the following data elements are
required:
o Payment Trigger = “true”
o Disbursement Number, <Disbursement Number “”>
o New Disbursement Sequence Number, <DisbSeqNum>
o New Disbursement Date, <DisbDt>
Note: When adjusting a disbursement date, the disbursement
amounts CANNOT also be updated in the same submission. If you
submit the disbursement amounts, the amounts must be the
disbursement amounts already on file on the COD database for this
disbursement number.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-107
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:
When submitting an adjusted disbursement amount for an actual
disbursement on the Common Record, the Disbursement Date (i.e.
the date the school disburses the funds to the student) is reported.
The transaction date (i.e. the date the school processes the adjusted
disbursement amount) is not submitted as it was in prior years.
A School disburses the first disbursement of a loan to a student for
$2000 on 9/10/2002. The school discovers that the disbursement
amount needs to be corrected to $1000. On 9/15/2002, the school
adjusts the disbursement amount to $1000. The actual
disbursement transaction and adjusted disbursement transaction
must be submitted on the Common Record as follows:

Payment Disb # Disb Disbursement Disb Fee Interest Net

Trigger Sequence Date Amt Amt Rebate Disb
# (gross) Amt Amt
Actual True 01 01 09-10-2002 2000 60 30 1970
Disbursement
Adjusted True 01 02 09-10-2002** 1000 30 15 985
Disbursement

** DO NOT submit the transaction date of 09-15-2002 on the

Adjusted Disbursement.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-108
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Inactivating a Direct Loan

To inactivate a Direct Loan, reduce the disbursements to $0 and update the
Award Amount to $0.

Business Rules:
! The Award Amount and all Disbursements must be reduced to $0
to inactivate a loan.
! All activity can be generated and submitted in the same Common
Record.
! A funded loan can be inactivated if a borrower returns the
disbursed funds to the school within 120 calendar days of
disbursement. All principal and fees are eliminated for a loan in
this status.
! A funded loan cannot be inactivated if a borrower returns the
disbursed funds to Servicing after 120 calendar days.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-109
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Generating Direct Loan Booking Notification

Responses
The COD System generates a Booking Notification Response when the
loan books with a first disbursement. Subsequent Booking Notifications
are NOT sent for each subsequent funded disbursement.

Business Rules:
! When the Document Status is equal to “Accepted” and the
Payment Trigger is “false,” the Common Record Response
indicates an accepted Award or in the case of Direct Loan accepted
loan.
! When the Document Status is equal to “Accepted” and the
Payment Trigger is “true,” the Common Record Response indicates
an accepted Disbursement.
! Two tags on the Common Record assists a school in determining if
a MPN/PLUS Promissory Note is accepted.
o The MPN Status tag <MPNStat> indicating a status of “A”
(Accepted) OR
o The MPN Link Flag <MPNLinkFlg> indicating a status of
“true,” record has been linked to a MPN.
! When the Credit Decision Status tag <CrDecisionStat> indicates a
status of “A,” it is indicating an accepted credit decision for the
PLUS Loan.
! A loan books when the award is accepted, the MPN/PLUS
Promissory Note is accepted and the first Disbursement is funded.
In the case of a PLUS loan, the loan must have an accepted Credit
Decision Status.
! When a loan books, the COD System generates a Booking
Notification Response to the school.
! A COD system-generated Booking Notification Response contains
a Document Type of “BN.” The Document Type indicates the type
of Response.
! A Response Document of Document Type “BN” contains a
system-generated Document ID.
! A Booking Notification Response contains the following data
elements in the Response Complex Element <Response>:
o Booked Loan Amount, <BkdLoanAmt>
o Booked Loan Amount Date, <BkdLoanAmtDt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-110
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o Document Type, <DocumentType>

o Processing Date, <ProcessDt>
! The Booking Notification allows a school to update their system
with the Booked Status of a loan to assist with the Direct Loan
reconciliation process.

Example:
Below is a sample Booking Notification Response:

<CommonRecord>
<DocumentId>2002-07-0T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-07-10T09:09:09.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="12345678"/>
</Destination>
<FullRsFlag>F</FullRsFlag>
<ReportingSchl EntityId="12345678">
<AttendingSchl EntityId="12345678">
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">
<SchlUseOnly>999999999</SchlUseOnly>
<DLSub>
<AwardYr>2003</AwardYr>
<SchlUseOnly>999999999</SchlUseOnly>
<AwardNum>001</AwardNum>
<AwardID>123456789S03G12345001</AwardID>
<Response>
<RsInd>A</RsInd>
<BkdLoanAmt>985</BkdLoanAmt>
<BkdLoanAmtDt>2002-07-10</BkdLoanAmtDt>
</Response>
<Disbursement Number="01">
<SchlUseOnly>999999999</SchlUseOnly>
<Response>
<RsInd>A</RsInd>
</Response>
</Disbursement>
</DLSub>
<Response>
<RsInd>A</RsInd>
</Response>
</Student>
</AttendingSchl>
</ReportingSchl>
<Response>
<DocumentType>BN</DocumentType>
<DocumentStat>A</DocumentStat>
<ProcessDt>2002-07-10</ProcessDt>
</Response>
</CommonRecord>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-111
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Generating Payment to Servicing Responses

When a student or borrower makes a payment to DL Servicing within 120
calendar days of the disbursement date, the COD System generates a
Payment to Servicing Response to be sent to a school. This transaction is
used when performing loan limits for this borrower.

Business Rules:
! A Payment to Servicing is generated by the COD System and sent
to a school when a borrower makes a payment to DL Servicing
within 120 calendar days of the disbursement date.
! A Payment to Servicing transaction should NOT update the
disbursed amount for the loan. This transaction is for
informational purposes only and should be considered when
reviewing this borrower’s loan limit for any future loans.
! In order to process a Payment to Servicing Response accurately,
the following data elements are returned in addition to the
Response complex element:
! Award Year, <AwardYr>
! Award ID, <AwardId>
! Disbursement Number, <Disbursement Number = “”>
! Disbursement Sequence Number, <DisbSeqNum>
! Disbursement Sequence Numbers on a Payment to Servicing
Response are sequential in descending order starting with 99 to 91.
! The Payment to Servicing Amount is reported as a dollar value
with a negative sign.
! If a previous Payment to Servicing Amount or partial
amount needs to be reversed a positive dollar value is sent
with the next descending sequential disbursement sequence
number.
! A COD system-generated Payment to Servicing Response contains
a Document Type of “PS.” The Document Type indicates the type
of Response.
! A Response Document of Document Type “PS” contains a system-
generated Document ID.
! A Payment to Servicing Response contains the following data
elements in the Response complex element <Response>:
o Payment to Servicer Amount, <PmttoSvcrAmt>
o Payment to Servicer Date, <PmttoSvcrDt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-112
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o Document Type, <DocumentType>

o Processing Date, <ProcessDt>
Note: For all data elements refer to the sample on the next page.

Example:
A school receives a Payment to Servicing transaction for $500 on a fully
disbursed $2625 loan for a first year student. The school’s system should
continue to store the borrower’s loan as $2625.

However, if the first year student decides to later request an additional loan
for $500 for the same academic year, the $500 Payment to Servicing is
used by the school when calculating the student’s annual loan limit of
$2625 and the student IS ELIGIBLE to borrow an additional $500 loan.

Thus, the school’s system should display two loans for this first-year
student:

Student Academic Year Disbursed Payment to

Grade Loan Amount Servicing
Level
1 09/02/2002 to 06/20/2003 $2625 $500

1 09/02/2002 to 06/20/2003 $500

Annual Loan Limit for 1st Year = $2625

Total Disbursed for Academic Year = $3125
Payment to Servicing = $500

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-113
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Below is a sample Payment to Servicing Response:

<CommonRecord>
<DocumentId>2002-07-10T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-07-10T09:09:09.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="12345678"/>
</Destination>
<FullRsFlg>F</FullRsFlg>
<ReportingSchl EntityId="12345678">
<AttendingSchl EntityId="12345678">
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">
<SchlUseOnly>999999999</SchlUseOnly>
<DLSub>
<AwardYr>2003</AwardYr>
<SchlUseOnly>999999999</SchlUseOnly>
<AwardNum>001</AwardNum>
<AwardID>123456789S03G12345001</AwardID>
<Response>
<RsInd>A</RsInd>
<PmttoSvcrAmt>-1000.00</PmttoSvcrAmt>
<PmttoSvcrDt>2002-07-10</PmttoSvcrDt>
</Response>
<Disbursement Number="01">
<SchlUseOnly>999999999</SchlUseOnly>
<DisbSeqNum>99</DisbSeqNum>
<Response>
<RsInd>A</RsInd>
</Response>
</Disbursement>
</DLSub>
<Response>
<RsInd>A</RsInd>
</Response>
</Student>
</AttendingSchl>
</ReportingSchl>
<Response>
<DocumentType>PS</DocumentType>
<DocumentStat>A</DocumentStat>
<ProcessDt>2002-07-10</ProcessDt>
</Response>
</CommonRecord>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-114
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan Promissory Note Processing

Promissory Note Processing

The Promissory Note process is either the responsibility of the school or
the COD System.

Business Rules:
! Obtaining a signed Promissory Note is either the responsibility of
the school or the COD System.
o For a subsidized or unsubsidized loan, the student can
complete an e-MPN or a paper MPN.
o For a PLUS loan, the borrower must complete a paper
PLUS Promissory Note.
! A student can decide to complete an electronic MPN.
o A student completes this process on the LO On-Line
Application.
o When a student completes the e-MPN process, a
Promissory Note Response is sent to the appropriate school.
! When a school is responsible for the Promissory Note process, the
school or the COD System can print MPN/PLUS Promissory
Notes.
o The school must send all completed promissory notes to the
following address: P.O. Box 5692, Montgomery, AL
36103-5692.
! Upon receipt of paper notes, the notes are screened for
completeness.
o Incomplete notes are returned to the school for correction.
o Accepted notes generate a Promissory Note Response to be
sent to the school.
! When COD is responsible for the Promissory Note process, the
MPN/PLUS Promissory Notes are printed by the COD System and
mailed to the borrower.
o The borrower returns all completed notes to COD.
o The COD System generates and sends a Response to the
school promissory note. For more details on this response
process, see the section, “Generating a MPN/PLUS
Promissory Note Response.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-115
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Submitting a Promissory Note Print Indicator

The Promissory Note Print Indicator identifies at the individual loan level
who is responsible for the printing of the promissory note for a specific
loan and can override the school’s promissory note print option. This
indicator can also be used to request the COD System to reprint a
promissory note.

Business Rules:
! One of the school options in the COD System indicates who is
responsible, the school or the COD System, for printing promissory
notes for loans originated by that school.
! The Promissory Note Print Indicator allows a school to decide at
the individual student loan level who is responsible to print the
note for a specific loan and overrides the selected school option.
! The Promissory Note Print Indicator can also be used to request the
COD System to reprint a promissory note.
! The Promissory Note Print Indicator is an optional data element
that can be submitted for an individual loan award.
o S = COD Prints and sends to Borrower
o R = COD Prints and sends to School
o Z = COD Reprint
! If an award does not contain the Promissory Note Print Indicator,
the COD System defaults to the option on the school profile when
processing the award.
! Schools printing Promissory Notes can either
o Print using the appropriate approved form or
o Print all text including data and data labels using the same
format and wording as the form provided by the
Department of Education.
Note: Schools printing all text must have the format approved by
FSA. For more information on the approval process contact COD
School Relations.
! To obtain approved Master Promissory Note and PLUS Promissory
Note forms contact Customer Service.
! MPN and PLUS Promissory Note print specifications are provided
at the end of this Implementation Guide.
! When printing Promissory Notes, it is recommended to use
Courier, 10 point, 12 pitch font.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-116
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! When mailing the MPN, a number 10 business window envelope is

recommended.
! MPN and PLUS Promissory Note print specifications are provided
in Appendix L – Print Specifications.

Example:
A school has selected the option with COD to print all its own promissory
notes. The printer used by the school malfunctions and cannot be repaired
for four weeks.

During this four week period, the school submits all loan records with a
print indicator of ‘R’ = COD Prints and sends to School.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-117
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Master Promissory Note

The Master Promissory Note (MPN) is the approved promissory note for
Direct Subsidized and Unsubsidized Loans for all schools. No changes are
being made to the MPN data elements for 2002-2003.

Business Rules:
! The MPN is a legal document requiring a student to repay the
funds borrowed under the Direct Loan Program.
! No dollar amount is printed on the MPN by the school or COD and
only one MPN is used for both subsidized and unsubsidized loans.
! The MPN ID prints on the MPN and is the 21-character loan ID of
one of the loans associated with the MPN with a loan type of “M”
for MPN for 01 and forward. For example:
999999998M03Gxxxxx001
! The components for the MPN ID are:
o Student’s Social Security Number: 001010001–999999998
o MPN Indicator: M for 01 and forward or S or U for 00
o Program Year: 00 and forward
o Direct Loan School Code: X00000–X99999 where X = G
or E
o Loan Sequence Number: 001–999
Note: The school code imbedded in the Loan ID continues to be
the DL school code (G or E code) and does NOT use the Common
School Identifier.
! The MPN ID is used by the COD System to identify which loans
are linked to a MPN.
! A MPN must be printed by the school or COD and signed by the
student borrower before disbursing a Direct Subsidized Loan or
Direct Unsubsidized Loan.
! An open MPN is valid for up to ten years from the later of the date
received or the first actual disbursement for any associated full
loan origination record.
! To close a MPN a student must provide a request in writing to the
Direct Loan Servicing Center or the school.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-118
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! When a school receives a closed notification, the school must

forward all original documentation to COD.
! Once a MPN is closed, no new loans can be linked to it. A new
MPN must be generated if new loans are originated. However, all
disbursements and booking activities for the loans already linked to
the closed MPN continue to be processed by the COD System.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-119
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Master Promissory Note Features

Schools can process MPNs using the Single-Year or Multi-Year Feature.

Multi-Year MPN Feature

Multi-year feature of the MPN applies to all four-year and
graduate/professional schools that are not subject to an emergency action
or limitation, suspension, or termination (LS &T) action per Direct Loan
regulations. Any school with questions regarding eligibility may contact
Direct Loan Operations. For more information regarding eligibility for the
Multi-Year MPN feature see Dear Partner (Colleague) Letter GEN-00-3.

Business Rules:
! When processing 2002-2003 loan records, COD is aware of open
MPNs processed by the LOC for program years prior to 2002-
2003.
! If a borrower is attending a school using the multi-year feature, the
borrower may have only one open MPN on file at COD, for all
subsidized and unsubsidized loans originated for program year
1999-2000 and forward.
! Schools using the multi-year feature must have a confirmation
process in place. For more details regarding confirmation process,
refer to the Direct Loan School Guide, Chapter 6 at
http://www.ed.gov/DirectLoan/pubs/profpubs.html.
! An open MPN on file at COD is assigned to a student.
! A school using the multi-year feature can use any MPN accepted
by the COD System.
! All loans for a student are linked to the same MPN across schools
and academic years.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-120
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Single-Year MPN Feature

The single-year MPN feature requires that a new MPN be completed for a
student for each academic year. All schools NOT eligible to process
MPNs using the multi-year feature, must use the single-year feature.
Schools eligible for the multi-year feature may opt to process MPNs using
the single-year feature.

Business Rules:
! Under single-year feature a new MPN must be generated each
academic year for each student.
! A single-year school must use a MPN generated at or for that
school only.
! A single-year school can link multiple subsidized and unsubsidized
loans for the same academic year, for the same student, to the same
MPN.
! The academic year start and end dates must be the same on all loan
records linked to a specific MPN under the Single-Year feature.
! When a school eligible for the Multi-Year feature, opts to use the
Single-Year feature, the school must update their option on the
COD website.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-121
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Generating a MPN/PLUS Promissory Note Response

A MPN/PLUS Promissory Note Response is generated by COD and sent
to a school to provide the status of a MPN or a PLUS Promissory Note.

Business Rules:
! A MPN/PLUS Promissory Note Response provides the status of a
MPN or a PLUS Promissory Note.
! A COD system-generated MPN/PLUS Promissory Note Response
contains a Document Type of “PN.” The Document Type
indicates the type of Response.
! A Response Document of Document Type “PN” contains a system-
generated Document ID.
! A MPN/PLUS Promissory Note Response contains the following
data elements in the Response complex element <Response>:
o MPN Status, <MPNStat>
o Document Type, <DocumentType>
o Processing Date, <ProcessDt>
• In addition, the following data elements are in the MPN/PLUS
Promissory Note Response:
o MPN ID, <MPNId>
o Electronic MPN Flag <EMPNFlg> is part of the Response
if an electronic MPN is filed by the student.
Note: The sample MPN Response on the next page does
not have this data element as an e-MPN was not filed.
! A MPN/PLUS Promissory Note Response is generated by the COD
System when a paper or electronic MPN/PLUS Promissory Note is
linked to an accepted loan award OR for pending notes.
! A Pending MPN is an accepted MPN which cannot yet be linked
with an loan award record. (No accepted Origination record on
file). In some cases, this situation is created by an e-MPN.
! For subsidized and unsubsidized loans, the COD System will
generate MPN Responses for Pending MPNs starting with version
1.1, April 29, 2002. (For MPNs accepted between 3/18/02 to
4/29/02, the COD System will run a special routine to capture and
send these MPN Responses to schools.)
Note: For PLUS loans, PLUS Promissory Note Responses are
NOT generated by the COD System at this time for Pending PLUS
Promissory Notes.
June 2002 (2002-2003) COD Technical Reference Implementation Guide
Version 3.4 COD Technical Reference Document for Full Participants I-122
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! An e-MPN Flag = “true” on a Promissory Note Response identifies

that the loan has been linked to an e-MPN.

Example:
Below is a sample MPN Response where an e-MPN was not filed by the
borrower:

<CommonRecord>
<DocumentId>2002-07-10T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-07-10T17:20:01.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="00000632"/>
</Destination>
<FullRsFlg>F</FullRsFlg>
<ReportingSchl EntityId="00000632">
<AttendingSchl EntityId="00000632">
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">
<DLUnsub>
<AwardYr>2003</AwardYr>
<LoanKey>01</LoanKey>
<SchlUseOnly>722411</SchlUseOnly>
<AwardID>123456789U03G12345001</AwardID>
<Response>
<RsInd>A</RsInd>
<EMPNFlg>False</EMPNFlg>
<MPNID>123456789M03G12345001</MPNID>
<MPNStat>A</MPNStat>
<MPNLinkFlg>True</MPNLinkFlg>
</Response>
</DLUnsub>
<Response>
<RsInd>A</RsInd>
</Response>

</Student>
</AttendingSchl>
</ReportingSchl>
<Response>
<DocumentType>PN</DocumentType>
<DocumentStat>A</DocumentStat>
<ProcessDt>2002-07-15</ProcessDt>
</Response>
</CommonRecord>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-123
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan PLUS Credit Check

Requesting a PLUS Credit Decision

Schools can request a PLUS Credit Decision on-line. This information
will be provided at a later date.

Generating Credit Decision Override Responses

When a PLUS borrower requests a credit decision override or submits an
Endorser Addendum, a Credit Decision Override Response is generated by
the COD System and sent to the school. This response provides the credit
decision status of the override or endorser.

Business Rules:
! A Credit Decision Override Response is generated by the COD
System and sent to a school to provide the status of a credit
override or the credit decision results of an endorser.
! A COD system-generated Credit Decision Override Response
contains a Document Type of “CO.” The Document Type
indicates the type of Response.
! A Response Document of Document Type “CO” contains a
system-generated Document ID.
! A Credit Decision Override Response contains the following data
elements in the Response complex element <Response>:
o PLUS Credit Decision Override Indicator, <CrOverrideInd>
o Credit Decision Date, <CrDecisionDate>
o Document Type, <DocumentType>
o Processing Date, <ProcessDt>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-124
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:
Below is a sample Credit Decision Override Response:
<CommonRecord>
<DocumentId>2002-07-11T09:09:09.0012345678</DocumentId>
<CreatedDtTm>2002-07-11T09:09:09.00</CreatedDtTm>
<Source>
<COD EntityId="00000001"/>
</Source>
<Destination>
<School EntityId="00000632"/>
</Destination>
<FullRsFlg>F</FullRsFlg>
<ReportingSchl EntityId="00000632">
<AttendingSchl EntityId="00000632">
<Student SSNum="123456789" DtofBirth="1972-01-01" LastName="SMITH">
<DLPLUS>
<AwardYr>2003</AwardYr>
<SchlUseOnly>722411</SchlUseOnly>
<AwardNum>001</AwardNum>
<AwardID>123456789P03G12345001</AwardID>
<Borrower SSNum="123456789" DtofBirth="1970-01-01" LastName="SMITH"/>
<Response>
<RsInd>A</RsInd>
<CrDecisionDt>2002-07-11</CrDecisionDt>
<CrOverrideInd>C</CrOverrideInd>
</Response>
</DLPLUS>
<Response>
<RsInd>A</RsInd>
</Response>
</Student>
</AttendingSchl>
</ReportingSchl>
<Response>
<DocumentType>CO</DocumentType>
<DocumentStat>A</DocumentStat>
<ProcessDt>2002-07-11</ProcessDt>
</Response>
</CommonRecord>

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-125
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan Reports

Direct Loan Reports Options

Direct Loan Reports are available to schools in a variety of format options.
Direct Loan schools can request these reports via the COD Website or the
COD School Relations Center.

Business Rules:
! Direct Loan Reports for 2002 –2003 are sent to schools as a flat
file and not an XML document. The flat file format options
include:
o Pipe Delimited or Comma Delimited comma (see example
below)
o Preformatted Text file
! Portrait
! Courier 10
! 78 characters per line
! 59 lines per page
o Fixed Length file
! Direct Loan Reports for 2002-2003 are viewable on the COD
Website in the following format options:
o PDF or CSV (COD Website)
! Some report options are tailored to a specific report. These
specific options are discussed under the appropriate report section.
Note: Comma Delimited formatted reports are available only on the
COD Website and are listed as the CSV option. These files are
downloadable into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-126
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Below is a summary of all Direct Loan Reports and available formats

generated by the COD System.

PDF Pipe Comma Preformatted Fixed

Delimited Delimited Text Length
School Account X X
Statement (SAS)
Pending Disbursement X X X X
List
Funded Disbursement X X X X
List
30 Day Warning X X X
Inactive Loans X X X X
Duplicate Student X X X X
Borrower
SSN/Name/Date of Birth X X X X
Change
Direct Loan Rebuild X

Example:
Below is an example of a pipe delimited report format:

Name|SSN|City
John Brown|111-11-1111|Columbus|
Sandra Farmer|111-11-2222|Fort Lauderdale|

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-127
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

School Account Statement (SAS)

The School Account Statement (SAS) contains the functionality
previously contained in the Direct Loan School Account Statement
(DLSAS) and the 732 Reports.

Business Rules:
! School Account Statement (SAS) is generated by the COD System on
a monthly basis.
! Once a school has closed out a specific program year, a school has
the option to not receive the SAS with approval and verification
from Direct Loan Operations.
! Schools have the option to have their SAS generated on the:
o First of the month (default setting) OR
o 15th of the month.
! Loan Detail is available at the disbursement level or the loan level.
! Schools receive the SAS in the following formats:
o Pipe Delimited (message class DSDD03OP – Disbursement
level or DSLD03OP – Loan Level)
o Fixed length flat file (message class DSDF03OP –
Disbursement level or DSLF03OP – Loan level)
! Summary information is always on the SAS and includes:
o Year-to-Date Cash Summary
o Monthly Cash Summary
o Year-to-Date Disbursement Summary by Loan Type
o Monthly Disbursement Summary by Loan Type
! Cash Detail and Loan Detail information is optional on the SAS.
! School options for the Cash Detail section of the SAS include:
o Monthly Cash Detail (default setting) OR
o Year-to Date Cash Detail OR
o No Cash Detail

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-128
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! School options for the Loan Detail section of the SAS include:
o Disbursement Level Detail:
! Monthly without loan summary (default setting) OR
! Year-to-Date with loan summary OR
o Loan Level Detail Year-to-Date OR
o No Loan Detail

Example:
A sample of the School Account Statement report is available in Appendix
I – COD Reports.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-129
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pending Disbursement List Report

Schools can use the Pending Disbursement List report (formerly the
Anticipated Disbursement Listing) to determine estimated disbursements
and disbursement dates on file on the COD System.

Note: Disbursements on this report have Payment Triggers = “false.”

Business Rules:
! The Pending Disbursement List Report is provided in the following
file formats:
o Pipe Delimited (message class DALC03OP)
o Preformatted Text file (message class DIAA03OP)
o PDF or CSV (COD Website)

Example:
A sample of the Pending Disbursement List Report will be provided at a
later date.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-130
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Funded Disbursement List Report

The Funded Disbursement List report (formerly the Actual Disbursement
Roster) displays all disbursements that have been funded.

Business Rules:
! The Funded Disbursement List Report is available in the following
formats:
o Pipe Delimited (message class DARC03OP)
o Preformatted Text file (message class DIAC03OP)
o PDF or CSV (COD Website)

Example:
A sample of the Funded Disbursement List Report will be provided at a
later date.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-131
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

30 Day Warning Report

The 30-Day Warning Report lists unbooked loans for which the COD
System has not received the required elements for “booking” a loan within
30 calendar days of the disbursement date.

Business Rules:
! The 30 Day Warning Report is available in the following formats:
o Pipe Delimited (message class DIWC03OP)
o Preformatted Text file (message class DIWR03OP)
o PDF or CSV (COD Website)
! Loans with Award Amounts = $0 do not display on this report.
! Loans that display on this report for a 90-day period without a
promissory note accepted and a disbursement funded are removed.

Example:
A sample of the 30 Day Warning report is available in Appendix I – COD
Reports.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-132
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Inactive Loans Report

The Inactive Loan Report lists all Direct Loan Awards that have been
inactivated (adjusted to $0) by the school for the reporting period.

Business Rules:
! The Inactive Loans Report is provided in the following file
formats:
o Pipe Delimited (message class INACCDOP)
o Preformatted Text file (message class INACCFOP)
o PDF or CSV (COD Website)

Example:
A sample of the Inactive Loans report is available in Appendix I – COD
Reports.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-133
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Duplicate Student Borrower Report

The Duplicate Student Borrower Report lists the student borrowers for
which the COD System has accepted multiple Direct Subsidized and/or
Unsubsidized Award records with the same or overlapping academic
years.

Business Rules:
! The Duplicate Student Borrower Report is provided in the
following file formats:
o Pipe Delimited (message class DUPLCDOP)
o Preformatted Text file (message class DUPLPFOP)
o PDF or CSV (COD Website)

Example:
A sample of the Duplicate Student Borrower Report is available in
Appendix I – COD Reports.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-134
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

SSN/Name/Date of Birth Change Report

The SSN/Name/Date of Birth Change Report shows SSN, Name and Date
of Birth changes that are initiated by any school and SSN changes that are
initiated by Direct Loan Servicing.

Business Rules:
! The SSN/Name/Date of Birth Change Report is provided in the
following file formats:
o Pipe Delimited (message class SNDCCDOP)
o Preformatted Text file (message class SNDCPFOP)
o PDF or CSV (COD Website)

Example:
A sample of the SSN/Name/Date of Birth Report will be provided at a
later date.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-135
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan Rebuild Process

A Rebuild File can be requested to rebuild your Direct Loan Database or

to recreate specific student records.

Business Rules:

! The Direct Loan Rebuild File is provided in a fixed length record

layout. Please refer to the 2002-2003 Direct Loan Technical
Reference for the Rebuild record layout
! The Rebuild File can be requested via the COD Website or by
calling the COD School Relations Center.
! A Rebuild File can be requested by a school for a specific:
o Award Year (Program Year)
o Student
o Award ID (Loan ID) or
o Date Range

Note: The date range option selects accepted loan awards within the date
range and provides all disbursement transactions related to these loans.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-136
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Direct Loan Entrance/Exit Interview

Requesting an Entrance Counseling File/Report

Schools may request an Entrance Counseling File or Report to identify
students who have completed entrance counseling on the Loan Origination
On-line Application.

Business Rules:
! Borrower’s Entrance Counseling results from the Loan Origination
On-Line Application are available in an electronic file format.
! Schools can choose to receive this optional report daily, weekly, or
monthly. The default frequency option is monthly.
! Schools can choose from the following file formats:
o ASCII-delimited (message class DECC03OP)
o Fixed length with Header and Trailer (message classs
DECF03OP)
o Pre-formatted report (message class DECP03OP)
! The default file format is fixed length file.

Example:
A sample of a monthly Entrance Counseling Results Report is available in
Appendix I – COD Reports.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-137
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Requesting an Exit Counseling File/Report

Schools may request an Exit Counseling File or Report to identify students
who have completed exit counseling on the Direct Loan Servicing
Website.

Business Rules:
! Borrower’s Exit Counseling results from the Direct Loan Servicing
Website are available in an electronic file or downloadable format.
! Schools can choose to receive this optional report daily, weekly, or
monthly. The default frequency option is monthly.
! Schools can choose from the following file formats:
o ASCII-delimited (message class DLCM03OP)
o Fixed length with Header and Trailer (message classs
DLFF03OP)
o Pre-formatted report (message class DLFM03OP)

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-138
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pell Grant Award and Disbursement Process

Pell Correction Edits to be Treated as Rejects

The COD System provides an option for the processing of Pell data that
allows schools to choose if they want to accept corrections to the Pell
Grant data they submit to the COD System, or if they would rather have
the data rejected.

Business Rules:
! Schools may select an option to have Pell Grant data that fails edits
rejected rather than receive corrections for that data.
! This option applies to all edits that are marked as an Edit Type C/R
in Appendix E – Edit Comment Codes and Descriptions.
! Both corrections and rejections utilize the same edit number to
indicate which edit was set; the Response Indicator differentiates
between corrected and rejected.
! When returning Response Document files, the COD System
returns an edit code, the field it pertains to and the value submitted
for rejected data
! When returning Response complex elements, the COD System
returns an edit code, the field to which it pertains, and the corrected
value.
! Unless the School contacts the COD School Relations Center to
change this option, the COD System will correct their data.

Storing of Reject Records

The COD System stores all rejected records. These rejects can be viewed
on the COD website.

Business Rules:
! Schools may view their rejected records on the COD website.
! Rejected records are not included in the YTD or Reconciliation
report.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-139
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Reporting Pennies in the Award and Disbursement

Amounts Data Elements
The Award and Disbursement Amounts on the Common Record may
include pennies. In the Pell Grant Program, pennies can be reported as
partial dollars or two zeros.

Business Rules:
! The data elements for Award and Disbursement Amounts on the
Common Record may include two digits to the right of a decimal
point.
! When the reported amount does not include a decimal point, the
COD System infers a decimal point and two zeros to the right of
the last digit reported. For example, if a school reports 1000, the
COD System infers a decimal and two zeros and stores as 1000.00.
! In the Pell Grant Program, schools may report partial dollars
(3500.32) OR zeros in the last two digits (3500.00) for Award
Amount and Disbursement Amount
OR
! Report the whole dollar amount only (3500) and the COD System
infers the decimal point and two zeros and stores as (3500.00).
! The Award and Disbursement Amount data elements are:
o Award Amount, <AwardAmt>
o Disbursement Amount, <DisbAmt>

Example:
When reporting a Pell Grant Award Amount of $1250. 34:

1) Include the decimal point and two digits to the right: 1250.34
OR
2) Include the decimal point and two zeroes to the right: 1250.00
OR
3) Omit the decimal point and report the whole dollar amount only: 1250
Then, the COD System infers a decimal and two zeros and stores 1250.00.

DO NOT submit 125000 as the COD System infers a decimal and stores
this submission as 125000.00.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-140
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Establishing Pell Grant Award Information

Award information submitted to the COD System for a student from a
specific Attending School applies to the entire award year for that student.

Business Rules:
! The COD System establishes only one set of Award information
per Attending School Entity ID per student per award year.
o The first submission of Award information that is accepted
by the COD System establishes the Pell Grant award for the
student for that Attending School Entity ID for that award
year.
o Subsequent submissions of Award information for that
student, Attending School Entity ID, and award year are
treated as an update to the original accepted data.
! Pell Grant Award Amounts that establish the award cannot be zero
on first submission.
! The COD System uses the CPS Transaction Number submitted
with the Award information to pull the EFC reported for the
student from the CPS and determine the student’s Scheduled
Federal Pell Grant. The Scheduled Federal Pell Grant and the
student’s Percentage of Eligibility Used at any other Attending
campus(es) is used to determine the student’s maximum Award
Amount for the entire award year.
! The CPS Transaction Number reported in the Award information
applies to all Pell Grant transactions for that award year.
! The COD System uses the Scheduled Federal Pell Grant Payment
and Disbursement Schedules, including the Low Tuition Payment
and Disbursement Schedules, to calculate the Scheduled Award
and validate the Award Amounts.
Note: Refer to Appendix H – Pell Calculations Table for the data
elements and calculations that apply according to the Payment
Methodology used by the School.
! If the Award Amount for the entire award year reported for the
student exceeds the maximum Award Amount determined by the
COD System, COD either corrects or rejects the Award Amount
depending on the school’s selected option.
o If rejected, the School must determine the correct Award
Amount and resubmit to the COD System.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-141
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Note: Refer to the Pell Correction Edits to Be Treated as Rejection

Edits section for more information.
! If the Award information for a student changes, the School must
submit the change to the COD System within 30 of the date the
School becomes aware of the change, or by the established Pell
Grant reporting deadline, whichever comes first.
! The COD System does not use the Award information to establish
or adjust a school’s Pell Grant CFL. Only Disbursement
information submitted with a Payment Trigger set to “true” can
change a school’s Pell Grant CFL.
! The COD System does not accept new Award information or
increases to Award information after the established student award
data submission deadline (September 30, 2003 or the next business
day) unless the school has been granted administrative relief from
this deadline, or has received relief from this deadline via the Audit
process.
! The COD System always accepts Award information decreases
until the award year shut down (September 30, 2008).

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-142
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Removal of Enrollment Status Edit on Award Amount

The COD System does not edit Enrollment Status to determine Award
Amount. In instances where required because of the Payment
Methodology, the COD System also edits Award Amount based upon
Weeks of Instruction and Clock Hours.

Business Rules:
! Schools are no longer required to report Enrollment Status.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-143
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Submitting Pell Grant Disbursement Information and

Payment Trigger
The COD System can accept Pell Grant Disbursement information in
advance of, on, or after the disbursement date.

Business Rules:
! Disbursement Date is defined as the date cash was credited to the
student’s account or paid to the student directly.
! The COD System must accept an Award Amount greater than zero
($0) before it can accept Disbursement information for that student.
Note: Award and Disbursement information can be submitted and
accepted in the same transmission.
! A student can have up to 20 disbursements (Numbers 1-20)
! Pell Grant Disbursement Amounts cannot be zero on first
submission.
! The total accepted and posted Disbursement information
(disbursement information with Payment Trigger = “true”) cannot
exceed the Award Amount for that student.
! When reporting a change to the COD System, replacement
Disbursement Amounts must be reported rather than an adjustment
to the existing Disbursement Amount.
Note: Refer to section titled Updating and Adjusting Pell Grant
Disbursement Amounts and Dates for more information.
! Disbursement Date may range from 2002-06-21 (June 21, 2002) to
2008-09-30 (September 30, 2008).
! The COD System accepts Disbursement information with
downward adjustments through 2008-09-30 (September 30, 2008).
! Depending on the funding method employed by the school, the
COD System may accept Disbursement information in advance of,
on, or after the disbursement date.
! Disbursement information is submitted to the COD System with a
Payment Trigger equal to “true” or “false.”
o Disbursements with a Payment Trigger set to “false” are
treated as edit only and do NOT change the CFL. False
indicates disbursement information expected as of the time
of the submission.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-144
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o Disbursements with a Payment Trigger set to “true” change

the CFL when applicable. True indicates actual
disbursement information.
o If the Payment Trigger is omitted from the Common
Record, the COD System sets it to “false.”
! Payment Trigger can be updated and disbursements can be
generated, updated and adjusted on the COD website.
! The required data elements for a Pell Grant edit only disbursement
are:
o Disbursement Number, <Disbursement Number= " ">
o Disbursement Amount, <DisbAmt>
o Disbursement Date, <DisbDt>
o Payment Trigger set to “false”, <PmtTriggerFlg = “false”>
o Disbursement Sequence Number, <DisbSeqNum>
! The required data elements for a Pell Grant disbursement
submitted to substantiate the CFL:
o Disbursement Number, <Disbursement Number= " ">
o Disbursement Amount, <DisbAmt>
o Disbursement Date, <DisbDt>
o Payment Trigger set to “true,” <PmtTriggerFlg = “true”>
o Disbursement Sequence Number, <DisbSeqNum>
! Pell Grant CFL changes, if applicable, are driven by:
o Disbursement Date, <DisbDt>
o Payment Trigger set to “true,” <PmtTriggerFlg = “true”>
! Schools designated as Advance Pay or Cash Monitoring 1
(CM1) may submit a Payment Trigger set to “true” up to 30
calendar days before the Disbursement Date.
o If the current date exceeds 30 calendar days before the
Disbursement Date and the Payment Trigger is set to
“true,” the COD Systemrejects the disbursement with error
code 051.
o If the current date is within eight (8) to 30 calendar days
before the Disbursement Date and the Payment Trigger is
set to “true,” the COD System accepts the disbursement,
but does not post the disbursement until seven (7) calendar
days before the Disbursement Date.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-145
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

o If current date is within seven (7) calendar days before the

Disbursement Date and the Payment Trigger is set to
“true”, the COD System accepts and posts the
disbursement.
! Schools designated as Pell Pushed Cash or Just-In-Time may
submit a Payment Trigger set to “true” up to 7 calendar days before
the disbursement date.
o If the current date exceeds seven (7) calendar days before
the Disbursement Date and the Payment Trigger is set to
“true,” the COD System rejects the disbursement with error
code 051.
o If current date is within seven (7) calendar days before the
Disbursement Date and the Payment Trigger is set to
“true,” the COD System accepts and posts the
disbursement.
! Schools designated as Reimbursement or Cash Monitoring 2
(CM2) can submit a Payment Trigger set to “true” if the current
date is equal to or after the Disbursement Date.
o If current date is before the Disbursement Date and the
Payment Trigger is set to “true”, the COD System rejects
the disbursement with error code 051.
o If the current date is equal to or after the Disbursement Date
and the Payment Trigger is set to “true,” the COD System
accepts and posts the disbursement upon review of
documentation by Case Management.
! A Payment Trigger set to “true” can only be updated to “false” on a
Pell Grant disbursement if the current date is within eight (8) to 30
calendar days before the Disbursement Date.
! Disbursement information with a Payment Trigger of “true” is
rejected unless a student has accepted Award information on file
for that Attending School.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-146
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example for Schools Designated as Advance Pay or Cash

Monitoring 1 (CM1):

Date Sent Disbursement Sequence Disbursement Disbursement Payment Result

Number Number Date Amount Trigger
08/15/2002 01 01 09/08/2002 $1500.00 true Posted on 9/1/02 (7
calendar days
before disbursement
date)

02/01/2003 02 01 02/07/2003 $1500.00 true Posted on 2/1/2003

(7 calendar days
before disbursement
date)

03/01/2003 03 01 06/01/2003 $500.00 true Disbursement

rejected; School
must resubmit
Disbursement
information within
30 calendar days of
Disbursement Date.

Example for Schools Designated as Pell Pushed Cash or JIT:

Date Sent Disbursement Sequence Disbursement Disbursement Payment Result

Number Number Date Amount Trigger
08/15/2002 01 01 09/08/2002 $1500.00 true Disbursement
rejected; School
must resubmit
Disbursement
information within 7
calendar days of
Disbursement Date.

02/01/2003 02 01 02/07/2003 $1500.00 true Posted on 2/1/2003

(7 calendar days
before disbursement
date)

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-147
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example for Schools Designated as Reimbursement or Cash

Monitoring 2 (CM2):

Date Sent Disbursement Sequence Disbursement Disbursement Payment Result

Number Number Date Amount Trigger
09/06/2002 01 01 09/08/2002 $1500.00 true Disbursement
rejected; School
must resubmit
Disbursement
information on or
after the
Disbursement Date.

02/07/2003 02 01 02/07/2003 $1500.00 true Posted on 2/7/2003

(On or after
disbursement date,
upon review of
documentation by
Case Management)

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-148
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Changing Pell Grant Disbursement Amounts and

Dates
Disbursement Amounts and Dates can be changed using the same
disbursement number, rather than reporting a new disbursement number.

Business Rules:
! To change a Disbursement Amount and/or Disbursement Date, the
following data elements are required:
o Payment Trigger, <PmtTriggerFlg = “”>
o Disbursement Number, <Disbursement Number “”>
o Disbursement Sequence Number, <DisbSeqNum>
o Disbursement Amount, <DisbAmt>
o Disbursement Date, <DisbDt>
! When changing a disbursement already reported to COD, the same
Disbursement Number must be reported.
! When changing a disbursement with a Payment Trigger = “false,”
the Disbursement Sequence Number must be set to “01.”
! When changing a disbursement that already has a Payment Trigger
= “true,” the Disbursement Sequence Number must be unique. The
next sequential Disbursement Sequence Number must be reported.
! Disbursement Sequence Numbers for a specific Disbursement
Number must be used in sequential order within the range of 01-
65.
! When changing the Disbursement Amount, replacement
Disbursement Amounts must be reported, rather than an
adjustment to the existing Disbursement Amount.
Note: In the prior year, a negative disbursement amount was
reported when changing disbursement amounts. For 2002-2003, a
Full Participant cannot report a negative disbursement amount on a
Common Record document. A replacement disbursement amount
MUST be reported.
! Disbursement Date is always the date the cash was credited to the
student’s account or paid to the student directly for this specific
Disbursement Number. Disbursement Date is NOT the transaction
date of the adjustment to the disbursement.
! Pell Grant disbursement amounts can be adjusted to $0.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-149
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Example:
The following table illustrates the use of Disbursement Sequence Number
and replacement Disbursement Amounts when making a change to an
existing disbursement:

Disbursement Sequence Disbursement Disbursement Accepted YTD

Number Number Date Amount Amount
01 01 09/01/2002 $2000.00 $2000.00

02 01 01/02/2003 $2000.00 $4000.00

02 02 01/02/2003 $1500.00 $3500.00

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-150
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Processing System-Generated Pell Responses

COD system-generated Common Record Response Documents of
Document Type “ND” (Negative Disbursement) are generated for several
situations, including Verification Status Code W, Negative Pending
Record, and Potential Overaward Process reductions.

Business Rules:
! A Response Document of Document Type “ND” contains a
system-generated Document ID.
! The Response indicates the Disbursement Number to which the
downward adjustment applies and a COD system-generated
Disbursement Sequence Number between 66 and 90.
Note: Refer to the Reporting Verification Status Code, Negative
Pending Records, and Potential Overaward Process sections for
more information.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-151
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Reporting Verification Status Code

Valid values for the Verification Status Code tag are: “W” or “V.” or the
Verification Status Code tag may be omitted from the Common Record.

Business Rules:
! The COD System valid values for the Verification Status Codes are
“W” (Without Documentation), “V” (Verified), or the Verification
Status Code tag may be omitted from the Common Record.
! Schools report a Verification Status Code of “V” on students for
whom verification has been completed, including all
documentation.
! QA Schools and other schools who verify students not selected by
the CPS report a Verification Status Code of “V” for those students
whose data they elect to verify.
! Schools report a Verification Status Code of “W” for students
selected for verification, but for whom the schools elects to make
interim disbursements prior to completing the verification process.
! For students with a Verification Status Code of “W,” the COD
System only accepts Disbursement Amounts up to 50% of the
student’s Scheduled Federal Pell Grant
! For students reported with a Verification Status Code of “W”, the
School must change the Verification Status Code to “V” (Verified)
once the data verification is complete.
! The COD System does not generate a Verification Status Code of
“W” based on selection by the CPS.
! Schools omit the Verification Status Code tag from the Common
Record for students whom the School elected not to verify.
! QA Schools or Schools exercising 30% tolerance option may omit
the Verification Status Code tag from the Common Record for
students selected for verification by the CPS that they elected not
to verify.
! The COD System produces a list of students at the School with a
Verification Status of “W” and sends a warning that the School
must take action.
! At some point after the warning, the COD System reduces all
disbursements for students with a Verification Status of “W” to
zero ($0.00).

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-152
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Negative Pending Records

If an update to Award information produces an Award Amount that is less
than the total of all accepted and posted disbursements (disbursement
information with Payment Trigger = “true”) for the student, the COD
System creates a Negative Pending Record for the student.

Business Rules:
! If the total accepted and posted Disbursement Amounts exceed the
Award Amount, the COD System generates a Response that
includes a Negative Pending Amount for the student and indicates
the Disbursement Number.
! Within 30 calendar days of receiving notice that the COD System
has established a Negative Pending Record for a student, the
school needs to send an adjustment to either the Disbursement
Amount or to the Award Amount equal to or greater than the
Negative Pending Amount.
! The COD System does not accept additional Disbursement
information with a Payment Trigger of “true” for a student with a
Negative Pending Record at COD, unless or until the Award
Amount increases.
! If the COD System does not receive an adjustment to the Award or
Disbursement Amount equal to or greater than the Negative
Pending Amount within 30 calendar days, it will generate a
Negative Disbursement Response with a Document Type “ND
• The Negative Disbursement Response contains the amount
of the Pell Negative Disbursement and is a downward
adjustment to the Disbursement Amount.
• It is only after 30 days that the COD system reduces the
disbursement and a system generated Negative
Disbursement Response is sent to the school.
• The downward adjustment to the Disbursement Amount
applies to the existing Disbursement Number and is
assigned a COD system generated Disbursement Sequence
Number between 66 and 90.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-153
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Concurrent Enrollment
A student may not receive a Pell Grant at two or more schools
concurrently. When more than one Attending School reports
disbursements for a student and the enrollment dates are within 30
calendar days of each other, the COD System identifies a potential
concurrent enrollment and sends a warning message to all schools
involved.

Business Rules:
! A student may not receive a Pell Grant at two or more schools
concurrently.
! When the COD System receives disbursement information for a
student from more than one Attending School for the same award
year, the COD System checks whether the enrollment dates are
within 30 calendar days of each other.
! If a concurrent enrollment situation exists, the COD System sends
the school that submitted the disbursement information a warning
edit on their Response document.
! The COD System sends the school that submitted the disbursement
information and all other schools with accepted disbursement
information in COD for the student and that award year, a Multiple
Reporting Record (MRR).

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-154
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pell Potential Overaward Process (POP)

A student may receive disbursements from more than one Attending
School during the course of an award year. When more than one Attending
School reports disbursements for a student, the COD System checks to
make sure that the student has not received more than 100% of their
eligibility for a Federal Pell Grant. Section 690.65 of the regulations
provides the basis for determining a student’s remaining eligibility when
another school has disbursed Pell Grant funds to the student:
! Calculate the Eligibility Used at each previous school by dividing
the disbursements to the student at the school by the Scheduled
Federal Pell Grant at that specific school;
! Calculate the Total Eligibility Used for the award year by adding
the Eligibility Used for all schools the student previously attended;
! Calculate the Remaining Eligibility by subtracting the Total
Eligibility Used from 100% (1.00000).
! The Remaining Eligibility is the percentage of the Scheduled
Federal Pell Grant at the new school to which the student is
entitled.
If the COD System receives disbursement information that places the
student in a situation where he/she has received more than 100% of their
Total Eligibility Used, the student has entered a Potential Overaward
(POP) situation. In a POP situation, the COD System accepts the
disbursement information and notifies all of the schools involved that the
POP situation must be resolved within 30 calendar days. If after 30
calendar days the situation has not been resolved, the COD System
generates a negative disbursement for all of the student’s Pell
disbursements at all schools for that award year. The eligible schools are
then required to re-report accurate disbursement records to reinstate the
student’s disbursements.

Business Rules:
! A student may not receive more than 100% of their eligibility for a
Pell Grant.
! A school to which a student transfers must determine the student’s
Total Eligibility Used, considering disbursements made and the
Scheduled Federal Pell Grant at each school the student previously
attended in the award year.
! When the COD System receives disbursement information for a
student from more than one Attending School for the same award
year, the COD System checks whether the student has received
more than 100% of their total eligibility for a Pell Grant.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-155
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

! If a Potential Overaward (POP) situation exists, the COD System

sends the school that submitted the Disbursement Information a
warning edit on their Response document.
! The COD System sends the school that submitted the
Disbursement Information and all other schools with accepted and
posted Disbursement Information in COD for that student and that
award year, a Multiple Reporting Record (MRR).
! The COD System allows a POP situation to exist for 30 calendar
days from the date the student entered the POP situation (defined
as the date the MRR for the POP situation is created).
! During the 30 day period, each school involved in the Potential
Overaward must apply the proper eligibility calculation. Only the
school that the student is not attending or that inaccurately reported
the disbursement information must report any changed
disbursement information to eliminate the POP situation.
! During that 30 day period, the COD System can accept and post
further disbursements that decrease or increase the student’s year-
to-date disbursement amount.
! The COD System accepts Disbursement Information that change
CFL from no more than 3 schools for students in a POP situation.
! If the student remains in a POP situation after 30 calendar days, the
COD System reduces all accepted and posted disbursements to
zero ($0.00) for that student and that award year AT ALL
SCHOOLS INVOLVED.
! Each school that correctly paid the student Pell Grant funds must
re-report the student’s Disbursement Information to COD.
! During the POP situation, the COD School Relations Center will
take a proactive role in contacting the schools in a POP situation.
! COD does not prevent the same schools from creating another POP
situation for the same student
! COD School Relations will escalate the issue should the same
schools create another POP situation involving the same student.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-156
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pell Administrative Cost Allowance (ACA)

The COD System calculates and pays ACA amounts.

Business Rules:
! The COD System calculates ACA amounts based on the number of
unduplicated recipients at each Reporting campus.
! The COD System pays ACA for students with at least one accepted
and posted disbursement during the course of an award year.
! The COD System disburses ACA multiple times during the award
year.
! Unless a school declines ACA, it receives a text message
indicating its unduplicated recipient count and the amount of ACA
being paid.
! The COD System pays each ACA amount directly into the
School’s bank account regardless of the Funding Methods used for
CFL.
! The COD System will process decreases in ACA obligations.

Pell Payment Schedule

For information on the Pell Grant Payment Schedule, please refer to the
2002-2003 Pell Grant Payment Schedule on www.ifap.ed.gov.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-157
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Pell Grant Reports

Pell Grant Reports Options

Pell Grant Reports are available to schools via data requests or on the
COD Website.

Business Rules:
! Pell Grant Reports for 2002-2003 are sent to schools as a Fixed
Length flat file and not an XML document.
! The SSN/Name/Date of Birth Change Report is also available in
the CSV and Pipe Delimited formats.

Note: Please refer to Appendix M – COD Message Class Table for

information on the messages classes to be used for Pell Grant Reports.

Data Request Response

After a data request is received and processed, a Data Request Response is
sent back to the school for each data request received.

Business Rules:
! The Data Request Response is provided in the following formats:
o Fixed length file

Example:
A copy of the preformatted report will be provided at a later date.

Note: The data request response record layout (fixed length) is provided
in the 2002-2003 Pell Technical Reference.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-158
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Electronic Statement of Account (ESOA)

The Electronic Statement of Account (ESOA) summarizes the status of a
school’s CFL verses the amount expended to date for that award year.

Business Rules:
! An ESOA can be COD system generated or may be requested by
the school.
! If a school is Advance Pay, the ESOA is sent when the initial CFL
calculation is performed. When COD has accepted and posted
enough actual disbursements to exceed the CFL, the COD System
generates an ESOA to the school. The ESOA is only generated
when the CFL is exceeded or decreased; it is not generated each
time a disbursement is accepted.
! If a school receives Pushed Cash, the ESOA is generated each time
the COD System accepts and posts actual disbursements. This is
because the school receives no CFL prior to the submission of
actual disbursements.
! The ESOA is provided in the following formats:
o Fixed length flat file
o

Example:
A sample of the Electronic Statement of Account (ESOA) report is
available in Appendix I – COD Reports.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-159
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Multiple Reporting Record (MRR)

The Multiple Reporting Record (MRR) provides information to a school
about a school’s origination and disbursement status at other schools and
the amount of the scheduled Pell Grant award disbursed. The MRR
identifies two primary types of multiple reporting conditions: concurrent
enrollment and potential overaward situations.

Business Rules:
! An MRR can be COD system generated or may be requested by the
school.
! The MRR is provided in the following formats:
o Fixed length flat file

Example:
A copy of the preformatted report will be provided at a later date.

Note: The MRR record layout (fixed length) is provided in the 2002-2003
Pell Technical Reference.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-160
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Reconciliation Report
The Reconciliation Report is a one-record summary of the data that COD
has for the student. This report can be used to reconcile the total
disbursement amount per student with COD.

Business Rules:
! The Reconciliation Report is provided in the following formats:
o Fixed length flat file

Example:
A copy of the preformatted report will be provided at a later date.

Note: The Reconciliation Report record layout (fixed length) is provided

in the 2002-2003 Pell Technical Reference.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-161
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

Year-to-Date Record (YTD)

The Year-to-Date (YTD) Record shows the number of recipients at the
school; the number of award and disbursement records that were accepted,
corrected, and rejected; and, for certain edit codes, the number of times a
school received that specific edit code on a response document. The YTD
Record can be used to replace a corrupt database or to reconcile records
with accepted data on COD.

Business Rules:
! The Reconciliation Report is provided in the following formats:
o Fixed length flat file

Example:
A copy of the preformatted report will be provided at a later date.

Note: The Year-to-Date record layout (fixed length) is provided in the

2002-2003 Pell Technical Reference.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-162
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

SSN/Name/Date of Birth Change Report

The SSN/Name/Date of Birth Change Report shows SSN, Name and Date
of Birth changes that are initiated by any school and SSN changes that are
initiated by Direct Loan Servicing.

Business Rules:
! The SSN/Name/Date of Birth Change Report is provided in the
following formats:
o Pipe Delimited
o Preformatted Text file
o PDF or CSV (COD Website)

Example:
A sample of the SSN/Name/Date of Birth Report will be provided at a
later date.

Note: Comma Delimited formatted reports are available only on the COD
Website and are listed as the CSV option. These files are downloadable
into Excel.

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-163
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

User Readiness Checklist

The following is a list of required or recommended steps to assist Full
Participants (Schools, Third Party Servicers, and Software Providers) with
implementing the COD System for the 2002-2003 Direct Loan and Pell
Grant Programs.

# Contact FSA indicating interest to be a Full Participant for COD

# Reference appropriate sections of the COD Technical Reference
Document to modify school or software provider applications to create
Common Record files in XML format
# Complete School Testing – Phase I: Communication Testing
# Sign-up for School Testing – Phase II: Common Record Manual
Verification
# Complete School Testing – Phase II: Common Record Manual
Verification
# Sign-up for School Testing – Phase III: Application Testing
# Complete School Testing – Phase III: Application Testing
# Obtain the Common School ID (Entity ID) from FSA (reference
Common School ID section within the Implementation Guide for more
information).
# Communicate your Common School ID (Entity ID) to your software
vendor, third-party servicer, or state agency, as needed.
# Complete COD Security Administrator Setup Process (reference the
“COD User ID Setup for Website” announcement on IFAP for more
information).
# Establish User IDs within organization for access to the COD website
(to be completed by the organization’s Security Administrator).
# Establish Rules of Behavior documents related to use of the COD
System
# Access COD Website to update School Processing options, as needed
(reference School Processing options within the Implementation Guide
for more information).

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-164
DRAFT–- FOR DISCUSSION PURPOSES ONLY
 DRAFT – FOR DISCUSSION PURPOSES ONLY

# Attend Full Participant Conference Calls

# Reference relevant sources of information, including:
o COD Technical Reference Document
o XML Schema for the Common Record
o Frequently Asked Questions about COD
o Local, regional and/or national conferences
o FSA Spring Training
o COD Full Participant Website

June 2002 (2002-2003) COD Technical Reference Implementation Guide

Version 3.4 COD Technical Reference Document for Full Participants I-165
DRAFT–- FOR DISCUSSION PURPOSES ONLY