From FNOL to settlement: the anatomy of a claim on ClaimFlow.

A motor claim in Vietnam involves an insurer, a broker coordinating between the parties, a service centre where the vehicle is received and repaired, and the vehicle manufacturer's after-sales organisation watching its network.

Each is built for its own part of the job. Holding the claim itself is the work that sits between them, which is why the status of a claim tends to live in whichever conversation happened most recently, and why that conversation is often a message thread rather than a system.

The design question is therefore narrow: who owes the next action, and by when. Everything below is that question, asked nine times.

Where the claim starts

A claim enters from the insurer's own core system. The insurer notifies the broker of a loss, and that notification becomes a claim notification in canonical form.

This is worth stating plainly because the alternative is often assumed. Two other designs are real: capture at the service centre by the person looking at the damage, and capture by the vehicle owner from their phone. Neither is what runs here today. The first notice comes from the insurer, and the first clock starts when it arrives.

Separately, and usually earlier, the service centre's own dealer management system pushes a work estimate: what the repair will involve and what it will cost. Those two records describe the same event and arrive from different directions, which turns out to be the most interesting problem on the page.

How the two sides are matched

The work estimate almost always exists before the insurer-side claim does. Matching them is evaluated within 24 hours of the inspection.

If no claim materialises in that window, the missed match is recorded against the insurer as a breach of its service level, rather than disappearing into a queue with nobody named. The gap between two organisations' systems is itself made somebody's responsibility, which is the single most useful thing in the model and the hardest to retrofit.

Who is on the clock, and for how long

From here the claim is a sequence of nine touchpoints. Each is a service level: a promise about how long one party may take, measurable against the record. Each names the accountable party, the event that starts its clock, the event that stops it, and the time allowed, its allotment.

Six of the nine:

• Insurer accepts the claim notification. 1, 2 or 4 hours, depending on region.
• Service centre completes inspection. 12 hours to 1 day, by cost band.
• Insurer approves the quote. 4 hours to 2 days, by approved amount, with a separate carve-out below a configured premium threshold.
• Insurer issues payment guarantee. 2 hours or 8 hours, by amount.
• Insurer pays compensation. 5 working days.
• Service centre issues the invoice. Within 4 hours of repair completion.

The payment guarantee is the one to watch. The workshop will not order parts without it, so that touchpoint is where the customer's car sits still.

Two things about the list matter more than the individual numbers.

The numbers are configuration rather than architecture. Regions differ, cost bands differ, and another market arrives with a different table.

And the calendars differ by party. The insurer's touchpoints run against working hours, in Vietnam 08:00 to 17:00 on weekdays with public holidays excluded. The service centre's run around the clock, every day, because a workshop's obligation does not pause at five. Two parties on the same claim are measured on different calendars because their obligations genuinely differ.

That measurement rests on a timestamp, and a timestamp is contestable. An insurer's regulated clock starts on a record created in somebody else's system. That is fair to argue about, and better argued in the contract than in the first disputed month. What makes it workable is that the record is visible to both sides as it is written, not produced afterwards by one of them.

What the trail holds

Every action above lands, as it happens, on an audit trail kept separately for each organisation on the platform. Each entry carries the actor who caused it, a correlation identifier that threads one claim across services, and a before-and-after picture of which fields changed.

That record does two jobs. It answers what happened to a specific claim without a reconstruction. And it could make an outcome-based commercial model checkable rather than argued, because both parties would be reading the same clock.

Where the AI goes, and when

The architecture reserves five AI surfaces as first-class parts of the system rather than additions to it. None of the five is live today. They are specified, the audit shape they must write into is built, and they ship in stages.

In the order they are planned to arrive:

1. Damage and fraud vision at the inspection step, writing a structured damage assessment and fraud signals onto the inspection report. Supplied by a specialist partner rather than built in-house.
2. An operations co-pilot in the operator portal, giving a per-claim summary and a suggested next action drawn from the other surfaces.
3. A mapping arbitrator, proposing resolutions where the work-estimate-to-claim match fails or returns several candidates.
4. A claim orchestrator, proposing the next step for each claim and moving it forward only after a human adjuster approves.
5. A breach-risk scorer on the touchpoint engine, computing a breach probability and expected time-to-close ahead of the deadline and warning the accountable party before the boundary rather than after it.

Each is specified to write into the same audit trail as a first-class actor, carrying how certain it was, which model version decided, the prompt identifier and the evidence it drew on. In a regulated claims operation, an automated decision has to be reconstructable a year later. Without that it is unusable, however accurate it was. That is why the log shape is designed before the agents rather than after.

Being exact about the ordering matters more than a general claim about AI. The scorer is last, and it is the one that would change the operation most, because a rule-based check can only trigger when the deadline passes and therefore reports a failure nobody can still prevent.

What you can evaluate today

The accountability engine, the nine touchpoints, the dual calendars, the matching window and the audit trail are the parts running in production. The five AI surfaces are architecture with a delivery order and no dates published here.