Big Banks and Receivables Mass Data
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?
Historical Background
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.
Tweet This