Core insurance management system

IT.101 Insurance

A full end-to-end platform covering policy management, claims processing, billing and customer portal, built from scratch and designed for reliability, auditability and scale.

Three systems in one

The brief was a core insurance system built from scratch, the system where the policies live and the site the customers sign into, as one platform. We knew how to build software. We knew a good deal less about insurance, so the project began with a crash course.

For the person buying insurance the whole thing is simple. There is a car, a house or some other asset, and a contract that says what is covered and when. The customer's side of the platform is just as simple. Insurances, invoices, assets, settings. Most customers sign in a few times a year to look at an invoice, and hope never to need the fourth reason, a claim.

Underneath, an insurance company runs on flows. Policies renew, terms change, quotes turn into contracts, claims come in and get handled, and every one of those touches the same customer, the same asset and the same money. After weeks of meetings with the people who do this work every day, and a long read of the rules the company operates under, the shape of the job was clear. In Europe that reading starts at EIOPAeiopa.europa.euThe European Insurance and Occupational Pensions Authority, the EU body that sets the supervisory rules national authorities apply to insurers., runs through Solvency IIeiopa.europa.euThe EU directive on how much capital an insurer must hold and what it must report, which shapes what a core system has to record. and the Insurance Distribution Directiveeiopa.europa.euThe EU rules on how insurance is sold and what the customer must be told before buying, which shape every sales flow. for how policies are sold, adds GDPRgdpr.euThe EU data protection regulation, which governs how a platform full of personal data is built and run. and DORAeiopa.europa.euThe Digital Operational Resilience Act, EU rules on the security and resilience of the IT that financial firms run on. for the data and the systems themselves, and lands with the Finnish supervisorfinanssivalvonta.fiThe Finnish Financial Supervisory Authority, which supervises insurers in Finland and applies the EU rules locally., who applies all of it at home. Solvency II alone, with the regulationeur-lex.europa.euCommission Delegated Regulation (EU) 2015/35, the detailed rules that fill in the Solvency II directive. that fills in its detail, is around a thousand pages of regulatory text. A core insurance system is three systems in one, a CRMen.wikipedia.orgCustomer relationship management: the customers, their contacts and the sales that lead to a policy., a policy management system and a claims management system, sharing every piece of data.

What the definition day set

Four things came out of the definition session. Security above all, because the platform holds every customer's personal and financial data. A codebase that AI tools can work in as they mature, which in practice means strict conventions and no clever surprises. A back office that guides the administrator through the work instead of expecting them to remember it. And a record of everything, every change by anyone, for internal audits and for the regulator.

Mapping the system showed the scale of it. Dozens of data models, each with its own screens. A long list of integrations with outside systems, from payments to vehicle registers. And more flows than anyone had counted, which turned out to be the most important finding of the whole project.

Two databases, one direction

Customer data lives in one PostgreSQLpostgresql.orgThe open source relational database the platform runs on, both the core and the public site. database that is off the public internet. That is where the back office works and where changes are made. The public site runs on its own database and never touches the core directly. When a customer signs in, through strong authenticationsuomi.fiSigning in with Finnish bank credentials or a mobile certificate, the level of identification insurance requires. with their bank credentials, the core opens a set of read-only viewspostgresql.orgThe Postgres extension that lets one database expose tables to another, here as read-only views scoped to one customer. into that one customer's data, and the site reads from those and nothing else.

A customer cannot write to the core at all. Anything they do, a new address, a claim, a change of cover, goes to the core as a messagepostgresql.orgPostgres' built-in notification channel, which the core listens on and turns into a process of its own., and the core handles it through its own flows with its own checks. If the public site were ever compromised, what an attacker could reach is one signed-in customer's own records, read only, and nothing they could change.

Screens from configuration

Dozens of models, each needing a list, a detail view and an edit form, most of them twice over, once for the back office and once for the customer. Writing those by hand would have eaten the schedule on its own. So the screens are generated on the fly from lightweight configuration files that say what each model is, which fields matter and who may see them. A new model means one new configuration, and its screens follow. The people writing the platform spend their time on the logic, and the screens stay consistent because no one draws them.

Everything is a process

The decision the rest of the platform rests on. When we mapped the flows, changing an email address turned out to be a process with a handful of steps. Enter the new address, send a verification, accept it, record the change. Handling a claim turned out to be a process with tens of steps, some automatic, some waiting on an outside system, some waiting on a person. Renewals, quotes, cancellations, payments, all the same shape, only longer or shorter.

So we built a process engine and put everything through it. A process is a list of steps. Steps are reusable, processes nest inside processes, and the screens a customer and an administrator see for a step come from the same view components, built from the fields that step needs. Automated steps move on by themselves. Integration steps wait for the answer. Steps that need a human stop and wait for one. Every step writes its own log entry and nothing is ever edited in place, so the audit trail the regulator asks for is simply what the engine produces while it works. Any flow in the system can be opened and read, step by step, by anyone allowed to see it.

Built on Rails

The platform is a Ruby on Railsrubyonrails.orgThe web framework BASED builds most of its systems on. 8 application. Hotwirehotwired.devRails' way of building fast interfaces by sending HTML over the wire instead of a JavaScript front end. carries the interface, so the screens are fast and light without a separate front-end stack, and Solid Queuegithub.comRails 8's built-in job queue, running on the database with nothing extra to operate. runs the background work, the automated steps and the integrations waiting on their answers. Boring choices on purpose. The interesting parts of this system are the process engine and the generated screens, and the framework's job is to stay out of their way.

Where it stands

The platform went live within the time given, which had been an optimistic estimate to begin with, and the reason is the two decisions above. Most of the system is generated or run by a small core we took the time to get right, and the rest is configuration. Adding a process or a model means writing the configuration and the steps, the screens and the logging come with them. The codebase holds to conventions strict enough that AI tools make useful changes in it without wearing the quality down.

That is the way we like to build. A small number of solid ideas, carried all the way through.