One of the less discussed topic within NFC implementation might be one of the most serious. Bringing customers an easy and cheap option to pay even small amounts with their NFC cards will certainly bring signficiant transaction volume growth for all payment systems involved.
Based on the Reserve Bank of Australia, there were about 11 million credit card accounts in Australia, which on average had 101 transactions per account, per year, at an average value of approximately $141 per transaction in the year 2005 (see RBA FSR 2005.pdf). This number more than tripled by the year 2012, reaching 330 transactions per account (see RBA FSR 2012.pdf). Similar situation also appears to happen worldwide. The Royal Band of Scotland (RBS) in its World Payments Report for year 2011 (RBP WPR 2011.pdf) states that the number of non-cash payments for North America, Europe and APACS regions almost doubled during the same period.
It is clear that major banking players are fighting against card fraud, and chip-and-PIN technology already proved highly effective, where applied. In the U.K counterfeit card fraud loses have dropped by 77% since 2004, when chip-and-PIN cards were first rolled out. Such a success will certainly drive further investments into EMV migration and the growth of all non-cash payments carried clearly correlates with this approach.
With the sunrise of the NFC and Mobile payments, we may see the same scenario happening again, but with a significant difference. Imagine how many times a day you are paying for your coffee, snack, public transport ticket, drink in a pub. With NFC technology, customers received an easy option how to pay for these with a single wave of their NFC card (or Mobile) and they are also rewarded for doing so with a quick transaction, easy for the customer and the merchant (e.g. VISA's product name PayWave). Paying small amounts has never been easier. And now back to technology again. What will be transaction volume growth at your payment system? Is it going to be double, triple or more? A transaction volume forecast by the RBS report mentioned above states that this number will triple by the end of year 2013.
Let's show this on example. Imagine a mid-sized payment switch designed back in 2006 for a regional merchant processing. The original design requirements for this processor were to withstand constant volume of 5 transactions per seconds (TPS), with ability to go up to 50TPS during peak times. As the time passed, TPS tripled by the year 2011 reaching average 15 TPS and with forecast getting to 45 TPS in a 2 years time. As you can see, we have almost reached design limits of our switch, just with average processing. While our peak processing can now easily get over 450 TPS on e.g. Christmas time, or Valentine's day.
Payment switches don't care whether the transaction was carried out for 50 cents or 70 dollars. Also it might be very likely that a total value of all transactions per customer's account won't grow at all. But what does matter is that each transaction coming through your system gets its processing and database storage resources. So far we have covered just TPS, but now imagine that your system needs to generate and send a clearing file to your issuer. Having these generated in 10 minutes these days, imagine this number multiplied by X, where this value have to reflect current size of your database and all transactions taken into account. Will be your clearing extracts from the back-office system send on time? What about reports and settlement operations, will be there a time-frame for those left?
EFTlab's projection shows that for each "fat" transaction there will be up to seven NFC/Mobile transactions. This simply means, a seven times higher transaction rate on your switch in a 2 years time, seven times larger transaction database, all extracts seven times larger and all back-office processing times seven times longer. All that just during a common day processing as these numbers might be completely different over the peak periods. And that is usually the most exposed time of the year, where "lightning" may strike, when your system suffers an outage.
Remedy for this is not simple at all. Payment system needs to be analyzed and secured for this event. For most cases there is still time to find out a value-cost balanced remedy, but these system-bottlenecks need to be identified. Following questions may help you to find out, if this is applies to you or not.
- Do you know your current average TPS?
- Do you know your switch processing limits (TPS)?
- How far are those limits, if you multiply your average TPS by 5?
- Was your system stable and responding all transactions during the last peak period?
- Are you aware about the average response time for your transactions?
- Is there any percentage of these being responded with times over 0.5s?
- Do you know your HSM's processing limits?
- Do you know current load on your HSM (balanced load)?
- Do you know what a portion of the day takes your current back-office processing?
- Is your back-office processing getting close, or over 6hrs per day for daily reports?
- Is your back-office processing getting close, or over 12hrs for daily & monthly reports to be generated?
- Have you practiced your DR procedure? Can you remember how long it took to rectify it and calculate how many transactions would be lost during the outage?
- Are you getting these numbers updated at least every 6 months?
Congratulations, if you are clear to answer majority of all above. In that case you are most probably aware about your system readiness and there won't be too much surprise for you. Otherwise I would strongly recommend getting to your support team and ask them these questions till there is not too late for your customers. Don't forget that we, at EFTlab, are more than happy to support you and your team in this challenge, so that you can have a relaxed Christmas time.