Automated claims. Missing validation. Paying out fake losses.

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The growth of micro-insurance in Nigeria

Low-cost insurance products are growing across Nigeria. Tech platforms offer bite-sized coverage, charging as low as ₦1,000 to ₦2,000 monthly for outpatient health bills or transit insurance. Because these ticket sizes are small, manual inspection of claims is commercially unviable. A company cannot pay human loss adjusters to check claim details when the premium is low.

To make these micro-insurance policies profitable, platforms must automate their workflows. They integrate payment processors like Paystack and Flutterwave to auto-debit accounts, and they build automated claim processing engines. However, this automation creates direct API security exposures. When speed is favored over server-side verification, attackers exploit the automated disbursement routes to request payouts using fabricated documentation.

Exploit 1: Claim evidence spoofing and missing verification

When users submit claims, the client application typically prompts them to upload a photo of the damaged asset or a copy of the hospital invoice. The frontend uploads the file to a storage bucket and POSTs the reference to the claim API:

{
  "policy_id": "pol_992817",
  "claim_amount": 45000,
  "evidence_url": "https://assets.insurtech.com.ng/claims/evidence_38210.jpg",
  "incident_date": "2026-07-08T10:15:30Z"
}

If the backend takes this payload and approves the claim without verifying the file properties, it remains open to exploitation. Attackers write simple scripts to register multiple accounts using bought KYC identities from online marketplaces. They then upload the same photo of a broken device screen, downloaded from a public forum, across dozens of different policies.

Without verification checks—such as checking EXIF tags for photo timestamps and GPS coordinates, or comparing cryptographic hashes of the files against historical uploads in the database—the backend processes each claim. Also, because these systems do not cross-reference invoices with registered hospital APIs, attackers can modify details on a single hospital receipt using basic image editors and claim health refunds repeatedly.

Exploit 2: Premium grace period abuse

To prevent immediate policy cancellation when recurring payments fail, platforms apply a mandatory grace period, often set to 14 days. If a Paystack or Flutterwave recurring charge fails, the policyholder remains covered while the system retries the payment. Attackers abuse this policy logic to get unpaid coverage.

First, the attacker registers a policy using a temporary virtual card from fintech services like Mono or Geegpay. The attacker funds the card with just enough money to clear the initial micro-charge verification. Once the platform flags the policy as active, the attacker blocks the virtual card or deletes the card profile.

When the platform attempts to charge the first full monthly premium, the transaction fails, putting the policy into the 14-day grace period. During this grace period, the attacker uploads a fake claim. The backend API checks the database:

const policy = await prisma.policy.findUnique({
  where: { id: policyId }
});

if (policy.status === "ACTIVE" || policy.status === "GRACE_PERIOD") {
  await disburseClaimFunds(claimId);
}

The state machine permits the transaction because the status is in the grace period. The system pays the claim. The attacker then leaves the policy to expire at the end of the grace period without paying any premium.

Exploit 3: Claim disbursement BOLA

Once a claim is approved, the payout is triggered via a disbursement endpoint. A typical API request looks like:

POST /api/v1/claims/cl_77302/disburse HTTP/1.1
Host: api.insurtech.com.ng
Authorization: Bearer eyJhbGciOiJIUzI1Ni...
Content-Type: application/json

{
  "bank_code": "000014",
  "account_number": "2031122334"
}

The API checks that the user has a valid authorization token and checks that the claim is marked as approved. However, it fails to perform object-level validation. It does not verify if the destination bank account belongs to the policyholder.

Because the backend processes the disbursement account details directly from the JSON body without confirming that the recipient matches the verified identity records retrieved during onboarding (using verification services like Dojah or Smile Identity), an attacker can swap the `account_number` to their own. The backend processes the disbursement to the modified bank details immediately, routing the funds to an unrelated account.

The business consequences of automated claim leaks

Automated claims fraud results in high loss ratios. When claim payouts outpace collected premium revenue, underwriting capital is depleted. This leads traditional insurance underwriters (such as Leadway, AIICO, or AXA Mansard) that partner with the InsurTech to cancel their capacity agreements. Without an underwriter backing the platform, operations cease.

Also, platforms face regulatory penalties. NAICOM enforces anti-fraud controls on all insurance intermediaries. Furthermore, under NDPA rules, any data exposure resulting from BOLA vulnerabilities attracts regulatory fines. These security gaps also affect funding, as high loss ratios make the platform unviable during investor due diligence.

Mitigation steps for InsurTech APIs

To secure automated premium and claim systems, platforms must implement validation checks at the database and API levels:

1. EXIF validation and image hashing

Verify image uploads on the backend. Extract the EXIF data from uploaded files to confirm the photo creation date and coordinates. Compute the SHA-256 hash of every uploaded file and search for duplicates in the database to prevent image reuse across multiple accounts.

import crypto from 'node:crypto';
import exifParser from 'exif-parser';

async function verifyClaimEvidence(fileBuffer: Buffer) {
  const hash = crypto.createHash('sha256').update(fileBuffer).digest('hex');
  
  // Reject identical files
  const existing = await prisma.claimEvidence.findUnique({
    where: { hash }
  });
  if (existing) {
    throw new Error("This file has been submitted for a previous claim.");
  }

  const parser = exifParser.create(fileBuffer);
  const result = parser.parse();
  const dateTaken = result.tags.CreateDate;
  
  if (dateTaken && new Date(dateTaken * 1000) < policy.startDate) {
    throw new Error("Incident date predates policy start.");
  }
}

2. Integrate partner verify loops

Build direct integrations with hospital management systems or device retailer databases using mutual TLS (mTLS) connections. Verify invoice and receipt references directly with the issuing partner to confirm the authenticity of the transaction before approving the claim.

3. Verify disbursement names

Before initiating payouts, query the NIBSS Name Enquiry API using the recipient bank account details. Compare the returned account holder name with the KYC name on the policy. If the name similarity score is low, block the payout and flag it for manual audit.

4. Define policy cooling-off periods

Prevent immediate claims on newly created policies. Implement a cooling-off period where claims filed during the initial 14 days of a policy or during a payment grace period require manual review.

Automated scanners check for route vulnerabilities. They do not verify photo metadata integrity or check insurance policy state machine timing rules. Identifying these logical flaws requires manual security analysis of the application workflows.

Related reading

Blog: BVN Spoofing and Liveness Bypass · Rate Limiting and Anti-Fraud Patterns · Webhook Security for Payment Platforms

Guides: CBN Compliance and Security · NDPR & NDPA Compliance

Services: API security testing · Penetration testing