I'd dare say that if a financial institution ever had a situation where an attacker could see any part of their database, they'd have far bigger problems to deal with.

Ahahahahaha! Yeah, right.

I can't speak for most financial systems (I only am familiar with one, but it's a big one), but I know plain text passwords happen. Lets call the system IET.

IET doesn't encrypt the passwords used for internet banking. To obscure the passwords, they're stored in the DB using EBCDIC. No joke.

Sure, in theory, encryption of data at rest doesn't matter if the system is secure; however, with a security posture like this, the data is bound to leak.

In this case, I found out about the unencrypted passwords because they were in the files going to the "print & statement" vendor: there is a default letter in the system that says "Hey your password changed to foo99!". Despite suppressing this letter, the data was still transmitted to the vendor: it is simply ignored.

There are ways around legacy systems not storing certain characters to database field sizes that range from running delegate password serves to hashing passwords into something that an be stored on the legacy system. The one thing this thread does get at is the money involved. To Amex the costs and risks of their "weak" password requirements don't outweigh those of implementing a more secure password system.