A funeral insurance claim rejected
for missing documents is a process problem.
The Funeral Claims Platform assembles, fraud-screens, and submits funeral insurance claims for any South African policyholder — regardless of which insurer they are with or how they took out the policy. Not by automating the decision. By getting the dossier right before it reaches the insurer. That is why the first-time approval rate is 94%.
94%
First-time approval rate
1–2 hrs
Document upload to submission
100%
Claims human-reviewed
5
Insurers supported now
Available to any South African funeral insurance policyholder — not only INSURELOANSA clients. Web and WhatsApp. Free to access.
The claims journey — plain language
Six steps. One outcome. Your claim reaches the insurer correctly.
The 94% first-time approval rate is a consequence of what happens in these six steps — not a marketing claim attached to a generic process. Every step exists because a specific failure mode in the direct-submission process has a specific, solvable cause.
Start your claim
Your claim number is generated immediately. A personalised document checklist is created on the spot — specific to your insurer and your claim type. Not a generic list of documents. The exact documents your specific insurer requires for this specific type of funeral claim.
Know exactly what to submit — before you upload anything
Assupol requires a certified copy of the death certificate. Hollard accepts a funeral parlour certificate. Sanlam's requirements differ again. The platform knows the difference and tells you before you upload a single document. SAM explains what each document is and why your specific insurer requires it. No guessing. No wrong documents. No rejected submissions for missing items you were never told about.
Submit via web or WhatsApp — a scanner is not required
Upload via the web portal or photograph documents with your phone and send via WhatsApp. Every document is processed immediately: orientation corrected, blur checked, cropped and deskewed, normalised to PDF, OCR fields extracted, classified by document type, matched against your insurer's checklist. If a document is unreadable you are told immediately — with specific instructions on what to fix, not a generic error message.
Processing — seven parallel checks in 1–2 hours
Once all required documents are received, seven processes run in parallel: document validation, identity verification (SA ID Luhn algorithm + format rules), policy verification, beneficiary confirmation, cause-of-death classification, fraud screening (deterministic engine — never auto-decline), and insurer submission preparation. Each produces a structured, auditable result with documented reason codes. The fraud engine cannot automatically decline a claim. Every flag goes to human review.
Human advisor review — no claim bypasses this gate
Before the claim reaches the insurer, a qualified human advisor reviews the complete assembled dossier. The advisor sees: the full claim record, the document checklist status, the fraud score and every signal that produced it, the compliance check results, and an LLM-generated triage summary in plain language. The advisor approves or escalates. The submission gate checks for advisor_approved before the InsurerRouter proceeds. No exception. No bypass.
Submission and proactive tracking
The claim is submitted to the insurer via the correct channel for that insurer — API, secure email, portal, or managed queue. The consumer receives confirmation with the insurer reference number and expected processing timeline. The NurtureOrchestrator sends proactive status updates via the consumer's preferred channel throughout. You are never left waiting without information.
The deterministic-first pivot
We built it with LLMs at the centre of key decisions. Then we changed it.
The Funeral Claims Platform was originally designed with LLM agents driving fraud scoring, compliance checking, document classification, and submission gating. In development, the outputs were useful. In production, the architecture was wrong — and the reasons why are worth understanding, because they define what the platform is now.
Requirement — Regulatory Auditability
The LLM-first failure
"The language model assessed the fraud risk as elevated" is not an auditable reason code under FICA.
The deterministic solution
"signal: bank_account_reused_across_3_claims_within_14_days, score: 72, confidence: 0.89, decision: escalate_to_human_review" is. Deterministic engines produce reason codes. LLMs produce explanations. The pipeline needs both — and the reason codes must come from the deterministic engine, not the LLM.
Requirement — Insurer-Grade Reliability
The LLM-first failure
A fraud score must be the same for the same inputs every time. A compliance check must pass or fail for documented reasons that can be reproduced.
The deterministic solution
LLMs are probabilistic. The same document, analysed twice on the same day with the same model, can produce different outputs. In an insurer-facing submission pipeline, this is not an acceptable risk. Deterministic engines are arithmetic — the same inputs produce the same outputs, every time.
Requirement — Zero Tolerance for Consequential Hallucination
The LLM-first failure
In a claims pipeline, a hallucinated fraud signal means a legitimate claim from a bereaved family is delayed or escalated unnecessarily. A hallucinated compliance pass means a non-compliant claim reaches an insurer and is rejected.
The deterministic solution
These are not user-experience failures. They are harmful outcomes for real people in real distress. The architecture was changed to ensure that the decisions that matter most are always made by deterministic rules with documented, reproducible, inspectable outputs.
Requirement — Human Oversight is the Commitment
The LLM-first failure
The platform's founding commitment is that a human advisor reviews every claim before submission. An architecture where LLM agents make autonomous decisions at multiple points in the pipeline is architecturally inconsistent with that commitment — even if a human also reviews at the end.
The deterministic solution
Deterministic engines produce structured, inspectable outputs that a human advisor can meaningfully review in minutes. An LLM's reasoning process is not inspectable in the same way. The human review gate is meaningful only if what the advisor is reviewing is structured, not opaque.
What LLMs do now — additive specialists, not decision makers
LLMs were not removed from the platform. They were repositioned to the role they are genuinely good at: explanation, summarisation, and drafting. Four bounded LLM specialists assist at specific points in the pipeline. None of them decide. None of them can overwrite a deterministic score.
| Specialist | When called | What it produces | Does it decide? |
|---|---|---|---|
| Triage Summariser | After initial intake and first documents received | Plain-language internal summary of the claim for staff — not the consumer | Never |
| Document Explainer | When documents are missing, unreadable, or incorrectly classified | Consumer-facing WhatsApp/SMS/email guidance explaining what to re-upload and how | Never |
| Fraud Analyst | When the deterministic fraud engine score exceeds the review threshold | Narrative explanation of the fraud signals in plain language for the human reviewer | Never |
| Comms Drafter | Before sensitive communications are dispatched to the consumer | Draft message variants for WhatsApp, SMS, and email — the deterministic engine selects the final template | Never |
Every LLM call is logged, audited, and bounded by governance controls — model allowlist, token caps, timeouts, safe fallback. LLM output is stored in ctx.llm_notes — a separate field that cannot overwrite deterministic fraud scores, compliance decisions, or validation results. The 94% first-time approval rate is a consequence of this architecture.
Security — addressed first, not last
Death certificates. Identity documents. Bank accounts. Policy schedules.
These are the most sensitive documents in a person's life — and they arrive during one of the most distressing moments a family faces. The platform was designed from the first line of code on the assumption that this data must be protected at every layer. Not retrofitted with security after the fact.
POPIA consent gate — technically enforced
popia_accepted: true is an API contract requirement. The API returns an error if consent has not been given. No personal data collection pathway exists before this gate. Not a UI checkbox.
South African data residency
All claim data and documents stored in South Africa via Supabase. No processing on servers outside South Africa. No cross-border data transfer.
Sensitive data never echoed in communications
No WhatsApp, SMS, or email contains SA ID numbers, bank account numbers, or policy numbers. Claims are referenced by claim number only in all external communications.
Secure upload tokens — per claim, per session
Each document upload session uses a claim-specific secure token. Documents cannot be uploaded to the wrong claim. Tokens expire after use.
Immutable audit log
claim_events table: INSERT ONLY. No UPDATE or DELETE granted to any role. Every decision, state transition, fraud signal, and actor logged with correlation ID, request ID, and timestamp.
Never auto-decline — FICA requirement and founding principle
The fraud engine produces a score, a decision, and documented signals. Flagged claims go to the human review queue. The platform cannot automatically decline a claim. FICA requires due process on every fraud flag.
FICA compliance — built into the pipeline
- SA ID number validated using Luhn algorithm and format rules (13 digits, valid DOB encoded, correct checksum)
- PEP screening: claimants and beneficiaries screened against Politically Exposed Person indicators
- KYC document checklist enforced per insurer, per claim type — missing items caught before submission
- Sanctions screening against applicable South African and international lists
- Suspicious transaction reporting hooks built into the verification stage
- Every FICA decision logged with documented reason codes in the immutable audit log
POPIA compliance — technically enforced
- Explicit consent captured before any claim is created — API contract enforced
- Consumer data used only for the purpose of processing and submitting the claim to the identified insurer
- Data minimisation: only fields necessary for the claim are collected
- Retention tags applied to all records — enabling scheduled deletion per retention policy
- Sensitive fields redacted in all audit logs and external communications
- All data stored in South Africa — Supabase South Africa region
- Channel consent gates: WhatsApp, SMS, and email require active opt-in before use
Insurer coverage
Five insurers now. A sixth in preparation.
Sanlam
SDM and related funeral products
Hollard
Hollard Funeral
Assupol
Excellence, 4Life, 4Sure
AVBOB
AVBOB Funeral Cover
Doves
Doves Funeral Products
African Unity Life
Funeral products
The platform is open to any South African funeral insurance policyholder — regardless of insurer. If the consumer's insurer is not on the current supported list, their claim enters a manual verification and submission queue. The claim does not die. It queues for resolution.
Three policy verification models
Model 1 — Proof of Policy
Consumer provides their policy schedule or certificate, policy number, and SA ID number. The platform validates via document authenticity checks, OCR field extraction, and human-assisted review where verification is uncertain. Works for any insurer, any policy.
Model 2 — Portfolio File / Periodic Data Feed
Where an insurer relationship provides periodic policyholder data extracts (a broker book or portfolio file), this becomes an instant Policy Reference Store for validation. Automated matching. Faster verification.
Model 3 — Manual Verification Queue
If no policy record can be confirmed via Models 1 or 2, a verification case is created, additional proof is requested, and the internal team confirms with the insurer via broker channels. The claim does not die — it queues for resolution.
vs. the alternatives
Claiming directly with the insurer
Consumer navigates a complex process alone, without knowing the specific document requirements for their insurer. Rejection for missing items is common. No feedback on what was wrong.
Using an attorney
Expensive. Slow. Typically engaged only for disputed claims — not for initial submission. The platform processes clean claims before they become disputes.
Broker-assisted claims
The broker has relationships only with specific insurers. The consumer may not be with those insurers. The platform is open to any policyholder regardless of insurer or channel.
Funeral parlour assistance
Informal. No claims processing infrastructure. No fraud screening. No FICA compliance framework. No structured audit trail.
Technical architecture
What runs under the claims pipeline.
A deterministic pipeline that processes claims through seven sequential stages, each wrapped in try/except to ensure a single failing component cannot crash the worker or leave a claim in an unknown state. Every state transition is logged before it occurs. If a stage fails, the claim returns to its last confirmed state.
Web — insureloansa.co.za/claims/start
WhatsApp — +27 60 014 5992 (SAM)
Document Processor
Seven Parallel Verification Stages — Deterministic
LLM Specialists — Additive Only · Cannot Overwrite Deterministic Results
Human Advisor Review Gate
advisor_approved required · run_submission checks this before InsurerRouter proceeds
No exception. No bypass. No claim reaches an insurer without this sign-off.
InsurerRouter
Per-insurer adapters
API · Secure email · Portal · Managed queue
NurtureOrchestrator
Proactive tracking
WhatsApp · SMS · Email · In-app — per consent
Runtime
Python 3.11+ — document processing ecosystem: Pillow, pdf libraries, pytesseract, OpenCV
API
FastAPI — async-native · Pydantic models · automatic OpenAPI spec · independent from marketplace
Task Queue
Celery — separate queues per pipeline stage · retry policies per queue · horizontal scaling
Database
Supabase PostgreSQL · Row-Level Security · immutable audit log (INSERT ONLY on claim_events)
Storage
Supabase Storage — private bucket · signed URLs with expiry · per-claim access control
Twilio WhatsApp Business API · document receipt via photo · SAM guidance per document
AI — Specialists
Anthropic Claude — 4 bounded LLM specialists · model allowlist · token caps · safe fallback
Fraud Engine
Deterministic — rule-based scoring · documented reason codes · never auto-decline · human review gate
Deployment
Railway — independent deployment from marketplace · auto-deploy from main branch
Insurer routing
InsurerRouter — per-insurer adapters · API / secure email / portal / managed queue
Any South African funeral policyholder
Any funeral insurance policy.
Any South African insurer. Free.
You do not need to have taken out your policy through INSURELOANSA. Any South African with a funeral insurance policy can submit their claim through this platform. Start online or via WhatsApp — a smartphone with a camera is sufficient.