The fact that a personal name is stored in EBCDIC is missing the point. the mainframe has supported unicode for 20 years. The bank account holders name is stored in a character column in a database. Every character column can be defined with a different codepage, so it is possible to define the name column as stored in UTF-8, EBCDIC or any of a number of other codepages.
For the bank to claim that the reason that they can store names containing diacritics because the name is coded in EBCDIC is nonsense. The bank just needs to change the database column definition to UTF-8.
You were making a really solid-sounding technical argument, but then you used the phrase "just needs to", which, for me, triggers a tendency to discard whatever the person is telling me.
It might not be as easy as you think if the system has somehow survived without an upgrade for decades. Who knows, maybe it's that ancient?
Back in the day I worked on CODASYL style databases (IDMS) that was EBCDIC. This is before relational databases were a thing. We had no PCs: all of the companies’ data was is in the Mainframe in EBCDIC. No ASCII anywhere, let alone UTF-8.
That’s assuming they didn’t develop the database in-house. If they concocted their own system, it very well could be that this data is in fixed-length records without much room for a quick fix.
For the bank to claim that the reason that they can store names containing diacritics because the name is coded in EBCDIC is nonsense. The bank just needs to change the database column definition to UTF-8.