As both a customer and a bank employee, I see the frustrations on both ends of monetary transactions. Since we don’t pay for anything with cash anymore, and with cybercrime and fraud keeping pace with the exponential growth of technology, studying ways to protect oneself quickly becomes a rabbit hole of madness and despair. Well fear not (rather, keep a healthy level of fear)! I will use my experience in the industry to try to simplify this nagging question: how do I pay for things? I will do this by tackling two subjects: Liability and Security.
Liability
Liability is simply: who is immediately responsible for fraudulent transactions? I say “immediately” because ultimately the bank still has to investigate, but depending on the type of transaction, someone’s money is tied up in the meantime. Also, ultimately customer loss is covered under different legal protections by transaction type. I will explain.
For Debit Cards, customer liability is based on when activity is reported. If a lost card is reported and then the card is used, that’s the bank’s fault for not deactivating the card. If the customer waits 2 days, there’s a $50 liability. Beyond that, up to 60 days, there’s a $500 liability. Beyond 60 days, and the customer is not protected from the loss.
A second point on Debit Cards–it’s the customer’s money that’s tied up during an investigation, depending on how nice the bank is. So even if you immediately report a lost card, and someone uses it to drain your account, you’re up a creek with no personal funds while the investigation is underway. That’s an extreme example, but something to consider.
For Credit Cards, customer liability is also based on when activity is reported, but it’s far less important. Technically, the law was very similar to Debit Card liability until the CARD Act. Now, the 60-day rule no longer applies, so customer liability caps out at $50. Even so, most credit card companies simply waive that paltry (to them) $50 liability for marketing purposes (pay attention to the next solicitation you get in the mail).
And, referencing the earlier point, a credit card is not the customer’s money. While an investigation is pending, it is not the customer’s finances that are being held. A stolen credit card is an inconvenience, yes, but a relatively minor one.
Security
Now that we’ve covered who’s responsible for what, we can address what is the safest method of payment. Security is defined by 3 methods: something you have (a physical card), something you know (a PIN), and something you are (biometrics). Security is enhanced as these methods are compounded. To explain: a magnetic strip credit card only leverages a single method: possession of the card itself. A physical swipe is all that’s needed for authorization. This method fails when that account information can be flashed to blank cards, creating facsimiles (counterfeit fraud, in the industry). Account information is stolen both on an individual basis by reading the unencrypted account number off the mag strip by a harvester (by anyone nefarious who has temporary access to your card), and from merchant databases (since merchants store your full account number for transactional history).
To address these problems, the EMV chip was introduced. The idea is that a card would leverage a second factor of authorization: something you know. In this case, a PIN would be coded into the chip with the account number and encrypted, thus preventing card duplication and rendering a card useless if stolen. It also makes storing and stealing information less useful because transactions are assigned a session token, determined by an algorithm on the chip and applied to transaction-specific data and a terminal nonce; only valid for that transaction; which the bank takes as verification that it was your card being used. This became known as the Chip and PIN method.
But, this method was neither standardized nor enforced. EMV whitepapers include a number of possible applications, which translates to varying degrees of security of which the customer can’t readily determine. And so, we also ended up with the Chip and Signature method. This undermines part of the point by not requiring a second factor of authentication (i.e. the PIN). The Chip and Signature method encrypts the account information and generates tokens in the chip, same as Chip and PIN, hopefully preventing harvesting the information and mitigating counterfeit fraud, but it doesn’t require a PIN. You see the difference–a stolen card can still be used.
Also, until chipped cards are mandatory, many are still printed with a magnetic strip, defeating all the benefits of the chip. The law shifted so that the bank can now force all liability on the merchant for not supporting chip technology, but nothing is legally required, so in the meantime we still have cards with insecure magnetic strips.
Now back to debit cards. The original debit card was only a debit card. It had an insecure account number in a magnetic strip, yes, but it required a PIN to authorize–so two factor. A stolen card, therefore, was theoretically useless as the thief wouldn’t have the PIN. But, then banks started leveraging the credit card networks to offset transaction costs, which is why you can run your debit card as a credit. Running it this way doesn’t require a PIN, thus destroying the purpose of the PIN itself, and the money still comes out of your bank account.
So to date, we had a single-factor authentication card, came up with a couple two-factor methods, undermined one, haven’t standardized the other, and came up with a way to mitigate duplicating a card but haven’t standardized or enforced it.
The most recent enhancement has been mobile pay–specifically for this article: Apple Pay. In this method, a secondary account number, derived from nonce i.e. the token, is generated and stored on a mobile device. As in the way time-based authenticators are used, a cryptogram is generated at the time of sale from an algorithm, the variables of which are unique to the device itself and cannot be determined mathematically from the cryptogram or the token, both of which are submitted to the merchant for authorization. A third element, a dynamic CVV, is submitted as well, another algorithmic derivative of the token and cryptogram. The security lies in that that the token, cryptogram, and CVV output are all required for a transaction, yet two of them are dynamic, and the cryptogram which ties together the mathematical relationship relies upon device-specific identifiers that are encrypted on the device and never divulged–only verified through the process–likely a hash (this is an overview, as the specific details are not published). The point is that any information harvested in the transaction or stored cannot be used to determine the account number, nor re-used, nor applied to determine the cryptogram’s elements that generate the cryptogram/CVV.
Furthermore, the mobile pay method leverages the security of the customer’s mobile device, therefore enforcing two factor authentication (the phone’s password/owner’s fingerprint). And, since all data is encrypted by default on an iPhone, stealing the phone won’t allow its use for payment.
Conclusion
For maximum security and minimal liability, use a mobile pay method of a credit card. After this, I rank other methods in decreasing order of ideal security/liability combination: mobilepay/debit card; Chip and PIN credit card*, Chip and PIN debit card*; Chip and Signature credit card*; magnetic strip credit card, Chip and Signature debit card, magnetic strip debit card.
*Only if card does not also have a magnetic strip.
NOTE: I have yet to be issued a chip-only card. So far, they have all been dual chip/magnetic strip cards. Dual cards ultimately offer little benefits over magnetic strip only cards if the card is stolen, but do use the chip over the strip whenever possible as this still limits the use of stored credit card data.
Bottom line: use mobile pay if possible, and always use a credit card over a debit card.
Also, you might be wondering how a phone or internet transaction occurs, to which I say: good question. If no one’s scanning the card/device, obviously the card’s security is moot. Although, Apple Pay does integrate with iOS applications, so you can pay through the same device’s merchant application as Apple Pay. And for EVVs, there is information regarding an out of band dynamic CVV generation….
Obviously we’re still working on the problem as a society. I dunno, maybe pay with cash after all.
–Simon
