IBOR and ABOR systems occupy their own space within the insurer’s technology stack and cater to different user groups with differentiated needs, knowledge, and skill sets.
IBOR systems provide portfolio managers with a robust security master enriched with market data, security analytics, risk calculations, compliance, and trading optimization tools.
ABOR systems emphasize tax lot calculations like book values, accretion, and gains/losses.
Depending on each specific system’s capabilities, insurance companies also need to make considerations for regulatory reporting, NAIC ratings, capital charges, and agency reporting, which requires an integration of ABOR and IBOR data.
The IBOR/ABOR integration challenge
Integration of these data sets is a common obstacle for insurance companies given the varying levels of granularity and lack of a one-to-one relationship across data sources.
Many-to-one and one-to-many data relationships require specific methodologies to calculate averages, weighted averages, and aggregate other data points. Standard aggregation methodologies are not well defined across the industry; therefore, firms must create their policies and programmatically automate the calculations to ensure the policies are adopted at an enterprise level within the organization.
In cases where both systems do exhibit matched granularity, there is still a challenge to appropriately map data records across systems. Within the insurance space, one common challenge is mapping tax lots across various systems. This is just as much a workflow and process consideration as it is a technology issue. Proper procedures must be enacted, governed, and followed to ensure that required data flows into respective systems at each stage of its lifecycle, and that data flows appropriately and consistently between systems.
Solution: Centralized business logic
There are many options to address these challenges depending on the resources available to the organization. The crux of the discussion typically revolves around the need for business logic, how it should be constructed and maintained, and where it should be deployed into a larger data pipeline.
In general, the preferred method should be an option that centralizes all the necessary logic to a single location that has access to all the necessary data inputs.
In many organizations, this takes the form of a data warehouse. This has the benefit of codifying centralized logic into data structures, archival of all inputs and outputs, robust auditing, and support to downstream processes to deliver files or populate reports.
Other options that could include the encapsulation of business logic into the reporting layer, desktop tools, or any manual task are sub-optimal in almost any scenario.
Data Flows
Achieving a ‘gold copy’
One key capability provided by the centralization of business logic to a holistic data warehouse is that data source hierarchies must be robustly maintained.
ABOR and IBOR have broad sets of data unique to each system, but there is considerable overlap between the two as well.
Given there are data fields that may exist in both systems, it is imperative to have a mechanism to dictate the preferred source, secondary, tertiary, and subordinate sources for each data element. Records that are cleansed and processed in this manner are typically referred to as “gold copy” data.
In insurance portfolios, where accounting drives much of the investment process, ABOR is likely to be the primary source for most inputs covered by the system, while IBOR would be the primary source for the rest.
In a consolidated data set from these two sources, a single data element could have lineage back to either system. When users work with this data, they should understand the provenance of these outputs, elevating the need for reporting metadata alongside any report data set.
Here is an example that shows how a data source hierarchy can be established for any field (e.g. Duration and Rating), with the hierarchy value indicating the order of evaluation.
Data Source Hierarchy
The primary source for Duration is IBOR, and it has provided a value, so it gets chosen. ABOR is the primary choice for Rating, but the value is not available, so the logic moves to the second choice, which is IBOR.
The source of the data values can change over time depending on the availability of data. It is critical to report the metadata explaining the lineage of each field, as illustrated in the third table.
