Through Thick and Thin- Branch and Teller Deposit Automation Redux?

Just when you thought branch and teller deposit automation was done and dusted, a new interesting development is slowly making waves. Early forms of both types of deposit automation were thick client applications that resided on PCs at the branch. In previous posts, I have touched upon the headed and headless versions of teller deposit automation. And there the technology sat until merchant capture hit the scene (I say capture deliberately, because that is what most of them were- remote capture with the rest of the work-flow centralized upstream).

The question was asked, "If a merchant can capture and send relatively large deposits using thin client technology, why can't the same thing be done from the branch?" Why not, indeed? The thin client approach minimizes the challenge associated with initially deploying and updating applications deployed across a branch network. Do it once centrally, and the entire network is current.

Not so fast, say some. What about the network latency in performing the entire capture-correct-balance continuum using thin clients? Will that not slow things down, and affect branch efficiency? After all, a merchant does not have to worry about people waiting in queue to make the next deposit. What if connectivity goes down? What are the offline recovery alternatives? How do deal with exceptions- missing checks and data?

While the battle is being fought, here are some perspectives on the issue. I think the cases for automating deposits at the teller and branch back counter will are driven by different imperatives. As discussed in previous posts, teller deposit automation (TDA) is increasingly getting bundled with teller systems. Teller systems are headed in a thin client direction. Therefore, I think it will be difficult for thick client TDA systems to survive when the mother ship is headed elsewhere. Deposits made at teller stations typically small, and it is likely that network latency will not significantly affect queue length at the teller. This, of course, makes sense for brand new teller deployments. Keep in mind, nevertheless, that there are many thick client teller desktops out there that can be retrofitted with traditional thick client TDA.

The branch back counter is a different kettle of fish. As observed previously, the landscape ranges from very large institutions that capture at the branch and perform data perfection and balancing centrally, to smaller banks and credit unions that perform the entire work-flow at the branch level. The deposits dealt with at the branch back counter tend to be larger, and therein lie the seeds of an interesting trade-off. If the paradigm is to only capture at the branch, and defer correction and balancing to centralized operations, a thin client front end for capture may make sense. If, on the other hand, the entire process of item correction, amount entry and balancing is to be done at the branch level, network latency and offline recovery considerations may be an issue in a thin client environment. We may perhaps see a hybrid work-flow evolve, a la merchant capture, where items are captured using thin clients, transactions nominally balanced against a control total from a teller tape, and sent to central operations for downstream operations. Yes, this will add work at the branch, but it may reduce workload centrally- particularly in smaller institutions that do not have complex balancing rules.

Interesting how technologies considered ready for benign neglect have a habit of asserting themselves when you least expect it. Thoughts?