The insurance underwriting team is required to apply new business rules, change existing ones, and make decisions based on underwriting business rules (aka the rule book) without the involvement of software development (or IT).

The myth is that by adopting a business rules management system (BRMS), or the next evolution of this category of product called Decision Management Suite (DMS), the team will be empowered to make better decisions by managing and automating business rules.

However, here is the ugly truth: these categories of products (e.g. BRMS, DMS) are not going to do the job alone!

Here is a thread of discussion in Gartner's Peer Community by a CXO of an insurance group, listing what is needed:

To make this work, meaning the underwriting team becomes more self-sufficient in business rules management, they need to easily do all the 3 categories of activities:

  • Pre-decisioning work
  • Decisioning work
  • Post-decisioning work

All of this should happen inside the underwriting team without hard-coding any of the requirements into systems, microservices, etc., or requiring deep technical knowledge. When one of them is hard-coded or relies heavily on the software development team or IT, then it becomes a blocker to the underwriting process; consequently, the underwriting team cannot accomplish the job without draining the development team's resources and lots of administration and manual tasks.

So, it is becoming essential to enable the responsible team to become self-sufficient for all of the above steps end-to-end, or it does not bring value (to accelerate the underwriting work) if you address just one part of it. This is where the current state of the market for DMS and BRMS falls into cracks – they just cannot help business agility.

Let's take a detailed look at what you need to have in place to enable the underwriting team to do their job accurately, with consistent quality, and less administrative and manual work, and without draining your software development team and IT resources.

The pre-decisioning work – data work

Underwriting decisions are not made in a vacuum, they require context. Context is data that provides a set of rules for execution. Data is not always easily accessible, and more often than not is not always in one place.

In underwriting process there are always the need to plug into a new set of data; they need to include a set of fields or information or connect to new on-prem or cloud systems. This dynamic of the work makes it very hard to predict every single field of data for all the cases upfront. Not only that, but also the requirements of underwriting decisions always evolving based on cases.

This is the true nature of the underwriting; it’s different case by case. Especially on business insurance products, and still, this is primarily relevant to consumer products when it comes to flexible insurance or highly personalized and customizable policies.

Therefore, the below capabilities are needed without using a coding approach:

  1. Data capability: easy-to-use data connection, acquisition, and query building
  2. Data processing: enriching and plumbing systems, and information from multiple data sources
  3. Data publishing: allowing the consumer (i.e. decision model) to simply and securely use the prepared data for decision-making by executing rules against it

Decisioning work – manual or automated decisioning

At any stage of the process (e.g. pre-bind, quote-to-bind, claim and etc.), the most important task of underwriting is to determine the risk for a case, decide whether or not the risk is within the business's risk appetite, and then de-risk it based on a series of guidelines (aka business rule book).

This process can be done manually by understanding the data (from the previous step), looking into the data either visually (e.g., charts), or analyzing it (filter, group, highlight etc) and comparing it against the specific case in the underwriting.

Book a Custom Demo

First or last name is too short





Or, it can be automated (or semi-automated) by modeling business rules and logic for execution without requiring programming and coding (e.g. less involvement of software development and IT teams).

Your underwriting teams need to be able to:

  1. Manage business rules by adding, deleting, and modifying them with a full audit trail Additionally, there is a need for multiple rule modeling techniques that can be chosen based on preferences and the rules' complexities
  2. Formulate some calculations for risk analysis, classification etc. Imagine something like Excel formulas (but not in Excel) and incorporated and integrated with your business rules
  3. Define the steps of the decision-making workflow that needs to be done. For instance, a decision might have multiple steps e.g. calculate this risk first based on some inputs, run these rules next and then pass the outcomes to another set of rules to finalize the results. This is called multistep decisioning.

Post-decisioning work

Once the rules are in place, tested and your team is happy, what should you be doing next?

Well, you need to deploy the decision somewhere, integrate it into multiple systems and processes, and make sure you can consistently monitor their execution (runtime) behaviors.

Also, while doing these, you are going to need to share your decision-ready data, rules, and decision workflow with your team members in a systematic and structured manner. Allowing them to copy and clone them for their own work and cases, or let them modify rules, data part, and any other parts of the work, and create a new revision for incorporating conditions and circumstances.

Subsequent to those changes, you will need to have a fully automated testing system in place to make sure you have not broken associated behaviors and not regressed the quality of the decisions and rules unintentionally.

All of these are translated into below capabilities you need to look for:

  1. Allowing multiple integration options of the underwriting decisions into your infrastructure: in-proc for both client and server-side as well as REST API service model
  2. Single-click deployment allowing your non-technical team to deploy decisions-as-a-service with an ease to cloud and on-prem
  3. Automated deployment and testing in a CICD pipeline
  4. Test cases and scenario development and execution
  5. Visual debugging and simulation capability
  6. A standard centralized repository for all the artifacts your team is building for the entire project
  7. A simple way of scaling when your processing volume grows

Conclusion

In short, the current state of decision management and business rules management do not serve the underwriting teams in insurance to become less reliant on the software development team and IT. to empower them and make them more productive, they need more than just managing business rules without relying on software development or IT teams. To achieve that, you need to look at the whole process, not just managing the business rules.

Unlike our unified and integrated, end-to-end decision management suite, most of the solutions in the market today only focus on the “Decide” stage of part the process – including open-source solutions such as DROOLS or other commercial products.

Covering the requirements for the end-to-end process in an integrated and unified approach is the only way to ensure successful adoption in the underwriting teams without draining highly skilled development and IT resources. This does not necessarily mean that the underwriting team does it all.

However, it means the responsible team does not rely on a coding approach and the traditional DevOps operation. The team should be able to do it all without requiring deep technical background and knowledge; consequently, they will have no (or very little) reliance on the software development team and IT resources.

Last updated September 4th, 2023 at 04:01 pm, Published August 30th, 2023 at 04:01 pm