Anomaly detection for federal missions.

Fraud, intrusion, claims anomalies, procurement anomalies, sensor anomalies. Calibrated false-positive rates, explainable alerts, operator-ready workflows. Detection that investigators actually use.

What we build

Anomaly detection is where machine learning confronts operational reality hardest. Most federal anomaly programs fail not because the models are wrong but because they are calibrated for a research metric instead of operator capacity. A model with 95% AUC and 500 alerts a day is useless to an investigator with bandwidth for 20. Our anomaly work starts with the question every federal program should start with: how many alerts per day can an operator investigate, and how do we maximize mission value within that budget.

We build production anomaly detection systems across fraud, network intrusion, medical claims, procurement, and sensor telemetry. Every system is designed with explicit alert-budget constraints, explainable outputs for investigators, and feedback loops that capture analyst adjudication to continuously retrain.

  • Fraud detection — benefits fraud (SSA, UI, SNAP), identity fraud, procurement fraud, grant fraud, tax fraud.
  • Medical claims — Medicare, Medicaid, Tricare, VA claims anomalies; provider profiling; DME fraud; billing errors.
  • Network intrusion — UEBA, lateral movement, C2 beaconing, data exfiltration, insider threat.
  • Procurement & contracting — bid rigging, collusion, phantom vendors, duplicate invoicing, price anomalies.
  • Sensor telemetry — industrial, aerospace, medical equipment anomaly detection for predictive maintenance.
  • Transaction monitoring — AML, sanctions evasion, cross-border payments anomalies.
  • Document and records anomalies — altered forms, synthetic identities, duplicate enrollment.

Tabular anomaly detection

For structured data (claims, transactions, applications), PyOD gives a solid toolkit: Isolation Forest, Local Outlier Factor, HBOS, ECOD, COPOD, and AutoEncoder variants. ECOD and COPOD have strong theoretical grounding and scale well. Isolation Forest remains the most interpretable default. For truly large tabular data (hundreds of millions of rows, thousands of features), we use DASK-parallel PyOD or gradient boosting with anomaly-aware objectives (one-class XGBoost variants).

When labels exist from past investigations, we move to supervised or semi-supervised learning, handling extreme class imbalance (fraud is typically 0.1-2% of cases) with focal loss, class-weighted gradient boosting, or scaled positive-unlabeled learning (PU learning). Supervised models recover schemes that match historical patterns. We always run an unsupervised companion model in parallel to surface schemes that do not, because fraudsters adapt.

Time-series anomaly detection

Sensor streams, transaction velocity, network flow rates, login counts, and claim volumes all generate time-series where the signal is a departure from individual baselines rather than an absolute threshold. Our time-series anomaly stack: matrix profile (STUMPY) for subsequence anomalies, seasonal-residual methods (STL decomposition) for seasonal series, LSTM autoencoders for multivariate sequences, TranAD and USAD for modern transformer-based approaches, and change-point detection (Bayesian online, CUSUM, ruptures) for regime shifts.

Streaming deployment matters here. A good batch anomaly detector is not the same as a streaming one. We deploy with Flink or Kafka Streams for low-latency scoring, Redis-backed state stores for entity baselines, and windowed aggregations that update incrementally.

Graph-based anomaly detection

Fraud and insider threat patterns are often visible only at the network level. A single transaction or claim looks normal; the connections between entities reveal the scheme. We use graph-based anomaly detection: PyG and DGL for GNN implementations (GraphSAGE, GAT), dominant-subgraph methods for dense-cluster detection, Oddball for egonet features, and entity-resolution pipelines to build the graph correctly in the first place (typos, abbreviations, and shell entities break naive joins).

Concrete examples: Medicare DME fraud rings where providers, patients, and suppliers form suspicious sub-networks; procurement collusion where a small set of vendors bid against each other across programs; UI fraud where beneficiary addresses cluster in unusual ways. In each case, the entity pair or triplet is the unit of analysis, not the individual record.

Medical claims anomalies

Medicare and Medicaid fraud alone cost taxpayers an estimated $50-100B annually. The CMS Fraud Prevention System and the HHS OIG have built sophisticated detection, but the space remains rich with room for improvement. Our approach combines provider profiling (billing volume, procedure mix, beneficiary demographics, geography) with peer comparisons within specialty bands, network analytics for collusion, and supervised learning on OIG and ZPIC-confirmed cases.

Explainability is mandatory. A claim flagged as anomalous needs a reason: "provider X bills CPT 99215 at 3.2x the specialty-geography median with a 94% new-patient ratio inconsistent with established practice." Investigators use that explanation to triage and build cases. SHAP values, counterfactual explanations, and feature-attribution dashboards are standard deliverables.

Network intrusion and insider threat

Federal cybersecurity teams drown in SIEM alerts. Most intrusion detection programs underperform because rules generate volume and ML layers produce unexplained scores that analysts ignore. We build UEBA layers that supplement existing SIEM deployments with per-entity behavioral baselines (users, hosts, service accounts, network segments) and detect deviations with calibrated alert volumes. MITRE ATT&CK mapping per alert lets analysts triage by tactic and technique rather than by score.

Data sources: Windows event logs, Sysmon, EDR (CrowdStrike, SentinelOne, Defender), network flow (Zeek, Suricata), authentication (AD, Okta, PIV), cloud audit (AWS CloudTrail, Azure Activity Logs). We normalize these into an entity-relation schema, run behavioral models per entity, and combine into a session score that an analyst can explain. Integration with TheHive, SOAR platforms, and ticketing systems closes the investigation loop.

Procurement and contracting anomalies

Federal procurement generates hundreds of billions in transactions annually. Bid rigging, phantom vendors, duplicate invoicing, split purchases to avoid thresholds, collusion rings, and inflated pricing all leave detectable patterns. We combine SAM.gov entity data, FPDS contract data, treasury payment data (via treasury direct or agency feeds), and USAspending to build entity graphs and detect anomalous patterns. Benford's Law on invoice amounts, duplicate-invoice detection with fuzzy matching, and bidder-rotation analysis on bid histories are specific tools.

Evaluation done right

The biggest cause of federal anomaly detection failure is bad evaluation. AUC-ROC looks good on paper but does not reflect operator reality. We use: precision-at-k (how many of the top 100 alerts are real), recall-at-fixed-FPR (how much fraud is caught with an operator-sustainable false-positive rate), time-to-detection for streaming cases (how fast after anomaly onset), and utility functions that weight operator time against value of detections. Walk-forward backtests with realistic alert budgets are mandatory. Random splits on temporal data are banned.

Federal agencies and programs

  • HHS OIG, CMS — Medicare, Medicaid, healthcare fraud
  • SSA, DOL — disability fraud, UI fraud, benefits fraud
  • DoD, DHS — network intrusion, insider threat, supply chain anomalies
  • Treasury FinCEN — AML, sanctions, BSA anomalies
  • FBI, DOJ — criminal pattern detection, evidence anomalies
  • GSA, agency CFOs — procurement fraud, improper payments

Related reading

Federal anomaly detection, answered.
What anomaly detection methods do you use?

PyOD tabular methods (Isolation Forest, ECOD, COPOD), time-series (matrix profile, LSTM-AE, TranAD, USAD), graph (GNN, Oddball), and supervised gradient boosting where labels exist. Method choice follows data shape.

How do you handle false positive rates?

Explicit alert budgets tied to operator capacity. Precision-at-k as primary metric. Per-segment calibration. Human-in-the-loop feedback to continuously retrain.

Can you detect novel attacks or fraud schemes?

Yes. Unsupervised anomaly detection plus graph analytics plus rule-based red flags. Supervised models only catch past patterns; novel schemes require behavioral baselines and graph signals.

How do you handle medical claims anomalies?

Provider profiling, peer comparisons within specialty and geography, network analytics for collusion, supervised learning on OIG-confirmed cases. Explainability mandatory for investigator adoption.

What about network intrusion?

UEBA layers on SIEM/EDR telemetry, per-entity behavioral baselines, MITRE ATT&CK mapping per alert. Works with Splunk, Sentinel, Elastic, Chronicle, Wazuh.

How do you evaluate?

Precision-at-k, recall at fixed FPR, time-to-detection, utility functions that weight operator time vs value. Walk-forward backtests with realistic budgets, not random splits.

Often deployed together.
1 business day response

Catch what matters, not what wastes time.

Production anomaly detection for federal agencies. Ready to deliver.

[email protected]
UEI Y2JVCZXT9HP5CAGE 1AYQ0NAICS 541512SAM.GOV ACTIVE