Through interactions with multiple people in explaining these concepts, I have realized that in some measure what I am talking about might be called a data “supply chain.” One of the big trends of ERP implementations for manufacturing organizations was supply chain consolidation. The systems allowed creating a very efficient process to procure materials for manufacturing goods and then distribute the finished products, providing significant savings. The systems did so by integrating with key vendors and significantly streamlined processes.
The same is possible in reporting and analytical processes. As we have noted in Business System Architecture, we have traditionally built a new, single-use supply chain for every reporting need, taking the business events – transactions or acts of commerce – to the reporting use for them. The cost of IT is driven by the number of components that must be maintained: Systems, programs, scripts, copies of data, processors, disk farms, network devices, etc. Each time we write a new program and do not retire an old one there is a good chance we have increased the IT budget in some way, even if only marginally1. Each time IT creates another data supply chain, feeding the results of the same business events to another reporting application, we increase the cost of IT.
Establishing entire new supply chains is much more expensive than adding just a new reporting output. An entire new supply chain requires a data acquisition layer, a target repository, and posting processes of some kind (even if only in the database), as well as a reporting layer. Then there are business processes such as reconciliation and adjustment that must be performed for systems with high data standards.
An alternative, of course, is using the finance data backbone discussed above to reduce the data acquisition, target repository, posting and some portion of the reporting processes. The cost of establishing the data backbone is more than a traditional reporting “supply chain”, but the per-unit cost of processing each business event through all the differing supply chains is less.
The Risk Supply Chain
One of the major supply chains built in financial services firms over the last few years supports risk reporting. Risk reporting started much later than the basic financial reporting. In many cases it has established a much newer supply chain of business events, and this supply chain continues to be enhanced as additional regulatory requirements emerge, like those issued as from Basel, Switzerland known as Basel Accords.
Because the attributes needed for risk analysis are many more than those traditionally kept by the finance system, the risk supply chain requires much lower levels of detail. Longer periods of history for account details are also typically desirable. Thus it has been even more challenged in its use of the basic reporting or subsystem architecture. This need for detail is mitigated because the risk system does not need to capture all financial events, but rather focuses much more on the originating product system postings, ignoring the offset side of the accounting system and financial events occurring in other systems which are not financial product related. The risk system also does not typically deal with some aspects of time, such as accruals processing.
In my discussions, some have suggested that instead of re-mediating the finance supply chain, we should switch and use the newer risk supply chain. If someone were to determine to use the principles outlined in this book to build the risk system first, it might be a simple thing to change the system components to have the following names.
Figure 149. Risk Management Platform
Building out the risk system first, I believe, should still follow the approached outlined in the SAFR method:
- Locate the summary level financial feed from the originating system;
- Determine those portions of the feed that relate to both the finance and risk systems;
- Drive the risk portions to lower levels of detail ensuring details balance with the summary level finance feed.
If this approach is not taken, the risk system and the finance system will never be truly reconcilable. Following this method is likely still the right approach for the simple reason that in spite of all the shortcomings of the finance system, the risk systems are still reconciled to it rather than the other way around. The requirements are in the data.
When this risk-only system is turned on, it should be approached as a parallel run with the finance system, similar to when we start up the FMS solution. The FMS solution typically only runs in parallel for a short period of time before the legacy system is cut off in some way (perhaps through tranching, as described in Find More Detailed Events). The risk solution may run in parallel for years before it is determined to add to it the remaining finance data, if they ever do.
Integrated Risk and Finance System
Figure 150. The SAFR Financial Management and Risk Solution
The picture contains more details of the source systems, TTL, Accounting Rules Engine, Data Store and Reporting Layers. Additionally, it clarifies the relationship of the traditional financial expense processes, such as accounts payable, payroll, etc. to the platform. These functions are typically handled by an ERP package of some kind.
In this respect, though, rather than the traditional integration of these modules with the GL, the GL is tightly coupled with the Arrangement Ledger, or AL. A few key aspects of the Arrangement Ledger are worthy of emphasis.
- Finance: The component is a finance owned component. It is not a transaction processing, settlement or other operational subledger system. Finance specifies the coding structures and processes. It is tightly coupled with the General Ledger.
- Detailed: It contains detailed data, often at a customer/contract level providing greater transparency for a greater set of purposes.
- Integrated: The AL is integrated with the source systems, but also with the integrated enterprise. Because its code structure starts with the General Ledger view, it encompasses the entire organization.
- Ledger: It is not a simple repository of source system data. It is not a simple data warehouse. Rather ledger functions are performed within it, like multi-currency processing, eliminations and consolidations, reclass and year-end processes. Thus drill down from any of the General Ledger balances is possible.
The use of on-platform or off-platform calculation services is reflected with the addition of the extract and integration rules processes. These would be used to extract that data from the AL needed for risk engine analysis. The outputs from that analysis may be used independent from the finance data. But as the diagram shows, there is only one supply chain of data into the platform, thus helping to ensure consistency.
The implications are much more than simply eliminating another set of systems or supply chain of the same business events to the risk systems. As I have watched the discussion on capital reserves funding that financial institutions must keep in wake of the 2007 financial meltdown, I have come to see that financial reserves are a question of risk, no doubt, and some portion of risk can be offset by knowledge. Increased transparency in reporting – visibility to the underlying causes of results and the current status of instruments – can significantly reduce the risk of default.
Undertaking building the type of system I have proposed is very expensive, as far as typical IT projects are concerned; it is a reworking of the entire information supply chain for organizations. I therefore have a proposal. I recommend that funding be provided by a corresponding reduction in capital reserves required for organizations that under take the initiative.
Extremely small changes in capital reserve laws can lock up – effectively consume – billion and billions of dollars. The changes in the systems needed are nowhere near that expensive. This is a reasonable approach, motivating the appropriate behaviors to build the new generation of reporting systems that will go much further to solving the financial reporting problems. It will be much more effective than focusing on indirect controls, or other types of regulation.
It may be possible, though, to take the solution even further, providing a greater base for the total reduction in IT costs.
Parent Topic: Part 7. The Plan