Object reference not set to an instance of an object.

Card-not-present (CNP) fraud is a big problem and is getting worse. It is possible its severity and the way it is outpacing ecommerce growth have influenced the drafting of the PSD2 and EBA RTS and defining the required levels of customer authentication and exemptions. Indeed, I attended an event recently where CNP fraud statistics were used to emphasise the need for payment security regulation in the PSD2.

To quantify the CNP fraud issue, based on a quick Google search, CNP fraud is growing at roughly 21% per year in Europe versus 13% per year growth in ecommerce. The value of European ecommerce is approximately €500 bn euros annually, and CNP fraud is about €1bn. In contrast, European card-present fraud (at point-of-sale) is falling and is below €300m per year.

However, is it right to relate the fraud risks of CNP transactions to PSD2 payments, specifically PISP payments where customers initiate and push a payment directly from their bank account to a beneficiary (a retailer for example)?

I don’t believe so, or at least I don’t expect that fraud arising from PISP payments to mirror CNP fraud.

A card is inherently prone to fraud. The root-cause of card fraud is theft of card numbers and related data through for example, hacking (data breaches), interception or phishing – card numbers are easy to steal and can be used with comparative ease in CNP ecommerce transactions, hence the growth in CNP fraud. The cards industry has layered ever-increasing sophistication onto cards in an attempt to make them secure in the digital world – for example, PCI, EMV, 3D-secure, dynamic CVV and tokenisation to protect and/or disguise card data; and with some success, notably EMV at POS, but this does not get away from the weakness of the pull payment process where card numbers are in effect keys to the account.

In contrast, PISP payments are push payments, sent by the consumer to the beneficiary’s account. No credentials, no card numbers, no bank account numbers or other identity details are shared with the beneficiary (or anyone else) – PISP payments are inherently much safer than card payments.

A good example of this is the iDeal ecommerce payment system in the Netherlands, where consumers push payments directly from their bank accounts to merchants. In operation for 10 years, iDeal is popular in the Netherlands and is the dominant online payment method. I can’t find fraud figures published by iDeal, but I understand they are very low and the evidence points to this: the low cost to merchants of an iDeal payment indicates any fraud risk premium in the fee must be low, and iDeal has no chargeback mechanism, also indicating that fraud is low (as a chargeback mechanism would undoubtedly have been implemented if reimbursing consumers for fraud is a regular occurrence).

The EBA has had to balance competing requirements in producing its RTS for PSD2, in particular the balance between user convenience and security. Feedback suggests the industry believes the balance is not right yet, particularly the low exemption limits and the inability of merchants and PSPs to make their own risk-based judgements on security.

I don’t know how, or even if the EBA has used CNP fraud data to inform its decisions to formulate the PSD2 RTS for secure customer authentication, but I suspect that the alternative payments world of push payments is a more realistic, and very different guide to fraud risks under PSD2 than the current realities of CNP fraud.