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.

Tricks with Clicks and Bricks

Akin to the many-headed Hydra of yore, banks present many faces to consumers and businesses. There are branches, call centers, mail centers, ATMs, online banking sites, remote deposit options, mobile applications, and others that are perhaps being crafted by the merchants of finesse in our institutions.

The quest for a cohesive multi-channel strategy has been an odyssey almost as long as Homer's celebrated voyage. Yet, one hopes that, unlike Odysseus, we don't end up alone, washed up on a beach in Ithaca! A lot has been written on the barriers to the holy grail- old systems, failed CRM initiatives, inadequate employee training, missing incentives, ad nauseam. I wonder, though, whether the fundamental issue is a tussle between two important strategic imperatives.

In their excellent, but slightly dated book, The Discipline of Market Leaders, Tracy and Wiersma define value as the intersection of three imperatives:

Operational Excellence, Customer Intimacy and Product Leadership. There are few organizations (perhaps none) that are excellent in all three dimensions. They generally tilt in one dominant direction, with the others playing supporting roles.

In retail banking, Operational Excellence and Customer Intimacy pull in opposite directions. Many institutions built branches to be points of high-touch service, driven by a Customer Intimacy paradigm. But branches are expensive to build and maintain. When viewed through an Operational Excellence lens, the fully loaded cost per branch transaction is significantly higher than ATM, online, and remote deposit transactions. Thus, the soft benefits of personalized service (assuming that it exists in branches in the first place) are unlikely to win spreadsheet wars in institutions driven by an Operational Excellence mindset. It is not clear whether institutions really want customers to visit branches, or whether they would be happy if all interaction moved magically from bricks to clicks.

The challenge is not unlike that faced by retailers that also have an online presence. Yet, many of them seem to maintain the balance between driving foot traffic to their stores and maintaining an online presence. To realize how effective cross selling can be, think of the last time you walked into a store to buy shoes and came out with that tie you really did not need. However, we struggle with cross selling in banking. Is it because these retailers are clear in their driving imperative, while financial institutions are torn between efficiency and service?

Odysseus filled his crew's ears with beeswax so that they would not be lured by the sirens' songs to certain death. We do not have the luxury of simple avenues to clarity. How do you think retail bankers should reconcile the tension between Operational Efficiency and Customer Intimacy? Let me know what you think.

(Fr)agile Software Development

Much of our world is made possible by software. There are myriad software systems that manage and move our money, keep track of our health histories, light our homes and offices, and indeed even enable you to read this post. While the sheer scale of accomplishment from zeros and ones flitting about at the speed of light is astounding, the manner in which some of these systems are developed, tested, and delivered raises a few questions.

Over the falls in a barrel. The early years of evolution in software development owed much to needs of the defense and aerospace industries. These were highly mission-critical systems that had to work correctly almost ten times out of ten. A linear process that involved detailed specifications, technical designs, strict coding discipline, reviews, and rigorous testing ensured the delivery of many high performance systems.

A version of this made its way into the commercial marketplace under the broad "waterfall process" moniker. The series of hand-offs, from product management, to architecture, design, development and testing, with intermediate review cycles, hearkened a series of waterfalls as in a cataract. While the process worked well for the most part, it lacked speed. The many steps limited organizations to one or two releases to the marketplace a year. It was difficult to nimbly respond to competitive and regulatory changes. If changes were not included early enough in the cycle, it was tantamount to missing an exit on a tollway, and waiting for the next one.

Sprints around the racetrack. In the 1970's, the automotive industry introduced the concept of "simultaneous engineering", where design engineers, manufacturing engineers, and quality control worked together in teams. As opposed to the linear, "throw it over the transom" model, this engendered both speed and sharing of ideas. That germ of an idea made its way into software as Agile Development. While there are many agile methodologies, the general concept is that specifiers, programmers, and testers work together in short, iterative, "sprints" to produce executable software. Over multiple sprints, complete, ready-to-release applications can be built.

Lost in translation. While agile development has made it possible to release software more frequently, a few challenges have appeared on the way to nirvana. To the agile purists, I will grant that many of these have to do with incorrect interpretation and implementation, and perhaps not because of fundamental drawbacks in the methodologies. The challenges are amplified when you add offshore development where the advantage of co-located teams disappears. They are also most acute when software is developed for General Availability to a large and varied customer base, as opposed to internal use within an enterprise. Here are some of the pitfalls I have observed over the years:

What we have here is a failure to communicate. With apologies to "Cool Hand Luke", one of the main complaints I have seen is, "We don't know what is coming, and when!" We have moved from exhaustive, written requirements to writing nothing down. The refrain is that the sprint teams communicate with each other, and are on top of release content. Some will add that everything can be discerned from documentation within the code. The problem is that there are many stakeholders outside the sprint team, such as sales, marketing, professional services, and support. These people are not adept at reading code, and think in terms of functions and applications, as opposed to individual features. The result often is that market facing groups either oversell or undersell the product (more often the former!).

Who's on first? While sprint teams are cohesive and democratic, the flip side is that it can result in no one at the helm. While the methodologies call for a "function customer" who signs off on software content and quality, this role is often missing in action. Either the role is completely absent, or it is relegated to a Product Manager who is more of a Product Marketer than someone who can go head-to-head with a technician. In the absence of this key role, many cooks jump in to influence the software broth in one direction or the other, resulting in content churn. The process is agile yes, but highly unstable.

Tried and tested. Agile methodologies like test driven development put testing and quality at the center of the process. In practice, however, quality often ends up getting the short end of the stick. The very expectation of agility can compress timelines due to unrealistic promises made to customers. In the rush to "get it out of the door", thorough testing is skipped, and some vendors essentially do their quality assurance on the customer's dime, by continuously band-aiding software at the customer site until it works. In extreme cases, this becomes a license to hack with little regard to version control, belying the very concept of "General Availability". While poor quality is not limited to agile methods, the less rigid process restrictions can exacerbate the tendency in organizations that already have a culture of treating quality lightly.

Customs and traditions. In organizations that cater to customers of varied sizes, the concept of General Availability can be turned on its head. There is often the case of a large customer that wants software customized to meet a unique need. There are very few vendors that have the discipline to examine whether that particular capability warrants inclusion in the software delivered to the general marketplace. The path of least resistance is to include it as a base capability that is "configurable". Over time, the preponderance of configurable customizations makes the software incredibly difficult to implement and support. Again, the lack of a process to adjudicate the "base versus custom" question can result in a multi-headed Hydra, with hidden heads that can appear to bite you when you least expect it.

Distant shores. Every one of the problems discussed explode in complexity when offshore development is involved. The communication challenge now includes time zones, national cultures, and language. The concept of sprint teams working in iterations is predicated on the concept of co-located personnel who can discuss, white-board, and resolve questions face-to-face. Getting this done with people somewhere else on the planet is very difficult, and contributes to hidden costs in offshore development that can obliterate the wage differential in the early stages of the offshore journey. The challenge can be overcome, but it takes special focus and attention to drive out the inefficiencies.

Brave new world. The benefits of agile development have ensured that it is here to stay in most environments. The word to the wise is that getting it to work right involves recognizing the pitfalls, and addressing them involving the right stakeholders. I would not be surprised if many of you recognized your organizations in some of the challenges I have outlined. It is important to recognize that getting software development to work is not just the purview of the programmers alone. Someone said, "War is too important to be left to the generals". If you'll allow the stretch, let me end by saying, "Software is too important to be left to programmers, and methodologies".

Why can't Tellers be Sellers?

Stepping into a debate that is as old as retail banking is perhaps unwise. There are passionate adherents ranged on both sides of the question. To some, the issue is not whether, but should tellers be sellers?

The question brings the raison d'etre of the retail branch network into sharp relief. Are branches retail storefronts with the primary mission to enhance customer relationships, or are they collection points for myriad transactions processed by centralized back office operations centers? Is the driving imperative one of customer intimacy, or does operational efficiency rule the roost?
A tilt towards operational efficiency has traditionally driven retail banking, with occasional overtures to the selling side of the equation. These overtures, however, tend to be fleeting, and with few exceptions, have not survived beyond some concerted marketing and employee incentive programs.

To understand why the push towards serving and selling the customer has not been sustainable, consider a few points. Making check deposits is by far the main reason customers visit a branch. When they do visit, the teller is the person they most often interact with. Regardless of all the training and incentives that may have been put in place, consider what tellers actually do. They are heads down punching numbers into keyboards (try counting the number of teller keystrokes the next time you're in a branch). They have barely enough time to complete the data entry and squeeze out a quick thank you before the next customer is at their window. Imagine a Neimann Marcus salesperson wordlessly packing what you've picked out and intently ensuring that the bow on the package is just right! Yes, the analogy is not quite right- but you get the picture.
So despite many a marketing push, it is the fundamental transaction tether that yanks the teller back into the role of a frontline operations clerk- the first cog in the vast infrastructure that we put in place to process paper checks, featuring planes, trains, automobiles and giant "paper factories".

There is an alternative, courtesy the legislative cover of Check 21 and advances in imaging and recognition technology. Teller Capture allows the teller to drop the entire deposit into a small foot print scanner and interact heads up with the customer, while an imaging application reads all the necessary information, ensures the transaction is balanced, and prints out a receipt when done. Teller Capture eliminates teller induced data entry errors, and also catches math errors up front. This "ready-to-post" transaction at the very beginning of the deposit stream results in major efficiency savings further down the value chain. It is as close to straight-through-processing as one can get in the check world.

"Not so fast," say some. "You want to make my tellers into check operators?" The reality is that the opposite is true. There is now evidence of major savings in teller time per deposit, including data from a Top 5 U.S. bank of having reduced keystrokes from 75 to 5!

"What about the cost of a scanner and software at every station?" challenge others. "It is really difficult to integrate these capture applications with teller systems." The cost per node for both hardware and software is steadily declining, making it well worth the while to examine the return on investment. The hard numbers on transportation savings, back office labor elimination, and funds availability make it interesting- leave alone the soft benefits in customer service and added sales. Capture systems are also increasingly being integrated into teller systems, both by teller vendors that have acquired check-capture technology, and pure play check imaging vendors that have certified their applications with leading teller vendors.

Coming back to the tellers-to-sellers paradigm, what do you do with the saved time? Do you use it to push even more transactions through? Do you have tellers refer customers to other branch personnel based on prompts from an integrated CRM system? Or do you have tellers take on more of a sales and service role themselves? Those are decisions that will be driven by your overarching strategic intent. Do you want tellers to be sellers in the first place? As you ponder that question, you may want to look at teller capture as an opportunity to cut the transaction tether that keeps pulling you back, yo-yo-like, to the paper factory of another era.