Hacker News Reader

Comment by wcoenen | Hacker News Reader

Missing context in the blog post: in the original court document, the bank mentions that it is already upgrading to a new system that doesn't have this issue. It just isn't done yet. So the bank isn't really refusing to fix this. They are just saying they can't fix it right now.

Also, the idea in the blog post that everybody can simply choose not to use EBCDIC, is a bit naive. For example, the Visa protocol for payment messages contains message fields encoded in EBCDIC. This is a specification implemented by thousands of Visa member banks and various types of intermediaries. You can't "just change" anything in a spec like that without a massive amount of planning and pain.

View on HN

The document states that the modifications to the system should have been made in 2020, but in 2021 they still couldn't spell the names of all their customers right, and the bank refused to provide a concrete timeline for the fix. The project that was supposed to fix their naming problem ended up being too complicated to implement and they stuck with their old systems.

International VISA transfers weren't the problem here. Bank statements and online environments carried the wrong name, and those had to be corrected. No sensible court would make a bank disconnect its payment systems because the receiving end uses a shitty system, but when it comes to communication between the bank and its customer, there is no such constraint.

Furthermore, EBDIC had already been extended to support the problematic characters long before the lawsuit took place. "Yes but EBDIC database" wasn't a good excuse because EBDIC itself could handle this specific edge case just fine.

By the time an investigation was done, the bank had made advancements and the name of the original plaintiff was representable, so they didn't receive a fine on that count (though they ended up receiving an impartiality related fine for their privacy officer) according to https://ellentimmer.com/2022/01/12/banken-7/

> You can't "just change" anything in a spec like that without a massive amount of planning and pain

planning such as GDPR being ratified a decade ago and effective since 2018?

EBCDIC is older than the GDPR by 60 years.

Give the plaintiff his/her money back and close all his/her accounts.

EBCDIC was obsolete in the 90s, and people in Europe have had names that EBCDIC couldn't spell since at least then (technically true! :D).

The issue is that whatever bottom of the barrel priced contractor they used gave them a "cheaper" new system in 1995 that was already obsolete. Now given the era, they could have made the choice to use wide chars instead and it would have been a reasonable choice (wrong in the long term, but still reasonable - unicode was only a few years old at the time), and wchars are easily (ymmv) extendable to utf-16 without having to re-encode everything which is the problem they have with EBCDIC.

I just saw the nightmare fuel from u/em-bee (https://news.ycombinator.com/item?id=38013102) and I guess that would also be an option :D

Surely they could think of a way to encode Unicode in EBCDIC.

https://en.wikipedia.org/wiki/UTF-EBCDIC

Reply on news.ycombinator.com