current system

filename: IP status: CONFIDENTIAL

Heritage Union Operational Systems

October 2010

of 8 filename: IP status: CONFIDENTIAL

HU has built two systems to support our business.

Sales Support System (SSS)

Designed to paperlessly manage a case from lead through to policy issue with capabilities such as quotes, e-applications, instant decisioning, identity verification, payment authorization, electronic and voice signature, document/data distribution.

Heritage Union Policy Administration System (HUPAS)

Designed to manage a policy after issuance to policy owner services and payment management.


In a nutshell, our systems can be characterized as follows:

• Entirely browser based

• All .Net (largely 3.5 with some older pieces being converted as we update them)

• All SQL 2008 database

• 4 Tier architecture with data, data access, business logic and user layers

• Web 2.0 with heavy use of dynamic content, Ajax and JQuery

• Hosted at Tier 4/SAS70 data center


Sales Support System (SSS)


The core functions of SSS include sales and new business administration and could be generalized as a special purpose CRM or case management system

with a number of unique capabilities.

Lead Quote Apply Sign

Instantly Underwrite

Manually Underwrite

Distribute Update

Leads are fed into the system by Agents (phone or field), various

consumer facing websites or special purpose utilities.

Ability to quickly quote all of our products and any other products

and dynamically manages product availability based on demographics,

states and strategy.

Fully dynamic application user interface for agents and consumers with reflexive questions and third party

validation.

Fully supports electronic and voice signature to include third

party vaulting.

Fully integrated instant decisioning platform with modular design allowing

for vendor swap out. Front and backend rule engine to quickly adjust

business logic.

When an application does not meet instant decision criteria, it is referred to underwriting. Underwriters have a

portal for this population and they work the case in our system.

Based on various rules and conditions, this capability

distributes documents and data to key partners to expedite underwriting or policy issue.

Various mechanisms to provide status updates (human and

systemic) to ensure we have a full view of our pending business.


To make all of this work there are a number of major subsystems within SSS that we will discuss further:

• Quotes

• Applications

• Case

• Distribution (AIM)

• Instant Decisioning (VIM)

• Product Administration

• User Administration

• Reporting (Wiz)

• Enrollment

• PDF Management

• Consumer Sites

• TPA Integration

• Vaulting

• Logging (data and event)


Quotes


The purpose of quote engine is to generate quotes for all existing products and riders based on customer information.

Making the products simple for the consumer shifted the burden of complexity to our systems. This quote engine was designed to accommodate the unique complexities of our products but could

readily be adapted to any product.


Product and rider lists are dynamic based on state, campaign, income, age, gender, and tobacco use.

Any value within the quote can be edited and every other value is instantly recalculated. By default all quotes presented cover 100% of income.


All underlying calculations use product configurations (that include rates and various limits and ranges) and can be reused within any other website.


Applications


The core purpose of the system is the ability to take paperless applications.

The application pages are entirely dynamic based on state and product and lead/quote data pre-fills to the application


In addition to dynamic content, we have reflexive questions that function just as a PHI does to characterize risks and is a key input to the instant

decisioning.


There is extensive QA rules to eliminate NIGO apps and numerous widgets to improve data capture and productivity.

The system provides format hints and QA rules to properly capture the DL#.

The system validates routing numbers and if accurate, pre-fills data. If inaccurate it prompts the

agent as below.


The system also validates payment information (via a web services integration) to ensure it is accurate and the account is in good standing.

Identity verification functions very similarly.


The system supports freeform notes from the agents and all reflexive questions/answers are represented as notes to facilitate underwriting if the

case is referred.

The notes are populated on the application PDF and become part of the policy.


The system utilizes user controls for elements that recur across multiple products. The example below if for beneficiaries and has built in QA.


The system provides scripts for voice signature to accommodate disclosures and authorizations. This is also entirely dynamic to meet unique state

requirements.


Once the voice signature is captured, the agent can click “Submit” which will trigger the instant decisioning (discussed later).


Case


In essence, SSS is a case management system (or a CRM) with many insurance specific utilities. One can think of it as an electronic conveyor

system moving leads to issued polices.


Each case has seven sections that are relevant to one of more parties.

1 Customer Information – basic demographics that are necessary to contact and quote.

2 Case Information – status information that is of most interest to sales

3Tasks – Ops, Sales, Underwriting and the system itself can assign tasks to themselves or each other to move the case toward policy issue

4 Notes – Ops, Sales, Underwriting and the system itself can annotate a case to help other parties do their work.

5Log – a human readable log of all changes to the case (e.g. X was changed to Y on this date by this person)

6New Business Admin – the largest and most complex section is specifically for Ops and Underwriting to convert completed apps to paid policies.

7 Policy Owner Services – for Ops to manage existing polices and provide the company with a lifecycle view of each policy.


Like most case management systems, it is status driven. The single most important status is the “App/Policy Status” which is the center of this

systems universe.


Case page consists of several sections. “Policy” sections are added as customer applied for policies. The relationships are pretty simple 1) each individual has one and only one case 2) each case may have one or more

polices.


The page includes productivity enhancements, such as zip/city/state verification and pre-filling, dynamic agent lists, age calculation, on-the-fly

formatting and validation, as well as various keyboard shortcuts.


All case and product-related information can be viewed or edited on this page. Users can use both keyboard and mouse to work with this page.

Permissions to edit data are driven by user roles.


Distribution (AIM)


AIM was built to accomplish several important objectives

1 Provide a central funnel for all applications that require some form of action

2 Provide an easy platform to associate call recordings with applications for voice signature

3 Create a means to manage the flow of new business and ensure IGO

4 Provide a mechanism to electronically distribute data and documents to our many partners


In the course of our business we distribute documents and data to a number of external parties.

Heritage Union

Underwriters

Lettershop

TPA

Vaulting

AIM manages all of this electronically based on rules and conditions.


When an app meets certain conditions, it is “uploaded” to AIM. This is done for the consumer for web sales.

Page 30 of 8


In this interface the Sales Manager can review each application for IGO status (if desired) and then distribute them.

Page 31 of 8


The Agent or Sales Manager can “attach” the call recording which will be archived with the PDF as our official litigation copy.

Page 32 of 8


When attaching a call recording, they are taken to a directory where calls are listed by phone number, agent name, and date stamp to facilitate searching

the lists.

Page 33 of 8


Once the application has been marked as IGO, clicking the distribute button will begin the process of sending the application and call recordings to the

various destinations depending on business rules.

Page 34 of 8


Instant Decisioning (VIM)


We achieved instant decisioning by building our own capabilities around a third party capability

Extract Translate Comm Decision Polling UpdateBackend

Rules

When triggered, the system will extract all data necessary for

instant decisioning.

The system will translate/transform the to meet

the needs of the vendor

The data is pushed via secured web services in XML.

Based on predefined criteria, our inputs and third party data, the decisioning platform render an

underwriting decision.

The system will poll the third party (differentially based on state) for the response and

retrieve it when ready.

There is additional backend rules so we can quickly adjust the inputs to meet our

business needs based on rate class, face value, product and other dimensions.

Based on the decision and backend rules, the case and UI

will be updated (e.g. “Congratulations, you have been

approved”)

We have built this capability modularly so we can quickly swap out vendors or build our own decisioning capability.


We also built an admin utility so we can have visibility into the decisioning process (inputs and outputs).

On this page you can look up any record by unique ID. You can also pull data by other crtieria.


Here you can see the full transaction history for that record


You can also view exactly what was sent and what was received in XML or human readable format.


Product Administration


Product administration is a complex combination of campaigns, products and states.

Adding a new product into the system currently requires direct access to the database. A number of product attributes such as carrier, age and benefit limits, type, etc must be defined. Additionally,

rates must be entered into the database for each age or age band. Once the products have been defined and rates entered, the administration portal allows systems admin personnel to set up and

modify the combinations very easily.

Page 41 of 8


The campaign drop down list filters the product and state combinations for specific campaigns.

Page 42 of 8


The user can easily create a new combination using the drop down lists and blanks at the top of the screen. In this example, AD5 will be added to Hawaii for Campaign 033 effective 10/18/2010 when the “Turn On” button is clicked.

Page 43 of 8


After clicking the “Turn On” button, a confirmation message helps prevent creating an incorrect campaign/product/state combination.

Page 44 of 8


AD5 is now turned on for Hawaii and Campaign 033

Page 45 of 8


Removing a Campaign/Product/State combination is simply a reversal of the process to add a combination. The user selects the appropriate values and

selects Turn Off.

Page 46 of 8


A confirmation message helps prevent accidentally deleting a campaign/product/state combination.

Page 47 of 8


User Administration


The system is configured to support differential access on several dimensions

•Different associates can be granted or denied access to certain views based on roles (e.g. underwriters will see only cases that are pending manual underwriting).

•Different associates can be granted or denied access to certain capabilities independent of roles (e.g. some associate in sales have permission to delete errant cases and others do not).

•We have partitioned the system to support multiple Agencies and granting or denying visibility into those cases by role (e.g. Ops can see all cases but agency A can see only the cases for agency A).

The following slides describe some of the basic user administration tools available in the system. This is only a sampling of the Administration tools we have built.


The SSS administration portal allows systems admin personnel to add or modify the underlying data for a number of areas.

Page 50 of 8


The user management screens allow systems personnel to set up, manage, or remove user accounts easily and quickly. The search feature allows searching by name, email, first letter of user name, or lists all users.

Page 51 of 8

The user selects the Edit or Delete icon to continue


Systems personnel can view general information about the user.

Page 52 of 8

“Disapproving” a user has thesame effect as locking them out.Users must be approved and not

lockedout to access the system.


Adding or removing users to and from roles is quick and easy. New roles can also be defined and added in this screen.

Page 53 of 8


User contact and work information for systems administrative purposes is displayed and managed in this screen.

Page 54 of 8


Adding a new user is a 6 step process which takes just minutes.

Step 1, Enter the user’s name.

Page 55 of 8


Step 2, Enter the user information.

Page 56 of 8


Step 3, Select the new user from the list of users

Page 57 of 8


Step 4, Select the appropriate role(s).

Page 58 of 8

Step 5, Updating profile information is optional.


Step 6, Enter sales agent specific information where appropriate.

Page 59 of 8


Reporting (Wiz)


To meet the endless need for data analysis, we built a reporting utility called the “Wiz” with a few key objectives in mind.

1 Readily usable by varying levels of data or systems sophistication

2 Embedded in SSS and there fore browser based due to distributed workforce

3 Satisfies 80%+ of our data/reporting needs

4 Implemented quickly with relatively little capital


The Wiz is really two very separate pieces 1) entirely de-normalized massive table with all relevant data 2) smart UI that can read table and self adjust

The table has hundreds of columns and thousands of rows. It is extracted from the production system just as a data

warehouse is.

The UI is entirely independent and is “smart” in that it can self adjust to changes in the underlying data.

Because the data is de-normalized, it can run queries very quickly.


Reporting tool provides a simple user interface for accessing all system data.

Queries/reports can be built, edited and saved for future use.


In any given query, data can be, included or excluded, arranged, filtered and sorted.


Enrollment


Enrollment files (EFs) are largely behind the scenes but an important component of the whole.

• EFs are sent from SSS to our TPA when a policy is ready to issue

• There is a robust set of business rules governing when they are sent

• They contain all data required to issue and bill the policy which varies by product type

• They are sent in a carefully agreed upon XML format in daily batches

• We have built administrative tools to monitor, retrigger and validate transmission and data integrity


PDF Management

of 8 filename: IP status: CONFIDENTIAL Page 68 of 8

Most products have a unique fillable application PDF template assigned. In some cases, the same form is used for products in the same family (i.e. LF65, LF5, and LF3). In addition to product specific applications, in many cases, there are state specific applications.

The PDF management screen allows system admin personnel to upload or replace application PDFs and map them to specific states, campaigns, and products.

There are two general types of fillable PDFs. The first is a non-sectioned PDF that contains all of the information required for a policy in one form. The second is a sectioned that that has a demographics section, payment authorization section, and an additional details section. The sectioned PDF permits sections to be shared without requiring a new version. The management screen accommodates both types.

The applications that are taken electronically (by Agents or consumers) ultimately manifest themselves in the form of a PDF file.


The screen fields are sufficiently self explanatory to make uploading a new or replacement PDF relatively straight forward.

Page 69 of 8


After selecting the name of a current PDF or supplying the name of a new PDF, the user clicks on the Browse button(s) to find the appropriate file(s) in

their system. The effective date of the PDF can be set to a future date to allow PDFs to be preloaded in preparation for a new

product or campaign launch. The end date is initially set to the maximum allowable date in the database. Or, if the last date of a campaign or product is predefined, the date can be set to allow the PDF to expire.

Page 70 of 8


After clicking the Upload button, the user is expected to map the PDF to the appropriate states. Clicking the Edit States hyperlink opens the

State/Campaign/PDF mapping screen.

Page 71 of 8


The user may start a new mapping by selecting a product and campaign from the drop down lists. Or, if the View Detail hyperlink is clicked, the states

selected for the campaign and product will be indicated with check boxes.

Page 72 of 8


In this case, this is a state specific PDF for Florida, so only Florida is selected. If the PDF was not state specific, the user may select multiple states to turn on or off. When the user is done, the Update hyperlink saves the changes.

Page 73 of 8


Consumer Sites


We have developed several consumer sites that function like the Agent portal but with an aesthetic and ease of use emphasis. All are fully integrated with

our new business administration system (SSS).

When a consumer enters quote information, a case in SSS is initiated and assigned to an agent so they can work the case if the consumer does not transact online.


Consumers can quote and select base products and riders and design custom coverage.

Base Product Rider

Products and riders are presented dynamically based on age, state or strategy. In addition, riders are presented based on base product.


The application is functionally equivalent to the Agent version but designed to walk the consumer through the process step by step … much like TurboTax.


Just like the Agent version, there are reflexive questions and instant decisioning


The consumer sites employ electronic signature capabilities.

•E-Sign/UETA Compliant

•Captures affirmative consent

•Presents the full app before and after signature

•Applicants can download, print or save a copy of the signed app

•Signed app is immediately vaulted with a third party as the official litigation copy.


TPA Integration


The objective of the TPA integration was two fold:

Bring post policy issue information back into our new business administration system to provide full lifecycle visibility into the performance of our block thus allowing marketing and operations to optimize their efforts.

Trigger Operations and Sales to perform certain functions that will improve the quality of our block that we felt we could perform more robustly than a third party.

To get this done, we essentially receive a massive data dump which we systemically scour to extract key information and update the relevant cases accordingly.


Policy changes, updates, and payments are reported to HU by Consecta via an automated daily XML file download. Each record consists of one policy

with one or more activity.

Page 82 of 8


Each record is parsed to identify the policy and the activity. Depending the activity and sub-activity code combination, the action may be acted upon or

ignored.

Page 83 of 8


The input data is bounced against a large rule set and certain actions are taken to update the case and when necessary trigger an action. Examples

include:

• If a policy is free looked, the agent will be prompted to resell the policy

• If the policy lapses, the agent will be prompted to save the case

• If payment fails, the agent will be promoted to capture new payment information

• If a claim is initiated, Ops will be prompted to initiate their claim review process


A reporting interface allows the user to review the inputs from Consecta. Various filters can be used alone or in combination to narrow the number of

records returned for review.

Page 85 of 8

The Relevant Records option limits the data to the specific portions of the XML files which match the search criteria.

Errors are usually data entry issues that

must be manually corrected in either the HU systems or the

Consecta systems


Clicking the Run button initiates the database search. In this case one record is returned for a specific policy number.

Page 86 of 8


The user chooses how to view the data (see next slide).

Page 87 of 8

Download returns the entire XML file,

Show Record returns the specific portion of the XML.


The user can work from the XML file…

Page 88 of 8

Or a slightly more human friendly version with some built-in interpretation…


Vaulting


Vaulting

• All signed applications in form of PDF files are automatically submitted to the vault via a secure channel.• PDFs are digitally signed protected and locked to prevent any changes after electronic signature was applied.• Voice recordings are also submitted to the vault as part of digital signature.• Application that needed manual intervention can be submitted to the vault manually.


Logging


Event logging provides visibility into system mechanics. It tells exactly what action was performed, when and by whom. It also makes it easier to troubleshoot and find systemic issues, even before they had any

impact.

Event logging


Data logging provides information about data changes, down to the field level. It gives the ability to track workflows, verify business rules.

Data logging


Policy Administration System (HUPAS)


HUPAS was born of necessity as we could not get our then TPA to react to changes quickly enough. This drove us to develop an lean policy admin

system to support rapid testing.

There are several subsystems within HUPAS that we will discuss further:

• Policy Data Entry

• Policy Update

• Payment Processing

• Follow-up Entry


The core purpose of the system is to permit rapid data entry and updates to current policies.

Data entry and policy updates use the same on-line forms. Updates begin with searching for an existing record. The search screen permits searching by policy numbers or last name.


Clicking on the name hyperlink in the search page directs the user to the data entry screen which is prefilled with existing information about policy.


There are a number of shortcuts built into the screen to enhance performance and to help ease data entry.

Clicking any of the link buttons runs QA on the form and saves the current entries to the database. These buttons and functionality are present on the subsequent screens

The Set Follow-up link opens the Follow-Ups screen

Keyboard shortcuts allow tabbing and one key data entry for drop down lists. The Save Record button is a manual method to save the currently entered data (if it passes QA).

The Copy Policy Holder button pre-fills the policy owner fields


Each screen in HUPAS has built in QA rules to help prevent human error and ensure data integrity.

Page 99 of 8


The product entry screen has a number system calculated and pre-filled values to eliminate human error.

Product selected drives backend rules for calculations and pre-filling fields.

Total benefit and monthly benefit is recalculated for LF 65 products to show current death benefit.

100% coverage is selected by default, but preset values or any percentage from 25 to 125 percent may be selected. Note: Subsequent business rules applied in SSS have made this feature obsolete, but it remains in HUPAS for legacy data.

The calendar control makes date entry quicker and error free.


The Case Management screen has been made obsolete by the Case Management in SSS. This screen was left in place to present legacy data but

is no longer used for data entry.


The Billing screen is the initial data entry point for new policies. It is also calculates the premiums based on the data entered in preceding screens and

is the launching point for payment entry and payment management.

Speeds data entry and prevents human error

If any changes in the policy triggerupdated premiums, a warning message prompts the user to

accept or decline premium changes


The payment entry screen displays the default premium, but will permit higher or lower payments.

This link in the Billing screen opens the

Payment Entry screen


The payment list permits the user to view the payment history of the policy.

This link opens the Payment List screen


The Beneficiary entry screen allows up to six beneficiaries per policy. Clicking the Add Me button will add the current beneficiary to the list and

performs QA on data capture and % allocations.

Page 105 of 8


The Notes screen permits entry of policy administration notes.

Page 106 of 8


The Claims page is just “Stubbed Out” as a placeholder in the event that HU was ever required to pay a claim for this test bed population.

Page 107 of 8

current system

Technology