Risk Management Information System Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the claim data model get scoped wrong so often?

Ask most development teams to model a claim and they will draw a table: claim number, claimant, date of loss, cause, paid, reserve, incurred, status. It is the obvious design and it is the single most common fatal error in this category, because it treats a claim as a thing with current values rather than as a thing with a history of values.

Everything a risk function needs is a comparison between two moments. A triangle is paid and incurred amounts by accident year at successive valuation dates. Adverse development is the difference between this month's reserve and last month's. A row that gets overwritten each month can answer none of that, and no amount of reporting work added later will recover history that was never stored.

The reason it happens is that the requirement gets written as reporting rather than as a model, so a team builds dashboards on whatever shape the loss run arrived in. The fix is to insist on the model before anything else: a claim, and separately, a valuation of that claim at a point in time carrying paid, reserve, incurred, recovery and expense, with every load creating a new valuation rather than replacing the last.

What goes wrong when you load ten years of legacy loss runs?

Triangles only mean something with history, so almost every one of these projects carries a conversion workstream. It is routinely the largest single line item and routinely the one omitted from the first estimate.

The problems are specific to insurance data. Older valuations arrive as PDF loss runs from an administrator you no longer use, so the data has to be extracted before it can be mapped. Cause of loss codes are proprietary to each administrator and were revised at some point, usually without a note. Claim numbers get reissued when a programme moves, so the same underlying claim appears twice under different identifiers and your frequency counts are wrong in a way that is very hard to see.

The fix is to treat conversion as its own workstream with its own timeline and its own acceptance test. Profile the historical extracts during discovery, not at cutover. Decide explicitly how many years you need at full detail and how many you can carry as summary triangles, because loading ten years at claim level when six would serve the actuary is expensive precision. Reconcile the converted totals back to the administrator's own year-end summaries and get your broker or actuary to sign off on the reconciliation before anyone builds a report on the data. And keep the source file exactly as received, because when a figure is challenged two years from now the only defensible answer is the original document.

Why do administrator feeds break after launch?

Every third party administrator sends a different loss run, and the mapping between their layout and your canonical claim model is the most business-critical logic in your risk function. After launch it is also the most fragile, because the people who change it do not work for you.

Administrator A calls a field Claimant State and administrator B calls it Jurisdiction. One reports incurred as paid plus reserve, another reports it net of recovery, a third folds allocated expense into incurred and a fourth reports expense separately. Then an administrator upgrades their claims system in the spring and reissues the export with two additional columns and a renamed status field. If your loader is tolerant, it accepts the file and quietly loads garbage. If your loader is strict but nobody owns the alert, the monthly load fails and gets noticed three weeks later.

The fix has three parts. Declare a schema per administrator and validate against it, so a structural change is a rejection with a readable reason rather than a silent misload. Make field mappings configuration your own team can edit, not code inside a change request queue, because the whole point of owning this is that you can respond in a day. And version every load so it is reversible, which matters more than it sounds: administrators reissue corrected files regularly, and being able to show exactly what changed between the original and the correction is how you challenge a reserving practice that looks inconsistent.

What happens when certificate compliance and incident capture are not covered?

These are the two gaps that turn a reporting system into a risk system, and they are the two most often deferred to a phase that never gets funded.

On certificates, a subcontractor's general liability policy lapses in April and 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. Tracking services answer whether a certificate exists and whether the date has passed. They do not answer whether the certificate satisfies the specific insurance requirements in the specific contract that vendor signed, and additional insured wording, waiver of subrogation, primary and non-contributory language and required limits all vary by contract type and project. The fix is to hold the requirement set on the contract, extract carrier, limits, dates and endorsement evidence from the certificate, and compare one against the other rather than checking dates. Escalation goes to the project manager who has the vendor relationship, before the expiry. Have counsel confirm wording sufficiency, because software can flag a short limit and should never give a legal opinion.

On incidents, near misses and first aid cases live in an operations system and claims live with the administrator, so the two never join. That is why most risk functions cannot demonstrate that prevention works, and it is why safety spending is argued on faith at budget time. The fix is that a supervisor's incident report becomes the parent record a claim attaches to when the administrator later reports it, which finally lets you compare near miss reporting against claim frequency at site level.

Should you build custom or configure what you already own?

If you are fully insured under a guaranteed cost programme with a single carrier and modest retentions, do not build. Ask your broker for their analytics and spend the money on safety. 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.

The honest test is whether the ingestion and normalisation of your specific feeds is where the value sits. If your loss data arrives from three or more administrators with inconsistent layouts, if your allocation formula is contested internally, if you run a captive or a group pool with members joining and leaving, or if you have already implemented a platform and your team is still rebuilding the same spreadsheet afterwards, that mapping logic is the asset and it should belong to you. That last case is the most common story we hear in this sector, and it is not a criticism of the platform. It is a signal about where your particular complexity lives.

How do hidden costs get into the quote?

A first release covering claim feed ingestion and normalisation, reserve change detection with alerting, and loss triangles and renewal reporting runs $70,000 to $150,000 across 12 to 18 weeks in our delivery experience. A full system adding incident intake, certificate and vendor compliance, cost of risk allocation and safety analytics runs $170,000 to $420,000 phased over 6 to 12 months. Four things push a quote past its estimate.

Feed count is the first and the most predictable, because each administrator is its own mapping project measured in weeks rather than days, and a quote written for two feeds does not scale linearly to six. Historical conversion is the second, and it is often larger than the feature work. International programmes are the third, since currency, jurisdiction and differing coverage structures multiply the model rather than adding to it. The fourth is taxonomy, which costs your time rather than the developer's: deciding one cause of loss structure, one coverage hierarchy and one location model needs your risk manager in the room for considerably more hours than they expect, and the project stalls without those decisions. Start with the two largest lines and the two administrators carrying most of the exposure, and leave certificates and incident intake to a second phase.

What separates a build that works from one that fails here?

The builds that work produce something an analyst uses at the next renewal. That means a triangle they trust enough to hand to an actuary, and a reserve movement alert that reaches a named risk owner the day the file lands rather than at the quarterly valuation. Everything else is secondary, and programmes that try to launch certificates, incidents, allocation and analytics simultaneously usually arrive at renewal with none of it finished.

An effective-dated location hierarchy is the other thing that separates the two outcomes, and it is invisible until it matters. You acquire eight sites, close two and restructure into new regions, and every historical allocation is now against a structure that no longer exists. Build the hierarchy so a site can be reported under whichever structure was in force at the time or restated under the current one, and version the allocation formulas so a prior year's charge can be reproduced exactly as issued. The first time an operating executive disputes a six figure allocation, reconstructing the calculation from memory is not a defence.

When you interview a developer, ask them to model a claim on a whiteboard, ask what happens when an administrator reissues a corrected loss run, and ask which insurance artefacts they have actually handled by name, since loss runs, ACORD certificate forms and actuarial extracts are all specific. Then settle ownership of 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 prices your programme for the next decade, so test the full export during the build rather than during a dispute.