The issue is that programmatic checks probably wouldn't work in this particular instance, considering sometimes you do want to repay the principal.

The biggest problem is this whole notion of "fake-paying" off the principal as the means to calculate accrued interest by essentially piping the actual repayment to /dev/null but actually forcing the user to type /dev/null 3 times

> The issue is that programmatic checks probably wouldn't work in this particular instance, considering sometimes you do want to repay the principal.

Of course it would - simply have a different top of the decision tree that would hard code "PRINCIPAL REPAYMENT" in one and "NO PRINCIPAL REPAYMENT" in another. Do not allow filling out details on the screen that selects the flow.

Or, as I've seen in consumer bill-paying software, a confirmation dialog with extra info (given that the erroneous payment was two orders of magnitude unexpected): "Your last payment to Verizon was $78.98. Are you sure you wish to pay $7,898.00?"

These are good, and even better when they require confirmation by re-entering the value exactly as it was previously entered; however in this case, I don’t think it would have helped.

The number typed was correct, and it was even in the correct location. It was that it was not also included in two other locations that caused the payment to go through in the incorrect manner.

Given the assumptions presented by the UI, I’m not sure anything other than an extremely detailed confirmation dialog showing exactly where the amounts were going would have solved the problem.

Even then it’s not clear to me that that info would even be available given that the software never seemed to have been designed for the use case of a partial payment in the first place.

FLEXCUBE code base is two decades' worth of hard coded decision trees. Fitting yet another decision tree in there might break something else for every single loan.

The entire story is the cost of not recognizing you're an engineering firm that handles money, versus a bank that bolts on IT at the lowest cost possible.

Citi learned the hard way, which is good, as it's the only way for such an org to learn.

> Citi learned the hard way

Do we have evidence that they actually learned anything from this?

No, we just know that they paid for a lesson

Surely the cost of upgrading their user interfaces is less than the $500M lost here? What about next time? What about previous losses that were small enough not to warrant press attention but still add up over time?

To be clear, the entire $500 million isn't lost yet. Citi will need to carry the loan itself for Revlon, so the money didn't evaporate. The cost will be the admin overhead, the reputation loss from the event, and the cost for having to carry the loan into the future (or not, if Citi can find a way to securitize it out).

If Revlon defaults on the loan entirely, then the money evaporates.

The value of the debt is 42¢on the dollar. So Citi is down 58% on the book value of the $500M in debt. They lost close to $300M from the mistake.

Those are unrealized paper losses. The final accounting can end up being a loss of anything in the range of $0-500M depending on how it all shakes out (whether Revlon goes bankrupt, whether Citibank sells the loans on at their reduced valuations now or holds on, and how the appeal goes).

In all my previous companies whenever we earned more than expected from a given project, we'd routinely analyze it and it was our job to make sure we can somehow repeat or benefit from this lesson for the future. In the same way, whenever there was a significant drop, it was our job to make sure we know the reasons behind it and implement preventive measures if applicable. The only factor that changed was the level of 'why?'s asked.

I can't imagine it's any different in Citibank.

> I can't imagine it's any different in Citibank.

Having worked for companies the size of small startups up through megacorps, my experience has been that megacorps can be unfathomably foolish in these kinds of things.

I'd expect Citibank to be less likely to learn (and apply) the right lessons from this experience, than a small or medium-sized business would.

Did you read the article? Three people signed off on it.

To me the key part was that they couldn't create a new loan. The mistake wouldn't have mattered much if Citi/Revlon had been on good terms with their creditors.

Edit: Removed accusation.

Well the underlying issue was that they accidentally sent the money in the first place. The fact that they were on bad terms with their creditors meant that they couldn't correct the mistake after it happened.

> The mistake wouldn't have mattered much...

Accidentally sending nearly 1 Billion dollars is a pretty big mistake and it matters a lot. You can't just be throwing hundreds of millions of dollars into people's accounts and think its not a big deal because they will "probably" give it back.

Maybe. A billion here, a billion there. Judging from that UI and overview of their process/controls, I can't imagine this was the first time something like this happened.

It seems noteworthy because they didn't quickly restructure the debt. They weren't throwing money into random accounts, they accidentally sent payments early.

As was mentioned in the article, Citibank has a "six-eyes" policy. They had three people review and approve this transaction. They were all confused by the interface.

(I am not sure what this policy means if one of the three people has lost an eye; presumably it requires a fourth approval.)