Process Mining for Insurance Claims Compliance

Insurance claims compliance comes with strict deadlines. When those deadlines aren’t met, there can be steep financial consequences for insurers. That’s why many insurers using process mining to run rule-based compliance checking and anomaly detection on their workflows.

For example, the Texas Department of Insurance found 9 of 50 reviewed claims paid late in a 2025 enforcement order, an 18% late-payment rate in the examined sample, and assessed a $200,000 penalty (TDI, 2025). Reporting built from claims-system logs rarely shows that exposure before an examiner does, because the late file usually stalled outside the core system, in a mainframe screen or an email thread. Reserve spreadsheets also hold work the core system never recorded.

On the other hand, process mining reconstructs each claim’s path from the records a system does keep, tests that path against deadlines and controls, and shows where the log itself goes dark.

What is process mining for insurance claims compliance?

Process mining for insurance claims compliance reconstructs each claim’s path from the claims system’s event log, compares that path against regulatory deadlines and internal controls, and flags every claim that broke a rule. The term process mining insurance claims compliance covers four linked activities, each with a defined input and output:

• Event log extraction: The claims system records a case ID (the claim number) and an activity name for each action a user or workflow takes. Each record also carries a timestamp, and the tool ingests those records.
• Discovery: An algorithm assembles the records into the as-is process model, including every ordering of steps that occurred, not the ordering the procedure manual assumes.
• Conformance checking: Software compares each claim’s trace against a reference model or a rule set and measures the deviation; rule checking tests individual constraints. Token replay and alignments score whole traces, completing the three main techniques.
• Monitoring: Rules run against new events as they arrive, so a breached deadline or a missing approval raises an alert while the claim is still open.

The continuous form of that fourth activity has a name in the audit literature. ISACA defines continuous controls monitoring (CCM) as “near continuous (or at least high-frequency) monitoring of control operating effectiveness” (ISACA, 2015). That “at least high-frequency” qualifier matters when a vendor’s marketing says real time and its documentation says micro-batch.

How does process mining detect claims compliance violations

Process mining detects a claims compliance violation by matching each claim’s recorded sequence of activities and timestamps against a rule, then reporting the affected claims and adjusters and identifying the steps where the match failed. Each stage below adds a layer of evidence to the one before it.

The claims lifecycle as an event log

Analysts can mine a claim when every lifecycle activity carries the claim number and an activity name, along with a timestamp. They also need the acting user wherever a control depends on who did what. Claims teams typically perform these property and casualty (P&C) activities in sequence:

• First notice of loss (FNOL) receipt
• Adjuster assignment
• Investigation, including reserve setting and inspection. Documentation requests also form part of this activity.
• Coverage decision, accept or deny
• Payment authorization and payment issuance
• Closure

The Process Mining Manifesto requires only that each event refer to an activity and to a case, and it treats resource and timestamp as additional information to capture “whenever possible”; its own example of a process instance is an insurance claim (IEEE Task Force on Process Mining, 2011). For compliance work both optional fields are mandatory. A deadline rule is a timestamp subtraction, and a segregation-of-duties rule is a comparison of user identities across two activities.

Discovering the real claims process and its deviations

Operations analysts use discovery to compare the documented happy path with the paths claims took. They examine the gap for rework and workarounds, including deviations that create compliance exposure. The documented process for a simple property claim runs FNOL, assignment, investigation, decision, payment, closure in that order. Analysts also identify reopened files, second assignments, repeated documentation requests, and payments issued in more than one batch, distinguishing the resulting process variants.

A 6-month academic study of Suncorp’s claims event log found that when the “Follow Up Requested” activity recurred more than four times, the claim had an 85% chance of running long (Suriadi et al., 2013). A reference model drawn from the procedure manual would not contain that loop. A conformance check against the manual alone would report it as unexplained deviation rather than as the strongest available predictor of a missed deadline.

Conformance checking against controls

Reviewers use conformance checking to test each claim trace against ordering and timing rules. They also test identity rules, and choose a technique according to the kind of breach. The techniques differ in what they score:

• Rule-based checks: A single constraint such as “payment requires a prior approval” is tested per trace and reported as fulfilled or violated. A violation may be temporary or permanent. This is the form most regulatory deadlines and approval controls take.
• Trace alignment: The whole trace is matched against the reference model, and every step the log contains but the model forbids, or the model requires but the log lacks, adds cost. The result is a fitness score per claim and per log.
• Segregation of duties: The check compares the user field on two activities, such as reserve set and payment authorized, and flags any claim where they match.
• Approval controls: The check compares the approver’s identity and the payment amount against the authority matrix, and flags approvals above limit or approvals missing entirely.

Alignment gives the fuller picture but costs more compute on logs with millions of events. Rule-based checks run cheaply and map directly to the way a regulation is written, which is why most compliance monitoring starts there.

Mapping regulations to conformance rules

To configure a conformance rule, you must define the events that start and stop the clock. You must also specify the unit of time the statute uses. The table maps the regulations claims leaders ask about most to the rule a monitoring tool would execute:

Regulation-to-rule mapping for claims conformance checks

Several states count business or working days rather than calendar days, and some start the clock at notice while the NAIC model starts it at proof of loss. A timer configured for the wrong unit reports false breaches in one state and misses real ones in another, so the rule library needs a per-state, per-line clock definition.

HIPAA applies to the health plan line of business only. HHS lists workers’ compensation, disability, and automobile liability with medical payments as “not health plans” (U.S. Department of Health and Human Services, FAQ 364) so a P&C carrier maps HIPAA rules to its health-related products and not to its auto or property claims.

Worked example: Catching a late decision and an unapproved payment

A reviewer can identify both a timing breach and an ordering breach in a single claim trace, using a timestamp subtraction for the deadline and a precedence rule for approval. The illustrative trace below shows one property claim as a conformance checker would read it:

Illustrative event log for claim CLM-48213

A reviewer identifies the late decision through arithmetic. Proof of loss arrived on March 9 and the coverage decision posted on April 3, 25 days later, past the 21-day accept-or-deny window in NAIC Model 902 §7(A) (verify current; the state of jurisdiction may use a different count or unit). The trace also contains no more-time notice event, which under §7(B) would have been due within the same 21 days (verify current), so the timing check reports two breaches on one claim.

• Ordering failure: A reviewer identifies the unapproved payment by comparing the authorization and approval events. Adjuster_204 permanently violates the precedence rule “supervisor approval precedes payment authorized” at 16:20 on 28 March, before the supervisor records approval.
• Identity finding: The reviewer also finds that the same user set the reserve and authorized the payment; that user recorded the decision as well. This breaches a segregation-of-duties matrix that separates reserving from payment authority.

The reviewer cannot determine from the log why adjuster_204 authorized early. The adjuster could have received a verbal go-ahead in a chat window or an emailed estimate; a supervisor could also have stood at the desk. These interactions leave no trace in the claims system, limiting log-based detection.

Can process mining detect claims fraud and leakage

Process mining detects the sequence and timing anomalies that precede fraud and leakage, such as a payment released by the person who set the reserve, but it produces anomalies for investigation, not confirmed fraud. The distinction shapes how a claims operation staffs the output.

In a peer-reviewed study of a global bank’s procurement log, process mining found 175 segregation-of-duties violations in 26,185 cases, where one person both received goods and released payment, and follow-up by internal auditors showed many flagged payments had legitimate supporting documents (Jans, Alles, and Vasarhelyi, 2014).

The domain is procurement, not claims, but the rule is identical to the claims control, and the lesson transfers: the anomaly list is an investigation queue, and its value depends on how fast a person can clear it.

Claims-specific internal fraud signals follow the same pattern. The checks that matter are:

• Repeated sequence anomalies by one user
• Payments issued to a payee whose bank account differs from the beneficiary of record
• Approvals above the approver’s authority limit
• Payment events with no matching decision event

Each resolves to an identity comparison or an ordering rule a conformance checker already runs.

Process mining also contributes the structural evidence behind leakage scenarios: reopened files, repeated reserve changes, duplicate payment events, and the follow-up loops that predicted delay in the Suncorp log, each tied to the claims and teams that produce them.

How is process mining different from traditional claims audits

A market conduct exam or internal file review samples roughly 100 claims from a population of thousands and reads them months after closure; process mining tests every claim against the same rule while the claim is still open. In one Delaware market conduct exam, examiners drew 109 files from a universe of 9,740 claims (Delaware Department of Insurance, 2021). A carrier whose own quality assurance mirrors that design learns about a pattern of late decisions after the pattern has already run for a year.

The Institute of Internal Auditors describes the alternative as a shift “from periodic evaluations… based on a sample of transactions, to ongoing evaluations based on a larger proportion of transactions” (IIA, 2015). For claims, the larger proportion is every file, and the evaluation runs daily rather than at exam time. The operational gain is the open claim caught at day 18 of a 21-day clock, with three days left to act.

File reviews miss cross-system rework for a reason that also limits log-based mining. A reviewer reads the claim file as the core system holds it, so the second touch where the adjuster re-keyed a reserve from a spreadsheet, or the email exchange that stalled a decision, is not in the file. Log-based process mining has the same blind spot wherever the work left the system; its advance over audit is population and timing, not reach.

Full-population testing brings its own failure mode. Research on continuous auditing at Siemens identifies “the management of audit alarms and the prevention of the alarm floods” as critical to a working program (Alles et al., 2018). Claims leaders who activate many rules across every open claim at once can overwhelm their exception team, so they introduce rules in priority order and tune thresholds against the first weeks of output.

Tools, platform integration, and continuous monitoring

Claims leaders should compare vendor marketing with documented ingestion and conformance behavior, including whether alerts arrive before deadlines. The subsections examine log-based platforms and claims-data integration, including desktop-level observation of work outside the logs.

What log-based platforms document

Log-based process mining platforms document conformance as model-based checking against a discovered or imported BPMN model, with the conformance rate expressed as the share of cases that fit. Ingestion runs on schedules or incremental loads, including micro-batch pipelines; vendors use the phrase near real time in documentation and drop the qualifier in marketing.

Alerts travel by email or platform message. A call can also start a process in another system.

Open-source academic frameworks implement alignment and declarative rule checking in full but document no alert-delivery subsystem.

Extracting claims logs from Guidewire and Duck Creek

Guidewire ClaimCenter records history events automatically, each with an eventTimestamp and a historyType, along with the user, and exposes them through GET /claims/{claimId}/history-events; Cloud Data Access streams historical changes to an S3 bucket (Guidewire, 2025). The event source exists. What Guidewire does not publish is a mapping from those events to the case and activity columns a mining tool needs, along with its timestamp column. The carrier’s data engineers build that mapping using third-party templates.

Duck Creek publishes no claim-history table documentation at all. The only extraction template found is third-party, draws status transitions from the Data Hub, and states that the Data Hub refreshes on a schedule, typically nightly. Reviewers using a deadline timer fed by a nightly refresh learn about a breach the following morning, and IT teams spend months completing the integration work.

The core platform is also only part of the claims desktop. Policy verification on a mainframe terminal, medical records in a Citrix-hosted vendor portal, reserve calculations in Excel, and claimant correspondence in email produce no event log a mining tool can read, and the handoffs between them are the steps where files stall and controls get bypassed.

Observing claims work that never reaches a log

Skan AI, an agentic AI platform, builds a Context Graph of Work from desktop-level observability of claims activity across the mainframe terminal, the Citrix session, the core claims system, email, and spreadsheets, so the conformance check covers the handoffs an event log never records.

The Context Graph of Work is a continuously updated model or digital twin that connects people, applications, tasks, decisions, policies, outcomes, sequences, and governance constraints as they occur in insurance claims operations.

Capture: The data source is Skan Virtual Assistant, a lightweight sensor that captures process activity on the adjuster desktop without backend connectors or application changes. Deployment requires no system downtime; IT participation is limited to sensor rollout.

Email content and keystrokes are never captured, and the unit of analysis stays on the work rather than the worker. That desktop-level observation is what lets Skan AI pair end-to-end process depth with zero-integration capture, where log-based mining reaches depth only after integration into every system of record and task mining captures tasks without the end-to-end process.

Protected information: Protected information on screen never leaves the carrier’s environment. Skan PRISM, an on-premises privacy and information security gateway, applies pixel-level redaction before any metadata reaches analytics, and raw screen data remains inside the customer-controlled perimeter.

Deployment runs hosted by Skan AI or in a private environment.

Privacy by design extends to the identities a segregation-of-duties check needs. Employee identities can be pseudonymized at capture, and masking is irreversible. The system logs every access to the resulting data.

Assurance: The Skan AI security, trust, and transparency page documents ISO/IEC 27001 and ISO 42001. It also documents SOC 2 Type 2.

Process analysis: Skan AI Intelligence converts the observations into end-to-end process flows, variant analysis, execution metrics, bottleneck detection, and drift detection. Teams can examine cross-application work such as a reserve re-keyed from Excel or a decision stalled in email.

A neurosymbolic AI architecture classifies on-screen activity with neural perception and applies explicit rules to that classification, which preserves an explainable reasoning path from observed activity to the flagged deviation.

First process evidence arrives within a few weeks of sensor rollout. Teams can also examine claims workflow bottlenecks across applications.

Insurer case studies and compliance KPIs to track

The published insurer evidence for process mining in claims is thin and mostly about cycle time, so a compliance program sets its own KPIs from the first week rather than borrowing a benchmark that does not exist. The Suncorp case cited earlier is a 2013 academic study of processing duration, not of compliance or leakage.

A Fortune 200 P&C carrier reduced minutes to close a case by 16% after applying desktop-level process observability to its claims process (Skan AI, 2024).

The KPIs below are the ones a claims operation can compute from its own traces and defend in front of a CFO or an examiner:

• Conformance rate and violation rate: The share of claims whose trace fits the reference model, broken out by rule and team. A site-level breakdown makes a 3% violation rate at 1 site visible against 0.4% elsewhere.
• Cycle time against regulatory clocks: Days from proof of loss to decision measured against the NAIC 21-day window and each state’s variant. For property, J.D. Power’s 2026 study puts time to final payment at 40.7 days (J.D. Power, 2026), a market reference rather than a regulatory limit.
• Segregation-of-duties breach rate: The share of paid claims where the same user sets the reserve and authorizes payment, with approval by that user checked as well.
• Deadline-at-risk count: Open claims within a set number of days of a clock expiring, reviewed daily, which is the metric that converts monitoring from retrospective to operational.
• Alert precision: The share of alerts confirmed as true deviations, tracked to keep the exception queue short enough to clear.

Report cycle time as a distribution, not an average. An average of 19 days hides the 8% of files that cleared day 21, and those files are the ones the exam report will list.