Teller Capture- Myths and Realities: Part III

Teller Deposit Automation (TDA) is where retail banking meets payment processing. The imperatives that drive these worlds are profoundly different. The previous installments dealt with some of the business case aspects of TDA. This post touches on systems integration and related business implications.

Retail banking and payment processing- shotgun wedding, a bridge too far? Let us see.

A common solution, seen mostly in the credit union world, is a check capture system interfaced with a receipt printer. That’s right, I did say “capture” not “deposit automation”, because that is exactly what this approach offers. Check images are captured after the teller has processed and posted the deposit. The benefits of keystroke reduction, and automated proofing and balancing at entry are absent. The approach adds the capture of check images on top of the original teller workflow- whatever that happens to be. Many solution providers offer this option, because of the challenges- both technical and political- associated with integrating deposit automation modules with teller platforms. So, if you opt for this solution, be aware that it is limited to image capture for archival and does not bring workflow efficiencies to the table.

Integrating deposit automation with teller platforms sparked a battle royale in the early days of Check 21. Providers of teller platforms saw anything that has to do with teller operations as their turf, while check imaging solution vendors viewed payment processing as their unique expertise. Often, this was reflected into political tension between the retail banking and payment operations groups within financial institutions. Some of the business case arguments I shared in the previous posts had their genesis in this departmental face-off.

There are two general alternatives for integration between teller platforms and deposit automation systems. An early approach, that is still in use widely, is a “toggle hand-off” between the teller host and the deposit automation system. When the teller is ready to accept deposits, she clicks on a button that brings up the deposit automation screens. All operations thereafter are conducted within the deposit automation system. After the deposit is proofed and balanced, the teller clicks another button that yields control back to the teller platform. As you can imagine, this sparked a firestorm of turf battles, as nothing seems to elicit emotion more than the ownership of the user interface.

An alternative, partly spurred by the politics, is the “headless API”. This approach leaves the user interface firmly in the hands of the teller system, while the heavy lifting of payment processing is performed, “behind the scenes”, by the deposit automation system. As teller platform providers have come up to speed on the nuances of check deposit processing, this alternative has gained more traction.

Both approaches work well, and are transparent to the depositing customer. There are marginal benefits in teller training with the headless approach. Once trained, however, I have not seen a marked difference in teller efficiency between the alternatives. It comes down to your institution’s operational philosophy. That said, my take is that the owner of the dominant platform will eventually control the interface. For example, I believe mobile banking applications will eventually subsume separate mobile remote deposit solutions…but more on that another day.

An important trend in the TDA world is the acquisition of check imaging companies or talent by teller and core system providers. Witness the Fidelity- Metavante (AFS, Bankware), Profit Stars- Alogent, Fiserv- Checkfree (Carreker) acquisitions to name a few. ARGO Data that dominates the very large bank teller space, has preferred to hire talent over buying a check imaging company. The upshot is that deposit automation is fast becoming a module that is already integrated with the teller platform. Nevertheless, there are independents who offer to integrate deposit automation with your teller system of choice, in lieu of the bundled alternative.

There are a few issues to be considered when looking at bundled versus separately integrated options. If you are considering a separately integrated deposit automation module, look carefully at the application programming interface (API) between the TDA system and the teller platform. Whose API is it- the TDA provider or the teller vendor? How well defined, and how flexible is the API? What is the strategy for version control as each system proceeds on its release schedule? In many cases, the interface is built without the overt cooperation of the teller vendor (only natural as they would prefer to sell you their bundled version). In these situations, there is often proprietary “glueware” that sits between TDA and the teller system. Who owns the glueware? What is the strategy to ensure that this essential piece keeps pace with the evolution of the two systems it is sandwiched by?

If you are considering bundled alternatives, ask the same questions as above. In many companies, divisions do not cooperate with each other as well as one might think, and sometimes behave like separate companies. Thus, “bundled” may not be as tightly integrated as one might think. There is also the issue of sort patterns to consider. In large institutions, the sort patterns that govern the business rules of deposit processing can be complex. These are traditionally owned and maintained by the operations departments, and are resident on centralized check clearing platforms. Now, the TDA paradigm requires that these sort patterns be applied at the point of entry- the teller. In other words, the TDA system needs to have access to, and be capable of administering complex sort patterns in real time, at the teller station. Does the bundled TDA system have the capability to administer complex sort patterns? If the provider of the back end check clearing system is different, what is the strategy for accessing and maintaining the patterns within the TDA system?

The early days of deposit automation saw different systems for TDA and back counter deposit automation. The back counter of the branch was used for bulk deposits and typically drove bulky scanners of higher speeds. TDA and back counter systems were not integrated, and lived in silo’d worlds. Today’s small footprint scanners are capable of variable speed including high speed capture. Thus, the rationale for separate TDA and back counter systems no longer exists. The need is for a deposit automation system that can be configured for teller or back counter operation. In other words, what is needed is a comprehensive Branch Deposit Automation (BDA) system that can be configured to work at the teller station or the back counter of the branch. Why deal with silos if you don’t have to?

As you can imagine, a blog post only touches the tip of the iceberg. There are many more nuances that need to be considered. Nevertheless, I trust these points help frame the decision process. In my next post, I’ll summarize the posts with a check list that might be of help.