01 - Award Eligibility Determination Requirements_REVISED PER CE.pdf

01 – AWARD ELIGIBILITY DETERMINATION

REQUIREMENTS

SECTION C – DESCRIPTION/SPECIFICATIONS

C.1 - INTRODUCTION

The U.S. Department of Education (ED), Office of Federal Student Aid (FSA), continues its Next Generation Federal Student Aid (Next Gen) initiative. Through this effort, FSA continues to implement a modern, flexible, and efficient system for FSA’s customers - students, parents, and borrowers – as well as partners at postsecondary institutions. In addition to improving the overall customer experience, the new environment seeks to improve operational flexibility, enhance cost and operational efficiency, and generate better outcomes for customers and taxpayers.

An Award Eligibility Determination (AED) Processing system would determine the eligibility of Title IV funds through a modernized processing solution of the FAFSA application.

C.2 – OBJECTIVES, REQUIREMENTS, AND MILESTONES

C.2.1 Solution Objectives

Award Eligibility Determination Processing System shall be a highly adaptable technical solution set which supports current and future FSA products and processes awarding and determining eligibility of Title IV funds. The solution shall deliver cost efficiencies through significantly increased automation, continuous improvement, and a modern technical backbone (e.g., modular code base, cloud operability, two-speed development compatibility, and/or innovative middleware). The solution shall better support changing rules, laws, and regulations with minimal operational complexity through the greater flexibility afforded by having separate rules engine(s) and integrated process workflows.

Integration across the enterprise and potential to further scale solutions

Solution will need to be integrated with existing and new solutions as well as vendors from across the lifecycle of student financing. Accordingly, all solutions will be implemented with both integration and future scalability in mind, ensuring third parties can “plug in” to use common tools and feed into common interfaces.

Implementation approach that minimizes risk and disruption for customers while deploying more efficient and effective solutions

The AED Processing System will need to have the flexibility necessary to seamlessly integrate with existing and future solutions provided by FSA or other vendors, across the entire lifecycle of student financing, including but not limited to:

- Next Gen Digital and Customer Care, which includes the digital platform (the StudentAid.gov website and myStudentAid mobile app), a customer care platform, and a marketing and communications platform.

- Next Gen Business Process Operations

- FSA Identity and Access Management

- Enterprise-wide Data Management Analytics Platform Service (EDMAPS)

FSA will have dedicated resources to validate vendor accountability by monitoring the operational environment and vendor performance to ensure a higher caliber of service than current state.

C.2.2 General Operating Requirements

Award Eligibility Determination Processing System shall satisfy the general requirement outlined in Section C.2.3:

Adaptability, flexibility, and ongoing innovation: Solution shall efficiently and effectively adapt to changes in the FSA operating environment (including changing Federal laws, regulations, and guidance), innovation in commercial financial services, and FSA’s goals.

Solution shall easily scale to handle changes in account and transaction volumes and have the flexibility to enable incremental modifications.

The solution shall be built with a modern architecture (e.g., but not limited to modular code base, cloud operability, two-speed development, rules engine, modern language) to deliver more efficient and effective functionalities and cutting-edge industry practices and products.

Solution shall implement a DevSecOps-driven-infrastructure that automates environment creation, testing, code quality checks, and deployment as much as possible (e.g., automatic issue flagging and event-triggered escalation).

Integration scalability and coordination across the enterprise: Solution will need to be integrated with existing and future solutions from multiple vendors that enable the lifecycle of student financing and compliance with all relevant laws and regulations. Accordingly, all solutions should be implemented with both integration and future scalability in mind, ensuring third parties can “plug in” through using common industry tools and allow access to data through industry common interface methods, e.g. APIs. In addition to this, the solution staff shall coordinate with the Digital Customer Care (DCC)-provided Command Center and Partner Participation & Oversight (PPO) customer service on common knowledge resources, contact scripts, agent desktop guides, and other training materials, ensuring that customer-facing instructions and resolution steps as well as back-office processing procedures are accurate in relation to Award Eligibility Determination.

FSA’s standards for internal and external Application Programming Interfaces (API): The Offeror needs to consult the DCC API enablement guide for guidance on the direction FSA is taking for standardizing and securing Restful Java Script Object Notation (JSON) APIs to account for FSA’s evolving and changing standards for internal and external API’s.

Adherence to FSA Next Gen Target State Architecture: Vendors should expect to follow and adhere to the Next Gen Target Architecture vision using common components and methods for capabilities like single sign-on, cloud platform services, etc. which will be published in the future. The Next Gen Target Architecture adheres to a series of guiding principles, directional goals for the Next Gen platform, which considers FSA’s organizational values, support for the business mission, and long-term strategy to serve customers and partners.

Currently, in the CPS system, data is automatically extracted from the database following each computing cycle and inserted into American Standard Code for Information Interchange (ASCII) flat files whole ensuring that no duplicates are included. This flat file is then sent to numerous FSA systems for processing. Note that all Personally Identifiable Information (PII) information for both student and parent collected via the FAFSA application is included in this extract. More significantly, not all systems require all the data in the ASCII files but is shared with every system needing even a single piece of data. Leveraging the Target State Architecture proposed above, please recommend the best approach to share such information from AED with other FSA systems that is cost effective, efficient, and secure.

The Next Gen DCC system includes multiple platforms that the AED vendor will need to integrate with, including providing APIs for the digital platform/StudentAid.gov and the myStudentAid mobile app, the customer care platform, and the marketing and communications platform to support sending email notifications to applicants and their parents.. All school and financial partners for Eligibility Determination will be provided by the Partner and Participation Oversight system. The selected Contract Awardee will be required to provide secure APIs to PPO to support the Digital Engagement layer for these business functions. The Contract Awardee will be required to publish an API library for the Award Eligibility Determination Processing System for use by other systems at FSA such as DCC and PPO. The Contract Awardee is responsible for maintaining all API libraries, code, and documentation to ensure a fully complete and integrated solution for FSA customers and partners.

Data architecture standards: Solution shall implement the enterprise logical and physical data standards supporting FSA’s master data management initiative.

Adherence to and monitoring for changes in laws and regulations: The solution shall meet or exceed existing Federal laws, regulations, guidance, agency guidelines or court mandates applicable to the FSA operating environment (including all accessibility elements such as

504/508 compliance). The solution shall establish a process for monitoring and informing personnel of new or pending changes to applicable laws and regulations, and then proactively partner with FSA to determine and communicate the implications to technical design and/or operational procedures. The solution shall continuously update to adhere to applicable laws and regulations.

Cybersecurity, Hosting and Middleware: The solution shall include robust cybersecurity protections and features to protect customer data. The solution must comply with the conditions in Attachment “03 – Security Technical Requirements”. The solution shall comply with the following:

1. Meet Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST) standards, and all cybersecurity regulations and mandates, including Presidential Executive Order (EO) 13800 - Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, to Identify, Protect, Detect, Respond, and Recover. The solution shall ensure that all development and management tools, including project management, version control, code repositories, DevSecOps management, monitoring, and cybersecurity, etc., are identified in the technical solution and in the system security boundary.

2. Be hosted in a secure environment. If any aspect of the solution is hosted in the cloud, the solution must be FedRAMP-approved or FedRAMP- “ready”, or must be hosted in a private cloud, per the definition in Attachment “03 -Security Technical Requirements.”

The solution may not be hosted in a shared, multi-tenant environment. Please note the FedRAMP-approved cloud shall require a Department/Agency-level Authorization to Operate (ATO), followed by the FSA-issued ATO for the system, which shall be FISMA and/or FedRAMP-approved at either a Federal Information Processing Standard (FIPS) - 199 High level or Moderate level, depending on the proposed architecture and corresponding FIPS-199 category of the system.

Special Notices

1. Hosting and Infrastructure: All vendors are hereby placed on notice that FSA, in seeking to comply with Federal IT Acquisition Reform Act, ED’s Strategic IT goals, as well as Office of Management and Budget’s (OMB)-mandated goals established in the Data Center Optimization Initiative (DCOI), may require all new applications and information systems, once created and stabilized, to transition to and leverage common cloud infrastructure services (e.g. through FSA’s Next Generation Data Center (NGDC) or some other FSA-identified services), and/or leverage common enterprise-wide traditional data center services and infrastructure hosting provider (e.g. through FSA’s NGDC or some other FSA-identified services/provider). The NGDC program provides a physical data center structure, access to FISMA High private cloud infrastructure services, and access to FedRAMP High and FedRAMP Moderate cloud infrastructure services, including Amazon Web Services (AWS) and Azure.

2. Middleware: All vendors are hereby placed on notice that FSA, in seeking to build a future state environment with a consistent, reliable, and scalable architecture; prevent duplication, redundancy, and incompatibility; and reduce costs and complexity, reserves the option to require all new applications and information systems, once created and stabilized, to transition the underlying enabling technologies, technology stacks, and platforms to and leverage FSA’s Enterprise Middleware Architecture & Services (EMAS) program, for middleware and cloud platform management, services, and support. At present, EMAS includes Integrated Technical Architecture (ITA) and Enterprise Service Bus (ESB), future middleware capabilities, as well Platform-as-a- Service services support in the cloud.

Section 6103 of Title 26 Internal Revenue Code as it pertains to Eligibility Determination.

The technical and operational components of the Award Eligibility Determination Processing System contract resulting from this solicitation shall have the ability to support the implementation of the Fostering Undergraduate Talent by Unlocking Resources for Education (FUTURE) Act (P.L. 116-91). The FUTURE Act amends Section 6103 of the Internal Revenue Code and allows the Internal Revenue Service (IRS) to provide certain taxpayer information to ED for the purpose of administering certain federal student aid programs authorized under Title IV of the Higher Education Act (HEA). The FUTURE Act, among other objectives, aims to:

• enhance the Free Application for Federal Student Aid (FAFSA®) experience by allowing ED to automatically obtain federal tax information (FTI) for each applicant, parent, or spouse who provides consent.

• improve program integrity for income-driven repayment (IDR) plans and total and permanent disability (TPD) discharge monitoring.

• leverage FTI for reducing the net cost of improper payments, managing oversight activities, and conducting analyses and forecasts; and

• provide an improved experience to ED’s more than 43 million customers.

The IRS is implementing the FUTURE Act–Direct Data Exchange (FA-DDX) solution, which will establish a secure connection between both agencies through an application programming interface that will process FSA’s batch and real-time FTI requests. The selected will need to support and manage the design, development, implementation, and operations of the centralized calculation engine (CCE) component of the FUTURE Act, which will receive FTI from the IRS through the FA-DDX solution and enable FSA to accurately determine the customer’s eligibility for various federal student aid programs. Additionally, the CCE component will also leverage interfaces with other FUTURE Act solutions such as the FTI Data Mart to allow FSA and FSA’s partners—schools, U.S. Department of Education agency staff—to view and access customer FTI. As part of implementing the FUTURE Act’s CCE component, the contractor shall comply with the standards and guidelines outlined in IRC §6103 (p)(4), in accordance with IRS Publication 1075: Tax Information Security Guidelines for Federal, State and Local Agencies.

Additionally, the contractor shall comply with any applicable provisions under IRC §6103 that FSA is required to meet as conditions for receiving FTI from the IRS.

The contractor shall work collaboratively with the IRS, FSA solution developers, and other contractors who are implementing various components under the FUTURE Act on items that include but are not limited to the following:

• responding to requests for information from the IRS and/or other relevant government agencies/contractors;

• supporting efforts related to the FA-DDX solution;

• ensuring the effective and seamless integration of the CCE component with various

FUTURE Act solutions, including the enhancement, operations, and maintenance of the

CCE;

• being proactively knowledgeable of all safeguards and cybersecurity; and

• supporting FSA and other contractors, as needed, with requirements, analysis, and planning efforts that impact any initiatives that involve the IRS.

Significant requests for information or changes will be performed through a change request process.

Regarding these Special Notices, any future changes will be managed through FSA’s Change Management Process that will be identified in the contract.

Identity and Access Management: Solution shall use FSA’s chosen Identity and Access Management (IAM) solutions for authorization, authentication, Single-Sign-On (SSO) via standards-based federation, self-services, and identity management. This will enable FSA to build a future state environment with a consistent and scalable set of security services for provisioning and managing all users, including AED personnel, other vendors or third parties, and FSA staff – implementation timing to be agreed with FSA.

Performance management: Contractor shall adhere to FSA’s Performance Metrics and shall include performance management mechanisms that would enable improved and ongoing achievement of metrics. FSA will utilize random sampling of accounts and reports to support EPS Performance Management. A set of defined performance metrics will be established as service level agreements (SLAs). FSA will establish performance metrics that the Offeror shall agree to prior to award. In accordance with FAR 16.402‐2 Performance Incentives and FAR 16‐ 402‐3 Delivery Incentives, Attachment “21 ‐ Performance Measurement Template” establishes the required performance metrics and associated targets that will be used by FSA to measure vendor performance against Next Gen vision and goals to include, but are not limited to:

i. Providing effective and efficient customer and partner experience;

ii. Improving operational flexibility;

iii. Driving greater operational efficiency;

iv. Improving financial and portfolio management;

v. Timely and accurate migration of accounts; and

vi. Improving customer outcomes and facilitating compliance with federal consumer protection laws and regulations, and Title IV legal requirements.

FSA will have dedicated resources to monitor vendor accountability and performance to ensure a high caliber of service delivery across the operating environment.

To see FSA’s developed SLAs, please see the attachments.

Quality control: Solution shall be supported by documented policies and procedures on vendor quality management system to ensure that more efficient and effective service can be provided.

Software licenses: Commercial software licenses acquired under this contract shall be transferable to the government.

Technical Support Help Desk: Solution shall provide a Tier II Technical Support Help Desk, including Technical Support Representative (TSR) staff for the solution to address technical issues with the solution or data generated. TSRs shall provide assistance and information to the users of AED-developed software products, including EDExpress, Direct Loan (DL) Tools, and FAA Access functionalities. TSRs shall also provide technical Assistance to software user.

Specific types of assistance covered under this solution shall include but not limited to:

• Providing processing information concerning FAFSA data;

• Resolving application and correction errors;

• Supporting the use of the EDExpress and Direct Loan Tools software products;

• Assisting in SAIG enrollment for the electronic transmission of batch services using an

FSA specific enrollment site

• Assisting with the Application Test System for third party software vendors

Tier I support will be provided by a separate the Business Processing Operations contact center support solution.

Transactional Data Integration: The solution shall provide transactional level data into FSA’s EDMAPS environment. Solution shall be responsible for developing the retrieval and processing solution working within the overall EDMAPS architecture.

Data Conversion: Solution shall plan to convert existing Eligibility (Central Processing System [CPS]) data and records necessary to effectively support future Eligibility functions. See FSA Deliverable Table C.2.4.2.

Continuous Improvement: The contractor shall provide a plan on how they will identify, analyze, propose, initiate and implement minor system enhancements at no charge to FSA and process improvements to continuously improve the customer experience, efficiencies and effectiveness of their solution. Offeror shall describe their Continuous Improvement approach as part of the Technical Proposal Volume L.15.2.

Independent Performance Testing: The contractor shall work aligned with FSA’s performance testing contractor to support independent performance testing of the solution. This includes but is not limited to establishing an independent performance testing environment, providing data set up as required to support performance testing, deploying an operational version of the solution, providing access to independent performance testers to monitor performance, support for identifying and defining performance testing scenarios and addressing performance testing issues identified.

User Acceptance Testing (UAT): The contractor shall develop tools and processes and provide support UAT in collaboration with FSA. The scope and nature of this testing is inclusive of all development and any operations and maintenance for the duration of the contract. It will be sufficiently comprehensive to ensure the completeness, quality, and adequacy of all deliverables.

The contractor shall provide UAT Test Data and File Mock-ups based on data requests submitted by FSA for the fulfillment of related NextGen products (for example but not inclusive of the FAFSA.gov and mobile application in the Digital Customer Center). UAT Test Data shall be provided to FSA based upon an agreed upon schedule between the contractor and FSA.

The Contractor shall support the FSA’s user acceptance testing after successful completion of Contractor testing. The Contractor shall provide supplemental UAT testing resources specialists to assist with UAT related testing activities to ensure all system components are tested at multiple integration levels to verify the functionality and completeness of the system.

The Contractor shall provide UAT Test Suites - test scenarios, test cases and test scripts for a solution or system under test.

• All test suites and test cases are mapped back to requirements.

• User Acceptance Test (UAT) Plan and test scenarios/scripts for users’ portion of the UAT.

• Establish test data and maintain the test environment and maintains UAT Defect

Log.

• The User Acceptance Test Summary Report summarizes the user acceptance test phase of the project. It must provide an overall assessment of the product tested and status of incidents occurring during user acceptance testing.

Contractor Support: The contractor shall support Federal Student Aid sponsored and business-related conferences and meetings. This may consist of usability studies, user research efforts, presentation development, webinar development, question and answer panel participation, and conference attendance.

The services and deliverables provided for the FSA Annual Fall Conference support shall include various professional services, development of presentations, and training. Contractor shall provide training to schools and FSA personnel. As part of FSA’s request for Conference Support, the contractor shall provide a list of potential conference support participants inclusive of their specific roles and responsibilities.

Travel and other ancillary expenses for school visits, conferences, and other special travel shall be negotiated before the subject event and billed as Other Direct Costs or Travel.

C.2.3 Operating Elements and Related Requirements

FSA seeks a technical solution addressing functions for Award Eligibility Determination.

C.2.3.1 Operating Element: Award Eligibility Determination Processing System. FSA seeks a more efficient and effective solution that shall accurately and efficiently determine eligibility for federal financing, based on applicable laws and regulations, by in-taking and processing various data sources for eligibility determination and calculates an Expected Family Contribution (EFC). The EFC data is then disseminated to financial aid offices at postsecondary schools who use the data to determine federal student financial assistance through various grants and loans and performs analysis for various uses by FSA and its partners.

Functions include but are not limited to:

• Development, Implementation, Integration and Deployment

• Application management

• Eligibility Determination

• Results Distribution

• Data Sharing

• Statistical analysis support

• Administration

• Additional Tasks

System and Software Development – Annual Release of the FAFSA Application

The Annual Release of the FAFSA application shall be deployed no later than October 1st of the year prior to the start of each award year or as directed by FSA. The activities and effort that are associated with the Annual Release of the FAFSA Application fall into the following two categories:

• The first category is the effort required to make changes to the system and services to enable the processing of an additional award cycle, commonly referred to as Annual Releases.

• The second category is the effort involved in making changes to the system and services that address deficiencies and enhancements to ensure the delivery of quality services as a part of the annual development process.

Currently, FSA utilizes a “cycle” approach to determine eligibility of aid to the school year students plan to attend. Each cycle provides an opportunity to update the application, incorporate regulatory changes, and make other desired and necessary changes. Within an application cycle year, there are two types of scheduled releases 1) cycle start-up and 2) point releases. Point releases include various types (i.e. production/code corrections, enhancements, and FAFSA application and correction shutdowns). At any given time, there are 2 active FAFSA cycles and 1 cycle underway: 1) Planning and development for an upcoming FAFSA cycle can take up to 13 months, August of the previous year through September of the year the new FAFSA will be released into production), 2) Operations and Maintenance of the current FAFSA cycle (21 months, October through June of the following year) and 3) Close out of the previous FAFSA cycle (2-3 months, July through September of the current calendar year).

For example, the planning and development for the upcoming 2021-2022 FAFSA cycle began in August 2019, this FAFSA cycle will deploy on October 1, 2020, and will be in production operating through the end of June 2022, (21 months later) as it then enters close out activities through late September 2021 (aligned with the end of a student’s academic year of summer sessions in late August). This is an example of the development cycle. FSA is open to other approaches and offerors are encouraged to propose their view of a highly flexible progressing system to meet and/or exceed FSA’s Next Generation vision.

FSA seeks proposals for a more nimble, modular, flexible, and self-service platform where changes can be easily, efficiently, and quickly incorporated by FSA personnel as desired and with routine, continuous and frequent vendor development in a shortened desired release schedule and able to be integrated and aligned with other Next Gen environment solutions.

Outcomes Solution shall meet outcomes and associated targets, supporting FSA’s vision and goals that will be incorporated into the AED Contract These outcomes include, but are not limited to:

• Flexible and adaptive solution: how quickly (i.e., number of days) eligibility rules can be modified on the solution

• Minimal error rate: software and system corrections made quickly and accurately

• Rapid results sharing: for an applicant’s eligibility data to be disseminated through FSA’s environment and the Next Gen solutions

Offerors shall complete Attachment “19 – Performance Measurement Template” to propose their targets for outcomes. See Section L.15.4.1.7 for instructions on completing Attachment 19.

1. Development, implementation, and integration: Solution shall provide a system in order to develop and process an annual Free Application for Federal Student Aid (FAFSA®) that has FSA’s student eligibility data. Solution shall effectively integrate with the future state digital platform, through which customers and partners will primarily engage with FSA, including the application portion of the lifecycle of student financial assistance. Additionally, solution shall:

a. Provide infrastructure required to process student data submitted through multiple channels, including web, mobile, and paper forms, in addition to third-party software applications via Electronic Data Exchange.

i. The solution shall provide pre-populated functionality availability to FAFSA.gov and mobile users that require certain system functionality of data variables.

b. Provide FSA personnel and its authorized users the ability to receive, test, and implement FAFSA changes and error fixes easily and efficiently.

c. Provide processing functions and data to enable application status and plain language rationale for notifications or rejections to be tracked and accessible to applicants and other approved parties.

d. Expose relevant services through FSA-designated solutions, e.g., Responsive Web Applications (RWA), Enterprise Service Bus (ESB).

e. Provide a method for schools and third parties to be able to provide FSA with all student’s data.

2. Application Management: Solution shall be designed flexibly to accommodate rapid changes and effective integration with other FSA solutions. The solution shall:

a. Have a flexible architecture which can be easily and rapidly adapted for changes in eligibility requirements, data sources, and additional business rules as determined by FSA.

b. Provide capabilities to support and submit applications for re-processing as instructed by FSA.

c. Maintain and provide access to the prior years of FAFSA data, in accordance with federal records management regulations, in a user-friendly manner for designated users.

d. Provide capabilities for FSA to review, grant, make corrections and resubmit aid eligibility applications deemed ineligible that require additional computer automated matched or if not possible manual intervention with, but not limited to other federal agencies that have agreements with FSA including but not limited to: Department of Defense, Department of Justice, Department of Homeland Security, Social Security Administration and Internal Revenue Service.

e. Provide capabilities to resolve student identity conflicts.

3. Eligibility determination: The eligibility process is a high-level business process that uses various data point inputs both from within the Department’s databases and external federal databases (i.e., computer matching agreements) from various data sources (i.e., FAFSA on the web, FAFSA mobile, paper forms, and FAA Access) to produce outputs for various eligibility components (i.e., Student Aid Report (SAR), Student Aid Report Acknowledgement (SAR ACK)). The eligibility process determines both an individual student's initial and ongoing qualification for federal financial aid. The eligibility process is organized around three major components which it interacts with: 1) web applications, mobile, paper and EDE, 2) the eligibility system, and 3) PC software.

Determining eligibility centers on six core sub processes: it receives the inputted data, processes the data, performs the edits, executes matching, accurately calculates the Expected Family Contribution (EFC), disseminates data to students, schools, and other FSA systems and agencies and conducts verification selection. Determining eligibility also goes through other FSA systems that provides pre-screening financial aid history data, post-screening for changes in financial aid history data (NSLDS), and receipt and storage of demographic data (from the processed Institutional Student Information Report (ISIR)) for institutional research in order to provide accurate determination of a student’s eligibility. The solution shall:

a. Collect and process new, renewal, or correction applications.

b. Process inputs from federal agencies, other existing and future FSA solutions, and other internal and external sources.

c. Provide capabilities to conduct the federal agency matching operations as per the matching agreement cycles.

d. Provide singular view of a student’s history with FSA (multi-year applicant data).

e. Provide FSA personnel and/or its authorized users the ability to easily and efficiently add, delete or modify Eligibility Rules and Requirements.

f. Include the capability to re-process past eligibility determinations as deemed necessary by FSA.

g. Include demonstration, practice, and testing functionalities which can be used by FSA staff, school partners, or other designated third partners.

4. Results Distribution: Solution shall generate eligibility determination results for applicants, school partners, and other authorized recipients. The solution shall:

a. Enable results to be shared, as close to real-time as possible, with appropriate parties and other FSA systems through secure file exchanges, interface files, and support the legacy APIs.

b. Have the ability to modify existing APIs or build new APIs to connect, interact and interface with other FSA Next Gen solutions (e.g., Digital Customer Care solution or Partner Participation and Oversight solution).

c. Support the dissemination of the results through communications executed by separately provided solutions (e.g., digital platform, Customer Outreach and Communications, digital marketing, printing, and mailing including English and Spanish language).

d. Provide print, mail, and Image Data capture (IDC)capabilities included by not limited to:

i. Mail all system-generated and hard copy documents to the customer, as applicable.

ii. Provide postage services for operations’ mailings.

iii. Provide IDC services in the form of mailroom duties, scanning, data capture/validation, and (hard copy) records management, and exception processing. The IDC system integrates with the Eligibility Determination system to provide data and receive confirmation of processing. The paper forms processed by IDC include:

1. FAFSA Application

2. SAR Correction

3. Signature Page

4. History Corrections on Non-standard Document

5. Data sharing: Solution shall ensure the secure exchange of files and data between FSA solutions and with relevant parties (e.g., but not limited to schools, other agencies, third-party servicers, and Guaranty Agencies [GA]). The Solution shall:

a. Apply data format, usability, access, and management standards in accordance with industry best practices and FSA requirements.

b. Enable continuous, real-time or near real-time exchanges of data with FSA’s Next Gen solutions, existing FSA solutions, and external parties to support the administration of FSA programs (e.g., providing enrollment capabilities to FSA systems and systems of other Federal agencies through FSA systems like the Participation Management/SAIG Enrollment system for schools and other eligible trading partners (Third Party Servicers, Federal Loan Servicers, Guaranty Agencies, State agencies etc.) accessing student inquiries, enabling record requests, and reporting applications and corrections) by schools who need to interface with the solution.

c. Integrate with and use existing and future Identity and Access Management solutions as determined by FSA.

d. Provide capabilities to support problem and incident management for those issues requiring collaboration in a multi-vendor environment.

6. Statistical analysis support: Solution shall provide capabilities to create and deliver all the data necessary for FSA to conduct statistical analysis of eligibility determination rules and processed logic to ensure accuracy and consistency as well as support compliance and reporting needs. The solution shall be prepared to provide answers to any questions regarding the data provided to FSA for analysis. The solution shall:

a. Provide capabilities to conduct analyses to drive continuous and consistent improvement of eligibility rules.

b. Provide capabilities in order for FSA to prepare internal data samples for analysis and inclusion in reports including, but not limited to:

a. Requirements the business rules and the verification model (by comparing a control group to verified filers);

c. Make IRS Statistical Data available to FSA which evaluates the accuracy of applicant reporting and determines potential Pell misallocated awards;

d. Include Fraud Detection Analysis which compares FAFSA data to IRS data, and other data sources, to determine discrepancies and identifies suspicious patterns that may indicate potential fraud rings; and

e. Provide end of year reporting which provides end-of-year data on Title IV applicants, Federal Pell grants, and TEACH grants.

f. Solution shall allow schools to access student demographic data records to allow them to build the information available on the ISIR.

7. Administration: Solution shall provide operational upkeep and maintenance for all aspects of the solution, including, but not limited to operational interfaces and tools to be used by FSA staff and partners, and databases. Solution shall:

a. Be operated cost efficiently and at the appropriate scale as eligibility determination volume fluctuates throughout the year. Solution shall effectively work with other providers to implement required modifications for peak periods.

b. Include a robust maintenance and troubleshooting approach to ensure minimal customer and operational disruptions. Solution shall resolve identified issues or requested modifications in a timely manner.

8. Additional Tasks:

The solution shall:

a. Automate all possible functions to minimize manual processing. Solution may only rely on streamlined manual processing by the separately provided AED in the cases where automation is not feasible. However, Solution shall provide personnel to do manual processing related to financial functions, interface support (i.e. COPPA and the incarcerated population), and error/dispute investigation and processing to be performed at the portfolio level. This includes staff to manually update for items that require immediate remediation.

b. Provide personnel AED “trainers” to be trained by the AED itself in order to provide support to the technical help desk that will support the technical users of the AED solution, the Student Aid Internet Gateway (SAIG), and other Next Generation systems regarding FSA application data, system data and functionality, and any technical issues. They will also support and coordinate the FSA Listserv process with FSA staff – though the FSA Listserv application which is operated by the Department of Education. The contractor will have to coordinate with internal FSA teams and the processing system to gather required data for the FSA tech server response.

i. Trainers shall then coordinate onboarding and refresher training for respective solution’s other personnel.

ii. Manage school customers inquiries and responses submitted through the FSATech listserv system.

c. Provide data capture & paper document digitization of high quality and accuracy so that the digital images become the official record and FSA can dispose of the paper docs eliminating storage fees in order to fulfill capabilities to process data from captured paper aid applications.

d. Print, assemble, and mail all system-generated and hard copy documents to the customer, as applicable. Printed documents include SARs, SAR Acknowledgements, and subsequent application letters. The contractor shall provide Not-to-Exceed amounts for printing based on estimated annual volumes.

Printing shall be funded up to the Not-to-Exceed amounts for each contract year in the annual contract price. Additional printing shall require additional funding to the contract. For the Base Year of the contract, for AEDS print images the annual volume expect for mailing is 4,571,128. In addition to this, all SARs shall be mailed within 4 business days of receiving the print request from CPS.

e. Provide capabilities for school and trading partner interfaces (i.e. EDESuite, Participation Management/Student Aid Internet Gateway (SAIG) enrollment system) including any manual loading of software releases when applicable.

Deliverables Deliverables shall be provided electronically whenever possible. Electronic delivery via e-mail shall be acceptable, with the deliverable files in both Acrobat (.pdf) and a current Microsoft Office format suitable for the report (Word or Excel) unless FSA requests a different format.

Deliverables shall be submitted to the Contracting Officer, the Contracting Officer Representative (COR), Program Manager, and Project Manager. The Government will review each deliverable and provide written notice of acceptance or rejection within ten (10) business days upon receipt. The Government will review the deliverable to determine that:

• It addresses the government’s requirement and meets the acceptance criteria.

• It is organized appropriately and written clearly and free of grammatical errors.

• It is formatted in both Microsoft (MS) Word or Adobe Acrobat or other acceptable format such as MS Excel, MS PowerPoint, or Microsoft Project.

• It adheres to industry (e.g., PMI PMP®), government (e.g., FISMA, NIST), and FSA standards, guidance, and regulations (e.g., Lifecycle Management Methodology (LMM), Management’s IT assessments as a function of security authorization, formerly certification and accreditation from FSA Technology Office), as applicable and related to documentation content, format, quality, and contractual terms.

Upon notice of formal written rejection from FSA’s CO, the Contractor shall address all comments/changes and submit a revised deliverable within five (5) business days if the changes can be easily addressed and understood by both the Government and Contractor. If the deliverable is rejected and/or must be altered to significantly change the deliverable, the Contractor shall have seven (7) business days to resubmit from date of the Government’s notice.

The Contractor shall furnish deliverables specified herein in accordance with the delivery schedule and requirements, to the delivery point(s) specified in the table below. If a deliverable is due on a calendar day that falls on a weekend day or a Government holiday, the deliverable or report is due the following business day.

Deliverables Table

Deliverable Description and Acceptance Criteria Due Date and Frequency

1. Kick-Off Meeting Kick-off meeting to introduce key personnel, stakeholders and their roles/responsibilities; discuss scope and project milestones, third-party dependencies;

review the activities required to initiate and manage the contract; and inform the team of necessary administrative items such as team contact information and define meeting cadence.

Agenda, Presentation, Meeting Minutes and Action Items required.

Within five business days of award.

2. Status Reports, Meetings and Meeting Minutes

Status report details on progress, performance metrics, schedule, incidents, Weekly – Standard day/time for reports and meetings to be determined but reports due action and issue log, and risk log/risk register.

Report and meeting provide a narrative review of work accomplishments and/or significant events for prior week; indicates outstanding and completed deliverables and work products, risks, staffing status and project schedules; and documents any technical performance problems or challenges and the steps being taken to correct them. All necessary personnel are available for the Weekly Status Meeting and can fully discuss and respond to questions from the Government.

Weekly Status Meeting Minutes provided after each status meeting.

one day prior to the weekly status meeting.

Minutes due one business day after weekly status meeting.

3. Program Management Plan

Program management plan that details the approach, controls, processes, and efforts that will be utilized to effectively organize and manage all work required.

Includes Scope Management Plan, Cost Management Plan, Risk Management Plan, Quality Management Plan, Staffing Plan, Schedule Management Plan, Communication Management Plan, Performance Management Plan, and Performance Monitoring Plan.

Details the Program’s organization; assignment of management functions, duties, and responsibilities with escalation procedures;

With Proposal

Redeliver 30 days after contract kickoff with appropriate updates.

applicable management policies and procedures;

staffing approach; and reporting for conducting contractually imposed tasks.

4. Performance Measures Service level agreements (SLAs) and key performance indicators (KPIs) based on industry best-practices and organizational experience to meet NextGen program goals and vision.

With Proposal

Redeliver 6 months after contract kickoff with appropriate updates.

5. Requirements Management Plan

Defines how requirements will be elicited, structured, and prioritized; how requirements will be recorded; how requirements will be modified; and how requirements will be traced and reconciled.

Clearly assigns roles and responsibilities for requirements management throughout their lifecycle.

The plan also clearly addresses how requirements will be managed as a configuration item, and what tools will be utilized to support any and all aspects of requirements management.

Initial plan to cover all system functionality at least twenty days prior to Requirements Stage Gate.

Updated for each release;

Final version for each release delivered prior to Requirements Stage Gate.

6. Requirements Documents Requirements are clearly articulated and testable.

Requirements (and their grouping and prioritization) are enough to plan further elaboration and are accepted by the Program/Project Owner.

High Level Requirements address the breadth of coverage and provide at least a preliminary description of how requirements may be

Initial documents to cover full system functionality at least ten days prior to Requirements Stage Gate.

Final version for each release delivered prior to Requirements Stage Gate.

grouped into releases and iterations.

Users Stories or Prototypes to facilitate functionality and feature development - short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

The Detailed Requirements Document captures detailed functional and non-functional requirements in the form of declarative statements, uses cases and other requirement artifact types as applicable to the project. Requirements in this document are captured at the level from which they can inform design and development.

The Requirements Traceability Matrix (RTM) ensures bi-directional traceability between high level/business and detailed/system requirements.

The RTM also associates detailed/system requirements with portions of the build designed to satisfy them.

Testing is also tied to the requirements on which they are based to ensure that the build meets all requirements.

7. Data Migration Plan The data migration plan features a comprehensive migration strategy with a risk minimizing means of performing the migration.

Defines processes associated with completion of data

As needed, provided for each release; Final version for each release delivered prior to Requirements Stage Gate.

migration effort, including conversion strategies, data mapping requirements, data clean up, and testing.

8. Data Conversion Plan The conversion plan features a comprehensive conversion strategy with a risk minimizing means of performing the migration.

Describes the strategies involved in converting data from an existing system/application to another hardware and/or software environment, including data clean-up, and testing.

Within 30 days of development start, provided for each release; Final version for each release delivered prior to Requirements Stage Gate.

9. Solution Architecture and Detailed Design Document

Combines both a high-level and detailed view of the solution architecture -

• Includes description and diagrams of infrastructure, network, security, data, and application architectures.

• Addresses all Technical Quality Control (TQC) factors and sub-factors identified as applicable and in scope.

• Includes mitigation strategies for all risks identified in the Technical Quality Control reviews.

• Includes Interface Control Documents (ICDs) to document all interfaces between systems and subsystems.

• Conveys detail necessary to allow coders to develop the system, and to support

Draft due fifteen business days prior to Design Stage gate and annually thereafter.

Final version for each release delivered at least 5 days prior to Design Stage Gate.

critical design reviews before beginning development.

Design is consistent with requirements, Preliminary Design and Technology Standards. Proposed design is feasible and workable.

The architecture document would contain information about the backend architecture as well as the application architecture.

10. Developers Integration Guide

Documents how internal and external parties will integrate with and consume any APIs/services that are exposed.

As needed, provided for each release; Final version for each release delivered prior to Design Stage Gate.

11. Configuration Management Plan

An overview of the organization, activities, overall tasks, and objectives of configuration management; addresses:

baseline work products, describes the mechanism to track and control changes/change requests, and the mechanism to establish and maintain baseline integrity.

Ensures all interfacing systems are taken into consideration and doesn't conflict with existing CM's of other interfacing systems.

Final version for each release delivered prior to Test Readiness Review.

12. Master Test Plan Master Test Plan addresses all aspects of testing covering all functional, nonfunctional requirements covering all phase level test plans. Details high level and overall test planning and test management.

Initial test plan to cover full system functionality at least ten days prior to Test Readiness Review.

Final version for each release delivered prior to Test Readiness Review.

• Includes System, User Acceptance, Performance, Inter-system, etc. Test Plans

• Master Test Plan includes objectives for the security control assessment and procedures for testing each security control

13. Testing Documentation Test Suites - test scenarios, test cases and test scripts for a solution or system under test.

• All test suites and test cases are mapped back to requirements.

Reports address the results of testing, provides a summarization of the test effort and a final assessment.

• The System Test Summary Report must summarize the system test phase of the project and include support materials related to version,…