The Australian Payments Clearing Association (APCA) releases card fraud statistics every six months for the preceding 12m period. Lockstep monitors these figures and plots the trend data. The latest stats were released this week, for FY 2012.
Here's the latest picture of Australian payment card fraud growth over the past seven financial years FY2006-12.
Compared with FY2011:
- Total card fraud is up 25%
- CNP fraud is up 27%
- CNP fraud represents three quarters (72%) of all card fraud.
- Card Not Present fraud as a proportion of all fraud remains at just under three quarters (72%).
As with the CY2011 stats we discussed last July, card fraud has again grown in all categories at once, not just Card Not Present, and this is unusual. The explanation may be a burst of skimming and counterfeiting in late 2011 which would be reflected in both the FY2012 and CY2011 numbers.
APCA's press release this week notes that card fraud has dropped in the past six months, contrasting financial 2012 ($189M) with calendar 2011 ($198M). This may not be a statistically valid comparison. We should expect seasonal buying habits will cause asymmetries within 12 months, making FY against CY a case of apples and oranges. Indeed, this looks like the first time APCA themselves have plotted CY and FY stats together. It certainly makes the latest figures look better.
Time will tell whether the trend is changing. The long term trend is that CNP fraud has grown at 38% p.a. on average, from $27M in FY2006 to $189M in FY2012. A 5% drop in the past six months may not mean much. The $189M loss most recently reported is probably close to the true trend.
APCA says "Broadly, the value of CNP fraud reflects growing retail activity in the online space, with many more businesses ... moving online". That's true but the question is: What will we do about it? Bank robbers rob banks because that's where the money is. Think about high road tolls: they reflect the popularity of driving, but we don't put up with them!
In any case, a cardholder's exposure to CNP fraud has nothing to do with whether they themselves shop online! Stolen card data are replayed online by criminals because they can. The online boom provides more places to use stolen cards but it's not where the criminals get most of their cards. Instead, it appears that account numbers are mostly obtained from massive database breaches at processors and large bricks-and-mortar retailers, like Heartland Payments, Global Payments, and Hannaford. So it's not fair to play down CNP fraud as relating to the cost of going digital, because it hurts people who haven't gone digital.
I'm afraid payments regulators seem light on ideas for actually rectifying CNP fraud.
Until recently, APCA actively promoted 3D Secure (Verified by Visa or Mastercard SecureCode) as a response to CNP fraud. In June 2011, APCA went so far as to say "retailers should be looking at a 3D Secure solution for their online checkout". But their most recent press release makes no mention of 3D Secure at all.
It looks to me that 3D Secure, after many years of disappointing performance and terrible take-up, is now too contentious to rate a mention from Australia’s regulators.
In my view, the industry needs to treat CNP fraud as seriously as it did skimming and carding. The industry should not resign itself to increasing rates of fraud just because online shopping is on the rise.
CNP fraud is not a technologically tough problem. It's just the digital equivalent of analogue skimming and carding, and it could be stopped just as effectively by using chips to protect cardholder data online.
The European Central Bank (ECB) and Reserve Bank of India have mandated that all online transactions must be subject to strong customer authentication from 2015 and Mid 2014 respectively. Other Central Banks have announced they will follow the EU lead. The ECB approach is technology neutral, and, mandates a liability shift by operation of law, overriding the card scheme rules. See http://www.ecb.eu/press/pr/date/2013/html/pr130131_1.en.html or https://en.wikipedia.org/wiki/Strong_authentication
3D Secure is one solution, but, as you mention, it has a terrible take up rate. This is due to a variety of factors, including poor customer experience, technical communication drop outs, low issuer enrolment, intrusive cardholder enrolment process and complex/outdated iframe based integration. The abandonment rate is more than 52%, according to Mastercard http://www.mastercard.com/us/merchant/pdf/rba_secure_code_HR.pdf (see Oage 5). 3D Secure also needs to be implemented on a card scheme by card scheme basis, making it expensive to roll out. Note that only the new version of 3D Secure complies with the ECB requirements, which mandate a dynamic factor, deprecating the old "passphrase" approach used by 3D Secure in legacy systems.
There are alternative authentication solutions in the market, that use 'reliance' authentication, and re-use the issuer's existing banking portals and security. This is in contrast to the expensive and difficult to maintain dedicated network, per the 3D Secure approach.
Reliance authentication is here > https://en.wikipedia.org/wiki/Reliance_authentication#Reliance_Authentication . Basically, as second party "relies" upon the security and identification of a first party, such as the issuing bank, using indirect means.
Examples of reliance authentication are :
a) PayPal's verification method, but which unfortunately only identifies first possession of the card, and not subsequent transaction authentication. It is a proprietary solution for use with PayPal in any case. This is method that sends the two random credits to your nominated account, that must later be confirmed by the cardholder accessing the account, thus relying upon the issuer's security.
b) NPCI in India and PaySecure, http://www.npci.org.in/PaySecure.aspx. Unfortunately, this isn't multifactor, so does not comply with the FFIEC and ECB requirements. The NPCI / Paysecure process uses a static PIN and a static image lookup process. Initial sign up process is via reliance on the issuer's security and cardholder accessing the account to retrieve last 3 transactions. This seems to me to suffer from the flaw that a fraudster could just as easily transact 3 times in a row, record the amounts, then enter the amounts, without needing to resort to accessing the account.
c) The http://www.isignthis.com method, which is ECB compliant. The iSignthis process, upon first detecting use of an unregistered credit card, notes the transaction amount as determined at the eMerchant point of sale, and splits the original sale transaction amount into two random amounts that equal the original sale amount. These 'splits' are processed normally, and the cardholder is asked to access and retrieve these amounts from their banking portal. The iSignthis process is a similar customer experience to PayPal, except that the process targets specific transactions as initiated at eMerchants. Mobile can be linked to card number for transmission of OTP's in order to streamline future transactions.
All of the above processes are patented, with b) and c) available as a service.
The above solutions are all cloud based, and rely upon the multi-factor authentication already in place with the issuer. Thus, there is no need to issue expensive chips in advance to users. Cardholders are already familiar and trust accessing their online, telephone or mobile banking. There is only passive involvement required from issuers, which in turn means that reliance authentication can reach all cards, without need for pre-enrolment.
The reliance method has legal standing under US, EU and Australian Anti Money laws when used with means that positively identifies traceability to the payer, or the payer. The ECB has now defined strong customer authentication, which clarifies requirements in this regard.
The ECB defines Strong Customer Authentication as:
â��a procedure based on the use of two or more of the following elementsâ�� categorised as knowledge, ownership and inherence: (i) something only the user knows, e.g. static password, code, personal identification number; (ii) something only the user possesses, e.g. token, smart card, mobile phone; (iii) something the user is, e.g. biometric characteristic, such as a fingerprint. In addition, the elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s).
At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the Internet. The strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data."
The Federal Financial Institutions Examination Council of the United States of America (FFIEC) issued Authentication in an Internet Banking Environment , dated October 2005.
Supplemental guidance by the FFIEC on this subject was issued in August 2006 , in which it was stated:
"By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category ... would not constitute multifactor authentication."
Further guidance by the FFIEC was provided on the 29th July 2011, where â��out of bandâ�� responses via differing devices were also encouraged.
Perhaps the Reserve Bank of Australia should step in and join the ECB, RBI, MAS (Singapore), the FFIEC, Swiss National Bank, and other Central Banks and mandate some technology neutral standards.
Thanks John for your interesting and thoughtful inputs.
I have to say however it's all very complex and novel from the cardholder's point of view. Yes, cardholders are familiar with Internet banking, but I don't see why an Internet banking experience should be interposed in the normal credit purchasing workflow. After all. when I use my card at the store, I am not forced to interact with the bank as part of the authentication. It should be the same with using my credit card online: I should be able to present it to the e-merchant electronically, and have the merchant verify (cryptographically and seamlessly) that the card and cardholder details are correct.
If we simply used the cryptographic primitives already built into chip cards and all browsers and mobile platforms, we could digitally sign payments instructions using a key unique to the cardholder, preventing replay attack and curtailing most CNP fraud online. See http://lockstep.com.au/blog/2012/04/01/kill-two-birds-with-one-chip.
This is the same technique used to authenticate an EMV card to a merchant terminal. Why not use it to authenticate the same card remotely to a merchant server?