Attachment J-4 NSLDS TIVOD Business Requirements 113023.pdf

NSLDS TIVOD Business Requirements

Version 2.0 1 11/30/2023 Controlled Unclassified Information (CUI)

National Student Loan Data System Business Requirements

Version 2.0 ● 11/30/2023

Version 2.0 2 11/30/2023

Table of Contents Section 1. NSLDS Overview

Section 2. Scope

Section 3. NSLDS Core Functionality

3.1 Automatic Closed School Discharge Evaluation

3.2 Aid Overpayment Tracking

3.3 Audit Support

3.4 Budget Services Data Extract Processes

3.5 Cohort Default Rate (CDR) Calculations

3.6 College Scorecard Calculations

3.7 Credit Reform Act Support

3.9 Enrollment Reporting

3.10 Exit Counseling

3.11 Financial Aid History (FAH) Information

3.12 Gainful Employment (GE)

3.13 Gainful Employment (GE) Rate Calculations

3.14 Imminent Danger and Hostile Fire Pay Interest Reduction Benefit

3.15 Income Driven Repayment (IDR)/ Public Service Loan Forgiveness (PSLF) Information and Payment Account Adjustments

3.16 Loan Purchase Program (PUT)

3.17 Online Loan Update

3.18 Post screening for Title IV Aid Eligibility

3.19 Prescreening for Title IV Aid Eligibility

3.20 Reaffirmation Information

3.21 Real Time Data Inquiries

3.22 Repayment (Notional) Information

3.23 Security Monitoring

3.24 Transfer Student Monitoring (TSM)

3.25 Web Inquiries

Section 4. Operational Support Functions

4.1 General Activities

Section 5. NSLDS Architecture

Section 6. NSLDS Databases

Version 2.0 3 11/30/2023

Section 7. System Interfaces

Section 8. Data Management

8.1 Deferred Requirements – Data Mapping

Section 9. Reporting

9.1 Canned Reporting

9.2 Ad Hoc Reporting

Section 10. User Access Points

10.1 NSLDS Professional Access

10.2 Studentaid.gov

10.3 Partner Connect

Version 2.0 4 11/30/2023

Section 1. NSLDS Overview The National Student Loan Data System (NSLDS) is the national database of information about loans and grants awarded to students under Title IV of the Higher Education Act (HEA) of 1965. NSLDS provides a centralized, integrated view of Title IV loans and grants during their complete life cycle, from aid approval through disbursement, repayment, deferment, delinquency, and closure.

The three main goals of the NSLDS are to:

1. Improve the quality and accessibility of student financial aid data.

2. Reduce the administrative burden of Title IV aid.

3. Minimize abuse within aid programs by accurately tracking funds awarded to assist postsecondary students.

NSLDS serves as the comprehensive resource on disbursed Title IV aid and its data is used to support the Department's commitment to protecting students' and taxpayers' investments by using student aid and enrollment data to promote transparency in college value and student outcomes. NSLDS data is used in real time to support financial awareness counseling for students and to help borrowers easily consolidate their loans and request an income driven repayment plan. Between 2001 and 2020, NSLDS has pre- and post-screened over 355 million student aid applicants, preventing over 6.1 million ineligible students from receiving aid, which amounts to an estimated $21 Billion saved.

It is also used by educational institutions, lenders, and servicers participating in Title IV HEA programs to track and manage aid eligibility and support administration and collection of funds. Information maintained in NSLDS is used by the Department for oversight and administration activities and it is shared with stakeholders including the White House, Congress, Government Accountability Office (GAO), Office of Inspector General (OIG), and other federal agencies for budgeting, planning, and compliance with federal regulations.

NSLDS allows authenticated users with appropriate permissions to conduct a specific search and view the specified data processed and maintained for various Title IV functions.

Version 2.0 5 11/30/2023

Section 2. Scope

The NSLDS System is supported on an Amazon Web Services (AWS) Platform which supports several Batch Interfaces, Web Services, a website for Financial Aid Professional Website, and currently use COGNOS as its reporting tool for NSLDS website users. For web transactions, users for the Professional Access website (nsldsfap.ed.gov) use the Access Identity Management System (AIMS) to log into the site. There is also a suspension file used to forbid certain users from using the system.

Select users can interact with the database directly via Structured Query Language (SQL) tools. A much broader group of users interacts with the database via batch file exchanges or via the nsldsfap.ed.gov website to either report Title IV financial aid data to NSLDS or request Title IV data. NSLDS processes and maintains data pertaining to the following Title IV programs:

• Campus-Based Programs o Federal Supplemental Educational Opportunity Grants (FSEOGs) (only applies to overpayments) o Income Contingent Loans (ICLs) o Perkins Extended Loan Options o Perkins Loans/National Direct Student Loans/National Defense Student Loans

• Federal Direct Loan Program (FDLP) o Federal Direct Consolidation Subsidized Loans o Federal Direct PLUS Consolidation Loans o Federal Direct PLUS Loans o Federal Direct PLUS Loans for Graduate and Professional Students o Federal Direct Stafford Subsidized Loans o Federal Direct Subsidized Consolidation Loans o Federal Direct Subsidized Stafford Loans o Federal Direct Unsubsidized Consolidation Loans

NSLDS BoundaryInternal & External FSA Systems

C O

D

AI

M

S D

C C

FL

S

FM

S

C

PS

PM

Sc ho ol s

G As

NSLDS HIGH-LEVEL OVERVIEW

NSLDS Core Database Data

ACSD

COD

Direct Loan

IDR App

FFEL

CPS

AMF

Aid Recipient

Eligibility

Enrollment

PEPS

Repayment

Cohort Default Rate

Exit Counseling

Perkins

GA

PSLF

Imminent Danger

NPSAS

School Alert

SSA

FLS

PM

FMS

Cognos Gitlab

Tools

VA Pell Restore pMDM Subsidy

PPO

EDM

APS

O

IG

N

PSAS

VA

SSA

pM D

M

Internal & External FSA Systems

External Internal

Cognos Sequel Developer

Version 2.0 6 11/30/2023 o Federal Direct Unsubsidized Stafford Loans o Federal Direct Unsubsidized Teacher Education Assistance for College and Higher Education (TEACH)

Loans

• Federal Family Education Loan Program (FFELP) o Federal Consolidation Loans o Federal PLUS Loans o Federal PLUS Loans for Graduate and Professional Students o Federal Subsidized Stafford Loans o Federal Supplemental Loans for Students (SLSs) o Federal Unsubsidized Stafford Loans o Refinanced Loans

• Federal Grants o Academic Competitiveness Grants (ACGs) o National Science and Mathematics Access to Retain Talent (SMART) Grants o Pell Grants o Teacher Education Assistance for College and Higher Education (TEACH) Grants o Federally Insured Student Loans (FISLs)

Incoming data is supplied to NSLDS from many different sources, both from other Federal Student Aid (FSA) systems and from thousands of schools and financial institutions across the country. The data arrives in a variety of formats and according to schedules set for each reporting organization. Output from NSLDS is determined by business functionality, and includes but is not limited to, web data displays, letters/emails, and batch files (reports, confirmations, error files) which are provided in a variety of electronic formats.

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

1. Volume 1: The contract resulting from this procurement will establish a performance-based business arrangement with the Contractor for efficient, effective, and responsive support of the NSLDS system, including collaboration with the current Contractor during the transition of all duties from the old Operations and Maintenance contract to the new. It is critical FSA’s programs deliver world-class customer service during the transition at the lowest cost without sacrificing service levels or quality and without disruption or degradation of services.

The Contractor shall propose their service model for operation and maintenance of NSLDS and shall include Information Technology Infrastructure Library (ITIL)-based processes, staffing model, and integration with FSA’s IT systems’ change, release, Software Development Life Cycle (SDLC), and Lifecycle Management Methodology (LMM) processes. In this volume, the Contractor shall propose industry best practices for cloud-based operations and maintenance.

The execution of this volume will provide support to NSLDS for several key objectives. Specifically, the Contractor will be responsible for 1) Data Collection, Data Quality, and Ease of Access, 2) Business Operations and Production Support, 3) Training, 4) NSLDS System Changes, 5) NSLDS Database Security,

6) Customer Assistance, 7) Transition Support, and 8) Audit Support. The contract may also potentially include (depending on Contractor responses) 9) additional work to incrementally improve the efficiency and functionality of the NSLDS website.

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

Version 2.0 7 11/30/2023 not for use in standard operations and maintenance activities of NSLDS, 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. In this volume, the Contractor shall propose best practices and methodologies for managing and delivering new systems development or enhancement requirements from FSA.

Section 3. NSLDS Core Functionality The NSLDS Contractor shall be responsible for the following operational functions:

3.1 Automatic Closed School Discharge Evaluation

When a school closes, impacted borrowers are relieved from repaying loans qualifying under Title IV Closed School Discharge regulations. Monthly, NSLDLDS evaluates loan information from loan holders and schools to determine eligibility for Automatic Closed School Discharge. NSLDS monitors and evaluates eligible loans and notifies the borrower and the appropriate Servicer to process discharge.

3.2 Aid Overpayment Tracking

The NSLDS Professional Website Aid Overpayment function shall allow data providers to update NSLDS when a student owes or repays an overpayment on a Pell, ACG, National SMART, TEACH Grant, FSEOG, Iraq and Afghanistan service Grant (IASG), or Perkins loan. This function also facilitates the reporting of fraud by schools and DMCS. Adding of an active overpayment triggers a message, borrowers are ineligible for aid which is used for borrower eligibility processes and is visible on the NSLDS website.

3.3 Audit Support

Audits and risk assessments are supported by a combination of audit logs, audit reports, Web, and database queries.

The Contractor shall be responsible for gathering all required data necessary to support an auditor’s request. NSLDS supplies auditors and program reviewers with data on specific organizations and on key indicators used to schedule audits and program reviews for maximum effectiveness. The Contractor shall support various security audits.

3.4 Budget Services Data Extract Processes

The Contractor shall support the Department of Education Budget Services Office in their twice annual pull of data to support data modeling of their statical abstract of Title IV loans and grant data. These data are used to support assumptions for estimating the long-term budgets for FSA programs. These data points are also used to answer budget-related questions and to support “what-if” analyses.

Version 2.0 8 11/30/2023

3.5 Cohort Default Rate (CDR) Calculations

The NSLDS Contractor shall calculate draft and official default rates for schools participating in FFELP and FDLP, lenders/lender servicers, and Guaranty Agencies (GA). NSLDS stores the numerator, denominator, and backup detail, and processes appeal rates. The cohort default rates are made available to each organization through the NSLDS Website. The school rates are made available to schools through the electronic CDR (eCDR) process.

NSLDS determines eligibility for sanctions or benefits based on CDRs and sends letters to schools on behalf of the Partner Participation & Oversight (PPO)Operations Performance Division (OPD), notifying schools of their sanction or benefit status. OPD users can override sanction or benefit status or request CDR web reports on the NSLDS Professional Access site.

3.6 College Scorecard Calculations

Annually the NSLDS Contractor shall calculate data by school for the College Scorecard’s Loan Repayment Rate, Completion Rate, Median Debt Amounts, and completion cohorts for Earnings Data retrieval from the Department of the Treasury. After each calculation, College Scorecard Calculation data is sent to the College Scorecard Website and the Department of Treasury Statistics of Income Division (SOI). The NSLDSFAP Website displays the Repayment Rates, Completion Rates, and Median Loan Debt figures for all schools with available data.

3.7 Credit Reform Act Support

The Credit Reform Act (CRA) Support and related Office of Management Budget (OMB) circulars require the Department to identify loans by loan program, cohort year, and risk category. NSLDS is the Department’s only source of this loan-level data. NSLDS makes available the data the Department’s Budget Services requires for this purpose.

3.9 Enrollment Reporting

Regulations require schools to report on the enrollment status of Title IV aid recipients every 60 days. The NSLDS Contractor shall generate Enrollment Reporting Rosters to school based on the school’s selected schedule. Schools or their servicers (often the National Student Clearinghouse) can respond to the reports by batch submission (via Student Aid Internet Gateway (SAIG) or spreadsheet upload submittal) or by entering data online. NSLDS then updates its database to reflect any changes in student enrollment status or program enrollment data and forwards enrollment status change data to the loan-holding community. The Contractor shall be responsible for the statistics for the percentage of students certified, the percentage of students certified with program enrollment data, and Enrollment Submittal Tracking information and make these data points available on the NSLDS Website.

3.10 Exit Counseling

When a school chooses to use their own Exit counseling process and not FSA’s studentaid.gov exit counseling tool.

The school can upload the list of students completing exit counseling to NSLDS. This data is shared by NSLDS to Federal Loan Servicers and guaranty agencies holding loans for these students. The Contractor shall be responsible for maintaining this NSLDS functionality.

3.11 Financial Aid History (FAH) Information

The Contractor shall maintain NSLDS FAH functionality. NSLDS generates FAH information and forwards a subset of a borrower’s history to Central Processing System (CPS) / FAFSA Processing System (FPS) as part of the

Version 2.0 9 11/30/2023 prescreening/Institutional Student Information Record (ISIR) process. NSLDS also generates a borrower’s entire FAH, consisting of borrower-level flags/indicators, aggregate loan amounts, loan, grant and overpayment details, outside the prescreening process in response to ad hoc FAH requests from schools. These requests can be made online or by SAIG batch submittal and are part of Transfer Student Monitoring. GAs can make FAH requests by SAIG batch submittal, and the data response(s) are restricted to borrowers with whom they hold or held a loan. The FAH information they receive contains only borrower and loan data. No grant information is included in the FAH for GAs.

3.12 Gainful Employment (GE)

NSLDS Contractor shall support Gainful Employment Regulations in NSLDS. NSLDS is required to collect annually for all programs at Title IV schools’ data on the annual cost of attendance and annual loan debt attributed to the programs. In addition to the annual data schools must also report the total cost of programs when the student graduates or withdraws for the program. Data collection is based on award year participation and is provided by institutions through batch and online submissions.

3.13 Gainful Employment (GE) Rate Calculations

NSLDS calculates the various rates and ratios for schools participating in GE Programs. NSLDS stores the numerator, denominator, and backup detail information regarding these rates. The GE Rates and Ratios are made available to each organization through the NSLDS Website. The Contractor shall be responsible for sharing certain GE data with EDWA’s Data Center.

3.14 Imminent Danger and Hostile Fire Pay Interest Reduction Benefit To support the United States Department of Defense, the NSLDS Contractor shall maintain the process of identifying loans eligible for interest benefits. NSLDS will maintain the capability to exchange data about borrower eligibility for the Imminent Danger and Hostile Fire Pay interest reduction benefit with the United States Department of Defense, Federal Loan Servicers, the Debt Management and Collection Service, and Total and Permanent Disability. NSLDS then stores data about loans to which this benefit has been applied.

3.15 Income Driven Repayment (IDR)/ Public Service Loan Forgiveness (PSLF) Information and Payment Account Adjustments The Contractor shall support all FSA’s programs for Loan forgiveness and account adjustments for payment counters based on current regulations and policies. NSLDS processes and stores information about electronic applications for IDR programs reported by Common Origination and Disbursement (COD), Federal Loan Servicers, and participating FFEL lenders and lender servicers. This information is used to create summary-level report extracts about Income Driven Repayment (IDR) applications and programs which are available for download by authorized users on the NSLDS Website. In addition, the Contractor shall calculate account adjustments on payments counters and eligibility for loan forgiveness as directed by policy makers.

3.16 Loan Purchase Program (PUT)

The Contractor shall continue to maintain information on a program identified as The Loan Purchase Program (PUT).

NSLDS matches FFELP records purchased by ED and are now reported from a Federal Loan Servicer. NSLDS applies the servicers’ loan identifier to the record to facilitate continued reporting and updating by the servicer.

NSLDS also provides online match resolution options to allow the servicer to indicate loans for which they now have reporting responsibility but was not updated based on data provided from the servicer. The Contractor shall maintain all requirements currently associated with the PUT program.

Version 2.0 10 11/30/2023

3.17 Online Loan Update

The Contractor shall maintain all the NSLDS online updating capabilities. NSLDS shall allow approved GAs, federal loan servicers, and designated ED users to update their agency’s loan data via the Web. This instantaneous update feature helps to reduce the turnaround time for problem resolution and error corrections.

3.18 Post screening for Title IV Aid Eligibility

A core function of NSLDS is to prevent fraud and abuse of Title IV aid. The NSLDS Contractor shall maintain the Post screening functionality. For each award year, NSLDS post screens Title IV aid applicants to identify those whose eligibility status has changed since the time of their original, or most recent Student Aid Report (SAR)/ISIR, aid application. The process screens for default, overpayment, and fraud convictions, as well as loan eligibility criteria.

3.19 Prescreening for Title IV Aid Eligibility

A core function of NSLDS is to prevent fraud and abuse of Title IV aid. The NSLDS Contractor shall maintain the Prescreening functionality. NSLDS prescreens all Free Application for Federal Student Aid (FAFSA) applicants for Title IV Aid, or when other criteria is met subsequent SAR/ISIR transactions, to identify those applicants who go into/out of default on an existing Title IV loan; who owe/paid overpayments on Pell, ACG, National SMART Grants, TEACH Grants, FSEOGs, IASG, or Perkins loans; or who have come close, exceeded or resolved aggregate loan limits, or other changes in aid impacting a borrower’s eligibility.

3.20 Reaffirmation Information

When a student defaults on a loan they are no longer eligible for aid. However, if the defaulted student works with the loan holder, they have an opportunity to reaffirm they owe this defaulted debt and they will repay this and any future aid. This reaffirmation information is updated on NSLDS website by the loan holder. NSLDS processes, stores, and displays reaffirmation information reported by FFELP lender/lender servicers and Federal Loan Servicers (FLS) on the https://nsldsfap.ed.gov/login NSLDS Website. This information is used by schools when considering the awarding of additional Title IV aid. In addition, the NSLDS post screening process monitors and provides notification of reaffirmation changes to CPS for inclusion on the ISIR. The NSLDS Contractor shall be responsible for maintaining this functionality Note: Reporting reaffirmation data to NSLDS is required of our federal loan servicers and optional for FFEL Program lenders and lender servicers.

3.21 Real Time Data Inquiries

The NSLDS Contractor shall maintain Real Time Data requests. NSLDS generates financial aid information in response to “real time” requests from ED applications. The following applications use this functionality:

• Studentaid.gov using extensible markup language (XML)

• Direct Loan Consolidation Application

• FACT (Financial Awareness Counseling Tool)

• IDR (Income Driven Repayment) Application

• TEACH Exit Counseling

• Federal Student Aid Information Center (FSAIC) Integrated Voice Response (IVR) System

• StudentAid.gov using JavaScript Object Notation (JSON)

• Health Resources and Services Administration (HRSA) using JavaScript Object Notation (JSON) https://nsldsfap.ed.gov/login https://studentaid.gov/ https://studentaid.ed.gov/

Version 2.0 11 11/30/2023

3.22 Repayment (Notional) Information

In addition to the Cohort Default information on NSLDS the Contractor shall maintain the NSLDS function of allowing the school to see how their cohort rates are changing each month. NSLDS provides schools summary and detail student repayment data for informational purposes. This NSLDS function allows a school to identify students have problems with repaying their loans so counseling can be offered.

3.23 Security Monitoring

The NSLDS Contractor shall maintain current security monitoring tools. NSLDS provides monitoring tools an organization’s Personal Data Protection Act (PDPA), and FSA can use to ensure users are compliant with the NSLDS rules of access. NSLDS systematically monitors and provides email notifications to PDPAs so they are alerted and can take the appropriate and necessary actions. NSLDS provides an ad hoc Adobe Portable Document Format (PDF) reporting capability to help monitor user activities, as well as reports delivered via SAIG mailboxes.

3.24 Transfer Student Monitoring (TSM)

An essential function the NSLDS Contractor shall maintain is the Transfer Student Monitoring process. NSLDS receives school profile and transferring student information via the NSLDS Website pages and/or SAIG batch submissions. NSLDS monitors each of these students for specific changes in loan and Pell, ACG, National SMART, and TEACH Grant status. NSLDS reports these changes to schools via Web pages or SAIG batch files. TSM alert emails are provided to the designated TSM point of contact. NSLDS Customer Service and authorized FSA Program Compliance personnel have access to view a school’s NSLDS Website TSM pages to provide support and oversight.

3.25 Web Inquiries

Critical to NSLDS is the NSLDS website for Financial Aid professionals, NSLDSFAP.ed.gov. The Contractor shall maintain this website at an optimal performance level. The website is for schools, state grant agencies, eligible and approved GAs, Federal Loan Servicers, lenders and lender servicers, and ED and its Contractors to view NSLDS data. Depending on user access, the Website also provides a list of ad hoc or scheduled reports.

Section 4. Operational Support Functions The NSLDS Contractor shall maintain the following operations support functions:

• Assessment of FFELP, FDLP, and Other Program Administration—NSLDS supplies data used in short-or long-term studies aimed at determining the effectiveness of loan program practices.

• Freedom of Information Act (FOIA) requests—NSLDS completes FOIA requests when they meet established guidelines.

• Loan Participation Program (LPP)—NSLDS contains data regarding Custodian and Sponsor lending organizations a part of the Ensuring continued Access to Student Loans (ECASLA) enacted funding process allowing participation interest agreements with ED. NSLDS links loans on NSLDS with the Custodian or Sponsor records received from Financial Management System (FMS).

• Loan Transfer Tracking—NSLDS preserves historical data on loan holders and loan sales dates used to understand secondary market activity, identify potential problems with loan program participants, assist borrowers in locating lenders or GAs associated with their loans, and assessing the administration and

Version 2.0 12 11/30/2023 billing practices of Title IV loan programs.

• Monitoring GA and Lender Financial Reporting for Reasonability—NSLDS supplies ED personnel with the detailed-level information needed to assess the reasonability of financial reporting from GAs and lenders based on changes in loan portfolios, loan status, loan balance information, and other loan details. NSLDS performs monthly and annual reasonability calculations for GAs.

• Payment Support of Account Maintenance Fees (AMFs) to GAs—NSLDS provides data about Outstanding Principal Balance (OPB) on open loans supporting AMF payments by FMS. With the change to supporting origination of only Direct Loans, the LPIF is no longer calculated for GAs.

• Research Studies and Policy Development—NSLDS supports long-term research studies and short-term policy development by providing ED with current detailed and aggregated loan, grant, and student data.

4.1 General Activities

In addition to these specific operational support functions, the NSLDS Contractor shall perform the following general activities:

• Generate statistically valid extracts of the production database.

• Incorporate and supports data standardization.

• Interface with Government-provided telecommunications links.

• Maintain a training database.

• Maintain demographic data on recipients and institutions.

• Maintain organization contact information for ED Regions, the federal loan servicers, schools, GAs, Lenders, Lender Branch servicers, and state agencies.

• Meet data currency requirements.

• Meet performance and response standards.

• Monitor user access and provides FSA with data of users falling outside of acceptable usage parameters.

• Preserve data security and confidentiality as required under the Privacy Act of 1974, as amended.

• Provide output in formats supporting executive information systems.

• Provide subject matter experts (SMEs) to interface with the user community and to provide input for new functionality.

• Receive and process new, changed, and removed user information from Participation Management.

• Support prevention and resolution of errors.

Section 5. NSLDS Architecture The NSLDS platform is a tenant of the FSA Cloud General Support System (GSS) which provides core security, perimeter networking, user access management, DevOps, infrastructure, and monitoring services to tenant systems.

AWS GovCloud is the main infrastructure of the FSA Cloud.

Version 2.0 13 11/30/2023

• FSA Cloud AWS Components exist within the AWS GovCloud (US-GOV-WEST-1) is comprised of several independent Virtual Private Clouds (VPC) and subnets segmenting the system into separate zones for discrete networking control and management. FSA Cloud provides core security, perimeter networking, user access management, DevOps, and monitoring services to tenant systems.

• NSLDS Core Execution VPC and NSLDS Core Data VPC are dedicated to the NSLDS platform and host NSLDS applications, services, and databases.

• AWS GovCloud is the Logging as a Service (IaaS) and Platform as a Service (PaaS) hosting the core FSA Cloud services for operations and management of cloud components. It also includes system application tenants. Capabilities include:

• Perimeter capabilities including Web Application Firewalls (WAF), Domain Name Servers (DNS), Virtual Private Networks (VPN), Firewalls.

NSLDS is a mission-critical data system providing comprehensive Title IV disbursement records at the borrower level. The database manages over 38 terabytes. NSLDS acquires, integrates, and stores data from various sources and makes it available to users and systems.

• The system shall provide for data retrieval against the production database and return requested data to the student access website with an average response time of 1.5 seconds.

• The system shall have a minimum storage capacity of 5 terabytes of data. (Note: Number shall be revised regularly during regular capacity planning activities.)

• The system shall accommodate the expansion of receiving and storing new data as well as storing current data.

• The system shall anticipate a 10% growth rate for loan data updates each year.

• The system should anticipate a 9.0% growth rate for grant data updates each year.

• The system should anticipate a 13% growth rate for enrollment data updates each year.

The Contractor shall continue operating and maintaining the following high-level architecture supporting the NSLDS System infrastructure:

1. Web: NSLDS consists of a web application and a set of micro-services segmenting the different functional areas and business logic components for the overall system. The communication between the application and the services is via REST-based API calls. The main application shall be composed of Angular webapps deployed to the Apache Hypertext Transfer Protocol daemon (httpd) container service. Apache httpd shall serve these angular webapps and proxy traffic to the backend service applications. The backend service applications shall be deployable Spring Boot code. Each deployable shall be broken down into a minimal common function correlating to specific business domain or functional package. These microservices will utilize Oracle for data retrieval and Redis buckets in AWS ElastiCache for data caching. Authentication to the web application is managed through AIMS.

2. Batch: The batch application is launched using Azkaban, an open-source batch scheduling tool, which runs a Unix command. The command spins up the java code using a bash script. The core business logic for each of the interfaces are run using Spring Batch with additional custom code to support the specific business requirements.

• The system shall perform batch data loads with associated processing functions between 1700 and 0600 eastern time.

• The system shall be capable of loading an average of 90 million data records per week.

• The system shall complete batch data loads with an average of 15 million records within 4 hours.

Version 2.0 14 11/30/2023

• The system shall complete batch data loads with a peak volume of 37.5 million records within 6 hours (peak batch load volumes occur an average of 10 days per year).

3. Container: The NSLDS architecture contains microservices deployed to support the core components making up the NSLDS system. The NSLDS core exec shall contain Red Hat Enterprise Linux (RHEL) atomic EC2s with OpenShift installed. OpenShift is a container management platform. Container services shall only be reached by other internal container services within the OpenShift cluster unless an external route is provided. These routes are only provided on tools or apps with user interfaces. Environment management is done with existing FSA management infrastructure capabilities utilizing Ansible and the configuration management database (CMDB).

4. Data: The databases are separate from the execution environment definition and are defined in the coredata infrastructure for network and security isolation. The environment cluster within the coreexec infrastructure has DB client container Ansible management jobs utilize to connect to the databases for environment specific automation tasks such as creating users, schemas, data definition language (DDL), and data for the environment. The environment utilizes Oracle databases and MySQL database for the Azkaban scheduling tool. The Contractor’s operators and FSA users have access to the Oracle databases.

The current security solution for this is to leverage a read-only replica and database link. With a separate linked database, many concurrent users can create tables or perform other tasks without the concern of effecting production. As part of the solution for the NSLDS Platform, Cognos Sequel Developer is implemented as part of the tooling within the NSLDS Boundary. Cognos Sequel Developer is a browser-based tool allowing direct SQL Access to databases and other functions. Access to the Cognos Sequel Developer URL shall only be accessible internally by users who are authenticated via an agreed upon VPN solution and not via the public internet.

Version 2.0 15 11/30/2023

5. Access: NSLDS users are authorized through single sign-on via Access and Identity Management System

(AIMS).

• The Contractor shall comply with the controls for access management contained in the current versions and revisions of: National Institute of Standards and Technology (NIST), SP-800-53, Recommended Security Controls for Federal Information Systems and Organizations; and NIST- SP-800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans.

• The Contractor shall comply with FSA access control and authentication policy and practice and shall meet the Identity Assurance Level 3 and Authenticator Assurance Level 3 requirements cited in NIST SP 800-63-3/A/B/C (equivalent to LOA4 authentication requirement cited in NIST 800-63-2 and OMB Memorandum M-04-04). If Contractor proposes use of its corporate tokens to meet FSA’s requirements, Contractor shall demonstrate to FSA without exception it can achieve IAL3 (Identity Assurance Level 3) and AAL3 (Authentication Assurance Level 3) authentication and meet all FSA requirements.

• Soft Tokens can be used instead of hard tokens. The soft token is an app running on the user’s mobile device. After downloading and registering the free Symantec VIP Access app on a phone or tablet, a user simply opens the application, and a One-Time Password (OTP) is automatically generated like a hard token. Use of a soft token is optional, however users who have a compatible mobile device are encouraged to transition to a soft token. There is no requirement to maintain property records on soft tokens.

• The Contractor shall use Personal Identity Verification (PIV) cards for Access to FSA Information Resources. Personal Identity Verification (PIV) cards issued by the Department of Education shall be used by all privileged users who work on systems residing within the Federal Student Aid (FSA) data centers.

Version 2.0 16 11/30/2023

Personal Identity Verification (PIV) cards issued by the Department of Education shall also be used by privileged users who access systems both within and outside the FSA data centers.

• The Contractor shall provide:

o Monthly, within three business days of month’s end: a list of all card holders, divided into

Privileged and non-Privileged status. The list shall include everyone’s name, job title, organization position, issue and expiration dates of security clearance, and other such personnel and security information as is identified in the reporting template, Monthly Vendor Employee Report, provided by the Contracting Officer and included as a template in the solicitation and award documents.

o Within three business days after the close of each month: a report from the Contractor’s privileged access management system, which shall generate data aligned with and usable by FSA’s CyberArk management system, showing the identity and activity of each Contractor and sub-Contractor employee with access to every FSA system and data store.

o Within 24 calendar hours upon request: raw system access audit logs of any or every system being accessed or tracked by the Contractor.

6. Reporting: Cognos is a Commercial-of-the-Shelf (COTS) product utilized for NSLDS reporting. End user access for Cognos site authentication will be via single sign-on (SSO) from the NSLDS Financial Aid Partner (FAP) Website (https://nsldsfap.ed.gov). Users will be able to access the NSLDS Instance of Cognos only after authenticating to the NSLDS FAP Website. Access to Cognos for users shall not be available without entering the FAP Site. Authorization within the Cognos site is driven by their role and group assignment within the Cognos Access Manager LDAP. The solution for the reporting architecture is to deploy Cognos for report retrieval and analytics. The Cognos reporting tool shall have connectivity to the Core Oracle Database and the Read-Only Replica within the tenant to support minimizing contention, user resource limitations, and a prioritization model shall be put in place.

FSA Cloud (GSS)

NSLDS Tenant

NSLDS Core Data VPC

Core DB FSA User

DB

Read Replica DB

DB Link real time replication

Alation

Contractors ED/FSA Users

GSS Access Manager

LDAP ManagementAccess Manager

Keycloak https://nsldsfap.ed.gov/

Version 2.0 17 11/30/2023

7. Infrastructure: The application is hosted in FSA Cloud (AWS Cloud environment) in its own tenant. There is a pre-production and production environment. The NSLDS preprod AWS account shall consist of a test coreexec and coredata VPCs, and performance test coreexec and coredata VPCs. Performance test has separated VPCs to mimic production scale and specs unlike the test VPCs needing to support many testing execution environments at once. For security purposes, the NSLDS production coreexec and coredata VPCs are in a separate production AWS account.

Section 6. NSLDS Databases The NSLDS application shall encompass 3 databases (core, replica, user access) separate from the execution environment definition and are defined in the core data infrastructure for network and security isolation.

1. Core: The Core database interfaces with the Production environment. Access to this database is limited to the Contractor Database Administrators.

2. Replica: The Replica database is a read-only database receiving information from the Core database in real-time.

3. User Access: The User Access database receives data from the Replica database and allows FSA users and the Contractor Operations team to have the ability to create tables or perform other tasks without the concern of effecting production.

4. Training: The Training database is updated periodically with Production data to allow FSA users and the financial aid/data reporting community to use for user training activities.

The Contractor shall update/maintain a separate and distinct training database environment for FSA users and the financial aid/data reporting community for use with user training activities; FSA and financial aid/data reporting users shall have access on an ad-hoc basis.

Version 2.0 18 11/30/2023

The NSLDS Training Website is a replica of the NSLDS Financial Aid Partners Web FSA resources and Financial Aid Partners use for training purposes. All data seeded is test data and there is no production information used within this application. The Training Website uses AIMS for user authentication.

• The Contractor shall maintain the training environment and website monthly, at a minimum, to mimic the current production code release(s).

• The Contractor shall maintain the training database data and update monthly, at a minimum, while being realistic and reflect production state data in all related tables as much as possible while ensuring data is PII.

• The training database environment shall function/perform online and batch functionalities like production so if FSA users need to process data to learn how the system works, it can be performed with minimal Contractor support.

• The Contractor shall make available the training database for Structured query language (SQL) training so class participants can learn to write queries and understand the NSLDS database while using the Personal Identifiable Information (PII) data maintained in the training database.

• The Contractor shall create SQL training material based on the training database PII data; if data changes due to system enhancements on an ongoing basis in preparation for quarterly delivery the training material shall be updated to reflect all data/system changes.

The Contractor shall prepare the training database for use at FSA and/or financial aid conferences. This includes preparing exercises for participants to access so they can learn how to use the NSLDS system.

Section 7. System Interfaces The NSLDS Contractor shall maintain NSLDS current Interfaces. The Interfaces include:

• Access and Identity Management System (AIMS)—AIMS authorizes users with a single sign-on to access multiple FSA systems. With AIMS, NSLDS users can access the NSLDS Professional Access Website using their FSA User ID and password for identity authentication.

• Central Processing System (CPS)—CPS interacts with the NSLDS System daily to support Eligibility Functionality in the CPS System in addition to communicating Aid Applicants to NSLDS. The eligibility functionality is supported by a request process initiated by CPS or Rules within the NSLDS System proactively alerting CPS of potential eligibility changes. NSLDS will share a person’s Financial Aid History with the CPS system for the proper eligibility checks to be performed. In addition, CPS daily submits demographic data (e.g., Demographic Data Exchange File) for NSLDS to consume to associate with an NSLDS Aid Recipient as needed. Files are exchanged via SAIG.

• Common Origination and Disbursement (COD)—Daily, COD and NSLDS collaboratively share information to support the Direct Loan, Grant, TEACH, ACG, SMART for Originations and Disbursements and Summary level information for Perkins as part of FSA’s Title IV Aid Programs. In addition, COD daily provides Loan and TEACH Exit Counseling as well as Income Driven Repayment Application information. NSLDS in turn sends to COD information regarding student eligibility, loans, Servicer information, borrower default data, as well as information to support the evaluation process for the subsidized usage limit regulation. NSLDS also distributes Cohort Default Rates to COD on a weekly basis to support rules in COD for single-disbursement benefits to eligible schools, as well as Closed School Enrollment files. Files are exchanged via SAIG.

• Debt Management and Collections System (DMCS)—DMCS sends NSLDS a file weekly containing data on all loans held by ED in the Debt Management and Collections System portfolio including FISLs, National

Version 2.0 19 11/30/2023

Direct/National Defense loans, Perkins loans, FDLP loans, FFELP loans, and TEACH loans. It also sends ED-held overpayments and fraudulent grants. Files are exchanged via SAIG.

• Department of Defense (DoD) – For the Imminent Danger Pay (IDP) and Hostile Fire Pay (HFP) Interest Reduction business process, NSLDS identifies Aid Recipients with Active-Duty status and sends a Simple Mail Transfer Protocol (SMTP) file annually.

• Enterprise Data Warehouse and Analytics (EDW&A)—NSLDS sends feeds of selected data to EDWA via SAIG monthly. EDWA contains federal student loan lifecycle data and consolidates data it receives from NSLDS and other systems (COD, CPS) and Title IV loan servicers. EDWA provides ED users with the ability to perform advanced statistical analysis and provide timely responses to external data requests.

• E-Appeals – NSLDS sends the Loan Record Detail Reports (LRDR) Records which are the build-up to the Loan Information used to calculate CDR Rates at institutions to the e-Appeals system to support School CDR Challenges. The file is sent via SAIG on an ad-hoc basis.

• Federal Loan Servicers (Department contracted servicers)—Federal Loan Servicers send weekly data files, as described in the NSLDS Data Provider Instructions (DPI), containing data on FFELP loans sold to the Department as well as FDLP loans, TEACH grants and various other Title IV aid data elements. NSLDS sends Enrollment Reporting data and Exit Counseling Completion data to Federal Loan Servicers on a weekly basis. Federal Loan Servicers (also identified on the NSLDS Professional Access Website as ED Servicers), include the original Title IV Additional Servicers (TIVAS) and Not for Profit (NFP) organizations.

The Federal Perkins Servicer, which services federally held Perkins loans, is included in this group. Files are exchanged via SAIG.

• Financial Management System (FMS)—The Department of Education’s FMS sends NSLDS a daily file containing changes to the lender and lender servicer participation information as well as a quarterly file containing changes to interest rates and special allowances. NSLDS provides summarized data about new guarantees, cancellations, and disbursements, as well as data about OPB on open loans supporting AMF payments by FMS. Additionally, ED’s FMS provides Treasury summary data for the PUT loans. Files are exchanged using SAIG via Enterprise Service Bus (ESB).

• FSA Partner Connect— NSLDS sends financial aid history data in JavaScript Object Notation (JSON) format for display on FSA Partner Connect in real-time via Simple Object Access Protocol (SOAP) Web Service.

• Guaranty Agencies (GAs)—GAs, or their servicers, send NSLDS, at a minimum, a monthly feed containing data on FFELP loans held by lenders, lender servicers, or by the GA itself. A Web page on the NSLDS Professional Access Website allows GAs to set their submittal schedules and view submittal details. NSLDS sends Enrollment Reporting data and Exit Counseling Completion data to GAs on a weekly basis. NSLDS also sends Reasonability data monthly and annually to GAs and sends backup detail data for AMFs quarterly. GAs also have ad hoc reporting capabilities to submit any Teacher Loan Forgiveness (TLF) data or information about loans partially or totally discharged for NSLDS to store and display. Files are exchanged via SAIG.

• Digital Customer Care (DCC)/StudentAid.gov —NSLDS sends financial aid history data in JSON format for display and download via the MyStudentData Download option on the StudentAid.gov Website in addition to acting as a passthrough for sending NSLDS information to Health and Human Services (HHS) users logged in via StudentAid.gov. NSLDS uses Representational State Transfer (REST) Web Service to respond to the web service calls from DCC/StudentAid.gov.

• Lenders/Lender Servicers—Approved FFEL Lenders or Lender Servicers can access NSLDS information through the NSLDS Professional Access Website. Loans sold from the FFELP to ED as part of the PUT loans were provided weekly to NSLDS at the same time the data was being provided to the ED’s FMS.

Version 2.0 20 11/30/2023

NSLDS also makes Enrollment Reporting data and Exit Counseling Completion data available to Lenders and Lender/Servicers.

• The National Center for Education Statistics (NCES) is the primary federal entity for collecting, analyzing, and reporting data related to education in the United States. NSLDS sends Aid Recipients Financial Aid History to them upon request to support their effort to determine how students and their families pay for postsecondary education. National Postsecondary Student Aid Study (NPSAS) also helps examine the impact of changes in federal policy concerning higher education over time by collecting data from a variety of sources including NSLDS, which provides student-level data with grants and federal student loans information. NSLDS supports the NPSAS study by responding to requests from NCES and distributing the necessary information needed for NCES to conduct the NPSAS. The responses are sent ad-hoc via SAIG.

• Office of the Inspector General —NSLDS sends data monthly to the Office of Inspector General (OIG) for purposes of populating the OIG Data Analytic System (ODAS) Data Warehouse. The data sent consists of both transactional data limited to changes occurring in select tables and non-transactional data providing the entire content of tables. The files are sent via Secure File Transfer Protocol (SFTP).

• Participation Management (PM)—PM sends NSLDS daily files containing data on external organizations and persons who have enrolled for NSLDS batch and online services. Files include organizations exchanging batch files via SAIG with NSLDS and individual online users who will access and perform functions on the NSLDS Professional Access Website. The inbound PM file is sent daily at 11:00 PM ET, Sunday through Thursday via SAIG. As an outbound service, NSLDS sends a daily file to PM containing information about Guaranty Agencies, Lenders/Lender Servicers received from FMS, and school data received from the Postsecondary Education Participants System. NSLDS also sends a file of users whose online access is to be removed due to inactivity or suspicious activity. NSLDS sends the outbound file via SAIG at 9:00 PM ET, after the school file is processed (8:00 PM ET) but prior to PM processing at 11:00 PM ET daily, Monday through Friday.

• Postsecondary Education Participants System (PEPS)—PEPS…