Turning Core Systems into Information Assets

by Steve Robinson and Bob Chappelear, SAP America Banking Solutions Team

Banking has always been a technology-intensive business. In a search for market share and economies of scale, banks continuously strive to make their core processing systems more capable and efficient. As a result, most back-office functions have become partially or totally automated, resulting in dramatic gains in productivity. Only recently has information technology significantly impacted the front office and the executive suite. Decision-support applications, such as customer relationship management (CRM), planning and forecasting, balanced scorecards, knowledge management, and enterprise portals, bring the promise of relevant, timely, and credible information and analysis to decision makers at all levels in an organization. These applications are dramatically affecting productivity by making knowledge easily accessible, thus improving the quality and timeliness of the decisions supported. In fact, these new beneficiaries of the information age are referred to as “knowledge workers.”

These applications are fueled by source data from the core transaction processing applications that allow a bank to deliver its products and services. Many bankers have found that their recent investments in decision-support technology have become compromised by an inability to satisfy an insatiable appetite for quality data. In other words, no matter how much you spend on sophisticated analytics, you can’t buy the data to feed them. A sophisticated data analysis tool often unintentionally exposes inconsistencies and errors in core processing databases that would otherwise go undetected. This makes decision makers lose confidence in the credibility of the analytics and renders the application nearly useless in the eyes of its intended audience. For example, a comprehensive CRM application should capture and aggregate the activity for a specific customer across all of the systems and processes that touch that customer. If those systems identify that customer differently, a composite analysis of that customer relationship may omit certain services or include irrelevant activity from another customer with a similar name.

Historical challenges with data quality

There are several reasons for this struggle with data quality. First, many core processing systems mined for data, so-called “legacy applications,” were designed to make the most efficient use of the scarce and expensive computing resources that they consumed. Any information not required to process and account for a specific product or transaction was not retained. Generally, the primary information and reporting requirement, aside from a few product-specific batch reports, involved data that had to be represented on the general ledger to satisfy external reporting requirements.

A second reason legacy systems often fail to provide useful information is that reporting enhancements made to aid analysis lack the flexibility to handle customizations mandated by new products. For example, if a demand deposit system is customized to handle checking with interest, many of the reports from that system instantly became inoperative. Some were never revived as development resources were shifted to the next vital processing enhancement required to remain competitive in a deregulated environment.

Another consequence of deregulation—merger, acquisition, and syndication activity—presents an ongoing threat to an institution’s information supply. Many reporting applications are customized for an institution’s specific, often home-grown application systems. The databases that accompany acquired companies and portfolios inevitably require changes. This leaves the surviving institution with the option of either merging the databases into a surviving system, often at great expense with an attendant loss of data integrity, or attempting to bridge systems with incompatible data structures into a common reporting application.

Outsourcing is frequently used to enhance product lines and improve efficiency, but often at the price of degrading information about those products. Outsourcing agreements historically have focused almost entirely on core processing performance with little attention to information requirements.

This level of information management was tolerated because it was possible to maintain an acceptable level of decision support within the context of a specific product or product line. Because banks have traditionally organized and managed themselves along product lines, a silo approach to information management was sufficient. Attempts to create an enterprise-level approach to the management of information assets were usually stymied by semi-independent businesses that were far more intent on being competitive within their own domains.

The information mandate of modern banking

The modern banking environment has created several management imperatives that mandate a superior method of enterprise information management. First and foremost among them is a comprehensive approach to the management of customer relationships. Customer relationship management, or CRM, requires acquiring and managing the activity within a specific customer relationship across all products. Simply reorganizing the bank along customer lines does not make this happen. It requires the ability to positively identify a single customer relationship in all of the systems that come in contact with that customer in a manner that facilitates comprehensive analysis of that relationship.

Enterprise risk management (ERM) is another imperative. ERM also necessitates a composite view across product and organizational silos that allows risk management to be monitored centrally. Risk is incurred and measured in many ways, and includes operational, market, currency, and credit-related risk. It is ideally managed in multiple dimensions, such as by customer, product, geography, and organization. Risk must also be assessed in the context of associated profitability. Banks have turned to activity-based costing techniques pioneered in manufacturing as a way to accurately measure the consumption of shared resources by a particular customer or product. Consistent, reliable data from an institution’s entire technology base is a prerequisite for the support of basic risk-reward decisions.

To answer these challenges, banks have employed a series of initiatives to create order from informational chaos. Before deregulation, many of the informational demands came from the regulatory environment. Fulfillment of these demands was primarily the responsibility of the finance function, and they used the tool over which they had control, the general ledger. The result was ledgers that were called upon to acquire, consolidate, and report information in several dimensions that was well beyond their original purpose of reporting financial results by legal entity. As requirements became more complex, this “fat ledger” solution quickly became untenable.

In reaction, banks quickly became leading adopters of the data warehouse concept. This has taken one or both of two forms in most instances: either a true enterprise data warehousing approach that is all-inclusive and elegant in concept, or a hodge-podge of information-aggregation efforts initiated within specific subject areas, e.g., human resources, risk management, marketing, finance. These have come to be known as “data marts.” The former approach has become discredited as a result of legendary projects that spanned many years and consumed millions of dollars only to die of their own weight or be compromised by the shifting sands of merger activity. The latter, while often generating near-term benefits for the lead organizations, creates a set of incompatible and irreconcilable reporting applications that are inadequate to support institutional objectives such as CRM and ERM.

Technology vendors, along with systems integrators have created many fine products, and generated handsome revenues by addressing the need to acquire, refine, and warehouse data from disparate and incompatible sources. Many have gone the extra step of creating banking-specific enterprise data models that can be customized to fit an institution’s specific needs. Computing resources have become so plentiful and inexpensive that old constraints which limited analytic capacity have given way to sophisticated data analysis, reporting, visualization, and predictive modeling tools that can be highly effective decision enablers. These tools are installed with great promise, only to disappoint in practice as they are placed on top of a data management infrastructure that cannot keep pace with them. This is because data transformation and scrubbing technology only treats the symptoms of the quality problem, not the underlying causes of it.

A new approach

The new internal and external mandates for information demand holistic, comprehensive approaches to data quality and stewardship. Leading-edge institutions are migrating to proactive process-oriented disciplines that protect the value of institutional information assets in all aspects of bank operations. Some of the best practices include:

Data custodianship discipline—Much of the corrupt data within banks is the result of process failures. A common error is the abuse of fields on data entry screens such as tracking the name of the lending officer in an address field when there was no other way to satisfy that requirement. Automated edits can always be circumvented and expediency will always prevail in day to day operations. Today’s desire among most banks for a customer-centric approach to management has made this problem even more glaring. Organizational silos prevent one area of the bank from sharing information with other areas. Many banks have addressed this issue by reorganizing along customer-oriented lines of business. In doing so, all bank personnel must be made aware of their role in the protection of information assets and the effective use of those assets in the course of their work. Institutional policy and culture should show no more tolerance for information abuse than they do for poor customer service or theft of assets. Several institutions have successfully established cross-functional departments dedicated to data management and the power to enforce standard practices across the firm.

Core system replacement—Many banks mandate that the groundwork for information acquisition and access be laid during the design phase of core systems replacement projects. In addition to incorporating the requisite product features and functions, replacement systems should capture and retain all data about customer interactions across delivery channels and product portfolios. They should also identify the analytic and external reporting dimensions (e.g., organization, GL account, customer, product, channel ID, geography). This, in turn, requires that those responsible for the implementation of the data warehouse and analytic applications become an integral part of the design team for the core system replacement. The same discipline applies to outsourcing. Outsourcing agreements and contracts should include explicit terms for the provision of operation data for analytics and reporting. Some outsourcers will also offer related analytic applications as part of their service.

Core system consolidation—Banks should make consolidation of product delivery systems a priority after any acquisition. Standardization of data management practices is always difficult to achieve across a large portfolio of products. It is nearly impossible if there is redundancy within that portfolio. Several of the largest U.S. banks are in the process of massive and expensive efforts to consolidate the overlap in their core processing environments created by hastily executed mergers and acquisitions.

Adoption of emerging standards—After several unsuccessful efforts, the industry is now beginning to adopt a set of standards for data and metadata management, as well as programming standards for analytic applications. Many organizations, including the American Institute for Certified Public Accountants, have recently been involved in establishing reporting standards that can be used across multiple venues. For example, the XBRL standard allows institutions to enter information only once, and that same information can then be used to create financial statements, website documents, SEC filings, credit reports, etc. XML is quickly gaining favor as the standard for data movement between applications and warehouses.

The role of vendors—Forward-thinking banks prefer application vendors that incorporate information management into their products and share common data/metadata across applications. An example would be a central customer information file that houses all data related to that customer relationship in one place for use by all products and processes that touch that customer. These vendors’ products offer open data warehouse interfaces, adhere to industry and technical standards, and provide a framework from which multidimensional reporting can be accomplished. A few of these vendors offer analytic applications, including profitability analysis systems, risk management systems, and data warehousing facilities that come integrated with their core processing systems. This level of integration not only accelerates implementation of the products, but also lowers the overall cost of ownership and lays the technical foundation for a holistic information management process that adds value through accelerated product delivery and superior decision support. This provides a true competitive advantage.

© Board Member Inc. All Rights Reserved