The following slides were developed while consulting at 12 of top 25 world banks about financial systems from 2013-2016. Although not specific to GenevaERS, it delineates the causes of the problems in our financial systems, and the potential impact of GenevaERS supported systems and the Event Based Concepts.
The recent financial crisis has exposed the systemic problem that the world’s largest financial institutions cannot adequately account for and report on liquidity, positions, currency exposure, credit, market, and interest rate risk and product, customer and organizational performance. The CFO plays a critical role in correcting this problem by leveraging the financial data they already control, as well as leveraging scale to take out cost. But even industry insiders do not realize that financial institutions suffer a unique set of domain problems when it comes to financial reporting.
Current financial reporting systems are antiquated and very inefficient. They were designed decades ago to simply track flow of capital, revenue and expenses at the company and departments levels. The lack of transparency is evident in the increasing costs of the finance function with few benefits to show for the investment. Sarbanes Oxley and other regulations have proven ineffective at getting at the root of the problem and the resulting financial meltdown regulations may well prove similarly ineffective. These pressures create diseconomies of scale which affect the largest institutions the most.
For the most part, existing systems deliver accurate results in summary, but the increase in transparency requires line of site to the underlying causes of those results. Consider if your personal bank account statement or credit card bill only presented the change in balance between periods, but provided no list of transactions. When the statement is as expected, further detail may not be needed. But when the balance is in question, your first response is ‘why’ and you immediately want to see the transaction detail. The same issues are at stake when managing the finances of the enterprise – with the associated cost and consequences considerably higher! A single instance of financial restatement has cost some organizations hundreds of millions of dollars to correct, not counting lost market valuation.
Currently 90% of the money supply in mature markets is represented by digital records of transactions and not hard currency. It’s no wonder that that the volume of electronic finance records being kept has exploded compared to when the systems were first created. Yet our approach to these demands has not been to automate the process of keeping and accessing the details of the transactions. Almost all employees in today’s financial institutions are involved in capturing and coding financial details in some way, and a large number of non-finance employees are involved in the investigative process to locate the additional detail so often required. The effort for this manual intervention is incredibly inefficient and costly.
As we see all around us, computing capacities have increased by several orders of magnitude since these finance systems were designed. However, reporting processes have grown organically as a system of transaction summaries in order to continue to bridge multiple financial systems – but have lacked a single unified approach. This has meant that for the most part the business of financial reporting has not benefited from the increase of computing capacities available today.
A Smarter Planet is founded on financial markets that provide for greater transparency and comprehension of the financial reporting by bank and non-bank entities, allowing the markets to react to conditions in more informed, less reactionary ways. IBM has spent 25 years refining an approach to this for financial institutions. The IBM® Scalable Architecture for Financial Reporting™ (SAFR) system provides financial reporting that is built bottoms up from the individual business event transactions to provide the finest grained views imaginable.
By harnessing today’s computing power and straight through processing approach, the details behind summary data can be made available in seconds rather than days or weeks. Providing nearly instant access to the highest quality financial data at any level of granularity will eliminate the duplicative reporting systems which tend to capture and produce summaries of the same business events for many stakeholders and reporting requirements.
More importantly, it will automate the hidden work of armies of people who are required to investigate details and attempt to explain results, or attempt to reconcile the disparate result of these many reporting systems—a truly wasteful activity caused by the systems themselves. Keeping the details in a finance system that can serve these needs allows for increased control, quality and integrity of audit efforts rather than dissipating them.
Some may question how much detail is the right level of detail? Others may suggest this is too radical a change in a mature, understood and tested set of systems. IBM experience with some of the largest financial services companies suggests that building a finance system. based on the requirement to instrument the most granular level of transaction detail immediately stems the tide of increasing costs, lowers a variety of risks and can be a key driver of transformation of the banks ability to become more agile. In time this approach begins to provide economies of scale for reporting.
SAFR is: (1) an information and reporting systems theory, (2) refined by 25 years of practical experience in creating solutions for a select group of the world’s largest businesses, (3) distilled into a distinctive method to unlock the information captured in business events, (4) through the use of powerful, scalable software for the largest organization’s needs, (5) in a configurable solution addressing today’s transparency demands.
Companies expend huge sums of money to capture business events in information systems. Business events are the stuff of all reporting processes. Yet executives report feeling like they are floating in rafts, crying “Data, data everywhere and no useful information.” Focusing reporting systems on exposing business events combinations can turn data into information.
Although analysis of business events holds the answers to business questions, they aren’t to be trifled with, particularly for the largest organizations. Reporting processes—particularly financial reporting processes—accumulate millions and billions of business events. In fact, the balance sheet is an accumulation of all the financial business events from the beginning of the company! Such volumes mean unlocking the information embedded in business events requires fundamentally different approaches. The 25 years of experience of building SAFR in services engagements has exposed, principle by principle, piece by piece, and layer by layer the only viable way.
This experience has been captured in a method of finding and exposing business events, within the context of the existing critical reporting processes. It uses today’s recognized financial data like a compass pointing north to constrain, inform, and guide identification of additional reporting details. It facilitates definition of the most important questions to be answered, and to configuring repositories to provide those answers consistently. It also explains how to gradually turn on the system without endangering existing critical reporting processes.
The infrastructure software, a hard asset with hundreds of thousands of lines of source code and feature set rivaling some of the best known commercial software packages, is most often what is thought of when someone refers to SAFR.
The Scan Engine is the heart of SAFR, performing in minutes what other tools require hours and days to do. The Scan Engine is a parallel processing engine, generating IBM z/OS machine code. In one pass through a business event repository it creates many business event “views,” providing rich understanding. It categorizes, through join processes, the business events orders of magnitude more efficiently than other tools. Built for business event analysis, it consistently achieves a throughput of a million records a minute. It is highly extensible to complex problems.
SAFR Views are defined in the SAFR Developer Workbench or rule based processes in the SAFR Analyst Workbench or in custom developed applications. The Scan Engine executed as a scheduled process, scans the SAFR View and Metadata Repository selecting views to be resolved at that time.
The Indexed Engine, a new SAFR component, provides one at a time View resolution through on-line access to Scan Engine and other outputs. It uses Scan Engine performance techniques. Reports structure and layout are dynamically defined in the Analyst Workbench. The Indexed Engine creates reports in a fraction of the time required for other tools. Its unique capabilities allow for a movement based data store, dramatically reducing data volumes required both in processing and to fulfill report request.
Upon entering Managed Insights, users select parameters to drill down to increasing levels of business events, and perform multidimensional analysis through the Viewpoint Interfaces. The Insight Viewer enables discovery of business event meaning in an iterative development mode.
The SAFR Infrastructure Software has been configured over 10 years for number of clients to provide an incredibly scalable Financial Management Solution (FMS) for the largest financial services organizations.
The heart of FMS is the Arrangement Ledger (AL). An “arrangement” is a specific customer/contract relationship. The AL, a customer/contract sub-ledger, maintains millions of individual customer/contract level balance sheet and income statements. This incredibly rich operational reporting system supports a nearly unbelievable swath of information provided by scores of legacy reporting systems in summary, with the added benefit of being able to drill down to business event details if needed. Doing so allows reporting high quality financial numbers by customer, product, risk, counterparty and other characteristics, all reconciled, audited, and controlled.
AL is fed daily business events typically beginning with legacy general ledger entries and then transitioning to detailed product systems feeds over time. The business events become complete journal entries at the customer-contract level, including reflecting the impact of time in the Accounting Rules Engine. Rules are under control of finance rather than embedded in programs in source systems, enabling Finance to react to changes in financial reporting standards, including International Financial Reporting Standards (IFRS).
The business event journal entries are posted by the Arrangement Ledger on a daily basis, while it simultaneously generates additional point in time journal entries based upon existing balances, including those for multi-currency intercompany eliminations, GAAP reclassification and year-end close processing. It accepts and properly posts back-dated entries to avoid stranded balances, and summarizes daily activity to pass to the General Ledger. The General Ledger provides another control point for the traditional accounting view of the data. The Arrangement Ledger detects and performs reclassification keeping the arrangement detail aligned with the summary General Ledger
AL also accepts arrangement descriptive information with hundreds of additional attributes to describe each customer-contract, and counterparty or collateral descriptive attributes, enabling producing trial balances by a nearly unlimited set of attributes, not just the traditional accounting code block. Extract processes produces various summaries, perhaps ultimately numbering in the hundreds or thousands, to support information delivery for not only traditional accounting but also statutory, regulatory, management, and risk reporting. The SAFR one pass multiple view capability allows AL to load data, generate new business events, and create extracts all in one process, including loading the incredibly information rich Financial Data Store.
Information Delivery includes multiple ways of accessing the Arrangement Ledger and Financial Data Store. The major window is through SAFR Managed Insights. This parameter-driven Java application provides thousands of different permutations of the data. It allows drill-down from summaries to lower and lower levels of data without impacting on-line response time. It allows dynamic creation of new reports and multi-dimensional analysis of Financial Data Store data. Extract facilities provide the ability to feed other applications with rules maintained by finance. Other reports provide automated reconciliation and audit trails.
FMS can be tailored to work within an existing environment, including working within the existing security and reference data frameworks. FMS is often can be a sub-component of an ERP implementation.
This is a financial system architecture for the 21st century. This is the reporting system architecture for the 21st century. Finance transformation starts with finance systems transformation. Finance systems transformation starts with rejecting the legacy finance systems architecture that provides only summary results. It is transforming the financial systems—the original enterprise data warehouse—into a system capable of supporting today’s information demands.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the author except for the use of brief quotations in a book review or scholarly journal. Posted by permission.
Through employing events-based concepts in systems architecture, organizations can dramatically increase the value and role their central systems play in accomplishing the business mission. Events-based architectural concepts result in system designs that increase the timeliness and quality of information, as well as expand the scope of business functions addressed by a given set of computer programs. Compared to traditional designs, events-based designs result in systems that are better, faster, and cheaper — from both development and operational standpoints.
The concept of event-driven (or events-based) systems started with taking a broader view of the proper role and scope for accounting systems. So we have used the accounting system problem as the basis for our discussion here. However, the same broader view applied to other application areas leads to the same general conclusions.
Events-based concepts discard the arbitrary limitations that historically have been used to narrowly define accounting. Under an events-based concept, owners of an accounting system become anyone in the organization with a need for information about events captured by the system, not just the accountants. While the accountants continue to be important users of the system, the financial statements and other reports accountants need are viewed as simply another byproduct of capturing and summarizing all the events of importance to the organization. Accountants use what they need to prepare balance sheets and cash flow analyses. Managers use some of the accounting data along with statistics about claims paid or policies issued to determine the number and type of adjusters and agents that should be assigned to various risks or locations.
Moving off the old accounting paradigm and its artifacts of invoices, journal vouchers, general
and subsidiary ledger files, etc., to an events-based approach has the effect of simplifying the system architecture problem for accountants, other users, and system builders alike. The traditional accounting system architecture has invoice and disbursement transactions being recorded in a payables subsystem, billing and cash receipt transactions get posted in a receivables subsystem, inventory receipts and issues get recorded in an inventory subsystem, and everything gets posted twice in the general ledger subsystem. Special functions often have to be developed to record cash receipts that represent previous overpayments of invoices or disbursements that represent refunds of credit balances in customer accounts. The effect of this traditional accounting system architecture is to create the multiple system problems of redundant entry and reconciliation within what appears to be the same system. This is why traditional accounting systems usually seem more complex than a general understanding of the accounting problem would suggest they should be.
By viewing accounting events in the same context as all events, a different architecture is suggested because it becomes impractical to build a new subsystem each time some new event needs to be captured. Information about vehicles inspected, miles of road striped, licenses issued, inventory counted, invoices received, invoices paid, bills issued, and cash deposited take on a similar appearance when viewed in the broader context. An events-based architecture for a system allows events to be summarized, counted, and compared at various levels of detail for various time frames according to the needs of the particular user concerned. Trends in product sales/square foot of floor space is of interest to assortment planners in retail operations. Payroll costs divided by miles of road striped by month would be of interest to a highway maintenance engineer. Warranty claims by product and failure type are of interest to manufacturers. Policy claims by risk with policyholder overlays would be of interest to risk managers and accountants alike.
As these examples illustrate, we can still get the accounting information required for financial accounting purposes from an events-based architecture by comparing various classes of events without having to incur the overhead of developing, operating, maintaining, and (probably most of all) understanding separate subsystems just to keep track of these subtotals for us.
Exhibits I-I through IV have been included to contrast the differences between traditional and events-based system architectures.
Exhibit I-I shows the basic architecture that has been used in accounting systems automation for the last 20 or so years.
Accounting events (which are a subset of all events a business would like to plan for, evaluate or control) are captured by a set of computer programs collectively called a transaction processor. The transaction processor takes a subset of information that was present on the accounting events as they were originally entered and posts the transactions on one or more summary files. The full detail is then posted to history files, which typically are archived or otherwise made relatively inaccessible. Report programs specific to the financial purpose being addressed are developed based on the specifics of information that was posted to the summary files by the transaction processor.
To the extent that the purposes being addressed have been fully provided for in the summary files and report programs, information can be obtained from the system. However, to the extent that detail information is required that was lost during the summary posting process, or was not captured at all because it was considered outside the scope of what accounting events properly should include, these requirements cannot be accommodated by the system and must be addressed by a subsidiary system specially designed for that purpose.
Exhibit I-II shows the extension of this result to the primary purposes that traditionally are included as part of the financial function. Financial reporting functions are provided for in a general ledger subsystem. Inventory control and reporting functions are provided for in an inventory subsystem. Fixed assets are a different type of inventory and are provided for separately again …and so on.
Each subsystem characteristically is designed to accept and process the specific events that are the appropriate subject matter for its corresponding area of the business. Event details are posted to inaccessible history files and specially designed summary files become the basis for narrow focus reporting requirements. Visibility to detail events captured and lost in the history files of one system become further removed in the context of the multiple subsystems of what we refer to as the — Financial Subsystems Paradigm. Each subsystem has its own data structures designed to support its particular purposes and business rules for transaction processing and reporting. Maintaining and understanding these subsystems and their interrelationships becomes an area of specialization in its own right. Systematically ensuring that the various subsystems are in balance is a labor-intensive function that consumes much of the energy invested in accounting activities. The numerous inter-system relationships make flexibility practically un-attainable.
Exhibit I-III illustrates the real impact of inside-the-box thinking relative to the Financial Subsystems Paradigm. The mainstream events that make or break business missions often have financial effects, but there also are other information requirements that are above and beyond what accountants need to accomplish their mission. By defining accounting systems narrowly, the Financial Subsystems Paradigm has left most mainstream business requirements to be addressed by still separate subsystems that capture most of the same events needed by the accountants, but with more detailed information attached.
The separate subsystems also have the same basic architecture of traditional accounting systems which is characterized by a transaction processor that archives detail and posts summary files that feed narrowly defined reporting processes. The result is that parallel systems are required to support accountants and mainstream business requirements which in turn creates increasing layers of reconciliation, flexibility, system maintenance, and data visibility problems. The layers of complexity caused by traditional architecture, coupled with the Financial Subsystems Paradigm, have resulted in a virtually unworkable situation from an enterprise standpoint.
Traditional architecture was fit for the purpose in the world of 20 years ago when the economics of computing power forced designers to archive detail (much like manual accounting systems) and automated systems were few in number, limited in scope and non-strategic in nature. A new paradigm is required as we attack integrated system requirements. The events-based architecture illustrated in Exhibit I-IV is a solution that is attractive both theoretically and practically.
Exhibit I-IV illustrates an architecture where the point of departure is a broad view of the business systems problem.
It views the proper subject matter for a system as all business events that an organization is interested in planning for, evaluating or controlling. Rather than building separate transaction processors to capture, edit and post payroll transactions, general ledger transactions, inventory transactions… and so on, one transaction processor can be designed to capture events according to their respective data structures and apply the respective business rules for editing and posting and reporting in a generalized way. It explicitly recognizes that detail information should be accessible so that information requirements can be accommodated as they are identified over time. In addition, it
recognizes that mainstream information require-ments and financial information requirements should be supported through the same data capture, maintenance, and reporting facility.
The practical result of viewing systems problems in this broader architectural context is a consolidated design for the systems that get built. A consolidated design means fewer programs to write, test, and maintain. Fewer interrelationships must be defined, understood, explained, and reconciled. The sensitivity to requirements defined at the outset is diminished substantially because views of the data captured are not limited by the summary data structures posted by the transaction processors.
A consolidated architecture is better because of its flexibility in accommodating changing requirements. A consolidated architecture is faster due to the reduced development life cycle emanating from the underlying simplicity of the concept. It is also cheaper because redundant functions are eliminated and there are fewer objects to build and maintain in the application portfolio.