Attachment J-3 COD TIVOD Business Requirements 113023.pdf

Version 1.0 1 11/30/2023

Controlled Unclassified Information (CUI)

Common Origination & Disbursement (COD) Business Requirements

Version 1.0 ● 11/30/2023

Business Requirements – Origination & Disbursement (COD)

Version 1.0 2 11/30/2023

Controlled Unclassified Information (CUI)

Table of Contents

SECTION 1. INTRODUCTION

1.1. OVERVIEW

1.2. SCOPE

1.3. COD CURRENT FUNCTIONAL STATE

1.3.1. Loan & Grant Processing

1.3.2. Web Support

1.3.3. Reports and Correspondence

1.3.4. Interface Support

1.3.5. Front-Office Support

1.4. COD TECHNICAL ARCHITECTURE

1.5. COD DATABASES

1.6. DEFERRED REQUIREMENTS – DATA MAPPING

SECTION 2. REFERENCE DOCUMENTS*

SECTION 3. LOAN & GRANT PROCESSING

3.1. INCOMING RECORD PROCESSING

3.1.1. Common Submission and Receipt

3.1.2. Batch Submission

3.1.3. Online Submission

3.1.4. Common Record Editing

3.2. COD PROCESSING

3.2.1. School Eligibility Verification

3.2.2. Student Eligibility Verification

3.2.3. Originations Processing

3.2.4. Credit Check Processing

3.2.5. Disbursement Processing

3.2.5.2. Direct Loans and TEACH Grant Discharges and Payments to Servicer

3.2.6. Responses

3.3. SERVICER ALLOCATIONS, LOAN DISTRIBUTION, AND PERSON-SERVICER RELATIONSHIPS

3.4. FINANCIAL PROCESSING

3.4.1. Student-Level Financial Processing

3.4.2. School-Level Financial Processing

3.4.3. Special Pell Grant Processing

3.4.4. Common Record Structure

SECTION 4. CAMPUS BASED

4.1.1. Fiscal Operations Report and Application to Participate (FISAP)

4.1.2. Forms and Waivers

4.2. PERKINS

4.2.1. Perkins (Distribution of Assets Process)

4.2.2. Perkins Program – System Interfaces

4.3. AUTHORIZATION AMOUNTS

4.3.1. Tentative Awards

4.3.2. Final Awards

4.4. MANAGE TRANSACTIONS:

4.4.1. Recalculation:

4.4.2. Reallocation

4.4.3. Supplemental

4.4.4. Distribution of Supplemental Campus-Based Funds

4.4.5. Reporting

4.4.6. Closeout:

Version 1.0 3 11/30/2023

Controlled Unclassified Information (CUI)

4.4.7. Manual Adjustments

4.4.8. FMS & G6:

4.4.9. Hold Schools:

4.5. CAMPUS BASED AWARDING

4.5.1. Campus Based Communications

4.5.2. Comment Log (ComLog)

4.5.3. Perkins Default Reduction Assistance Program (DRAP)

4.5.4. Teacher Cancellation Low-Income (TCLI) Directory

SECTION 5. FUNDS MANAGEMENT

5.1.1. Current Funding Level (CFL) Processing – Initial CFL and CFL Adjustments

5.1.2. CFL Adjustment

5.1.3. FMS CFL Updates

5.1.4. Institution’s Funding Update

5.1.5. Drawdowns and Funding Controls

5.1.6. Funds Drawdown

5.1.7. Funding Controls

5.1.8. Substantiation

5.1.9. Closeout

SECTION 6. WEBSITE OVERVIEW - COD

6.1. PURPOSE AND OBJECTIVES

6.2. SCOPE

6.3. GENERAL INFORMATION

6.4. WEBSITE BUSINESS REQUIREMENTS

6.4.1. Website General Requirements

6.4.2. Search Functionality

6.4.3. Create Record(s)

6.4.4. Request Record(s)

6.4.5. Update Record

6.4.6. General Information

6.4.7. Online Workflows

6.4.8. School Financial Information and Program Award Year Specific Information

6.4.9. Reporting

6.5. RETURN OF TITLE IV (R2T4)

6.5.1. Post-Withdrawal Disbursement Tracking

6.5.2. Return of Title IV (R2T4) Tool

SECTION 7. REPORTS AND CORRESPONDENCE

7.1. PURPOSE AND OBJECTIVES

7.2. SCOPE

7.3. REPORTS

7.4. DATA REPOSITORY / WAREHOUSE

7.5. BUSINESS INTELLIGENCE AND REPORTING TOOL

7.6. REPORT GENERATION PROCESS

7.6.1. Standard Reports

SECTION 8. SYSTEM INTERFACES

8.1. COMMON SERVICING INTERFACE REQUIREMENTS

8.2. END TO END SYSTEM BALANCING

8.3. SCHEDULE A, B, AND C REPORT REQUIREMENTS

8.4. ADDITIONAL COMMON SERVICING INTERFACE REPORTS

8.5. COMMON APPLICATION INTERFACE

8.6. APPLICANT DOCUMENT PROCESSING

8.6.1. Master Promissory Notes (MPNs)

Version 1.0 4 11/30/2023

Controlled Unclassified Information (CUI)

8.6.2. TEACH Agreement to Serve or Repay (TEACH Agreement)

8.6.3. Endorser Addenda

8.6.4. Direct PLUS Loans Requests/Applications

8.6.5. Direct Loan and TEACH Grant Counseling

8.6.6. Informed Borrowing (Annual Student Loan Acknowledgment)

SECTION 9. ANNUAL ROLLOVER SUPPORT (NEW AWARD YEAR SET-UP)

SECTION 10. FRONT OFFICE SUPPORT

10.1. BUSINESS MANAGEMENT SUPPORT

10.2. TECHNICAL OPERATIONS SUPPORT

10.3. ADMINISTRATIVE FUNCTIONS

Version 1.0 5 11/30/2023

Controlled Unclassified Information (CUI)

Section 1. Introduction

1.1. Overview

In April 2002, the Common COD(COD) System was launched to reengineer the process of delivering and reporting Federal Pell Grants and Direct Loans into a common COD process.1 Although federal student aid loans and grants have unique operating characteristics and requirements, providing a common business process and technology platform significantly eased the burden for school Financial Aid Administrators. As a result, the COD process provided educational institutions a simplified and shared process for requesting, reporting, and reconciling Title IV funds. The current COD System supports most federal student aid programs (Pell Grants, Iraq & Afghanistan Service Grants (IASG), Teacher Education Assistance for College and Higher Education (TEACH) Grants, Campus Based programs (Federal Supplemental Educational Opportunity Grants, Federal Work Study, Perkins) and Direct Loans.

1.2. Scope

The Contractor shall propose their technical solution to COD requirements in two volumes:

1. Volume 1: Current-state Operations and Maintenance – the Contractor shall propose their service model for operation and maintenance of COD and shall include Information Technology Infrastructure Library (ITIL) based processes, staffing model, and integration with Federal Student Aid (FSA’s) IT systems’ change, release, SDLC (Software Development Life Cycle), and LMM (Lifecycle Management Methodology) processes. In this volume, the Contractor shall propose industry best practices for cloud-based operations and maintenance.

O&M activities shall be performed to support COD, which includes but is not limited to, high level system control access; support for system development, testing, and production environments; change request and technology and application enhancement support and management; integrated configuration management of COD and all its related components; system processing; service disruption prevention and mitigation; and related dashboards and reporting.

The Contractor shall propose a total number of service hours to fulfill the 1,000 or so data requests per annum, support for data governance (metadata and business glossary management), and support for publishing open data to the FSA Data Center website. The total number of proposed service hours shall be a “bucket” of hours used by FSA to draw down from during the contract period. The Contractor shall note these service hours are not for use in standard operations and maintenance activities of COD, which include infrastructure, data interfaces, application management, user access management, security services, among other services mentioned in this document as well as in the Minimum Information Technology Contract Requirements (MITCR) document.

2. Volume 2: New Capabilities Development – FSA requires new system development and enhancements from time to time. The Contractor shall be required to analyze these requirements for impact on other FSA systems, infrastructure, operations and maintenance, and cost. The Contractor shall also propose a technical solution, budget, a project manager, and schedule to meet those requirements. The Contractor shall also ensure any new development or enhancement aligns with FSA’s Target State Architecture and FSA Branding Guidelines. In this volume, the Contractor shall propose best practices and methodologies for managing and delivering new systems development or enhancement requirements from FSA.

Version 1.0 6 11/30/2023

Controlled Unclassified Information (CUI)

1.3. COD Current Functional State

The FSA COD Functional Categories, shown in Figure 1-3, breaks down the functional components of the COD environment for ease-of-understanding and organizing the COD Business Requirements.

This functional architecture comprises multiple functional categories (horizontal groupings) broken down into functions (vertical groupings). Each function is supported by multiple modules (boxes). Implementation of business functionality via each module entails a combination of systems and activities supported by appropriate personnel.

The detailed business requirements for each module are provided in subsequent sections and labeled above.

Figure 1-3 (below) is provided to give the Contractor an understanding for the data sources, flows, structures, architecture, tools, and functionality, which, in effect, are our current-state requirements. The Contractor shall use this figure along with the information contained in this document to understand and develop an innovative, efficient, and reliably secure technical proposal.

For the Direct Loan, Pell Grant, IASG Grant, TEACH Grant, Campus Based and other programs as required, the COD System shall accept and process originations and disbursements for current and active (open or closed) Award Years along with any related promissory notes and TEACH Agreements, perform person (students, parents, endorsers) level, school level, award, and disbursement editing, conduct credit checks for Direct PLUS Loans, and interface with other Federal Student Aid external systems. The COD System shall process, perform edit checks on and accept or reject origination and disbursement data received in Common Record Documents from schools/third party servicers and COD Web. The COD System shall send responses back to schools regarding the data submitted and any edits failed during processing. The COD system shall store all documents processed and the corresponding responses to those documents and allow COD Web users access to the detailed information within each document.

The data processed shall be stored and viewable via the COD Web. The COD system shall log and retain audit trails on data received and processed, including changes to and from, source/user and date/time.

Figure 1-3

Version 1.0 7 11/30/2023

Controlled Unclassified Information (CUI)

As outlined in Figure 1-3 above, the scope of COD Processing includes, but not limited to, the operations and maintenance for the following:

1.3.1. Loan & Grant Processing

• Incoming Records (Section 3.1), which consists of the following methods of submitting records for processing by the COD System:

o Batch Submission – refers to the batch-mode submission of origination and disbursement records to the COD System for processing. Batches are submitted using an eXtensible Markup Language (XML) based Common Record. Most commonly, schools use commercial software contractor applications, custom software, FSA-provided software, or third-party servicers for exchanging data with the COD System through the Student Aid Internet Gateway (SAIG).

o COD Web Submission – refers to the web module providing schools, COD Customer Service Representatives (CSRs) and/or FSA staff an interface to the COD System and the ability to submit origination and disbursement records. The interface also allows schools to create and submit origination and disbursement records and corrections in a Common Record format for processing.

o Paper Document Submission – refers to the function receiving signed documents including, but not limited to, Master Promissory Note (MPN), Endorser Addendums, and Campus-Based signature pages by mail, images and stores the images, and submits data elements from the document to the COD System linking to the origination record. The Contractor shall store original documents in a fireproof vault for retrieval and later transfers the documents to permanent storage at a Federal Records Center (FRC). The Contractor also prints and mails hard copies of the electronic Master Promissory Note (eMPNs) at a borrower’s request.

• COD Processing (Section 3.2) – includes “front-end” functions of ensuring appropriate record format, determining school, program, and student eligibility, processing both real-time and batch COD record, responses as well as the related functions of ensuring all prerequisites are met (e.g., MPNs are signed, TEACH agreements are signed, etc.). This function also includes credit check processing for applicants of PLUS Loans as well as the notifications and responses returned to schools and applicants. COD records are submitted to COD using an XML-based Common Record. Most commonly, schools use commercial software contractor applications, custom software, FSA-provided software, or third-party servicers for exchanging data with the COD System through SAIG.

• Servicer Allocations, Loan Distribution and Person-Servicer Relationships (Section 3.3) - includes distributing “booked loans & TEACH Grants” to Federal Servicers using an adjustable algorithm. A loan/TEACH Grant is considered booked when the COD System has an accepted award/origination, a linked Master Promissory Note/TEACH Agreement-To-Serve or Repay, and at least one funded disbursement record. The interface includes but is not limited to:

o Loan Activity File (COD System to Federal Servicer): Includes new loans, new disbursements for existing loans, disbursement adjustments, disbursement date changes and non-financial changes such as but not limited to name changes, award amount, grade level, etc.

o Servicer Activity File (Federal Servicer to COD System): Includes transfer notifications, discharge transactions and payment to servicer transactions.

Note: See Common Servicing schema, Additional Servicing Support Guide and Common Servicing Layout documents for more information.

• Financial Processing (Section 3.4) - includes Student Level Processing, School Level Processing, Special Pell Grant, other Grant Processing and Pell Administrative Cost Allowance (ACA), Processing, and running various global jobs.

• Campus Based Programs (Section 4) – includes the administering the disbursement of individual awards, administrative management, and financial tracking of funding for the Federal Supplemental

Version 1.0 8 11/30/2023

Controlled Unclassified Information (CUI)

Educational Opportunity Grant (FSEOG), Federal Work Study (FWS), and the Federal Perkins Loan programs.

• Funds Management (Section 5) - includes establishing initial current funding levels, adjusting current funding levels, managing funding controls, supporting school substantiation of funds received using actual disbursement and cash data, completing reconciliation and school closeout activities, closing-out funding for each award year, and processing extensions to data submission (closeout) deadlines. It also includes easy access to and retrieval of data in an archive system.

1.3.2. Web Support

• COD Web (Section 6) - includes the capabilities required to support the needs of key participants

(namely schools, CSRs, FSA staff) in the COD process for a web-based interface to manage their activities. Activities are, included but not limited to, viewing school financials, accessing documents submitted through StudentAid.gov, running reports and queries, and entering disbursement information.

1.3.3. Reports and Correspondence

• Correspondence (Section 7.6.1.3) - includes letters and other notifications to persons and schools provided in various formats depending on type, including but not limited to email, paper (mail), Hypertext Markup Language (HTML), SAIG text message, and broadcast message formats. Electronic correspondence for certain programs is also available on StudentAid.gov in Portable Document Format (PDF) format. SAIG Message Classes are assigned to define the type (i.e., category, program, and/or award year of electronic data being sent to or received from FSA systems.

• Reporting Module (Section 7.2, 7.3) - captures the scope of reporting requirements for all stakeholders and includes standard pre-defined reports and access to a data warehouse of production-level data and analytical tools for ad hoc analyses and reporting

• COD Operations Portal (Section 7.6.1.2) - covers the need for a central repository for all working documents, contract deliverables, and other operational products to ensure the efficient and effective operations of the COD environment and oversight by FSA.

1.3.4. Interface Support

• System Interfaces (Section 8) – high-level overview of the interfaces COD exchanges data with to support overall functions.

o Common Servicing Interface Requirements (Section 8.1) - includes the transfer of “booked loans” (i.e., loans ready for servicing) and TEACH Grants to servicers, based on FSA’s distribution algorithm, and repayment applications.

o Common Application Interface Processing (Section 8.5)- includes sending completed Income Driven Repayment and Loan Consolidation applications to the Federal and Commercial (Income Driven Repayment (IDR) only) servicer

• Applicant Document Processing (Section 8.6) – includes information on the integration of the COD system must accept data for applications aid recipients may have to complete prior to a school originating or disbursing aid. Information is also provided regarding the various checks the COD system must perform to allow for origination and disbursement to occur.

Version 1.0 9 11/30/2023

Controlled Unclassified Information (CUI)

1.3.5. Front-Office Support

• Business Management Support (Section 10.1) - includes a variety of business activities and support services to ensure the secure, efficient, and effective operation of the COD process and compliance with applicable policies, processes, and procedures.

• Technical Operations Support (Section 10.2) - provides various technical support, service, and technology management functions to ensure all COD System components are functioning correctly.

Technical Operations Support covers system O&M, configuration, infrastructure, systems enhancement, and performance monitoring and capacity planning.

• Administrative Functions (Section 10.3) - includes administrative functions to support testing efforts, procedure documentation, website outage and access management.

1.4. COD Technical Architecture

1. Web: The primary function of COD is to process loan and grant records received from schools. COD performs a variety of important processes key for processing, storing, and reconciling financial aid data of federal student loans. COD Web is a public facing web application hosted in Amazon Web Services (AWS) GovCloud. The primary users are schools. The application is used to perform tasks such as reviewing school financial information and reports, perform award and disbursement management, view completed documentation, and verification of borrower information

Version 1.0 10 11/30/2023

Controlled Unclassified Information (CUI)

2. Batch: Schools submit groups of student records to COD in a file called a Batch. A batch can consist of origination records, change records, and disbursement records and will have a unique Document ID number. A batch may, and generally does, contain multiple awards for multiple students. Batches could also contain multiple award years and multiple reporting and attended school ID's. The school submits these batch files/records via SAIG mailbox. A receipt is generated once the COD system has validated the batch file received via SAIG. Once COD processes a batch from a school, a Response will be sent back to the school. The Response details the processing or rejection of the common records contained in the batch (includes reason for rejection).

3. COD-Digital Customer Care (DCC) Servicer Lookup Interface: The COD system created and secured an internet facing service over Hypertext Transfer Protocol.

4. Hypertext Transfer Protocol Secure (HTTPS) to be consumed by the Call Center Backbone (CCB) telephony sites. The FSA Partner and School Relations Center telephony backbone Interactive Voice Response (IVR) (in support of DCC) will identify the phone number of the caller via Automatic Number Identification (ANI), and then invoke the COD service. The provided phone number on service invocation will be used within the COD service to identify the associated customer. Once identified, the servicer of the customer will be provided back to the IVR.

5. Alerting Services: (xMatters) COD makes use of the xMatters Software as a Service (SaaS) solution for operations alerting and alert escalation to COD support personnel. xMatters receives alerts from the COD system and distributes them to appropriate personnel based on predefined rules. xMatters does not contain any sensitive data.

6. Print Input Services: The Print Input Services application supports the scanning and data entry for paper forms received by mail from borrowers. The system maintaining the data for this processing is provided by Conduent as part of our document management solution. Inbound paper documents arrive at a facility and then scanned and double key inputted into a system hosted at a document management site.

7. Print Output Services: The Print Output Services application supports the printing and mailing of correspondence to schools and borrowers. The processing, printing, enveloping, and mailing occur at the Integrated Mail sites. Paper document printing and mailing is performed at the Integrated Mail facilities in Milwaukee, Wisconsin. They receive data feeds from COD and then print and mail them to borrowers and schools.

8. Application: The COD architecture enforces isolation between execution and data components as well as isolation between production and preproduction environments using Virtual Private Clouds (VPC). A VPC is a logical portion/section of the AWS cloud which is used to create isolation/separation from other VPCs.

Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) components in AWS are deployed into a VPC.

9. Access: The Access and Identity Management System (AIMS) interface is an indirect browser-based interface utilizing Security Assertion Markup Language (SAML) for authentication of COD Web users. AIMS is hosted at the FSA data center and is a web service designed to authenticate web users logging into the COD Web website. Calls to AIMS support user authentication, SAML assertion renewal, and enterprise logout

10. Reporting: Cognos is a Commercial-of-the-Shelf (COTS) product COD utilizes for reports. End user access for Cognos site authentication will be via single sign-on (SSO) from the COD site (https://cod.ed.gov). Users will be able to access the COD Instance of Cognos only after authenticating to the COD Web, access to Cognos for users will not be available without entering the COD Web. Authorization within the Cognos site is driven by their role and group assignment within the Cognos Access Manager Lightweight Directory Access Protocol (LDAP). COD is hosted in AWS GovCloud using Linux Red Hat with Oracle as the database, and Cognos as the reporting tool (accessible via cod.ed.gov).

https://cod.ed.gov/

Version 1.0 11 11/30/2023

Controlled Unclassified Information (CUI)

1.5. COD Databases

The Contractor shall support multiple databases supporting COD business functions. The following table provides the database specifications supporting the COD System.

COD Database Support

Database Type Database Name Prod/ Pre-Prod Storage Capacity

Oracle Production PROD 74.05 TB

MySQL Production PROD 165 GB

PostgreSQL Production PROD 310 GB

SQL Server Production PROD 500 GB

COD Interfaces:(COVERED IN SECTION 8)

1.6. Deferred Requirements – Data Mapping

FSA is in the process of designing and implementing an Enterprise API Management solution. The contractor’s solution ingress/egress API’s (Exposing APIs for use externally and/or features using APIs provided by other FSA systems) shall integrate/use FSA’s Enterprise API Management solution. The contractor’s solution for APIs shall conform to the API Enablement Guide at go-live of the initial task order.

See attachment: API Gateway Enablement Guide v1.6 and any subsequent versions for more details.

• FSA API Management Solution envisions the following capabilities:

o API Specification Repository capturing full API specifications enabling machine readable API specification that can be used in FSAs DevSecOps tool chain and infrastructure as code capacities.

o API Developers portal allowing developers to discover and leverage FSA APIs o API Governance enabling FSA to manage and coordinate API changes across the organization.

o Gateway standards for all ingress and egress access points. Specific Gateway technologies will be determined later.

o API Management solution standards for securing and monitoring internal APIs.

o Automated deployment and configuration of API’s through DevSecOps tool chain.

o All ingress and egress APIs interacting with FSA systems shall follow FSA’s authentication standards. All access tokens will be managed by one of FSA Enterprise Access Token managers (AIMS, PAS, System to System).

Version 1.0 12 11/30/2023

Controlled Unclassified Information (CUI) o Security rules and policies for ingress and egress access to APIs shall be externalized and available to the API Management solution for enforcement. Those policies shall be under change management and subject to governance.

o All APIs exposed to Web Sites or Mobile apps will protect those API using FSAs Enterprise API Management standards.

• The contractor shall collaborate with FSA to establish API Security policies externalized and managed in the API Management solution. The contractor can replicate those security policies in their solution but must coordinate with FSA so those rules can be centrally managed, applied, and informed access APIs contractor ingress and egress APIs through FSAs API Management Solution.

• The contractor shall develop and implement FSA-approved protocol specification for data exposure from systems/applications in the vendor IT environment to downstream operational components and data lake in FSA’s IT environment.

o Protocol specification must encompass data governance protocols in addition to integration and interoperability protocols o The contractor shall maintain documented lifecycles and processes for how data flows across its processing platform, define crosswalks for data across multiple systems, and ensure IT solutions are configured to meet FSA’s data integration needs o The contractor shall support data migration and ingestion of historical loan data into FSA-approved destinations, to enable operational reporting and longitudinal analysis involving historical data.

o The contractor shall support data migration and ingestion of relevant third-party data into FSA-approved destinations, to enable the third-party data to be incorporated into operational reporting and analyses.

• DEFERRED REQUIREMENT: The contractor shall enable real-time data services with built-in APIs to provide a universal access method independent of language specific integration, greater flexibility in implementation tools, and capabilities to perform additional business logic on the data, including formatting, standardization, and enrichment.

• DEFERRED REQUIREMENT: The contractor shall ensure proper metadata management to include the following:

o System functionality to capture and store: (a) audit trails of when core, reference, and unmatched data was captured and updated; (b) record of attribute changes; and (c) definitions of data elements, locations, and types o Business capabilities to query, search, and report on metadata

• DEFERRED REQUIREMENT: The contractor shall ensure data-related tools and solutions properly meet all applicable data governance requirements which may include, but are not limited to, the following:

Version 1.0 13 11/30/2023

Controlled Unclassified Information (CUI) o Data synchronization and availability – Integrate with upstream source systems and downstream consuming systems either in batch ETL or API. (timeliness, frequency, service-level agreements) o Data quality standards – Ensure that data is complete, accurate, and consistent. Profile, cleanse, and monitor data on an on-going basis o Data conformity and interoperability – support common keys, industry standards, common object model to enable longitudinal analysis.

o Data privacy – create processes including any required encryption, data masking and tokenization, etc., with a particular focus on practical PII management without overly conservative access limitations.

o Data change management – maintain a change management process to make changes to data (updates vs initial creation, transactional, exception handling, etc.)

• DEFERRED REQUIREMENT: The contractor shall provide FSA a data dictionary of data stored on the contractor’s systems.

o The contractor shall provide FSA a data dictionary for all data housed on a system’s platform, including ancillary services/sub-contractors accessing data relating for FSA Customers.

o The data dictionary shall include the following:

Field name, field definition (in simple to understand terms), valid values for the content, field format/length for data stored in the system (i.e. databases, access databases, tables, and spreadsheets).

Specialized Data including, but not limited to:

• Imaged data:

o Collateral materials, specifically promissory notes o Old/Legacy data o Other imaged data o Forms and other documents provided either by or to the aid recipient o Call recordings

• Historical transactional data for all actions (financial and non-financial) o The contractor shall provide a catalog of their procedures and training materials.

o The contractor shall provide the deliverables in this requirement to FSA on an annual basis (or upon request) in an excel workbook.

Version 1.0 14 11/30/2023

Controlled Unclassified Information (CUI)

Section 2. Reference Documents*

DO CU ME NT T ITLE** LIN K O R ATTA CH ME NT

Alt Doc of Income Layout Attachment 10 Application Schema v1.6 Attachment 11 COD Common v 1.5 Attachment 12 Common App Interface Support Guide Attachment 13 Common Application Schema Attachment 14 Common Servicing Interface Support Guide Attachment 16

Common Servicing Core Main Review Attachment 17 Common Servicing Schema File Layout Attachment 18 COD Technical Reference https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10- 26/2023-2024-cod-technical-reference-may-2023-update

COD Resources https://cod.ed.gov/cod/codResourceList.action Campus Based Resources https://cod.ed.gov/cod/campusBasedResources.action COD Technical Reference, Vol. 6, Section 7 COD Reports https://fsapartners.ed.gov/sites/default/files/2021- 12/2223CODTechRefVol6Sec7Reports.pdf https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10-26/2023-2024-cod-technical-reference-may-2023-update https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10-26/2023-2024-cod-technical-reference-may-2023-update https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10-26/2023-2024-cod-technical-reference-may-2023-update https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10-26/2023-2024-cod-technical-reference-may-2023-update https://fsapartners.ed.gov/knowledge-center/library/system-technical-references/2022-10-26/2023-2024-cod-technical-reference-may-2023-update https://cod.ed.gov/cod/codResourceList.action https://cod.ed.gov/cod/codResourceList.action https://cod.ed.gov/cod/campusBasedResources.action https://cod.ed.gov/cod/campusBasedResources.action https://fsapartners.ed.gov/sites/default/files/2021-12/2223CODTechRefVol6Sec7Reports.pdf https://fsapartners.ed.gov/sites/default/files/2021-12/2223CODTechRefVol6Sec7Reports.pdf

Version 1.0 15 11/30/2023

Controlled Unclassified Information (CUI)

Section 3. Loan & Grant Processing One major business process for COD is Loans and Grants Processing, which generally involves the applicant, the school’s financial aid office (versus the Funds Management process which is generally handled by the school’s business office), and the COD System to process loans and grants. As outlined in Figure 1-3, Loans and Grant processing includes activities covering the submission and results for incoming records to the system (section 3.1), COD system processing for federal loan and grants (Sections, 3.2, 3.3, 3.4, 4, 5), and various reporting and correspondence activities (section 7).

The key steps involved in Loans and Grants Processing are described as follows (note: FSA’s business rules provide for some variation in the sequence of these steps):

• Determine Financial Aid – based on information provided in the Institution Student Information Record (ISIR), a school participating in Title IV programs offers a financial aid award package may include federal loans and/or grants to a prospective or current student.

• Receive/Accept Financial Aid Package – the student accepts the financial aid package best suited to his/her needs. Once the financial aid package is accepted, the school can determine the disbursement schedule, which is later created at the time of origination for loans.

• Provide Commitment – in the meantime, the student enrolls in school as required. Before aid is disbursed to the student, he/she must sign any commitments depending on the type of financial aid accepted. Commitments can be Promissory Notes for loans, an Agreement-to-Serve or Repay (Agreement) in the case of a TEACH Grant, and other commitments such as entrance counseling for Direct Loans and Initial and Subsequent Counseling completion for TEACH Grants.

• Submit Origination and Disbursement Records to FSA – the school’s Financial Aid Office submits origination and disbursement records to the COD System for processing.

• Receive Payment –the school draws down the funds and disburses these funds to the students in accordance with regulatory requirements. Schools in good standing may draw down and disburse funds before origination records are received by the COD System.

• Report Actual Disbursements/Submit Changes and Adjustments – Schools submit records of actual disbursements and changes and/or adjustments to previously accepted data.

• Distribute Loans for Servicing – loans ready for servicing (i.e., loans meeting certain criteria to become “booked loans”) are then distributed by the COD System to approved Servicers based on an algorithm provided by FSA. This algorithm may be adjusted by FSA at any time.

3.1. Incoming Record Processing

The COD System shall receive, and process origination and disbursement records submitted by schools participating in Title IV programs. A high-level process flow for processing common records is captured in Figure 3-1 below and are explained throughout this document.

Figure 3-1: High Level Common Record Processing Flow

Common Record

Submission

Common Record Receipt

Common Record

Processing

Common Record Editing

Response Notification

Version 1.0 16 11/30/2023

Controlled Unclassified Information (CUI)

3.1.1. Common Submission and Receipt

The COD System shall accept Common Records in two ways:

• Batch Submission of records sent via FSA’s SAIG to the COD mailbox. The Enterprise Service Bus (ESB) shall periodically sweep the COD mailbox and transmit the Common Record data to the COD System for processing.

• Online Submission – An authorized user manually enters Common Record data via the COD Web, which is then converted into an XML document and transmitted in real-time to the COD System for processing.

• For each Common Record received, the COD System shall generate appropriate Responses after the processing of the Common Record and shall send them back to the submitting entity, as Common Records, to communicate the results of the processing and action(s) to be taken, if any.

3.1.2. Batch Submission

Common Records can be submitted to the COD System in batch mode using XML document files transmitted to COD’s Student Aid Internet Gateway (SAIG) mailbox. The Enterprise Service Bus (ESB) performs periodic sweeps of COD’s SAIG mailbox and transmits the COD Common Record files to the COD System.

The SAIG (Batch) Interface is used by schools and third-party servicers through their custom and commercial software applications to submit Common Record Documents. They also receive Common Record responses and acknowledgements communicating processing results back from the COD System through SAIG.

3.1.3. Online Submission

The COD Web shall provide a centralized site for schools’ Financial Aid Administrators (FAAs), Third-Party Contractors, FSA staff, CSRs, and other authorized users to submit award and disbursement data for federal student aid programs. The COD web shall serve as a submission avenue for updating the COD System.

When a user manually enters data online via the COD web site, the COD Web site shall create a Common Record document for data entered online and send it directly to the COD System.

Examples of COD web submissions include:

• Origination records

• Disbursement Records

• Web Credit Checks

Note: The above list is not meant to be exhaustive, and FSA requires the COD Web to remain flexible and scalable to accommodate new and discontinued services.

The starting point for COD Processing is the receipt of incoming origination and disbursement data. The following sections provide the business requirements for receiving incoming origination and disbursement data in the correct record format, verifying the eligibility of the school to submit such records to FSA, and confirming the eligibility of the student to receive the intended federal student aid.

3.1.4. Common Record Editing

The COD System shall perform various edits on the Common Record data received including Document, Entity/School, Person/Student/Parent, Award, and Disbursement information to determine its validity and suitability for processing. Three edit modes shall be supported:

Version 1.0 17 11/30/2023

Controlled Unclassified Information (CUI)

• Correction –

• For Direct Loans (DL) and TEACH data, the COD shall automatically make corrections on the data, process the record, and send a Response record back to the submitting entity indicating the corrections made.

• For Pell Grant data by default, the COD System shall automatically make corrections on the data, process the record, and send a Response record back to the submitting entity indicating corrections made. Pell Grant data corrections may include adjusting the amount of the Pell Grant award to the student. From the School Level Options in COD Web, schools can elect to have Pell Grant records rejected instead of having them automatically corrected by the COD System.

• Warning – The COD System shall send a Response record to the submitting entity indicating a warning and relevant information but shall continue to process the data.

• Reject – The COD System shall reject a Common Record with invalid/unacceptable data and shall send a reject Response record to the submitting entity. Rejected records are stored and held by the COD System pending corrective action from the submitting entity. Common Records can be re-submitted via batch or COD Web to correct rejected data.

3.2. COD Processing

3.2.1. School Eligibility Verification

COD receives the daily school file and creates or updates information on schools (domestic and foreign) eligible to participate in Title IV programs.

The COD System shall use the school information resulting from processing the school file to verify the eligibility of the school to originate and disburse loans and grants. Eligibility checks are done at the Title IV and individual program levels. If the school is not eligible, the system shall reject the record and return a Response record indicating the reject reason.

3.2.2. Student Eligibility Verification

When processing Common Record Documents, the COD System shall use the information resulting from processing the Free Application for Federal Student Aid (FAFSA) Processing System (FPS) demographic data files to validate the student’s eligibility to receive financial aid as determined by FPS. The COD System shall use data from FPS to verify student eligibility, including, but not limited to social security number, date of birth, and name match; PELL eligibility flag; and others.

If the student is deemed ineligible, the COD System shall reject the award and disbursement data submitted for the student and return a Response record including the reject reason.

3.2.2.1.Student Eligibility Interfaces FAFSA Eligibility Determination FPS processes a student’s FAFSA and determines a student’s aid eligibility and Student Aid Index (SAI). FPS then sends the results from the processed FAFSA to the student in the Student Aid Report (SAR) and sends an ISIR to the schools the student indicated on the FAFSA.

FPS also sends the COD System a daily demographic data file which contains applicant eligibility information. The COD System shall process and store the information from the files to be used in student eligibility validation. The interface to FPS is specified in the FPS Demographic File Interface Document.

The COD System shall create, when applicable, a new customer/person record in the COD Database because of processing the person records included in the FPS Demographic File.

Version 1.0 18 11/30/2023

Controlled Unclassified Information (CUI)

In addition, the COD System maintains an Application Programming Interface (API) to enable the transmission of student-level FWS wages for inclusion in the SAI calculation and ISIR.

3.2.3. Originations Processing

The COD System shall process school origination records establishing a new loan or grant award or update an existing award for any of the Direct Loan, Pell Grant, IASG Grant, TEACH Grant, Campus Based Programs, and other programs as required.

The COD System shall perform award edits on pertinent origination record fields, such as but not limited to, the student’s annual award amount, enrollment and loan period dates, Student Eligibility Codes including any Ability to Benefit status to receive Title IV, and COA (Cost of Attendance) to ensure they are complete, correct, and conform to FSA’s guidelines.

In addition to person and award data, DL and TEACH origination records must contain anticipated/pending disbursement data. If the origination record is accepted, the COD System shall check if the award is for an existing or new person, or whether the award already exists. Accordingly, it shall create or update the person and award data records in the COD Database.

3.2.3.1.Direct Loans Originations When processing a Direct Loan award origination, the COD System shall perform edits to validate award information is complete, correct and conforms to FSA’s guidelines. The COD System shall perform the following, including but not limited to:

• Process origination and disbursement records received from eligible domestic and foreign schools.

• If the origination record passes all the edits and it's accepted, check if the award is for an existing or new student, or whether the award is already on file. Accordingly, it shall create or update the student/parent and award data records.

• Send loan servicers any changes to the student/parent award record made after the loan has been booked.

• Validate the grade level and dependency status is valid for the loan type submitted.

• Require schools report anticipated and/or actual disbursements equaling the total loan amount approved of the loan when creating a new loan.

• Require an origination record has a minimum of 2 substantially equal disbursements unless the school is eligible to do single disbursements.

• Validate disbursement dates are within a school's eligibility period.

• Accept origination of new DL awards from foreign schools if the school has lost eligibility but has been granted a processing extension if the student has one or more previous DL awards with an actual disbursement from the same attending school.

• Validate the student is not over the annual loan limits based on their grade level.

• Attempt to link the loan to MPN on file based on FSA linking criteria.

• Notify applicable school(s) when a loan successfully links to an MPN, or when the status or expiration changes using the Common Record or Promissory Note response.

• Generate a Disclosure Statement package based on the school option when the origination record passes all the edits and it's accepted. The COD System shall also integrate with StudentAid.gov to provide the Disclosure Statement correspondence to display to users.

3.2.3.2.Direct PLUS Loan Originations Graduate/Professional students are eligible to receive Direct PLUS Loans (Grad PLUS Loans). Parents of dependent undergraduate students are eligible to receive Direct PLUS Loans (Parent PLUS Loans).

Version 1.0 19 11/30/2023

Controlled Unclassified Information (CUI)

When processing a Direct PLUS Loan award origination, the COD System shall perform edits to validate award information is complete, correct and conforms to FSA’s guidelines. The COD System shall perform the following, including but not limited to:

• Determine if the loan is a Parent PLUS Loan or a Grad PLUS Loan based on whether the student and the borrower are different or if the student and borrower are the same.

• NOT perform any loan limits when processing Direct PLUS Loan records.

• Verify a valid credit check is on file or initiate a new credit check. See section below additional information on

Credit Check Processing (Section 3.2.4).

• Prevent a school from disbursing a Direct PLUS Loan when all the credit requirements have not been met.

Credit requirements are met when the following are on file: A credit check with an approved decision or a credit check with a denied decision and an approved endorser and completed PLUS Credit Counseling or a credit check with a denied decision and an approved credit appeal and completed PLUS Credit Counseling.

• NOT link a PLUS loan to a PLUS MPN if the credit is denied unless there is an approved appeal or endorser linked.

3.2.3.3. TEACH Grants Originations

When processing a TEACH Grant award origination, the COD System shall perform edits to validate award information is complete, correct and conforms to FSA’s guidelines. The COD System shall perform the following, including but not limited to:

• Process origination and disbursement records received from eligible domestic schools from the main location.

• If the origination record passes all the edits and it is accepted, check if the award is for an existing or new student, or whether the award is already on file. Accordingly, it shall create or update the student and award data records.

• Send loan servicers any changes to the student award record made after the award has been booked.

• Require schools report anticipated and/or actual disbursements equaling the total award amount approved of the award when creating a new TEACH Grant.

• Validate disbursement dates are within a school's eligibility period.

• Validate the student is not over the annual award limits based on their grade level.

• Attempt to link the award to a TEACH Grant Agreement to Serve or Repay (TEACH Agreement) based on FSA linking criteria.

• Notify applicable school(s) when an award successfully links to a TEACH Agreement, or when the status changes using the Common Record or Agreement response.

• Generate a Disclosure Statement package based on the school option when the origination record passes all the edits, and it is accepted. The COD System shall also integrate with StudentAid.gov to provide the Disclosure Statement correspondence to display to users.

3.2.3.4.Pell Origination When processing a Pell award origination, the COD System shall perform edits to validate award information is complete, correct and conforms to FSA’s guidelines. The COD System shall perform the following, including but not limited to:

• Process origination and disbursement records received from eligible domestic schools.

• If the origination record passes all the edits and it is accepted, check if the award is for an existing or new student, or whether the award is already on file. Accordingly, it shall create or update the student award data records.

• If the COD System is creating a new student, check archives for matching student Pell Lifetime Eligibility Used (LEU) to link with newly created person in the COD System.

• Send National Student Loan Data System (NSLDS) any award or disbursement changes made after the record has been accepted.

Version 1.0 20 11/30/2023

Controlled Unclassified Information (CUI)

• Validates the origination links to a CPS/FPS Transaction with Pell Elig = Yes with a valid Expected Family Contribution (EFC) or Student Aid Index (SAI).

• Calculates the Scheduled Award based on either o (2023-24 and prior) EFC, Cost of Attendance (COA), and published Pell Payment and Disbursements

Schedules, and in some cases the addition of the Children of Fallen Heroes (CFH) Indicator or Post 9/11/ Deceased Vet Dependent indicator.

o (2024-25 and forward) SAI, Max Pell, Min Pell, Iraq & Afghanistan Service Grant, CFH Indicators, and COA using a formula.

• Require schools report an Award Amount greater than 0, but less than or equal 100% (150% if the Alternate Documentation of Income (AEI) = “true”) of the Scheduled Federal Pell Grant Award (SFPG). OR if there are LEU Adjustments at the Attended School ID for the award year, 100% (150% if AEI = “true”) plus the absolute value of the sum of the LEU Adjustments for the award year.

• Require schools report an Enrollment Date within the valid date range.

• Require schools report an Attendance Cost (cost of attendance) within the valid range.

• Validate Verification Status code of “W” is submitted within the Verification W valid date range.

3.2.3.5.IASG Origination When processing a IASG origination for 2017-18 through 2023-24, the COD System shall perform edits to validate award information is complete, correct and conforms to FSA’s guidelines as it does for Pell with the following exceptions: Limits award creation to the COD Web

• Validates the origination links to an CPS Transaction with a Department of Defense (DoD) Match Flag – Yes, and Pell Elig ≠ Yes with a valid EFC o Calculates the Scheduled Award based on an assumed-zero EFC, Cost of Attendance (COA), and published Pell Payment and Disbursements Schedules, and IAS Grant flag (checkbox).

o Calculates a Sequester-limited Scheduled Award based on the calculated Scheduled Award and the annual published reduction percentage for IASG based on the date of the first disbursement.

•…