Sweat the big stuff

Consider the following anecdote, and if you have never encountered something like this in your banking career, consider yourself fortunate. Then ask if the credit goes to sound preparation, or just plain good fortune.

A wire transfer form was completed with every numeral correct—but with no decimal point in front of the cents portion.

The result was an instruction to issue payment that was 100 times larger than it should have been.

As this was a transfer initiated by the bank, the offset of which was a general ledger account, there was no issue of insufficient funds. The fast, accurate personnel in the wire transfer unit, with some diligent work-arounds, completed the transaction as it appeared. No questions were asked.

It was a gigantic sum. Fortunately the transfer was bound for the bank’s own account at another financial institution. No loss was incurred.

But what would have happened if that payment was bound for somewhere else?

Size makes a difference in every part of banking

Many banks suffer from an odd sort of blind spot. Banks generally have a deep and broad set of policies and procedures regarding large loans and large investment positions.

But how confident are you that your systems are equally robust when it comes to transaction processing?  Especially in the early stages of building an operational risk platform, it’s been my experience that the chief risk officer or the operational risk manager has a challenge to confront here.

The challenge is primarily one of intra-bank culture, and it is quite understandable.

Making large loans is a deliberative process. Banks deploy analysts, managers, senior management, and even board members to help achieve quality decisions. Policies and procedures are scaled based on size, individual decision making is limited, and discussion and sharing of points of view is encouraged. For investments, there is a whole process typically built around the asset-liability management committee, and other controls.

This is not the case for large transactions—and for good reason.

Transaction processing is an intra-day affair. Thus banks’ systems aim for efficiency and accuracy, and there is typically little time for contemplation.

As a result, we staff our operational areas with employees whose skills coincide with fast and accurate outcomes. Indeed, we reward employees for delivering against those standards. We accept that certain losses will occur as a cost of doing business.

That approach works well for the overwhelming majority of transactions by number and even by aggregate dollar value. But certain transactions are worthy of inquiry before completion, and we need a way to identify and escalate them. My opening anecdote is but one example.

Software can be a great help in our effort. We use it to identify potential fraud issues and for AML compliance.

One key input into these systems is whether the transaction is unusual for the customer. While large size contributes to the likelihood of it being identified as unusual, that is not necessarily the case. In addition, once identified as unusual, the attention paid in the review and authorization process may not be segmented by size.

How major glitches arise

There are many other examples, and you may in fact have your own horror stories. So, what is the root cause? 

I view the answer as having two elements:

First, as mentioned, we value speed and accuracy in transaction processing.

Many of our operations employees understand their own tasks well. However, often they do not understand the context in which transactions occur; how the tasks link to each other in the transaction processing systems; and what purposes are being served.

In short, many do not know why they do what they do, and thinking may be confined to individual silos.

Second, bank risk managers may not have built clear escalation guidelines in all our operations areas.

These guidelines are critical in bringing to the attention of the proper people the larger, riskier transactions that need inquiry and deliberation prior to completion.

The reality of running a transaction processing unit is that we need people who work accurately and quickly. It is incumbent upon Risk Management, then, to build clear, realistic guidelines to escalate transactions to the people who will review them in context and with knowledge of the entire system.

We cannot expect to staff our units with people who have all of the above attributes, after all. The answer lies in appropriate processes.

Building escalation guidelines begins with data gathering. For each major type of transaction processing, gather the number of transactions and sort by logical dollar-size segments. Compare those segments to the tolerance levels you have regarding operational losses. This will vary bank by bank, but relates to size, capital, earnings, and overall management attitude.

Next, identify the right decision makers for each area. Grant approval authority to the appropriate people based on dollar size. But also include notice at least one level up.

So, if a vice-president in check clearing can approve up to a certain amount, there should be a contemporaneous notice to what might be a senior vice-president in charge of operations. Similarly, if the size of the transaction requires SVP approval, the Chief Operating Officer should receive notification.

In addition, I recommend that any time approval is escalated to a person above the VP level, the central risk management function should be notified. This can be to the Operational Risk Officer in the first instance and at designated levels to the CRO as well.

Timeliness of this process is critical. The reason people are notified is that we want them to have the capacity to influence the decision. To aid in timeliness, there should be back-up staff members designated and copied on the notices in the event the primary people are not available.

In addition, escalation guidelines should be simple. Stick to one or two variables at most. This has the downside of being overly inclusive, but the cost should not be great compared to the potential to avert great harm.

Balance people and processes

Risk managers should recognize the talents we seek in our employees to fulfill the business objectives we have. We should then build systems and controls that identify transactions that require a different set of talents, and get those transactions in front of the people with the requisite skills.

I ask that readers contribute an anecdote, and describe whether the event resulted in a loss or was a “near miss.” Use the comment section below.