State Street Bank is nearing the end of a three-year installation of a staggering $300 million mass data project that will remap the roadways to a custom-built data warehouse. By all measures, that size of an investment is daunting for an industry, never mind for a single institution. Given State Street’s relative size to larger bank rivals, the potential for even larger investment amounts might be in the offering as others follow suit. Conversely, proportionate investment amounts are almost unthinkable for non-top-tier banks, further widening the competitive gap in a consolidating industry.
State Street Bank officials figure they will reap $575 million to $625 million cost savings by automating such tasks as software development. That’s significant because the bank writes nearly all of its own software for asset management, trading and transaction services. Plus, the bank’s private cloud promises a fresh revenue stream from clients who want to outsource their data and back-office applications there.
The project is being closely watched for several reasons but one, certainly, is to determine if big data can generate revenue. Still, how will banks approach the process before even contemplating the tasks of execution?
In an earlier article for BS&T I discussed the fact that islands of disparate data aren’t a new phenomenon for banks; it has its origins in how banks were initially chartered. What is new is how banks today are capturing and using the data to its fullest potential. They were organized fundamentally as deposit takers and lenders. Bank management considered asset and liability management key drivers as they began to assemble rudimentary data for management reporting. This fundamental view of data segmentation continues to drive the use of data in today’s banks.
The internal organization of banks along multiple gross segments further compounded the view of data. Those segments were commercial/retail; loans vs. services, and even banking vs. credit cards. Inevitably, specialization has further isolated the islands to the point that they can be viewed as continents unto themselves.
Fast forward the clock, the sheer magnitude of data is going to explode exponentially within banks in the next few years as they access vast data libraries and try to harness social and streaming media data to determine customer preferences and risk.
As banks look at this topic, is it even possible? How will they justify the cost? Is there a practical approach?
Steps Toward Receivables Mass Data
More than any other payment transaction set, receivables data proves to be the messiest transaction data to handle. Only 10 percent of remittances are included with payments in a format supported by a standards group. Add to this the capture and exchange of images, spreadsheets with invoice details and ad hoc emails detailing invoice exception instructions and the task of normalizing receivables data can be monumental. No one transaction payment silo is equipped to handle this task.
What are the required steps?
1) While mass data designers would argue that clean data isn’t essential, a consistent view of data becomes the fundamental starting point for developing a receivables mass data strategy.
Given the plethora of bank transaction processing systems, the essential first step involves normalizing the transaction data into a common view (schema). Establishment of the view can be achieved by using emerging industry standards (i.e., ISO 20022) or an internal proprietary view inclusive of all of the transactions sets. The major hurdle becomes the definition effort and the time to determine the normalization process.
Herein lies a major distinction: Processing transaction data is the fundamental customer requirement. The derived insights of mass data are secondary to the primary need to provide clean transaction data for input into customer’s transaction processing systems. A comprehensive receivables schema and data store designed and built with a view toward reuse in a mass data strategy inherently improves both processes.
2) More than 40 percent of remittances require operator intervention. Even those that, theoretically, can automate the process fully (e.g., lockbox or electronic data interchange - EDI) still need initial programming to create systemic interfaces and data-capture solutions for exception handling. Three key elements are necessary to ensure receivables data is useable and actionable.
• Business rules and self-learning are essential to reduce the size of the repair process.
• Payment exceptions presented in a manner that is agnostic to the payment channel.
• Customer access and involvement in the repair process is possible through a common exceptions process.
As the ultimate stakeholder in the quality of the data, customers prove essential to the quality process. Unfortunately, receivables processing remains a disjointed process both for customers and banks with many interfaces connected to transaction payment silos. Abstracting the data from the source transaction systems into a receivables data store removes the complexity of multiple payment platforms and facilitates the repair of the data by the customer. And the customer, as the ultimate stakeholder for the quality of the data, thus insures the veracity of the data as it applies in mass data analytic tasks.
As described, developing a receivables mass data approach requires many interrelated parts and challenges.
Some banks already have taken the initial step toward realizing a receivables mass data approach. Payments hubs, both payables and receivables, are being deployed by banks to address customer payment-optimization needs. Hubs by definition must use a consistent data schema to facilitate transaction decisions and apply rules engines to perform many of the tasks.
As transaction-processing engines, hubs aren’t designed for data analytics. But they do provide useful elements in developing a payments mass data strategy:
1. Aggregation – It disintermediates the numerous other transaction systems and associated data bases into a single data instance, eliminating the need for multiple new interfaces into a mass data strategy.
2. Consistency – It normalizes data across the other transaction silos into a common data schema.
3. Data quality – The data has been enhanced to meet the primary transaction needs of the customer and it’s of a higher quality going into a mass data strategy.
The investment in hub deployments by major banks becomes the first directional step in realizing a mass data strategy. It provides the ability to reuse investments in hubs for mass data as some of the fundamental and costly efforts required of mass data (i.e., aggregation of the data, normalization and quality) already have been addressed.
Taking the First Step
Historically, Comerica Bank has led in Midwest lending and treasury services to its corporate customer base. Faced with direct competition from larger banks, it is reviewing new approaches to address its customer’s needs. “Our customers’ needs were changing, and our receivables solutions needed to evolve to keep in step with those changing needs. Our clients rely on us as their trusted advisor to help them be successful. In this case, success means helping them manage their receivables data more effectively and efficiently,” said Deb Stevens, vice president/ product manager for Receivables Products.
Comerica has plans to offer a receivables platform centered on a central database (hub) that aggregates, normalizes and synthesizes data for new receivables product development. “We are testing ways to eliminate our customers’ difficulty in dealing with multiple product silos for information. We are seeking to allow for their direct access to enhance data quality, and accelerate the application of the data to their internal systems. Our new receivables approach is now one part of a larger strategy to address customer data across the enterprise and provide us new insights,” according to Stevens.
Lawrence F. Buettner is a senior vice president at Wausau Financial Systems, which provides receivables technology for financial institutions. He has 30 year of experience in financial treasury management, and was an SVP at First Chicago.