Finovate Blog

I get that multi-channel messaging is a mess. I understand that new regulation is creating huge backlogs in project queues. But 17 years into the Web-banking era, I should be able to service my bank account entirely online, if that is my choice. And more importantly, if I’ve signed on for alert services, there shouldn’t be any surprises when I go to log in to my account. 

Yesterday, <largebank> failed me on both accounts (see note 1).

With Finovate Europe less than two weeks away, we are wiring large sums to London to pay for it. My bank got a bit concerned about all this outbound activity, which is good. I’m glad they are paying attention.

But how they went about notifying me about their concerns was simply outdated. Here’s how it went down:

1. The bank called me from a toll-free number and left a voicemail asking me to call them back. Despite the fact that I get every alert under the sun, the bank did not send an email or text message. I don’t know about you, but listening to voice messages from random 800 numbers is very low on my priority list. By mistake I did happen to hear it a couple hours after the fact. 
2. As soon as I listened to the message, I first went to my email to see if I’d also received a message from the bank to verify the authenticity of the phone call. Seeing nothing there, I attempted to log in to online banking to verify the call and assure myself that my account had not been drained. But guess what? The bank had disabled my account access and gave me a vague error message with instructions to call a toll-free number. The number matched the one on the voice mail so at least I could confirm it wasn’t a vishing attack. There had been no mention in the voice mail of my account access being disabled.

Now, when you are 11 days out from an event and the cash in the bank is needed to pay for it, it’s beyond disconcerting to be locked out of your account for no known reason.

Luckily, we were able to quickly assure the bank that yes, we really did need to wire that much money. So we are back up and running and our patient vendor simply had to wait one more day. (Update: I wrote this post yesterday. Today, the same thing happened again with another wire. While it wasn’t a surprise this time, it’s annoying.)

________________________________________________________________________________

A Better Process
________________________________________________________________________________

Let’s repeat this scenario using an approach that preserves your customer’s sanity while making it more convenient for those that favor digital channels:

1. Bank sees something odd so it freezes outgoing wire-transfer capability and sends me a text message, an email message, and also leaves a voice mail.
2. Instead of shutting down my account access, they let me into my account so I can verify that the balances are still there. And for extra credit, the suspicious activity is highlighted.
3. After confirming the transaction through an extra authentication step, the bank re-opens my outgoing wire capability.
4. For extra credit, let me simply authenticate the suspicious items by replying back to the messages (at least on smaller dollar items).

Now that I can breathe again, I can lay out three rules to guide your “suspicious activity” messaging:

1. Contact the customer via the channel of their choice (but also use others for backup in urgent situations).
2. Allow the customer to authenticate transactions without moving out of that channel.
3. Never completely disable online access (unless absolutely necessary). Yes, shut off transfer-out functions, but continue to allow “read only access.” And post a red warning graphic within the account to draw attention to the suspicious activity. 

————————–

Notes:
1. I’m not identifying the bank because my “data point of one” may not be indicative of what other customers experience. But I will disclose the name “off the record” if you email me [email protected].
2. For more on messaging, small business, security and much more, see our Online Banking Report (subscription required).