Will an Iphone Competitor Offer a Push Transaction and Eat Apple’s Lunch

In a recent review ( see http://paymentnetworks.blogspot.com/2014/09/review-of-iphone-payment-initiation.html )  of the Iphone payment application, I noted it offered a reasonable risk posture (surmised from a conjecture of the payment architecture, not knowledge of the payment architecture) for the time being but open to a variety of attacks likely to occur when data scraping attacks meet tough new defenses. The conjecture of the Iphone architecture came partly from various descriptions I picked up from surfing the net ( see for example Ian Kar excellent post http://bankinnovation.net/2014/09/apple-said-to-negotiate-deep-payments-discounts-from-big-banks/  or http://lexpansion.lexpress.fr/high-tech/paiement-sans-contact-pourquoi-l-apple-pay-change-la-donne_1574585.html ) and partly from techniques I have discussed on this blog (see for example http://paymentnetworks.blogspot.com/2014/07/catalog-of-attacks-on-retail-payment.html ). 

With the implementation of a token (finally eliminating a personal account number (PAN) in a transaction when the card is not present) and taking the validation of the user out of the authorization process the application meets some of my criteria for a secure payment method. However, the payment method does not accomplish a payment push to a payee and still needs an acquirer to route its transaction in a conventional way.

Personal electronic device (PED) manufacturers and their software developers will likely notice these glaring holes and see the value of transmitting payment data directly to the payer’s financial institution (FI). For this to work payees must exist in a data store that allows the payer’s FI to route the payment correctly and instantly notify the payee and payer that funds are en route. The account numbers associated with the payee must be one way only and not allow a transaction push or pull to originate from the same number. Such a convention allows banks to assign potential payees a publically accessible number without any risk to the funds in the associated account. The equivalent of a bank routing number embedded in the identifying number will eliminate duplicates by competing financial institutions.

Best of all, the merchants will not need to pay an acquirer, Reg E. will not apply, and attackers will only have small windows for a man in the middle or lunch room type of attacks against the payer only; data scraping will be useless. Those pluses will spur PED developers to create the next payment super application. 

Next Blog: Eliminating data scraping attacks in a payment push architecture