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...
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.
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 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.