Claims fraud detection,
quote protection & policyholder security
Five claims, five policies, five identities — one device. Keverd sees what the claims system cannot: the hardware behind every submission and every quote request.
Trusted by forward-thinking teams
























Overview
Insurance fraud costs the Kenyan industry billions annually. The IRA estimates 20–30% of claims contain fraud or exaggeration — motor insurance carries the largest share.
As platforms digitize — online purchase, digital FNOL, self-service portals — the fraud surface expands. Fraudsters file from any device, any time, under any identity.
Keverd works below identity verification and above claims adjudication. Beyond claims: competitor scraping of quote engines harvests years of actuarial work — BOT and AUTOMATION flags catch scripts that humans never run.
The problem
What insurance platform fraud looks like
Linked motor claims — one device
Multiple claims across policies, vehicles, and identities — each looks independent in the claims system. The device fingerprint is the same. Keverd connects them at submission, before assessor or payout.
Quote engine scraping
Competitors and brokers harvest premiums at scale to reverse-engineer pricing. BOT and AUTOMATION flags plus request velocity — scripts do not navigate like real users.
Synthetic policyholders
Fabricated identities, minimum premium, claim soon after bind. One device registering multiple policies under different names — flagged before the policy is bound.
Policyholder account takeover
Phished credentials → new device → claim on active policy, bank detail change, or refund redirect. Continuity check before any sensitive action.
Broker and agent misuse
Elevated portal access is legitimate within a book of business. Same device on accounts outside that book — anomaly in the weekly audit trail.
Ring fraud on staged incidents
Related claims from different devices sharing IP range, timezone, and registration timing. True IP and location data connect infrastructure even when devices differ.
How Keverd solves it
Five layers across the insurance journey
Claims, quotes, bind, policyholder portal, and broker access — Keverd captures:
- Device fingerprint on every claims submission
- Prior claims and policies linked to the same device cluster
- Quote engine request volume and BOT / AUTOMATION patterns
- Policy registration history per device — synthetic identity farms
- Policyholder login continuity and new-device alerts
- Broker and agent portal access logged for weekly audit reports
Claims cluster detection
Fingerprint each FNOL submission. Same device across different policies, vehicles, and claimants — surfaced before assessor dispatch or payout.
Quote engine protection
Flag scraping scripts by behaviour and volume. Block, rate-limit, or serve degraded quotes — your call on competitive response.
Policy onboarding
Check device at bind time. Multiple policies or prior fraud flags on one fingerprint → underwriting review before the policy is active.
Policyholder portal
Continuity on login and sensitive actions — claims, bank changes, cancellation, refund requests. New device → verify first.
Broker & agent audit
Device-level access log. Devices touching accounts outside a broker’s registered book surface in weekly compliance reports.
Integration
Five touchpoints — claims first
Digital-first insurtechs can activate all five in one deployment. Traditional insurers typically prioritise claims submission, then quote engine, then portal channels.
Claims submission
- Placement
- Claims submission form
- Trigger
- Claims form submission
- Response
- device_id, prior_claim_count, suspect_score, risk_tier, flags[], action_taken
Highest priority. Assessor sees Keverd data in queue before assessment starts.
Quote engine
- Placement
- Quote request form or API
- Trigger
- Quote submission or API call
- Response
- device_id, request_count_in_window, bot_flag, automation_flag, suspect_score, action_taken
Block, rate-limit, or degraded data — platform configures response; session logged with full device and IP.
Policy registration
- Placement
- Policy purchase / registration form
- Trigger
- Policy application submission
- Response
- device_id, prior_policy_count, prior_claim_flag, suspect_score, risk_tier, action_taken
Surfaced to underwriting before bind when device history is suspicious.
Policyholder portal
- Placement
- Login + sensitive action pages
- Trigger
- Login, claim, bank change, cancellation, refund request
- Response
- device continuity flag, is_new_device, suspect_score, risk_tier, action_taken
New device on high-impact actions requires re-verification.
Broker & agent portal
- Placement
- Broker and agent portal sessions
- Trigger
- Access to policyholder accounts
- Response
- access log: device_id, account, timestamp, action — weekly audit report
For aggregators without direct policy hold, quote engine and referral flow are the primary touchpoints.
Workflow
Motor claims fraud
- 1
Fraudster
Submits multiple motor claims under different policies and identities from one device.
- 2
Keverd
Links submissions to the same fingerprint at FNOL — prior claim count and flags returned.
- 3
Assessor
Sees cluster context in queue — investigates linked claims before payout.
- 4
Investigation
Week-one cluster report shows independent assessments that shared one device.
Quote engine scraping
- 1
Scraper
Automated script fires hundreds of quote requests with varied inputs.
- 2
Keverd
BOT / AUTOMATION and volume thresholds identify non-human patterns.
- 3
Your platform
Block, rate-limit, or return degraded pricing data per your competitive policy.
- 4
Outcome
Actuarial and pricing work protected from systematic harvesting.
Policy onboarding fraud
- 1
Fraudster
Registers several policies from one device with different fabricated identities.
- 2
Keverd
Flags device policy count and prior fraud signals at application.
- 3
Underwriting
Reviews before bind — policy never becomes claimable.
- 4
Claims
First-loss fraud prevented upstream, not at adjudication.
Field guide
Reading Keverd flags in insurance
For claims assessors, underwriters, fraud investigation, and portal administrators.
| Flag | What it means | How to use it |
|---|---|---|
| BOT | Session behaviour matches non-human patterns. | Primary signal on quote engine scraping. Rate-limit or block. |
| AUTOMATION | Form completion and timing consistent with scripting. | Quote requests and bulk portal access — review or restrict. |
| USER_AGENT_SPOOFED | Device misrepresents browser or OS. | Common on scraping stacks. Review on claims and quotes. |
| TIMEZONE_IP_MISMATCH | Timezone does not match IP location. | Often fires on cloud-based scrapers. Context — pair with BOT/AUTOMATION. |
| AD_BLOCKER | Ad blocker detected. | Informational. Low weight in claims fraud scoring. |
First 30 days
What success looks like
- Week 1first linked-claims cluster report for fraud investigation
- 100%of digital claims submissions fingerprinted
- Quotescraping sessions identified — block or degrade per policy
- 90 daysdefault linked-claims window — extend for long-tail products
- Day 30threshold review with claims, underwriting, and compliance teams
The linked-claims cluster report is the strongest deliverable: show investigations that independent assessments shared one device — and the payout value you avoided.
Default configuration
Tuned for insurance platforms
| Claims link window | 90 days — same device, multiple claims | Extend for life and long-tail liability products |
| Quote scraping | BOT/AUTOMATION + request count per device/hour | Block vs. rate-limit vs. degrade — platform choice |
| Policy registration | >2 policies per device → underwriting flag | Tuned to portfolio and channel mix |
| AD_BLOCKER | Ignored in claims score | Low correlation with FNOL fraud |
For insurance teams
Starting the conversation
Different entry points for insurtech, traditional insurers, and comparison aggregators.
The opening question — claims
How many claims did you pay last year where the same device had submitted other claims you never connected? Most platforms do not know — that gap is where Keverd starts.
Quote engine — aggregators
Do you know how many automated quote requests hit your engine last month — and whether any competitor is building a pricing map from your output? Reframes scraping as competitive intelligence.
Retrospective cluster analysis
Run device fingerprints against historical submission sessions from existing logs — often without live integration. Show linked claims that were assessed as independent.
ROI framing
Linked cluster report × value of claims that would have paid out = strongest ROI story in the portfolio. Lead the 30-day review with that number.
Onboarding
5–7 working days — claims live in ~3 for modern stacks
- 01Prioritise touchpoints: claims first, quote engine second, registration third, portal fourth, broker fifth
- 02Share URLs for claims, quote, registration, policyholder portal, and broker portal
- 03Add Keverd snippet to each web touchpoint; configure webhooks on claims and registration
- 04Configure quote scraping response: block, rate-limit, or degraded data
- 05Agree claims flag thresholds with fraud investigation
- 06Agree policy registration thresholds with underwriting
- 07Agree broker audit report format and distribution with compliance
- 08Test run: submit test claims from same device under different policy numbers
- 09Brief assessors, underwriters, and fraud team on field guide and workflows
- 10Go live — first claims cluster report at end of week one
Known limitations
Interpret signals correctly
- Keverd does not analyse claim documents, damage assessments, or incident reports — complements adjudication, does not replace it.
- Claims via agent or broker intermediaries fingerprint the intermediary’s device — useful for agent-volume anomalies, not direct policyholder device in that channel.
- Degraded quote data requires platform configuration of what to return — Keverd flags; you decide the response.
- USSD and voice claims channels are outside session fingerprinting — digital submission channels only.
- Broker audit findings are sensitive — involve compliance when surfacing internal misuse patterns.


