Data Domains & Security

After working with data day-in and day-out for a while, it doesn't seem unreasonable that thinking about the domain and appropriate datatype for storing a set of data would become second-nature. I know it's that way for me. Sadly, I can't say the same for one of the banks I do business with, which shall remain nameless.

I have accounts at several banks, only one of which is brick-and-mortar in my neighborhood. The rest are either online only, or have a physical presence somewhere far far away from me. The bank in question has an online banking system that's rather primitive compared to others, though it works perfectly well. The complexity of their interface was less important to me than the interest rate they paid about 5 years ago when I was shopping for another online bank.

The task I was trying to accomplish at said bank was to close one of the accounts I had there, as it had been unused and sitting empty for some time. After looking through their online help, I found that I had to "email" their customer service team to close out an account. I put "email" in quotes because I highly doubt this had anything to do with email – more like a secure messaging system that was probably utilizing a database and comparable (from an end-user standpoint) to Facebook messages.

So I typed out my "email" to customer service as follows:

Can you please close account #[Bacon] as I no longer need it and it has a $0 balance? Thank you!

I clicked "send" and was greeted by red text telling me my message contained invalid characters. My first thought was that the pound sign was the culprit, so I removed it and tried again to no avail. The question mark? Same thing. In the end, the character that (literally) broke the bank was the dollar sign. The absurdity of this still amuses me days later, as this is a bank that's based in the U.S. and one would think that dollar signs would occur frequently in conversations with customers. Apparently whoever designed this system wasn't banking on that.

This got me thinking as to why a bank wouldn't allow a dollar sign in its recommended method of communications. I highly doubt the limitation is present in the database that's storing the messages, it's more than likely occurring in the application layer. My best guess is that this is for reasons of security, as many languages use dollar signs to denote variables including PHP and Powershell. Security is obviously important, especially in banking, but there has to be better ways to achieve the desired level of security other than disallowing dollar signs and presumably other characters as well.

The fact that U-Turns are prohibited on some roads in the U.S. doesn't mean that all vehicles should be built without the ability to make a left turn. This would surely prevent U-Turns from occurring, but would also hamper the essential driving behavior of turning left. Similarly in a database environment if a user is not allowed to delete rows from a table, this does not mean that they should also be prohibited from deleting rows from other tables. Fortunately SQL Server permissions are very granular and can be granted/denied on a per-table basis. While security should always be a primary concern, effort should be made to ensure that acceptable behaviors are interfered with as little as possible.