Amendment_0003_Revised_RFI_Data_Modernization 101024.pdf

Data Modernization Request for Information (RFI)

Amendment 0003: To revise RFI under Feedback Solicited, changes annotated in red font (pages 17-18).

Description and Purpose This Request for Information (RFI) is for planning purposes only and for Federal Student Aid (FSA) to determine available technology, sources or providers, and those providers’ capability to deliver the product, service, or capability described herein.

In its work to modernize FSA’s Title IV Financial Aid Origination and Disbursement (TIVOD) technology ecosystem, we are actively investigating new management and contract strategies/approaches, and additional technology implementations allowing the organization to (among other benefits) enhance and simplify existing data integrations, improve the quality and utility of existing data assets and borrower-facing products, allow for more efficient acquisition of additional data assets, maximize the capability to deliver reports and views to FSA stakeholders, and ensure appropriate compliance with data access, data labeling, and data security laws and policies. FSA envisions modernizing the TIVOD systems portfolio to benefit other segments of FSA’s Enterprise Architecture in the future.

FSA is evaluating the need for one or more future solicitations related to the systems, data instantiations, and/or ‘Challenge Areas’ noted in this RFI. FSA anticipates any future solicitation(s) would create value in the following areas:

1. The management and governance of FSA’s full data lifecycle,

2. The modernization of FSA’s data architecture and data engineering hard-technical ecosystem to attain desired strategic and compliance outcomes, and

3. The acceleration of FSA’s maturity in the integration of data assets to glean insights, improved program oversight, conduct proactive analyses, and facilitate evidence-based policymaking and positive customer outcomes,

4. The ability to decrease operational costs, while accelerating time-to-market for quality, high-value products.

This request for information does not constitute a solicitation and it is not an indication the Government will contract for any of the items and services discussed in this notice. Submission of a response to this RFI is entirely voluntary.

The voluntary submissions of answers to this RFI does not obligate FSA to pay or entitle the submitter of information to claim any direct or indirect costs, charges, or other compensation.

Interested parties are responsible for adequately marking proprietary, restricted or competition sensitive information contained in their response. Any information considered proprietary should be noted via appropriate markings.

Classified information and concepts shall not be submitted in response to this RFI.

The Government and its support contractor(s) will use information furnished in response to this RFI to inform and support planning and development of any potential solicitation and contract, or for such other purposes as described below. Classified concepts and information shall not be included in the submittal. FSA and its contractor consultants, who are bound by appropriate non-disclosure agreements, will review the information submitted in response to this

RFI.

There is a 35-page limit for this RFI response. The Government will not review any information or attachments included exceeding the 35-page limit. NO MARKETING MATERIALS ARE ALLOWED AS PART OF THIS RFI.

Generic or non-specific capability statements will not be reviewed.

FSA notes while respondents must conform to this RFI’s stated submission guidelines and specifications, respondents are not required to submit information for every area or question stated in subsequent sections of this RFI. FSA welcomes responses limited in scope to topics/areas in which a vendor holds expertise or experience.

FSA Background and Key Information Federal Student Aid (FSA), an office of the Department of Education (ED), administers all phases of the Federal student financial aid programs from a student’s submission of the Free Application for Federal Student Aid (FAFSA®) through retirement of student loan debt. In Fiscal Year 2023, Federal Student Aid delivered more than $114.1 billion to more than 9.7 million students attending approximately 5,600 postsecondary institutions. Federal Student loans have become a core component of postsecondary education financing, serving over 43 million student customers with a loan portfolio more than $1.6 trillion.

As part of FSAs continuing Next Generation (Next Gen) initiative, this RFI is aimed at modernizing legacy processing systems to improve operational flexibility; efficiently and effectively integrate new and existing capabilities and features; drive greater operational efficiency; reduce complexity; and improve the stability and cybersecurity of its technology ecosystem.

When referenced in this document, partners include institutions of higher education, state grant agencies, eligible and approved Guarantee Agencies, Federal Loan Servicers, lenders, and lender servicers, third-party software providers, third-party services, and Department of Education (ED) staff and its contractors.

Contractors may acquire more information via the Student Aid Data Center and FSA’s 2023 Annual Financial Report, linked below:

• https://studentaid.gov/data-center/student

• https://www2.ed.gov/about/reports/annual/2023report/fsa-report.pdf

FSA Challenge Area Statements:

FSA seeks to improve its position in the following ‘Challenge Areas’:

1. Data Architecture: FSA’s data is tightly coupled to its operational systems, and many systems serve as operational data stores or reporting/analytics platforms. Although FSA has integrated/centralized control over portions of its data and information ecosystem, its solutions do not cover the entire aid-lifecycle or all instantiations of data, and solution engineering does not allow FSA to fully decouple or fully integrate all data. Additionally, lack of data architecture/engineering standards decreases FSA’s ability to provide data governance and oversight to the distributed development teams. These factors contribute to challenges in overall data quality, integrating existing data assets, in obtaining or integrating with net-new data assets, in resolving latency issues, and in creating and optimizing an enterprise-wide modern instantiation of data fit for all required operational and strategic purposes.

2. Data Management and Governance: FSA’s organizational structure, enterprise systems, data instantiations, and product development and delivery environments are complex and highly matrixed. In addition to FSA-owned systems, the existence of FSA partner systems, contracted loan servicing systems, vendor-owned cloud tenancies, and several internal and external data interfaces present complications in designing, developing, implementing, and overseeing a unified data management and governance process spanning the full Software Development Life Cycle (SDLC) and data lifecycles. Although the Agency has significant ability to know, understand, manage, use, and govern its data assets, FSA still desires improvements in its ability to efficiently integrate data sources, establish positive control of all data assets, improve data quality, establish, and manage enterprise-wide Master Data Management capabilities, conform data to Federal and best-practice standards, and maintain optimal transparency in data lineage.

3. Data Security: For FSA to achieve its strategic and operational goals, and so it can ensure continued compliance with Federal laws, regulations and policies, and adherence to industry and Government best-https://studentaid.gov/data-center/student https://www2.ed.gov/about/reports/annual/2023report/fsa-report.pdf practices, FSA must continue to define and implement security-related data management frameworks, policies, and tools covering the entire data lifecycle across the entire FSA environment of platforms, tenancies, systems, networks, data instantiations, production pipelines, and analytics instances. FSA’s current challenges lie in working to identify and evaluate technology and best-practice data management/governance methods supporting enterprise-wide data labelling, data access controls, and the establishment and management of secure data analytics and system development sandboxes.

4. Servicing Data from Loan Transfers: Current-state batch and flat file-transfer protocols employed to transfer accounts between servicers represent a risk to FSA’s ability to provide historical continuity of servicing information. Additionally, data latency challenges from file transfers can result in black-out periods for borrowers as accounts are transferred and boarded. Such an occurrence limits FSA’s ability to proactively manage the student loan servicing portfolio and creates challenges in maintaining data quality and a concise and accurate historical record for the borrower. FSA desires to enhance its technological runway and operations, enabling faster, near real-time transfers of servicing assignments without the loss of historical data. While FSA envisions using Common Data Models (for data storage and data exchange), streaming services , and an FSA-controlled cloud-based data integration tool suite or data instantiation to help enable success, FSA has not yet developed an enterprise strategy or full-scale operational plans to implement change in a sustainable, incremental fashion.

5. Borrower Experience: FSA’s multi-faceted loan servicing operating environment also presents challenges to borrower outcomes and the Agency’s bottom line. FSA’s six contracted non-default loan servicers are responsible for managing the day-to-day interactions and overall repayment journeys of FSA’s direct-loan borrowers. An additional contracted servicer exists to manage defaulted loans. Each servicer has separate and distinct operations and technology infrastructure (e.g., websites, access credentialling, customer-care contact lines, cybersecurity postures). Further, a single borrower may have a presence in multiple systems, leading to inconsistency and redundancy in identity management and master data management. FSA seeks to enhance the integration and utilization of its pMDM system to address this challenge.

Although FSA has achieved great progress in unifying ‘back-end’ loan information for several workstreams and making information readily available to borrowers using a common design pattern in a one-stop dashboard (on StudentAid.gov’s ‘MyActivity’ dashboard), additional progress is desired. In addition to reducing the managerial effort and cost associated with current-state program and system/data interface change management, FSA’s goal is to create a truly unified StudentAid.gov borrower portal. Meeting this goal requires the integration of defaulted loan information, improved system performance and analytics, and greatly increased borrower facing functionality, i.e., scheduling, and making payments, changing due dates, managing personal information and documents, and evaluating scenarios/options for loan forbearance or repayment. This should all happen within Studentaid.gov.

To effectively solution and deliver these and other capabilities, FSA is also challenged to modernize the architecture and engineering (back-end) of its systems, the supporting data architecture, and the web-front-end portal.

6. Document Repository: Similar to challenges encountered with FSA’s structured data, official correspondence and documents are also impacted by lack of enterprise-wide integration between various FSA systems. Although several stakeholders and FSA systems have their own individual document repositories, a unified instance of borrower documents and correspondence does not exist. This results in a disjointed borrower record, unnecessary document transfers, undue additional data security and data retention risks, and makes it difficult to create a consistent user experience across the full student aid lifecycle. Although FSA has begun work on centralizing documents and correspondence, additional work is needed to migrate the myriad of repositories into a single instance and to create the needed integrations to support the various FSA and partner systems.

In the following ‘FSA Technical Sections’, FSA provides additional information about Current-state TIVOD systems, data architecture, and functionality, the established vision for Future/Target-state functionality (where possible), and other reference material useful in understanding FSA’s TIVOD systems operations. In the ‘FSA Technical Sections’, FSA also provides targeted ‘Technical Questions respondents should use in directing their responses to this RFI.

FSA Technical Section 1: Data Strategic Framework/Principles:

FSA’s Data Strategy FSA’s Data Strategy is based on the Data Management Association (DAMA) framework and leverages the Data Management Body of Knowledge (DMBOK). By following this strategy, FSA seeks to establish and improve upon effective governance strategies in managing the principal aspects of effective data management, including:

• Overall Data Governance

• Data Architecture

• Data Quality

• Data Modeling & Design

• Data Storage & Operations

• Data Security & Access

• Data Integration

• Document & Content Management

• Reference and Master Data Management

• Data Warehousing and Business Intelligence and Insights

• Metadata Management

The data strategy seeks to lay the foundation for and continuously improve upon our data management practices in alignment with Federal Data Management and the Department of Education standards including participation in the Department’s annual Data Maturity Assessment (DMA) reporting. The following document, originally developed in 2020, represents FSA’s current approach to managing current and future systems, application, data, reporting, analytic, and integration projects to align with Data Management Principals and Objectives above. See Attachment No. 1 titled “FSA Data Strategy v 1.0” for additional information.

FSA’s Data Management Principles and Objectives

• Create, maintain, and integrate high-quality large historical data sets, and make them available to FSA’s managers for insights, decision support and policymaking.

• Integrate as much transactional data as possible and develop centralized access to real-time 360-degree views of customers, and partners.

• Simplify, streamline and deduplicate data integrations between FSA partners while increasing resiliency, quality, performance, and timeliness in support of program requirements.

• Streamline the storage and retrieval of archival data; define and strictly follow associated storage, retention, and destruction policies.

• Manage data security centrally for the FSA organization.

• FSA will have improved data consistency and quality, the capability to deliver reports and views to even more teams within FSA, enhance and simplify data integrations, the ability to streamline fulfilment of data requests, and the capability to acquire and make available more datasets to enhance machine learning.

• Data Quality is the cornerstone to FSA’s organization. Throughout the National Student Loan Data System (NSLDS) and Enterprise Data Management and Analytics Platform (EDMAPS) environment, convenient and authorized access to reliable, resilient, and convenient access to high-quality data is critical to both FSAs internal and external stakeholders in fulfilling our mission.

FSA Technical Section 2: Enterprise Data Management and Analytics Platform (EDMAPS) and National Student Loan Data System (NSLDS) As a part of FSA’s TIVOD ecosystem, EDMAPS and NSLDS serve as centralized back-end data stores which share common query, reporting and machine learning tools. Additionally, both have databases interacting with customer facing applications using file-based integrations and real-time and near real-time APIs.

1. EDMAPS unifies data by providing centralized data management and access for student aid award and servicing data. EDMAPS has established several key data systems, databases, and support components.

Please refer to the EDMAPS diagram below for more details.

FSA’s vision for EDMAPS is to incrementally integrate and manage student aid award and servicing data for centralized or possibly virtualized access and storage. When this vision is fully realized, FSA will have improved data consistency and quality, the capability to deliver reports and views to even more teams within FSA, enhance and simplify data integrations, the ability to streamline fulfilment of data requests, and the capability to acquire and make available more datasets to enhance machine learning. The new EDMAPS will also have enhanced security coming from centralizing access, reporting, and logging.

2. NSLDS is a custom-built comprehensive national database of information about the Federal financial aid history of recipients of student financial assistance authorized under Title IV of the Higher Education Act of 1965, as amended. Information from NSLDS is used by stakeholders including the White House, Congress, General Accounting Office (GAO), Office of Inspector General (OIG), lenders, servicers, other federal agencies and most importantly, students and their parents, to provide a comprehensive resource on disbursed Title IV aid. Between 2019 – 2022, NSLDS was modernized and re-deployed within existing system boundaries.

FSA’s goal for NSLDS is to secure the services of a vendor to provide Operations and Maintenance (O&M) support for the NSLDS program enabling FSA to effectively collect and integrate customer Title IV aid data to support aid delivery and Title IV program management and oversight.

EDMAPS Current Data Architecture and Functionality (O&M) EDMAPS is hosted on the Amazon Web Services Cloud, with an increasing user base and growth in data. EDMAPS has processes to ingest, integrate, and store data from various sources and makes it available to users and systems.

Annually, EDMAPS submits around 132 service requests with an average of 6,255 hours, 50 change requests, and 64 bug tickets.

1. The Enterprise Data Warehouse and Analytics (EDWA) platform is a comprehensive collection of historical customers, loan and grant awards, partners, and servicing data used for analytics, reporting, fulfilling data requests, statistical and pattern-based predictive modeling, and machine learning. EDWA fulfills over 1,000 external requests annually.

a. Data Acquisition and Integration: EDWA receives customer data, student aid application and award data, partner, and enrollment data daily, and loan servicing data weekly. Incoming data is processed based on business rules specific to each data source to integrate them with EDWA.

Various methods and tools are used for replication, including file-based integrations via SAIG and the Apache Kafka tool, which is utilized and managed by Confluent for some data exchanges between internal and external systems.

i. The data in transit uses the latest Chief Information Security Office (CISO) mandated Secure Socket Layer (SSL) / Transport Layer Security (TLS) for encryption.

ii. The Contractor must implement Internet access via Trusted Internet Connections (TIC) or MTIPS (Managed Trusted Internet Protocol Service) in accordance with Office of Management and Budget (OMB) Memorandum M-19-26, Update to the TIC Initiative, September 12, 2019.

iii. The system provides mechanisms to integrate and ingest data from a variety of sources.

This can include support for Extract Transform Load (ETL) processes, as well as external tables to access data stored in the Amazon Web Service (AWS) data lake. The system allows for the creation and management of data integration and ingestion processes within the database.

b. Current Tools and Subscription Services

i. Smarty Streets is automated and integrated with other processes utilizing address cleansing, including latitude and longitude information, and congressional district data is available for each address in the database.

ii. Real time phone number retrieval internal to EDMAPS system boundary. Including but not limited to validating mobile or landline, carrier, country, geographic region, device type, communication method preferences, and more.

c. Storage and Organization: EDWA’s database runs on Greenplum, a massive parallel processing database engine. Its data structure is atypical for a data warehouse, as it uses a 3rd normal form relational model instead of a star or snowflake schema.

i. There is also an Elastic Compute Cloud (EC2) instance referred to as the “analytics platform” with views used for advanced analytics, dashboards, general reporting, statistical methods, leveraging Python, R, Jupyter, AWS Sagemaker, and other statistical software. This is also where the FSA team creates statistical and machine-learning models in the Development environment for use in Production.

ii. The Personally Identifiable Information (PII) in the EDWA database is tokenized using Protegrity Data Protection.

iii. EDWA contains about 90 Terabytes (TB) of data increasing by 1TB per quarter from about 124 different partner file formats from FSA Financial Partners (e.g., Services, Guaranty Agencies), Education Partners, including the Department of Education, Internal Revenue Service (IRS), and more than seven FSA internal systems, commercial data (e.g., Smarty Streets for data cleansing), and other ad hoc data as needed to fulfill data requests. Approximately 32 of the about 124 file formats contain PII.

iv. EDWA does not archive any data, so all data is on the active database with backup and recovery capability.

2. Person Master Data Management (pMDM) is a database of master or golden records of persons (customers) used by FSA’s systems. The types of customer data mastered and maintained within pMDM include customer identifiers, name, address, phone, mobile phone, email, demographic, preferred contact method, employer information, and attributes. This data is then provided to requesting systems on either a real-time basis for individual records, or batch basis for groups of records.

a. Data Ingest and Integration pMDM receives person data from several FSA systems at various intervals. Batch data enters the pMDM system into the File Inbound Area where it is quality-checked and filtered to allow only new data. Each person record is then sent to the Web Services engine using hierarchy rules to allow only the best possible record into pMDM. The same Web Services engine is used to acquire real-time data from another FSA system using hierarchy rules.

b. The Web Services Engine is primarily an Application Programming Interface (API) exchanging data between pMDM and other internal systems, but also includes the hierarchy rules to determine which source and fields of a Person's basic data is considered as "master" data.

i. Systems send their person data to pMDM batched on an hourly basis, weekly, or in synchronous real-time API calls.

ii. Information is also entered directly and in real time through the Web Services component utilized by Digital Customer Care (DCC) for customer-facing interactions.

iii. The data in transit uses the latest Chief Information Security Office (CISO) mandated Secure Socket Layer (SSL) / Transport Layer Security (TLS) for encryption.

Inventory of Webservices Avg. # Annual Calls

COD 51,832,552

Date of Death Element Data File (DDE)

75,330,684

Digital Platform 575,752,544 FTI Data Mart N/A Marketing and Communications Platform

(MCP)

128,680,942

Medallia 12,853,788 Person Authentication System (PAS)

122,989,345

PAS Lightweight Directory Access Protocol (LDAP)

N/A

Partner Participation and Oversight (PPO)

164,746

Salesforce 8,848,819 School 26,191,591 Servicer 123,394,293 Veterans Affairs (VA) 2,040,891

c. Data storage and organization. pMDM is on an Oracle database engine, organized in the 3rd normal form relational structure. The database is approximately 2451.61 Gibibytes (GB) with about 160 million active customer records and about 500 million real-time service calls to pMDM to create, read, or update it annually. More than 57 million master records are added annually and more than 300 thousand such records are added during the peak month of October each year. The database also stores inactive records either demoted or maintained for auditing purposes.

d. Data access and distribution. The most active real-time user of pMDMs data is Digital Customer Care (DCC) (studentaid.gov). DCC is customer-facing and often the first point of entry for those who want to learn about or apply for student aid. Customers are also encouraged to visit DCC often to check on the status of their application and to update their contact information and contact preferences. Information is entered into pMDM directly and in real time through the Web Services component.

i. pMDM does not archive data nor does it delete data. It only makes the best customer record or field “active,” meaning it is the master record. The non-master records and fields are demoted to “inactive” status but maintained in the database for audits and reviews.

ii. pMDM sends person records daily to EDWA.

iii. FSA systems request batch data on an ad-hoc basis to get the person master data from pMDM.

iv. There are no end-users who have direct access to the pMDM database or Web Services.

3. EDMAPS Data Lake sits on AWS’s Simple Storage Service (S3) storage and has four zones: the “Raw” zone, which has a directory structure to place incoming data files from various systems; an “Archive” zone, which currently stores historical data; a “Consumer” zone which holds user-created data files; and the “Document Repository” zone (see below for description), which securely holds digitized versions of paper applications for specialty programs, and loan servicing-related documents. Today, the data lake holds about 407TB of data.

a. The Document Repository is a scalable and reliable storage infrastructure receiving, accepting, and storing multiple filetypes of unstructured documents, such as Portable Document Format (PDF), Word, Excel, PowerPoint, plain text, image files, and audio files securely. The repository supports the ingestion and retrieval of documents via system integration APIs and includes robust indexing capabilities as well as relevant metadata such as title, author, date, and keywords.

4. Data Streaming Services. With the current implementation of the Specialty Processing Subsystem (SPS) supporting Public Service Loan Forgiveness (PSLF), Teacher Education Assistance for College and Higher Education Grants (TEACH) and Total & Permanent Disability (TPD) processing, FSA has introduced a streaming capability through the implementation of a Confluent Kafka Cluster in the EDMAPS environment.

This streaming platform is being used to enable real-time/near-real-time asynchronous data exchanges between SPS and the USDS servicers.

5. EDMAPS Inactive Databases include:

a. Debt Relief is a standalone data repository of applicants who applied for financial aid debt relief.

The application code is on hold, but the application information is available for analytics and archiving.

b. Private Collection Agencies (PCA) is a standalone data repository with no users or data outflows to systems. This archive stores a variety of static historical data, including database extracts, images and other artifacts of default collections activities generated by decommissioned PCAs.

c. Decommissioned Servicer Archive is a standalone date repository with no users or data outflows to systems. The archive currently stores static historical database extracts (in file format) of the Fed Loan and Cornerstone core servicing systems originally operated by the Pennsylvania Higher Education Assistance Agency (PHEAA).

6. EDMAPS Metadata is a cataloging tool storing EDMAPS’ metadata – data dictionary, business glossary, data lineage, and business rules at the field level, captured with IBM’s Information Governance Catalog (IGC) tool. This information is currently limited to systems within EDMAPS, not all of FSA’s systems. The EDMAPS team has two goals to improve usage of metadata within business teams and our data governance board: 1) Incrementally capture metadata for all information systems, and 2) Move metadata to a different tool making it easier for a broader audience to view and update. Options for a better tool should be considered.

7. Reporting Products and Analytical Models, this layer has delivered several products (about 44 different reports, views, and about 24 different dashboards, and visualizations) for use by FSA’s departmental staff and Enterprise Data Office (EDO) teams.

8. Report Tools, EDMAPS’ users utilize Cognos and Tableau for analytics, reports, statistical analysis, and visualizations. Python and R are used for research, modeling, and machine learning. Alation is used for query storage and collaboration.

9. The Federal Tax Information (FTI) Data Mart is hosted at FSA’s Next Generation Data Center (NGDC), which is managed by FSA’s Technology Directorate. While EDMAPS does not host the Mart, it does need support services from the Contractor to operate and maintain it. These include managing the Mart’s database to smoothly move data from two primary sources: the FTI Module, which sends FTI and PII data, and EDMAPS, which sends customer, loan, and related historical data. This Mart is used for analytics, visualizations, dashboarding, and reporting by a limited number of analysts.

NSLDS Current Data Architecture and Functionality (O&M)

NSLDS contains nearly 39TB of data about loans, grants, students, borrowers, and partners. It provides an integrated view of Title IV loans and grants during all stages of their life cycle from aid approval through disbursement, repayment, default, and closure.

NSLDS data is used in real time to support borrower-specific features on StudentAid.gov as well as the "student view" of information for Financial Aid Professionals via the FSA Partner Connect website. It also maintains data exchanges with about two dozen internal and external (federal and state agencies) to support their student loan incentive programs. On average, NSLDS provides real time data for about 175 million calls per month.

Incoming data is supplied to NSLDS from many different sources, including other FSA systems, and thousands of partners across the country. The data arrives in a variety of formats and according to schedules set for each reporting organization. In addition to the Data Provider Instructions (DPI) which defines standards for file integration from the reporting entities, authorized users can make updates to NSLDS data via a full featured user interface.

Output from NSLDS is determined by business functionality, and includes but is not limited to, web data displays, letters to partner officials, and batch files (reports, confirmations, error files) which are provided in a variety of electronic formats. The NSLDS website supports over 50,000 users in their roles as financial aid professionals, who retrieve aid data for over 20 million borrowers per month. NSLDS processes and maintains data pertaining to the three campus-based programs, Federal Supplemental Educational Opportunity Grants (FSEOG), Federal Work Study (FWS), and Federal Perkins Loans, and the Federal Direct Loan Program, Federal Family Education Loan Program (FFELP), and Federal Grants.

The solution also includes operations, service support, and program management.

1. Receive and store student and borrower loan, grant, and enrollment data from Data Providers. Perform calculations using NSLDS data to support operations and continuous monitoring of the Title IV programs.

2. Maintain the NSLDS Professional Access website, including the ability for users to request NSLDS data-driven reports.

3. Maintain a data monitoring and resolution group to ensure the quality of data in NSLDS meets minimum required standards, and to aid Education users with data requests and provide training for analyzing NSLDS data via the User Database.

4. The National Student Loan Database Systems (NSLDS) also performs calculations and screening, provides audit support, internal and external pre-defined and ad hoc reporting, and real time data inquires, email notifications, security monitoring, and a web user interface leveraging FSA's identity and access management authentication and authorization controls.

Desired Enhancements to EDMAPS AND NSLDS Current State:

FSA has identified the following areas as having potential benefit in modernizing the TIVOD technology ecosystem:

1. Implementation of Commercial Off the Shelf (COTS) products to replace the custom code in as many areas as possible. The Contractor’s response must describe how their proposed COTS tools will reduce or eliminate custom code, be more effective and efficient, and can be implemented without disruption to our user base.

2. Federal Risk and Authorization Management Program (FedRAMP) authorized, and portable and severable cloud solutions accommodating migration to the existing enterprise cloud environment. Proposed solutions must either be positioned as an application tenant in one of two existing platforms in use by FSA, or if the proposed solution is positioned in another platform (not one of the existing FSA platforms) it is expected the solution must be portable, severable, and scalable to FSA’s enterprise cloud environment in the future.

3. Modernizing the design of the EDMAPS’ data structures and their functionality. Modernizing the design of EDMAPS data structures, infrastructure, tools, and functionality.

4. Modernizing the utility and usage of EDMAPS’ current-state components.

5. Modernizing the design and utility of NSLDS transactional and operational data stores, and data warehouse to facilitate real-time lookups and updates, record processing and batch-file creation, and complex querying and machine-learning.

6. Enhancements or improvements to FSA’s strategies and tactics for inter-system data integrations improving data quality, accessibility and to provide an avenue for deriving additional insights and value from FSA’s data.

7. Improvements or enhancements to FSA’s implementation of Information Technology Infrastructure Library (ITIL) processes and deliverables, and approach to data security.

8. Optimizing performance, logical infrastructure, and security in FSA Cloud tenancy.

9. Modernization and standardization of Representational State Transfer (RESTful) API connections with all internal/external systems and entities, noting the FSA Cloud provides network boundaries for NSLDS and tenant applications, while networking for external systems exists separately.

FSA Technical Section 3: FSA TIVOD Data Access, Analysis, and Distribution Current State

1. Data Request Team fulfills data requests from congressional members, Government agencies, and internal business leaders. On an annual basis, the team fulfills over 1,000 requests by querying NSLDS and EDWA and corroborating data with other FSA systems. This team also publishes FSA data for public consumption on the FSA Data Center website.

2. Research and Modeling Team develops statistical modeling and pattern-based machine learning to predict fraud and defaults and prevent overpayments and wrongful payments. The team uses Python for machine learning, statistical analysis, and modeling, and Alation to manage and collaborate on their queries.

a. The EDWA Team has full access to both EDWA’s core database, which is the actual database, and the Analytics Platform, which is a subset of the core database containing oft-used analytics data.

b. Advanced Analytics and Machine Learning supports the deployment and management of advanced analytics and machine learning models, including the ability to integrate with third-party tools and libraries. The system also provides mechanisms for testing, validation, and monitoring of models to ensure accuracy and performance.

i. The virtual machines are cloud-based and accessible remotely from anywhere in the United States with an internet connection.

3. Reporting and Visualizations tool allowing authorized users to access and create reports and visualizations in a variety of formats based on the data in the data warehouse utilizing the Greenplum database and other data sources as needed.

a. Reporting against EDWA utilizes Cognos and Tableau for analytic reporting and Alation for query and metadata management. Analytic reports are available to a wide audience within FSA.

4. The Data catalog and querying tool is Alation and is web-based and accessible from multiple devices and browsers and integrates with our existing infrastructure and tools, including the database.

5. Data Processing and Analysis tools and capabilities for processing and analyzing data, such as data mining, statistical analysis, machine learning, and predictive modeling. The system must also support data visualization and reporting to facilitate insights and decision-making.

6. Graph analytics is currently utilizing the Greenplum database with Apache MADlib installed. The system must allow for the creation and management of graph data structures within the database, as well as the ability to perform graph analytics queries on this data.

7. Mechanisms to perform Graph Fuzzy String Matching accomplished using string similarity algorithms and techniques such as Levenshtein distance and allow for the creation and management of fuzzy string-matching queries within the database.

8. Mechanisms to perform Geospatial Analytics to support for spatial data types, indexing of spatial data, and spatial queries. The system must allow for the creation and management of geospatial analytics queries within the database.

9. Mechanisms to support advanced analytic features offered by Greenplum. This can include support for machine learning algorithms, statistical functions, and data visualization tools. The system must allow for the creation and management of advanced analytics queries within the database.

Desired Enhancements to TIVOD Data Access, Analysis, and Distribution Ecosystems

1. Ad Hoc Research and Analysis with specialized areas of advanced analytics, such as algorithmic fairness.

2. Remote desktops for specialized access to the data warehouse, and all other Information Technology (IT) assets, including the database, virtual machines, analytics tools, reporting and visualization tools, and other software used by the organization.

3. Third party software proof of concept and implementation support to integrate the third-party software with the data warehouse and other systems.

FSA Technical Section 4 General Data Quality, Data Architecture and Functionality

Desired Enhancements to Current-state Data Quality, Architecture and Functionality:

FSA seeks to improve and better integrate data management and governance within its SDLC and improve data accessibility and data quality in accordance with relevant Federal standards. FSA’s vision is to provide an enterprise data model (EDM) comprised of a Common Data Model (for storing data) integrated with a Common Messaging Model (for exchanging data) which share object names following an enterprise naming convention. Legacy system/database implementations and future design work for new systems/databases will leverage FSA's EDM in preparation of the various architecture and engineering artifacts required during the SDLC.

FSA has identified the following initiatives below as having potential benefit in modernizing the data management and governance ecosystem. The challenges many of these initiatives address emanate from the current Servicing Environment. The following context diagram is presented as a reference point to help orient the responder to the current servicing data integration landscape.

1. Create a Common Data Model: FSA desires to have a standard common data model for supporting the full student loan life cycle from Awareness, Application, Origination and Disbursement through Repayment and on to Default Management. While we have done initial work on this effort and have a reasonable starting point, we require assistance in moving this effort forward, including a better definition of clear goals and objectives for its realization and use.

2. Create a Common Messaging Model: FSA has a wide array of system components requiring integration and sharing of data. In conjunction with the Common Data Model above, FSA desires to define a Common Messaging Model creating standards for sharing information between FSA systems.

FSA envisions this Common Messaging Model to be domain based and define a library of standard blocks of data with standard naming conventions and field definitions enabling consistent and high-quality sharing of data within whatever protocol is deemed appropriate for the data integration (flat file, Comma Separated

Values (CSV), Application Programming Interface (API), Extensible Markup Language (XML), JavaScript Object Notation (JSON), etc.).

3. Expand master data to include additional domains (e.g., Grant and Loan Awards and Organizations (partners)). FSA currently has a pMDM system capturing customer identifiers, customer demographic (name, address, phone, email) and customer preference information from COD, DCC, PAS and indirectly from USDS Servicers via NSLDS. This information is used by DCC and to drive FSA’s own communication campaigns. Today, pMDM does not ingest customer information from partners, nor is the information utilized by USDS Servicers and the Default Servicer in their servicing operations. FSA’s vision is to incorporate pMDM content along with other master lists for Awards and Organizations into a true Enterprise Master Data Management System architected "As-A-Service (AAS)" to our Enterprise of authorized users.

Expand and unify the Document Repository: Today, multiple FSA systems currently generate documents sent to borrowers and receive documents from borrowers. These include forms, letters, emails, and other notices becoming part of the borrower record. Each system (COD, SPS, Customer Relationship Management (CRM), the five USDS Servicers) has its own individual document repository. This creates a disjointed record of borrower correspondence and artifacts. Furthermore, when a borrower’s account is transferred from one servicer to another, these imaged documents must be transferred to the receiving servicer, creating duplication and increasing data security risks.

a. To address this, FSA envisions an Enterprise Document Repository which would be a single repository where these imaged documents and other unstructured data can be stored, indexed, and accessed by authorized parties and systems within an FSA owned environment while eliminating the need to transfer documents between FSA systems.

4. Expansion of Data Streaming: As mentioned above, the current implementation of the Specialty Processing Subsystem (SPS) supporting PSLF, TEACH and TPD processing is leveraging a Confluent Kafka Cluster in the EDMAPS environment to enable real-time/near-real-time asynchronous integrations between SPS and the USDS servicers. FSA’s vision is to expand the use of this streaming capability as another option for integration between systems when traditional batch file integrations through the Student Aid Internet Gateway (SAIG) or synchronous API integrations won’t suffice.

5. The development of a Unified Borrower Portal: FSA’s long-term vision is to create a single point of access for student loan borrowers and Grant recipients to manage their account throughout the aid delivery, repayment, and default/rehabilitation lifecycle. This includes gaining access to critical self-service features for obtaining current account information, managing their contact information and preferences, managing repayment plans, making payments, and understanding their eligibility and applying for the many benefits associated with student loans such as income driven repayment plans, forgiveness programs, deferment/forbearance options and other repayment tools. FSA recognizes availability of quality data is a critical enabler of these features within a single borrower portal. Today, this data is spread across the FSA landscape including COD, NSLDS, USDS Servicers, the Perkins Servicer, and the Default Management system.

6. Simplifying and optimizing loan servicing transfers – Today when a borrower’s student loan account requires a transfer between USDS Servicers, a file transfer protocol (known as EA27) is employed. This transfer mechanism is dated in its definition and has not kept pace with new data elements driven by new regulations and other program changes. This has resulted in significant gaps requiring numerous supplemental files to be transferred along with the EA27 with corresponding reductions in data quality.

Additionally, this transfer is generally considered to be point-in-time, meaning only the account information needed to service the loans from this point forward is passed and full account history is not passed to the new servicer in a meaningful and complete manner. The nature of the process is also cumbersome and driven by batch processes and flat file transfer, requiring two weeks of a black out period for borrowers when an account is transferred. This limits FSA’s flexibility in managing the student loan servicing portfolio.

FSA desires to revamp this process, enabling faster, real-time transfers of servicing assignments without the loss of historical data. FSA envisions the creation and real-time population of a Common Data Model could enable a new paradigm where servicers can retrieve the information needed to ingest into their servicing systems from a centralized source in near real-time.

7. Improving Data Management Capabilities by:

a. Developing a robust, single, centralized database of high-quality master reference data for use by other systems reducing the number of duplicate copies, and moving toward more reliable, complete, consistent, and current data. Expand and enhance data governance for all FSA applications and systems via an integration hub serving as the single, authoritative, holistic view of FSA’s customer, award, and partner organization records across the enterprise, enabling FSA to manage its own best-of-breed solution without solely relying on contractor preferences. Note reference data should be another domain within the MDM solution.

b. Expanding metadata to include all FSA systems to enable data governance, streamline establishing consistent business rules, and enable proper data distribution, deprecation, archival, and destruction.

c. Developing new subject-focused analytics data marts to fully serve FSA’s managers by delivering function-specific analytics reporting capabilities to internal teams.

d. Supporting enhanced security, creating a framework securing data across multiple environments and architecture tiers and promote/regulate the usage of the shared services to produce consistent results. This framework provides FSA with the confidence their data is being stored in a safe manner and the data is only accessed through secure channels.

Feedback Solicited With this RFI, FSA seeks industry feedback, technical information, and recommendations on what technology, technical capabilities, applied methodologies, staffing considerations, and Government and industry best-practices FSA could construct, procure, and/or employ in solutioning the six (6) ‘Challenge Areas’ noted in this Section.

With this RFI, FSA also seeks industry feedback on acquisition considerations (e.g., cost and pricing drivers, contract structure, acquisition sequencing, etc.) shaping the acquisition strategies for anticipated future solicitations and contracts to procure, design, develop, implement, manage, or sustain technology related to solutioning FSA’s Challenge Areas.

To direct responses to this RFI, respondents shall review the ‘FSA Challenge Statements’, ‘Technical Questions’, and other technical and contextual information provided in this RFI. Again, respondents are not required to address every Section of this RFI, nor are they required to respond to all Technical Questions noted in each Section.

RFI responses shall provide the following information:

1. A description of the company as follows:

a. Company Name

b. Unique Entity ID

c. Address (Including telephone and email)

d. Points of Contact

e. Based on the North American Industry Classification System (NAICS) Codes listed below, state whether your company is classified as any small business category including Small Business, Woman-Owned Small Business, Economically Disadvantaged Women-Owned Small Business, Small Disadvantaged Business, 8(a), HUBZone, and Service-Disabled Veteran-Owned Small Business

NAICS Code NAICS Code Description Size Standard 518210 Computing Infrastructure Providers, Data Processing, Web

Hosting, and Related Services $40M

541511 Custom Computer Programming Services $34M 541512 Computer Systems Design Services $34M 541519 Other Computer Related Services $34M

f. A description of your company’s primary business product/service line.

g. Are your services available on the General Services Administration’s (GSA) Federal Supply Schedule? If yes, provide the contract number(s) and corresponding NAICS Code(s).

h. Are your services available through any other Government contract vehicles? For example, National Aeronautics and Space Administration's Solutions for Enterprise-Wide Procurement (NASA SEWP) government-wide acquisition contract (GWAC), National Institutes of Health (NIH) GWACs, etc. If yes, provide the contract number(s) and corresponding NAICS Code(s).

2. A summary-level capability statement of the respondent’s ability to solution the specific ‘Challenge Area(s)’ noted in this RFI.

3. Specific responses to the ‘Technical Question(s)’, which are furnished in each ‘FSA System’ Section of this RFI. Responses provided must demonstrate the respondent’s understanding of the question, and include:

a. Relevant technical information or citation substantiating the respondent’s recommendations or suggestions offered.

b. 5-year Rough Order of Magnitude…