Fund Allocation features for Group Customer Plans
Group Customers Dynamic Plan Level Allocation Feature
OIPA's retail Policy administration allows a Plan definition to optionally associate a Fund allocation definition, providing a simple access for all Policies and Policy level activities to use as default allocations that are or are not restricted to user change on the Policy or Activity and to copy to entities as desired. Fund Allocations in general are typically needed in cash value products in order to direct investment, withdrawal and transfer of money to/from a specified set of funds. Group Customer Product definition allows Fund associations, but does not allow creation of Plan Fund Allocations that can be copied to a group's member certificates or allow activities to display default Activity Fund Allocations based on the Plan Fund Allocation that a user may or may not change on the activity. The system has added a Plan level Allocation to the Group Customers Plan set-up with a patch delivery of 11.3.1.28. The new feature provides a flexibility that supports applying the same Fund Allocation across all member certificates during the enrollment process, to modify Plan Fund Allocations that impact all member's certificates and to support an individual's member certificate with an independent Fund Allocation. This facilitates the administration of Fund Allocations to the group customer business in support of cash value products and pensions. In order to begin using this feature, a cash value product must associate any number of funds to a Product definition. That allows the creation of a Plan Fund Allocation based on the associated Product's funds. The enrollment process creates a group's member certificates and it is the choice of the configuror to copy the Plan Fund Allocation to each certificate. The decision should be based on the ease of processing with the certificate's fund allocations or ease of processing with the Plan's Fund Allocations and the product's specification that may allow group members to independently change their certificate's allocations. Modifications to the Plan Fund Allocations is considered a change to the Plan that allows it to be in effect during a period of time while other Plan changes can be in effect during different periods of time. Group Customer Plan level Fund Allocations are created and modified in a new tab on OIPA's Plan screen, Plan Allocation. The available funds on this screen are funds associated to the parent Product. This screen supports only independent fund allocation declarations and does not support Model declarations. Use of a Plan Fund Allocation in an activity process requires the Plan to be activated. A new database table, AsPlanAllocationSet, was added to OIPA to persist the user's fund allocation entry so the system can accurately re-display the user's entry in different user sessions. Configuration in the PolicyAllocationScreen has additional access to the Plan's EffectiveFrom date which supports time sensitive modifications to the Plan's Fund Allocation.
Configuration modifications
PolicyAllocationScreen business rule
Access to the Plan's EffectiveFrom date has been added to support time sensitive modifications to the Plan's Fund Allocation. The total set of values available to the <AllocationDate> element is the Policy's PlanDate (Policy:PlanDate), Plan's effective from date (Plan:EffectiveFrom) and the Policy's dynamic field names (Policy:[field name])
XML Syntax Additions | ||||
---|---|---|---|---|
Element | Attribute | Parent Element | Description | Element / Attribute Values |
<PolicyAllocationScreen> |
provided for context |
|||
<AllocationDate> | <PolicyAllocationScreen> |
Optional: This element indicates that funds and models that are available for the Policy's Allocations should be based on the effective date of the Policy or the Plan or the Policy's dynamic date field. |
|
XML Schema content additions only
<PolicyAllocationScreen> <AllocationDate>[Policy:PlanDate | Plan:EffectiveFrom | Policy:[field name]]</AllocationDate> ... </PolicyAllocationScreen>
XML Example content additions only
<PolicyAllocationScreen> <AllocationDate>Plan:EffectiveFrom</AllocationDate> ... </PolicyAllocationScreen>
CreatePolicy business rule
Test conditions are added to the <Allocation> section of the business rule to conditionally create a specific allocation. This is already in use for other sections of the rule and provides the same functionality as those sections. Plan has also been added to the value of the ALLOCATIONSOURCE attribute. When the ALLOCATIONSOURCE attribute has a value of "Plan", the attribute FROMTYPE is unnecessary and the attribute TOTYPE must have a value that is not "01" and "03".
XML Syntax Additions | ||||
---|---|---|---|---|
Element | Attribute | Parent Element | Description | Element / Attribute Values |
<CreatePolicy> |
provided for context |
|||
<Allocations> | <CreatePolicy> |
provided for context |
||
<Allocation> | <Allocations> |
provided for context |
||
ALLOCATIONSOURCE | <Allocation> |
Optional: Allocation records will be copied from the current Activity, from the new Policy's Plan allocations or from the source Policy. |
|
|
FROMTYPE | <Allocation> |
Optional: This attribute identifies the source allocation by its type code. Activity Allocations have a type code of "03". Plan Allocations have a type code of "01". Policy Allocations have multiple type code values and those values cannot be "01" or "03". When ALLOCATIONSOURCE is Policy, this attribute is required and must have a valid Policy Allocation type code value. When the ALLOCATIONSOURCE is either Activity or Plan, this attribute is unnecessary. |
|
|
TOTYPE | <Allocation> |
Optional: This attribute identifies the Policy Allocation type that will be created. It may be a different allocation type code value than the source allocation identified by the FROMTYPE attribute or the allocation type code implicitly identified by the ALLOCATIONSOURCE attribute. |
|
|
<Tests> | <Allocation> |
Optional: This element defines a structure containing one or more conditions that allow the parent structure to continue processing when all conditions contained by the structure evaluate to true. |
||
<Test> | <Tests> |
Required, Repeatable: This element defines a condition. The element is repeated to define an additional condition connected by a logical AND in the code. |
|
XML Schema content additions only
<CreatePolicy> ... <Allocations> <Allocation ALLOCATIONSOURCE="Activity" FROMTYPE="03" TOTYPE="[code]"> <Tests> <Test>[condition]</Test> <Test>...</Test> </Tests> </Allocation> <Allocation ALLOCATIONSOURCE="Plan" FROMTYPE="01" TOTYPE="[code]">...</Allocation> <Allocation ALLOCATIONSOURCE="Policy" FROMTYPE="[code value]" TOTYPE="[code value]">...</Allocation> </Allocations> ... </CreatePolicy>
XML Example content additions only
<CreatePolicy> ... <Allocations> <Allocation ALLOCATIONSOURCE="Plan" TOTYPE="14"> <Tests> <Test>AllocationsMV</Test> </Tests> </Allocation> </Allocations> ... </CreatePolicy>
Ability to use Product level Funds at a Group Plan Level
This enhancement is the first step in multiple steps to incorporate Funds into the Group set-up so that Group insurance/annuities/pensions can issue products with cash value. Rules Palette users can associate the Primary Company's defined Funds to the Product Level through the Product List and Product Status List nodes. In OIPA, the Product assigned Funds and their attributes can be copied to a Plan as it is dynamically created during its Group business setup process. All Product level funds are copied to the newly create group Plan. With this set-up, group Policies and their activities have access to fund processing features (Policy Allocation, valuation and assignment in activities, activity/transaction allocations) as it has existed in non-group related plans.