Creating the Image Data Warehouse

“We didn’t actually overspend our budget.
The allocation simply fell short of our expenditure.”
-Keith Davis

For years, banks have struggled with the overall design of check/document imaging systems. Online reports were usually on one system, imaged checks and statements on another. Documents could be imaged on several – one for signature cards, one for loan documents, one for invoices, another for lockbox. As a result, one of the biggest struggles for banks has been trying to decide how many platforms/products to purchase.

This decision was made somewhat easier by two factors:

• Few systems existed that could support all types of images at a price that wouldn’t deplete the entire net worth of the bank.
• Since many initial investments were made to support an individual operational function (e.g. signature cards), a single platform wasn’t critically important.

Forward to 2003. While everybody knew imaged checks would become mainstream, few were right about how fast it would happen. Viewpointe alone images more than 60 percent of the 40 billion checks written annually. The Fed and other imaging/presentment services (e.g. the Endpoint Exchange Network) account for most of the rest. Banks internally image most of the on-us items that don’t get routed.

Imaged document systems are becoming more affordable, and the number of loan docs, signature cards, lockbox invoices, internal bank invoices, appraisal information, withdrawal slips, teller receipts, et al that is becoming available for access and research is proliferating at a biblical level.

Maybe it is time to reexamine exactly how banks will treat all of this information and manage it as an asset and a service and efficiency tool. As luck would have it, we have some case law to work with – data warehouse.

On paper, an enterprise repository/source of data makes perfect sense. Information as a corporate asset… integrated reporting… It is no secret, however, that most initial forays into data warehouse did not result in the imagined payoff. Any credible ROI that banks have realized on this investment has been very recent. Why is this? Here are two reasons that certainly hindered success:

• The warehouse never became the “enterprise repository.”
  Most bank data warehouse systems did a good job of capturing the information stored in the core system. However, while there has been a concerted effort to gather information from other systems (loan origination, leasing, trust, separate loan servicing systems), it hasn’t eliminated a fractured group of databases in most places. Passing data between systems, when necessary, is still manual and cumbersome. In other words, we haven’t institutionalized the warehouse.
• Analysis was never intuitive and easy.
  For all the talk about how Crystal, Forest and Trees, and other front-end report writing tools made life easy for the non-database administrators among us, it isn’t really true. Have you used these packages? They are robust, and they can produce good-looking, useful reports, but they are not easy to learn and use for anything but fairly simple list-and-total efforts. And for good reason – most meaningful reports are complex in terms of how many places they need to look for data, fields they need to calculate, ways they need to show trends, etc.

The net result is that there are still lots of local databases, identical data stored in multiple analysis systems (just think about all the spreadsheets where we store an account balance!), and a lack of corporate commitment in many banks to use an enterprise warehouse.

Back to imaging. At the end of the day, all of our images are no more than a data warehouse of pictures. Like the data warehouse, the images must be managed as a single enterprise asset. Because the records are static in the sense that they don’t need to be updated, the images are simpler. However, in the long term there will be more sources. Think about it. Checks may be stored at a Viewpointe-like service provider, at the Fed, locally (on-us items), at the point where they were converted to an ACH item, or elsewhere. Documents may be stored locally, at a service provider’s site (e.g. lockbox provider, third-party loan, credit card payment service), or elsewhere. As our clients in Massachusetts would say, that’s a wicked big warehouse.

Banks will expand use of imaging quickly, and our Gonzo advice of the week is to learn from our first data warehouse efforts and do two things:

• Think single point of storage and pointers, not redundant.
  There will be a natural impulse to store copies of images in more than one place, for the same reasons that we stored data in multiple places. Try to design to avoid this. If a check item or a document must be accessed and used by multiple employees/departments/systems, store it once and point those systems to it. This can be complicated when some of the sources are outside the bank, as in the case of images, and there will need to be cooperation and some industry standards set. A simple example of this is Viewpointe, which doesn’t send an image when an item is being settled between two of its users. It sends the information and a pointer record saying where the image is if you want to look at it. As an industry, we need to be able to do the same thing if multiple vendors are involved.
• Design for customer use.
  Normally any Gonzo writer who says something as obvious as “we have to be customer-centric” would be sentenced to attend, as a groupie, all of Cher’s farewell concerts for a year. However, this is one time where it may really matter. My partner Steve Williams offered the idea, in last week’s tome, that banks may become an image storage service for customers in the long term as the try to retain loyalty. A capital idea. So, as you design how all these imaged records get accessed, let’s include the thought that the system could also contain images we scanned and store for customers. Then ask this: could a customer use this tool to look up checks, documents, and other stored records without help? This should be your design standard. Believe me, if you can design a tool that is easy for customers, the employees will be happy to use it, too.

An explosion of images will hit us in the next two to five years. Let’s don’t think about how to store and access them after it happens. It’s time to start thinking “horizontally” about imaging systems.
–tr