The third in a series of videos about financial system transformation in financial services, this time dealing directly with the data that must come from the source systems and be placed in the platform, the subject of the prior two videos.
This video is longer than my typical videos, but I have attempted to be quite comprehensive on a topic I have studied for decades. The form our data takes through the data supply chain from transaction capture to analytical and reporting uses is not well considered, and at times leads to very simplistic assumptions about how to improve it.
Source Data
Let’s begin by considering what data looks like in the source system. By and large, it is concerned with transaction data. But in most systems–particularly those with higher volumes–there is also balance data, which gives a perspective over time.
Posting
The process of updating the balances is done within a posting process. Many legacy systems do this daily, but even systems that have shorter periods (every second?) perform this function consistently because balances always represent activity over some time period.
Cut Off
Because of this relationship, there is almost always some form of cut-off, a moment when transactions are no longer included in the balance. In financial reporting, knowing what period is covered by the report is always important.
Dependent “Transactions”
The source system transactions are not the only transactions in the organization required for various purposes. Some transactions are created in the source system at the time of the customer transaction, but are dependent upon the customer transaction to determine their amount. For example taxes and commissions.
But quite frequently even these transactions which are exposed to the customer are not the only transactions needed. Other dependent transactions are also created, which are not typically shown to the customer, like reserves for losses and such.
All these dependent transactions are also needed for financial reporting in some shape or form.
Dependent Systems
It may not be clear where in the data supply chain these dependent transactions are created. They might be created in the source system at the time the original transaction is captured. But they might also be created in other systems after the source system.
One particular type of system which creates dependent transactions is called Accounting Rules Engines. These systems are what create debits and credits–one well defined set of dependent transactions. These feed data to the enterprise reporting repository called the General Ledger.
The General Ledger is a particularly important financial reporting system which gives the enterprise its view of business. Instead of presenting the individual customer perspective, it presents the enterprise’s perspective in total. And this critical function needs to typically be completed before business begins the next day, so the enterprise knows where it stands and what it can and cannot do for business the next day.
In some cases, the dependent transactions (including most General Ledger debit and credit feeds) are created in aggregate, not individually for each customer transaction.
Data Warehousing
A simple solution which ignores all these extra transactions is data warehousing. The premise behind data warehousing is that if one simply gathers all the data into one location, reporting is enabled. But without clarity about what is meant by “all the data,” and without a way of retaining the linkages between the originating business events and the dependent transactions, reporting processes are often like attempting to reverse engineer the transactions generation processes. Often they are not very accurate or insightful.
As an example, just the required data–both originating business events and dependent accounting, risk, analytical and other process transactions–required for the Federal Reserve FR 2052a Complex Institution Liquidity Monitoring Report is astounding.
An Instrument Ledger
A more effective solution is to construct an instrument ledger, which retains the details needed for so many of the perspectives, and the relationships needed for understanding what the data means.
Start by focusing on the General Ledger, the most important ledger in the enterprise, containing the enterprise view and highly audited. The General Ledger balances cannot be wrong, or the organizational existence is in jeopardy.
From the General Ledger, locate the originating business events and dependent transactions required to make the GL balances. This is the beginning set of data needed for many perspectives. This data can be supplemented with additional business events and dependent transactions for additional data supply chains.
Build processes which bring these more detailed transactions together for reporting–while maintaining the linkages and relationships between them. A ledger is an effective way to do this, because ledgers organize data and relationships over time. This becomes an Instrument Ledger if it retains visibility to the customer/contract levels of detail needed for creation of some many of the dependent transactions.
Updating this ledger within the constraints of the daily financial cycle, so that the outputs are available at the start of business, and having it retain the levels of detail needed for all the important perspectives that are required is a major systems challenge. Commercial packages have not been designed with these goals in mind, but it is what our increasing data hungry world requires.
This is the solution to finance transformation in Financial Services.
This is episode 255 of Conversations with Kip, the best financial system vlog there is. Literally learn more–about ledgers and financial systems–at http://www.LedgerLearning.com
Previous videos in the series
Leave a Reply