Insurers in the Kingdom are working through the SAMA counter-fraud framework insurance claims teams must now operate against, and a common pattern is emerging. Detection rules built for banking are adapted to claims, declared fit for purpose, and never tested against the way insurance fraud actually behaves. This article explains why that approach leaves blind spots, what scenario-based testing tends to reveal in motor, health and property lines, and why network analysis finds what transaction rules do not.
The examples below are illustrative composites of the situations we see, not accounts of any specific institution, and they carry no figures.
Why banking logic does not transfer to claims
Banking fraud is usually a transaction problem. A payment is unusual for a customer, a device, a time or a amount, and a rule or score flags it. The unit of analysis is the event.
Insurance fraud is usually a relationship problem. A single claim can look entirely ordinary: a plausible loss, a reasonable amount, a valid policy. What is not ordinary is that the same claimants, repairers, clinics, assessors or witnesses keep appearing together across claims, policies and product lines. Threshold rules written around one claim at a time cannot see that.
Three differences matter most:
- Value is spread across many small claims, deliberately kept below review thresholds.
- The participants are often insiders to the process: providers, repairers, intermediaries and sometimes staff.
- The fraud crosses policy lines, so a motor team, a medical team and a property team each see only a fragment.
What the framework asks of insurers
SAMA's Counter-Fraud Framework expects regulated institutions to have governance, policies, defined roles, detection and response processes, and reporting that the board and the regulator can rely on. Scenario testing of fraud controls is part of demonstrating that detection is effective rather than merely present. The practical question for a chief risk officer is simple: if a realistic fraud scheme were run against our controls today, would we notice?
Scenario workshops answer that question. They bring together claims, underwriting, special investigations, compliance, internal audit and data teams, and walk realistic schemes through the rules, workflows and escalation paths that exist on paper and in the system.
Motor: staged accidents
Staged and exaggerated motor collisions are the classic case. Rules inherited from banking typically look for a spike in claim frequency on one policy, or an unusually large amount. A well-run ring avoids both.
In a scenario workshop, the pattern looks different. Several vehicles on unrelated policies are involved in collisions with the same counterparties. Claims route to the same small set of repair workshops. Passengers and witnesses recur across incident reports. Each claim passes individually. Collectively, they describe a closed group.
The blind spot is not a missing rule. It is that the rules evaluate the claim and the policyholder, while the signal sits in the links between parties.
Health: provider and member collusion
In medical claims, schemes often involve a provider and a group of members: inflated procedures, services not rendered, or repeated treatment patterns that sit just inside accepted clinical ranges. Banking-style amount thresholds are poorly suited here, because normal cost variation across providers is wide.
Scenario testing tends to show that provider-level behavior is reviewed in isolation from the members who use the provider, and from the intermediaries who direct them. Shared addresses, phone numbers, referral paths and bank accounts connect parties that the claims system stores in separate tables.
Property: repeat losses and shared actors
Property and fire claims carry a different signature: recurring losses, shared assessors or contractors, and ownership structures that change shortly before a loss. Here the gap is often between underwriting and claims. Information that would raise suspicion at inception is not visible when the claim arrives, and the reverse is also true.
Why network analysis reveals the pattern
Social network analysis treats claimants, policies, vehicles, providers, repairers, addresses, phone numbers, bank accounts and intermediaries as nodes, and the relationships between them as links. Instead of asking whether a claim is unusual, it asks who is connected to whom, and how densely.
A workable approach follows these steps:
- Consolidate identifiers across motor, health and property systems so the same person, address or account is recognized wherever it appears.
- Build a graph of parties and claims, with links for shared attributes and repeated co-occurrence.
- Look for clusters: groups of entities connected far more tightly to each other than to the wider portfolio.
- Identify bridge entities that link clusters across policy lines, such as an intermediary or a shared contact number.
- Prioritize clusters for investigation using the structure of the network, not only individual claim amounts.
- Feed confirmed findings back into rules, so detection improves after each case.
This is where cross-line collusion becomes visible. A repairer in a motor cluster may share a contact detail with a clinic in a health cluster. No single line owns that observation, which is why it is missed.
Network analysis has limits. It depends on data quality, it produces leads rather than conclusions, and it needs human investigators and sound data-protection handling. Linking personal data across lines must be justified, proportionate and aligned with the Personal Data Protection Law. It complements transactional rules; it does not replace them.
Turning findings into governance
Detection gaps matter to a board only when they connect to ownership and reporting. Findings from scenario testing should lead to clear actions:
- A named owner for each fraud scenario and its controls.
- Defined escalation between claims, special investigations and compliance.
- A three-lines-of-defense split, so that those who run controls, those who oversee them and those who assure them are distinct.
- Regular reporting to the board and to the regulator that describes scenarios tested, gaps found and remediation status.
ISO 37001, the anti-bribery management systems standard, is a useful reference here. Collusion with providers, repairers or intermediaries often involves improper payments or inducements, and its emphasis on due diligence, controls over third parties and reporting channels fits those risks well.
Where to start
A practical first step is a short set of scenario workshops per product line, using realistic schemes rather than generic fraud categories. Record what the current rules would and would not catch, then decide where graph analysis, data consolidation or workflow changes are justified.
How we can help
SAMA Counter-Fraud Framework Implementation is the service that turns this work into a complete program. We design and implement the governance, policies, roles, processes and reporting your institution needs to meet the SAMA Counter-Fraud Framework. The work moves through four stages: a baseline gap assessment against the framework, design of governance, policy, operating model and reporting, roll-out with training and process adoption, and assurance through self-assessment and readiness for regulator review.
Deliverables include a counter-fraud strategy and roadmap, a policy and procedure set, a RACI and operating model, and a compliance self-assessment against the framework. Implementation typically takes three to six months, depending on your starting point and size. We write the policies in Arabic and English, tailored to your products and approved through your governance.
