Retroactive Settlement Verification

What this pillar does for you.

Retroactive Verification is the cleanest description of what JIL does for historical payments: you give us your past payment history, we run 175 checks across free public data + your records, and we tell you which payments were improper, fraudulent, or recoverable - with sealed evidence per finding. For an MCO, that's hitting the CMS 60-Day Rule with documented detection. For a state Medicaid program, it's identifying recovery candidates without contingency-fee exposure. For a federal agency, it's the audit trail that survives an OIG referral.

What you get back: a structured findings package with severity bands, sealed evidence per finding (CREB™ - Court-Ready Evidence Bundle), source provenance for every flag, and a recovery-priority list. Findings deliver in days, not months. See the Tier flow visual for how Retroactive runs through Tier 1 → Ava → Tier 2 → Ava Pro → Tier 3 → Ava Pro+.

One corpus in. A ranked, sealed findings ledger out.

Customer ships a 4-year payment corpus. JIL re-verifies every record against the vendor's Tier 1 profile, Ava surfaces Tier 2 fraud-detected settlements, the customer approves or ignores, and CREB™ ships only on the approved findings. Funds already moved - JIL re-verifies the record, not the rail.

Full workflow document →

Control plane and data plane are strictly separated.

JIL operates the retroactive attestation engine. The customer keeps custody of the historical payment corpus. The corpus arrives as metadata only - no PHI, no PII bulk, only the surface needed to verify each record. JIL re-verifies and produces sealed findings; recovery (clawback, referral) is the customer's downstream action.

Six stages from corpus to sealed findings ledger.

Stages 02 and 03 run in massively-parallel sharded execution against the corpus. Stage 04 (Ava) is agentic - it reasons over Tier 1 output to identify which fraud-detected settlements warrant escalation. Stage 05 is the customer's approval gate. Stage 06 only runs on approved findings.

Your LOB. Your tier. Your checks. Ava data-mines only what you approved.

175 production checks live today (and growing). JIL ships a default profile per Line of Business at each tier (1, 2, 3); customers customize from there. Ava's retroactive sweeps run only over the checks you have enabled, and the reproducibility manifest in every CREB™ carries your profile_id + check-set hash so a third party replaying the analysis gets bit-identical results.

The 175 check catalog is the universe; LOB-default Tier 1 picks the public-data baseline subset (included in your engagement), Tier 2 layers in commercial enrichment (scoped per case), Tier 3 adds the bank graph + investigator review + court-order-gated sources.

Customer customization (opt-out of specific checks within the tier) is audit-logged. The customer's profile_id is embedded in every CREB™'s reproducibility manifest, so the same corpus + the same profile produces the same findings ledger, every replay.

No external LLM. No data exfiltration. Findings you can defend in a hearing.

Ava is JIL's in-house Agentic AI + Data Mining engine. No OpenAI API. No Anthropic API. No Google Vertex. The model, the orchestration, and the data-mining queries all run on-premise inside JIL's perimeter (or, on customer engagement, inside the customer's tenant). Customer data never leaves the customer's perimeter. The Tier 1 verdict path is deterministic rules + statistics, not stochastic LLM inference; Ava's agentic layer rides on top to group, narrate, and route findings but never produces the underlying flag.

CREB™ - Court-Ready Evidence Bundle.

Sealed only on approved findings. Per-claim, per-payer, per-payee, with the full check rendition + Ava's escalation rationale + the customer's approval signature. The corpus-level Merkle root anchors all per-record verdicts in a single L1 transaction (inherited-quorum, patent claim 51). Civil-admissible per FRE 902(14) and patent claim 53.

Who runs this pillar, and against what corpus.

Retroactive Settlement Verification is a single pipeline; the vendor profile loaded at Stage 03 specializes the verdict to the customer's recovery context. Federal/state enforcement agencies, MCO payment-integrity teams, qui tam relator counsel, court receivers, and internal audit all use the same engine - different profiles, different recovery downstream actions.

100M records in 10 to 20 minutes.

The retroactive engine is throughput-bound, not latency-bound. The pipeline is shardable across the 20-validator pool; per-record signatures aggregate via inherited-quorum (patent claim 51) into a single corpus Merkle anchor.

Ship the corpus. Approve the findings. Recover.

Two endpoints: POST /v1/retroactive/corpus to ingest (batch or streaming) and POST /v1/retroactive/findings/:id/decision to approve or ignore Ava-surfaced settlements. Same dual-path auth as the rest of the JIL stack: HMAC-signed primary, mTLS at the edge for institutional, Bearer for admin / cron.

POST /v1/retroactive/corpus
X-JIL-Access-Key-Id: rsv_a3f9b7c2
X-JIL-Timestamp:     2026-04-29T17:32:08Z
X-JIL-Nonce:         <16+ bytes opaque>
X-JIL-Signature:     base64( HMAC-SHA256(secret, canonical) )
Content-Type:        application/x-ndjson

{ "record_id": "clm_2022-1Q-0001-0F", "payer": "MCO-HM-44", "payee_npi": "1487...215",
  "amount": "612.50", "rail": "ACH", "date_of_service": "2022-01-04",
  "issued_at": "2022-01-08T09:14:22Z" }
{ "record_id": "clm_2022-1Q-0001-10", ... }
... 38,200,000 more records ...

{
  "rsv_id":            "rsv_01J9G...B71A",
  "corpus_window":     { "from": "2022-01-01", "to": "2026-04-28" },
  "estimated_records": 38200000,
  "tier_1_profile":    "mco-payment-integrity-v3",
  "status":            "running",
  "progress_url":      "/v1/retroactive/rsv_01J9G...B71A/progress",
  "ava_settlements_url": "/v1/retroactive/rsv_01J9G...B71A/findings"
}

POST /v1/retroactive/findings/find_01J9G_4F2A1/decision
{ "decision": "approve", "downstream_action": "clawback", "notes": "..." }

200 OK
{ "creb_id": "creb_01J9G...B71A_4F2A1",
  "creb_url": "sdv://customer-44/creb/creb_01J9G...B71A_4F2A1.pdf",
  "anchor":   { "chain": "jil-l1", "block": 18902441, "merkle_path": "..." } }

Questions answered by the retroactive engine.

• Was the payee dead on the date of service? SSA DMF + state vitals death verification, evaluated at the payment date.
• Was the payee excluded? OIG-LEIE, SAM, state Medicaid exclusion, corporate-integrity-agreement status, debarred contractor lists - evaluated as of the historical date.
• Was the license valid on the date of service? NPPES + state licensing + DEA registration + facility certification, against the relevant historical date - not today.
• Was the entity dissolved? SOS dissolution records, registry status, name-change pivot detection, shell-entity flags.
• Is the payee a duplicate enrollment? Cross-program / cross-jurisdiction duplicate detection (state Medicaid, Medicare, Tricare, VA).
• Are the corridor / typology / velocity patterns anomalous? Tier 1 thresholds applied per-record; Ava clusters anomalies into actionable settlements.
• Should this finding be approved for recovery? Ava recommends, the customer approves; CREB™ ships only on approved.

Detailed documentation.

One pipeline. Six delivery surfaces.

Ready to replay your 4-year corpus and recover what slipped through?

Engagement framework, vendor-profile design, and integration runbook are available under NDA. Initial briefings are 60 minutes for federal / state enforcement, payer SIU, qui tam relator counsel, court receivers, and internal audit.