Two factor authentication with card not present transactions

(neil_cm17) #1

It looks like the vast majority of fraud now is committed online during card not present transactions when the card details including the CVV number are used fraudulently. Wouldn’t it be possible for Monzo to send a request to the users phone if the card was used online and then ask them to authenticate themselves using Touch ID and if they failed to do this within a certain time period the transaction would automatically decline.

Two Factor Authentication on transactions
(Rika Raybould) #3

The exception to this is 3-D Secure (often called Verified by Visa, MasterCard SecureCode or AMEX SafeKey). 3DS makes it possible to present additional security challenges to the user for online purchases. These can take almost any form the issuer chooses so Monzo have some space to work in to create something unique here.

Unfortunately, it is up to the merchant to support 3DS but as more online merchants add it to their checkout process, the fraud detection trigger for non-3DS supporting merchants can be lowered to suspect and decline transactions from these merchants slightly more often (offering an easy unlock from within the app).

Worth noting that EMVCo took over 3DS as of 2.0 and that 3DS processing (though not with the normal web frame/popup) is required for merchants to support Apple Pay in-app and on the web.

(neil_cm17) #4

From the sounds of it what I proposed is not techniquely feasible due to need the need to authorise the transaction within 200ms. A way around it might be have to ability to disable / enable the card for card not present transactions or have the ability to enable it for a limited time only.

It does sound like 3D secure was designed to address this but why don’t the card companies make it compulsory? It sounds like they are willing to tolerate a certain level of fraud.

(Rika Raybould) #5

Exactly, it’s a game of providing the smoothest experience (for all parties, not just users) for the lowest costs while also trying to keep risk down and deal with legacy technologies from all around the world. 3DS requires everybody in the chain to support it from merchant to acquirer/processor and then network to issuer.

As the US has shown with their years late and insane train of fail that is their EMV deployment, it only takes one part of the chain to refuse or decide it’s too expensive and the whole thing grinds to a halt.

To get everybody to support 3DS, you have to prove that the security benefits will decrease the level of fraud and increase the throughput of transactions to lose less/bring in more money than it costs to implement. Apple market Apple Pay on the web by pointing out the hugely increased conversion rates from two touch purchases and the near-zero chargeback rate for fraud reasons.

(James Billingham) #6

Some occasional cards (Maestro I believe) do require 3DS for all transactions!

(Ben Green) #7

That may be one way around it, although many online transactions don’t take place instantly at the the customer submits their payment request.

For example, Amazon only take payment when the seller marks an order for physical goods as dispatched. Another problem would be delayed transactions which can happen anywhere anytime. Just happened to me with a starbucks order I made last Friday. Yesterday it got refunded then this morning I was charged again.

It’s a nice idea, but I can imagine it creating more problems than it solves unfortunately :disappointed:

(Ted Peeters) #8

Isn’t this something that would be solved by implementing a ‘Final’-like feature? Separate PAN card numbers created per transaction/per institution, that you could revoke authentication for & assign new numbers to as and when. It’s a huge feature I’d love (along with Moneybox style penny saving) that surely would be some undertaking, and as far as I’m aware, isn’t on the Roadmap yet, but has been talked about before.

(Rika Raybould) #9

Eugh, this whole concept of generating single purpose card numbers still feels like such an ugly, user complex and merchant hostile hack to rely on for anything other than untrustworthy merchants when tokenized payments are taking off and better ways of handling subscriptions are being used by more online merchants (GoCardless, Stripe’s Smarter Saved Cards, etc.).

(Alex Sherwood) #10

I think it could be :thumbsup:

Monzo could make this feature far easier to manage than Final have by automatically setting the card limit & merchant based on the authorization.

I’m not especially concerned about this either. The merchant will never know, unless they do try to charge the wrong amount right?

So if you could set Monzo to automatically create a new card for you each time you make a transaction, without any need for user input, I’d be in favour of this.

If there’s any user interaction required though, I don’t think it’s worth the hassle, as I’ve never experienced issues with these transactions.

Either way, I’d still like to have this solution for subscriptions.

(Rika Raybould) #11

People type the wrong amounts, close them too early, upgrade subscriptions without remembering to also up it with their bank (I know this is not an issue with Final as it simply alerts), allow browsers to save and reuse card numbers, etc. Having discussed this with a few friends that run online stores shipping to European countries that have these kinds of services, they cause total, non-obvious support nightmares from unexpected declines (This may not be such an issue with Monzo however as they already provide a good amount of information in decline reasons and this could be extended.). In addition, they fall over completely when someone thinks they can be clever and use it with a service such as Uber where the authorisation amount is not the final charge.

Giving a merchant permission to pull whatever they want from a single card number like we have now is clearly not the right solution either.

I don’t know what the eventual Monzo solution will be, certainly my personal opinion is to get more merchants using smarter methods to take recurring payments and get users on Apple Pay and Android Pay wherever possible with a smarter bank that is able to track and inform about upcoming payments, warning/alerting if they are suspiciously different than normal.

(Alex Sherwood) #12


RIchard’s last comment & my reply below is related to subscriptions, rather than card not present transactions, see this post for more

That looks like a solid list of potential issues. But I don’t know how often they occur in the grand scheme of things. It sounds like a lot of the issues are caused by users not understanding how to use the cards correctly (though you could argue that this also means they’re too complex of course) & customer support teams not being aware of the product. Both could potentially be solved by widespread adoption & useage of the solution.

So I’ll defer to Monzo here, if they consider these potential problems & create the solution then great, if they decide it’s not worth the hassle, they’re well placed to make that call because it’ll cost Monzo if they get it wrong.

I completely agree with all of these points though -

I know that Monzo’s planning to implement all of the ideas that you’ve listed (apart from the first obviously, which is down to the merchants to implement) & they’ll be really useful.

(Leigh Garland) #13

I work with a lot of big merchants, and they often choose or want to disable 3Ds because the experience is so appalling for the user that it costs them more in abandoned baskets than it does in fraud. I believe that Amazon choose to take the hit on the higher card transaction rate and cover their own losses, rather than use 3DS. It seems there’s definitely some scope for innovation here…