I read this story about Citibank's mistaken transfer—which cost it about half a billion dollars—a while back, and the sheer improbability of the mistake struck me. How could a banking giant make a blunder of such staggering magnitude despite multiple checks and balances? So what exactly went wrong here?

I recently circled back to that story and realized that it was, unsurprisingly, more complicated than it had sounded at first blush. Nevertheless, as software developers and software users, I suspected we could learn quite a bit from this expensive mistake along with our customers. 

I want to unpack a few of those lessons—but first, let's review what happened. 

ICYMI: What Happened in the Citibank Wire Transfer Case

The bare-bones version of the story goes like this: Citibank, acting as the administrative agent for Revlon's loan, meant to process $7.8 million in interest payments to Revlon's lenders. However, Citibank's software system required that it set up and execute what was, in effect, a "dummy" transaction to process the interest payment. Citibank would create a transfer of the entire outstanding balance, including both principal and interest, into an internally held "wash account." Citibank's staff had to check not just one clearly labeled box but also two other boxes with cryptic and confusing labels to direct the funds to the internal account. Because they only checked the one box, the money, totaling about $900 billion, didn't go to the wash account—it was wired straight to the creditors. (A rather large oops!)

Citibank realized its error within 24 hours and asked the lenders to return the mistakenly transferred money. Some did, but several lenders refused due to a strange quirk of New York law: the "discharge-for-value" exception. This defense applies when someone receives a payment that is, in fact, owed to them. That recipient can keep mistakenly sent funds so long as

• the recipient did not fraudulently induce the payment and 
• the recipient did not realize at the time of receipt that the money was sent by mistake. 

Citibank filed a lawsuit to recover the unreturned funds, which totaled about $500 million. Most of the facts in the litigation were simple. First, Revlon did owe its creditors, though the total amount was not due until 2023. Second, the payments the lenders received were correct payoff amounts, down to the penny. Third, the lenders—who weren't even expecting payments—did nothing to induce the payoff. So the only real question for the court was whether the lenders immediately realized that Citibank made a mistake when it sent the payments. 

...the only real question for the court was whether the lenders immediately realized that Citibank made a mistake when it sent the payments. 

To make that determination, the court relied heavily on evidence from chat messages—which brings me to the first lesson of this case. 

Chat Messages Make for Useful Evidence

The judge, in this case, considered several types of evidence in deciding that the lenders did not initially realize that Citibank accidentally sent these payments. First, the court opinion cited "a slew of communications evidencing a contemporaneous belief on the part of the Lenders that the payments were a full [and intentional] paydown" of the loan.

Second, the initial news coverage also pointed to chat messages as a critical component of the court's evidence. That caught my eye, as we frequently talk about the importance of preserving messages from collaboration tools. The most egregious examples included these:

DFREY5: I feel really bad for the person that fat fingered a $900mm erroneous payment. Not a great career move . . . .

JRABINOWIT12: certainly looks like they'll be looking for new people for their Ops group

DFREY5: How was work today honey? It was ok, except I accidentally sent $900mm out to people who weren't supposed to have it

But I'll be honest: when I first read this story and saw these chats cited as evidence, I didn't understand the judge's logic. To me, these chat messages indicate that the recipients did assume the transfer was a mistake. So how did the court use that evidence to reach the opposite conclusion? That brings us to our second lesson.

Complete Metadata Is Critical to Interpret Chat Messages Accurately

It turns out that the ruling was all about the timing. Immediately after Citibank sent the money, no one was making jokes about it. A few messages were sent asking whether anyone had expected a payoff, but for the most part, it was business as usual. The next day, though, Citibank recognized its error and started sending recall notices asking the lenders to return the money. It was only then that the shocked jokes began. 

The court pointed to this timing as proof that no one recognized the mistake when the funds were first received. Before the lenders received any recall notices from Citibank, "communications reflecting a belief that the payments were made by mistake" were "conspicuously absent from the record." The court surmised that the lenders did not initially recognize the mistake from the number of messages exchanged after Citibank sent its recall notices. If they had, they would have been making snarky comments about it the day before—and they weren't.

The point here is simple: to understand what happened or convey to the court an accurate picture of disputed events, you must be able to establish a verifiable timeline. To establish a timeline with instant messages, you must have precise, complete, trustworthy metadata that demonstrates who sent them and when. 

But there's one more lesson that struck me here: none of this had to happen, and it wasn't exactly the human error that led to this hugely expensive mistake. 

Poorly Designed Software and Bad User Interfaces Cause Errors

One Bloomberg author referred to the Citibank error as "a gothic horror story about software design." However, a UX design expert opined that a more user-friendly interface could have prevented the mistake. In his view, "just adding more clear instructions for each field and using more human-friendly language and terms" would have "drastically" improved the software, reducing the chances of such an error.

This lesson is essential for us, of course, as designers. We must never forget that our software's job is to be so easy to use that our users don't make avoidable mistakes like this one. But I'd argue there's an equally important lesson for software users: be critical of the software you interact with every day. Are you tolerating a lousy interface because you're used to it? Do you use a poorly designed system that forces you to do things in a wrong or frankly stupid way? Have you stopped to think about what costs you might incur due to that poor software design? 

At Hanzo, we've spent several years urging people who use collaboration applications like Slack to integrate those messages into their corporate ediscovery and information governance workflows. This case highlights the importance of instant messaging in corporate communications and the central role those messages can take in resolving factual disputes. We're way past the point of assuming a "don't ask, don't tell" strategy around ediscovery for instant messages, be they from Slack or another chat application. 

This case highlights the importance of instant messaging in corporate communications and the central role those messages can take in resolving factual disputes.

Is Your Organization Prepared? 

If your organization uses messaging, chat, or collaboration platforms to conduct its internal business, you need to prepare now. Ediscovery requires you to identify and extract information—including complete metadata—from these platforms. You don't want to discover that you are not ready to meet your obligations when it's crunch time.

[View source.]