#customers #backend

Modern insurance platforms: Meet all requirements with SCIP

Over the years, we here at sum.cumo have accumulated plenty of experience in determining which capabilities and components are necessary when developing package solutions for the insurance industry. One factor that's critical for success in digital sales and administration of insurance products is the insurance platform. We're pursuing SCIP as a model of a fully automated insurance platform that fulfills the requirements and serves the interests of all parties involved. In the following, we'd like to explain those interests in more detail and from our perspective.

The six types of requirements

The backbone of any future-proof, scalable insurance platform is a modern technology stack. In our last article, entitled "Just the Right Size", we already detailed how SCIP serves this need as a cloud-based and hosted platform with a full-featured API and separate front and back ends.

However, the practical implementation of an insurance back office (i.e. the module that administrators work with daily) needs to serve the needs of external users (such as customers, brokers, auditors and other service providers) in addition to those of internal users (such as administrators, marketing experts and actuaries). In other words, the requirements that the system must satisfy come from every department of a digital insurance company.

Bildschirmfoto 2020-01-22 um 11.58.46.png

1. Self-service through automated process chains

Scaling up an insurance technology company always involves a massive increase in the number of inquiries and modification requests received from customers. At the same time, customers nowadays expect their problems to be solved immediately. How can we reconcile this? Companies like Netflix and Amazon show us how. Young target groups want to be able to solve their problems themselves – without having to go to the trouble of contacting company representatives. Thus the key to shifting the burden away from administration lies in providing self-service options for standard processes.

Bildschirmfoto 2020-02-03 um 11.24.45.png

In SCIP, we've already automated such standard processes. Take contract amendments, for example: Our customers are able to generate them directly from the customer portal and receive updates in real time about how amendments will affect their premiums. Once they accept, the SCIP back end executes the necessary procedures fully automatically and then provides the customer's new, updated policy. Administration costs: zero.
SCIP handles new applications and policy issuance, cancellations, and claims notifications (including booking initial reserves) the same way. The roadmap for SCIP also envisions automated claims processing, where damages are calculated automatically by external partners in order to immediately generate an offer for the customer to confirm via the customer portal.

2. Efficient manual processing through user-centric design principles

In other words, someday administrators will be required only to handle complex business transactions. This means that it will remain important to keep the use of the platform as simple as possible for these users, too. How to accomplish this? First of all, users have to be able to judge which processes are important and urgent. That's why we intend to put considerable development resources into the task and notification management of SCIP's back end in order for it to provide administrators with even better support in directing their attention where it's needed. Secondly, processing complex business transactions has to be able to proceed as quickly and as simply as possible. That's why we relied on established design principles and patterns, such as those of Google's Material UI (well known from apps such as Google Mail, Google Maps, etc.), in creating the SCIP back end. This helps users get used to a new system; it eases the changeover process. In addition, we identify the points in every process where it can be made slimmer and faster. For example, soon full-text search will become the main entry point for finding contracts, persons, claims and even the associated bookings and invoices.

3. Focus through integration of external applications

Today's insurance companies need to see themselves as platforms that provide the core processes while working the entire range of the market in order to cherry-pick the best-in-class solutions. This is the only way for them to continue developing their platforms cost-effectively and keep up with the speed of the market. A high-performance interface is the prerequisite.
SCIP provides a full-featured interface that fulfills the GraphQL standard developed by Facebook. This means that every process of the insurance back office can be implemented by external systems, allowing savings throughout the entire value creation chain. For example, self-learning underwriting engines can be integrated that perform risk assessments optimized using machine learning techniques. This requires that product models be flexible.

4. E-commerce as an example for flexible product models

The insurance business has a lot to learn from the fast-moving e-commerce sector, where introducing a new product in an online shop normally takes just a few minutes. Introducing a new insurance product usually takes weeks or even months. That's why our SCIP back office will be based on a flexible product model. What exactly does that mean? Let's say we want to introduce a "lite" version of an existing car insurance product. To do this, we create a clone of the existing product in the product configuration tool and then modify the premium parameters and acceptance guidelines. The system automatically performs the necessary adjustments (such as documentation chain validation, documents, invoicing, etc.). This will permit new versions of products to be implemented in just a few days.

5. Separation of data collection and analysis

The data of the insurance back office is of great interest to various user groups, including the actuarial, marketing, and business intelligence departments, to name a few. Here, too, keeping focus is an important requirement for success; an insurance platform integrates analysis tools, but does not provide them itself. From this, two basic requirements follow:

  1. All data is available at any time via an interface.
  2. All data can be exported over any interval.

SCIP allows any inventory data to be exported in CSV format to external systems at any time. Beyond that, it's easy to forget the necessity of analyzing user behavior in the back office. The SCIP back office is equipped with the latest analysis software from WebTrekk and Hotjar. This enables us to track (encrypted and anonymized) which procedures are performed particularly frequently and thus identify opportunities for optimization – which translate into immediate reductions in administration costs.

6. Automation? Yes! But only within the boundaries of regulatory provisions

In addition to general security regulations on digital solutions (such as the GDPR), insurance providers are subject to significantly more stringent requirements. In our experience, there are three different types of requirements: transparency, views & rights, and control mechanisms.

Bildschirmfoto 2020-01-22 um 11.59.05.png

The SCIP back office is built on a fully configurable system of roles and rights that permits simple administration and restriction of user access rights. Any actions performed on contracts or claims objects are recorded, producing a transparent and auditable contract history. In the age of open ecosystems, total transparency also requires tracking which third-party services communicated what to the system when. Thus the SCIP back office saves every incoming or outgoing interface message. In addition, numerous security mechanisms are implemented in SCIP, such as individual payout limits for each employee, spot checks of payouts, and others.

Summary

As we've shown, there are all manner of different types of requirements that a modern insurance back office has to fulfill. The situation is made more difficult by the fact that these requirements can sometimes conflict with each other (such as auditable, manual changes vs. full automation). In addition, it's hard to prioritize across different areas, because everything seems equally important.
How to solve this dilemma? In SCIP, we provide a flexible solution that can be used both as middleware for focusing on sales and service processes and as a modern inventory tracking system. We're cooperating with various different partners to rapidly continue developing SCIP. This ensures that every partner has the opportunity to set their own development focus without neglecting the other areas.