Transactions That Process Projections
Occasionally insurance companies need to run projections that mimic a policy’s behavior as if it were processed on a day-to-day basis using normal processing. When projections are run, the logic typically uses a subset of the same calculations, retrievals, business processing logic, and updates as those used during normal lifecycle processing.
Valuation requires some additional consideration. When valuation is needed, a starting value based on the funds is used, and then further crediting is handled through a fixed method (either a single field or a string of values that is pre-determined.) The same rules will be processed for both the projection and regular processing. In this way, the system ensures that the end results are the same for calculations, costs and updates when the input parameters are the same.
Typical situations where projections would be used include annual statement reporting and Illustrations, including new business and proposals.
Scenario
An annual statement for a Life Insurance policy needs to project from the current date to the maturity date of the policy. All current policy information is used. If there are any loans on the policy, these carry forward (without additional loans), and reflect riders/benfits dropping off of the policy at the specified times. This projection uses all of the calculations and processing as with normal “in force” policy processing. There are two projections made: one for “with premiums paid” as reflected in the “anticipated annual premiums” on the policy information, and the second is with “no premiums” paid. The values that are returned are the Projected End Dates for both with and without premium.
How Projections Work in OIPA
OIPA sets into memory the beginning values for each Instance Data Element, which reflects the current information in the Database. This can be performed multiple times using a single activity. Fields that are updated throughout the projection processing that also need to retain their original (current) values are loaded via math variables or a collection before the rest of the math commences.
OIPAchecks to see if a value for a field exists in memory before looking to the database to retrieve it. TheTable name : Field name (e.g., Policy:FieldName) syntax does this as well as the POLICYFIELD and SEGMENTFIELD math variable types. OIPA always returns the latest value in memory first.
Only the values in memory are updated: the actual database table value is not changed during the projection processing. It is possible for a field's value in memory to change any number of times throughout the activity processing.
Overview of Configuration
The Math pane of a transaction is used to configure projection processing. The Palette window contains a category named Update. The MathUpdate element can be dragged and dropped into the Math pane. This element is used to hold the math variable (or literal numeric value) that is copied into the specific Table field in memory. The FIELDNAMEattribute holds the name of the Table field to update in memory. The TYPE attribute identifies the source table of the record type to update. SegmentFieldCollection will update the named Segment field records with the collection values. Both of these attributes are required. An optional SEGMENTGUID attibute is required only if TYPE equals SegmentField. It identifies the segment record to update.
MathUpdate Element in Palette Window