Insurance Verification RFI 70FA4026I00000004.pdf

Federal Emergency Management Agency (FEMA) Request for Information (RFI) # 70FA4026I00000004

February 17, 2026

REQUEST FOR INFORMATION (RFI) SUMMARY: The Department of Homeland Security (DHS), Federal Emergency Management Agency (FEMA), Individual Assistance (IA) Division, is conducting market research to identify sources and technical approaches to support insurance verification and insurance data-sharing services for FEMA’s IA Program under the Robert T. Stafford Disaster Relief and Emergency Assistance Act (Stafford Act).

FEMA is seeking information from industry on capabilities to:

1. Validate insurance coverage status for disaster survivors (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance, etc.) using secure, survivor-authorized data sharing, to comply with Stafford Act and regulatory requirements to prevent duplication of benefits; and

2. Enable survivor permissioned digital connectivity between survivors and their insurance carriers (e.g., via account “linking” or similar mechanisms) so FEMA can receive verified policy, coverage, and claims information directly from insurers, thereby reducing survivor burden and manual document review.

This RFI is issued solely for information and planning purposes in accordance with FAR 15.201(e).

FEMA does not intend to award a contract on the basis of this RFI or to otherwise pay for the information received. Responses to this RFI will be used to inform FEMA’s acquisition planning for potential future procurements to modernize insurance verification and underinsurance adjudication processes within the IA Program.

GENERAL INFORMATION: This Request for Information (RFI) is issued solely for information-gathering and market research purposes to identify sources that can provide insurance verification and survivor-permissioned insurance data-sharing services in support of the FEMA IA Division and the IA Program.

In accordance with FAR 15.201(e), RFIs may be used when the Government seeks to obtain price, delivery, other market information, and capabilities for planning purposes. Responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. This RFI shall not be construed as a commitment by the Government for any purpose, nor does it restrict the Government to an ultimate acquisition approach.

FEMA is specifically seeking information on:

• Services and technical solutions that can securely validate whether a survivor has relevant insurance coverage (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance, etc.) using survivor-authorized access to personally identifiable information (PII) and sensitive PII (SPII);

and

• Services and technical solutions that allow survivors, at their option, to authenticate and “link” their insurance policy/account to FEMA’s Disaster Assistance Portal (DAP) (www.DisasterAssistance.gov), enabling FEMA to receive verified policy, coverage, and claims information directly from insurers to support determinations of uninsured and underinsured losses http://www.disasterassistance.gov/

February 17, 2026 and to prevent duplication of benefits as required by the Stafford Act and 44 C.F.R. Part 206 and § 206.191.

Respondents are solely responsible for all expenses associated with their RFI responses. Respondents will not receive additional information in response to their submittal to this RFI and will not be notified of the results of this market research.

PROPRIETARY INFORMATION AND DISCLAIMERS: Respondents shall identify any proprietary information in their RFI response. Information submitted in response to this RFI will be used at the discretion of the Government. Further, the information submitted will remain confidential insofar as permitted by law, including the Freedom of Information and Privacy Acts. FEMA reserves the right to utilize any non-proprietary technical information in the anticipated Statement of Work (SOW) or solicitation.

Although it is not necessary to address in their response, respondents shall be aware of any potential, actual, or perceived organizational conflicts of interest. Any real or potential conflicts must be sufficiently mitigated prior to a contract award. For further guidance, refer to the Federal Acquisition Regulation, Part 9.5.

NAICS CODE: 518210 – Data Processing, Hosting, and Related Services

FEMA anticipates that the requirement will primarily involve secure data processing, hosting, integration, and related services to support real-time or near-real-time insurance verification and data exchange with insurance carriers and aggregators. Respondents may propose alternative or additional NAICS codes they believe are more appropriate for their solution(s), such as:

• 519290 – Web Search Portals and All Other Information Services

• 541511 – Custom Computer Programming Services

• 541512 – Computer Systems Design Services

• 524298 – All Other Insurance Related Activities

Respondents should identify their primary NAICS code(s) and business size status relative to those codes.

PRODUCT SERVICE CODE (PSC): DA10 – IT and Telecom – Business Application/Application Development Software as A Service

ANTICIPATED PERIOD OF PERFORMANCE START DATE: Beginning in FY27

ANTICIPATED ACQUISITION STRATEGY: FEMA has not yet determined an acquisition strategy and is using this RFI to inform that decision. Potential strategies under consideration may include, but are not limited to:

• Use of existing Government-wide Acquisition Contracts (GWACs) or DHS/FEMA vehicles;

• Full and open competition;

• Small business set-aside(s), if appropriate based on market research;

• A phased or modular approach (e.g., pilot / proof-of-concept followed by scaled implementation).

February 17, 2026

Respondents are encouraged to provide feedback on acquisition approaches, contract types, and performance structures (e.g., outcome-based, consumption-based pricing) that they believe would best support this requirement.

ATTACHMENT: FEMA anticipates including, as applicable, draft requirements and background materials as attachments to any future RFI or solicitation, such as:

• Excerpts from the Individual Assistance Program and Policy Guide (IAPPG), Version 1.1 Amended, describing insurance, duplication of benefits, and underinsurance;

• Relevant portions of the IA Modernization RFI 70FA3125I00000010 use cases (e.g., insurance integrations, validation, and automation); and

• A refined Insurance Verification Concept of Operations / One-Pager describing the desired end-state for insurance verification and survivor-permissioned data sharing.

For this RFI, FEMA may provide a high-level concept paper or one-pager summarizing the desired capabilities and statutory/regulatory context.

RFI RESPONSE SUBMITTAL INSTRUCTIONS:

Interested contractors shall submit their RFI responses electronically to Meeka Tilahun, Contracting Officer, at Meeka.Tilahun@fema.dhs.gov and Guylaine Yearwood, Contract Specialist, at Guylaine.Yearwood@fema.dhs.gov no later than 3:00PM Eastern Standard Time (EST), March 4, 2026. Questions regarding this RFI are due no later than February 25, 2026.

• File format: PDF (preferred).

• Page limit: FEMA recommends a maximum of 25 pages, excluding cover page and any corporate brochures or appendices.

• Page layout:

o Paper size: 8.5” x 11” o Font: Times New Roman or Arial, minimum 11-point o Margins: At least 1 inch on all sides

• Organization: Respondents are encouraged to follow the topic areas and question structure provided in this RFI to facilitate FEMA’s review.

RFI Responses shall include the following information in the order below:

A. Cover Page with the following information:

1. Company Name

2. Company Address

3. UEI Number

4. Company Point of Contact - Name, Title, Phone, and Email address

5. Statement of current business size status (i.e., HUBZone small business concern, service-disabled veteran-owned small business firm, 8(a) contractor, woman-owned small business, small business, or large business concern). Also, business size in relation to the NAICS code size standards assigned to this acquisition.

6. GSA Schedule Number, Contract Number, and Period of Performance and/or DHS Strategic Sourcing Vehicle Category Name and Contract Number, if applicable

B. Contractor Capability Statement (No more than 10-15 pages in length)

1. Summarization of relevant projects showing capabilities

2. Past performance in applicable areas

3. Database/Insurance Company Coverage and known gaps.

C. Contractor RFI Responses to questions (No more than 25 pages plus attachments)

The responses received will assist FEMA with identifying the number and nature of the entities that consider themselves potential technical solution providers. Each respondent, by submitting a response, agrees that any cost incurred in response to this RFI, or in support of activities associated with this RFI, shall be the sole responsibility of the respondent. FEMA shall incur no obligations or liabilities whatsoever, to anyone, for any costs or expenses incurred by the respondent in responding to this RFI.

BACKGROUND/PROBLEM STATEMENT

FEMA administers the IA Program under Section 408 of the Stafford Act, 42 U.S.C. § 5174. The IA Program provides financial assistance and direct services to eligible individuals and households who have uninsured or underinsured necessary expenses and serious needs as a result of a Presidentially-declared disaster.

FEMA is currently executing a multi-year IA Modernization effort to improve efficiency, consistency, and survivor experience of IA program delivery. As part of this effort, FEMA has selected Salesforce as its enterprise Customer Relationship Management (CRM) platform for Individual Assistance case management and survivor engagement. Future IA capabilities, including insurance verification and data-sharing, are expected to integrate with and leverage this Salesforce-based environment and FEMA’s broader IA technical architecture.

Statutory and Regulatory Context – Duplication of Benefits and Insurance

The Stafford Act and FEMA’s implementing regulations require FEMA to prevent duplication of benefits (DOB) and to consider insurance and other sources when determining eligibility and award amounts:

• Stafford Act § 312 (42 U.S.C. § 5155) – Requires the President to ensure that no person receives disaster assistance “with respect to any part of such loss as to which he has received financial assistance under any other program or from insurance or any other source.” It also requires procedures to ensure uniformity in preventing duplication and allows Federal assistance where only partial benefits have been received, provided Federal assistance is not duplicative.

• Stafford Act § 408 (42 U.S.C. § 5174) – Authorizes IHP assistance only when individuals and households are “unable to meet such expenses or needs through other means,” and requires that IHP assistance be reduced or denied to the extent that insurance proceeds or other compensation cover the same loss.

FEMA’s regulations at 44 C.F.R. Part 206, Subpart D implement these requirements for IHP:

• 44 C.F.R. § 206.110 – States that no individual or household may receive IHP assistance for any part of a loss that has been covered by insurance or any other source, and that assistance will be reduced by the amount of such proceeds.

• 44 C.F.R. § 206.113 – Requires that survivors have necessary expenses or serious needs that they are “unable to meet through other means, including insurance, loans, or other disaster assistance.”

• 44 C.F.R. § 206.117 and § 206.119 – Provide that Housing Assistance and Other Needs Assistance (ONA) may only address losses not covered by insurance or other sources, and that assistance must be reduced or recouped when insurance proceeds duplicate FEMA assistance.

• 44 C.F.R. § 206.191 – Implements Stafford Act § 312 across FEMA programs and requires FEMA to consider anticipated or actual insurance proceeds, reduce assistance accordingly, and recover overpayments when later insurance proceeds create a duplication.

The Individual Assistance Program and Policy Guide (IAPPG), Version 1.1 Amended (July 2025) further operationalizes these requirements, including:

• Expectation that survivors pursue all available insurance;

• Prohibition on providing IHP assistance for losses covered by insurance;

• Allowance for FEMA to provide limited assistance prior to insurance settlement, subject to reduction or recoupment; and

• Detailed rules for underinsurance, including how FEMA may assist with uninsured or underinsured portions of verified losses (e.g., Home Repair Assistance, Home Replacement Assistance, and ONA categories).

Current-State Insurance Verification and Underinsurance Determination To comply with these statutory and regulatory requirements, FEMA must determine:

1. Whether an survivor has relevant insurance coverage (e.g., homeowners, renters, flood (non- NFIP), auto);

2. Whether the policy covers the peril(s) and type(s) of loss at issue; and

3. Whether the survivor is uninsured, fully insured, or underinsured for the specific disaster-caused losses.

Today, FEMA’s IA Program processes rely heavily on:

• Self-certification of insurance status at registration and during case processing; and

• Manual document collection and review for underinsurance determinations.

Specifically:

• Survivors self-report whether they have insurance and the type(s) of coverage (e.g., homeowners, flood (non-NFIP), auto). FEMA has no systematic, automated means to validate the existence or status of coverage across carriers.

• For survivors who are underinsured, FEMA requires documentation such as insurance policies, declarations pages to include ALE/LOU coverage, settlement letters, denial letters, and estimates.

Survivors typically upload or mail these documents to FEMA.

• FEMA staff then manually review these documents to determine coverage, exclusions, deductibles, and net uninsured or underinsured losses. This process is labor-intensive, time-consuming, and prone to delays and inconsistency, especially during large-scale disasters with millions of registrations.

February 17, 2026

This current approach creates several challenges:

• Compliance risk: Reliance on self-certification and manual review makes it difficult to consistently and efficiently ensure compliance with Stafford Act § 312 and § 408, and 44 C.F.R.

§§ 206.110, 206.113, 206.117, 206.119, and 206.191.

• Survivor burden: Survivors must locate, download, scan, upload, or mail multiple insurance documents—often while displaced or without reliable connectivity—creating friction and delays in receiving assistance.

• Operational inefficiency: FEMA staff spend significant time manually interpreting insurance documents, which slows case processing, creates a chance for error, and diverts resources from higher value activities.

• Data fragmentation: Insurance information is not consistently structured or integrated into FEMA’s systems, limiting FEMA’s ability to automate eligibility and award calculations, support analytics, or re-run business rules when policies or disaster parameters change.

These challenges are particularly acute as FEMA modernizes its IA technology stack and transitions case management and survivor interaction capabilities into FEMA’s Individual Assistance Processing System environment. Insurance information that remains unstructured and disconnected from core IA systems is harder to leverage within Salesforce workflows, rules engines, and analytics.

FEMA’s Desired End State FEMA seeks to modernize its insurance verification and underinsurance adjudication processes by leveraging secure, survivor-permissioned data exchange with insurance carriers and/or insurance data aggregators, and by integrating these capabilities into FEMA’s Individual Assistance Processing System and associated IA systems.

At a high level, FEMA’s desired end state includes:

1. Automated Insurance Coverage Verification o Ability to securely determine, with survivor consent and appropriate privacy and security controls, whether a survivor has relevant insurance coverage (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance, etc.) and basic policy attributes (e.g., carrier, policy number, effective dates, coverage types).

o Ability to use this information to support compliance with duplication-of-benefits requirements and to reduce reliance on self-certification.

o Ability to provide coverage status and key attributes within FEMA’s Individual Assistance Processing System in a way that supports caseworker workflows and automated rules.

2. Survivor-Permissioned Account/Policy Linking o Ability for survivors, at their option, to authenticate and “link” their insurance policy/account to FEMA’s Disaster Assistance Portal (www.DisasterSssistance.gov) or other FEMA channels (e.g., call center, DRC), using secure, industry-standard methods.

o Once linked, FEMA would be able to receive structured, machine-readable insurance data directly from insurers or aggregators, such as:

Policy details (limits, deductibles, coverages to include ALE/LOU coverage, exclusions);

Insured property information (address, dwelling type, vehicles);

http://www.disastersssistance.gov/

Claims status and settlement information (amounts paid to include ALE/LOU, denials, partial payments).

o This would reduce or eliminate the need for survivors to upload or mail insurance documents and would enable FEMA to automate portions of eligibility and award calculations for uninsured and underinsured losses.

o The linkage and resulting data should be consumable by and visible within FEMA’s Individual Assistance Processing System, supporting both automated decisioning and human review.

3. Integration with FEMA IA Systems and Rules Engines o Ability to integrate insurance data into FEMA’s IA systems, including FEMA’s

Individual Assistance Processing System and associated decision/rules engines, in a way that:

Supports automated checks for duplication of benefits;

Supports underinsurance calculations (e.g., FEMA-verified loss minus insurance settlement, up to statutory caps);

Is auditable and traceable for compliance and recoupment purposes; and Supports future IA Modernization efforts (e.g., use cases in IA Modernization

RFI 70FA3125I00000010).

4. Security, Privacy, and Compliance o Solutions must support secure handling of PII/SPII, comply with applicable Federal privacy and security requirements (e.g., FedRAMP, encryption in transit and at rest, role-based access control), and support FEMA’s obligations under the Privacy Act and DHS/FEMA system of records notices.

o Survivor consent, transparency, and control over data sharing are essential. Survivors must be able to opt in, understand what is being shared, and revoke access where appropriate.

o Any integration with FEMA’s Individual Assistance Processing System and other IA systems must align with DHS and FEMA security architectures and controls.

FEMA Objectives

FEMA’s overarching objective is to modernize how the IA Program verifies insurance coverage and determines underinsurance, in order to:

• Comply more effectively and consistently with Stafford Act §§ 312 and 408 and 44 C.F.R.

duplication-of-benefits requirements;

• Reduce burden on disaster survivors; and

• Improve the speed, accuracy, and auditability of the IA Program eligibility and award determinations.

Within the context of the ongoing IA Modernization effort and FEMA’s adoption of FEMA’s Individual Assistance Processing System, FEMA is seeking industry input on technical and business solutions that can:

February 17, 2026

1. Automate Insurance Coverage Verification o Provide services and/or platforms that, with survivor consent and appropriate security and privacy controls, can validate whether a survivor has relevant insurance (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance, etc.) and retrieve key policy attributes (e.g., carrier, policy number, effective dates, coverage types, limits, deductibles).

o Support FEMA’s need to reduce reliance on self-certification and manual document review, while enabling consistent application of duplication-of-benefits rules.

2. Enable Survivor-Permissioned Policy/Account Linking o Provide capabilities for survivors to authenticate and “link” their insurance policy/account to FEMA’s Disaster Assistance Portal (www.DisasterAssistance.gov) and/or other FEMA channels, using secure, industry-standard methods (e.g., OAuth-style flows, API-based consent, or similar).

o Enable FEMA, once the survivor has granted permission, to receive structured, machine-readable insurance data directly from insurers or insurance data aggregators, including policy details and claims/settlement information relevant to the IA Program determinations.

3. Integrate with FEMA’s Individual Assistance Processing System and IA Ecosystem o Provide integration patterns, APIs, connectors, or other mechanisms that allow insurance verification and data-sharing capabilities to be integrated with FEMA’s Individual Assistance Processing System and associated IA systems and rules engines.

o Support use cases such as:

Automated checks for duplication of benefits;

Automated or semi-automated underinsurance calculations;

Caseworker decision support within Salesforce; and Audit trails and reporting for compliance and recoupment.

4. Ensure Security, Privacy, and Compliance o Operate in a manner consistent with Federal security and privacy requirements (e.g., FedRAMP, encryption, identity and access management, logging and monitoring), and support FEMA’s obligations under the Privacy Act and DHS/FEMA system of records notices.

o Provide clear mechanisms for survivor consent, transparency, and revocation of access, and support FEMA’s need to handle PII/SPII in a secure and compliant manner.

5. Scale for Catastrophic Events o Demonstrate the ability to operate at national scale, including during large-scale disasters with high registration volumes, multiple insurers, and diverse policy types, while maintaining performance, reliability, and data quality.

February 17, 2026

Topic Area 1 – Corporate Capabilities and Relevant Experience

1.1 Corporate Overview

a. Provide a brief overview of your organization, including:

• Year founded, size (number of employees), and primary lines of business;

• Primary NAICS code(s) and business size status;

• Any parent company or major subsidiaries relevant to this RFI.

b. Identify which technical area(s) you are responding to:

• Technical Area A – Insurance Coverage Verification Services;

• Technical Area B – Survivor-Permissioned Policy/Account Linking and Data Sharing;

• Both Technical Area A and Technical Area B.

c. Describe any teaming or partnership arrangements you would anticipate using to deliver a complete solution (e.g., data aggregators, core system vendors, implementation partners).

1.2 Relevant Experience with Insurance Data and Public Sector

a. Describe your experience providing insurance-related data services, integrations, or platforms, including:

• Types of insurance supported (e.g., homeowners, renters, flood (non-NFIP), auto, other P&C lines);

• Number and types of carriers or data sources you currently connect to;

• Geographic coverage (national, regional, state-specific); and

• Percentage compared to total insured population

b. Describe any experience working with U.S. Federal, state, territorial, tribal, or local government agencies on:

• Disaster assistance, benefits, or eligibility determination programs;

• Insurance verification, claims data exchange, or duplication-of-benefits prevention;

• Integrations with government CRMs or case management systems.

c. Provide up to three examples (public sector or private sector) of projects where you:

• Implemented insurance coverage verification at scale; and/or

• Implemented consumer-permissioned policy/account linking and data sharing; and/or

• Integrated insurance data into a CRM or case management platform (e.g., Salesforce).

For each example, please include:

• Customer type (e.g., Federal agency, state agency, insurer, financial institution);

• Scope and objectives;

• Key capabilities delivered;

• Approximate scale (e.g., number of users, number of policies/accounts, transaction volume);

• Duration and current status (e.g., pilot, production, decommissioned).

1.3 Experience with Salesforce and IA Like Use Cases

a. Describe any experience integrating your solution(s) with Salesforce, including:

• Use of Salesforce APIs, AppExchange apps, or managed packages;

• Types of Salesforce products (e.g., Service Cloud, Experience Cloud, Government Cloud) you have integrated with;

• Any FedRAMP or public sector Salesforce implementations you have supported.

b. Describe any experience with use cases similar to FEMA’s Individual Assistance program, such as:

• Benefits eligibility and adjudication;

• Claims intake and processing;

• Case management involving third-party data sources.

1.4 Contract Vehicles and Certifications

a. Identify any existing Federal or DHS/FEMA contract vehicles or schedules under which your solution could be acquired (e.g., GSA MAS, GWACs, DHS IDIQs).

b. Identify any relevant certifications or authorizations, such as:

• FedRAMP authorization (and impact level);

• SOC 2, ISO 27001, or similar;

• Any insurance industry certifications or memberships (e.g., ACORD, industry data standards bodies).

February 17, 2026

Topic Area 2 – Technical Approach: Insurance Coverage Verification (Technical Area A)

Respond to this section only if you provide, or propose to provide, insurance coverage verification services (e.g., confirming whether an individual has a policy, basic policy attributes, and high-level coverage information). If you do not provide these services, you may skip this section.

2.1 Service Description and Core Capabilities

a. Describe your insurance coverage verification service(s). At a minimum, address:

• Types of insurance you can verify (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance, etc.), auto, other P&C lines);

• Types of information you can reliably provide (e.g., carrier name, policy number, effective/expiration dates, coverage types, limits, deductibles, status such as active/lapsed/cancelled).

b. Explain how your service determines whether an individual has coverage. For example:

• Direct carrier integrations;

• Use of insurance data aggregators;

• Use of credit-header or other third-party data;

• Other methods (please describe).

c. Indicate whether your service can distinguish between:

• Policies covering the damaged property (e.g., specific dwelling address, specific vehicle); and

• Policies held by the individual that may not be relevant to the specific loss.

2.2 Identity Resolution and Matching

a. Describe how your solution would match a FEMA survivor to insurance records, including:

• Data elements used for matching (e.g., name, address, date of birth (DOB), Social Security number (SSN) last 4, policy number);

• Matching algorithms or approaches (e.g., deterministic, probabilistic, fuzzy matching);

• How you would handle common disaster-related issues (e.g., temporary addresses, name variations, joint policies).

b. Provide any metrics you can share on:

• Match rates (e.g., percentage of successful matches given a complete data set);

• False positive / false negative rates, if available;

• Typical data quality issues and how you mitigate them.

c. Describe how your solution would support FEMA’s need to avoid over-reliance on self-certification while still respecting survivor consent and privacy.

2.3 Data Elements and Level of Detail

a. Provide a representative list of data elements you can provide for each verified policy, such as:

• Carrier name and NAIC code;

• Policy number;

• Policy type (e.g., HO-3, renters, NFIP, auto);

• Effective and expiration dates;

• Named insured(s);

• Insured property address or VIN;

• Coverage types (e.g., dwelling, contents, ALE/LOU, liability);

• Coverage limits and deductibles (if available);

• Policy status (active, cancelled, lapsed, pending).

b. Indicate which data elements are:

• Always available;

• Often available but not guaranteed;

• Rarely available or not supported.

c. Describe any constraints on how frequently FEMA could query or refresh coverage data (e.g., daily, near real-time, batch windows).

2.4 Use Cases Relevant to FEMA

a. Describe how your coverage verification service could support FEMA’s key use cases, including:

• Determining whether a survivor has any relevant insurance coverage;

• Distinguishing between insured, uninsured, and potentially underinsured survivors;

• Supporting FEMA’s duplication-of-benefits checks under Stafford Act § 312 and 44 C.F.R. §

206.191;

• Identifying cases where FEMA may provide limited assistance prior to insurance settlement, subject to later adjustment.

b. Explain how your service could be used to flag or prioritize cases for manual review (e.g., ambiguous coverage, conflicting data, high-risk scenarios).

2.5 Technical Interfaces and Integration Patterns

a. Describe the technical interfaces your solution provides for coverage verification, such as:

• RESTful APIs (please describe authentication, typical payloads, and response formats);

• Batch file interfaces (e.g., SFTP, secure file exchange);

• Web-based portals or dashboards;

• Any existing connectors or accelerators for Salesforce.

b. Describe how your solution could be integrated with:

• FEMA’s Individual Assistance Processing System (e.g., via APIs, middleware, AppExchange apps);

c. Indicate whether your solution supports:

• Synchronous, real-time queries (e.g., during registration or caseworker interaction);

• Asynchronous/batch processing (e.g., nightly coverage refresh for a population of survivors);

• Event-driven or message-based integration patterns.

2.6 Coverage Breadth and Carrier Participation

a. Describe your current coverage of the U.S. insurance market, including:

• Number of carriers or data sources you connect to;

• Approximate percentage of the U.S. homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, auto insurance market you can successfully return tangible data for;

• Any notable gaps (e.g., certain regions, U.S. territories, federally-recognized tribes, small mutuals, surplus lines).

b. Explain how you onboard new carriers or data sources and typical timelines for doing so.

c. Describe any existing relationships or agreements with:

• Major national carriers;

• Regional carriers;

• NFIP or Write-Your-Own (WYO) flood (non-NFIP) insurers (if applicable).

2.7 Data Freshness, Accuracy, and Quality Controls

a. Describe how frequently your data is updated from carriers or data sources, and how you ensure:

• Timeliness (e.g., policy status changes, cancellations, renewals);

• Accuracy and completeness;

• Handling of corrections or retroactive changes.

b. Describe any data quality monitoring, validation, or reconciliation processes you employ.

c. Explain how you would support FEMA’s need for auditable records (e.g., what data was returned, when, and from which source) to support compliance reviews and potential recoupment actions.

2.8 Limitations, Assumptions, and Dependencies

a. Identify any key limitations or assumptions associated with your coverage verification service, such as:

• Types of policies or carriers not supported;

• Situations where coverage cannot be reliably determined;

• Dependencies on survivor-provided information or consent.

b. Describe any legal, regulatory, or contractual constraints that could affect FEMA’s use of your service (e.g., carrier participation agreements, data use restrictions).

2.9 Contributory Database Participation and Minimum Data Requirements

FEMA understands that many insurance verification services operate as contributory databases, where access to data is contingent on participants contributing their own data. FEMA needs to understand what would be required for the IA Program to be treated as a contributor and to gain access.

a. Describe whether your insurance coverage verification service operates as a contributory database or relies on contributory data models. If so, please explain:

• The general principles of participation (e.g., “give-to-get” model, reciprocity requirements);

• How government entities are typically onboarded as contributors, if applicable.

b. Specify the minimum data elements FEMA would need to provide in order to be considered a contributor and gain access to your data, such as:

• Applicant identifiers (e.g., name, date of birth, address, SSN last 4);

• FEMA case identifiers (e.g., registration ID, disaster number);

• Insurance-related data FEMA holds (e.g., self-reported carrier, policy number, claim information, FEMA-verified loss amounts, FEMA payment amounts);

• Any other required data elements (please list and explain why they are needed).

c. For each required or requested data element, indicate:

• Whether it is mandatory for participation or optional but beneficial;

• How frequently FEMA would need to contribute or update data (e.g., real-time, daily, post-award);

• Any constraints on the form or structure of contributed data (e.g., specific formats, schemas).

d. Describe how contributed FEMA data would be:

• Used within your ecosystem (e.g., to improve match rates, enrich records, support other participants);

• Protected and governed (e.g., access controls, use limitations, segregation of government data);

• Segmented or flagged, if FEMA requires that its contributed data be treated differently from other contributors’ data.

e. Explain any policy, legal, or contractual considerations FEMA should be aware of before becoming a contributor, including:

• Data ownership and rights;

• Ability for FEMA to limit or condition downstream use of its contributed data;

• Options for FEMA to discontinue contribution and what happens to previously contributed data.

February 17, 2026

Topic Area 3 – Technical Approach: Survivor-Permissioned Policy/Account Linking and Data Sharing (Technical Area B)

Respond to this section only if you provide, or propose to provide, survivor-permissioned policy/account linking and ongoing insurance data-sharing capabilities. If you do not provide these services, you may skip this section.

3.1 Service Description and Core Capabilities

a. Describe your survivor-permissioned insurance data-sharing solution. At a minimum, address:

• How survivors authenticate and “link” their insurance policy/account to a third-party (e.g., FEMA);

• Types of insurance accounts supported (e.g., homeowners, renters, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, and auto insurance), multi-policy accounts);

• Types of data you can share once a survivor has granted permission (e.g., policy details, declaration pages to include ALE/LOU coverage, claims, settlements).

b. Explain whether you operate primarily as:

• A direct integration provider (connecting FEMA to individual carriers);

• A data aggregation platform (connecting to multiple carriers and normalizing data);

• A combination of both; or

• Another model (please describe).

c. Describe how your solution differs from or complements basic coverage verification (Topic Area 2), particularly with respect to:

• Depth of data (e.g., detailed coverage terms, claim line items);

• Frequency and duration of data access (e.g., one-time vs ongoing updates).

3.2 Survivor Authentication, Consent, and Linking Flows

a. Describe the end-to-end user experience for a survivor linking their insurance account, including:

• How the survivor initiates the linking process (e.g., via FEMA’s DAP, call center, DRC, inspections);

• How the survivor is authenticated with their insurer (e.g., username/password, multi-factor authentication, carrier SSO, identity proofing);

• How consent is captured (e.g., consent screens, scopes, duration, revocation options).

b. Indicate which technical patterns you support for consent and linking, such as:

• OAuth 2.0 / OpenID Connect-style authorization flows;

• API-based consent frameworks;

• Redirect-based flows from a web or mobile application;

• Other patterns (please describe).

c. Explain how your solution could be embedded into FEMA’s Individual Assistance Processing System user interfaces to include www.DisasterAssistance.gov (e.g., iFrames, web components, deep links, Salesforce Lightning components).

3.3 Data Elements Available After Linking

February 17, 2026

a. Provide a representative list of data elements you can provide once a survivor has linked their account, including:

• Policy-level data o Carrier name and NAICS code;

o Policy number;

o Policy type (e.g., HO-3, homeowners, renters, NFIP, flood (non-NFIP), mobile home, condo/townhouse, earthquake, fire, hurricane, sewer back up, auto);

o Effective and expiration dates;

o Names of insured;

o Insured property address or VIN;

o Coverage types, limits, deductibles;

o Key exclusions or endorsements (if available).

• Claims level data o Claim number(s);

o Date of loss;

o Date of claim;

o Claim status (e.g., open, closed, denied, pending);

o Adjusters report or inspection information;

o Payments issued (amounts, dates, categories such as dwelling, contents, ALE/LOU);

o Denial reasons or partial payment explanations (if available).

o Claims adjuster contact information.

b. Indicate which data elements are:

• Always available;

• Often available but not guaranteed;

• Rarely available or not supported.

c. Describe how your data model supports:

• Distinguishing between multiple policies for the same survivor;

• Mapping claims and payments to specific properties or vehicles;

• Supporting FEMA’s need to calculate uninsured and underinsured portions of verified losses.

3.4 Data Access Frequency, Duration, and Event Handling

a. Describe how often FEMA could access or refresh data for a linked account, including:

• One-time retrieval at the time of linking;

• Periodic refresh (e.g., daily, weekly);

• Event-driven updates (e.g., when claim status or payment changes).

b. Explain how long access persists after initial consent (e.g., until revoked, for a fixed period, per claim), and how (FEMA’s standard period of assistance is 18 months):

• Survivors can view and manage their consents;

• Survivors can revoke access;

• FEMA would be notified of revocation or expiration.

c. Describe any throttling, rate limits, or usage constraints that would apply to FEMA’s use of your APIs or services.

3.5 Integration with IA Modernization and FEMA’s Individual Assistance Processing System

February 17, 2026

a. Describe the technical interfaces your solution provides for linked-account data sharing, such as:

• RESTful APIs (authentication, payloads, response formats);

• Webhooks or event notifications (e.g., claim status changes);

• SDKs, connectors, or AppExchange apps for Salesforce.

b. Explain how your solution could be integrated with:

• FEMA’s Individual Assistance Processing System for caseworker access and automated rules;

• FEMA’s back-end IA systems and data stores;

• FEMA’s DAP for survivor-facing flows.

c. Provide any reference architectures, diagrams, or patterns you recommend for integrating your solution into a Salesforce-centric environment in a Federal context.

3.6 Support for FEMA’s Underinsurance and Duplication-of-Benefits Use Cases

a. Describe how your solution could support FEMA’s need to:

• Identify underinsured survivors (e.g., FEMA-verified loss exceeds insurance payments);

• Determine net uninsured/underinsured amounts for specific categories (e.g., dwelling, contents, transportation);

• Apply duplication-of-benefits rules (e.g., reduce or deny assistance where insurance fully covers the loss).

b. Explain how your solution could help FEMA:

• Reduce manual review of insurance documents;

• Flag cases where manual review is still required (e.g., complex endorsements, disputes);

• Maintain an auditable record of insurance data used in determinations.

3.7 Carrier and Platform Participation

a. Describe your current relationships with insurers and/or core system vendors that enable survivor-permissioned data sharing, including:

• Number and types of carriers currently supported;

• Any major national or regional carriers;

• Any support for NFIP or WYO flood insurers (if applicable).

b. Explain how you onboard new carriers or platforms for survivor-permissioned data sharing and typical timelines.

c. Describe any incentives or value propositions you offer to carriers to participate in such data-sharing arrangements.

3.8 Legal, Regulatory, and Contractual Considerations

a. Identify any legal, regulatory, or contractual frameworks you rely on for survivor-permissioned data sharing, such as:

• Consumer consent frameworks;

• Data sharing agreements with carriers;

• Applicable state insurance or privacy laws.

b. Describe any constraints that could affect FEMA’s use of your solution, including:

• Restrictions on data use or retention;

• Requirements for FEMA to be a party to certain agreements;

• Limitations on cross-jurisdictional data sharing.

3.9 Limitations, Assumptions, and Dependencies

a. Identify key limitations or assumptions associated with your survivor-permissioned linking solution, such as:

• Types of policies or carriers not supported;

• Situations where linking is not feasible (e.g., no online account, legacy systems);

• Dependencies on survivor digital access (e.g., email, mobile phone).

b. Describe any user experience or accessibility considerations you have addressed (e.g., multi-language support, accessibility standards) that may be relevant for FEMA’s diverse survivor population.

February 17, 2026

Topic Area 4 – Integration with IA Modernization and FEMA’s Individual Assistance Processing System

4.1 Overall Integration Approach

a. Describe your overall approach to integrating your solution with a Federal, Salesforce-centric environment such as IA Modernization ecosystem. Include:

• High-level architecture (narrative and/or diagram);

• Key components (e.g., APIs, middleware, adapters, data stores);

• How your solution would fit into FEMA’s IA workflow (registration, eligibility determination, case management, recoupment).

b. Identify which parts of your solution would be:

• Hosted by your organization (SaaS, PaaS, etc.);

• Deployed within FEMA’s environment (e.g., Salesforce managed package, on-prem components, containers);

• Managed by third parties (e.g., data aggregators, cloud providers).

4.2 Integration with FEMA’s Individual Assistance Processing System

a. Describe your experience and capabilities to integrate with Salesforce, including:

• Use of Salesforce APIs (REST, SOAP, Bulk, Streaming);

• Any existing Salesforce AppExchange apps, managed packages, or accelerators you offer;

• Experience with Salesforce Government Cloud or public sector implementations, if applicable.

b. Explain how your solution would expose insurance data and functions within FEMA’s Individual Assistance Processing System, such as:

• Custom objects, fields, and relationships (e.g., Survivor, Policy, Claim, Payment);

• Lightning Web Components or other UI components for caseworkers;

• Flows, triggers, or orchestration to support automated rules (e.g., DOB checks, underinsurance calculations).

c. Describe how you would support:

• Real-time lookups from within Salesforce (e.g., caseworker clicks “Check Insurance”);

• Background/batch processes initiated from Salesforce (e.g., nightly refresh of coverage or claims data);

• Error handling and retry logic for failed calls.

4.3 Integration with FEMA’s Individual Assistance Processing System and Other IA Systems

a. Describe how your solution could be integrated with www.DisasterAssistance.gov for survivor-facing flows, including:

• Embedding linking or consent flows (e.g., redirect, embedded widget, iFrame);

• Handling session management and security between the Portal and your service;

• Ensuring a consistent user experience and branding.

4.4 Data Flows, Persistence, and Synchronization

a. Describe the end-to-end data flows you envision between your solution and FEMA, including:

• What data is requested by FEMA and when;

• What data is returned by your solution and how it is structured;

• Where data is persisted (in your environment, in FEMA’s environment, or both).

b. Explain how you would support:

• Initial data load (e.g., first-time coverage checks or account linking);

• Ongoing synchronization (e.g., claim status changes, additional payments);

• Conflict resolution (e.g., when FEMA and carrier data differ).

c. Describe how your solution would support FEMA’s need for:

• Audit trails (e.g., who requested what, when, and what was returned);

• Historical snapshots (e.g., what data was used at the time of a determination);

• Traceability for compliance reviews and recoupment actions.

4.5 Performance, Latency, and Availability Considerations

Note: During peak periods, some of FEMA’s existing integrations have seen transaction volumes in excess of 20 per second.

a. Provide typical and maximum expected response times for:

• Real-time API calls (e.g., coverage check, account linking, claim retrieval);

• Batch or bulk operations (e.g., nightly refresh for a large population).

b. Describe how your architecture supports:

• High availability and fault tolerance;

• Load balancing and scaling during large disasters with high registration volumes;

• Graceful degradation or fallback options if a carrier or data source is temporarily unavailable.

c. Explain any dependencies or constraints that could affect performance (e.g., carrier system availability, third-party aggregators)

4.6 Configuration, Extensibility, and IA Modernization Alignment

a. Describe how configurable your solution is with respect to:

• Data mappings (e.g., mapping carrier fields to FEMA/Salesforce data model);

• Business rules (e.g., thresholds for flagging underinsurance, DOB checks);

• Workflow integration (e.g., when to trigger calls, what to do on failure).

b. Explain how your solution could evolve alongside IA Modernization roadmap, including:

• Ability to add new carriers, data sources, or policy types;

• Ability to support new IA use cases (e.g., additional IA Assistance Program categories, future programs);

• Ability to adapt to changes in FEMA policy, regulations, or business rules.

c. Describe any tools or capabilities you provide to support FEMA’s internal teams (e.g., configuration consoles, admin dashboards, sandbox environments).

4.7 Implementation Approach and Dependencies

a. Outline a notional implementation approach for integrating your solution into FEMA’s IA environment, including:

• Major phases (e.g., discovery, design, build, test, pilot, rollout);

• Typical timelines for each phase;

• Key milestones and decision points.

b. Identify key dependencies on FEMA, carriers, or other parties, such as:

• Access to test environments and sample data;

• Participation of carrier partners;

• Approvals for security, privacy, and architecture.

c. Describe any recommended sequencing (e.g., start with a subset of carriers, a pilot state, or a specific disaster type) to reduce risk and demonstrate value quickly.

February 17, 2026

Topic Area 5 – Security, Privacy, and Compliance

Respond to this section if you propose to handle, process, or transmit FEMA survivor data, including PII/SPII, or to integrate with FEMA systems. This applies to both Technical Area A and Technical Area B.

5.1 Security Architecture and Controls

a. Describe your overall security architecture for the proposed solution, including:

• Hosting environment(s) (e.g., commercial cloud, GovCloud, on-prem);

• Network segmentation and boundary protections;

• Encryption in transit and at rest (algorithms, key management approach).

b. Identify any existing security authorizations or certifications relevant to this effort, such as:

• FedRAMP authorization (include impact level and service model – IaaS/PaaS/SaaS);

• SOC 2 Type II, ISO 27001, or similar;

• Any DHS, FEMA, or other Federal ATOs for related systems.

c. Describe your identity and access management (IAM) approach, including:

• Authentication mechanisms (e.g., SSO, MFA, API keys, OAuth tokens);

• Role-based access control (RBAC) and least-privilege principles;

• How you manage privileged access and administrative accounts.

5.2 PII/SPII Handling and Data Protection

a. Describe how your solution will handle FEMA survivor PII/SPII, including:

• Types of PII/SPII you would store, process, or transmit (e.g., name, address, DOB, SSN last 4, policy numbers);

• Where this data would reside (geographic location, logical/physical boundaries);

• How long you retain such data and how retention policies are enforced.

b. Explain your data protection measures, including:

• Encryption standards for data at rest and in transit;

• Tokenization, masking, or minimization strategies, if used;

• Backup, recovery, and data destruction procedures.

c. Describe how you support data subject rights and obligations relevant to FEMA (e.g., access, correction, deletion), recognizing that FEMA is the system of record owner.

5.3 Privacy, Consent, and Transparency

a. Describe how your solution supports survivor consent and transparency, including:

• How consent is presented to survivors (e.g., language, scope, duration);

• How consent is recorded and stored (e.g., logs, consent records);

• How survivors can review and revoke consent.

b. Explain how your solution can support FEMA’s obligations under:

• The Privacy Act of 1974;

• DHS/FEMA system of records notices (SORNs) related to disaster assistance;

• Applicable Federal privacy policies and guidance.

February 17, 2026

c. Describe any Privacy Impact Assessments (PIAs) or similar analyses you have completed for comparable solutions, especially in the public sector.

5.4 Logging, Monitoring, and Auditability

a. Describe your logging and monitoring capabilities, including:

• Types of events logged (e.g., authentication, data access, data changes, API calls);

• Log retention periods;

• Tools or platforms used for log aggregation and analysis.

b. Explain how your…