Emerging technologies represent an opportunity when designing accident and health insurance products, processes, and platforms. Newer technologies like blockchain, heightened consumer expectations for anytime anywhere services, and the impact of social media translate to a growing challenge (and opportunity) for insurers. This especially holds true for complex products like accident and health (A&H) lines of business.
Approaching product design for A&H with a risk management perspective as the cornerstone enables insurers to define a product process as a series of discrete tasks. Rather than developing a software platform as a single application, tackling development as a series of small processes (i.e. microservices) allows insurers to address each process component with the most appropriate technologies.
This segmented approach enables the optimum process with capabilities such as process automation, rules-based functions, or advanced analytics – just to name a few. When the right technologies are applied to each discrete task, benefits can range from underwriting best practices, to risk avoidance from tariffs, regulatory and cyber, all while enabling a streamlined and personalized customer experience. But achieving these benefits requires a well thought out plan and quality execution.
Adopting a product framework
A cross-discipline team that includes subject matter experts representing marketing, underwriting, compliance, claims, operations, IT, etc. can collaborate to develop a product framework, an asset that will continue to facilitate new product innovation in the future. Key benefits for insurers adopting a framework approach is the resulting understanding of the commonality between products and geographies within a corporate structure, and the establishment of a common set of business processes, reporting and other functions. When commonality is identified and built into the framework infrastructure, rapid implementation of future products is enabled.
Product definition in a framework includes product settings, lifecycle schema, fields, coverages, benefits, validations, tax and tariff tables, premium calculations etc. Product and coverage templates can be created to define generic building blocks for quick products launches. Comprehensive product template(s) can be configured and used as building blocks to enable re-use and control consistency across products and regions. Here are some common framework elements (i.e. finite tasks) that can be addressed with microservices:
Monitoring processes (aggregates / Premium etc)
Common attributes for common entities (clients/insured’s, Brokers, Agents, users etc)
Common elements of a Product definition
Common elements of a Rating architecture
Fees and taxes
Exchange rate processing
Given that Insurer systems are a common target for cyber-attacks, cybersecurity and consumer data privacy concerns represent a critical exposure that must be addressed in any product framework design.
As insurers look to emerging technologies, considering a microservices architecture versus the traditional monolithic architecture can enable the best use of new technologies, while extending the capabilities and lifespan of current technology investments. A microservices architecture coupled with a well-defined product framework in place will give insurers a strong arsenal to enable innovation, automation, and a competitive edge.
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|CookieLawInfoConsent||1 year||Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_145775225_1||1 minute||Set by Google to distinguish users.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|_hjAbsoluteSessionInProgress||30 minutes||Hotjar sets this cookie to detect the first pageview session of a user. This is a True/False flag set by the cookie.|
|_hjFirstSeen||30 minutes||Hotjar sets this cookie to identify a new user’s first session. It stores a true/false value, indicating whether it was the first time Hotjar saw this user.|
|_hjIncludedInPageviewSample||2 minutes||Hotjar sets this cookie to know whether a user is included in the data sampling defined by the site's pageview limit.|
|_hjIncludedInSessionSample||2 minutes||Hotjar sets this cookie to know whether a user is included in the data sampling defined by the site's daily session limit.|
|_hjTLDTest||session||To determine the most generic cookie path that has to be used instead of the page hostname, Hotjar sets the _hjTLDTest cookie to store different URL substring alternatives until it fails.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt.innertube::nextId||never||This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.|
|yt.innertube::requests||never||This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.|
|_hjSession_2863287||30 minutes||No description|
|_hjSessionUser_2863287||1 year||No description|