01 / FraudGuard™ — the single-record screen
Does this one record look wrong on its own?
FraudGuard™ screens a single payment, application, or transaction the moment it appears — before it joins the graph, before a dollar moves. It pattern-matches each record against known fraud signatures, threshold breaches, and anomalies versus expected program behavior. A hit doesn’t get recovered after the fact. It’s held at the decision.
02 / What FraudGuard checks
Three reads on a single record.
FraudGuard works on the record in front of it — one payment, one application, one transaction. It doesn’t need the chain or the entity history to raise its hand. Each record gets three reads.
Read 01
Known signatures
Matches the record against a library of known fraud patterns — structures, sequences, and shapes that have signalled fraud before.
Read 02
Threshold breaches
Tests the record against program limits and ceilings. An amount, a frequency, or a timing that crosses a hard boundary gets flagged on contact.
Read 03
Behavioral anomalies
Compares the record to expected behavior for its program. What’s statistically off — not just over a fixed line — surfaces as a signal for review.
03 / Three questions, three signal sources
FraudGuard asks the first one.
Decision Pipelines™ runs three independent signal sources, each asking a different question of the same federal dollar. They don’t replace each other — they catch different things. FraudGuard is the single-record lens.
Single record · FraudGuard™
Does this one record look wrong on its own?
Signatures, thresholds, and anomalies on an individual payment, application, or transaction — no context required.
Entity · Identity resolution
Is this really the same entity?
Resolves records from many sources to canonical tokens the graph hangs off — and raises its own alerts when identities collide.
Chain · Fund-flow graph
Does this chain of money make sense?
Conservation, cycles, skip-tiers, orphans — anomalies in the shape of the path that only appear end to end.
04 / The layer underneath — identity resolution
Stable IDs first. Then the graph can hang off them.
Before the flow graph can connect anything, every record has to resolve to a canonical entity. Identity resolution does that — matching across SAM, SSA, IRS, and state eligibility databases. It’s a prerequisite for the graph, and a signal source in its own right.
Conflicts
One strong key — an SSN, a UEI — pointing at divergent attributes. Or one identity reached through mutually inconsistent strong keys. The system refuses to silently merge them.
The conflict itself is the signal.
Gray-band matches
Confidence in the middle band — too strong to drop, too weak to trust. Rather than auto-merge or discard, the match is promoted to a governed Decision for human adjudication.
Promoted, not guessed.
05 / Built to screen against the federal record
The same sources oversight uses.
FraudGuard is designed to screen each record against the authoritative federal sources — so duplicate identities, excluded parties, and deceased recipients are caught at the decision, not discovered in a post-payment clawback.
06 / Where this is in the build
Straight about what’s live.
The screening logic and the governance around it are built. The live program feeds that put real records through it are the integration step ahead — so the working prototype runs on seeded, synthetic records.
07 / On the record
A flagged record isn’t a recovery problem. It’s a decision.
FraudGuard catches the single record. Identity resolution catches the entity. The graph catches the chain. Every hit lands in the same place — held on the record, with rationale, before the money moves.
Screen at the decision. Not in a post-payment clawback.