I've worked with Citi as a partner, as a client and as a service provider in various other banks and fintech companies, and I'm so not surprised. In fact none of my colleagues are.

The problem is Citi itself. It's always an absurd amount of indian subcontractors who aren't paid to care but just to look good on a cost cutting plan (so they do their job), a disorganized / panicked organization who seem to never know what's happening when and follow mega-processes rather than solve problems.

My bank has those, but we can take shortcut if we must - not Citi, can make you wait 2 months for a csv file via sftp, and then pretend to be ready when you finally discover it's a frigging indian contractor writing the csv rather than an automated process... we were like "guys seriously why are you even lying about it" when it all came crashing down with crazy errors never seen in the UAT. Turns out the automation guys were late and they made an effing human do the prod version meanwhile ...

In another company, working with Citi on a completely different sector/group/vertical, I spent nights with their tech guys in India figuring out their own system and why they couldn't work... and they had less clue than me, it's absurd.

They seem to work in very split team where americans will do the high level design and then outsource to dev + support + deployment teams, ofc isolated from each other, in India. So nobody US cares about any actual implementation detail of anything, the 3 indian teams don't know each other, and nobody feels responsible of anything. It's absurd I've had multiple separate experience of the same thing, with me and my colleagues doing the connection layer between various Citi stakeholder who had no idea about each other.

There was even a time where a Citi country team in Hong Kong begged us to introduce them to the Citi country team in Singapore, and show them their product and processes...

Your experience with Citi is very similar to mine. It is funny that as an organization Citi seems to believe that its technology is brilliant and that any software that it uses must be built by Citi. Tremendous hubris combined with total incompetence. Not a winning combination.

Well I ll be honest we all do. My own bank, another giga multinational, also has this hubris, fine. But at Citi they went so far in the outsourcing nobody knows anything anymore. The people you talk to to organize stuff are timezones away from the guys doing stuff. And me I m close to the Indian time in HK, work with our own outsourcing in India who are fine for what they re here for etc and we have pains. But never to the extent of Citi where there s like internal conflict or total lack of communication that makes the contractors lie more than usual to the managers... I dont know I dont get why each time we have to deal with Citi it's the same story. It s organisational though, not tech (their tech I ve dealt with is okay)

At work we have several modules which each have their "output control". When the user hits "submit", we run several checks and outputs a list of potential issues.

We've got four levels: info, warning, severe warning and error. Warnings are highlighted, severe warnings must be explicitly accepted (and we log this) and errors prevent submission.

When clicking on an item in the list, the cursor moves to the relevant control, so they don't have to hunt around.

We add the checks we can think of, and keep on adding checks based on user mistakes and feedback.

I'm not familiar with the financial world, so I don't know how common it would be to do what they wanted to do, but at the very least it sounds like the principal account number being filled out but not the two others is something we'd made an info item from, to highlight what would happen. If what they ended up doing is unusual, it would be a warning and likely severe warning due to the amount.

That would, by itself, make the UI less shitty. Also, if you're the sort of person who thinks in those terms, you're also likely the sort of person who'd have come up with a better design overall anyway.

This sounds like one of those situations where devs tasked with programming something that they have little to no understanding of what they are programming does. Yes, the dev programmed button A to perform action B, but doesn't truly understand how/why/what/when/where action B. It's just a check box of the requirements that has now been completed.

However, a dev that does understand action B would be able to anticipate various forms of input from button A and how that could cause undesired results from action B.

This isn't a knock on the dev that is less knowledgable about the full thing. It is a knock on the people upstream that should be more aware of issues. Also, the people most knowledgeable about action B tend to have little to no understanding of programming. While they might understand that providing bogus data to action B can have bad results, they are not aware enough to tell the devs that sometimes valid looking data is just not sane.

I wouldn’t even assume lack of understanding as much as being locked into a work-to-order situation where they’re not rewarded, possibly punished, for doing anything which isn’t on the assignment. This is super common in outsourced hellscapes where the MBAs like to LARP as architects and UI designers and there’s no effective feedback loop from the actual users.

In this case, yes, in general I doubt it.

I assume this system is designed to handle manually adjusted payments for syndicated lending. So you've got one borrower with potentially multiple credit facilities, with each credit facility will be funded by multiple lenders, each with potentially multiple accounts. The events you are dealing with are fees, underpayment/overpayment of interest or principal, late or early payments of principal, transfers of balances from one lender to another, funding transactions and plenty I haven't thought of or considered but are represented by check boxes on that UI.

It's complicated. The reason the system exists is because it's complicated, and prone to human error, and the before and after might generate dozens of events in dozens of accounts.

What seems weird is that accounting software typically adds these transactions immediately with a future date, so in this case whenever the batch was executed. You don't need to wait to see the impact, just for it to take effect. This UI has to work extra hard to obscure this visibility.

I don't know how it's in this particular system, but I have also seen banking core software which would add these transactions during end of day batch procesing, by which time the original operators wouldn't be looking at them anymore, and anything that should be settled 'today' would also get executed during that batch process.

Right. I think this situation needs a "Dry Run" button.

I had exactly the same thought. Whenever I write a tool that manages a complex process, I try to add a dry run mode, and more often than not, I use it.