In yet another case of features of convenience creating spin-off consequences, we now have money e-transfer "auto deposits" in question. Instead of enhanced security for customers, this actually opens up vulnerabilities that aren't very hard to spot whether your intentions are good or bad.
At the heart of the e-transfer system's new flaw is -- surprise -- a complete lack of authentication. Previously there was one simple, but workable level of authentication; but the recently added auto-deposit feature removes even that. What?! How did this get approved and why?
Simple: convenience.
To be fair ("to be faaiiiiir", for you Letterkenny fans) convenience is a powerful lure, I'll grant you that. But I am genuinely baffled how this idea made it through assessment and approval.
First, what is e-transfer auto deposit? For those that aren't familiar, Interac is a debit network layer that sits on top of the entire Canadian bank system allowing for simple fund transfers using email notifications (funds are not actually transferred within email messages) with secured links as well as facilitating debit at point of sale terminals as well as a lesser used ecommerce payment gateway. It is run by a consortium of major financial players in the industry. Its closest equivalent in America, for example, is the VISA Debit network though with significant differences it's the same idea.
For the most part the Interac platform, being one of the early financial new innovations decades back has run mostly incident free - the e-transfer service being introduced later, as online technology came of age.
The original Interac e-transfer model included a de facto validation process of a security question for the recipient to answer in order to receive the funds being transferred. That security question would be passed along separately between payor and payee and can be re-used or not, their choice. The key point here, is *validation*. The simplest of techniques that provides David and Monica (our heroes) to easily say "I'll email you the $100 bucks"; security word is "gandalfthewhite". In moments, Monica has submitted payment and Dave simply clicks to receive and validate that he actually is Dave by entering "gandalfthewhite" as security answer and they're done. Dave's got $100 and Monica is secure in knowing that only the bearer of the secret phrase could receive the funds. All instantly transferred.
No security phrase validation at the recipient's account? No problem, we'll give your money to whomever happens to own this incorrect email account. Your money is now missing? Tough luck, you shouldn't have tried it in the first place then.
Then auto-deposit shows up. Dave can now set his account to no longer require security phrases and simply pass-through Monica's funds into his account. It's certainly convenient: Dave no longer has to give a thought to these deposits -- that $100 just shows up. He's saved himself the <sarcasm>arduous task</sarcasm> of entering a security phrase.
UPDATE Jun 21, 2021: Ontario man says he's out $3,000 after making simple e-Transfer mistake
Let's break down why auto-deposit convenience is more jeopardy than convenience and the risks this poses to both Dave and Monica.
- email security: we'll start with an easy one. Email is already the subject of attacks and takeover as well as man in the middle style interceptions. Simply put, email as a technology should be left out as the single guardian of important things (like money) as possible. While there are simple sender->receiver auto-deposit bank capabilities that do need to pre-exist for both parties at the end of the day if someone can get at that transfer message, and there is no security question (because it's now auto-deposit), they stand a good chance at siphoning off this to their own account.
- email fraud: similar to email security. There have been numerous reported incidents of users being duped into sending e-transfers to an incorrect address; to someone they think they know, but in actuality are not the person they're truly sending to.
- address errors: humans do make mistakes -- this is an easy one. If you accidentally send your deposit to the wrong email address; even just one character off, that deposit could very well go into the wrong person's auto-deposit account. No security phrase validation? No problem, we'll give your money to whomever happens to own this incorrect email account. Tough beans if you need to fix this and get your money back.
- senders don't get to make their own decision: in setting up your e-transfer payment, you don't have a say in whether your payee has standard security phrase set up or auto-deposit. If you're concerned that your money may go astray for any reason, the possibility of auto-deposit allowing your money to go to the wrong person means that you only have two choices: be comfortable with the risk that the recipient and their provided email address are accurate; or don't send it at all.
Interac E-transfer sorely needs a confidence play. Users should have a simple, but complete sense of the security behind their payments and banking security. In one fell swoop Interac has removed an important point of that confidence, in doing so has added four serious reasons to pause that now underpins every e-transfer transaction.
Is Interac e-transfer broken? No, this is still a good platform and provides good service. Is your money in serious jeopardy? Again, no, for the most part your transactions are going to be fine. Have the odds of running into trouble increased notably? Yes, they have, and users now need to exercise extra caution when e-transferring funds, especially to a new payee.
So what's to be done about this? If we put our roadmap future wizard hat on Interac needs to be looking at how to restore confidence to funds transfer processes.
There could be a pre-auto-deposit transaction validation process which requires the payee to first authenticate against the user's intended deposit before authorizing an auto-deposit. With pre-validation the payor now has formal acknowledgement of her intended payee.
Payors could have the choice whether they want to take the risk of sending to an auto-deposit payee. Perhaps the amount being sent is fairly large and the risk too large. Maybe you don't care about risking $15, but you do care about $647. It's your money, it should be your managed risk to control. This financial limit strategy already exists for the NFR tap-to-pay functionality, why not here? You could force any transaction over a certain amount to be security phrase validated no exceptions.
Moving forward there are a host of closed-loop validation technologies already out there from QR code scanning to OAUTH and related 2FA codes. Not all of these will be approachable for the broader public, but the techniques can be applied all the same with the right user experience potentially involving a bank account holder's app as well.
If Interac wants e-transfers to be taken seriously for a wide range of fund transfers they need to understand the risk-mitigation mindset users are taking on when they deal with different players in their lives. They can get this right, but they need to embrace user risk-mitigation and how proper validation strategy can play a significant role in e-transfer's next step evolution.
What can you do about this? You can refuse to use the service, this is an obvious one (and is one that iTristan Group is seriously considering). But you don't have to throw it all away, at a B2C level, e-transfers do offer a lot of convenience. Some e-transfer interfaces sort of allow you "see" if your intended recipient is or is not using auto-deposit by requesting security phrases (auto-deposit not active) as part of the transaction set up, or not requesting security phrases (auto-deposit is active). The only way to know is to try it out with known accounts for both scenarios to see if this works for your bank - YMMV.