Verify vs. Detect: Why Identity Proofing Alone Misses Enrollment Fraud

During open enrollment, an exchange integrity analyst may find a cluster of approved applications linked by reused phone numbers, bank details, or an agent identifier. Each application cleared remote identity proofing, and each uploaded income document rendered normally in the portal. The scenario is a composite based on the broker-driven enrollment patterns CMS has described publicly, including complaints about unauthorized plan switches and enrollments ^[2].

Here is the direct answer to the question this raises: identity verification evaluates a claimed identity within an application ^[4]. Enrollment fraud is behavior that emerges across applications, over time, through a shared actor. Proofing is an application-level control. Fraud detection is a cross-application control. If your stack stops after proofing, the shared-actor pattern stays invisible.

That distinction is not academic. It mirrors what happened in cloud security over the last five years. Endpoint tools got good enough that attackers stopped bringing malware and started bringing valid credentials. CrowdStrike reported that the large majority of its detections in 2024 were malware-free, meaning the intrusion looked like an authenticated user doing authenticated things ^[3]. No single event was alertable. Only the sequence told the story. Enrollment fraud has the same shape: valid-looking identities, valid documents, valid broker credentials, and a pattern that exists only in the aggregate.

The Applicant Who Passed Every Check and Never Existed

Walk that composite cluster forward. Each applicant resolves to a real Social Security Number. Each has a plausible address. Each reports household income landing in the low end of the subsidy range, the band where premium tax credits push net premiums toward zero for many Marketplace enrollees, so the applicant never notices a bill ^[9].

Verification did its job. It asked "is this a real identity, backed by evidence that resolves to a real-world person?" and returned a defensible yes, which is precisely the question NIST SP 800-63A tells it to answer ^[4]. Nobody in the pipeline asked the second question: is this the same actor filing hundreds of times?

Nobody asked because no system in the stack is responsible for asking. The proofing vendor sees one application and returns a result. The eligibility engine evaluates household composition against program rules ^[5]. The document portal accepts a PDF and stores it. The case management system opens a case only after someone else files a complaint. The pattern lives in the seams between those systems, which is exactly where fraud lives in every other domain.

This is why control-coverage thinking beats category shopping. When a vendor says "we do identity," ask which specific jobs they perform and which they leave to something else.

What Identity Proofing Actually Promises (and What It Does Not)

NIST's Digital Identity Guidelines describe identity proofing around a central purpose: resolving a claimed identity to a real-world person using validated evidence ^[4]. That boundary does not address intent, program eligibility, or patterns created when the same actor submits multiple applications.

A synthetic identity built on a legitimately issued but misused SSN can satisfy a remote IAL2 flow. The number exists. The name and date of birth may match a credit header. The address is real. The person behind the keyboard is not the person the number belongs to. The Federal Reserve's synthetic identity fraud work describes exactly this failure mode: the identity is stitched together from real and fabricated attributes, so systems designed to confirm existence confirm existence ^[6].

CMS Marketplace standards, including MARS-E security and privacy requirements and remote identity proofing expectations, set a floor for eligibility systems ^[5]. A floor is not a detection ceiling. Treating that compliance posture as fraud coverage is the same category error as treating encryption at rest as breach detection.

Data-source matching also inherits the gaps of the data underneath it:

• Thin files. Young applicants, recent immigrants, and people outside the credit system have little to match against, so verification either fails legitimate applicants or lowers its bar.
• Credit-header noise. Stale addresses and typo-derived name variants make near-matches routine, which trains reviewers to accept fuzzy results.
• Deceased and reused numbers. Death Master File hits and numbers appearing under multiple unrelated names are adjudication problems, not resolution problems.
• Randomized issuance. Since SSA moved to SSN randomization, geographic and sequential inference no longer applies, so any issuance-plausibility logic has to be rebuilt against current rules ^[7].

The practical takeaway: proofing answers "does this person exist and is this evidence valid" ^[4]. It does not answer "is this number legitimately theirs," "was this paystub fabricated," or "how many other applications share this artifact."

A Control-Coverage Matrix for Enrollment Integrity

Stop evaluating tools by category name. Build a matrix where rows are concrete jobs and columns are the systems you already own, then find the empty cells. The rows below are anchored to published expectations: identity binding from NIST SP 800-63A ^[4], eligibility and MARS-E obligations from CMS Marketplace standards ^[5], SSN adjudication data from SSA ^[7], and referral evidence standards from the Medicaid Fraud Control Unit program ^[8].

Run this against your stack in an afternoon. For each row, name the system, the team, and the person who would get paged. Empty cells are not gaps in tooling first. They are gaps in ownership.

The seams matter more than the boxes. The proofing vendor knows whether the identity resolved ^[4]. The eligibility engine knows household composition and the income attestation ^[5]. If those systems do not bring their context together at decision time, an unusual income pattern may never be compared with other applications from the same agent ^[9].

The Four Signals Verification Never Sees

Document forensics

A fabricated paystub rarely fails a visual check. It fails a structural one. Font substitution and text reflow appear where a template was edited. XMP and PDF producer metadata shows a consumer editing tool rather than a payroll provider. Object-level hashes repeat across applications from unrelated employers, which is the tell that one template is serving a whole ring. Altered special-enrollment-period letters are the same story with a date field.

SSN intelligence

Issuance context versus date of birth, numbers in never-issued ranges, numbers appearing under multiple unrelated names, and death-file hits are adjudication signals, not resolution signals ^[7]. A verification pass and a bad SSN adjudication can both be true for the same application ^[6].

Broker and agent behavioral analytics

Submission velocity per NPN, off-hours clustering, near-identical income figures landing just above or below program thresholds, and reused contact and payment artifacts. One application from an agent looks like work. Ninety in a night across three phone numbers looks like a business model, and it is the behavior pattern behind the agent and broker suspensions CMS reported in 2024 ^[2].

Graph relationships

Entity resolution across address, phone, email domain, bank account, and device fingerprint surfaces clusters that are invisible one application at a time. Same reasoning that makes graph analysis useful in identity security generally: the individual events are authorized, the relationship structure is not ^[3].

GAO's improper-payment reporting shows why program-integrity teams need controls that work across systems rather than only at intake ^[1]. The practical lesson is not a national dollar figure; it is that documentation, eligibility, identity, and behavior must be reviewed together when the risk question crosses those boundaries.

Why the "One Application at a Time" Review Model Breaks

Eligibility review is usually organized around the individual case, which can leave cross-case patterns out of view. Checking whether a phone number, bank account, address, or agent identifier also appears in unrelated applications requires access to a broader dataset and a workflow designed for that question. Documentation and verification gaps recur in federal improper-payment reporting, which shows why that broader view matters ^[1].

Manual investigation often becomes record stitching. Answering "what did this agent touch" can require application history, broker attestations, document files, call-center notes, and payment records from several systems. The investigation becomes easier to review when each source is linked through a repeatable procedure instead of reconstructed informally.

A repeatable procedure makes the work easier to follow. The sequence below is a documentation discipline: each step produces an artifact an outside investigator can understand without direct access to your systems ^[8].

• Pin the identifiers. Start with the applicant ID, SSN hash, agent NPN, device fingerprint, and payment instrument. Record the SSN signal as an adjudication result rather than a simple match flag, because reuse and death-file conditions are different questions ^[7].
• Pull connected applications. Find applications that share an artifact with the starting set across the relevant enrollment period.
• Build the relationship tree. Use applications, agents, addresses, phones, and accounts as nodes, then timestamp the shared-artifact links so another reviewer can retrace them.
• Classify the behavior. Separate template reuse, income clustering, velocity anomalies, and identity anomalies so each finding can be reviewed independently.
• Produce a scope table. Summarize the affected enrollments, funds at risk, plans and issuers involved, and the agent-of-record chain ^[9].

Speed here is a compliance control, not an efficiency metric. Referral windows close. Recovery windows close. Advance premium tax credit dollars keep flowing monthly while the case sits ^[9].

Designing the Verify-Then-Detect Pipeline

Sequence the stages so each one narrows the population the next has to examine:

1. Proofing decision. Identity resolves or it does not. Record the assurance level and the evidence used ^[4].
2. Document forensics. Metadata, font and layout structure, template hashes, and issuer plausibility.
3. SSN adjudication. Death-file hits, cross-name reuse, never-issued ranges, issuance plausibility ^[7].
4. Entity resolution. Link applications by phone, address, email, bank account, and device.
5. Ring scoring. Score the cluster, not just the application.
6. Human review. A named reviewer, a documented rationale, an audit entry.
7. Referral packet. Evidence, chain of custody, and the reviewer's determination ^[8].

A verification pass raises trust. Behavioral risk can lower it again. That is the progressive trust model applied to enrollment: trust is a running score that responds to new evidence, not a stamp collected at the front door. Response escalates in proportion to evidence strength, from monitoring, to requesting additional documentation, to holding pending review, to suspending the agent of record, to referral.

Here is a scoring rule expressed concretely so you can argue with it. Thresholds are illustrative starting points, not tuned values:

{
  "rule_id": "ring-cluster-policy",
  "window": "<policy-defined enrollment period>",
  "cluster_key": ["agent_npn", "phone_e164", "bank_account_hash", "address_norm"],
  "signals": {
    "shared_artifacts": { "threshold": "<validated threshold>", "weight": "<model weight>" },
    "cluster_size": { "threshold": "<validated threshold>", "weight": "<model weight>" },
    "submission_velocity": { "threshold": "<validated threshold>", "weight": "<model weight>" },
    "income_clustering": { "threshold": "<validated threshold>", "weight": "<model weight>" },
    "document_template_match": { "threshold": "<validated threshold>", "weight": "<model weight>" },
    "ssn_adjudication_flag": { "values": ["deceased", "cross_name_reuse"], "weight": "<model weight>" }
  },
  "actions": ["monitor", "request_documentation", "hold_pending_review", "refer"],
  "human_review_required": true
}

And the query shape that finds shared artifacts before you buy anything:

SELECT phone_e164,
       COUNT(DISTINCT application_id) AS apps,
       COUNT(DISTINCT agent_npn)      AS agents,
       MIN(submitted_at), MAX(submitted_at)
FROM approved_applications
WHERE submitted_at >= :review_window_start
GROUP BY phone_e164
HAVING COUNT(DISTINCT application_id) >= :minimum_cluster_size
ORDER BY apps DESC;

No adverse eligibility or coverage action should rest on a score. Detectory routes scored clusters into a review queue where a person makes the call and the rationale is written to the audit trail, which is also what makes the resulting packet usable by an MFCU ^[8]. If you are evaluating options, our rundown of public benefits fraud detection platforms covers how these layers get packaged differently across vendors.

Metrics That Prove the Detection Layer Is Working

Leading indicators, tracked weekly:

• Shared-artifact rate. Share of approved applications sharing two or more identity artifacts (phone, address, bank account, device) with another approved application. Source: application database plus entity resolution output. Direction: down.
• Applications per unique agent NPN per week. Plot the distribution and flag the top decile. Source: broker submission records. Direction: watch the tail, not the mean.
• Document template reuse rate. Distinct template hashes divided by document count. Source: document forensics output. Direction: down.

Quality indicators, tracked monthly:

• Referral acceptance rate. Share of packets accepted by the MFCU or CMS without a request for additional evidence ^[8]. Direction: up.
• Overturn rate on human review. How often reviewers reverse a high score. If reviewers are reversing most high scores, your thresholds are miscalibrated. Direction: toward a stable band, not zero.
• False-positive burden per analyst hour. Cases closed with no finding, divided by analyst hours spent. Direction: down.

Do not optimize for alert volume. Alert counts are trivially inflatable and they reward the wrong behavior. The output that matters is defensible cases: clusters with documented evidence, a human determination, and a referral packet someone else can act on ^[8].

Baseline before you tune. Ring behavior only reads as anomalous against a measured normal, and normal differs by state, by open-enrollment week, and by broker channel mix. Give yourself a couple of weeks of baseline data before anyone argues about thresholds.

FAQ and a Practical Starting Point

Does IAL2 proofing stop synthetic identities? No. It confirms that evidence resolves to a real-world identity ^[4]. A synthetic identity assembled around a legitimately issued number can satisfy that flow, which is why SSN adjudication and document forensics sit downstream of proofing rather than inside it ^[6][7].

Is fraud detection duplicative of eligibility verification? No. Eligibility verification tests an application against program rules ^[5]. Fraud detection tests behavior across applications. Different question, different data shape, different owner.

Who should own enrollment fraud detection? Program integrity should own the pipeline and thresholds. Eligibility operations owns intake quality and the human review checkpoint. The SIU owns referral packaging and containment authority. Assign it explicitly or it will fall between them.

What makes evidence referral-grade? Provenance for every artifact, a reproducible method for each finding, a documented human determination with rationale, and a timeline an outside investigator can follow without access to your systems. MFCUs handle criminal and civil Medicaid cases and need evidence that survives that standard ^[8].

Do we need graph analytics or will rules do? Rules catch the patterns you already know. Graph structure catches the ring that changed one artifact to evade your rule. Start with rules on shared artifacts, add graph when your clusters stop being obvious.

Start with a small sample

Pull a recent sample of approved applications. Count how many share a phone number, bank account, or mailing address with another approved application, using the SQL above or the equivalent in your reporting tool. That count tells you whether the cluster pattern in the opening scenario is hypothetical at your exchange or already sitting in your data.

The metric to start this week

Applications per unique agent NPN, plotted weekly, with an automatic flag on the top decile. In the opening scenario, that ratio plus the shared-artifact count is what surfaces a broker-driven cluster during open enrollment rather than after complaints arrive months later ^[2].

A phased rollout

Begin by baselining the shared-artifact and agent-activity ratios. Next, run the control-coverage matrix and name an owner for every empty cell. Pilot a single signal end to end, such as document forensics or SSN adjudication, and review how often analysts overturn it ^[7]. Then add the review workflow and build referral packet templates with your MFCU liaison before the first real case reaches that stage ^[8].

References

[1] U.S. Government Accountability Office, "Improper Payments," 2025. https://www.gao.gov/improper-payments

[2] Centers for Medicare & Medicaid Services, "CMS Newsroom: Marketplace program integrity actions," 2025. https://www.cms.gov/newsroom

[3] CrowdStrike, "2025 Global Threat Report," 2025. https://www.crowdstrike.com/en-us/global-threat-report/

[4] National Institute of Standards and Technology, "Digital Identity Guidelines," 2025. https://pages.nist.gov/800-63-4/

[5] Centers for Medicare & Medicaid Services, "Health Insurance Marketplace resources and standards," 2025. https://www.cms.gov/marketplace

[6] Federal Reserve Payments Improvement, "Synthetic Identity Fraud resources," 2025. https://fedpaymentsimprovement.org/

[7] Social Security Administration, "Social Security Number Randomization," 2025. https://www.ssa.gov/employer/randomization.html

[8] U.S. Department of Health and Human Services, Office of Inspector General, "Medicaid Fraud Control Units," 2025. https://oig.hhs.gov/fraud/medicaid-fraud-control-units-mfcu/

[9] KFF, "Explaining Health Care Reform: Questions About Health Insurance Subsidies," 2025. https://www.kff.org/affordable-care-act/issue-brief/explaining-health-care-reform-questions-about-health-insurance-subsidies/