Shortcomings of SFCU Online Banking

Like most people at Stanford, I bank with Stanford Federal Credit Union (SFCU).

Their lacklustre online banking system is fine for rudimentary day-to-day stuff, but it has a few dusty corners with some, frankly, ludicrous omissions and worryingly amateurish “features”.

Let's stick with tradition and talk about “Alice and Bob”, who are both SFCU customers.

I can think of three things off the top of my head...

Shortcoming #1

Suppose Alice and Bob have some shared monthly expense that happens to be paid out of Alice's checking account. Bob wants to set up a scheduled transfer of, say, $100 to Alice's checking account on the 1st of every month. It was easy for Bob to do one-time transfers to Alice, and it was easy for Bob to set up scheduled transfers between his own savings and checking accounts, so putting the two together is doable, right?

Wrong.

Ironically, Bob can set up scheduled transfers to any account at any other bank using the ABA routing code and account number, but the external application/service SFCU use rejects SFCU's own ABA routing number. After some back-and-forth with SFCU customer service, their solution — to Bob wanting to set up a scheduled monthly transfer to Alice's account at the same branch of the same bank — was to mail Alice a monthly check.

Just thinking about it makes me smile. Was I wrong when I said “ludicrous”? Maybe I should've said “hilarious”.

Shortcoming #2

Suppose Alice and Bob have a shared checking account. They want to open a second one. Bob clicks through to the screen for opening a new account, and there — much to his surprise and satisfaction — is a check-box that says “Share this account with Alice”. Strangely, Alice doesn't see this check-box when she tries, but Bob ticks the box and moves on.

Easy-peasy, right?

Wrong.

The “feature” simply doesn't work. After some back-and-forth with customer support, they tell Alice that she and Bob will just have to come in and fill out a paper form.

Here's how it should work:

• The New Account page has a shared account option (via a tab, separate page, or whatever, the HCI/UI/UX details are unimportant to the current argument) with, inter alia, a text-box to enter the other customer's customer number
• Alice fills in Bob's customer number and clicks OK.
• Bob gets an email, clicks on a link, logs in, and it takes him to a page that says “Alice wants to open a shared checking account with you.”; it has 2 buttons “Accept” and “Decline”.
• If Bob accepts, the account is opened.
• If Bob declines, it isn't and Alice gets a message to that effect

They clearly thought of giving customers the ability to open joint accounts via the online banking system, otherwise the check-box wouldn't exist, so why didn't they actually implement it? And if they subsequently decided that they weren't going to implement it, why is the check-box still there?

Either support the feature or don't. It's not hard.

Shortcoming #3

The final shortcoming is simultaneously the most trivial and the most concerning. The previous two are oversights. Irritating, perhaps, but really just oversights or missing features.

The online banking system has an integrated messaging system for customer support. It also has a timer that logs you out automatically after a period of time. I'm sure you can guess… Yes, it can try to log you out while you're typing. Apparently resetting the JavaScript timer that's already there on every keystroke was too much.

But that doesn't really concern me. Again, it's just an oversight, and because you are prompted before being automatically logged out, it's not a critical issue.

What gives me cause for concern is that the messaging system only allows alphanumeric characters plus a list of “allowed special characters”.

What this suggests is that the developers, quite rightly, feared:

• a SQL injection attack; and/or
• HTML special characters — like “<”, “>”, and “&” — being entered by the client, and later interpreted by the customer service agent's browser, such that the message entered by the client was not faithfully presented to the customer service agent.

These are legitimate fears and it is right that the developers should take measures to defend against them. What's worrying is that the only way they could see of defending against them was to have an allowed list of characters, which suggests that the developers were either lazy and sloppy or just plain incompetent, and nobody at SFCU knew enough to reject this amateurish hack.

If there's one thing I don't want to suspect was developed by dilettantes and acceptance tested by ignoramuses, it's the online banking system I use.