Then someone sued and they thought they'd still win this "frivolous litigation" that is "due to a technical limitation that is out of our reach."
Also convert input from UTF8 to EBCDIC at every point a user or employee can type into a modern keyboard/OS. Eg searching customers by name.
Teach employees on inputting characters. Are we going to allow all unicode characters? Will they be able to find records if the customer doesn't give the diacritics in one context such as phone?
Also some routine tasks will be done using a mainframe terminal which doesn't support displaying these characters. More training there as they will just display the UTF-EBCDIC version of the field.
Are there connections like tax agencies, credit reporting agencies, other banks, Visa/Mastercard, and what character sets do they support? We always sent them ASCII CSVs via FTP and everybody who understands it no longer works here.
This wasn't accepted as a defence with "it's 2018 and you're still using a system from 1995 wtf?!" so they still had to pay a (small) fine.
If it happened her, in the US, fixing the issue would be a very expensive process, probably requiring replacement of the entire system and triggering tons of audits, etc.
very trustworthy
there is also the issue that I would be surprised if that system _didn't_ had tons of security vulnerabilities (which just weren't found because of it's obscurity). Heck, I have heard of enough cases where old banking systems had ton's of well known security issues in their interface they just "defined away" by means like "oh you need to be a bank employee to abuse them so they are not an issue" or "pst, don't speak about it we (supposedly) can't afford an update and they would fire people if they need to do an update".
"We're going to replace this anyway" is a pretty bad excuse for a fix that should've been completed ten years ago, and with the replacement clearly not coming any time soon, especially when the you're legally obligated to provide the fix.