Risk Management Information Systems: Why Your Loss Triangle Is Wrong and Your Actuary Already Suspects It

Why the loss run is the most expensive spreadsheet in the company

It is six weeks before renewal. The actuary has asked for loss data valued as of last month, by line, by accident year, with paid and incurred split out. Your workers compensation administrator sends a fixed width text file. The general liability administrator sends an Excel workbook where the reserve column is formatted as text. The auto carrier sends a PDF. The captive sends nothing until you chase it. An analyst spends nine days rebuilding a triangle, and in that triangle three claims that were reserved at $40,000 in March are now at $310,000, and nobody in the risk department knew until the file was opened.

That is the whole problem in one paragraph. The tools around it are usually a spreadsheet stack, a broker portal you can read but not query, a certificate tracking service, and possibly Origami Risk, Riskonnect or Ventiv if the organisation bought a platform. Those three are real, capable systems and they run large risk programmes properly. What they charge dearly for, and what determines whether the implementation succeeds, is the part nobody demos: mapping every administrator's feed into your coverage structure, your location hierarchy and your cause of loss taxonomy, and keeping that mapping alive when an administrator changes their export next quarter.

The exposure is not the software cost, it is the funding decision. Reserve data drives your actuarial estimate, which drives your collateral, your accrual and your retention choice. Being wrong by a few hundred thousand on incurred but not reported losses moves real money and it moves it before you find out. In risk programmes we have worked on, the recurring pattern is the same: two to three weeks of analyst time per renewal spent on data assembly, adverse development discovered at valuation rather than when it happened, and no honest allocation of cost of risk back to the locations generating the claims, which means operations managers have no financial reason to care about safety.

Problem 1: every administrator sends a different loss run and the mapping lives in a person

Administrator A calls it Claimant State. Administrator B calls it Jurisdiction. Your captive calls it Sit. One sends incurred as paid plus reserve, another sends it net of recovery, a third includes allocated expense in incurred and a fourth reports it separately. Cause of loss codes are proprietary in every case. Reconciling all of that into one taxonomy is not data entry, it is a set of business rules, and right now those rules exist in one analyst's head and a workbook with hidden columns.

Packaged platforms will build these mappings for you and charge accordingly, then charge again when a feed changes. That is a defensible commercial model, but it means the most business-critical logic in your risk function sits behind a change request queue.

What a custom build does: a feed pipeline where each administrator has a declared schema, a mapping to your canonical claim model, and validation rules that reject a file rather than quietly loading garbage. Every load is versioned and reversible, so when an administrator reissues a corrected file you can see exactly what changed. Field mappings are configuration you can edit, not code someone else owns. The immediate payoff is that a monthly load stops being a person-week, and the durable payoff is that the mapping logic becomes an asset your organisation controls when you next put the administrator contract out to tender.

Problem 2: adverse development is found at valuation, months after it happened

A claim reserve moves from $40,000 to $310,000 because an adjuster received a medical report. That single change may be more significant to your programme than everything else that happened that month. Today you find out when the quarterly file lands, if anyone reads the detail, which they do not because there are eleven thousand rows.

What a custom build does: treat every load as an event stream and diff it against the prior valuation. Reserve movements above a threshold you set generate an alert to the named risk owner the day the file lands, with the claim narrative, the adjuster note if the feed carries it, and the history of prior movements. Large loss reviews become a standing list rather than an annual archaeology exercise. This is technically simple and organisationally transformative, because it converts your risk function from reporting on the past to intervening in claims that are still open.

Problem 3: certificates of insurance expire and nobody notices until there is a claim

A subcontractor's general liability policy lapsed in April. They are still on site in July. There is an injury, their carrier denies, and your programme absorbs a loss that a contract said you would never carry. The certificate was in an email folder and its expiry date was in nobody's calendar.

Tracking services exist and they are cheap, but they generally answer whether a certificate exists, not whether the certificate satisfies the specific insurance requirements in the specific contract that subcontractor signed. Additional insured wording, waiver of subrogation, primary and non-contributory language and required limits vary by contract type and by project, and the certificate form itself carries only a summary of coverage.

What a custom build does: the contract holds the insurance requirement set, the vendor record holds the certificates, and the system checks one against the other rather than just checking dates. Document extraction reads the certificate and pulls carrier, policy number, limits, effective and expiry dates, and the endorsement checkboxes, then flags where the evidence falls short of the requirement. Expiries escalate before the date, not after, and the escalation goes to the project manager who has a relationship with the vendor, not to a risk inbox. Confirm the legal sufficiency of wording with your counsel and broker, because a system can tell you a limit is short but it should never be your legal opinion.

Problem 4: cost of risk allocation depends on a hierarchy that changes every acquisition

You allocate premium, retained losses, administration fees and collateral cost back to divisions and locations, usually by a formula involving payroll, revenue, headcount and loss experience. Then you acquire eight sites, close two, and restructure into new regions. Every historical allocation is now against a hierarchy that no longer exists, so trend analysis by location silently breaks and the argument at the budget meeting becomes unwinnable.

What a custom build does: an effective-dated location hierarchy where a site can be reported under whichever structure was in force at the time, or restated under the current structure, on demand and without rewriting history. Allocation formulas are versioned so a prior year's charge can be reproduced exactly as it was issued. Public entity pools have the same requirement with member entities instead of divisions, and the same failure mode when a member joins or leaves mid-year. This sounds like an accounting nicety until an operating vice president disputes a six figure charge and you cannot reconstruct how it was calculated.

Problem 5: incident data never meets claim data, so prevention is guesswork

Operations records near misses, first aid cases and vehicle incidents in one place. The administrator records claims in another. The two never join, so you cannot answer whether the sites with high near miss reporting have lower claim frequency, which is the single most useful question in the entire discipline. Your OSHA 300 log is maintained separately again, usually by someone in HR (Human Resources), and recordability decisions are made without reference to how the claim actually developed.

What a custom build does: incident intake as a phone-friendly form supervisors will actually complete on the floor, with the incident becoming the parent record a claim later attaches to when the administrator reports it. Frequency and severity analysis then works at the level where prevention happens, which is a shift at a site, not a division in a report. Recordability determination and log generation sit on the same record rather than in a parallel workbook.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category has a fairly predictable shape. A focused first release covering claim feed ingestion and normalisation from your administrators, reserve change detection with alerting, and loss triangles and standard renewal reporting runs $70,000 to $150,000 and ships in 12 to 18 weeks. That is a system your analyst uses for the next renewal rather than a proof of concept. A full risk management information system adding incident intake, certificate and vendor compliance, cost of risk allocation with an effective-dated hierarchy, safety analytics and an actuarial data extract runs $170,000 to $420,000, phased over 6 to 12 months.

What drives cost up here: the number of distinct claim feeds, because each administrator is its own mapping project measured in weeks not days. International programmes, because currency, jurisdiction and coverage structures multiply the model. Historical conversion, because loading ten years of claims from legacy files to make triangles meaningful is a real workstream. And the taxonomy decisions, which need your risk manager in the room for more hours than they expect.

What keeps cost down: starting with your two largest lines and the two administrators that carry most of the exposure, and leaving certificates and incident intake to phase two. Loss data quality is where the money is.

Build versus buy, and when buying is right

Buy if you are fully insured under a guaranteed cost programme with a single carrier and modest retentions. Your broker's analytics will cover you and a build is a waste. Origami Risk, Riskonnect and Ventiv are also the right answer if you need broad functional coverage quickly, have the budget for a proper implementation, and your programme structure is fairly conventional. There is no shame in buying a good system.

Build when two or more of these are true. You receive claim data from three or more administrators or carriers with inconsistent layouts. Your allocation formula is contested internally and cannot be reproduced from records. You have an active captive or a group pool where members join and leave. Your incident data and your claim data will never be joined by a vendor because the vendor does not know your operations. Or you have already implemented a platform and find your team still rebuilding the same spreadsheet afterwards, which is the most common story we hear in this sector.

The real decision point is whether the ingestion and normalisation of your specific feeds is the value. If it is, that logic belongs to you, because it is the thing you will still need when you change platforms, administrators or brokers.

How to choose a developer for an RMIS build

Ask them to model a claim on a whiteboard. If they do not immediately separate the claim from its valuations over time, so that paid, reserve and incurred are point-in-time facts rather than fields on a row, they will build you a database that cannot produce a triangle. That is the single most common failure in this category and it is fatal.

Ask how they handle a corrected loss run. The answer must involve versioned loads and the ability to see what changed between valuations. Anyone who plans to overwrite the prior file has not understood what you are buying.

Ask what insurance data they have actually handled. Loss runs, ACORD certificate forms, IAIABC workers compensation reporting and actuarial extracts are all specific artefacts. Ask which administrators and which formats, and treat vague answers as a no.

Ask who owns the code, the cloud accounts and the historical claim data, in writing, before kickoff. At Digital Heroes the client owns all of it from the first commit. Your loss history is the asset that prices your programme for the next decade, and it should never sit somewhere you cannot extract it from in full, in a format your actuary accepts, on a day of your choosing.