Three People Approved. The Interface Decided.

What They Missed · Part 06/10

It is 11 August 2020, and the transaction on the screen is routine. Citibank acts as administrative agent on a 2016 term loan to Revlon, the cosmetics company — the bank in the middle, collecting payments from the borrower and distributing them to the lenders. Today an interim interest payment is due: roughly $7.8 million, spread across hundreds of funds and institutions. The software that will move the money is Oracle's Flexcube.

The person entering the transaction — the maker, in the language of the procedure — follows the path the system allows. Flexcube has no clean way to send interest alone on this loan. The working method is to enter the payment as if the entire loan were being repaid, then point the principal at an internal "wash account," so that only the interest actually leaves the bank. On the screen, this comes down to a handful of fields and checkboxes. He sets the field marked PRINCIPAL to the wash account and moves on.

A second person — the checker — reviews the entry and confirms it matches the procedure. A third — a senior manager in Delaware, the approver — reads the summary, notes in an internal chat that the principal is headed to the wash account, and signs off. Three people, exactly as the control requires. The payments go out.

What actually happened

The next day, Citibank discovers it has not sent $7.8 million. It has sent roughly $894 million of its own money — the full outstanding principal of a loan not due until 2023 — to Revlon's lenders, along with the interest.

The error had passed through a control built precisely to stop it. Citibank ran a six-eyes procedure on payments of this size: a maker enters the transaction, a checker verifies it, an approver gives the final sign-off. All three steps happened. All three people believed that setting the PRINCIPAL field to the wash account would keep the principal inside the bank. The system's manual said otherwise: to suppress the principal, three separate fields — FRONT, FUND and PRINCIPAL — all had to be set to the wash account. Only one was. Flexcube did exactly what its configuration told it to do, and none of what its operators believed they had told it to do.

There was even a warning. Before the final step, the screen displayed a notice that the account in use was a wire account and that funds would leave the bank. It did not say how much, to whom, or why that might be worth a second look. It was the kind of warning that appears on correct transactions too — and so it was acknowledged the way standing warnings are, and the run proceeded.

What followed moved the case out of operations manuals and into courtrooms. Citibank asked for the money back the same day. Some lenders returned their share; roughly $500 million was withheld — in part because the amounts received matched, to the penny, what those funds were owed on the loan. To the recipients, it looked like a deliberate early payoff. In February 2021, Judge Jesse Furman ruled that under New York's discharge-for-value doctrine the lenders could keep the money, calling the event "a banking error of perhaps unprecedented nature and magnitude." On 8 September 2022, the Second Circuit reversed the decision unanimously, and the money eventually came back — more than two years after three people approved an interest payment.

The approvers answered the question they could see

It is tempting to file this story under human error, and the court record does name humans. But look at what each of them actually did. The maker followed the documented workaround. The checker verified that the entry matched the workaround. The approver confirmed that the principal was pointed at the wash account — which, on the screen in front of him, it was. Every person in the chain answered the question the interface put to them, and answered it correctly.

The question the interface put to them was: are these fields configured the way the procedure says? The question the system was actually executing was: should $894 million leave the bank today? Those are different questions, and nothing on the screen translated one into the other. The approval step measured configuration. The consequence stayed invisible.

Part 4 of this series told the opposite story: Knight Capital, where faulty code traded for forty-five minutes because no human gate stood in the loop at all. Citibank–Revlon is the harder lesson, because the gate was there. Three qualified people stood in the loop, took the step seriously, and clicked approve. The control did not fail for lack of humans. It failed because the humans could not see through it.

Approval is only a control when the approver can see what they are approving. Otherwise it is not a decision — it is a signature on a question someone else phrased.

What this means for your close

A monthly close runs on approvals: reconciliation letters, matching lists, payment runs, adjusting entries. Each one carries a signature, and each signature is assumed to mean that a person examined the thing and agreed. In practice, the honest answer to "what did the approver actually see?" is often a total, a status label, or a score — the configuration, not the consequence.

• Count the approvals in your close, then ask what each approver actually sees. A signature on a total is not a signature on the lines beneath it.
• Ask your systems for consequences, not configurations. "Fields set per procedure" and "this much money moves today" are different sentences; the approval screen should speak the second one.
• Treat standing warnings as a finding. A warning that appears on correct transactions trains people to acknowledge it on the incorrect one.
• Require a reason that can be read. Human approval is necessary, but it is not sufficient — it becomes a control only when it arrives with an explanation the approver can check and, when needed, reject.

The sentence under the signature

Consider what the same screen looks like when the question is phrased honestly. In a line-level close, a matching engine does not present a checkbox; it presents a claim. This payment closes these two invoices: same counterparty, the amounts sum to the open balance, the reference appears in the bank description, the dates follow in sequence. That is a reason chain — an argument the approver can walk through step by step and reject at any step. It is the difference between a score and an explanation, a distinction we set out in black box versus reason chain; and the matching itself is genuinely hard, for reasons we cover in FIFO and partial payments.

This is the principle iFinances is built on. The engine suggests; it shows its reasons in plain terms — company, amount, date, reference — and the approval stays human, asked as a consequence rather than a configuration. The machine's job is to make the sentence under the signature readable. The signature's job does not change. What changes is what the click means: not "the fields look right," but "I saw what this does, and I agree."

Frequently asked questions

Did Citibank get the money back?

Eventually, yes. In February 2021, a federal district court ruled that the lenders holding roughly $500 million could keep it under New York's discharge-for-value doctrine. On 8 September 2022, the Second Circuit reversed that decision, and the funds were returned. The recovery took more than two years and two rounds of litigation — for a payment three people had approved in minutes.

The bank had a three-person approval process. Why didn't it work?

It worked exactly as designed, which is the uncomfortable part. The maker, the checker and the approver each verified what the Flexcube screen showed them: that the fields were configured according to the internal procedure. What the screen never showed was the consequence — that with only one of three required fields set to the wash account, roughly $894 million would leave the bank. The control failed not because people skipped it, but because the approval step measured configuration instead of consequence.

What does a wire-transfer error have to do with reconciliation software?

The failure pattern is the same at any scale: a person asked to approve something they cannot actually read. A matching engine that outputs only a score or a status puts its approver in the position Citibank's screens put its operators. An explainable match states its consequence in checkable terms — which payment closes which invoice, and on what evidence — so the approver can verify the reasoning or reject it. That is what turns a click into a control.

Return to 11 August 2020, one last time. Three people did their jobs. The maker followed the documented procedure. The checker confirmed the entry matched it. The approver read the summary, noted where the principal was pointed, and signed. Nothing about those three people needed fixing; what needed fixing was the sentence they were shown. Every monthly close contains versions of that moment — a queue of items, a set of screens, a person about to click approve. The question worth asking before the click is the one Citibank's screens never answered: does the approver see what actually happens next?

✦ iFinances — See what you're missing.