At the time of writing, in Canada, our credit and debit cards have the ability to do “tap pay”, which is when you hold the card up next to or against a receiver device (usually a hybrid that also handles chip and swipe payments) for a brief moment until a notification sounds, and your payment is processed. This is very convenient. The simplicity and speed come at a cost, however: what happens if your card gets into the wrong hands?
There are some safeguards in place. First, an obvious one, is that there is a limit of a certain dollar value per transaction, so at least a thief would not be able to run to the nearest big-box store and buy a new home theatre setup. In Europe, I am reliably informed, this limit is much lower than it is here, further improving the security and making it for those little on-the-go purchases. This, of course, does not prevent them from going to the mall and picking up something small from every store, so there's also a total-per-day limit (according to the one bank I asked, it's $200) to prevent that. It still wouldn't prevent a thief from using the card sparingly over a long period of time. That is where the second security measure comes into place, or at least it should.
When setting up my first card with “tap pay”, the bank staff explained that there is an algorithm in place that is supposed to “flag” abnormal attempts for a payment authorisation, and then request that the buyer enters in the PIN for the card. In the time that I had “tap” enabled, I had my PIN requested fewer than 1% of payments, and at locations that were not abnormal, such as our most-frequented grocer. The times where the card was used in abnormal ways, like a big day at the mall, the PIN was never requested. I found this rather abnormal, as it seemed that our actions would be typical of someone snatched a wallet in a crowded area.
When I realised this, it made me wonder what could be done to improve the security of this method of payment without diminishing its benefits.
Here is my theoretical solution:
When a card is first used at a merchant, “tap” always requires the buyer enters their PIN. By entering the PIN for a transaction, the buyer has approved that merchant for “tap” payments. If the cardholder goes to another business, the same process occurs. If they return to a merchant that is already been approved, then “tap” works with no PIN. The approval could be given something along the lines of a three-month expiration from the last payment to further prevent theft. This way, a daily trip to the overpriced cafe or the gas station would be a simple “tap”, whereas the infrequent visit to the hardware store may or may not require a PIN, depending on how much DIY the buyer does.
Another level of security that could be an opt-in addition would be to link the approval to the amount be paid. When a purchase requiring a PIN is made, the authorisation system records the amount paid. When further payments are attempted at that merchant, assuming the authorisation has not expired, the amount must be less than or equal to the PIN-authorised transaction. If the new payment is greater than the previous maximum, then the PIN becomes a requirement again. This way, if the pickpocket is a keener and attempts to make a large purchase at the store they just saw their victim leaving, they would not be able do go on a shopping spree.
These changes would make the system much more secure and require much less waste on the part of the banking system. The only “tap” payments that would happen would be at businesses where the process is explicitly approved and, if that additional price-based precaution is in place, payments for amounts that the cardholder has deemed to be normal. The number-one benefit of my suggested changes, however, would be that there is no need, or at least a much lesser need, for an algorithm to notice when a payment is abnormal, because they give the cardholder more control of how they approve what is normal, and by having a more explicit “normal” and “abnormal” list, it actually makes things more convenient for the cardholder. That is what I want.