Insurance Framework

Time to Market, Modular, Reduction in Costs, Digital, Modernization etc. etc. lets face it I was part of these jargons and part of numerous programs that were conducted and deliver in my past life. Often, it all boiled down to did we meet our goals that we set out to begin with, and the answer for me was NO, yes I was able to deliver the final business outcome but not exactly what my business sponsor had expected.

Looking back at the lessons learned over the years, it often boiled down to two core aspects i.e.

• Architecture of the current system / software enabling or disabling the ability to - Time to Market, Modular, Modernize etc.

• Business Modeling implementation on the current system / software enabling or disabling the ability to - Time to Market, Reduction in Costs, Modernize etc.

And, thus Ignatica Framework was born!! not really, after plenty of cuts, burses and broken bones this java framework is matured to be robust production grade insurance framework that will give the technology team(s) to:

• Deliver business in days not months

• Is modular to a point where plans are isolated and run independently

• Is inexpensive to run as the developers only need to write three java class to build a full production code (module), runs on open source.

• Is 100% cloud agnostic.

• Is fully automated and reduces developer boiler fatigue (i.e. writing repetitive code like getters, setters, validations, json transformations etc.)

• and much more..

So, what is Ignatica Framework? Let me tell you what it is not first

• It is not a Out Of The Box (OOTB) insurance administration system that you can start using tomorrow.

• It is not a claim management, or policy administration with full UI and workflows etc.

• It is not a rules engine nor a plan configurator that can export some sort of magical sauce that you can plug into your legacy system.

This is a insurance technology framework written by engineers for engineers 100% ground up for Cloud technologies, to enable you to go to market with your own front end or UI's and your customer data powered by Ignatica Framework.

It comes with

• Java SDKs over 3000 Abstract Java Classes built for Insurance Industry,

• Fully managed Batch Architecture with 100% plan level isolation

• API Router / Configuration Server / Discovery Server full production ready servers that forms the background automation at runtime.

• Plan Engine / Data Engine full production ready servers that forms the core to create plans, publish plan, manage lookup data, extract data for analytics etc.

• Coverage (Online) & Batch (Offline) production ready core servers that you can extend using the SDK's to build your own set of modules.

• 100% coding free Java Templating for Mongo Document Management,

• 500+ API's to manage / create plans,

• 40+ sample modules for Life, Term Life, ILAS, ILAS Takaful (quote, bind, premium deposit, death claim, etc.),

• benefit definition and management with 100% flexibility

• (billing, Lapsation, Reinstatement etc.) batch that you can use or model your own modules,

• 100% Kubernetes, i.e. Cloud Agnostics with full docker images (build to deploy) to get full active-active across data centers, regions etc.

• 100% Jenkins pipeline based automation to build and deploy (launch Plan) that compiles modules and deploy individual Online / Offline capabilities per plan, making it the only framework in the market that have 100% isolation between plan(s).

• customized dockers for live monitoring and a lot more capabilities...

Inspiration 

Living in Hong Kong, our daily discussions and great ideas where born out of Cha chan teng’s (Cha chaan teng) where standard raw material like rice, tofu, noodles etc. (Java ENUMS & Constants) is used to create over 100+ types of dishes (Templates & Abstracts) with levels of spices (Environment Variables, SDK Reflections) and if that is not enough every table in the shop (Modules) has a standard set of spices (Boiler Plates, Beans) to alter the outcome of the dish that is placed in front of the consumer in record amount of time, i.e. in less than 15 min or else the shop looses business.

This was fascinating to me, why can I not have a framework that essentially does the same, so I had to look at both sides of the coin, i.e. the necessary raw material for the builders and modeling the business outcomes that are predictable and yet diverse.

Business

These are some of the view(s) that the team agreed upon, over countless hours of whiteboarding on how to engineer the business side of the coin. This is not the exhaustive list of areas that we had to remodel or rethink from the insurance platforms that are available in the market.

Disclaimer: The following are my views and not a debate between right vs wrong, or sane vs insane, in order for me to make a call on the engineering aspect there is a decision to make, and this is what we landed for the long term gains of ability to deliver products in weeks and not month by using off the shelf developers or back-office teams without needing months of training and onboarding processes.

Business Modeling

After working in the main stream industry / corporates / banks, it was time for me to do something that I was passionate about, and that is to build a platform that would help clients to build products faster (with few clicks), cheaper (total cost for time to market); and thus as co-founder of Ignatica Ltd, I built the platform from Architecture / JAVA SDK to API Engineering. The following blog(s) are a inside peek of the technology / architecture and the amazing work I and my team did to bring this platform to life.

The Architecture

Ms. Eva is a valued customer for the insurer, and the insurer wants to offer incentives or discounts irrespective of the insurance plans Ms. Eva has purchased.

Philosophy: This should not prohibit the insurer from offering Ms. Eva incentives or discounts.

Agreement: The top-level holder that is capable of handling nonfinancial or financial transitions, specific to Agreement

Ms. Eva decides to buy an insurance plan at a point in time with tailored coverages / benefits unique to her

Philosophy: A point in time purchase is a component of a plan that has specific coverages / benefits.

Component: This level provides the view of “Point-In-Time” purchases / contracts (traditional Policy) and accounting that now can serve as a component level money / points movement. This also provides the ability to now bill and collect single payments across components and offer claims compensation across components to better service Ms. Eva’s needs. This also provides the ability to pay out Premiums from Dividends across different Components.

Ms. Eva has an unfortunate event and must claim from one of her “point-in-time” purchases.

Philosophy: Coverage level accounts are Cash Books i.e., Premium A/c., Fund A/c’s, Claim A/c, Tax A/c. General A/c. etc. so it should be viable for the provide to pull out money from all the applicable components to meet Ms. Eva’s unfortunate event.

Coverage: This level is the actual execution of plan parameters, i.e., Insured Risk Configurations, Fund Portfolio etc. Plan Microservices are configured and executed at this level.

Ms. Eva decides to add a new coverage to her existing component (point-in-time) with different plan options.

Philosophy: Component(s) are container(s) of coverage’s (traditionally Riders that are products), however each of the coverage(s) within a component runs independently that provides greater flexibility. Besides multiple coverages under the same Component (traditionally Group Policies) allows a better customer experience given that each coverage under the same Component can be from different plans (risks, accounting, etc.), and can have different insured / beneficiary.

Plan Modeling

"A plan is a set of configurations and values that defines the product that is sold in the market by the insurer".

A Plan forms the basis of the core platform, where individual plans are built and executed independently in the platform as part of the Publish automation process.

Coverage Modeling

Coverage is the backbone of that defines the post sales activities, cash flows and business service events as stipulated in the legal binding between a insurance provider and a buyer etc.

Finance & Non finance Movement

As MongDB is not a RDBMS, I had to make use of the semi-structure data pattern to our advantage;

• we do not distinguish between types of accounts i.e.

• Financial or Money Accounts (TAX, PREMIUM, CLAIM etc.)

• Date Accounts (NEXT BILLING DATE, PAID TO DATE etc.)

• Fund Unit Accounts (FUND, TOPUP, BUY, SELL etc.)

• Crypto Accounts (COINS)

• Consumption Accounts (POINTS)

• Benefit Allocation Accounts

• we do a rolling update accounting to take the balance from the previous, add or subtract the current transaction and create new document. This way the last active document (Mongo Document) reflects the current balance without need to go through a daily update.

By leveling the movements financial, or non financial it is easy to trace top to bottom or bottom to top movements, providing auditability and traceability.

Top → Bottom

Modules that will require movement of data (financial or non financial) from external systems into the platform:

example: Premium Paid, Fund Top Up Purchased etc.

Rollup Agreement Level Accounts → Distribute To Agreement Component Level Accounts → Place at coverage level accounts

Bottom → Top

Modules that will require movement of data (financial or non financial) from internal to external

example: Claims, Interest Paid Out etc.

Rollup Coverage Level accounts → Rollup Agreement Component Level Accounts → Place at the Agreement Level accounts - for claims or withdrawals where final destination is external systems.

Rollup coverage Level accounts → Rollup Agreement Component Level Accounts - for interest bearing products.

Now, these are very few views on how I see the future insurance world that will have the flexibility and the agility that is required to launch products in days and not month

Engineering

But, that also meant I had to look at the Technical side of the coin, and that means, enabling the Engineering, QA, DevOps (Release Management), Production Support, Infrastructure etc. teams to have a solid framework that they can use to support the rapid go to market. Keeping in mind, the human aspects, i.e.

• a developers needs to be writing production code in one week of training

• a QA team should not be running more than 100 test cases (modular)

• the production support can scale up / scale down without shutting down services

• stop boiler code fatigue for Java Developers, so all the Rest End-Point, Controllers, Json to Object Mappers are all built in the framework, the developers just have to define 3 classes and push the code to QA -> Production.

• data structures should be agnostics to the underline database, i.e. all the data model is PoJo based, so in the same Mongo Collection you can manage multiple data modules. So, no upgrades to databases, no backward combability tests, restoring database is just a matter of uploading the json data.

• active-active across regions

• etc. etc.

As we can see, building a robust platform with future proofing requires a totally different approach than a conventional monolithic application design. There is lot more of the engineering side that I have implemented into the design & build, however without understanding the business building a complex platform is not feasible.