Teller Image Capture- Myths and Realities: Part II
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?
Written by Vijay Balakrishnan, President of StratEX LLC. Mr. Balakrishnan will be presenting on an Orbograph webcast covering the past, present and future of image capture technologies on May 9th at 2pm ET.
To register, click: http://www2.orbograph.com/l/16322/2013-04-26/5g12t.