Bank $Security
Banks. They take your money and lend it to others. They lend money deposited by other people to you, either as a car loan, mortgage, or for credit card purchases. For this privilege, you give them all of your personal information, including your social security number. Implicit in that exchange is the fact that the bank should keep your personal information confidential. Security is important. One might think that such a concept would be important to banks. One would be wrong.
To be fair, the high ranking people at the banks probably believe that all of their customer information should be - and is - secure and protected. Unfortunately, there are multiple layers of middle and lower management (that we all know all too well) that might not comprehend that point.
The other thing that banks do is nightly batch processing to keep assorted records updated, generate TPS reports, issue bills, update financial inventory, credit usage and so forth. Since customers tend to hit ATMs at all hours of the day and night, you want your systems-update processing to be able to occur while the system is live. To that end, date and timestamp ranges of transactions to be processed for a given business period usually come into play in some form. The point is that you shield your ongoing transactions from reconciliation activity by excluding it from the reconciliations. The beat business goes on.
Randy worked at a major bank in the Pittsburgh, PA area. Considering that it's a major bank, it seemed odd that their customer facing website was often down for more than an hour at a time during business hours. When he started in 2016, it took about a month to get permissions to get the development tools he needed installed. Hmmm, perhaps they are vigilant about controlling access to their environments, even development; possibly a good, if bureaucratic sign. Once set up, he was assigned to work on their Web Banking app which was written not in MVC but in ASP.NET WebForms. OK, maybe they're slow to adopt newer technologies because they want someone else to beta test them. Caution can be a good sign.
As part of doing his work, Randy sent SOAP messages to the mainframe to retrieve test data for developmental testing. One day, he deduced that the test social security number was that of his boss. He verified this by asking his boss what he had for lunch that day. Sure enough, there were debit card charges for it in the test environment. Uh oh.
That's right; live data in the test environment. Anyone with even novice skills could have gotten social security, routing and account numbers for every customer of the bank! Rather than fight with the, ahem, highly knowledgeable individuals that thought that this was a good setup - and potentially be blamed for any breaches, Randy chose to jump ship and head for saner pastures.
Interestingly, I went to their website, which states that their business hours are M-F 8AM-8PM and Sat 9AM-3PM. At 1:15 on a clear, dry Saturday when the bank should have been open for business, I called the bank posing as a potential customer to ask why their website is often down for more than an hour at a time almost every single night. The auto attendant said to try back during business hours.
Hmmm...
[Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!