1 / 24

Fast-Tracking your Insurance MI

Fast-Tracking your Insurance MI. Presented by Nico Kichenbrand. Agenda. Components of an insurance MI solution A typical insurance MI project Experienced gained / lessons learnt New fast tracking approach.

michealgomez
Download Presentation

Fast-Tracking your Insurance MI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fast-Tracking your Insurance MI Presented by Nico Kichenbrand

  2. Agenda • Components of an insurance MI solution • A typical insurance MI project • Experienced gained / lessons learnt • New fast tracking approach Let’s treat this session as a workshop – feel free to ask questions & share your experiences or needs

  3. Our insurance MI solution today

  4. What we deliver today… • What is normally included in an insurance MI application? • Data extraction & error handling • Premium analysis • Claims analysis • Loss ratios • Triangulations • Standard set of reports • Audit & reconciliation reports • Excel Dashboards • Menus • Automated updates

  5. What does a typical insurance MI project look like?

  6. Our experience so far … • What does a typical insurance MI project looks like? • Two different data sources, one for premiums and the second for claims coming from one or more backend providers • System specific data sources requiring custom developed data extraction routines • Customer specific measures, calculations, naming conventions and business rules • Some commonality, but some unique LOB structures • Potentially a customer specific earnings model • Multiple Calendars / Offset calendars / Binders / Varying policy terms • Customer specific features and functions (e.g binders, complaints, currency, payments, receipts)

  7. What have we learnt from these projects?

  8. What have we learnt … • Lesson learnt from insurance MI projects • Dealing with one or more 3rd parties can be very time consuming • Infrastructure • Premium data • Claims data • Customers may have multiple source systems with multiple providers • Issues with the source files which results in numerous iterations • Incomplete (missing key values, e.g effective date) • Inconsistent data (e.g text values in date fields) • Data errors (24% average rejection rate) • Poor integration (e.g claims for non-existing policies)

  9. What have we learnt … • Lesson learnt from insurance MI projects • Customer specific needs force design changes • Affects load process, DB design, cube design and reports • Sensitive data gets included in the source • Customer name, address, postcode, email, phone number, etc • Data reconciliation process difficult and time consuming • Normally 3 sources of reference • The system • The extract we get • The user’s Excel model • Policy management system and claims system often different providers • EDI a “law” onto its own

  10. What have we learnt … • Lesson learnt from insurance MI projects • Product structures can be complicated • Single LOB with multiple attributes • Multi LOB with the same attributes across all LOBs • Multi LOB with unique attributes per LOB • Multi LOB hierarchy • Multiple products / Multiple risks / Multiple insurers • Many products could contain the same risk • Many risks can be associated with the same product • Each risk can be underwritten by multiple insurers • Each insurer can have a share in multiple risks

  11. What we have learnt … • There may be more than one earnings model • Our standard model • Earn at a transaction level • Combination of policy inception date (NEW), policy start date (REN), Effective date (MTA / REIN / CAN / LAP) and Accident Date (Claims) drive a daily earnings model for the term of the policy • Earnings aggregation as changes are applied over time • Potential models • Earn everything within the original policy term, not over 12 months from effective date • Seasonal earning model, i.e earn everything on the inception date

  12. What we have learnt … Everyone likes the idea of predictive analysis BUT Any form of data mining and machine learning is only as good as the quality of the sample you use. (and then you have to figure out what it means)

  13. What can we do to fast track and enhance your insurance MI solution?

  14. I need your feedback … • From here on I am discussing the things we are working on now and for the next 6-12 months. • Our key focus is to : • Speed up and simplify the initial rollout • Create a configurable platform • Add value to your data • Sort out the infrastructure • Let us know what you think… • Do you agree with them? • Do you believe there is a better way to achieve this? • Do you see value in what we are doing? • Where is the highest value for you? • Are we missing something?

  15. What can we do to fast track this… • Have one database design for all customers and levels of complexity • Customer specific naming conventions / analysis fields • PSD Calendar / As At Calendar / Binder Periods • Single v Multiple lines of business • Extend the database design to handle all the different subject areas • Quotes • Premiums & Claims • Multiple LOBs • Financial Analysis (Payments & Receipts) • Multi-Currency • Complaints / 3rd Party data

  16. What can we do to fast track this… • Provide a standard data template per subject area / LOB • Excel template per subject area (Premiums / Claims / Quotes / …) • Standard load routines (User defined mapping of attributes / names) • Error handling profiled ito key data v attribute data • Field level feedback on any errors found • Efficient and automatic error recycling • Highlight errors in the source data and track them • Customer can correct errors in the source data • System will generate a full audit of all corrections made in the source • Enables optimum rollout and enables all system corrections to be done offline and in one go • Simplifies the automation of the data loading process

  17. What can we do to fast track this… • More sophisticated reconciliation tools • Inclusion of all key information in the source data • Full data tracking through load process • Full recon reporting by YOA from source > DB > cube (including record counts, quote, policy, claim counts, written and earned values) • Full auditability from the cube to the source per policy / claim • Support 3rd party data providers through web services connector • Reference Data (Currency, Vehicle details) • GIS Data (Flooding, Accidents) • Profile Data (Experian, Lexus Nexus)

  18. What can we do to fast track this… • Supply data sets in the format required by the consumer • Customer specific extracts (PowerBI, Excel, CSV, etc) • 3rd party extracts (Experian) • Statistical analysis extracts (Emblem) • Machine learning extracts (Azure) • Built-in support for regulatory reporting • Include all the required measures and ratios • Store transaction level detail • Develop standard regulatory reports • GDPR Support • Support for dynamic data encryption

  19. What can we do to fast track this… • Add support for value added analysis • KPI analysis • Exception based analysis • Claims estimations / ultimate loss ratios • Data profiling • Centrally maintain all the business logic • Allow tools of choice without replicating the logic • Ad-Hoc Analysis in Excel • Auto synching ReportStudio and Excel PivotTables • Regulatory reporting in ReportStudio • Complex precision formatting reports

  20. What can we do to fast track this… • Offer a multi-tenanted hosted platform • Secure hosted platform • All required infrastructure and software in place • Automatic backups / Disaster recover plan • Sophisticated data collection process (on premise database) • Platform optimised for value added processing • Multi-tenancy ensures • Software updates apply to everyone • Optimisations benefits all • New value add processes available to all • New functions and features available to all • Scaling up / out benefits all

  21. Accelerating your insurance MI solution

  22. Key messages… • We already provide a comprehensive MI solution on premiums, claims, loss ratios and triangulations • Through a common, extended design we can handle both simple and complex insurance MI requirements and phase your adoption over time • We are now offering a secure, multi-tenanted hosted platform to develop your MI solution much faster without the need for you to worry about infrastructure • Through 3rd party integration you can take advantage of enriching your data as and when required • Using our new value add capabilities, you gain new insights into your data and identify opportunities • Our ability to deliver data in any format allows you to use your tools of choice of further analysis

  23. Accelerated insurance MI solutions It is all about a concerted team effort I am here for the rest of the day…look forward to getting your feedback and thoughts

  24. Fast-Tracking your Insurance MI Presented by Nico Kichenbrand

More Related