In August 2020, Citibank was administering the loans to cosmetics and personal care company, Revlon. As part of that function, Citibank wanted to pay the interest due to the lenders. Using a software called Flexcube (as seen in the user interface below), Citibank accidentally wired the full loan amount (interest and principal) to the creditors: $7.8 million in interest and $894 million in principal — for a total of roughly $900 million.
How could that happen?
Three people in total checked the specifics on the transfer before it was sent. Every one of them thought it was correct and so it was approved and sent. To affect the transfer as it was intended, the software required people to check three checkboxes to overwrite the default settings: FRONT, FUND, PRINCIPAL (see screenshot above). However, the users thought that only one overwrite (PRINCIPAL) was needed. None of them consulted the user manual which explained the correct usage.
When they realized what happened, they contacted support and asserted the software must be defective. The bank then asked the lenders to return the money, but the lenders refused. The parties took the issue to court, where it was decided in February 2021 that Citibank only got $400 million back — a loss of $500 million.
Let's look at the issue from a user experience (UX) and user interface (UI) design perspective.
Problem 1: Software Failed to Consider All Relevant Use Cases
The software didn't consider relevant use cases. Paying only interest to multiple creditors wasn't a scenario the software could directly process. To make an interest payment without the principal, users had to create a new account in Flexcube which was set to pay creditors the full amount due by default. So anyone using the software had to use multiple overwrites to exclude the principal from the transaction. This “patch” turned out to be not only inefficient but also error prone.
Wiring only interest shouldn't be a rare edge case that can only be handled indirectly. A proper design and development process identifies all relevant use cases, which then creates a system where users can execute their work effectively, efficiently and comfortably.
Related Article: Up Your UX Proficiency in These Areas
Problem 2: Assuming People Would Know How to Use the Software
The software creators and the bank over-relied on users knowing the software. Further, they over-relied on the users being aware of the manual, using the manual, understanding the manual and acting according to the manual. But humans are imperfect. Humans forget information. Humans misinterpret information. Humans make errors. Even three people can be mistaken. Technology — when properly designed — can help so we don't have to fully rely on users’ knowledge of software and manuals. Technology can add another layer of safety. Which leads me to problem three ....
Problem 3: A Mismatch Between Conceptual and Mental Model
The software did nothing to help mitigate the mismatch between how the software actually worked and how the users thought it would work (UX godfather Don Norman calls this the mismatch between conceptual and mental model). That the users contacted support after the fact and claimed the software was malfunctioning shows they did not understand how the software works.
As stated above, you should not rely on the existence of manuals for help. A context-specific online help would have allowed the bank associates to look up guidance directly from the UI at the moment it was needed. The challenge with this incident is that the associates thought they were doing the right thing, so why would they consult help?
Related Article: Use Behavioral Intelligence to Improve Your Site's User Experience
Problem 4: The User Interface Lacked Any Error Prevention
No appropriate error prevention was built into the software. This violates long-standing UI design principles: One states that the user interface should prevent a problem from occurring in the first place by either eliminating error-prone conditions or by checking for them and presenting users with a confirmation option before they commit to the action (this is one of 10 design rules from another UX godfather, Jakob Nielsen).
When you edit a document in Microsoft Word and hit the Close button, Word will ask you something like “Are you sure you want to quit without saving?” In the Citibank case, the UI should have summarized in detail what would happen before finalizing the transaction and ask for an explicit confirmation. It should have shown all amounts (interests and principals) per creditor and showed the sum of all outbound transfers as $900 million. The design could have included a special formatting for sums that high, for example a large, bold red font to draw attention. At that point, the users would have seen and realized their mistake and hit the cancel button rather than finalizing the transaction. Instead, the UI only showed a generic confirmation dialog that stated: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?”
Don't Forget Humans Are Part of System Design
The software was clearly built without proper user experience considerations, both in terms of process and the UI design. The UI looks dated, but age is no excuse for poor design as the UI design rules mentioned above date back to the 1990s.
Why then was the software never fixed?
Because until the incident, the software worked. But as other cases (e.g., the explosion of the space shuttle “Challenger”) have shown before, things will go wrong if the right (read as: wrong) conditions are met. While this is rare, it will eventually happen. And when it does, the outcomes may be catastrophic, and nobody can imagine how the “obvious” flaws of the system could be missed all that time.
Following a user-centered process which systematically includes the future users when designing and building interactive software is the key to prevent events like this from happening. From a system design perspective, humans are as much a part of the system as the technology. The software therefore needs to consider the human perspective. What are people good at, and what are they bad at? How do users think about accomplishing their workflows, and what are their mental models? This in turn requires designers and developers to engage with future users to learn their perspectives. The use cases covered by the software need to be tested with real users for proper usability. Can they accomplish their goals? Do they make mistakes? Is there anything on the UI that confuses them? Does their mental model correspond with the conceptual model? Is there anything missing they would need? How easy or hard is it for them to execute relevant use cases?
Finally, while this article is focusing mainly on UI and UX, it is important to note that these factors weren't the only issues. Topics like training and risk management played vital parts as well. Stakeholders often say: “How much does it cost to do all these things? It sounds expensive.” Instead, the question should be: “How much does it cost not to do these things?” And the answer in this case is $500 million.