PWS Treasury_Fraud_Tools_Requirements_20260527.docx

Treasury Fraud Detection and Payment Verification Tools Draft Statement of Objectives (SOO)/Capability Requirements

1. Objective The U.S. Department of the Treasury seeks commercially available capabilities and related professional services that can help identify, score, explain, verify, and operationalize fraud and improper-payment risk before payments, benefits, grants, refunds, awards, or other Treasury-supported disbursement activities result in improper payments.

For purposes of this document, fraud detection and identity-risk assessment generally refers to probabilistic or rules-supported assessment of identity, entity, behavioral, contact, device, network, watchlist, and transaction-risk signals. Payment verification and payment integrity generally refers to validating whether a payment, account, payee, recipient, or payment instruction satisfies payment-control, account-validation, data-matching, and return-rule requirements. These functions are related and may use overlapping data, but they tend to support different decision points and different operating models.

2. Capability Relationship and Response Organization Treasury is organizing required capabilities into two related capability areas: (1) fraud detection and identity-risk assessment and (2) payment verification and payment integrity.

Fraud detection and identity-risk assessment capabilities support identification and assessment of potentially fraudulent, suspicious, synthetic, or high-risk identities, entities, behaviors, devices, account changes, transactions, or related indicators prior to payment determination, authorization, or disbursement activities. Typical outputs may include risk scores, confidence measures, alerts, indicators, supporting explanations, investigative data, dashboards, and reporting.

Payment verification and payment integrity capabilities support validation and verification of payment, payee, account, ownership, matching, return-history, and related payment-control requirements associated with payment processing and payment-integrity operations. Typical outputs may include match or no-match determinations, account-validation results, ownership-verification results, return indicators, payment disposition outcomes, exception handling, and payment-integrity reporting.

Capabilities may support one or both capability areas depending on operational use case, workflow stage, available data, and authorized use.

3. Fraud Detection and Identity-Risk Product Capability Scope Fraud detection and identity-risk capabilities should support individual and entity screening at enrollment, application, account-change, pre-award, pre-payment, payment-request, disbursement, and retrospective-analysis stages as authorized by the Government. These capabilities are expected to be score-based, indicator-based, or confidence-based, and should help Treasury and agencies identify risk before rigid payment-control decisions are reached. Respondents should describe whether each capability is available today, configurable today, planned, or dependent on third-party services or additional Government data.

Fraud detection outputs may also inform payment verification or post-payment analysis where legally and operationally appropriate, but respondents should explain how risk scores, indicators, and confidence measures would be translated into Government-approved review or payment-control rules.

The core fraud detection and identity-risk product capabilities should include:

· identity resolution and entity resolution;

· synthetic identity fraud risk scoring;

· first-person identity fraud risk scoring;

· death risk scoring;

· watchlist, sanctions, exclusion, or compliance-risk indicators where legally permissible;

· contact, channel, device, session, behavioral, and network-risk indicators where available and authorized;

· explainable score drivers, normalized risk indicators, and review-support outputs; and

· model governance, fairness, monitoring, and performance-management controls appropriate for high-volume Government use.

4. Fraud Detection and Identity-Risk Functional Requirements

4.1 Identity Resolution and Entity Resolution

Resolve individuals and organizations across submitted identity attributes, payment attributes, account attributes, government identifiers, business identifiers, address data, phone data, email data, network/session data, device data, and historical or consortium-derived activity where legally permissible.

Support both individual and organization records, including partial, inconsistent, missing, malformed, stale, or conflicting data.

Return match confidence, attribute-level agreement or disagreement indicators, data-quality observations, and reasons for low-confidence or no-information results.

Distinguish identity-resolution confidence from fraud-risk scoring so that a weak match is not automatically treated as fraud without explanation.

Support entity-linking and network-analysis indicators that can surface shared addresses, shared contact channels, shared devices, shared accounts, shared identifiers, coordinated submission patterns, or other connections that may indicate organized fraud activity.

4.2 Synthetic Identity Fraud Risk Scoring

Provide a synthetic identity fraud risk score or equivalent risk category for identities that appear fabricated, manipulated, or assembled from inconsistent identity attributes.

Detect risk patterns such as SSN/TIN, date-of-birth, name, address, and history inconsistencies; identities with a better-matching identifier elsewhere in available data; identifiers tied to fraud-linked activity; implausible identity attributes; thin or recently created identity histories; and cross-entity activity suggestive of synthetic identity construction.

Differentiate, where supported, between identity manipulation involving a real base identity and wholly fabricated identity construction, without requiring Treasury to adopt any vendor-specific taxonomy.

Return score drivers or reason explanations sufficient for threshold setting, manual review, audit, and model-performance evaluation.

4.3 First-Person Identity Fraud Risk Scoring

Provide a first-person identity fraud risk score or equivalent risk category that helps determine whether the person associated with a transaction, claim, application, award, account, or payment appears to be the genuine person acting with knowledge, control, and legitimate intent.

Detect risk that a real person's identity is being used without their knowledge or consent, including account takeover, stolen identity, mule, nominee, coerced, social-engineering, or payment-redirection scenarios.

Detect first-party abuse patterns where a real person may be intentionally misrepresenting identity, eligibility, history, or intent, including suspicious dispute or block patterns, assumed-identity behavior, or other intentional misrepresentation indicators where legally and operationally appropriate.

Use contact-channel and history indicators such as phone ownership and geography, phone carrier risk, email history, suspicious email handles or domains, recent email creation or priming behavior, IP or location mismatches, address consistency, and other available identity-history signals.

Support configurable thresholds and review categories so Treasury can distinguish low-risk pass-through, needs-review, high-risk escalation, and no-information outcomes.

4.4 Death Risk Scoring

Provide a death risk score, deceased indicator, or equivalent confidence-based outcome that identifies whether an individual associated with a payment, claim, account, award, application, or recipient record may be deceased.

Use legally permissible death data and corroborating identity attributes to reduce false positives and support review of conflicting or low-confidence results.

Return death-risk explanations, relevant attribute agreement, confidence, and data-source freshness information where permissible.

Explain how death-risk scoring would support, differ from, or complement payment-verification death-screening return rules. Fraud detection output should inform risk and review, while payment disposition rules must remain governed by the applicable Government payment-verification process.

4.5 Watchlist, Sanctions, and Compliance Indicators

Identify potential matches against legally permissible watchlists, sanctions lists, exclusion lists, or other Government-approved compliance sources relevant to fraud and improper-payment prevention.

Return match strength, source, list type, relevant identifiers, and review guidance sufficient for compliance escalation rather than an unexplained binary result.

Support clear segregation of compliance indicators from fraud-probability scores where required by law, policy, or operational governance.

4.6 Contact, Channel, Device, Session, and Behavioral Risk Indicators Assess phone, email, IP address, address, device, browser, operating-system, geolocation, and session attributes where such data is available and legally permissible.

Detect anomalous or high-risk sessions, including bot-like behavior, remote-access indicators, browser or operating-system anomalies, proxy/VPN or location risk, suspicious device reuse, and links to prior fraudulent or high-risk activity.

Support passive device or session-risk collection only where authorized and technically appropriate, and disclose any client-side collection, user-notice, consent, accessibility, privacy, and implementation implications.

Return normalized indicators such as pass, review, alert, no-information, and underlying signal details in a way that can be consumed by Treasury systems, dashboards, and case-review workflows.

4.7 Explainability, Case Review, and Reporting

Provide explainable outputs that identify the main score drivers, supporting indicators, confidence level, and recommended review posture.

Support dashboards, exports, or reporting that allow Treasury to review score distributions, high-risk cohorts, recurring risk drivers, volume, latency, throughput, service availability, and operational outcomes.

Support manual review workflows or case-management integration, including the ability to preserve evidence, comments, disposition, reviewer actions, and audit history.

Provide raw or normalized risk indicators where permissible so Treasury can evaluate and tune thresholds without relying solely on a vendor-provided aggregate score.

4.8 Model Governance, Fairness, and Performance Management

Describe model-development, validation, monitoring, drift detection, retraining, versioning, and change-notification practices.

Describe controls for minimizing bias, disparate impact, unexplained adverse outcomes, and over-reliance on protected or proxy attributes.

Provide performance evidence relevant to Government use cases, including precision, recall, false-positive rate, false-negative rate, no-information rate, latency, throughput, service availability, and score calibration where available.

Support Government review of model documentation, risk controls, data provenance, testing methodology, known limitations, and operational guardrails as required by the Government.

5. Payment Verification and Payment Integrity Product Capability Scope Payment verification and payment integrity capabilities should validate whether a payment, debit, refund, claim, benefit, grant, award, or related disbursement activity is directed to the correct account and recipient, and whether account, owner, identity, device, or exception-history signals indicate that the payment should proceed, be flagged, be returned, or receive additional review under Government-approved rules.

This capability lane is generally more deterministic and payment-control-oriented than pre-award or pre-payment fraud scoring. It focuses on account status, account ownership, payee/account alignment, prior payment and exception history, validation against Government-approved sources, and operational payment disposition. Fraud indicators may be identified through payment verification, but they should be presented with the payment-control evidence needed for agency adjudication, audit, and payment operations.

The core payment verification and payment integrity product capabilities should include:

· routing number and account-number validation;

· bank-account status validation, including whether the account appears open, closed, invalid, overdrawn, negative, new, ineligible for debit, or otherwise likely to return;

· account-owner authentication and payee-to-account matching using name, business name, address, TIN/SSN/ITIN, date of birth, phone, driver license, authorized-individual, and other legally permissible attributes;

· account and exception-history review, including prior federal payment history, ACH/check return history, claims, prior attempts to block, reverse, or challenge payment, possible duplicate payment activity, adverse account history, and other signals related to improper payments;

· provider/source orchestration across Government-approved bank-network, financial-agent, commercial identity, account-history, digital identity, email-risk, device-risk, and cross-government account sources;

· machine-readable result normalization, including detailed evidence, operational summaries, and simplified outcome categories where appropriate;

· business-rule-ready outputs that preserve both the summarized disposition and the underlying evidence used to support that disposition;

· real-time, near-real-time, and batch processing modes suitable for high-volume Treasury payment workflows; and

· security, privacy, audit, reporting, and data-disposition controls appropriate for sensitive payment and account data.

6. Payment Verification and Payment Integrity Functional Requirements

6.1 Account Validation and Account Status

Validate routing transit number and account-number combinations for consumer, business, checking, savings, and other supported account types, using Government-approved sources.

Return account-status outcomes that distinguish accounts that appear usable for payment, accounts that appear closed or unusable, cases where available sources do not provide sufficient information, adverse account conditions, account identifiers that cannot be validated, and conditions suggesting that a payment or debit may be returned.

Support validation of disbursements, ACH credits, ACH debits, WEB debit account-validation requirements, refunds, claims, supplier payments, benefit payments, grant payments, and other Government payment or collection use cases.

Support both single-transaction real-time validation and high-volume batch or bulk-file validation, with item-level results, request identifiers, reconciliation, retry handling, and error reporting.

Support account-status freshness indicators, provider/source identifiers, last-update dates, confidence indicators, and known limitations or no-information reasons where available.

6.2 Account Owner Matching and Authentication

Authenticate whether the submitted payee, recipient, claimant, vendor, program participant, taxpayer, organization, or authorized representative appears to be an owner or authorized user of the submitted account.

Support owner matching for individuals and organizations using full name, first name, middle name, last name, suffix/prefix, business name, alternate business name, address, city, state, postal code, TIN/SSN/ITIN or last four digits where authorized, date of birth, phone, email, driver license, and authorized-individual attributes.

Return match indicators at both summary and attribute level, including exact/close match, conditional or partial match, no match, unavailable/no data, and overall match score where available.

Use matching logic that tolerates common name variations, abbreviations, edit distance, phonetic similarity, transpositions, punctuation, spacing, hyphenation, address abbreviations, and other ordinary data-quality variation while preserving adverse mismatch signals.

Distinguish account-status validation from owner authentication so an account can be open while ownership remains mismatched, inconclusive, or unavailable.

6.3 Account History, Exception History, and Improper-Payment Signals Support account-history inquiries that allow Treasury to submit an account and receive available payment, return, claim, exception, and adverse-history information for a defined lookback period or other Government-approved window.

Return exception-history elements such as return count, return categories, last return date, last return reason, claim count, claim categories, non-receipt claims, deceased-payee indicators, non-entitlement indicators, invalid-account indicators, indicators that the provided account could not be found or validated, and other payment-integrity exception categories where available.

Identify whether an account has prior successful federal payment history, prior account-and-payee matched payment history, prior account-and-TIN matched payment history, prior account-and-name matched payment history, or prior account-and-owner history sufficient to support confidence in the account-payee relationship.

Surface high-risk payment indicators such as recent adverse account history, prior returns caused by insufficient available funds or comparable account conditions, unresolved payment or account exceptions, prior attempts to block, reverse, or challenge payment, possible duplicate payment activity, prior failed payment attempts, repeated submission patterns, conditions suggesting that a payment or debit may be returned, and other patterns associated with administrative returns, fraud, or improper payments.

Support cross-government account matching and internal account-history analysis as an evidence tier that may complement external bank-network or commercial account-validation responses.

6.4 Provider and Source Orchestration

The solution should support modular orchestration across Government-approved and legally permissible sources. The requirements below describe capability categories and required functional coverage, not named vendors, named products, proprietary services, or proprietary interfaces.

Support bank-network, financial-institution, and consortium account-validation sources that can verify routing/account combinations, account existence, account status, debit eligibility, payment-return risk, account closure, adverse account conditions or history, and account-owner alignment.

Support commercial or financial-network account-status and account-owner verification capabilities that can validate account ownership, account status, authorized-user relationships, account risk, identity consistency, and payment-routing suitability where authorized by Treasury.

Support identity-verification capabilities that return verification indexes or confidence measures, field-level match indicators, and risk indicators for name, address, TIN/SSN/ITIN, date of birth, phone, driver license, organization attributes, authorized representatives, and related identity attributes.

Support identity-data validation capabilities that can assess SSN/name/date-of-birth consistency, deceased-identifier indicators, identifier issuance timing, high-risk address indicators, mail-drop indicators, business-address indicators, and other identity-data anomaly checks.

Support email-intelligence capabilities that can provide email risk scoring, email-history indicators, domain-risk indicators, suspicious-email indicators, email/account consistency indicators, and imposter-scam or social-engineering indicators as part of payment-integrity review where email is available and legally permissible.

Support digital identity, device, and session-risk capabilities that can provide device fingerprinting or device recognition, browser and operating-system anomaly detection, bot detection, remote-access indicators, location-risk indicators, proxy/VPN indicators, behavioral-risk indicators, velocity indicators, and linked-fraud or network-risk indicators where the workflow involves online enrollment, account maintenance, payment request, or pre-payment interaction.

Support Government-owned or Government-managed sources such as cross-government account matching, account history, payment history, exception history, TIN validation, routing-number validation, and other DNP-designated sources.

Support configurable waterfall, parallel, or tiered routing logic so Treasury can minimize cost, latency, and unnecessary external calls while preserving sufficient evidence for high-risk, no-information, or conflicting cases.

6.5 Request Data and Response Data

Accept minimum account inputs, including routing transit number and account number, and accept optional transaction inputs such as transaction type, amount, currency, payment or check serial number, payment channel, request context, program or agency metadata, and unique request ID.

Accept owner inputs for individuals and organizations, including name components or full name, organization name, alternate name, postal address, TIN/SSN/ITIN, date of birth, phone, email, driver license, authorized representatives, and other legally permissible identifiers.

Return provider/source-specific details and normalized Government-facing summaries, including account status, owner status, match score, attribute-level match indicators, response code, reason code, error code, no-information reason, source identifier, and data freshness indicator where available.

Support detailed evidence responses for audit and analysis, operational summaries for decisioning, and simplified outcome categories for systems that only need normalized results.

Support response categories that can map to payment-verification business rules, including whether payment may proceed, whether account-owner evidence appears aligned or misaligned, whether account or owner evidence requires review, whether available sources provide insufficient information, whether a payment or debit appears likely to be returned, whether payment should be suspended or returned, and whether a processing or validation error occurred.

6.6 Digital, Email, and Device Risk for Payment Workflows

For online workflows, support digital-session and device-risk analysis that can help distinguish legitimate users from scripted bots, compromised sessions, synthetic or stolen identities, remote-access misuse, and payment-redirection attempts.

Capture or accept session-level indicators only where legally authorized and appropriately noticed, including session ID, browser attributes, operating-system attributes, device attributes, IP/geolocation attributes, behavior patterns, failed attempts, typing or click patterns, scroll behavior, correction behavior, and orientation changes where applicable.

Return digital and device outcomes such as pass, needs review, fail, no information, risk alert, browser anomaly, operating-system anomaly, bot indicator, remote-access indicator, linked-fraud indicator, location risk, and behavioral risk signal.

Support email-risk indicators that identify suspicious email history, high-risk domains, limited history, suspected fraud email, email/location mismatch, and other account-control signals relevant to payment enrollment, account changes, or disbursement redirection.

Preserve digital, device, and email risk outputs as supporting payment-integrity evidence rather than automatically dispositive payment-return rules unless Treasury separately approves that operating model.

6.7 Operational Controls, Reporting, and Auditability

Provide quality-control and reporting capabilities for accuracy, volume accountability, processing times, workload tracking, service availability, provider/source availability, error categories, timeout rates, no-information rates, and management responsiveness.

Support agency and Treasury reporting on payment-verification outcomes, account-status outcomes, owner-match outcomes, exception-history outcomes, and payment disposition without obscuring the underlying evidence.

Preserve audit trails that link each result to request data, source/provider responses, normalized summaries, rule evaluation, manual review, disposition, and data-disposition records where applicable.

Support operational review of false positives, false negatives, inconclusive results, conflicting-source results, override decisions, agency adjudication, and rule-tuning needs.

Retain records, reports, documents, and other evidence related to payment verification and account validation according to Government retention and audit requirements.

7. Shared Performance, Scalability, and Availability Requirements

7.1 Fraud Detection and Identity-Risk Throughput

Real-time or near-real-time fraud detection and identity-risk screening must support sustained throughput greater than 500 transactions per second, with respondents describing tested maximum throughput, burst capacity, throttling behavior, queueing behavior, horizontal-scaling approach, and expected latency at volumes above 500 transactions per second.

Batch fraud detection and identity-risk screening should support large file or bulk-query processing with volume accountability, file-level reconciliation, item-level result status, error reporting, restart/retry handling, and predictable completion timelines.

7.2 Payment Verification and Payment Integrity Throughput

Real-time payment verification and account-validation services should support sustained high-volume operation and must support surge or temporary operating capacity greater than 1,000 transactions per second for defined high-demand windows, emergency programs, tax-season spikes, disaster programs, new-program launches, or other Treasury-approved surge events.

Respondents should distinguish normal sustained throughput, tested maximum throughput, temporary surge throughput, burst duration, throttling behavior, queueing behavior, downstream provider limits, and latency at volumes above 1,000 transactions per second.

Batch processing should support every-calendar-day operation except for Government-approved exceptions, with documented file-size limits, item-level reconciliation, restart/retry procedures, and predictable completion timelines.

7.3 Shared Availability, Resiliency, and Dependency Disclosure Services should be available 24 hours a day, 365 days a year for Government-approved real-time use cases unless otherwise approved by Treasury.

Solutions should include resiliency, redundancy, disaster recovery, incident response, monitoring, service-level reporting, and continuity-of-operations approaches appropriate for federal payment and fraud-prevention use cases.

Respondents should identify dependencies that may affect scale, including third-party data providers, external enrichment services, client-side collection, downstream provider limits, rate limits, licensing limits, data-refresh schedules, batch-window limits, test-environment limits, manual-review bottlenecks, and support procedures for temporary capacity increases.

8. Shared Data Handling, Security, and Privacy Requirements Securely ingest, process, store, transmit, and dispose of sensitive Treasury data, including personally identifiable information, controlled unclassified information, tax-related data where authorized, payment data, account data, and fraud-risk outputs.

Comply with applicable federal security, privacy, records, and data-handling requirements, including NIST 800-53 controls, FISMA requirements, FedRAMP or equivalent cloud authorization where applicable, encryption, access control, logging, monitoring, incident response, and audit requirements.

Operate within Treasury-approved or Treasury-designated environments when required and disclose all hosting locations, subcontractors, third-party services, data-processing locations, and cross-border data-transfer implications.

Use Government-provided data only for authorized Government purposes, prohibit unauthorized reuse or model training unless separately approved in writing, and certify data disposition at the end of any Government-authorized evaluation period.

Support data minimization, role-based access, least privilege, segregation of Government data, retention controls, export controls, and reproducible audit trails.

9. Shared Integration and Product Delivery Requirements Support secure system-to-system integration patterns suitable for Treasury and agency workflows, including synchronous screening, asynchronous screening, batch submission, result retrieval, dashboard review, and case-management integration.

Support configurable rules, thresholds, outcome categories, and escalation paths without requiring custom feature development during market research.

Identify minimum and optional input data for each capability, including whether the capability can return useful results with sparse data and what data elements materially improve match quality or risk-score quality.

Provide result schemas or equivalent output descriptions that distinguish risk score, risk category, confidence, no-information, match quality, score drivers, supporting indicators, recommended review posture, account status, owner status, and payment-verification disposition.

Describe product documentation, administrator controls, user controls, reporting interfaces, monitoring interfaces, and technical integration materials available to Government users.

10. Professional Services, Retrospective Analysis, and Pilot Support Professional services, implementation support, advisory services, staffing, retrospective analysis, and pilot-analysis support should remain a separate response lane from the product capability requirements above. Respondents may propose professional services for fraud detection, payment verification and payment integrity, or both. A respondent is not required to support both capability families; Treasury should be able to evaluate a respondent for the lane or lanes in which the respondent satisfies the applicable requirements.

Respondents should distinguish product functionality from services such as implementation planning, data mapping, retrospective data analysis, KPI development, baseline development, pilot evaluation, threshold calibration, payment-rule design, model-governance support, training, operational playbooks, case-review support, integration support, and sustainment support.

10.1 Professional Services Scope by Capability Family

Respondents should identify whether their proposed professional services apply to fraud detection and identity-risk assessment, payment verification and payment integrity, or both. If a respondent proposes only one lane, the response should describe the applicable data requirements, analytical methods, staffing, deliverables, assumptions, and limitations for that lane without implying coverage of the other lane.

For fraud detection and identity-risk assessment, professional services should support retrospective analysis of identity, entity, behavioral, contact-channel, device/session, network, watchlist, transaction, and other authorized risk indicators to identify, quantify, and categorize suspected or confirmed fraud patterns.

For payment verification and payment integrity, professional services should support retrospective analysis of account status, account-owner matching, payee/account alignment, return history, exception history, payment history, account-history signals, improper-payment indicators, and payment disposition outcomes.

10.2 Fraud and Improper-Payment Taxonomy Development

Professional services should include data-science and subject-matter support to categorize fraud, suspected fraud, payment-verification failures, and improper-payment patterns into discrete, explainable sections that Treasury can use for reporting, benchmarking, rule design, and operational decision-making.

The taxonomy should preserve the working distinction between fraud detection and payment verification/payment integrity while allowing cross-cutting analysis where the same transaction, recipient, identity, account, or program record has indicators in both families.

Categories should be defined in a way that supports consistent measurement over time, including category definitions, inclusion and exclusion rules, confidence levels, evidence requirements, known data-quality limitations, and the relationship between vendor-derived indicators and Government adjudication or return outcomes.

10.3 Two-Year Baseline Analysis

Professional services should develop a general two-year baseline of fraud, suspected fraud, payment-verification issues, and improper payments using Government-provided historical data and legally authorized enrichment or scoring methods. The baseline should quantify the volume, dollar value, rate, distribution, and concentration of relevant categories across dimensions designated by Treasury.

Baseline dimensions may include agency, program, payment type, payment channel, benefit or disbursement category, recipient type, entity type, account type, account status, owner-match outcome, return or exception reason, identity-risk category, device/session-risk category, geography, time period, data source, confidence level, no-information outcome, and other dimensions approved by Treasury.

The baseline should support ongoing measurement of program performance and improper-payment prevention activities. Respondents should explain the methodology, assumptions, data sources, data exclusions, statistical confidence where applicable, repeatability of the analysis, and how Treasury could refresh the baseline over time.

10.4 KPI Development and Measurement Recommendations

Professional services should recommend KPIs for each applicable capability family and for the combined improper-payment prevention mission. KPIs should support both baseline measurement and ongoing program assessment and should distinguish fraud-detection performance from payment-verification/payment-integrity performance.

Recommended KPIs may include money saved or preventable dollars, improper-payment dollars identified, fraud-risk dollars identified, transactions prevented or flagged, return reduction, exception reduction, account-owner mismatch rate, account-status issue rate, identity-risk rate, synthetic identity risk rate, first-person fraud risk rate, death-risk hit rate, no-information rate, review rate, alert-to-action rate, false-positive rate, false-negative rate where measurable, precision, recall, coverage, latency, and operational cost per dollar protected.

Respondents should provide recommendations on how Treasury should interpret baselines, compare vendors or services, avoid double-counting, handle overlapping categories, separate confirmed outcomes from risk indicators, and measure efficacy after any future operational integration.

10.5 Staffing, Methods, and Deliverables

Professional services should include appropriately qualified data scientists, statisticians, payment-integrity analysts, fraud analysts, data engineers, and subject-matter experts needed to ingest, normalize, analyze, interpret, and present the results.

Expected deliverables may include a data-analysis plan, data dictionary and mapping notes, taxonomy and category definitions, two-year baseline report, one-month pilot report, KPI framework, reproducible analytical methodology, executive summary, detailed technical appendix, dashboard or tabular outputs, limitations register, and recommendations for future operational integration or additional data collection.

The analysis should preserve traceability from each metric and category to the underlying data, assumptions, scoring outputs, business rules, source responses, and Government outcome data used to support it.

10.6 Data Handling, Governance, and Limitations

Professional services must comply with all applicable security, privacy, data-use, record-retention, and Government data-handling requirements. Respondents should identify any data needed to conduct the analysis, any third-party data or enrichment proposed, any data retention or reuse limitations, and any constraints that affect repeatability, validation, explainability, or operational adoption.

Respondents should clearly state analytical limitations, including incomplete ground truth, missing attributes, no-information outcomes, sampling limits, historical-policy differences, downstream provider limits, potential overlap among categories, and cases where risk indicators cannot be treated as confirmed fraud or confirmed improper payments without Government adjudication.

Page 2 of 14 DRAFT Statement of Objectives (SOO) May 2026