Attachment 2_FSA Modernization RFI QA_071425_V2.docx

Anticipated Vendor Questions and Answers (Q&A) This Q&A assists vendors in understanding the Request for Information (RFI) and Federal Student Aid’s (FSA) needs. The Q&A is provided for informational purposes and will be updated if needed.

1. Q: Is FSA looking for a single vendor to provide an end-to-end solution, or could this modernization be split among multiple vendors (e.g., one for integration platform, another for front-end, etc.)?

A: At this stage, Federal Student Aid (FSA) is open about the execution approach. FSA welcomes both turnkey solutions from single providers as well as specialized solutions that could be integrated. Our goal is a cohesive system. If your response involves multiple vendors or a consortium, please clarify the roles and how you would manage integration and accountability. FSA has historically managed multiple vendors, but FSA is interested in governance models that ensure unity of vision (e.g., a lead integrator model). Additionally, no decision has been made yet on the procurement strategy (e.g., single award vs. multiple); and this RFI could inform that decision.

2. Q: Will the Government provide access to current system documentation, architectures, data schemas, etc., to help vendors understand the legacy systems in more detail—either now or in a future Request for Proposal?

A: For the purposes of the RFI, FSA provided as much detail as possible under “FSA’s Current State and Associated Challenges” and “FSA’s Current and Legacy Systems Overview” of the RFI. FSA understands that the additional technical details (e.g., architectural diagrams, data models, interface control documents) may be needed for a fully informed response to the RFI. If FSA issues a solicitation, FSA intends to provide more comprehensive documentation of FSA’s existing environments to qualified bidders under a secure process. However, if there are particular details you believe are critical, you may note those in your response to the RFI.

3. Q: Is the scope of this modernization expected to include the student loan servicing platform, or is it limited to the “systems of record” (Central Processing System (CPS)/ FAFSA Processing System (FPS), Common Origination and Disbursement (COD) System, National Student Loan Data System (NSLDS), etc.)?

A: The primary focus of this RFI and the anticipated modernization effort is on the core systems that process and store student aid data – essentially the systems of record and data infrastructure mentioned. While the loan servicing systems (i.e., the systems used by loan servicer contractors to manage borrower accounts and process payments) is currently managed through the Unified Servicing and Data Solution (USDS), FSA is looking for ideas on how to enable FSA’s Technology Goals as enumerated in the Request for Information across FSA solutions, including servicing systems. More specifically, modernized systems should be designed to interface smoothly with servicers including feeding data to/from servicers or eventually maybe incorporating servicing data into the central data repository.

4. Q: Can vendors propose commercial off-the-shelf (COTS) products or cloud services as part of the solution or is FSA looking for a fully custom-built solution?

A: FSA is very much open to COTS, Software-as-a-Service (SaaS), or Platform-as-a-Service (PaaS) components if they meet our needs. FSA does not want to reinvent the wheel if there are proven products that can be configured to meet our requirements. For example, a COTS financial aid management system, a CRM for student interactions, or a cloud-based data analytics platform could be parts of the solution. If you recommend COTS/SaaS, please address how it would integrate with other components and any limitations (e.g., customization capabilities, vendor lock-in). While any commercial solutions must be compliant with federal security and privacy requirements and be FedRAMP authorized if the solution is cloud-based, FSA is open to gaining insights about non-FedRAMP authorized solutions if there is a plan in place to get the solution FedRAMP authorized. FSA is also conscious of cost, so licensing models should be clearly explained. In summary, mixed solutions are fine (i.e., you might propose a custom integration layer using open-source tech while using a COTS product for analytics or case management) as long as you are clear about each component in your proposed architecture.

5. Q: How should we handle cost information in the RFI response? Is FSA asking for budget estimates or detailed pricing?

A: No cost or pricing information is required in response to this RFI. In fact, FSA prefers that you focus on technical and strategic aspects. If you want to speak to cost efficiency in a qualitative way (e.g., “our approach reduces O&M costs by consolidating systems”), do not include any pricing information. This is not a Request for Proposal; and FSA is not selecting vendors or solutions at this stage. FSA is mindful of cost and any future procurement will consider total cost of ownership so if there are cost-related insights (e.g., “a phased approach could allow FSA to spread investment over X years” or “retiring System Y could save $Z million annually”), you may mention those in general terms; but again, no formal cost or price proposal should be submitted as part of your response to this RFI.

6. Q: Will the modernized system be hosted in a government cloud environment (e.g., FSA’s own Amazon Web Service/Azure environments), or should vendors propose hosting?

A: It’s likely that FSA will require the solution to be deployed in an environment where the government has direct ownership for security and governance. FSA is not looking for vendor-provided data center hosting. However, you should specify the cloud architecture and services you would utilize. For example, if you propose AWS, detail which AWS services (e.g., Elastic Compute Cloud (EC2), Relational Database Service (RDS), or Lambda) and how they’d be configured. If multi-cloud or hybrid, explain that too. FSA expects the solution to be cloud-first and meet federal Cloud Smart guidelines. The exact hosting arrangement (i.e., Government furnished vs, contractor managed) can be determined later. It’s anticipated that FSA will want the proposed solution to be in a Federal Risk and Authorization Management Program (FedRAMP) Moderate authorized environment. If you have a cloud environment that is FedRAMP authorized and want to propose a solution running there, you can mention it; but ultimately data and operations must meet federal security controls and FSA’s oversight requirements.

7. Q: What is the role of FSA’s internal Information Technology (IT) team versus contractors in this effort? Will FSA provide a team or expect a team to work alongside the contractor; or is the contractor expected to handle everything (e.g., design, development, and implementation)?

A: FSA has internal IT resources, including enterprise architects, developers, designers, security officers, project managers, and subject matter experts for each existing system. FSA anticipates a collaborative and integrated effort. A contractor (or multiple teaming partnerships) will likely be engaged to do the bulk of design and implementation work; but FSA will provide technical oversight, requirements input, be involved with development, and will remain directly involved in decisions. For example, FSA’s Chief Operating Officer and Chief Technology Officer will set certain guidelines and will need regular status updates. Additionally, FSA will also involve business units to define requirements and validate that the modernized system meets their needs. In your response, you can assume that you will have access to current system experts (e.g., the incumbent contractors for COD, NSLDS, and others during knowledge transfer) and that FSA will assign project liaisons to work with your team. However, FSA does not have a large in-house development team that could build rapidly build new solutions, so FSA will rely on industry for that heavy lifting. If you think certain tasks are best performed by federal staff (e.g., security, policy reasons or integration of DevSecOps tools), you can note that in your response to the RFI.

8. Q: Are there legacy system contractors that a new contractor would have to coordinate with? For example, if we propose replacing System X, how do we interface with the current contractor operating System X?

A: Yes, currently each major legacy system is supported by an external contractor. In a modernization scenario, FSA would facilitate coordination with those contractors as needed. For instance, if a new contractor needs to extract data from NSLDS or COD, the contractor maintaining those systems would provide data dictionaries, access to databases, and other materials under FSA’s direction. FSA anticipates including requirements in any future contracts for incumbent contractors to cooperate in data migration and transition. It is important to note that FSA would have to manage sensitivities and contractual boundaries. FSA can arrange government-led meetings to share information and ensure the new and old teams collaborate on transition planning. The RFI response can assume that data and knowledge transfer is achievable; but if you have specific needs (e.g., “we would need read-only access to the legacy databases for a period of 6 months” or “we would like to interview the legacy system architects”), you can state those as part of your approach. FSA wants to avoid a scenario where lack of legacy knowledge hampers the new implementation – so any strategies you have for mitigating that (like reverse engineering from code or leveraging documentation that should exist) are welcome.

9. Q: How will data migration be handled, especially if proposing a new system? Is FSA open to a phased migration (for example, migrating one system at a time) or expecting a full migration at once?

A: FSA is open to phased migration strategies. In fact, given the volume of data (millions of student records, billions of transactional entries), a thoughtful migration plan is crucial. If you propose a greenfield system, FSA would like to hear how you would migrate historical data from NSLDS, COD, and other FSA systems – possibly in chunks or by categories (e.g., move Pell Grant history first, then loans, etc.), or perhaps by cut-off date (e.g., start fresh for new awards and archive the old). FSA understands that not all historical data might need to be in the live system (e.g., some could reside in an archive or data warehouse if not frequently used). Feel free to propose an approach where, for example, active students’ data is migrated first, and legacy data remains read-only until needed. FSA plans to keep historical records accessible as required by law (e.g., financial records retention). The specific method (phased vs big bang) will depend on the design and risk tolerance in your proposed solution. FSA leans towards phased migration for safety such as old and new systems/databases in parallel for a period of time; reconciling results; and then switching over. If your solution inherently allows co-existence (e.g., new modules can read old databases until fully cut over), please ensure this is explained in your response to this RFI. Ultimately, FSA’s desired approach will hinge on ensuring data integrity and minimal downtime during the switchover. The RFI is a good place to share any innovative migration techniques you have used. FSA is aware that migration can be one of the hardest parts of modernization, so FSA is especially interested in how to do it with verification steps (i.e., ensuring no student record is lost or changed incorrectly).

10. Q: Given the sensitivity of FSA’s data, will there be any special requirements around using offshore resources or non-U.S. citizens in development?

A: Yes. While the solicitation if issued will specify this in detail, vendors can expect that all personnel with access to sensitive FSA data or systems must be United States citizens or lawful permanent residents (i.e., Green Card holders) located on U.S. soil. Offshore development or support that involves access to live data will likely be prohibited. There may be some flexibility for development work that uses dummy data; but even then, FSA prefers onshore delivery. Additionally, cybersecurity considerations and Department policy generally mandate U.S. citizenship for positions involving access to Department networks and systems. Vendors should plan to comply with personnel security requirements, which include background investigations for staff (e.g., NACI or higher-level background checks depending on the role). If your delivery model heavily relies on offshore teams, you would need to adjust that model for this project. Hence, it’s best to assume an onshore delivery model to avoid clearance and data handling complications. If there are any roles that you propose could safely and cost-effectively be completed offshore, you can mention them; but FSA will still likely require all key work to be done within the United States.

11. Q: What are the metrics that FSA will use to evaluate the technology modernization initiative’s success?

A: FSA will include specific performance work statement (PWS) metrics and or service level agreements (SLAs) if a RFP is issued. For this RFI, FSA seeks your recommendations on any Key Performance Indicators (KPI) that will enable FSA to evaluate the success of the Technology Goals outlined in the RFI. Some of FSA’s initial metrics include the following categories:

a. System Performance & Reliability: system uptime percentage; average response times; and ability to handle peak loads without incident. FSA would consider the modernization successful if FSA significantly reduces unplanned downtime (i.e., 99.9% or higher availability) and can process peak volumes faster (e.g., processing a FAFSA form in seconds instead of relying on overnight batch process).

b. Integration & Efficiency: reduction in the number of separate systems/databases; elimination of duplicate data entry or reconciliation tasks; average time to propagate data across systems; and cost savings in FSA’s operations. For example, integrating NSLDS and COD into one system is a measurable reduction in fragmentation.

c. Customer Satisfaction & Adoption: user satisfaction scores from surveys; reduction in call center volume for certain inquiry types (i.e., increasing self-service); and usage of online self-service tools. FSA will measure success through smoother product launches (e.g., minimal complaints from students, borrowers, and partners) through FSA’s contact centers and Customer Experience surveys. Additionally, FSA may consider the percentage of students who can complete aid tasks without needing school or call center intervention because the system guides them effectively.

d. Analytics & Outcomes: average reporting times (i.e., the time it takes to produce end-of-month or end-of-year reports); the breadth of data accessible for decision-making (e.g., number of data elements or domains unified); and evidence of data-driven decisions like FSA’s ability to quickly identify a trend and implement a policy change because of better data. While this is somewhat qualitative, FSA can set goals like “reduce time to generate Executive Reports from 2 weeks to 2 days” by having integrated data.

e. Security & Compliance: passing security audits with minimal findings; meeting FISMA metrics at a higher maturity level; and preventing major data breaches. Additionally, FSA will also look at how quickly our solutions can implement required security updates including the time that it actually takes (i.e., days instead of weeks) for the new system to patch vulnerabilities due to modern DevSecOps practices.