Judge: Citibank isn't entitled to $500M it sent to various creditors last August
arstechnica.com
arstechnica.com
I don't even have anything to add. The paragraph speaks for itself... You can't make this up
ALL THREE PEOPLE INVOLVED IN THIS TASK WERE CONFUSED by the interface and all three thought that this was the correct way to do this.
This wasn't the case of one person checked the wrong box. Everyone who looked at this was confused. This problem was not individual, but systemic.
These things were put together in haste in the 90's and Oracle keeps pushing them and their corporate customers keep these things going long past when the interface becomes utterly unfamiliar.
The blame has to be shared, however, with the battle-axe personalities of the people that use this stuff. They would like nothing more than to retire while still using the _exact_ same applications and dated interfaces they've used for 20+ years. Literally, these are default "grey-theme" java applications, with all kinds of inconsistent UI quirks and absolutely no shits given for discoverability or even being able to create hyperlinks so that people can share stuff without screenshots.
It's fine if it's the same people keep using these apps forever, but the problems start when new people get on-boarded. If it's like most places, the newbies will be given no training and the only help they will get would be from some dour in-house oracle-application jockey whose been doing the same thing for decades. That's when people make very, very expensive mistakes. We hear about this one because the sum was vast, but people make $10,000 mistakes on shit software from Oracle all the time-- that's partly why Oracle has a very deep bench of retained lawyers, I suppose.
I have to say Citibank deserves it.
There's a psychological defect in the human brain called Anchoring. If you are first presented with the wrong answer to a problem, it affects your ability to objectively come up with the 'right' answer. You will not catch all of the garbage I threw at you because I threw it. "Double" checking is a misnomer because it's not really doubling the number of brains.
Some things should work more like nuclear launch codes. I don't approve your action, I perform the exact same action, and if we both did exactly the same thing, then something happens. If we don't, then nothing happens or you get an error.
Might this problem still have happened? Yes. But the first time it happened would probably have been taken more seriously, instead of what we usually do: deflect, deflect, deflect.
Unfortunately because of the court case, instead, people associated are the users.
Pretty much every modern financial app I've used has one of those confirmations - some better than others but all pretty clearly state "you are going to transfer $XXXX.XX to ACCOUNT_YYYY -- click here to approve transfer".
Even venmo's quick prompt to make sure you really mean to send your pet sitter $125.00 before initiating a transfer would have avoided this problem.
I know you didn't mean it this literally but the issue is worse than that. They weren't confused. If they were confused, they would have sought clarification. Instead, they were sure they were doing the right thing.
Overwrite default settlement instruction
Select the ‘Overwrite default settlement instruction’ check box to confirm
that the liquidation entries should be posted into the Internal GL account.
System posts the entries to the Internal GLs only if you check this check box.
Otherwise, system posts the entries as per the settlement instructions specified
for the component of the contract.
> Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was Raj, a colleague of his in India, and a senior Citibank official in Delaware named Vincent Fratta. All three believed that setting the "principal" field to an internal wash account number would prevent payment of the principal. As he approved the transaction, Fratta wrote: "looks good, please proceed. Principal is going to wash."
Somewhere in there, one of the SREs said something that's stuck with me. Roughly, he said that the concept of human error is useless. Every time a human error escalates into a real problem, the deeper problem is a design flaw. At scale, human errors are a certainty, and, while documentation and training is far from useless, no amount of it can change that fact. It's therefore a critical responsibility of systems designers to design their systems to be resilient to mistakes.
The solution they came up with was a "Grinder Off" button that lit up to indicate the grinder was turned off. It was...confusing to say the least. And as an infrequent user of this coffee maker it was all too easy to screw up. To add insult to injury, that off light turned off (i.e. enabled grinding) every time you brewed a new pot. You had to be sure to press it every time you brewed from pre-ground beans, which was always for us.
My digital kitchen scale turns off pretty quickly after use. This is terrible, because it also doesn't remember tare (i.e. the weight of the empty container you put onto the scale prior to filling it), so when you turn it back on it zeroes on whatever's on the scale. Did not read the measurement immediately, or forgot the value? You now have to empty the content into another container and try again. Annoying if you're measuring uncooked rice. Infuriating if it's sticky, ultra-viscous fat.
My dishwasher has a "COMPLETE" light that tells the household that a washing cycle finished after the door had last been closed, a signal that the contents of the dishwasher are likely clean (unless you leave the light on after emptying, but we rarely forget). But if you close the door accidentally just once after that, the light stays off, and there is absolutely no way to put it back on without a washing cycle. I read the manual, tried various logical and illogical key combinations, nothing. Now you have to tell your household "I didn't have time yet to put all the clean stuff out but the light is off, please remember that".
My TV likes to switch automatically to its internal speakers for various reasons, which I never want to use because they are terrible in this particular TV, and switching back requires going through multiple laggy submenus. But worse, if I turn the TV on and notice it's on internal speakers again, I have to wait for it to finish booting completely before I'm allowed to navigate the laggy submenus.
To leave this rant on a more positive note, though: The digital interfaces of my coffee maker, my microwave, and my water cooker (multiple temperatures, auto-reheat, auto-shutoff) seem to do exactly what they should, under many and sometimes non-trivial circumstances, so I'm glad good UX design still exists.
That coffee maker is well designed for its intended happy path use case, which is not the same as you can say for this Oracle software.
On top of that you're also supposed to clean and dry the grinder parts after every use or it eventually gets clogged. I just switched to pre-ground coffee and a simpler coffee maker.
You are about to send $83,932,198.83 to (various account information fields)
Unlike, say, a site that sells hand knit mittens or maybe organic kibble.
https://news.ycombinator.com/item?id=26170694
:-)
The next paragraph continues:
Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was Raj, a colleague of his in India, and a senior Citibank official in Delaware named Vincent Fratta. All three believed that setting the "principal" field to an internal wash account number would prevent payment of the principal. As he approved the transaction, Fratta wrote: "looks good, please proceed. Principal is going to wash."
In the case of b2b, it’s more complicated. You’re selling to office administrators, whose goal is to score the best deal for the company. Since they aren’t the primary users of the product, stuff like UX doesn’t matter as much as cost.
Best illustrated by Slack, which thought they could sell to businesses based on a beautiful UI, but their market was dominated by Microsoft Teams, which could sell better to enterprises.
One day, a novice-level Java error in Oracle’s code caused a multi-day outage requiring data to be restored from backups and reloaded to get any functionality back and several months of that group deploying duct tape to get everything working.
For a consumer app, people would leave in droves as one star reviews poured in. In this case, they solved this by inviting the relevant VP to a football game in the corporate box with the account rep, both of the same fraternity, and starting that Monday nobody in management talked about the outage publicly again.
This UI is pretty good ! Haha. No seriously today we had a one hour conversation on what happen when a user cancel a trade twice. I don’t think we’re gonna find a elegant solution within the contraints of the clusterfuck of sub-system we maintaining. Kinda disheartening.
If I am an approver of a $900M transfer using an edge case I will follow instructions:
"Citibank’s internal Fund Sighting Manual provides instructions for suppressing Flexcube’s default. When entering a payment, the employee is presented with a menu with several “boxes” that can be “checked” along with an associated field in which an account number can be input. The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL” — meaning that the employee had to check all three of those boxes and input the wash account number into the relevant fields." [1]
[1] https://www.bloomberg.com/opinion/articles/2021-02-17/citi-c...
Conway's Law applies here. It's a hugely dysfunctional bank, saddled with bureaucracy, fragile software (company change control ran on a IBM mainframe as late as 2015, requiring IE6), teams that are 'silo-ed', and talking with other teams are often the equivalent of a divorce lawyer's communication between spouses.
Sandy Weill's crowning glory of mashing together Salomon Brothers, Smith Barney, Primerica, Travellers, Citicorp, and Diner's Club.
resulting in issues like Citi got. Seriously who thought that UI, requirements, text, and all, was a long term solution for handling any amount of money?
> Citibank's procedures require that three people sign off on a transaction of this size. In this case, that was Raj, a colleague of his in India, and a senior Citibank official in Delaware named Vincent Fratta.
The names of these individuals seems like an unnecessary detail, especially since the article names the software interface as the culprit. I can't help but think about the recent NYT/SSC incident.
They aren't naming the designers of the software, the devs who implemented it, or any number of other middle managers and other folks involved in building it and maintaining it. Just these 3 unfortunate individuals who failed to use it properly...
Seems like it works for design as well.
The blame rests on the software vendor who built such an atrocious product and decision makers at Citibank who chose that software, in my opinion.
Just because their names are relevant to the court case doesn't mean they are relevant to readers of an article reporting on that court case - especially when that article doesn't even bother to identify the court case itself or the software vendor implied by the article to be responsible for the root cause of the matter.
Both laziness and foolishness are in ample abundance, so the two men now will have to live out their lives marred in this scandal for no good reason.
Had the names been withheld the same lazy fools would run out of their attention span before they could find the names in the court papers.
The UI bug and the impact is interesting, but the names of the individuals or where they are from add no value to this article.
If the intent is to just provide the reader with more relevant information, surely the identity of the development firm behind Flexcube would be more relevant. Again, that information is conspicuously absent. It seems Flexcube was developed and distributed by Oracle.
If this sort of behavior is the result of "journalistic standards", then maybe it's time for those standards to be revised.
The information is drawn from public court documents and the incident is something with nearly a billion dollars in consequences that affects multiple publicly traded companies.
What do people think the word "news" means if not this?
But who cares that Citi lost half a billion dollars because of an interface mistake?
The latter is news. The former is not. The story loses none of its impact or relevancy leaving the names out.
Not really. In Germany it's very uncommon to name individuals in news reports, even in murder cases. If at all the format used is Angela M.
There is always a balance between the 'personality rights' of the individual and the public's right of information.
The story here is a good example - there is zero need to know the individuals' names.
You don’t actually say what this thing we’re supposed to understand is, but I think you’re implying that it’s in the public’s interest to know it? If that’s what you meant, I’d disagree that these names are in the public interest.
Sure, their names are “news” but how does the name of someone who made an innocent mistake help me understand the news? What’s the value-add? The “ROI” seems in strongly negative territory here.
Naming the developers who wrote this and signed off on it, now that might be more relevant.
When pressed they'll blab some indefensible nonsense about their duty as a journalist, which apparently includes throwing innocent people under the bus with a flourish.
I’ve got no sympathy for Citi and the litany of penny-pinching that created the situation. And I loathe that their first reaction was probably to require ANOTHER layer of bureaucratic approval. But I don’t find any value in embarrassing the people who pressed the buttons.
Nobody is saying they aren't allowed to publish the information. Tabloids exist and can say whatever they want, but a serious outlet like Ars is held to higher standards by their customers. I assume Ars removed the names because they agreed those details were unnecessary and only served as a potential liability for those named.
Free speech means the freedom to say or not say what you want. Ars chose to not say something of their own volition.
So it's really the design of the software and not just the style of it that was wrong and had to be improved. A usability professional would have caught that immediately - and would have been way cheaper.
This is what happens when Oracle just bangs out UI elements with whatever tool they use for it that just check off a list of product features.
There’s literally no design happening here.
Need a banking app? Give me the features... bang flexcube.
Need CSR software? List of features...
Need inventory management? ...
They’ve been doing this shit for years and winning deals because they’re “enterprise”
Those old things were so lean, so fast, so cheap, zero fancy feature, zero presentation, zero confusion. And the software used every cycle to either make you go on, or then check or even prepare fixes (think live typecheck suggestion in your IDE but for accounting input operators).
I was brutally shocked by the contrast between everything I've been fed and seen in college (that said these were the j2ee 4 days .. so peak sadness). Of course by the time I left there was some grand plan to replace it with modern html/css/js evil reincarnation that was slower, and less useful.. basically going back from your old makita impact driver to the shiny new bluetooth connected released yesterday that will fail and require the v2 before being barely useful.
tl;dr: glory to old terminal application made with skills.
To be fair, lots of risk-mitigation investments are cheaper in hindsight, once you know the risk actually got realized.
Explain on top of that the scheme for the interest payments and he will notice that the UI does not fit to that purpose at all. Why would paying interests involve a wash account and a real money transfer at all? If that's the job to do the UI has to facilitate it directly, not with crazy schemes. That's Aufgabenangemessenheit (to be fit for the purpose, not sure about the official translation) and it's the highest dialogue principle. That got completely ignored here. This was never usability tested, I'm certain - or if it was the results were ignored.
It really is the norm. I've worked a handful of different jobs over the years and always got an extensive onboarding guide because the section for the software is just so bloated. Software with good UI could've easily reduced the guide size by 3/4.
This was an issue of an operations team that just did not know how their system worked. Perhaps the system design could have been better. Most likely it could have been, but if Citi had a team of people using a system responsible for billions of dollars without the competence to use it correctly, that failing goes way beyond the UI.
The user thought that setting the target account in one line would be enough to have the money be sent there instead of where it ended up being sent to. There the UI was misleading, that's a violation of the self describality a dialogue has to fulfill (I'll freely translate the principles, I would have to look up the official english translation); in that the UI has to communicate by itself in which state it is, what every button does, every icon means, what even is clickable etc.
Then the system did not clearly communicate what would happen. That's not only an issue of describing itself, it's also an issue of fault tolerance. The system did not prevent the user from a mistake he was about to make. This could have happened by clearly describing what would happen at the end of the process and offering an undo operation. They tried to implement this outside of the UI by requiring 2 additional set of eyes, clearly that was not a sufficient solution.
But most importantly, the process the UI was offering was the wrong one for the job. This was about sending parts of a debt to creditors. Instead of offering a clear way to do that, they had a convoluted process that involved a wash account plus a real money transfer to that account (how crazy is that!) instead of supporting exactly the work that was to be done. That violates the primary dialogue principle: Be the right tool for the job (Aufgabenangemessenheit). Admittedly, I miss context to know for sure what would be the right tool for the job and why they ended with this solution, maybe it's a bit less crazy than it sounds.
Yes, all of that together goes far above simple UI issues, but it's nonetheless an issue of the UI. It's just also a complete usability fail. It's really the job of usability professionals to analyze software and scenarios like this and to provide better solutions. That was and partly still is my job :)
The headline ideally should have called it an usability issue. That would have covered the UI part and included the other aspects.
They likely just got document that when you receive message with these fields filled this should happen. And then other team of programmers had implement UI with these fields and then make it send message here.
Scenario from article would be solved by UI if the requirement would be "SEND MONEY [YES/NO]; AMOUNT [XXXX]; APPROVALS [JANE/JACK/JILL]" but that is not what that window is doing and at that level there is no "SIMPLY SEND $7.8M; MAKE IT NOW [YES/NO];". I don't even know what it takes to move $7.8M to different accounts but I expect it is quite involved process that has to trigger multiple different things.
Internal applications have to be more complex that external applications - that's why you sometimes have to call a company to do something the consumer frontend doesn't support. The employees are expected to operate a more powerful/flexible system than the customer, and I think there's always a risk inherent there.
In this case, it's likely that it's not just a dumb UI thing that the employee "needed to set the "front" and "fund" fields to the wash account as well as "principal." I suspect thank "front" and "back" are actually real business concepts in how the bank models transfers which the employee/reviewer did not understand well. Instead they expressed a different model of a transfer (an external one) which is a totally legitimate use case, just not the intended one.
That's kinda one level of empathy, I suspect this really happened because these users think about these operations as "I check this box, then I check that box" rather than "I get how transfers work and I am going to express my intention using that understanding." So it's probably much more of a training issue, because to give these people a very narrow and polished consumer-style frontend would take away the flexibility they likely need to actually execute their roles.
A ten pound sledge hammer can be used to drive finishing nails in fine furniture but it would be absurd to claim that all the dented furniture coming out of your shop is a result of poorly trained workers rather than inadequate tooling.
A generic hammer, like this UI (at least, as much as is apparent from the screenshots in the article) can drive basically any nail. But specialized hammers exist for good reasons. This is equally applicable in software tools.
A good tool should enable you to do things you couldn't do without it but the best tools make it easier to do what you want and harder to do what you don't want.
My decade-old Quickbooks software similarly lets me create GL entries and assign amounts to the accounts involved. If I let my $12/hr intern who doesn't know what they're doing use that feature and they post to the wrong accounts, then of course bad things will happen. Instead, he uses other more specialized interfaces (like you suggested) to enter things like invoices, bills, etc. We give children safety scissors, and expect adults to be able to handle the real thing.
I really do have sympathy for the employees involved, and strongly agree with your sentiments that software should be engineered for safety. But I encourage anyone else reading this and forming an opinion to click into the article and have a glance at the screenshot.
The form looks like it can accomplish all sorts of things and business logic, just like a SQL query can accomplish all sorts of things and business logic in a database.
There's nothing inherently wrong with that. But like you say, the issue is with training.
The fact that 3 people who were presumably trained in how to use this tool, used it wrong, means it's absolutely a failure of training.
Business logic very often isn't "intuitive", because tools are used in all sorts of ways. When it comes to business logic, what's often most important is documented procedures and checklists.
The real question is, since this was a procedure that had been performed regularly and correctly in the past, why did it fail this particular time? Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?
Oftentimes it's an employee turnover/transfer/vacation issue that exposes the lack of documentation, and the real issue is too much knowledge in employee's heads that isn't committed to paper in the right places -- pure sloppiness of business procedures.
> The Fund Sighting Manual explains that, in order to suppress payment of a principal amount, “ALL of the below field[s] must be set to the wash account: FRONT[;] FUND[; and] PRINCIPAL”
and checklists:
> Raj then emailed Fratta, seeking final approval under the six-eye review process, explaining “NOTE: Principal set to Wash and Interest Notice released to Investors.”
and confirmations:
> which prompted a warning on his computer screen — referred to as a “stop sign” — stating: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” But “The ‘stop sign’ did not indicate the amount that would be ‘sent out of the bank,’
To answer your question "Why were these 3 employees left to assume they were using the tool correctly, rather than referring to a definitive documented procedure that would give them the answer for sure?" My guess is that the manual is a million pages long and incredibly confusing.
My takeaway from this is that you can't train and document your way out of a core human factors issue. Your point about SQL queries is apt; that's why you don't just give humans access to prod.
This is no more user error than Boeing’s recent sensor disaster. Sure if the pilots had the proper training none of that would have happened, and Boeing didn’t make sure they had it. But it wasn’t a training failure that was the issue with with the Max 8. Training was only a second order cause.
The first UI issue is the obvious lack of intuitiveness. There is ancient software that is resonably intuitive to use, because the people who led development took responsibility to do the right thing: invest in UX/UI so that their software is a success. Others however cut corners to get more short-term profits, or dismiss design as if it was decoration (it's not, good design is form + function and most serious designers pay more attention to the latter than the former).
The second UI issue is (an assumed) lack of feedback in the output of the transaction. After doing the transaction, if there was a feedback screen confirming to the user what they've done, the error could be caught much more easily. For example, before actually sending any transaction there could be a screen saying: - Summary of transaction - X$ will be sent to account XYZ - X$ will be sent to account ABC
This looks like obvious stuff, but is often obvious stuff and small details what turn a problematic user experience into a succesful one.
I am also recognizing that both you and I may not understand the complexity. Saying "X is being sent to ABC" may be a gross-oversimplification of the transaction and could obscure lots of badness. It's possible that the level of complexity of the screen IS what's needed to express it.
Analogy:
Would you expect to walk into the cockpit of an airliner and see a big dumb screen that tells the pilot "you are landing the plane?" or would you accept that it's a complicated serious of operations which the pilot understands by putting together the various bits of info on various instruments. Hope the parallel is clear.
Again, by no means am I insisting this is a great application (I don't know anything about it) but that you can only simplify the display of very complex state so much.
You can't judge intuitiveness without knowledge of the intended userbase and usage pattern. A sovereign app for specialists in a process can be intuitive with a design which would be radically unintuitive for an occasional-use app for people only tangentially aware of the same process.
> Looking at the evidence, I would say this is a pure UX/UI issue at root: three people got confused about what they needed to do, and they all thought they completed their task successfully when they didn't.
It's definitely a UI/UX alignment issue, where the understanding/knowledge of t(at least some of) the current users is not aligned with the assumptions of the UI.
But without knowing a lot more, it's hard to tell if the real problem is UI/UX design or processes and procedures for maintaining, assessing, and addressing (whether through system changes or otherwise) the current understanding and evolving needs of the current staff.
We aren't at the point where it is legitimate to expect software adapt automatically to changes in the userbase.
> For example, before actually sending any transaction there could be a screen saying: - Summary of transaction - X$ will be sent to account XYZ - X$ will be sent to account ABC
These sums up what I think too. I get that internal software is more complex, and bank transaction are also complex, but when three people checked it, though it was good to go and didn't realize a mistake until the next day, that's a problem.
Showing a summary of how much is being sent to where, and how much is going to stay in the account is the minimum I would expect for a finance software that's used to transfer millions of dollars in a single action.
of course it is...
Honestly with names like "front" and "wash" the whole thing should be checked by tax officials. The words probably mean something else, but ... wow
It's funny how worked up and self righteous one could get even while recognizing that they don't actually understand the concept. It's particularly amusing that you were alarmed by "front" (what, like a mafia front?) when there's also a "back".
I have never worked at Citi but I can make reasonable guesses as to what these accounts are.
Wash is a term that means "funds did not leave the firm" (you may have heard the expression "it's a wash" to mean "things net out to 0."
Front and back may have to do with direction of funds flow, or perhaps a hierarchy of accounts (like "we are pulling from account X on the back-end and into account Y on the front-end")
Not saying these are exactly right, point is that as someone who's been in finance for a long time these are totally innocent.
All enterprise software is terrible like this. It's because the people ordering the software are disconnected from the people who will have to use it
This made me laugh so hard, I can just imagine some bank executive hearing this and nodding, thinking they're going to change the world somehow.
> The system is embedded with a patented blockchain adapter that enables Oracle FLEXCUBE to interface with any blockchain system. The adapter enables a seamless interchange of information between Oracle FLEXCUBE and external blockchain data setscan work with any version of Oracle FLEXCUBE with minimal changes. The easy configurability of the adapter enables banks to leverage blockchain technologies to solve business problems,improve process efficiency, reduce risk and enhance straight through processing.
I think I'm just being trolled now
"best in breed"
"pre-integrated"
"...unlocks intelligence ingrained in..."
such presentations remind me of Rockwell's Retro Encabulator:
Our application is not immune to exposing exceptions to the business. But, we have added measures throughout to minimize this as much as possible. In areas where there is a lot of jargon which might confuse new employees, we put help buttons which allow a user to quickly review important terms & other documentation in-line with the actual functionality. This makes our application almost a training course in and of itself.
Additionally, in cases where we identify that poor choices could have broader impacts to other parts of the business (i.e. lighting 500mm on fire), we add explicit validations with hard cutoff limits to prevent insane things from happening. In this specific case, we would probably walk the user through a decision tree to force them down a valid path and ensure the funds were being tagged to the correct account(s). We also have approval loops in our application for more sensitive operations, but even these have integral validations & other measures to ensure that "experienced" employees don't screw up either.
I'm terribly afraid that you're going to be punished for focusing on the right things.
If you all could see how frustrating Ariba (by SAP) is, you'd have a great laugh.
That doesn't necessarily follow, lawyers have a long tradition of including "cover your ass" clauses even if they don't think it's likely that they would be liable without it.
We use Oracle for our HR system and it's the single worst piece of software I have ever used (and that includes Windows Me!).
> But the law makes an exception when a debtor accidentally wires money to a creditor. In that case, if the creditor doesn't have prior knowledge the payment was a mistake, it's free to treat it as a repayment of the loan.
There's a major UI issue here, no doubt about it.
But, it's important to also point out how bizzare this exception is, how did this even get included as the one and only exception?
So, if I borrow $1,000 from you and am supposed to pay it back next month, and then the due date arrives, and I accidentally transfer $1,000 to you, then yeah, it makes sense that you should be able to keep the money you are owed, even if it was sent mistakenly. It would be bizarre to demand that the creditor return the money to a debtor who is at risk of stiffing them.
But in this case, the due date for repayment was far in the future, and it makes far less sense for the exception to come into play.
That said, I don't understand why the creditor would want to hold onto the money. If they made a loan, they did so to make money off of interest payments, and if the loan is prepaid, they make less.
EDIT:
I read more about the lawsuit. In most cases, it doesn't make sense for the creditor to want to hold onto the money.
But in this case, the creditors were on bad terms with the debtor and were worried that if they returned the erroneously transferred money, they might never see it paid. So the exception to the law, which seems unnecessary unless the loan is past due, ended up benefiting them, because they got their at-risk loan paid back.
The borrower in this case is in financial decline, so they would not get the loan on those terms day. Imagine if you had a loan, lost your job, and then accidentally repaid the loan. The lender would be breathing a sigh of relief.
> Earlier in the year, as the pandemic was accelerating, Revlon experienced financial difficulties and sought to borrow more money. To do that, Revlon convinced a majority of its previous creditors to allow it to transfer collateral from its old loan to a new one.
> The strong-arm tactic angered the other creditors, who felt that the reduced collateral could leave them holding the bag if Revlon ran out of money. That's more than a theoretical concern: Bloomberg's Matt Levine reports that Revlon's debt is "trading at around 42 cents on the dollar." But under the terms of the loan, the minority lenders didn't have a way to force early repayment.
In any case, I doubt this ruling will stand, they are a huge bank and this is a decent chunk of change. They've got their ways to making sure the appeal goes in their favour.
The article mentions the creditor's impression of the company soured over time, and further their debt was trading for 42c on the dollar. So they got a nice little >2x return on expected value.
The point is, if the creditor is owed a debt, and receives payment for it, and A) He has no reason to think the payment was a mistake at the time he received it, B) He did not falsely induce the debtor to make the payment, then the creditor should not have to worry that the debtor will come to him the next day and say “Uh, that was a mistake, I want the money I owe you back.”
It is question how exactly the law is written. I would not bet on legal details to be exactly right in non-law-expert journal.
Here, a receiver or an errorneous wire transfer is not required to send them back based on the fact that wire transfer was unintentional on the sender side, but is required send them back based on the fact that the receiver do not have valid claim to that money.
If the law in NY has been formulated this way, the 'bizarre exception' would be just natural result of the law and not explicit exception. If a debtor unintentionally sends money to the creditor while the debt is due, then creditor has valid and legal claim on that money.
If you look at this sequence of events you can see why it might be problematic:
1) Bob has money, which he lends to Dave. Dave has possession but it's still Bob's money.
2) Dave returns the money to Bob. It's Bob's money and he has possession of his own money.
3) Nobody owes anyone anything and there's no obligation from either Dave or Bob to do anything as any agreement that existed has been fulfilled.
4) Court orders Bob to give Bob's money to Dave.
The action contemplated in point 4 here is a pretty extraordinary remedy. Even though it's Bob's money, and there's no contract or agreement outstanding that obligates him to do anything, and even though Bob has done nothing wrong and is not in breach of any obligation or agreement he's going to be ordered to give money, which is his and he has every right to have, to someone else.
It's pretty easy to see why the legal system might decide that's not something it wants to do.
That's not the way a loan is structured legally. Legally, a loan is a bargained-for exchange (a contract) in which the lender gives the borrower money and the borrower promises to make payments according to a schedule. (Note: It can be more complicated than that.) When the borrower receives the money, it becomes his money. If the borrower doesn't make the payments, then the lender can sue for breach of contract or to foreclose on a security interest if there is one.
> ... there's no contract or agreement outstanding that obligates him to do anything ...
By default, a lender is entitled to receive the stream of payments specified in the loan contract and is not required to accept prepayment if he doesn't want to (e.g., if the lender is receiving interest at 10% and the current rate is 5%, the lender does not have to allow the borrower to pay the principal all at once). Prepayment rules can be modified by the loan contract terms (e.g., imposing a penalty for prepayment) or by statute (e.g., a state law requiring housing mortgages to allow prepayment without penalty after some amount of time).
There's also a value to finality. Particularly given that we didn't have instant or even next-day transactions when these laws were written, allowing a creditor to move on with their lives once the debt seemed to have been repaid makes sense. And not having an exception would allow debtors to pay their debt and then reconstitute it days later if they changed their mind. Having this rule reduces the prevalence of that and the corresponding costs.
If you take out a $200,000 home loan with $200 minimum payments and accidentally make a $2000 payment ($1800 over the required minimum), I can see a request for an $1800 return being legally valid - granted you aren't behind on payments.
If you are behind, I would argue that including the total past-due, whatever is still overpaid, can legally be requested for return. So if you owe 3 payments, a request for $1400 returned would be legally valid.
However, if you are behind on payments, it could also be argued that you've breached trust with the lender and any money they receive from you is now theirs until the balance is $0. This is something that should be explicitly discussed in a loan contract prior to agreement.
Comparing an bank-to-individual loan and a bank-to-bank loan is a bit apples to oranges, but a massive unintentional overpayment can have serious ramifications, and I wouldn't write it off as simply as, "Well, you owe them a grand total of X, and even though you only owe them Y per month and overpaid, you don't get any of what you overpaid back".
> The UMB Complaint was the culmination of a bitter dispute between Revlon and Citibank, on the one hand, and a group of Lenders holding a large interest in the 2016 Term Loan, led by or including most Defendants here, on the other. The group of Lenders alleged that, in the May 2020 Transaction, Citibank and Revlon had improperly manipulated the voting provisions of the 2016 Loan Agreement to gain approval of an amendment that permitted Revlon to strip collateral backing the loans.
> ...
> In that heated context, it was reasonable for the Lenders to believe — and several did believe — that Revlon and Citibank, perhaps with the help of Perelman and MacAndrews & Forbes, had figured out a creative way to pay down either enough of the Lenders to prevent them from filing the UMB Bank lawsuit or the 2016 Term Loan altogether.
It's not really 'an exception'. The article most likely written by a non business person confuses a mistake (money sent to the wrong account) with money sent to the right account. The law almost certainly doesn't allow a wire transfer sent to be recovered for that reason and type of mistake. It does (by design) allow a transfer sent to a mistake (like a typo) to be recovered. This actually makes sense and here is why:
A wire transfer is payment for 'goods or services' let's say. Often that 'goods or services' is released (or relied upon) when money is received.
Wire transfers are by design 'final'. ACH is not. An ACH can be reverse (for a number of reasons).
If you could claw back wire transfers all sorts of things (that depend on them being final) would break down and you'd have all sorts of problems down the transaction line.
It's like giving someone money in a sense. You give someone money they give you something in return.
I'd assume that got included as an exception due to lobbying by lenders/creditors. :) If a hundred years ago or whatever, it might require some historical digging to ascertain the details.
If we're looking for rational reasons (and laws aren't always motivated by rational reasons), we could imagine that the creditor, assuming that it was a debt repayment, has already spent the money or whatever, it's not fair to make them give it back, they might not even have it anymore. They weren't just a random person with no reason to expect the wire transfer so should have looked into it more before just spending what wasn't their money -- they had all the reason in the world to assume it was their money, and go forward accordingly. And the money was owed to them after all, so they aren't exactly keeping what didn't belong to them, they just got what belonged to them back a bit early.
For similar reasons, items at Sherrif's auctions can't be returned to the original owner even if they win the original court case that led to the auction.
Sometimes a basic UI is the most efficient at some tasks, but one has to be trained to use it properly and processes have to be in place to prevent horrible issues. This is the problem here and this is where they failed.
If there was a screen that said "the transaction you have selected will result in a total of $900 million being sent to the following parties, broken down as follows: ...; Please confirm you wish to proceed" - then the outcome would have been very different.
That's very bad for your cash flow, and you lose 2 years worth of interest from that, but in the long run, citibank isn't $500M poorer, right?
I'm trying to understand what the real financial impact is. Interest rates aren't very high right now, so can maybe a few percent of the $500M per year?
Regarding the UI issue: Not only is it bad that the user interface is weird, but that approval seems to use the same bad UI as entering the data. The approval stage really needs a line like "this will result in a $ X being sent out on $Date to $Recipient".
Edit: The 'creditor' in this case is composed of 10 investment advisory firms, who, at one point, thought the interest payments were a good deal for them. But, rest assured that they are quite pleased to be made whole on their bad investment. Source: https://www.cnn.com/2021/02/16/business/citibank-revlon-laws...
Effectively, Citibank bought a 500m loan at par when its trading at 43c to the dollar. So Citi just gave the lenders a little over $250m and now is stuck with a non performing loan.
It's like playing poker and you decided to flip one of accidentally showed your hand. Sorry, but you already joined passing the risk game and shamefully faulted out on the low risk scenario due to negligence.
Okay, but Citibank wasn't the debtor here, they were simply the middleman. And:
"To believe that Citibank, one of the most sophisticated financial institutions in the world, had made a mistake... would have been borderline irrational"
Sure, if you hear hoofbeats, the likely guess is horses, not zebras. But if someone calls you up and says "Hey, I got some nice pics of zebras running by your house" then you know the probable guess was wrong, and should act accordingly.
Absolutely the mistake was Citibank's fault. Maybe you think that means, inherently, that they should lose the case. But if you look at the actual laws on the books, I really don't understand how the interpretation of the laws comes down against Citi here. Though a half $billion mistake on UI design might still be a very beneficial lesson for the entire UX design community to remember.
If the user and his manager was unsure, they should have tested it on a dev system or with a smaller amount. Blaming bad software is easy. But having worked with complex ERP systems for more than a decade, I can easily say tat most of these systems are designed keeping user feedback in mind. In fact a lot of modules that Oracle sells were systems that their users built as add-ons to Oracle and were finally embraced by Oracle.
Everybody blames bad ERP systems from Oracle (PeopleSoft, JD Edwards, Oracle EBS) and SAP. Yet noboody is building competing systems at a mass scale. Because they are complex and needs lots of integrations.
That is why, you see lots of small business ERP systems but very few complex full scale ERP systems -the kind Oracle dabbles in.
There's no need for that level of ambiguity.
You're dealing with large sums of money.
The parameters described in the video are superlatively ridiculous.
It's their fault.
FYI verticals of ERP are usually not that complex. And there are other reasons people don't compete, it's because of the inherent flexibility needed in these systems and their vast incumbency.
Now take that complexity that is in your imagination now and couple it with internal software. Think about the last megacorp you worked at and how awesome the internal tools are.
Now imagine writing the applications and processes that govern and that internal software. The internal end product doesn’t get the product attention it deserves, because well... it’s just internal and not seen by customers. The stuff you write to support that end product gets even less product attention. It’s an act of God to get a few more lines in on top of the millions of redundant lines already present. Now couple that with the inane process of financial management internal to the financial industry.
Shitty enough yet knowing the product management requirements to make this good user facing software? Try imagining then testing it with automation.
The complexities are vast enough that converging, in my area, to git for version control from various other tools was a multi year effort to avoid completely halting the business requirements.
Edit: regulation doesn’t help either. Very often not enough time and effort is spent translation legal requirements into usable UI, and you have be both a legal and software expert to understand what you’re doing. If you get it wrong, you may well have just signed away all your money. Case in point: power of attorney features, pretty much everywhere.
The need for transferring principal to your own “wash” account in order to make an interest payment to other parties seems unconventional.
It’s violating the problem domain. Similar to using special int values like -1 or -2 in an orderId DB field to indicate that order was cancelled or in progress instead of creating an explicit orderStatus field.
To do that they needed to make an interim interest payment to that one creditor, and mark the loan as paid off to that creditor; but the system wouldn't let them mark the loan as paid off without making payment of the principal in full, and it wouldn't let them pay creditors individually.
If they'd just been "repaying" the principal they'd have caught the issue when it said (paraphrasing) "Money actually leaving, are you sure [Y/N]", but they were expecting some money to go out as interim interest (they'd got the OK to pay the relatively small amount of interim interest to the other creditors).
If you are doing something really really specific against usual procedures no UI can save you...
And here I am, tearing out my hair, sleepless nights, wondering if using iodash instead of pure JS incurs in needless overhead for people I don't know from anywhere visiting my website.
(probably someone got a nice check out of it though)
https://www.oracle.com/industries/financial-services/banking...
> Ordinarily, paying back a loan early wouldn't be a big deal, since the parties could simply negotiate a new loan on similar terms. But in this case, some of the lenders were not on good terms with Revlon and Citibank.
Source: spent several years working in the loan and high yield space at a well-known fund.
https://docs.oracle.com/cd/E53393_01/homepage.htm
However, Citibank's real mistake was trying to use the software for something it probably was not really designed for. It seems they created a "hack" to make this type of interest-only and rollover payment possible so that they didn't have to bother trying to figure out the correct interest payments for the loan holders.
<< On Flexcube, the easiest (or perhaps only) way to execute the transaction was to enter it in the system as if paying off the loan in its entirety, but to direct the principal portion of the payment to a "wash account" (an internal Citibank account) to help ensure that money does not leave the bank. >>
I remember using Infosys's Finacle in 1998 (it was called Bancs2000 then). It had a TUI interface and was very snappy until they moved to a web based version and called it Finacle. We hated it because it couldn't keep up with muscle memory everyone had developed on the TUI. Flexcube came a bit later and started to gain momentum around 2005-2006.
PS: also wanted to add that most of the issues I've seen in these banking software are due to never-ending customizations demanded by the banks. The core products are usually well designed. There is basically an entire industry around core banking customizations and a lot of people working in that are basically old-school bankers who have migrated to technology (nothing wrong with that) - a good portion of them have excellent business knowledge but not much idea of UI/UX.
Key point 'wrong account' is not 'right account but for the wrong reason'.
The article most likely written by a non business person confuses a mistake (money sent to the wrong account) with money sent to the right account. The law almost certainly doesn't allow a wire transfer sent to be recovered for that reason and type of mistake. Importantly though it does (by design) allow a transfer sent to a mistake (like a typo) to be recovered. This actually makes sense and here is why:
A wire transfer is payment for 'goods or services' let's say. Often that 'goods or services' is released (or relied upon) when money is received. In the sense that it is not reversable under any and all circumstances. A wrong account is 'going to the wrong place'. The right account is the right place.
Wire transfers are by design 'final'. ACH is not. An ACH can be reversed (for a number of reasons).
If you could claw back wire transfers all sorts of things (that depend on them being final) would break down and you'd have many problems down the transaction line.
I'll take $100,000 for this consultancy recommendation, thanks Citibank. ;)
Edit: in case that was snark: ha, ha.
This paid off really well for me recently, where the `execute` stage turned out not to be fit for purpose, but the statement of intent was all still correct. The rewrite didn't have to touch the "gather" stage at all. Huge rewrite becomes naturally much more limited in scope. Just another tool in the modular-design toolbox: you create a strongly-typed API boundary down the middle of the program.
(hashtag defunctionalisation)
Even if you think you have an excellent, fool-proof UX, always make people confirm big things.
For complex actions, the UI should summarize the future result of the comment - not so little as to be useless (ex: "some of the money will go to an external account" = how much money? on which external account? only one? more?) and not much as to be a description of the underlying software process (as a debugging output would)
This requires both domain knowledge and software literacy, so it is hardly found, if ever.
This seems weird. There are all sorts of novel mistakes all the time, even by very competent groups. Even if it’s not a mistake, it would be a surprising action to take.
But most of all, it seems really weird to say it would be irrational to expect what happened would happen. Like people who profited off of 2008. Were they irrational or prescient? It’s impossible to tell a lot of the time, so “it would be irrational to be correct” seems like a very over strong statement.
I think the point is more that it’s entirely reasonable to assume that the receiver of the funds, in good faith, assumed that this wasn’t an error.
Now let's talk about Flexcube. Oh, it's an Oracle app! Guess who else is rich, has no interest in aesthetics, and loves lawyers. I'm seeing a pattern here. Design. Matters.
Tragic Design by Shariat and Saucier
https://www.amazon.com/Tragic-Design-Impact-Bad-Product/dp/1...
If you have an O'Reilly subscription, you can read it on their site.
There's more software out there like that than your Twitter UI for posting a message than you can imagine.
Raj probably still has a job working on non-Citibank accounts. I doubt Vincent Fratta is still employed by Citi. I guess this is fair? Raj made a mistake for one client where the client-- the experts-- signed off on it.
[1]: Outside analysis, sync up a video from an earlier flight with the failed flight, sync'd up to T-0 ignition. The successful flight the co-pilot Alsbury hit the button at T+13s, the fatal flight at T+9s. The fatal flight was the first test of a new engine, so there is some error in this calculation. Wikipedia claims it was 14 seconds too early, but I'm not sure how much I trust the source it cites.
[2]: The feathering device was a clever idea that the designer, Burt Rutan, had: if you fold the entire spacecraft in half while you are up in space then it will pretty much always be in a safe attitude for reentry and you don't need to have much maneuvering authority in space. But below Mach 1.4 there isn't enough aerodynamic pressure to keep the spacecraft from folding in half when you don't want it to (and then the spacecraft gets torn apart by all of the aerodynamic pressure that is there- not enough to keep it from folding in half, but too much to survive if it does fold in half). So they put in these big honking locks to prevent it from folding when you don't want it to. But now you have a new problem: if those locks prevent it from folding while you are up in space now you burn up in the atmosphere because you don't have enough control to keep the spacecraft oriented in a safe manner. So you have to undo the locks above mach 1.4 but before you have burned enough of your rocket fuel that you are committed to going into space: if you try and undo the locks and they don't go, you immediately stop the rocket engine and glide back down to a safe landing. So you have a very narrow window that the button has to be hit, and if you are out of that window you can either accidentally feather and die or fail to feather and die. At a certain point you just have to give up on your clever ideas and admit that they are not helping you.
I wonder if the CS education in countries that critical software often gets subcontracted to teaches about software disasters like this
They wanted accidental repayment of loans to be a one way street, and that’s exactly what they got.
But the law makes an exception when a debtor accidentally wires money to a creditor. In that case, if the creditor doesn't have prior knowledge the payment was a mistake, it's free to treat it as a repayment of the loan.
I wonder if folks here on HN agree with this law or not. It sounds like it could be construed as an unfair rule put in due to lobbying by lenders. Thoughts?
General case: I receive an unexpected wire transfer from someone I wouldn't expect to pay me. It would be unreasonable for me to expect that the money is fairly mine.
Exception: I loan out money to someone and ask them to pay me back no later than one year from now. Six months in I receive a wire transfer for the entire amount back. It's reasonable for me to expect that the money is mine and I'm free to spend it as I like. If now the debtor comes and asks for the money back because their wire transfer was a mistake, I may not even have the money anymore and would be put in a bad spot through no fault of my own.
Why would someone not want to refer to some true documented procedures while processing such large transactions ? Firstly, is there such a documentation or a procedure or a checklist in place ? Documentation and process is a key to every unique tool or solution.
That form looks like it's been around a loooooooong time.
I've always had a great experience with my onshore and offshore Indian colleagues, I have family of east Indian origin. But all of the offshore call centers and IT should be banned or hit hard with high penalties by the US government given the COVID pandemic.
UI/UX isn't a nice facade that you put on top of critical infrastructure.
It is critical infrastructure.
Really? People make mistakes. Institutions make mistakes.
But this is definitely not as bad as some of the other UI I've seen in SAP, Oracle, etc. It's certain that nobody who ever uses this UI actually approved this UI. Even if you do use it, hate it, you have no way of asking for a change.
Shameless plug, I run an open source project to build internal and enterprise apps. We've built it so you can set up warnings and confirmations to prevent such errors. Our pitch: Use Appsmith and save at least $500M https://github.com/appsmithorg/appsmith
Kudos on your project but if you want (need) to compare it against others, do it against their more recent offerings
[0] https://www.bloomberg.com/opinion/articles/2021-02-17/citi-c...
So, given the time value of money this cost them closer to 2%/yr of that balance?
I thought I've had bad mornings..
I expect to receive a Jakob Nielsen newsletter, soon, discussing this.
> A creditor of another or one having a lien on another’s property who has received from a third person any benefit in discharge of the debt or lien, is under no duty to make restitution therefor, although the discharge was given by mistake of the transferor as to his interests or duties, if the transferee made no misrepresentation and did not have notice of the transferor’s mistake. RESTATEMENT (FIRST) OF RESTITUTION § 14(1) (Am. Law Inst. 1937).
(Note: The ALI Restatements are not law per se. This section, however, was explicitly adopted by the New York Court of Appeals in a prior case. Here, the federal court applies this law because it is the relevant law of New York.)
[0] https://www.courtlistener.com/recap/gov.uscourts.nysd.542310... at p. 36.
I will chip in my 2 cents from my experience on both sides of user interfaces:
In parts of user interface (UI) design, there has long been a principle that to make good use of the UI the user should have accumulated experience with the UI where they ran essentially experiments to discover how the UI and associated system worked.
So, with this principle, the CITI people just needed more experience with experiments, at ~$900 million per experiment!
So, right, the principle is flawed and for some applications expensive/dangerous.
While this principle of users getting experience from experiments has worked for the UIs of a range of applications, to be careful a principle should be that a user should be able to use an application as intended the first time and with no experiments.
Case 1. Last week I went to the Web site of my bank and used its UI to transfer some money from one account to another. The experience was Excedrin headache #394,325,757,110: I entered the data, and nothing happened.
So, I had to start running experiments. I hit Enter and left/right single/double clicked on everything in the window, and nothing happened. It appeared I was seeing all of the window horizontally, so I checked vertically, and to do that I looked for a vertical scroll bars. There were none. So, I converted the application to full screen and still saw no vertical scroll bars or way to make the money transfer happen. So, I did some more study and finally discovered that the window was so tall that the bottom of the screen was hidden by my tilted keyboard, and the part I could not see had the HTML push button for approving the transfer.
So, the UI designers just assumed, insisted, never told anyone, that, naturally, of course, all the users will be using their Web site with the windows expanded to full screen. And for some reason, whether their window is full screen or not, the UI designers don't like vertical scroll bars. The screen for the transfer had only a few lines of text and didn't need so much vertical screen space, but the designers seem to like using as much screen area as they can.
Okay, I learned how to use their UI. Still not so good: (a) The bank keeps changing their UI, and in this case made it worse. So, with that bank I will have to go through such mud wrestling nonsense several times a year. (b) To me, the original HTML controls were nicely designed, including the scroll bars, and one result was that nearly all the many millions of Web pages worked somewhat the same. Then somehow many UI designers wanted their screens to work in some unique way until they changed to another unique way a few months later. The power of JavaScript made this problem much worse.
Case 2. Also last week, in a weak moment, I decided to get a user id and password (PW) at one of the social media Web sites. They stated some rules for passwords; I followed those and typed in a password in a file where I keep such things; copied that PW to the system clipboard, pasted it into their HTML single line text box for passwords, and nothing happened. I hit Enter, clicked around, etc. and nothing happened. I pasted the password in again, reloaded the page, closed the browser and tried again, etc. and nothing happened -- no messages, nothing. I still don't know what is wrong except it isn't me.
As I've mentioned at Hacker News before, for my startup I have 100,000 lines of typing of software for a Web site ready to go live. In that code I used eight design principles in UI: (i) No icons. Instead all the links are words in the English language that clearly describe the function of the link. For icons, I usually am not sure what they mean, can't look them up in a dictionary, and can't pronounce them, spell them, or type them -- IMHO, bummer. (ii) There are no acronyms. None. (iii) The only controls used are standard HTML. I wrote no JavaScript at all although Microsoft's ASP.NET wrote a little for me; apparently it has to do with cursor positioning but is optional. (iv) Each page (screen) has a link "Help" to explain the screen in detail. (v) Each screen has both vertical and horizontal scroll bars. (vi) The screens are designed for a window 700 pixels wide and are still usable in a screen 300 pixels wide. (vii) All the fonts are large and have high contrast. (viii) All HTML control bounding boxes are bold and black with high contrast. IMHO (i) - (viii) help UI design.
Revlon who is in terminal phase and who screwed up its creditors.
Money-lenders.
This is like a Roman-Empire time gladiator combat of criminals who were sentenced to death.
So an interface like this only controls the money on Citi's end. Once the wire transfer occurs, there wouldn't be any way for this software to undo that transaction.
You could create a psuedo-undo in this software tool, which is how Gmail creates an "undo send" feature. Like a wire-transfer, once you send an email, there is no way to undo it. The email is sent to the recipients servers, there is no way to reverse that. Gmail creates a Psuedo-undo which means that they basically wait after you click "send" and they don't send the email right away. They wait 30 seconds or so before actually sending the email. So if you click "undo" during that artificial waiting period, then it simply cancels the send that hasn't occured yet. It feels like "undo" to the sender, but in reality an artificial waiting period was created, which allows you time to cancel it before sending. Not a proper "undo", but it acts similarly. But it is worth noting that once that artificial waiting period is up and the email is actually sent, then there is no undo anymore.
In the case of this story, you could potentially create a psuedo-undo. The software could create an artificial waiting period before initiating the wire transfer, which would allow time to undo. But the problem is that no one would have noticed it until the wire transfer was completed anyway. Someone noticed that $900M left the account when they thought money was staying in the bank. Only then did they realize that the mistake was made. Three people signed off on this transaction before it was sent and all three thought it was correct. So a psuedo-undo wouldn't have helped in this case.
They send back money before they had to
some returned it back but 500M didn't came back
that's not a 500M mistake at all.
stop support that click-bait nonsense
I was moaning when i had to use SAP for a little while