Why 23 of 24 Fake Applications Were Approved and How to Close the Front Door

In December 2025, the Government Accountability Office (GAO) testified on preliminary results of covert testing of the federal Marketplace ^[1]. GAO created fictitious applicants who stated incomes that qualified for the advance premium tax credit (APTC); for plan year 2024 they included applicants who gave invalid, never-issued Social Security numbers ^[1]. For plan year 2024, the Marketplace approved fully subsidized coverage for all four fictitious applicants, even though GAO either was not asked for documentation or generally did not provide what was requested ^[1]. For plan year 2025, it initially approved coverage for 19 of 20 fictitious applicants, and coverage for 18 was still active in September 2025 ^[1]. Across the two plan years, 23 of GAO's 24 applications were approved ^[1].

GAO also found that the Marketplace did not always generate data matching inconsistencies for its plan year 2024 fictitious applicants ^[1]. The results are preliminary, and GAO's plan year 2025 testing was still under way when it testified ^[1]. They already show where the front door is weakest: identity and income claims that should prompt verification did not stop subsidized coverage from starting.

This article breaks down the fraud vectors behind those approvals, maps the front-door detection architecture that stops them, and explains how to implement forensic, synthetic-identity, and behavioral controls at enrollment scale without creating eligibility barriers for legitimate applicants.

The GAO Test That Exposed the Front Door

GAO's testimony describes two rounds of covert testing ^[1]:

• Plan year 2024. GAO submitted applications for four fictitious identities in October 2024, some independently through HealthCare.gov and some with help from an insurance agent or broker. All four received subsidized coverage for November through December 2024, and the combined APTC paid to insurers for them was about $2,350 per month ^[1].
• Plan year 2025. GAO developed 20 fictitious applications. The Marketplace initially approved coverage for 19. It later cancelled coverage for one enrollee for whom GAO did not provide the requested documentation of citizenship status. As of September 2025, coverage for 18 remained active, with combined APTC of over $10,000 per month ^[1].

GAO says it used publicly available hardware, software, and materials to produce counterfeit documents and submitted them where appropriate for its testing ^[1]. Sophisticated forgery was not what got the 2024 applicants through, though: GAO either was not asked for documentation or generally did not provide what was requested, and coverage started anyway ^[1].

The testing points to two structural failures. First, the plan year 2024 applicants who used never-issued Social Security numbers were among those approved, so identity checks did not stop them. Second, missing documentation did not stop subsidized coverage from starting: any follow-up came after enrollment, as with the plan year 2025 enrollee whose coverage was cancelled later ^[1].

Controls that act before coverage starts are the scalable answer. Review that begins after approval begins after subsidies are already being paid, and the totals are large: federal agencies reported an estimated $186 billion in improper payments across 64 programs in FY2025 ^[3].

Fraud Vector 1: Fabricated and Stolen SSNs

GAO's plan year 2024 fictitious applicants included people who gave invalid Social Security numbers that had never been issued ^[1]. A format check that confirms an SSN has nine digits cannot tell whether the number was ever issued or whether it belongs to the applicant. Front-door controls need more than format validation: issuance and death-file checks, duplicate-use detection, and plausibility checks between the applicant's stated age and the SSN issue date.

A deceased individual's SSN can pass a format check until someone compares it with death records such as the Social Security Administration's Death Master File (DMF). Whether a marketplace runs that comparison at intake depends on its data-access agreements and on whether its eligibility system was built for cross-file checks, so confirm what your own workflow does rather than assuming it.

Synthetic-identity fraud is harder to detect because the SSN is real and not flagged as deceased. The fraud is in the mismatch between the SSN and the claimed identity. Issuance timing can help, with care. SSA began assigning SSNs randomly on June 25, 2011, and the High Group List frozen at that point can still be used to validate numbers issued before that date ^[2]. A number that could only have been issued after 2011, attached to a 45-year-old applicant, is worth a closer look when other signals point the same way. It is not proof on its own: people who immigrate or first need an SSN as adults legitimately receive numbers later in life. A front-door control should queue that combination for human review, never deny on it.

Duplicate SSN use is a behavioral red flag. If the same SSN appears on three applications filed in different states with different names, at most one can belong to the number's real owner, and the cluster needs review. Graph-based identity resolution detects these patterns by clustering applications around shared attributes like SSNs, addresses, bank accounts, and phone numbers. A single SSN reused across five unrelated applications looks more like a coordinated pattern than an isolated error.

The detection architecture for synthetic-identity fraud requires three layers. First, real-time DMF cross-checks flag deceased SSNs before application approval. Second, SSN plausibility scoring flags mismatches between stated demographics and SSN issue patterns. Third, duplicate-use detection clusters applications around shared SSNs and surfaces networks of related submissions. Human investigators review the clusters, not random samples of individual applications.

Fraud Vector 2: Altered Income Documents and Fabricated Paystubs

GAO says it produced counterfeit documents with publicly available hardware, software, and materials and submitted them where appropriate for its testing ^[1]. Marketplaces receive altered paystubs and income letters outside of any test too, and during open enrollment human reviewers cannot inspect every upload closely.

Document forensics analyze indicators invisible to human reviewers. Metadata extraction checks when a file was created, what software generated it, and whether it has been modified since creation. A paystub labeled "January 2025" that was created in Microsoft Word on March 15, 2025, is suspicious. A PDF with visible copy-paste artifacts where income figures were overlaid on a template is fraudulent.

Font analysis detects when different parts of a document use inconsistent typefaces or point sizes. Legitimate paystubs generated by payroll software use consistent formatting. Fabricated paystubs created by copying a template and manually editing fields show font mismatches, alignment errors, and pixel-level artifacts where text was inserted over existing content.

Template-signature libraries catalog known-good document structures from legitimate employers and payroll providers. When an application includes a paystub, the system compares it against the library. Matches to known templates increase confidence. Deviations trigger closer inspection. Entirely novel templates from unknown employers are flagged for validation.

The detection pipeline has to keep up with open-enrollment peaks, whatever your exchange's daily upload volume is, without introducing delays that frustrate legitimate applicants. That means forensic checks run asynchronously. Applications are accepted, forensics run in parallel, and only applications with specific anomalies are held for review. Clean documents auto-approve. Suspicious documents queue for investigator review with forensic findings highlighted.

False-positive tuning is critical. Legitimate enrollees sometimes submit unusual but valid documents: handwritten paystubs from small employers, screenshots of online pay portals, or informal income letters. The system must distinguish between "unusual but plausible" and "structurally fraudulent." This requires iterative tuning where investigators provide feedback on flagged cases and the system adjusts scoring thresholds.

The trigger values in the table below are illustrative starting points, not benchmarks. Set your own from cases your reviewers have resolved.

Fraud Vector 3: Forged Special-Enrollment Qualifying Letters

Special-enrollment periods (SEPs) allow eligible individuals to enroll outside the standard open-enrollment window after qualifying life events like losing employer coverage, moving to a new state, or gaining citizenship. SEP eligibility requires documentation: a termination letter from a previous insurer, proof of residence change, or an employer letter confirming coverage loss.

SEPs are high-value targets for fraud rings because they bypass enrollment windows that limit application volume. An operator can spread SEP applications across the whole year instead of concentrating them in the open-enrollment window. Lower submission rates reduce the likelihood of behavioral clustering detection, making SEP fraud harder to spot without document forensics.

Automated SEP controls should validate sender authenticity before accepting the document. Employer letters should include verifiable employer identification numbers (EINs). Insurer letters should come from registered health plans. Letters from unknown or suspicious originators are flagged immediately. This requires maintaining a reference database of legitimate employers, insurers, and their document templates.

Template-matching algorithms detect when the same forged letter is reused across multiple applications. Fraud rings often create a single template and personalize it with applicant-specific details. The structural signature (font, layout, wording) remains identical. Document clustering surfaces these patterns even when the forged letters are submitted weeks apart.

Human reviewers should only see SEP applications where automated checks surface specific anomalies: unknown sender, template mismatch, metadata inconsistencies, or duplicate use across multiple applications. Random sampling of SEP applications is ineffective because random samples rarely land on the applications that belong to an organized pattern.

The Front-Door Detection Architecture That Stops These Attacks

The front-door detection architecture is a four-layer stack: document forensics, synthetic-identity intelligence, broker-ring behavioral analytics, and human-in-the-loop referral queues. Each fraud vector maps to a specific automated control that runs before application approval. Detection produces referral-grade evidence packets with highlighted anomalies, not just binary pass/fail flags.

The first layer is document forensics. Every uploaded document passes through metadata extraction, font analysis, template matching, and pixel-level tampering detection. Clean documents auto-approve. Suspicious documents are flagged with specific forensic findings and queued for investigator review. The investigator sees the original document side-by-side with forensic annotations highlighting the anomalies: mismatched fonts, metadata inconsistencies, copy-paste artifacts.

The second layer is synthetic-identity intelligence. Every SSN is cross-referenced against the Social Security Administration's Death Master File. Duplicate SSN use across multiple applications is flagged. SSN plausibility scores check whether the issue date aligns with the applicant's stated age. Mismatches trigger identity-validation workflows where additional documentation is requested before approval.

The third layer is broker-ring behavioral analytics. Applications are clustered by shared attributes: IP addresses, browser fingerprints, broker codes, submission timestamps, document templates. When an unusually large group of applications shares similar patterns, the cluster is flagged as a potential organized ring. Human investigators review the cluster, validate that it's genuinely suspicious, and refer to Medicaid Fraud Control Units (MFCUs) or CMS if fraud is confirmed.

The fourth layer is the human-in-the-loop referral queue. Automated detection feeds a case queue where investigators review evidence packets with highlighted anomalies. Referral packets include the original application, flagged documents with forensic annotations, SSN intelligence findings, and related-application clusters. Investigators make final determinations and generate defensible referrals to enforcement agencies. Feedback loops tune detection rules: when investigators mark a case as legitimate, the system learns and adjusts scoring thresholds to reduce future false positives.

This architecture closes the front door without creating eligibility barriers for legitimate enrollees. Automated controls handle routine applications without human intervention. Only applications with specific, actionable anomalies are held for review. Legitimate enrollees with unusual but valid documents are less likely to be wrongly held, because the system distinguishes between "unusual" and "structurally fraudulent."

Implementing Document Forensics at Enrollment Scale

Document forensics has to absorb open-enrollment peaks without introducing application delays. This requires parallel processing pipelines where forensic checks run asynchronously after application submission. Applicants receive immediate confirmation that their application is received. Forensics run in the background. Clean documents auto-approve. Suspicious documents queue for review.

Metadata analysis is the first forensic check. Every document has embedded metadata: creation timestamp, authoring software, modification history. A PDF paystub labeled "December 2025" that was created in Adobe Acrobat on January 20, 2026, is plausible. The same paystub created on March 15, 2026, after the application was submitted, is suspicious. Metadata extraction flags these inconsistencies automatically.

Visual forensics detect font inconsistencies, alignment errors, and pixel-level tampering artifacts. Legitimate paystubs generated by payroll software have consistent formatting: uniform typeface, aligned columns, predictable layout. Fabricated paystubs show irregularities: multiple fonts in the same section, misaligned text boxes, overlaid text where income figures were manually edited. Computer-vision checks apply these tests the same way to every document, which reviewers working through a long queue cannot do.

Template libraries catalog known-good document structures from legitimate employers and insurers. When an application includes a paystub from "Acme Corp," the system retrieves Acme Corp's known payroll template and compares the submitted document against it. Structural matches increase confidence. Deviations trigger manual review. Entirely novel templates from unknown employers are flagged for validation before approval.

False-positive tuning is the hardest part of forensic implementation. Legitimate enrollees submit unusual but valid documents: handwritten paystubs from small employers, screenshots of online pay portals, informal income letters from freelance clients. The system must distinguish between "structurally unusual" and "fraudulent." This requires iterative tuning where investigators provide feedback on flagged cases. When an investigator marks a handwritten paystub as legitimate, the system adjusts its scoring model to reduce future flags for similar documents.

Durations and targets depend on your data, vendors, and staffing, so the plan below lists phases and what to measure rather than generic timelines or benchmarks.

Building the Broker-Ring Behavioral Analytics Layer

Enrollment fraud often runs through agents and brokers. From June through October 2024, CMS suspended the Marketplace agreements of 850 agents and brokers for reasonable suspicion of fraudulent or abusive conduct related to unauthorized enrollments or plan switches ^[4]. In July 2024, citing increases in unauthorized changes to consumers' enrollments by agents and brokers, CMS began blocking an agent or broker from changing a consumer's federal Marketplace enrollment unless that agent was already associated with it ^[5]. Organized fraud rings file many applications from the same IP blocks, browser fingerprints, and broker codes. Behavioral clustering detects these patterns by analyzing application metadata that individual manual reviewers never see: submission timestamps, device fingerprints, geographic origin, document-upload patterns.

As an illustration, picture a ring filing 40 applications over six weeks. It creates a detectable behavioral signature. Applications cluster around shared attributes: same broker code, sequential submission times (every Monday at 10am), similar document-naming conventions ("paystub_jan.pdf", "paystub_feb.pdf"), identical browser user-agent strings. No single application looks obviously fraudulent. The pattern becomes visible only when you analyze many applications together.

Broker analytics track application volume, approval rates, and document-quality scores per agent. Normal broker volume and approval patterns vary by market, so set each agent's baseline from your own enrollment data. Brokers whose volume, approval patterns, or fraud-flag rates diverge sharply from their peers warrant investigation. This doesn't prove fraud, but it surfaces suspicious patterns that human investigators should review.

Graph analysis maps relationships between seemingly unrelated applications through shared contact information, addresses, bank accounts, and phone numbers. For example, five applications filed by different brokers with different applicant names but the same bank account are linked. Ten applications from different states with sequential SSNs are linked. Graph clustering reveals these connections even when the applications were submitted weeks apart.

Human-in-the-loop review validates behavioral clusters before referring to enforcement agencies. Not every cluster is fraud. A legitimate employer-sponsored enrollment event might generate 30 applications from the same broker on the same day with similar document structures because the employer provided a template. Investigators review the cluster, contact the broker if needed, and confirm whether it's organized fraud or a legitimate batch enrollment.

The feedback loop is critical. When investigators confirm that a cluster is fraudulent, the system learns and updates its clustering algorithms to detect similar patterns faster. When investigators mark a cluster as legitimate, the system adjusts to reduce future false positives. Over time, the behavioral analytics layer becomes more precise at distinguishing organized fraud from legitimate batch enrollments.

The Referral Queue and Human-in-the-Loop Controls

Automated detection feeds a case queue where investigators review evidence packets with highlighted anomalies. This is not a random audit where investigators manually re-check a small random sample of applications. It's a targeted review where investigators only see applications that automated systems flagged with specific findings: forensic anomalies in uploaded documents, SSN mismatches, or behavioral cluster matches.

Referral packets include everything an investigator needs to make a determination. The original application with all supporting documents. Forensic annotations highlighting metadata inconsistencies, font mismatches, or tampering artifacts. SSN intelligence findings showing death-file matches, duplicate use, or plausibility mismatches. Related-application clusters showing other submissions from the same operator or broker.

Program-integrity staff review the evidence, make final determinations, and generate defensible referrals to MFCUs, CMS, or state enforcement agencies. Referrals include the original evidence packet plus investigator notes explaining why the application is fraudulent. The receiving agency decides what to investigate or recover; a complete packet lets it start from evidence instead of collecting it again.

Feedback loops tune detection rules based on investigator decisions. When an investigator marks a case as fraudulent, the system logs which detection rules triggered the flag and reinforces those rules. When an investigator marks a case as legitimate despite automated flags, the system adjusts scoring thresholds to reduce similar false positives. Over successive review cycles, this tuning should improve precision and reduce investigator workload; confirm it with your own overturn and confirmed-fraud data.

This architecture closes the front door without overwhelming program-integrity staff with false positives or creating eligibility barriers for legitimate enrollees. Automated controls handle routine applications. Human investigators review only the applications that automated systems flag with specific, actionable anomalies. The aim is that legitimate enrollees are not wrongly denied or delayed: the system holds only applications with concrete findings, not random samples, and a person makes the call.

Common Questions About Front-Door Fraud Detection

How do you prevent false positives from delaying legitimate enrollees? Progressive trust architecture holds only applications with multiple specific anomalies. A single unusual document doesn't stop approval. A deceased SSN plus an altered document plus a behavioral cluster match does. Requiring several independent findings before a hold keeps false positives down, because legitimate applications seldom trigger multiple unrelated red flags at once. Measure your own rate from reviewer decisions.

What happens if a legitimate enrollee submits a handwritten paystub from a small employer? Handwritten documents are flagged as unusual, not fraudulent. The investigator reviews the document, sees that it's structurally plausible (consistent handwriting, reasonable employer details, no obvious fabrication), and approves it. The system logs that decision and adjusts scoring to reduce future flags for similar handwritten documents.

Can fraud rings bypass document forensics by submitting clean documents? Document forensics is one layer. Even if a fraud ring submits forensically clean documents, synthetic-identity controls flag deceased or duplicate SSNs, and behavioral analytics detect submission patterns. Bypassing all four layers (forensics, identity intelligence, behavioral clustering, and human review) is much harder than bypassing one.

How long does it take to implement front-door detection at a state marketplace? It depends on your data access, vendors, and staffing, so set durations from your own procurement and integration constraints rather than a generic estimate. A phased rollout helps: start with SSN cross-checks and behavioral clustering, which reuse data you already hold, and add document forensics in phase two.

What's the ROI of front-door detection compared to post-enrollment audits? Post-enrollment audits try to recover subsidies that have already been paid, which costs investigator time, legal proceedings, and collection effort, and not every dollar comes back. Front-door detection acts before coverage starts, so a fraudulent application it stops never generates a subsidy to recover. The return depends on your fraud volume and staffing, so measure it against your own recovery data rather than a generic multiple.

Next Steps: Closing Your Front Door

Start with an architecture assessment. Map your current enrollment flow and identify where automated controls exist (if any). List the checks you run today, such as SSN format validation and income-threshold checks, and the ones you do not, such as death-file cross-checks, document forensics, or behavioral clustering. Those are the gaps.

Prioritize synthetic-identity controls first. SSN issuance and death-file cross-checks and duplicate-use detection address the identity gap GAO's testing exposed. Partner with a data provider that maintains updated DMF access and build real-time cross-checks into your eligibility-verification workflow.

Add document forensics in phase two. Start with metadata extraction and template matching. These catch the most obvious fabricated documents without requiring pixel-level visual analysis. Expand to font-consistency and tampering detection once your investigator team is trained on forensic evidence review.

Build the behavioral analytics layer last. This requires aggregating application metadata across many submissions and tuning clustering algorithms to distinguish fraud rings from legitimate batch enrollments. Plan time after launch for false-positive tuning based on investigator feedback.

If you're a state marketplace or Medicaid program-integrity lead, reach out to your eligibility-system vendor and ask what fraud-detection capabilities they support natively. Some vendors offer modular add-ons for document forensics and synthetic-identity checks. If your vendor doesn't support these controls, consider a third-party fraud-detection platform that integrates via API with your enrollment system.

GAO's testing showed that the federal Marketplace front door was still open in plan years 2024 and 2025 ^[1]. Closing it takes identity checks, document forensics, and behavioral analytics that run before coverage starts. The question is whether you'll implement them before the next audit reveals that your front door is still unlocked.

References

[1] U.S. Government Accountability Office, "Patient Protection and Affordable Care Act: Preliminary Results of Ongoing Work Suggest Fraud Risks in the Advance Premium Tax Credit Persist," GAO-26-108811, December 10, 2025. https://files.gao.gov/reports/GAO-26-108811/index.html

[2] Littler Mendelson, "Social Security Numbers Now Being Assigned Randomly." https://www.littler.com/news-analysis/asap/social-security-numbers-now-being-assigned-randomly

[3] U.S. Government Accountability Office, "Improper Payments," FY2025 government-wide estimate. https://www.gao.gov/improper-payments

[4] Centers for Medicare & Medicaid Services, "CMS Update on Actions to Prevent Unauthorized Agent and Broker Marketplace Activity," October 17, 2024. https://www.cms.gov/newsroom/press-releases/cms-update-actions-prevent-unauthorized-agent-broker-marketplace-activity

[5] Centers for Medicare & Medicaid Services, "CMS Statement on System Changes to Stop Unauthorized Agent and Broker Marketplace Activity," July 19, 2024. https://www.cms.gov/newsroom/press-releases/cms-statement-system-changes-stop-unauthorized-agent-broker-marketplace-activity