Loading
Policy admin, first notice of loss, adjusters and repair networks each hold part of the answer. We connect them so a claim becomes a decision rather than a queue, without replacing the systems you already run.
Four systems · one claim
Where it breaks
It does that well. What it was never asked to do is let distribution, claims and partners work from the same model, which is why every new idea turns into a change request against the one system nobody wants to touch.
Rating, wording and workflow all live inside the policy platform, so launching a variant means a release, a regression cycle and a queue behind whatever else is in flight that quarter.
A canonical product and policy model outside the admin system, so distribution and claims stop depending on its release calendar.
The claim arrives by phone, portal or email, then waits for a human to read it, classify it and decide where it goes. The straightforward claims wait behind the complicated ones.
We capture the notice once and route it on your rules, so simple claims move straight through and adjusters get the ones that need judgement.
Every MGA and cedant sends a different layout on a different day. Someone normalises them by hand, and the treaty position is only as current as the last person to finish reconciling.
We normalise bordereaux into the same policy and claim model, with the lineage your actuarial and reporting teams need behind the numbers.
How it works
We normalise policies, claims and partner submissions, route them on your rules, and publish them with the lineage behind every number.
Scroll the diagram sideways →
ACORD messages where your partners use them, a canonical policy and claim model where they do not, and REST and events for everything new. A new MGA is a mapping against the same model.
The runtime sits on your cloud tenancy, in your data centre, or split across both. Residency and supervisory expectations usually make the decision, and we design to them.
Claim pipeline throughput, partner submission health and failed routings all land on one dashboard. We can run it under a support agreement if you would rather not.
Products
DwaniAI and MetricMonitor read the same policy and claim model, so a policyholder is the same policyholder whether they are asking or you are measuring.
First notice of loss, claim status, renewals and policy questions over voice and chat, in the languages your markets use, with a handover to a person the moment the answer needs judgement.
Explore DwaniAI →Claims pipeline throughput, policy admin health, partner submission status and integration SLAs on one screen, with history a regulator or an auditor can follow.
Explore MetricMonitor →How we work
Nothing we build takes over as the book of record on our timetable. Both paths process the same work, your team compares them against your own month end, and the switch happens when you are satisfied.
It is included in every engagement. Every migration and every new channel works this way.
A flow is correct when your own numbers agree, checked against the reporting you already produce and already trust.
Documents, endorsements and prior claims travel with the policy, or the policy does not travel. A migrated record that has lost its history costs more than it saves.
Recent work
Anonymised at the client's request
An insurer had a variant its distribution team could sell and a policy platform where every rating change queued behind the annual release. Claims and the broker portal both read from that platform, so nothing could move independently.
We built a canonical product and policy model alongside the admin system, pointed distribution and claims at it, and left the platform as the book of record. The variant launched without a platform release.
Talk to us about your estate →Questions
Yes, and we would usually rather integrate with it than replace it. We work through whatever it already exposes, whether that is an API, a message queue, a database view or a file drop, and we do not put custom code inside a vendor platform where a supported interface exists.
Get started
Tell us what you are trying to launch or speed up, and what the policy platform will and will not allow. An integration architect reviews it and comes back within two working days.
