eData Information Web Meeting

1. eData Information Web Meeting Pending File Consumability Evaluation Results June 27, 2012

2. Pending File Consumability First project as part of eData plan Addressing issues with pending feeds in place today Quality of information Timeliness of information

3. Approach • One on one sessions with each party • Review issues from each individual perspective • Categorize issues based on where they may be happening (e.g. carrier, vendor, business interpretation) • Group issues by company and communicate specific concerns • Carrier List based on distributor • Vendor List based on distributor • Face to face meeting held to discuss common issues as an eData opportunity • Hosted by Manulife, open to all premiere members • Tie back to company specific concern should be known • Agree on resolution • Gain commitment to make adjustments as needed

4. Carriers: Manulife Sun Life Canada Life Industrial Alliance Transamerica RBC Solution Providers: Virtgate Winfund Blue Sun Univeris Ageman Distributors: Hub Dundee PPI Financial Horizons Investors Group Bridgeforce Credential IDC Worldsource Participants to DateOne on One Review Sessions Sessions can still be scheduled. Please contact Tana Sabatino for more information.

5. Distributor View • Reviewed role of case manager • Workflow • Number of cases handled • How workload is managed • What triggers a case to be looked at • Issues experienced with data in current feeds • What causes reconciliation issues • What requires manual processing • What requires going to website for review

6. Understanding the Case Manager Discovery: The case manager is the true customer of the pendinginformation.

7. A typical day of the case manager • Look at the follow-ups for today • These are automated task entries that trigger the case manager to follow up on the case • Handle email communications of new requirements

8. A typical day of the case manager • Follow ups generated by: • Internal service standards • Example standards: • Initial 14 days; subsequent 7-10 days • Every 7 days • Every 7-10 days • Every 4-5 days • They manually set a follow up task in the future based on these standards and it will trigger an event when it comes due • Requirements being updated in the feed • This depends if the vendor system has this functionality AND if it is activated • If utilized, cases that had an update to a requirement will also appear in their task list for the day

9. A typical day of the case manager • How many follow ups? • About 40 cases today in follow up. • 300-400 pending cases total being managed. • About 30 cases today in follow up. • 200-300 pending cases total being managed. • 200 pending cases total being managed. • 52 follow ups for today.

10. A typical day of the case manager • Each item flagged as a follow up is acted on • Case manager goes to the case and then to the requirements screen to see what has happened • Some case managers go to carrier website first as their preference • Not all carriers sending feeds, so website is only source in this case • Carrier website checked for data not available • “Other” requirements • Additional Details • Underwriter notes • Events • Decisions • Case Status • While in feed, many distributors do not update this automatically • Carrier website checked for missing requirements • Manual requirement comparison conducted • Carrier website checked 100% of the time for cases being reviewed for these reasons

11. A typical day of the case manager • Once case reviewed • Agent provided an update if that is their process • E.g. Case manager emails them • Follow up flag reset on agency management system based on service standard

12. A typical day of the case manager • Once follow ups are completed the case is not reviewed again unless there is activity • It’s time again based on service standards • A requirement was updated (or added) via feed • If they use a vendor systemprocess that triggers a follow up • Notification of new requirement or event, e.g. status change

13. A typical day of the case manager • Notification of new requirements and events • These come in via electronically to the distributor • Distributors are notified of most new requirements and events in some electronic form • Method of obtaining them varies by carrier • Carrier secure email system (requires log-in) • Email with details • May or may not be emailed to agent directly; depends on carrier • Notification of email • Requires log into carrier email system to see what it is • Sample case manager gets 80+ of these notifications daily

14. A typical day of the case manager • Notification of new requirements • Case manager adds the correspondence to the case in the system (copy and paste) • Adds it as a note, location depends on system • Case manager may check to see if requirement already received in feed • Not all do • Case manager may add them as a new requirement and include the details • Even if requirement there, they may opt to add it again separately to provide details that were not in the feed anyway • When case comes up for follow up, they will sometimes check to see if the requirement later appeared in the feed • If so, some opt to close the one they added; others leave them both open

15. About the Data What they see

16. Data Content Issues • Case status interpretation and communication • What it means for a case to be ‘done’ varies • Between distributor and carrier • Between different distributors • Unclear on definitions • Approved, issued, inforce • Need to ensure all relevant status changes are understood and communicated to allow distributors to manage their business Issue Rqmts Received Policy Pages Delivered Underwriting Decision Made Policy Issued Policy placed inforce

17. Data Content Resolutions • Case status interpretation and communication • Distributors notified of major milestones of policy status changes as soon as possible. • Examples include case approval, case approved as substandard, case declined. • Acknowledge thatworkflow of carrier may not be in sync with the status changes that are tracked • Agree on standard list of ACORD codes to communicate the milestones – and agree on what they mean • Distributors need to agree on using the same breakdown else the information will still be lost in translation • Vendor systems must support the same list • Next step: complete a cross mapping of company policy status codes for review at industry level. This includes both carrier and distributor system codes.

18. Data Content Issues • Identification of requirements • Unclear what requirement codes are being used • Same requirement uses different requirement code between carriers • Different requirement code used to communicate same requirement between carriers • Different requirements mapped to a single requirement code within a carrier making items appear as duplicates when they are not • Requirements incorrectly mapped to CITS codes • Too many requirements mapped to ‘other’, ‘additional’ information

19. Data Content Resolutions Use of Requirement Codes • Next Step: Provide a cross industry mapping of all requirement codes in use today in order to ensure they are all supported. This effort will also result in recommendations to add new codes, remove the use of certain codes, and remap existing codes. • Follow up: All trading partners should send their list of current requirement codes/mappings.

20. Data Content Issues • Missing requirements • Not all requirements are being sent from carrier that appear on website • Doesn’t treat what distributors view as equal requirements equally, so not all sent • Event notifications top this list • e.g. case status changes, underwriting decisions • Intentional screening done at carrier side • Carrier decides what they think distributor wants to see • E.g. screen out issue requirements • Not all requirements being displayed in vendor agency management system • Only displays requirements with known codes • Intentional screening done at vendor side

21. Data Content Resolutions Provide All Requirements • Screening out requirements at carrier level is inconsistent • Next Step: All carriers should be advised to not screen out particular requirements. Different distributors are interested in seeing different things. They should have the option to screen at their discretion. • Next Step: Screening of requirements by vendor system should be considered to avoid the complaint of ‘meaningless’ requirements appearing in feed, simply because that particular distributor doesn’t care about it. • Competitive advantage opportunity of vendor • Events not actual requirements but are wanted to be treated as such • Next Step: determine which events are provided today and ensure there’s a requirement code available for mapping • Emails are sent for requirements that never appear in feeds • This relates to the above two points • Next Step: Determine if these 2 items (along with providing details as described next slide) closes this gap completely

22. Data Content Issues • Missing details for requirements • Free form comments not sent in feed so it is impossible to know what the full requirement is without looking at website • “Other” • “Additional information” • “See insurance company memo” • “Respond to Question # 10”

23. Data Content Resolutions Provide complete information • Provide additional details in feed itself to level it is available on website • Next Step: Work with carriers to provide this information in the feeds themselves in the appropriate free form text strings available • Next Step: Recommend vendor systems read both (not just one) text string so that no details are inadvertently lost in the conversion

24. Data Content Issues • Requirement status interpretation and communication • Different status codes selected by different carriers that mean the same thing • e.g. Evaluated versus completed • Vendors not supporting full list of CITS codes • Cancelled, waived not showing in some systems • Deleted requirements • No way to know it went away

25. Data Content Resolutions Provide full support for needed statuses • Next step: complete a cross mapping of company requirement status codes for review at industry level. This includes both carrier and distributor system codes. • Follow up: All trading partners should send their list of current statuses/mappings.

26. Data Content – Next Meetings • Requirement code and status mapping • Cross mapping between all companies • To be done by eData project manager • Teleconference scheduled to discuss results, next steps • August 13 11:00-1:00pm ET • IN ADVANCE - carriers and vendors to provide full requirement code and status mapping for cross industry analysis Register:www.cliedis.ca/edatacurrentmeeting.php

27. Data Timing • Focus on notifications • Has greatest impact on improving workflow of case manager • Case manager does not look at the case unless they know there is a reason to • Notifications will allow vendor systems to build functionality as desired to trigger case manager of activity • Notifications can replace the manual email process in place today

28. Batch Rq Rs Same time Notify Portal Data Timing • Carrier Perspective • Don’t just tack on more alternatives to get at data

29. Carrier-Distributor Environment with eData - From Business Case Client Website Carrier Environment Distributor Environment Information presented as available, close to real time Pending Case Status Request Response Inforce Servicing eData Web Services eData Web Services Request Response ALL Pending and Urgent Inforce Notifications Urgent Notifications Poll Notification Additional eData services Information accessible as available, close to real time Batch Processing Pending Nightly CITS XML FTP Batch File Delivery Batch File Processing FTP Inforce Weekly CITS XML FTP Commissions Periodic CITS XML Additional eData batch feeds For reconciliation, data mining, marketing

30. Carrier-Distributor Environment with eData – After Analysis Client Website Carrier Environment Distributor Environment Information presented as available, close to real time Inforce Servicing eData Web Services eData Web Services Request Response ALL Pending and Urgent Inforce Notifications Poll Notification Additional eData services Information accessible as available, close to real time Batch Processing FTP Batch File Delivery Batch File Processing FTP Inforce Weekly CITS XML FTP Commissions Periodic CITS XML Additional eData batch feeds For reconciliation, data mining, marketing

31. Data Timing • Carrier Perspective • Don’t just tack on more alternatives to get at data • With this approach • request/response not needed for pending • With this approach • overnight batch can go away if notifications of changes are provided throughout the day

32. Data Timing • Carrier Perspective • Web Portal approach • Must allow carriers to move toward this with a batch interim approach • Focus on improving timing, and quality of information first • Standardizing how it is delivered comes later • Minimize menu of options / expectations of presentation from carrier

33. Notifications Identified Option A – Web Portal Delivery ALL Pending and Urgent Inforce Notifications Load into Distributor system Web Portal Post Poll Notification Option B – More Frequent Batch Delivery Batch Post Pending Many times Per day CITS XML FTP Distributor Carrier A or B – Distributor experience identical Vendor processing issue

34. Understanding How Feedsare Processed

35. Processing Feeds • Feeds come in the morning • Service standards vary • But all should be in by 9am • Days of delivery vary • Mon-Fri • Tues-Sat • Feeds get loaded • Most have an automated process for loading • Cases match when they can • The rest are flagged for reconciliation

36. Processing Feeds • Feed Volume • Sample from distributor: • 1 day snapshot • 930 cases total • Approx 700 in policies that get feeds • 190 cases came in on feed (190/700 = 27%) • Possible that cases are counted multiple times. Unclear if this stat is based on requirements; each insured; or policy numbers • Sample from carrier: • 10 day sampling of select MGAs • Average 737 cases; average 116 in feed (16%) • 4 day sampling • 1258 cases; 168 case average over 4 days (13%) • 1 day snapshot • 10890 cases pending; 2139 in feed (20%) • 4 day sampling of select MGAs • Average 27%

37. Processing Feeds • Reconciliation process • What triggers a case for reconciliation depends on the agency management system • Their match criteria • Processing for when an exact match is not found • Load it in separate • Flag it to see if a match could be found • Common issues reported • Unmatched policy numbers • New case so didn’t have policy number assigned yet, app was sent to carrier directly so they didn’t see it yet, number entered with different format • Child insureds (treated as insureds in feed, but not by distributor) • Name mismatches (with or without middle names) • Treatment of joint cases • Reconciliation manual • Must find possible matching case • Some systems help in identifying possibilities • Must change data to make match • Feed reprocessed for those updates once changes made

38. Processing Feeds • Sample reconciliation stats: • Distributor A: • Today: 608 cases / 27 were unmatched (4.5%) • Distributor B: • Yesterday: 206 cases / 36 were unmatched (17%) • Today: 235 cases / 17 cases were unmatched (7%) • Quote from distributor: “ Feed reconciliation is extremely cumbersome and takes a lot of time. It is very problematic. ” { because of all the work in match, reprocess, and then still have to research requirements } • Not all distributors reconcile cases

39. Reconciliation Issues • Reconciliation challenges by type • Unmatched policy numbers • New case so didn’t have policy number assigned yet • App was sent to carrier directly so they didn’t see it yet • Policy number different/changed than what was utilized initially • Number entered with different format • Child insureds • treated as insureds in feed, but not by distributor • Name mismatches • Eg with or without middle names • Period or no period in abbreviation • Treatment of joint cases • Requirements matched at case level and split across insureds correctly • Recognize differences in vendor processing • Understand areas of competitive advantage

40. Reconcilitation – Next Meetings • Reconciliation process exploration • July 18th11:00am-1:00pm ET • CITS product feed overview • Why necessary • Format, expectations for delivery • July 26th 11:00am-12:00pm ET Register:www.cliedis.ca/edatacurrentmeeting.php

41. Communication between Business Partners Distributor Carrier Vendor

42. Communication Gap • Distributors want CLIEDIS involvement in closing gaps “Thank goodness someone is looking at this. We know what issues we see but we have no ability to identify whose problem it is.” {carrier versus vendor versus CITS definition}

43. Communication Gap Knowledge base • Business users lack knowledge of pending feeds • Crosses carriers and MGAs • Although they know the values shown on their own systems, they typically do not know: • How the feeds are produced • Where they come from • How values shown on their systems relate to values shown in the feed and/or values that have been imported into consumer systems

44. Communication Gap Communication channel • Carriers have no clearly defined mechanism for addressing feed problems identified by MGA • No clear way for MGAs to identify and report back problems with the data feeds to the carriers such that the issue will be investigated, prioritised and readied for Production. • Getting technical support on data feeds from carrier organisations is at best ad-hoc and is often based on personal relationships between personnel involved in the CLIEDIS CITS and eData initiatives.

45. Communication Gap Resolutions CLIEDIS Governance • Determine role of CLIEDIS in establishing these connections and providing investigative support to uncover cause of issues • Determine role of CLIEDIS providing discovery and mediation resources • Determine role of CLIEDIS is encouraging companies to convert to standard CITS feed or provide a CITS feed and move to new versions as needed

46. Next Meetings • Reconciliation process exploration • July 18 – 11:00am-1:00pm ET • Paramed process overview • To engage paramed companies • Gauge interest, solicit participation • July 25th – 11:00am-12:00pm ET • CITS product feed overview • Why necessary • Format, expectations for delivery • July 26th – 11:00am-12:00pm ET • Requirement code and status mapping • Cross mapping between all companies • To be done by eData project manager • August 13th – 11:00am-1:00pm ET • Face to face Paramed kickoff • September 11th at Transamerica’s offices • Face to face 2nd and hopefully final pending information session • September 12th at Transamerica’s offices Information:www.cliedis.ca/edatacurrentmeeting.php

47. Next Meetings CLIEDIS Annual Seminar September 13, 2012 Toronto International Centre (near Toronto Pearson Airport) Registration to begin in July

48. Questions ? Tana Sabatino, eData Project Manager – tsabatino@cliedis.ca Julie Parrott, CLIEDIS Executive Director – jparrott@cliedis.ca