Annuitization with Overflow

Annuities are retirement products that may be used to help an individual increase savings or generate a guaranteed stream of income. Annuities that are used to increase savings are called deferred annuities. Annuities that generate a stream of income are called income annuities. Many times both types of annuities are used to create a single product that has an accumulation phase (deferred annuity) and a payout phase (income annuity).

When both products are used to create a single product, annuitization must occur to change the product’s behavior from that of a deferred annuity to that of an income annuity.

The Annuitant can choose to receive the payments for life or for a specified period. In addition to choosing the length of time for the payments, the annuitant can choose the amount. The payments are driven by the types of underlying funds associated with the annuity. The funds associated with annuities can be either variable or fixed. Variable funds will be subject to market conditions and can vary during the accrual phase and the payout phase. Fixed funds on the other hand will increase by a specified percentage during the accrual phase and have a specific amount paid throughout the payout phase. If the annuitant outlives the period specified in the annuity contract (i.e. 20 Year Certain) payments will continue for the remainder of the annuitant’s life.

In OIPA, annuity products use Benefit Split functionality to generate a policy’s guaranteed payment stream upon annuitization. Funds may be variable, fixed or a combination of variable and fixed. This functionality as well as an enhanced Fund Allocation structure facilitates a seamless transition from the accumulation phase to the payout phase of a Variable Annuity product. The withdrawal transactions can also accommodate the situation when the annuitant outlives the contract through an overflow process.

Benefit Split records can be created for scheduled or nonscheduled benefit payments or for annual benefit leveling. Activities can also be used to emulate these behaviors as needed. XML tags and attached business rules support this functionality

Important   If Benefit Split functionality is used, then all funds on the policy must be set up for Benefit Split.

Components of Benefit Split Processing

There are three major components of the Benefit Split functionality:

  • creating (adding) Benefit Split records: Benefit Split records are created in the global Calculate General rule on the Benefit Split tab in the visual editor.
  • reading (calculating) the value of Benefit Split records: the GetBenefitSplit Math Statement is used to retrieve the benefit split records.
  • updating (changing) existing Benefit Split records: the DoBenefitSplitChange rule is configured on the transaction initiating the change (typically Transfers, Purchases and Withdrawals). DoBenefitSplitChange supports variable to variable transfers as well as variable to fixed, and ABL purchases. In addition to changing the Benefit Split, it can also be reassigned from one fund to another.

OIPA Benefit Split on Segment Screen

OIPA Benefit Split on Segment Screen in OIPA

Code Names Needed for Benefit Split

The following code names and values must be created to support Benefit Split.

  • AsCodeFundType 03: this code is for FixedBenefit. It is a zero interest, fixed annuity payout fund.

  • AsCodeBenefitSplitType 05: this code is for Current Benefit Segment. It is used for active benefit split records that are paying out.

  • AsCodeBenefitSplitType 51: this code is for Deferred Benefit Segment. It is used for deferred life contingent benefit split records.

  • AsCodeBenefitSplitStatus 01: this code is used to indicate Active status. It is used for active benefit split records.

  • AsCodeBenefitSplitStatus 99: this code is used to indicate Deleted status. It is used for segments that were deactivated due to recalculations and update activities.

Preliminary Configuration Steps

There are four steps that must be taken before configuring Benefit Split.

  1. The Fund Allocation structure must be established before using the Benefit Split functionality. Since child funds typically offer a choice of benefit funds it is important for this to be configured correctly.
  2. Configure the FundScreen.
  3. Parent funds and Child funds must be configured. Benefit funds are always attached to a child fund in a one to one relationship.
  4. The Fund Screen must be associated with the plan and the funds.

High Level View of Benefit Split Configuration Steps

Once the preliminary configuration steps are complete and the business rules and code names have been created, the actual benefit split configuration can take place. The significant steps involved in this process are shown below. Follow the links for additional information on any step in the process.

Refer to the Benefit Split Prototype to see an example of all configuration described below.

  1. Create the Calculate General business rule with the supporting Benefit Split fields.
  2. Create the SegmentName rule for Benefit Split. This segment will point to the Calculate General rule that was configured in the previous step and include any dynamic fields that may be required by business processes.
  3. Create transactions. Benefit Split functionality can be accomplished using transactions (activities). Configure the Assignment Types that will be needed inside the transaction XML.There should be at least two transactions created; a payout transaction and a spawned disbursement. Additional transactions can be created to support other business needs for annuitization. Transaction elements are discussed in more detail in the section below.
  4. Add Attached business rules.