The Root Cause
The risk and finance lifecycle of a loan is a complex process involving data capture, data transformation, event translations, models, computations that also feed other computations, journalization, and overall workflow. The true issue is that most financial institutions cannot efficiently and effectively integrate (1) the data portion of the problem with (2) the risk and finance function portion of the problem, and then merge everything to complete (3) the backend reporting and analytics portion of the problem.
The diagram below illustrates a typical risk and finance process at a financial institution, where accounting, reserving, and stress testing are used as functional examples. Disparate data sources feed a process that must adequately centralize and stage the data to then feed various risk / finance functions, which are each mini workflows in and of themselves. These functions are NOT mutually exclusive and require significant coordination and orchestration. The results of these functions are then require further re-aggregated and organization to support reporting and analytics.
The mathematics are straight-forward, but understanding when the math is applied, to what loan population it applies, and how the results feed other rules, is complex. The true issue is that most financial institutions cannot efficiently and effectively integrate (1) the data portion of the problem with (2) the risk and finance function portion of the problem, and then merge everything to complete (3) the backend reporting and analytics portion of the problem.
While financial institutions may initially express the pain / problem as a computational problem or reporting problem, the real root cause involves the lack of integration across the end-to-end process. Many institutions initiate projects to address the symptom, but fail to address the root cause. For example, many institutions initiate a loan data mart project to "automate the reporting," but realize far too late that the reason the reporting was manual was due to issues way upstream that cannot be addressed by a data mart. Another example is to purchase a "point solution" that automates a reserve model or that performs non-accrual accounting. These solutions focus on automating the mathematics but do nothing to address the data integration upstream or the reporting / analytical needs downstream. For a point solution to be effective, financial institutions need to spend lots of money addressing all components, as well as the required reconciliation activities, of the process to make each point solution work.
A more holistic approach needs to start all the way back at the source data and go all the way to the end stakeholders. Solving for the data component vs. the functional component vs. the analytical component are by themselves difficult, without then adding the burden of reconciling amongst the various components. . In the end, those institutions that have taken an integrated view of solving for all three by solving the root cause have yielded the highest returns and now have an architecture that is far more adaptable to future needs. This is the approach that serves as the foundation for how Primatics architected EVOLV.