We’ve said it before and we’ll say it again: insurance is complex. With its wide range of diverse processes, integrations, legal and regulatory requirements, pricing considerations and reporting obligations, building an insurance product – let alone an insurance platform – can be very challenging.

But that’s exactly what we did at Qover: we created a modular, configurable and scalable insurance platform that can be embedded with minimal effort.

READ MORE: How being cloud-native strengthens our orchestration platform →

Our platform allows us, through configuration only, to create a set of APIs that partners can then integrate into their ecosystem – activating user acquisition funnels, a policy administration system, claims, data and more.

This means we can configure any product for any insurer in any country – centralising all the related legal documentation and communications – to launch an insurance program in a matter of weeks rather than months.

To show us exactly how that works, we asked Qover’s tech team to walk us through an example setup: Louise Davaux, Product Owner, demos our configuration in video form; while Gino Heyman, Lead Functional Architect, takes a deeper dive in this blog post by explaining 6 key capabilities of Qover’s orchestration platform.

‍

‍

1. Configuring an insurance product

The first step when launching an insurance program (or upgrading an existing one) is defining an insurance product in our system, or a product configuration that allows us to control the entire platform and perform the following functions:

• Define the coverages
• Determine the price computation of every policy instance throughout its lifetime
• Define (aspects of) the products’ API endpoints
• Specify validation and lifecycle business rules
• Enable or disable features

We embrace ‘resource orientation’ to design simple, consistent and easy-to-use APIs: every entity in our platform is considered a resource that is securely accessible via a RESTful API. There are two sides to our API: a static part that defines our system’s main resources such as master policies and risk; and a dynamic part that is controlled by the configured subject definition and product features.

The subject definition defines the subject of the policies and risk item endpoints, while features can introduce whole new endpoints (e.g. an endpoint to fetch the green card for a vehicle – more on that later).

First, let’s start with the coverages.

Bundling coverages into packages

Coverages are at the core of any insurance product. We can define one or more types of coverage within a single product configuration. 

Each coverage:

• is linked to an insurer, allowing us to combine coverages from different insurers into a single package/policy.
• has its own pricing configuration.
• can define what additional/specific risk information, what we call the subject, is captured and reflected in the API endpoints.
• can have multiple variants that can override/extend the coverage configuration.

We can, for example, define the Motor Own Damage (MOD), Motor Third Party Liability (MTPL) and assistance coverages shown below.

MOD and MTPL are covered by the insurer Amazing Insurance, while assistance is provided by Shield Assistance. MOD also comes in two variants – Premium and Standard – with different limits (at a different cost).

‍

‍

In our API, the coverages section of our sample product configuration would look something like this:

‍

Pricing is a complex subject and can be set up in various ways. To get a glimpse of what’s possible, our sample configuration includes:

• a simple hard-coded value of 2500/year for assistance;
• an offset-based embedded lookup that computes a price based on the vehicle’s type and insured value for MTPL and MOD;
• MOD coverage with a premium variant that overrides the MOD default values.

Pricing is configured as expressions that are evaluated against the risk item. The configuration snippet above omitted the pricing expression for readability.

‍

‍

Coverages are not exposed as such, though; they’re bundled into packages. Every policy requires a package selection that will define the applicable coverages and their variants.

For example, a fleet owner could select the ‘Standard’ package for some vehicles and the ‘Premium’ package for others. The Standard package includes MTPL and the standard variant of MOD, while the Premium package includes MTPL, as well as the premium variant of MOD and roadside assistance.

‍

The packages section of our sample product configuration:

‍

Defining subjects

What is actually insured – or what we call the subject – depends on the product or coverages. This could be a person, property, event, vehicle, purchase, etc.

To offer this flexibility, our platform allows us to define the information we need to capture per product and/or coverage. We do this by leveraging a customised JSON schema definition.

For example, we can define the following schema for our automotive sample product:

‍

Note that this is a simplified version; our platform also supports:

• Dynamic variant selection: when more than one variant is configured, the customer or partner must select one, depending on whether the coverage is offered as an add-on or is a native component of the company’s product.
• Optional coverages: additional coverages (with one or more variants) can be selected per policy if desired.
• Internationalisation: product configuration includes defining the target countries and languages. Every aspect of the product configuration can also be modified/overridden per country. For example, if taxes differ in France, we can change them; if certain coverage variants aren’t available in some countries, we can remove them from the package.
• Automatic API generation: Based on the product configuration, we could also automatically generate API documentation to aid our partners in implementation.

Discover our APIs and how to integrate them →

2. Creating a master policy

We talked about product configurations and policies for the sake of simplicity. Our platform also supports master policies.

Master policies group a set of risk items (as a dynamic risk) that can change over time. Fleets are a great example of this: a single master policy (fleet) can have thousands of risk items (vehicles) that can be continuously added, updated or removed using our API.

Another example would be a master policy for a fintech or bank where each risk item corresponds with an insured customer with a certain subscription.

‍

3. Adding a risk item

Now that we’ve set up the product, master policy and defined the subject, we’re ready to add risk items to their insurance policy.

This simple API call requires minimal data input.

Following the same example, all it takes to add a vehicle to a master policy is:

‍

When receiving this request to create a risk item, our system will create the risk item to store all relevant data, including computed premium values. Since we enabled certain features, our platform will also:

• generate a policy schedule document and email it to the policyholder.
• generate a green card document – proof of auto insurance that you need to have in your car – and email it to the driver or policyholder. 
• automatically notify the appropriate authorities about the vehicle’s MTPL coverage (depending on the country) .
• include links to resources from enabled features in the response; in this case _link.greenCard and  _link.policySchedule.

Here’s the response from the create request in JSON form:

‍

Pricing

Each time a risk item is created or updated, the premium values are (re)computed.

This process takes several things into account, such as:

• The pricing model. We support a subscription model, where the total policy premium is known up front, and a pay-per-use model where premiums are computed during reporting.
• A premium expression that calculates the base premium per coverage. This expression can take various policy properties into account, such as the subject, configured lookup tables with pricing factors, etc.
• Effective periods. A policy update that changes the premium can take effect at any point in time, even retroactively. This means that when computing the new premium we only need to take into account the relevant portion of the premium of (previous) versions.
• Taxes and discounts. Tax rates and types differ per country, which our platform also takes into account when calculating the premium.

In the example above, the fields package.coverages.mtpl.premium and package.coverages.mod.premium represent the premium values at a coverage level, computed as per the above configuration. The premium field in the root is the sum of all sub-premiums.

‍

4. Editing a risk item

How risk items are updated depends on the master policy’s product configuration. Most policies require endorsements (possibly with approvals, etc.), while others are more flexible or dynamic by nature.

A master policy for a fleet of vehicles is one such example: vehicles can be added, updated and removed as needed, as long as it’s within the contractual bounds of the master policy.

Let’s say the fleet owner decides to upgrade the package of the vehicle that was added above starting on August 1. In that case, all that’s needed is the following request:

‍

When receiving this request, our system will create a new version of the risk item to reflect the requested changes, including updated premium values. All enabled features will also be invoked and result in additional (typically asynchronous) actions.

In this example:

• The policy schedule document will be regenerated and emailed to the policyholder.
• The green card feature will result in a no-op, since no relevant changes were detected (MTPL hasn’t changed). Otherwise a new green card would be sent out.
• The relevant authorities would be contacted to update their records if needed.

The request will return a second version of the risk item after updating the package from ‘Standard’ to ‘Premium’:

‍

Getting the versions

Each time a policy is created, updated, endorsed, cancelled or rescinded, our system records a new, immutable version.

This way, we have full transparency on the entire lifecycle of any given policy and our claims team can easily trace it from start to end (stay tuned for more on claims management in an upcoming blog post).

Here's a sample request to fetch all versions of an existing risk item:

‍

5. Managing policy lifecycles

Companies often think that once a policy is created, the hard work is done – but lifecycle management shouldn’t be underestimated, particularly when it comes to offering insurance in a B2C model.

The main lifecycle aspect of a master policy is billing between Qover and the partner, but B2C policies involve contract renewals, cancellations, amendments, endorsements and more.

Luckily, much of this is embedded in our platform:

• API and user experience support to optimise your operating model for customer support
• Policy administration for amendments and renewals
• Billing & collection
• Management of unpaid invoices
• Registered letters and register emails
• Cancellation process and local rules

‍

6. Enabling additional features

The scalability of our platform is reflected in its features. Features are modular building blocks and can be generic (applicable for all/most policies) or specific to a particular line of business.

As previously mentioned we can enable certain features that affect the generic platform in two ways:

• Triggering additional actions/subprocesses, usually asynchronously by ‘hooking into’ the main policy process
• Extending the generic API with specific endpoints. The green card feature, for example, adds a /green-card endpoint to fetch the generated document.

They can define API endpoints and/or integrate into the main policy process, either synchronously or asynchronously.

Some examples include:

• Generating documents: a generic feature that allows us to configure documents (like the policy schedule or terms & conditions for any country) that are (re)generated as needed.
• Generating green cards: we can automatically generate and send out a green card to drivers when they rent a car from a covered fleet or purchase insurance for their own vehicle. In addition to this, the feature also extends the API with a /green-card endpoint that allows for deeper integrations.
• Reporting to authorities: This feature ensures that mandatory MTPL coverages are reported to local authorities. This can be accomplished through an API integration or an exchange of data files, depending on the country.
• Operational reporting: There are two main sides to reporting: analysing the performance of your insurance program and handling the operational side between partners and insurers. Our platform can automate reporting and streamline communications between all stakeholders – i.e. the bordereau, invoices, etc.
• Deliveries: Some resources in our system are entities that need to be ‘delivered’. For example, a bordereau report, a generated policy schedule or green card PDF can all be configured to be emailed, transmitted via sFTP or dropped in a storage bucket.

‍

‍

Conclusion

Qover’s highly flexible platform supports any insurance combination: different insurers per country, different coverages by countries, etc. We centralise and configure all of this to cut implementation time from 12-18 months to as little as three weeks. 

We can switch on or off any part of our modular platform to tailor it to your needs – whether that’s a full set of features or overlaying our tech on top of your existing stack.

What’s more, our platform is constantly evolving – from developing new features to adding new countries, our team at Qover is making it even easier for companies to offer the best insurance experience for their customers across Europe.

‍

To dive even deeper into Qover’s policies API, check out our full documentation or request a demo from one of our experts.

‍