Year 5 Revenue Capacity (per CEO Pg 23)
$500M – $1.5B
$50B / yr volume × 1%–3% fee = $500M–$1.5B
$50B is 1% of US payment volume. Of $4.9T US healthcare spend, $1T is waste, fraud, and abuse — Moonlitic eliminates DELAY & DENY tactics with transparent reconciliation. Sit on the rails, take the toll, return the savings.
🛣
1. Claim Payment Routing
decide payor → provider channel
POST/api/payments/route
Each inbound claim is routed to the right payor channel based on payer registry, prior-auth status, and Part-2 sensitivity. SUD-coded claims (ICD-10 F10–F19, T36/T40) automatically take the SUD-protected channel with extended settlement timeline.
Inputs: claim_id · payor_id · provider_npi · amount_cents · patient_id · ICD-10 codes
Output: routing decision · next action · estimated settlement days · compliance tags
⚠
2. Denial Management
classify · queue · appeal
POST/api/payments/denials
Every X12 835 denial gets parsed, classified by CARC + RARC code, and routed: appeal-worthy denials hit the appeals queue with auto-prefilled letters; non-appealable denials route to the patient-billing flow with transparent explanations.
Categories: authorization-issue · timely-filing-limit · charge-exceeds-fee-schedule · non-covered-charge · service-bundled · wrong-payor · other
Output: classification · appealable bool · next action
📈
3. Reimbursement Optimization
re-bundle · re-bill · maximize
POST/api/payments/reimbursements
A rule engine inspects each claim against payer fee schedules and CMS guidelines, suggesting re-bundling, modifier adjustments, or re-bills that maximize legitimate reimbursement. Every suggestion above $500 routes to provider review before submission.
Output: delta_cents · delta_pct · rationale · requires_review
Compliance: never alters clinical content; only billing-line adjustments within payer policy
🏦
4. Provider Settlement
batch ACH · NACHA · RTP
POST/api/payments/settlements
Daily settlement batches consolidate approved claims into ACH, NACHA, or Real-Time Payments rail. Every batch > $10K total triggers the SoX-1 dual-approval workflow: two distinct approvers from mlt-finance-approver must sign before NACHA file generation.
Rails: ACH · NACHA · RTP
Compliance gate: SOX-1 dual approval > $10K · ledger-anchored audit
📒
5. Payment Audit Trail
ledger-anchored · regulator-readable
GET/api/payments/audit?claim_id=…
Every payment event (route → denial → reimbursement → settlement) writes an HMAC-SHA256-signed entry to Azure Confidential Ledger. An auditor querying by claim_id gets the full chain — verifiable offline against Microsoft's hardware root of trust. SOC 2 + HHS OCR + SoX simultaneously.
Output: chain of ACL entries · timestamps · signing identities · chain_verified bool
Verification: scripts/verify-ledger-chain.ts (offline)
HIPAA · audit logging on every request
HIPAAPHI Every request through hipaa-audit.ts middleware writes a structured audit record. PHI never logged.
42 CFR Part 2 · SUD-protected channel
42-CFR-PART-2 Claims with ICD-10 F10–F19 / T36 / T40 codes auto-route to the SUD channel. No marketplace exposure.
SoX-1 · dual approval > $10K
SOX-FINANCIAL Settlement batches above $10K total require two distinct approvers from mlt-finance-approver. ACL entry records both.
Ledger anchoring · regulator-grade
HMAC-SHA256 Every event chain-signed to Azure Confidential Ledger. Verifiable offline. HHS OCR + SOC 2 + auditor-friendly.
F06 Payouts Built (loose JS)
patient-side · 80/20 NET cascade · Velo ACH
Patient gets paid when their data clears the marketplace. Single recipient (the patient). Velo Payments rail, IAL2-verified payee, 1099-NEC tracking. The "Sarah gets paid" path.
VS
Payments Optimization Skeleton ✱
payer ↔ provider · NACHA / RTP · system-wide
Provider gets paid faster. Payer pays cleaner. Patient gets transparent EOBs. Many recipients, many channels, batch settlement. The "everyone in healthcare gets paid faster, fairer, with audit-grade transparency" path. Eliminates DELAY & DENY tactics.