Not a 'good idea', but it's partly because the same password is used for telephone banking. And people seem to have trouble with typing long passwords on numerical keypads.

legacy systems

I understand that, but I'm looking for something more specific... Hashes aren't length-limited by design; I suppose storage size or database limitations could be an issue, but a 6-character password in ASCII with 1 million users is 6 megabytes.

Hashes aren't limited, but the os might be limited in its implementation.

ref: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...

And I quote:

If you are RACF-defined, you must enter the password defined in the RACF® data set as the value for password. The new password specifies the password that is to replace the current password. new_password must be separated from password by a slash(/) and, optionally, one or more standard delimiters (tab, blank, or comma). new_password is 1 to 8 alphanumeric characters long. This operand is ignored for non-RACF defined users. (Printing is suppressed for some types of terminals when you respond to a prompt for a password.) With z/OS® V1R7 or later, the password and new_password can be in mixed case, if your installation has enabled RACF mixed case password support.

Some of these systems originate from the era when a 5mb hard drive was an incredible amount of space, even at enterprise level. They pre-date personal computing.

Do the other banks still have the same limitations at their root, but just take a numeric hash of whatever you enter, compare against a 6 digit integer and pray you don't find a collision?