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?

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.

Teller Capture Myths and Realities- Part II

The business case for Teller Deposit Automation (TDA) rests on the hard benefits of central proof elimination, reduced transportation and float, and the softer advantages of improved customer service, error elimination and early risk detection. Let’s take a closer look.

If you have a ready-to-post transaction at the teller station, clearly there is no need for any further proofing and balancing. This was a no-brainer benefit in the early days of Check 21 when branch alternatives were compared to centralized processing centers. The headcount reduction in central proofing alone could underwrite the business case for either teller or back counter deposit automation (BDA). In a strange way, the case is more complex now because trade-offs are made, not against central processing, but between TDA and BDA. An added twist in the tale is the financial institution’s workflow preference. The US is made up of institutions that prefer to proof and balance at the branch, and those that like to proof at the branch, but balance centrally. Not surprisingly, most small institutions exhibit a branch balancing preference, while larger ones opt for centralized balancing.

The actual business case analysis involves running scenarios that are unique to the institution. Nevertheless, it is relevant to make a few broad observations. Those that object to TDA actually increasing teller workload and queue length have a point when it comes to large commercial deposits. Thus TDA is not right for all deposits. Many institutions limit TDA to deposits containing, say, ten items. The rest are either dealt with through a separate BDA system, or set aside for tellers to process during slow periods.

Does TDA reduce keystrokes, or does it actually imply more work for the teller? I am one of those strange people that actually counts keystrokes whenever I go to make a deposit at a branch (yes, I still visit branches). I have accounts at institutions that use TDA, and those that do not. My experience is that TDA drastically cuts down keystrokes. Contrary to the claim that TDA makes tellers into proof operators, I find similar deposits taking about half the time in TDA institutions. I have deliberately made deposits with addition errors on the deposit slip, and I find that TDA institutions catch them faster. The key is that with improved recognition software, and vastly better MICR readers, technology is doing the heavy lifting, leaving little as a teller burden. The keystroke reduction is borne out by statistics including one from a large institution that observed a reduction from 75 to 5 keystrokes (what were they doing previously with 75 strokes??). Now, the theory is that reduced keystrokes allow more teller “face time”, to allow cross selling. Not once in my informal mystery shopping did I experience the “selling teller”. The institutions I visited seem to use the reduction in keystrokes to drive efficiency over cross-selling.

While the back counter versus teller trade-off requires more space than a blog post, there are key (no pun) considerations for BDA in larger institutions. Typically, these are environments where items are scanned at the branch but corrected and balanced at the center. If an item needs to be rescanned, or an operator needs access to the original paper, the fact that the check item is at a branch many miles away presents challenges. There are systems with instant messaging capability back to the branch, butthe DRIFT principle (DO IT Right the First Time) that TDA offers is compelling.

Transportation savings are trickier. While check truncation does eliminate the need to move paper, there is still a lot more paper that needs to be moved daily from the branch- not the least of which is cash, the only paper that cannot be truncated. There is an emerging move towards “the paperless branch”- an interesting convergence between check truncation and document management. It will be interesting to watch how this scenario pans out in the absence of a legislative catalyst like Check 21. Nevertheless, with careful analysis it is possible to quantify transportation savings due to TDA.

An aspect that is often overlooked is the potential to identify risky deposits at the very outset through TDA. We have accelerated the movement of money to the speed of light. Both inadvertent errors and outright fraud have kept pace. Yet, our industry still chooses to address risk on a batch basis on “Day Two”- a hold over to the old centralized mechanical capture days. It is my take that TDA and Day Zero Risk Management make perfect bedfellows. More on this in another post.

I know no one looks at float anymore because we are about as close to “free money” as one can get. While I don’t have a crystal ball, it doesn’t take rocket science to know that the sizeable national debt will push inflation and drive rates northwards in the not too distant future.

Lastly, the single biggest barrier to TDA is the difficulty in integrating deposit automation with teller platforms. With many core vendors having acquired check imaging companies, this should become easier. This, however, is not as straightforward as it might appear. Not all integrations are equal and, like everything else, there are trade-offs here as well. More on that in Part III.

Teller Capture- Myths and Realities- Part I

While the U.S. check payments industry has seen a dramatic transformation from being awash in oceans of paper, to an almost all-image environment in less than a decade, there is debate about where images are best captured. The alternatives are many- teller stations, branch back offices, ATMs, central processing centers, offices, stores, homes and mobile phones, to name a few.

Capture points of entry can be broadly divided into two categories:

1. Interior points, within a bank’s infrastructure like tellers, branches and ATMs, where the driving imperative is one of cost reduction and efficiency.

2. Exterior points, like offices, stores, homes and mobile phones, where the drivers are combinations of revenue uplift, customer convenience and efficiency.

This is the first of a series of posts on the pluses and minuses of various capture strategies. We begin with Teller Capture.

Let me begin by saying that I have never liked the term “Capture”. It is a holdover from the times when MICR (and later image) data were read and “captured” on electro-mechanical reader/ sorters. While sorters have been relegated to museums and the odd eBay page, the term lingers. I find the term limiting because it tries to describe a workflow which is far more comprehensive than the mere capture of information. I submit that the capture-correct-balance continuum that is typical of the many “capture” processes in use today is better referred to as Deposit Automation.

Now that I have my pet peeve out of the way, let us look at Teller Deposit Automation (TDA). The quick take on TDA is to have a proofed, balanced, and ready-to-post deposit, before the customer making the deposit has left the teller station.

That last statement sometimes lets loose a flurry of concerns:

• I don’t want to make sorter operators out of my tellers
• Error rates will go up because tellers aren’t trained to be proof and balancing operators
• Queue length will go through the roof because each deposit is going to take much longer
• Tellers (and perhaps customers) will not accept this new and different process
• A scanner, computer and software at each station will be tough to justify
  
  

To be honest, there are also issues of a political nature that can rise to the top. TDA lies in that No-Man’s-Land between Retail Banking and Operations. In some institutions, particularly larger ones, TDA can be a lightning rod for turf battles. Nevertheless, let us look at the other end of the telescope and examine the benefits touted by proponents of TDA.

The hard benefits that drive the business case are:

• Truncation and reduction of transportation
• Central proofing and balancing elimination
• Float gains through early capture (yes, I know…but interest rates will not always remain subterranean)

The soft benefits that supplement and sometimes drive the decision (depending on the institution’s strategic priorities) are:

• Keystroke reduction freeing up more teller time for customer service
• Error reduction through lower keyboard data entry
• Potential risk reduction through integration of TDA with risk management systems
• Potential for enhanced service through integration of TDA with Customer Relationship Management (CRM) systems

The business case battles are fought on multiple fronts with hard and soft benefits challenged, defended and examined from many angles. My next post will take you through some of the battlefields (I’ll admit I have a few scars from these skirmishes).

Payment Hub Realities

At BAI's Payments Connect conference in Phoenix last week, I moderated a panel discussion on "Getting the Technology War Elephant to Dance". One of the avenues explored was to "extend" the reach of legacy systems through Payment Hubs.

The panelists were Taylor Vaughan, Director Treasury Services at First Tennessee Bank, Dave Shipka, Senior Vice President Enterprise Payments at Comerica Bank, and Elizabeth Cronenweth, Product Line Manager at Sterling Commerce (now a part of IBM). There were interesting perspectives from two bankers who were in the midst of implementing hubs, and a technology solution provider with a handle on industry trends. Here are some take aways:

• Financial institutions are being buffeted by strong headwinds in the form of potential lost revenue (aka the Durbinator), heightened compliance regimes (one bank- not represented on the panel- stated at the conference that they project 30% of their IT budget to be spent on compliance), polarized demographics with Boomers and technology savvy Gen Nexters demanding very different services, explosions in channels and payment alternatives, increasing non-bank competition and globalization.
• Some of the imperatives driving technology infrastructure planning are:
  
  1. Comprehensive customer view across all relationships. Most systems in place are transaction centric and don't offer a customer view- let alone a 360 degree view across relationships.
  2. Multi-channel and multi-payment capability as opposed to the silo'd legacy environment.
  3. Real-time operations to enhance customer service and reduce risk.
  4. High up-time availability and ubiquity- anytime, anywhere.
  5. Nimble operating environment lending itself to agile change management.
• Existing infrastructures present barriers to the imperatives through silo'd architectures and organizations, batch operating environments, old and poorly documented code, hard coded interfaces and long lead-times for change management.
• There are two broad approaches to deal with the challenge- "extend" the reach of legacy systems, or replace them altogether.
• It is very early in the evolution of Payment Hubs and there is considerable debate as to what it is, and is not.
• A vision of a Payment Hub- a single platform that operates across all customer relationships, channels of interaction and payment alternatives.
• Payment Hubs can be data centric where data and business rules reside at the hub, or message centric where the hub is a traffic cop. The reality is that evolving hubs include combinations of both approaches.
• The main driver for hubs is the "spaghetti" environment in most institutions, with one-to-one paths from every channel to multiple legacy systems.
• A challenge that should not be overlooked is political pushbacks from the owners of various legacy turfdoms. Some see the implementation of a hub as a direct threat to their jobs.
• It is absolutely essential to have an executive sponsor who will stay the course, as the hub can and will touch many parts of an institution.
• Both revenue and cost perspectives should be carefully looked at. Clearly, the cost of an increasingly expensive and unwieldy status quo needs to be compared with the expense of implementing hubs. Often, the cost of the status quo can be untenable. What is needed then, is the will to take on the risk of transformation through enabling technologies like hubs.
• Another perspective is to "sell" the hub on the back of one or two revenue opportunities. This view suggests that it is difficult to get consensus on implementing a hub on a cost reduction play alone. Integrated Payables can be one such revenue opportunity. Eliminating silo'd payables and multiple files not only enhances customer service, but presents an opportunity for value-added pricing. A follow on can be the other side of the mirror- Integrated Receivables. This view recommends building the case based on the revenue opportunity, and having the transformational foundation for the enterprise pulled along by a growing topline.
• The option to replace legacy systems as opposed to the "extend" paradigm was examined, but discarded due to the complexity of "legacy spaghetti". An interesting observation shared was that if much of the intelligence ended up in the hub, there was no need for a legacy system, except for settlement. Can a hub be a Trojan Horse that eventually eliminates legacy infrastructure? Intriguing concept indeed!
  
• A perspective on batch versus real-time was that both capabilities were needed in the hub as the batch based legacy systems were not going away overnight. This implies a careful definition of the Target Operating Model and a well defined Change Management Program to get there.
• Lastly, a challenging note to the hub concept was raised, in that an attempt to over-centralize can end up in a potential single point of failure. Clearly, thought needs to be given at the design and architecture stage to safeguard against the hub bringing down the whole ship.
• It was a fascinating dialog, and one that I enjoyed moderating. My take is that we will see more hub implementations in larger institutions in the U.S. and other older economies that do not have the benefit of leap-frogging from manual or poorly automated environments to the latest and greatest.

Watch this space as we evolve into a post Great Recession society!

StratEx at BAI Payments Connect

In the post Dodd-Frank-Durbin world, the mantra chanted by many is that banks have to be more innovative and nimble. They have to provide differentiated value in the face of fierce competition from non-banks. Customers want to interact 24/7, through multiple channels, and using varied payment methods. The holy grail is a real-time, 360 degree view of the customer that includes all relationship types (deposit, loan, investment etc. etc.), channels of interaction (online and brick and mortar) , and all payment vehicles from check to card to wire.

Easy, right? Wrong!

Most financial institutions are saddled with systems that are decades old, and impossibly silo'd. The choices in front of financial institutions are to:

(a) Extend the reach of legacy systems through systems like payment hubs, or
(b) Rip out old technology completely and replace them with new systems.

The Bank Administration Institute (BAI) will address this choice between the devil and the deep blue sea, among many other interesting topics, at Payments Connect in Phoenix, March 7 through 9.

I will be providing an overview of the topic and moderating discussion on the topic at a session, aptly entitled, "Technology and Process En Route to Payments Profitability: Getting the War Elephant to Dance."

If you're planning to be at the conference, you may want to put this session on your agenda. It should be informative and interesting. If you don't plan to be in Phoenix, watch this space, I'll post a summary in the near future.

The Branch is Dead, Long Live the Branch

That we live in a wired (or perhaps more appropriately, a wireless) world is an oft repeated truism. As I work on this post, I am using the Internet. My mobile phone just beeped with a text message. An intrepid bunch of schoolmates are using Facebook to organize a high school reunion half a planet away. Reunion after how many years, you say? Well, let's just say it is enough for many grey hairs.

If the drumbeat of news is to be believed, consumers are leaping en masse to interacting with their financial institutions through mobile phones and other remote channels. You can now snap a picture of a check with your phone and deposit it in your bank from anywhere in the world. Remote Deposit Capture (RDC) allows businesses and consumers to scan checks from the comfort of their offices or family rooms, and zap across images for deposit. The perfect storm of convenience and technology should mean that very few people visit their neighborhood branch anymore, right? Wrong!

An item (no pun, honest!) in The 2010 Federal Reserve Payments Study caught my eye. Yes, the number of checks written has declined from about 30 billion to 24.4 billion. However, only 13% of checks deposited were received by financial institutions as images. That means a respectable 87% of checks were deposited physically. So, despite all the noise about check deposits getting virtualized, there still is a healthy number of people walking into branches to make deposits.

Now, your take on the physical branch versus self-service debate will dictate whether you see this glass half full or half empty of your beverage of choice. Proponents of RDC will point to the enormous growth potential in the remaining 87%. The same percentage will be looked at by some retail bankers as rationale to invest in branches.

At the risk of being a fence sitter (come to think of it, sitting on an actual fence can be acutely uncomfortable), let me say that both views are correct. RDC will continue its growth, albeit at its present course and speed- I don't see a "big bang" transformation in that direction. I do, however, see an opportunity for investment in technologies like teller capture and enhanced training for tellers to go beyond their current role as deposit takers. Teller capture uses technology to capture images, proof, and balance deposits at the teller station. It reduces keystrokes and data entry errors. It also provides more "heads up" time for tellers to interact with customers, where additional training can enhance the customer experience.

Transformation is a funny thing. Just when you think the new and different will swamp the world, something from the hoary past reaches out to remind us of its existence. Success will go to those who craft strategies to leverage both.