Solvency II has 3 pillars – Pillar I that address capital requirements, Pillar II that is focused on workflow, governance and audit, while Pillar 3 details the framework for reporting. Unsurprisingly, Pillar I has attracted the most attention with insurers evaluating their entire business to determine what the new capital requirements will entail. But the significance of Pillar 2 and 3 is gradually dawning on the industry as institutions realize that compliance with these aspects will be just as important.
Given the volume of data that insurance firms will have to grapple with and report on in order to fully comply with Solvency II, getting the data warehouse and technology analytics in place that will ensure seamless data flow, is a key priority. Institutions that had already significantly invested in appropriate technology might get away with just an upgrade – others will simply have to conduct a complete overhaul that will include the purchase of new systems.
But whether an upgrade or a complete purchase, this expensive investment can come to naught if the business workflows are not re-evaluated and modified to comply with the new regulations. In fact, seasoned IT project managers know that projects that place as much emphasis on workflows as they do on technology, have a higher chance of rapid success/actualization than those that focus their energies on the technology alone.
But what is a workflow?
In the context of compliance with as comprehensive a regulation as Solvency II, workflow does not just refer to a set of successive actions. It must go beyond that and factor hierarchy in the organization, identify distinct business units and divisions, and clearly document how each relates to the other. Workflows must recognize the different roles in the company and what levels of access are necessary for each role to properly execute its function. Finally, the workflow must mirror the organizational model – whether centralized, decentralized or a hybrid.
For Solvency II, each distinct reporting period will needs its own process workflow whose key components will include start date, data acquisition, actual reporting, and the eventual archival of the reports and underlying data.
To be fair, Solvency II is not the beginning of insurer regulation. As an important player in any economy, the insurance industry is traditionally one of the most heavily regulated – often only second to banks. The difference now is that Solvency II changes how reports are done. More specifically, Solvency II stands out for the more detailed reporting requirements, shorter deadlines between reporting cycles and higher degree of control.
With this in mind, developing a reporting workflow for the large insurers that are likely to be most affected by Solvency II is no mean task. The organizational complexity of large multinational insurance firms means every single reporting workflow is the product of several disparate building blocks. The data from these building blocks includes liability, asset and market information as well as several additional external and internal sources of data. The data must be captured, collated, cleaned for errors and inconsistencies, checked for completeness before it is eventually approved for upload into the data warehouse and reporting platform.
Due to the dual control principle outlines in Solvency II, the approval for upload/reporting must be done by someone different from the individual(s) that that retrieved the raw data. This control is not only important for reporting purposes and regulatory compliance, but it is particularly vital for insurance firms where the data used for actuarial analysis and risk computation must be of the highest possible quality. Since industry supervisors will require evidence that the reports they receive from insurers are indeed based on approved data, the reporting workflow must incorporate an audit trail for both automated and non-automated steps.
The dual control inadvertently introduces a potential bottleneck or single point of failure in the reporting workflow. In addition to important data not being available when required, what happens when the person charged with approving the data declines to do so? The workflow must anticipate and develop a speedy resolution process for such exceptions. Resolution would typically involve rejection of data with reasons indicated, correction of data and later re-submission for approval.
Classifying User Actions
Once the data inputs and outputs of the workflow have been identified, the user actions required from start to finish of each workflow must also be isolated. For a clearer workflow, user actions can be broadly classified into business user activities and administrative activities. Administrative activities include setting up reporting cycles, rolling over data from previous reporting periods, defining reporting hierarchy, specifying the risks modeled at each stage in the workflow and loading external market data.
Business user activities include loading liability and asset cash flows, executing modeling processes, generating risk scenarios and tweaking risk factor correlation. It is only by segmenting documenting the administrative and end user processes for each reporting workflow that insurers can move on to determine specific employees responsible for each task.
In the light of these requirements to get the workflow right, it is easy for staff charged with Solvency II reporting to become overwhelmed with all that it takes to attain this high standard. The trick to a properly functioning workflow system is starting small, focusing on the major elements, incorporating the minor aspects and then allowing for the integration of new processes or exceptions as they become apparent.
More on data warehouse.