US20110004492A1 - Dynamic adjustment of insurance premiums - Google Patents

Abstract

A method to dynamically adjust a premium of an insurance policy is disclosed. At least one of an entity input data or an environmental input data is updated by a dynamic insurance provisioning system, the entity input data being an input data that is specific to an entity insured by the insurance policy and the environmental input data being additional input data that is not being specific to the entity. A determination is made as to whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data. Responsive to the determination, the premium of the insurance policy is recalculated.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims the priority benefit of U.S. Provisional Application No. 61/182,589, entitled, “Variable Life Protection Base on Dynamic Inputs,” filed May 29, 2009, which is hereby incorporated herein by reference in its entirety.
BACKGROUND
• Insurance is typically viewed as a form of risk management, in terms of which there is a transfer of risk from an insured party to an insurer party in exchange for a premium. An insurer may be a corporation selling the insurance, while an insured (e.g., the policy holder or owner) is typically a person or an entity that is buying the insurance. An insurer charges the insured a premium, which is typically a once-off or recurring monetary payment from the insured to the insurer in exchange for the assumption of the risk by the insurer. There are many types of insurance, such as auto insurance, home insurance, health insurance, disability insurance, casualty insurance, life insurance, and credit insurance, to name but a few.
• Life insurance (or assurance) is typically provided in terms of a contract between a policy owner and an insurer. The contract may obligate the insurer to pay a sum of money to a beneficiary specified by the policy holder upon the policy holder's death, terminal illness or catastrophic event.
• The insurer typically calculates policy prices using mortality tables (i.e., statistically-based tables showing expected annual mortality rates). Main variables in mortality tables have traditionally been age, gender and use of tobacco.
• Life insurance is often provided in two basic classes, namely temporary life insurance or permanent life insurance. Temporary life insurance provides coverage for a specified term of years for a specified premium, while permanent life insurance remains in force until the relevant policy matures or pays out.
• U.S. Pat. No. 7,395,219 describes an “insurance on demand” transaction management system that implements an intermittent risk exposure liability insurance method. The method involves establishing an Internet business site enabled for communication between insurers and insured. Insureds are enrolled in intermittent risk exposure liability insurance policies. These policies provide a variable insurance premium rate depending upon an intermittent use of an insured article (e.g., a motor vehicle). The start and completion times of each intermittent use of the insured article are logged on the Internet business site by the insured. These start and completion times are verified. Premium insurance rates are applied and billed in accordance with the verified log start and completion times of use.
• U.S. Pat. No. 5,839,118 describes linking an external computer with a system of an insurance carrier and a system of an independent lending institution to determine an optimal premium structure for a variable life insurance product, using a portion of a policy owner's money and a lending institution loan to finance a premium. The system provides for the tracking of several variable life insurance policy cash values to ensure each individual policy cash value is adequate for collateral purposes.
BRIEF DESCRIPTION OF DRAWINGS
• Some embodiments are illustrated by way of example and not limited in the figures of the accompanying drawings in which:
• FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within a dynamic insurance provisioning system, according to an example embodiment.
• FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example system, as may be processed by example methods.
• FIG. 3 is a graph that provides an example for a scenario in which a customer preference for sampling net worth (Input A) is set to a time period of 1 week (t2−t1=1 week) and a trigger threshold is set to 10%.
• FIG. 4 is a block diagram illustrating the architecture of a dynamic insurance provisioning system, according to an example embodiment.
• FIG. 5 is a flowchart illustrating a method, according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
• FIG. 6 is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
DETAILED DESCRIPTION
• In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the subject matter of this disclosure may be practiced without these specific details.
• As used herein, the terms “person,” “individual,” “entity,” or “customer” are used interchangeably to refer to a party (e.g., an insured or an insurer) that interacts with a dynamic provisioning system.
• Example embodiments include systems and methods for providing life assurance protection based on changes in individual and environmental characteristics that are partly predefined by the insured party (e.g., a customer). It should be noted that embodiments of the present invention may be utilized to provide other forms of insurance protection.
• FIG. 1 is a schematic diagram illustrating an insurance provisioning environment within which a dynamicinsurance provisioning system100 may be deployed, according to an example embodiment. The dynamicinsurance provisioning system100 is shown to be communicatively coupled by anetwork102 to one or more information sources. The information sources may include one or more network access devices (e.g., a personal computer system104),regulatory computer systems106,medical data systems108, andfinancial data systems110. The dynamicinsurance provisioning system100 may receive inputs (or input data) from one or more sources. The inputs may include entity inputs (or entity input data), environmental inputs (or environmental input data), customer preference inputs (or customer preference data or customer preference input data or customer preferences), regulatory inputs (or regulatory input data), medical inputs (or medical input data), market inputs (or market input data), or other inputs.
• In various embodiments, the dynamicinsurance provisioning system100 may update previously received or stored input data to determine whether a risk (e.g., an underwriting risk) associated with providing an insurance policy has changed. Based on this determination, the dynamicinsurance provisioning system100 may recalculate a coverage amount, a coverage time period, or a premium of the insurance policy. In various embodiments, the dynamicinsurance provisioning system100 may initiate the updating in response to receiving a preference of an insured entity or an insuring entity regarding when (e.g., a date or a time) or how often (e.g., a frequency) a coverage amount, a coverage time period, or a premium of the insurance policy is to be updated. The dynamicinsurance provisioning system100 may amend the insurance policy based on the updating.
• For example, an entity (e.g., aperson112 or a corporation (e.g., via an agent)) may use thepersonal computer system104 or other network access device (e.g., a mobile communication device, such as a mobile phone, personal digital assistant, netbook, e-reader, and so on) to provide entity inputs (also called entity input data) or customer preference inputs to the dynamicinsurance provisioning system100. In an example embodiment, an entity may be a corporation that is acting (e.g., via an agent) on behalf of itself or on behalf of one or more individuals. The entity may provide the entity inputs or customer preference input data using software running on the client system that accesses the dynamicinsurance provisioning system100.
• The dynamicinsurance provisioning system100 may receive the input data (e.g., via a publish/subscribe system or by querying interfaces (e.g., application program interfaces (APIs))). An entity may also provide entity inputs or customer preference data using an out-of-band communication channel (e.g., a voice call). The dynamicinsurance provisioning system100 may further receive (e.g., via the publish/subscribe system or querying interfaces) regulatory inputs in the form of regulatory information from theregulatory computer system106, medical information (e.g., pertaining to theperson112 or to a group of people) from themedical data systems108, and financial data (e.g., wealth data for theperson112 or market data pertaining to one or more markets) from thefinancial data systems110.
• The dynamicinsurance provisioning system100 may store the entity inputs, the customer preference data, the regulator information, the market data, or other data in storage (e.g., a database, file system, or memory; not shown). The dynamicinsurance provisioning system100 may make a decision whether to store the customer preference data based on the received entity input data. The dynamicinsurance provisioning system100 may access the data in the storage (e.g., using an operating system command, an API, or a query) for further processing or analysis.
• The dynamicinsurance provisioning system100 is furthermore shown, inFIG. 1, to be communicatively coupled via the network102 (e.g., the Internet) to channelpartner computer systems116 and aninsurer computer system120. The channelpartner computer systems116 may be associated with the various channel partners, such as brokers, agents and financial advisors that broker and sell insurance products of an insurer associated with theinsurer computer system120. The dynamicinsurance provisioning system100, as will be described in detail below, uses the various inputs from the systems104-110 to dynamically calculateperiod commissions114, which are communicated to the channel partner computer systems116 (or to bank accounts associated with the channel partners), and aperiod premium118, which is communicated to the insurer computer system120 (or to a bank account associated with the insurer). A period premium is one of a series of premiums that may be different from another one of the series of premiums. For example, with respect to an insurance policy having an adjustable premium, the amount of the premium prior to an adjustment of the premium may be considered to be a first period premium and the amount of the premium after the adjustment may be considered to be a second period premium. As another example, the amount of a premium prior to a renewal of an insurance policy may be considered to be a first period premium and the amount of the premium after the renewal of the policy may be considered to be a second period premium. Similarly, a period commission is one of a series of commissions that may be different from another one of the series of commissions. A period commission may be associated with a period premium. For example, a period commission may be provided to a channel partner upon a renewal of an insurance policy.
• FIG. 2 is a block diagram providing a high-level representation of relationships between information components of the example dynamicinsurance provisioning system100, as may be processed by example methods. A policy is recalculated or reissued based oncustomer preferences200 that define a specified time interval and a trigger threshold for accepting input changes, which in turn generate a trigger to change the underwriting risk or coverage amount.
• Entity inputs202 may include one or more inputs pertaining to (or specific to) a person (e.g., individual inputs or individual input data), a corporation (e.g., corporation inputs or corporation input data), or another entity. Examples of corporation inputs may include values corresponding to a corporation's size (e.g., number of employees), geographic location, or business focus. Examples of individual inputs may include values corresponding to a person's health status, biometric inputs (e.g., sensed physiological or behavioral characteristics, such as fingerprint, facial, iris, gait, voice, or other characteristics), marital status, location, or age.
• Environmental inputs204 may include market inputs206 (e.g., to perform a market valuation of a customer's net worth), regulatory inputs208 (e.g., regulatory changes to determine individual liability such as inheritance/estate tax), and mortality table210 (e.g., mortality data that refactors the underlying risk; the refactoring may include, for example, incorporating population mortality data).
• Data inputs (or inputs), includingentity inputs202 andenvironmental inputs204, may be captured through a combination of manual and automatic data feeds, such as through a biometric sensor, a manually entered cholesterol value, or an automatic updating of the customer's net worth. For example, inputs may be captured through system integration with an Internet-based portfolio administration service (e.g., a “wrap” platform, such as Aviva's Wrap and Sipp Platform or AXA's Elevate wrap platform). The Internet-based portfolio administration service may be one of thefinancial data systems110 ofFIG. 1.
• If a change in input causes a change incoverage amount212 orunderwriting risk214, then the dynamicinsurance provisioning system100 recalculates theperiod premium amount216. Anew premium amount216 triggers a change in the period commissions218 paid, for example, as trail commission that can be calculated daily and paid monthly to the agent/distribution channel.
• By having the coverage amount based on independently verifiable external variables, such as customer's net worth or current inheritance/estate tax calculations, the adverse/anti-selection risk is significantly reduced, thus reducing the underwriting burden, speed of issuance, and overall cost.
• Further details of the example information components shown inFIG. 2 are now discussed.
• Customer preferences data200 may be categorized as personal attributes and product preferences. Personal attributes include preferences for capturing personal information, such as a cell phone broadcast or a self-report for determining country location. Product preferences may include time period and threshold triggers to determine when a particular input, such as net worth, is considered for recalculation of underwriting risk or coverage amount. Time period is based on time intervals, such as real time, daily, weekly, monthly, quarterly, or annual. Thresholds may be based on either absolute or percentage changes of input.
• FIG. 3 shows agraph300 that provides an example of a scenario in which a customer preference for sampling net worth (Input A) is set to time period of 1 week (t2−t1=1 week) and a trigger threshold is set to 10%. In the graphed example, Input A would not trigger a recalculation of coverage amount because the value of Input A only changed 5% over the time period. In other scenarios, multiple triggers may be associated with each one of multiple inputs, includingentity inputs202 orenvironmental inputs204.
• Referring back toFIG. 2,entity inputs202 may be captured though automatic and manual data uploads. The entity inputs may include such information as biometric data through biometric sensors, health status change through physician statements or electronic heath records, weight, body mass index (BMI), level of fitness, cholesterol, or marital status.Entity inputs202 primarily drive underwriting risk, although inputs such as marital status may combine withenvironmental inputs204 to determine coverage amount (e.g., all things being equal, coverage amount for an unmarried customer will be different than coverage amount for a married customer because inheritance tax (IHT) liability is different).
• Theentity inputs202 may be independently (or externally) verifiable. The dynamicinsurance provisioning system100 may use a weighting mechanism to assign weights toentity inputs202 according to an extent thatsuch entity inputs202 are independently verifiable. For example, the dynamicinsurance provisioning system100 may assign weights having high values toentity inputs202 received automatically through a biometric device (indicating a relatively great level of external verifiability) and weights having low values toentity inputs202 received as a result of manual inputs by theperson112 or other entity (indicating a relatively low level of external verifiability). The dynamicinsurance provisioning system100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk. The dynamicinsurance provisioning system100 may considerentity inputs202 to be generally less independently verifiable thanenvironmental inputs204 and may therefore typically assign weights having lower values toentity inputs202 than toenvironmental inputs204.
• Environmental inputs204 may be data inputs that are not specific to an entity but nevertheless impact bothcoverage amount212 andunderwriting risk214. The environmental inputs may be external to theentity inputs202. For example, environmental inputs may come from an Internet-based portfolio administration service that tracks market changes or regulatory changes in IHT calculations that impactcoverage amount212. The market changes or regulatory changes may be categorized asenvironmental inputs204 because they are not specific to an entity. Furthermore, market changes or regulatory changes may be external toentity inputs202, but may include data that affects the entity inputs202 (e.g., a customer's investment portfolio).
• It will also be appreciated that mortality tables, which may contain population mortality data, may not be specific to an entity. Mortality tables may be external to entity inputs202 (e.g., automatically loaded as they are published by an external source). Mortality tables may impact the customer'sunderwriting risk214, resulting in a recalculation of theperiod premium216.
• Environmental inputs204 may be independently verifiable. The dynamicinsurance provisioning system100 may use a weighting mechanism like the one described above with respect toentity inputs202 to assign weights to theenvironmental inputs204. The dynamicinsurance provisioning system100 may then use the weights when performing any one of various calculations, including, for example, a calculation of underwriting risk. The dynamicinsurance provisioning system100 may considerenvironmental inputs204 to be generally more independently verifiable thanentity inputs202 and may therefore typically assign weights having higher values toenvironmental inputs204 than toentity inputs202.
• A customer'sunderwriting risk214 may be calculated in real-time as entity inputs202 (e.g., customer inputs) orenvironmental inputs204 are received. Changes tomortality data210 may be manually or automatically fed into the system. At the time of initial underwriting, the customer may be provided with an option to select underwriting bands in excess of an initial coverage amount. These bands may determine the medical evidence that the customer should supply to support acoverage amount212 within that band. Such bands may become “binding bands” at the time of policy issuance, and may allow thecoverage amount212 to flex up to that amount without requiring additional medical underwriting. For example, a customer's initial coverage may be set at 1 million Euros and may require the customer to undergo a qualifying process, such as completing a simple blood and urine test. At time of medical underwriting, the customer may choose to select a binding band of up to 5 million Euros and therefore may have to undergo an additional qualifying process, such as an electrocardiogram (EKG) or a treadmill test. This medical information may be gathered, processed, and underwritten by an underwriting information coordination (UIC) module (to be described in further detail below) and the binding band (or range) may be written into the customer's record within a dynamic risk assessor (DRA) module (also to be described in further detail below).
• Thecoverage amount212 for the customer may be the policy face amount for the time period. It may be recalculated based on changes inenvironmental inputs204 andentity inputs202. Thecoverage amount212 may be required or optional (e.g., recommended). For example, thecoverage amount212 may be required if the customer is obligated by a third party to carry an amount of insurance that corresponds to thecoverage amount212. For example, thecoverage amount212 may be required if a mortgagor of a property contractually obligates a mortgagee to maintain an amount of insurance coverage on the property that is equal to thecoverage amount212. Alternatively, the coverage amount may be recommended if the customer is not obligated to a third party to maintain thecoverage amount212. For example, thecoverage amount212 may be recommended if the customer is obtaining or managing a life insurance for no other reason than for his own peace of mind. Thecoverage amount212 may increase or decrease. If thecoverage amount212 is recommended, the customer may be given an option to accept the recommended amount.
• The period for premium calculation may be determined by thecustomer preferences200. A premium calculator module, described in further detail below, receives inputs (e.g., theunderwriting risk214 and the coverage amount212) to determine aperiod premium216. Theperiod premiums216 can be aggregated over a period to consolidate billing. For example, a customer may choose to set a recalculation time interval (or frequency) equal to daily. While a daily premium is calculated, the total for the month is calculated and customer is invoiced at the end of the month. The recalculation frequency may, in turn, affect a frequency at which the dynamicinsurance provisioning system100 initiates a receiving of updates of input data.
• The amount ofcommission218 paid to distributors (e.g., agents, brokers, or independent financial advisors (IFAS)) may be set as a function of premium earned. Thecommission218 may be earned on a time interval basis and from that basis a variable trail-based commission may be paid. A trail commission tracker component, described in further detail below, tracks and disbursescommissions218 to the appropriate distribution stakeholders.Commission218 may be paid on the sum of one ormore period premiums216.
• FIG. 4 is a block diagram illustrating the architecture of a dynamicinsurance provisioning system400, according to an example embodiment. Thesystem400 is shown to comprise a number of modules that receive inputs402 (e.g., theinputs202 and204 discussed above with reference toFIG. 2) and interact with each other to provide outputs404 (e.g., a policy, premium, period cover, or commission amount). The individual components of thesystem400 are now discussed.
• A value integration (VI)module406 builds, tracks, and verifies the customer's net worth. TheVI module406 includes a manual data entry interface and automatic data integration component (not shown) for gathering and monitoring the customer's total net worth. The data integration component integrates with third-party systems and information feeds to determine the value of the customer's portfolio. This integration channel uses a multi-channel (e.g., HyperText Transfer Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), Web Service, or File Transfer Protocol (FTP)) architecture to automatically receive updates of the value of all classes of assets such as stocks, bonds, warrants, annuities, pensions, art, collectibles and property. For assets not automatically updatable, a manual data entry system, using HTTPS, is used to capture asset value. Customers and system users have access to view and update assets or asset values based on system controlled workflow and approval. For each asset an independent valuation attribute is set and a process for updating and validating values is set.
• A customer information (CI)module408 captures customer preferences (e.g., attribute and product preferences), customer information such as living location, and marital status, and regulatory information, such as IHT rules. Customer preferences for medical underwriting bands are specified in theCI module408, and requests are made to an underwriting information coordination (UIC)module410 to schedule examinations, if a determination is made that the customer should provide additional medical information based on a limit of the binding band being reached. Data are updated in theCI module408 through manual updates using a web browser, or auto data feeds such as the customer's cell phone location signal or third party feeds. TheCI module408 may also specify how much a premium or coverage amount can change without triggering the need for the customer to accept or reject the change.
• An underwriting information coordination (UIC)module410 determines and gathers information requirements to support manual and automatic underwriting decision making. TheUIC module410 collects customer information, diagnoses medical information requirements based on the product and customer preferences set, schedules the examination or collection of information, collects the medical information, and provides the information to an underwriting and administration (UA)module414. The medical underwriting bands are presented to the customer at a time of scheduling through theCI module408, allowing for the customer to opt-in for a higher ceiling in the policy binding band to accommodate for greater flex (or range) in coverage amount.
• A health and wellness (HW)module412 provides functionality to measure, monitor and facilitate positive health for the customer. For example, theHW module412 receives manual and automatic data feeds on a customer's weight, BMI, level of fitness, cholesterol, or smoking habits. TheHW module412 has functionality for requisitioning and managing physician statements or electronic heath records.
• TheHW module412 also contains an online survey administration tool for health risk assessment (HRA), and a time-based data model to track and report on changes in customer health. Each information element is attributed with an independently verified source flag and system for updating if independently verifiable. In one instance, each element may be associated with metadata that includes an indicator of whether the information element has been independently verified or an identifier of a system that has performed (or is capable of performing) independent verification of the information element. For example, theHW module412 may receive entity input data related to a level of fitness of an insured entity (e.g., via the online survey administration tool). Based on a determination that the entity input data has not been independently verified, theHW module412 may select a source of additional input data. The selection may be based on an ability of the source to provide input data that can be used to independently verify the entity input data (e.g., a source capable of providing EKG or a biometric input data to verify a level of fitness). TheHW module412 may associate metadata with an information element (e.g., the level of fitness of the insured entity) that indicates whether the information has been independently verified. TheHW module412 contains tools and functionality to enable an insurer to interact with a customer to help manage his/her health. TheHW module412 may share the same customer presentation layer as theCI module408.
• An underwriting and administration (UA)module414 takes real-time data inputs from the other system modules to calculate risk, premium and commission amounts. TheUA module414 generates a new or amended policy, such as new premium, period cover, or commission amounts for a defined time period. TheUA module414 comprises a database and application layer.
• A dynamic risk assessment (DRA)component416 receives inputs (e.g., updates previously received inputs) and contains business logic for determining if a premium calculation or recalculation is necessary and possible based on changes in the customer's risk profile. Based on preset tolerances or thresholds, if a change in one or more input variables such as smoker status, health status, travel/residency, avocation/hazardous pursuits occurs and is within the binding bank, theDRA component416 passes the appropriate value to a premium calculation (PC)component418.
• Based on input from theDRA component416, thePC component418 may perform a calculation of the premium, including a calculation of a period premium or an aggregating of the premium over a period of time. ThePC component418 may calculate one or more amounts of one or more payments of the premium based on input data, including entity input data, environmental input data, or customer preference data. For example, thePC component418 may determine that an entity should pay the premium in a single payment or in multiple payments based on input data received from a wrap platform. Additionally, thePC component418 may determine that entity should make payments at one or more specific dates, over a specific time period, or with a specific frequency based on customer preference data (e.g., preferences of an insured entity or an insuring entity). ThePC component418 may perform the calculation in real-time. An illustration of a calculated premium for a joint life policy is provided below.

• Step 1	The system calculates the current age based on the coverage start
  	date.
  	$t_{\mathrm{Age}}=\frac{d_{\mathrm{CoverStart}}-d_{\mathrm{Birthday}}}{365.25}$
  Step 2	ThePC component 418 identifies the rate tables based on
  	Gender, Health and Smoking Status.
  	TPreferred= f(gender, health, smoking)
  Step 3	ThePC component 418 selects the mortality rate table for the
  	person given the age at the beginning of the coverage and the
  	current year.
  	qMortality= f (tAge, tYear)
  	Note 1: The mortality rate table may be organized such that look
  	ups are based on the age at the start of coverage and the current
  	year as of the calculation.
  	For example, a person being born on Jul. 14, 1971, starting coverage
  	on Dec. 1, 2008, being in Good health, and having given up
  	smoking would have the following mortality rates:

  	Year	Mortality Rate
  	0	0.2976660835
  	1	0.3562437660
  	2	0.4311634821
  	3	0.5129592493
  	4	0.6037844779

  	Note 2: The mortality rate will be interpolated over the user
  	defined Time Period to provide a Period value
  Step 4	The system calculates the life rate based on the mortality Rate
  	and the Health Loading Factor.
  	rLif e= qMortality* (1 + fHealthLoading)
  Step 5	If there is a joint life, the system calculates the joint life first rate
  	based on the two individual rates.
  	$r_{\mathrm{JLF}}=1000*\left(\frac{r_{\mathrm{Life}1}+r_{\mathrm{Life}2}}{1000}-\frac{r_{\mathrm{Life}1}*r_{\mathrm{Life}2}}{{1000}^2}\right)$
  Step 6	The system calculates the core price as follows:
  	$p_{\mathrm{Core}}=\frac{r_{\mathrm{Life}1}*A_{\mathrm{Life}1}}{1000}+\frac{r_{\mathrm{Life}2}*A_{\mathrm{Life}2}}{1000}+\frac{r_{\mathrm{JLF}}*A_{\mathrm{Life}\mathrm{Joint}}}{1000}+c_{\mathrm{Policy}}+c_{\mathrm{Trust}}$
  	cPolicy= cn(1 + i)n+ co
  	cTrust= cn(1 + i)n+ co
  	Note 1: The Core Price is calculated on a yearly basis and can be
  	interpolated for a user defined Time Period
  	Note 2: The Core Price is based on the mortality rate for each life,
  	the assured value, and the cost of the policy.
  	Note 3: The cost of both policy and trust are based on the
  	compound Time Period cost at Time Period X. If one was to
  	compute the cost given the duration the future value of the cost is
  	computed as follows:
  	$c_{\mathrm{Total}}=c*\left[\frac{{\left(1+i\right)}^n-1}{i}\right]+c_o$
  Step 7	The system calculates Travel/Residency Loading price:
  	$p_{\mathrm{TRL}}=\frac{r_{\mathrm{TRLoading}1}*A_{\mathrm{Life}1}}{1000}+\frac{r_{\mathrm{TRLoading}2}*A_{\mathrm{Life}2}}{1000}$
  	Note 1: The loading factors are further based on the number of
  	periods the loading factor is active for.
  Step 8	The System Calculates the Avocation/Hazardous Pursuits
  	Loading Price:
  	$p_{\mathrm{AHP}}=\frac{r_{\mathrm{AHPLoading}1}*A_{\mathrm{Life}1}}{1000}+\frac{r_{\mathrm{AHPLoading}2}*A_{\mathrm{Life}2}}{1000}$
  	Note 1: The loading factors are further based on the number of
  	periods the loading factor is active for.
  Step 9	The System Calculates the price as the sum of the core price,
  	Travel Residency Loading and Avocation/Hazardous Pursuits
  	Loading.
  	p = pCore+ pTRL+ pAHP
  	Note: There maybe additional loading factors that will be used in
  	the future. (This is most likely based on the product offering
  	itself.)
  Step 10	The System calculates the fee and commissions for the current
  	Time Period:
  	$c_{\mathrm{FeesCommissions}}=p_{\mathrm{Core}}\left(\frac{r}{1-r}\right)+\mathrm{<figure-callout\; label="f\; Step"\; filenames="US20110004492A1-20110106-D00003.png"\; state="\{\{state\}\}">f</figure-callout>}$
  Step
  11	The Time Period price is calculated as a summation of the fee
  	and commissions and the core cost:
  	pPremium= p + cFees Commissons
  Step 12	Finally, the yearly premium is divided by the invoicing interval
  	(e.g. 365.25 days in a year):
  	$p_{\mathrm{Daily}}=\frac{p_{\mathrm{Premium}}}{365.25}$

• A trail commission tracker (TCT)component420 calculates and tracks commissions paid to the partners in the distribution channel, such as agents, brokers and financial advisors. Partners can view and model commission revenue flow using this tool. Commission transparency is provided using an online tool to access data within theTCT component420.
• TheUA module414 may include a coverage amount component (not shown) to calculate a new coverage amount for an insurance policy based on one or more data inputs. Additionally, theUA module414 may include a coverage time period component (not shown) to calculate a new coverage time period for an insurance policy based on one more data inputs.
• FIG. 5 is a flowchart illustrating amethod500, according to an example embodiment, to determine variable life protection attributes, based on dynamic inputs.
• During a given time interval, defined by customer preference in theCI module408, customer life attributes502 of cholesterol and weight have increased slightly and the data are manually entered into theHW module412. The updated cholesterol and weight data are fed into theDRA component416 to determine if a rate recalculation is necessary. The changes in cholesterol and weight are within tolerances set by the underwriters using theDRA component416 and the rate remains the same for the next time interval period if all other variables remained constant.
• However, during the same time period the customer got married, moved to Kazakhstan, and theregulations504 changed an inheritance tax (IHT) rate calculation. Tax deductions and exceptions for inheritance tax are automatically fed into theCI module408. TheCI module408 assesses thenew regulations504 against the customer profile, and the changed marital status. This information, combined with regulatory changes, determines a recalculation of inheritance tax is required. The customer new tax liability is calculated.
• Also during the same period, theVI module406 identifies that the customer'snet worth 506 changed, triggered by a 15% decline in the customer's stock portfolio, while the customers other assets remained unchanged. The customer's trigger threshold is set at 5% within theCI module408 and therefore the 15% decline in stock portfolio is sufficient to trigger a request to theCI module408 to recalculate IHT. TheCI module408 iteratively calculates the impact of the new coverage amount on IHT combined with changes in regulatory environment and marital status. A new coverage amount is either required or recommended.
• The premium calculation (PC)module418 receives a request from theCI module408 to calculate a new period premium based on a net increase in coverage required or recommended primarily due to the customer relocating to Kazakhstan and having an increased tax liability. ThePC module418 checks with theDRA module416 to determine if the customer's risk profile changed. In this example, the change in cholesterol and weight does not trigger a risk revaluation. ThePC module418 also checks with theUIC module410 to determine if the increase in coverage is within the medical underwriting band. The increase in coverage is within the medical underwriting binding band and the increase in the premium does not exceed a threshold specified in theCI module408 that would trigger the need for the customer to accept or reject the premium increase; therefore, coverage was automatically provided.
• The new premium amount is calculated and the premium amount sent to theTCT module420 to calculate and disburse trail commission payment to the customer's broker.
Modules, Components and Logic
• Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable storage medium or in a transmission signal) or hardware modules or devices. A device is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a device that operates to perform certain operations as described herein.
• In various embodiments, a device may be implemented mechanically or electronically. For example, a device may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A device may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a device mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
• Accordingly, the term “device” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which devices are temporarily configured (e.g., programmed), each of the devices need not be configured or instantiated at any one instance in time. For example, where the devices comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different devices at different times. Software may accordingly configure a processor, for example, to constitute a particular device at one instance of time and to constitute a different device at a different instance of time.
• Devices can provide information to, and receive information from, other devices. Accordingly, the described devices may be regarded as being communicatively coupled. Where multiple of such devices exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the devices. In embodiments in which multiple devices are configured or instantiated at different times, communications between such devices may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple devices have access. For example, one device may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further device may then, at a later time, access the memory device to retrieve and process the stored output. Devices may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
• The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules or devices that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules or devices.
• Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented modules or devices. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
• The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs).)
Electronic Apparatus and System
• Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
• A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
• In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).
• The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.
Example Machine Architecture and Machine-Readable Storage Medium
• FIG. 6 is a block diagram of machine in the example form of acomputer system600 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
• Theexample computer system600 includes a processor602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), amain memory604 and astatic memory606, which communicate with each other via abus608. Thecomputer system600 may further include a video display unit610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system600 also includes an alphanumeric input device612 (e.g., a keyboard), a user interface (UI) navigation device614 (e.g., a mouse), adisk drive unit616, a signal generation device618 (e.g., a speaker) and anetwork interface device620.
Machine-Readable Storage Medium
• Thedisk drive unit616 includes a machine-readable storage medium622 on which is stored one or more sets of instructions and data structures (e.g., software)624 embodying or utilized by any one or more of the methodologies or functions described herein. Theinstructions624 may also reside, completely or at least partially, within themain memory604 and/or within theprocessor602 during execution thereof by thecomputer system600, themain memory604 and theprocessor602 also constituting machine-readable media.
• While the machine-readable storage medium622 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term “machine-readable storage medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
Transmission Medium
• Theinstructions624 may further be transmitted or received over acommunications network626 using a transmission medium. Theinstructions624 may be transmitted using thenetwork interface device620 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), the Internet, mobile telephone networks, Plain Old Telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.
• Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims (20)

1. A method comprising:

updating at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity;

determining, using a processor, whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data; and

responsive to the determining, recalculating a premium of the insurance policy.

2. The method ofclaim 1, wherein:

the entity input data is biometric input data; and

the environmental input data is a mortality table.

3. The method ofclaim 1, wherein:

the entity input data is a net worth data of the entity; and

the environmental input data is regulatory input data.

4. The method ofclaim 1, further comprising:

identifying a first source of the entity input data;

selecting a second source of the entity input data to verify the entity input data independently of the first source;

using the second source, verifying the entity input data independently of the first source; and

associating metadata with the entity input data to indicate the verifying of the entity input data.

5. The method ofclaim 1, further comprising:

receiving a frequency at which the premium is to be updated,

wherein the updating of the at least one of the entity input data and the environmental input data is based on the frequency.

6. The method ofclaim 1, further comprising:

receiving a change threshold corresponding to the at least one of the entity input data and the environmental input data; and

wherein the recalculating is based on a value of the at least one of the entity input data and the environmental data transgressing the change threshold.

7. The method ofclaim 1, wherein the updating of the at least one of the entity input data and the environmental input data includes interacting with a wrap platform.

8. A system comprising:

an underwriting information coordination module to update at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity; and

an underwriting and administration module to:

calculate a risk associated with providing the insurance policy based on the updating of the at least one of the entity input data and the environmental input data;

determine, using a processor, whether the risk associated with providing the insurance policy has changed; and

recalculate a premium of the insurance policy based on a change in the risk.

9. The system ofclaim 8, wherein:

the entity input data is biometric input data; and

the environmental input data is a mortality table.

10. The system ofclaim 8, wherein:

the entity input data is a net worth data of the entity; and

the environmental input data is regulatory input data.

11. The system ofclaim 8, further comprising:

a health and wellness module to:

identify a first source of the entity input data;

select a second source of the entity input data to verify the entity input data independently of the first source;

use the second source to verify the entity input data independently of the first source; and

associate metadata with the entity input data to indicate the verifying of the entity input data.

12. The system ofclaim 8, further comprising:

a customer information module to receive a frequency at which the premium is to be updated, wherein the underwriting and administration module is to update the at least one of the entity input data and the environmental input data is based on the frequency.

13. The system ofclaim 8, further comprising:

a customer information module to receive a change threshold corresponding to the at least one of the entity input data and the environmental input data, wherein the underwriting and administration module is to recalculate the premium of the insurance policy based on a value of the at least one of the entity input data and the environmental data transgressing the change threshold.

14. The system ofclaim 8, wherein the underwriting and administration module is to update the at least one of the entity input data and the environmental input data based on an interaction with a wrap platform.

15. A machine-readable storage medium embodying a set of instructions that, when executed by a processor, causes the processor to perform a method, the method comprising:

updating at least one of an entity input data and an environmental input data, the entity input data being an input data that is specific to an entity that is insured by an insurance policy and the environmental input data being additional input data that is not specific to the entity;

determining, using a processor, whether a risk associated with providing the insurance policy has changed based on the updating of the at least one of the entity input data and the environmental input data; and

responsive to the determining, recalculating a premium of the insurance policy.

16. The machine-readable storage medium ofclaim 15, wherein:

the entity input data is biometric input data; and

the environmental input data is a mortality table.

17. The machine-readable storage medium ofclaim 15, wherein:

the entity input data is a net worth data of the entity; and

the environmental input data is regulatory input data.

18. The machine-readable storage medium ofclaim 15, the method further comprising:

identifying a first source of the entity input data;

selecting a second source of the entity input data to verify the entity input data independently of the first source;

using the second source, verifying the entity input data independently of the first source; and

associating metadata with the entity input data to indicate the verifying of the entity input data.

19. The machine-readable storage medium ofclaim 15, the method further comprising:

receiving a frequency at which the premium is to be updated, wherein the updating of the at least one of the entity input data and the environmental input data is based on the frequency.

20. The machine-readable storage medium ofclaim 15, the method further comprising:

receiving a change threshold corresponding to the at least one of the entity input data and the environmental input data, wherein the recalculating is based on an amount of the at least one of the entity input data and the environmental data transgressing the change threshold.

Images