Pricing the Push Model; Putting Apple Pay into Obsolescence; Same Thing

The push model (payer directs financial institution (FI) to pay; payee does not request payment) has many price options which make income from interchange fees look like the punk change its fast becoming.  As governments move to cap interchange fees (the MasterCard decision in Europe and the Durbin Amendment in the US) FI incentive to create a new billing structure that cuts out the transportation middle men and keeps most fees in-house increases. The Push model will do just that.

If payees have a common registry which FI access to route push payments then payer (nee Issuer) FI charge consumers various types of fees consistent with transaction volume and value. Since Regulation E does not apply (Reg E forbids payer liability for pulled payments) FI can charge payers for insurance for unauthorized transactions, or charge a set fee for a capped number of transactions over a set time period.

Consider each FI account world wide as a potential retailer number. Compare that number with strictly retail accounts receiving payments from payment card activity. Since the retailer subset is clearly quite less than the complete set of all accounts, the potential fee payer pool is quite less and therefore cannot dilute fees in a reasonable manner. The push model changes the number of fee payers to all with any kind of FI account and so the fees can be significantly less and still increase FI income considerably. FI also remove themselves from the clutches of anti-trust warriors because they will compete for accounts by changing the fee structure for various types of customers.

Retailers themselves without the overhead of payment origination infrastructure may offer to pay some or all of consumer fees to attract bargain hunters. If a common standard exists for a data protocol (tailored ISO 20022 anyone) from personal electronic devices (PED) to FI then a total amount can be diverted to various parties including fee payees and tax authorities. Signs at the checkout lanes may offer discounts for specific payer FIs because of deals struck by regional, national, or local FI.

In short retailers will stop accepting payment cards because of the expense and the race to get payer money by striking deals with large and small FI going after various segments of the payer business. Apple Pay will be obsolete in a few years and EMV compared unfavorably to the beta max video model.

Next Blog: Payment Homeomorphisms

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

Does Government have a Role in the Evolution of Payment Systems?

Lawmakers cannot define a payment hub. When they try, they make laws like defining pi as 3.141 to make construction budgets (and therefore timed payments) precise. Other than being really funny (forgive my odd sense of humor), such bizarre attempts raise a legitimate question, namely, does government influence on payment system architecture needlessly force modifications or does it have a benefit. 

  

I think payment hub design requires data elements that support the only legitimate government concern, taxes, and fight back on government encroachment on anonymity due to cross border or value inspections. Governments wanting to know specifics of transactions traveling within payment systems need warrants based on probable cause other than detection of a large value because of a large tax payment.   

I am not naïve; governments can, have, and will use payment systems, like any other commercial infrastructure, as a weapon or an intelligence platform, so be it, but that requirement should not influence efficient design. This discussion leads naturally to a question of a cash pools, their union, and the obvious attraction they garner from thieves and governments alike.

No reader yet has contradicted me on the published premise that payment systems require speed between initiation and settlement to reduce risk. So why are we not seeing various economic sectors teaming together to form small value gross real time payment systems (SVGRTP) based however loosely on the Bum’s Pocket I described earlier in this blog

(see http://paymentnetworks.blogspot.com/2014/07/indian-tribal-organizations-as-model.html et. seq. ).

My vision of a patron at say an Indian casino in Michigan with a windfall of winnings, leaving with nothing more than a passport, and traveling to Macau and back without a payment card, cash, or anything except the ability to transfer funds immediately from the casino to the taxi, the airline, the hotels, the restaurants, and tips in cash when required, without any trepidation, remains only a vision.

Certainly the toothless antitrust authorities in the US do not stand in the way and the other G20 nations endorse cross small value transfers using the haphazard pull methodologies implemented by cards and other tokens set up in advance under careful host government scrutiny. Why financial institutions let large payment networks dictate the relationship between them and their retailers and force apart their natural conduit of fund movement remains a true mystery.

I do understand the reluctance of financial institutions (FI) to meddle with a working system regardless of leaky pipes and archaic data structures. However, at what point do FI look around and realize that their customers demand rapid movement of their funds in a secure reliable way and they will go elsewhere to get that service as manifested by growth of private label and pre paid cards. True governments such as the US making prohibitions for instance on gambling, requiring funds reporting, allowing the immediate ex-judicial seizure of cash in or out of bank accounts, enforcing card issuer and payment network monopolies by allowing the price fixing of fees, and many other nanny policies increase the search for alternate payment methodologies. However, FIs need to pull their collective heads out of the sand and compete in a realistic manner or they will find themselves on the losing end of a retailer revolt that creates self sustaining models of the bum’s pocket.

Next Blog: A PED design for access to the Bum’s Pocket

Review of The Iphone Payment Initiation Method

After doing a bit of research on the new Iphone payment application and finding very few facts, I thought I could easily make up some facts and see if my reader(s) agree. The application initiates a payment using a token, a cryptogram, a geocoded position, and an approved amount. User authentication (biometric) occurs as a separate function from payment initiation A large acquirer routes the transaction by translating a portion of the token as a bank identification number (BIN). The acquirer forms an 8583 request using the personal account number (PAN) portion of the token which the issuing institution (or its agent, likely the large acquirer) translates to the actual PAN. No EMV required although a PKI method may have produced the cryptogram giving a nod to the EMV Imperium.

Apple cut a deal so they will assume some Reg. E payouts and that might be the devil that makes or breaks the venture. The scheme (if I am remotely near the actual facts) likely will succeed in the near term because there is easier money in data scraping electronic cash registers in regional and national chains than there is in jail breaking the I6 and launching a lunch time attack. However the imagined payment architecture is vulnerable to a lunchtime attack, (ultimately allowing intercept of NFC transmissions, and counterfeiting the results) or a Man-in-the-middle attack (intercepting and moving the auth request to another retailer while jamming the NFC with the retail receiver). Neither attack is cost effective while the keystone cops trace data scrape attackers with “tut, tut, you need EMV”. Sooner or later, however, just like the price of oil causes wildcatters to reopen wells, moving data scrapers to the iphone application, its predecessors, and its progeny will seem like a reasonable business proposition.

As long as financial institutions do not push payer funds to payee accounts with real time notification routed correctly to payer and payee then payer funds remain vulnerable to retailer foibles, mainly the false retailer belief that possession of payer financial data increases the velocity or impact of payments.

Next Blog: Something you know, something you have, and something you will think.

Restricting PED Functions while initiating Payments

The initiation of a payment is the result of a series of discreet functions. The functions act on sensitive data (payer and payee financial data) which requires a unique environment because money attracts theft. The rapid growth of payment initiation from a personal electronic device (PED) naturally attracts thieves (and possibly others with different motivations). However the operating systems of commercially available PEDs allow unrestricted user activity because diversity of functions available to users drives PED ubiquity.

This divergence of function (restricted v. unrestricted) requires a reasoned response fitting the problem and yet still allowing users the myriad activity available to them. In the previous post I advocated the use of a hypervisor to monitor operations of electronic cash registers based on X86 architectures (see http://paymentnetworks.blogspot.com/2014/09/is-implementing-hypervisor-for-ecr.html ). This approach works only with devices dedicated to initiating payment and is not practical for a PED.

If we look at operating systems available for most PEDs and consider their use for initiating payments it’s a bit like looking into the mouth of an alligator just before you put your head between its jaws. Further, payment data moving in the clear from device to device, allows interception outside of PED operating systems and thus gives attackers the opportunity to counterfeit payment initiation. Encryption of all data with keys accessible only to the payer and the account administrator clearly solves the problem of financial data traveling in the clear. However the data still exists in the clear on the PED before transmission and thus open to attack with very little ability for defense. Providing defenses against attacks requires slowing all activity on the device (a non-starter) or slowing payment initiation to make sure the PED does not host attacking software.

I take the liberty to define hypervisor differently than the precise use of the term in my previous post. I define hypervisor as any trusted kernel that only allows software registered with it to run. The kernel can increase protection and slow the initiation of payment further at a level that makes sense for the risk of harm present in a transaction.

The hypervisor may be present after boot-up, but only active when users initiate payments. If we consider the various software present in a PED as sets of functions, then diagram 27 shows the intersection of a hypervisor with other functions.

Diagram 27: Intersecting Sets of Functions

Designers now can create trusted applications and drivers, register them with hypervisor providers and grow the relationship between hypervisor and trusted applications to services other than payment initiation. In the US this tradeoff between speed, flexibility (running a non-trusted application while initiating a payment), and transaction security, does not seem to appeal, because unauthorized transactions must be refunded as per Reg E. However if Regulation E no longer applies because user push payments instead of having the payee pull the payment, then the tradeoff may be more acceptable. Predicting the reactions to users is for marketers and not a topic of this post, however, neutralizing future attacks on PEDs, may boil down to a question of selling it to the users.

Next Blog: How safe is NFC transport 

Is Implementing a Hypervisor for ECR Payment Applications Cost Prohibitive?

The publicity surrounding data scraping attacks against ECR applications prompted me to write a few posts about approaches to stop the execution of such malware at the operating system level (see for example http://paymentnetworks.blogspot.com/2014/07/detection-of-data-scraping-in-retail.html ). After the recent UPS attacks, I think it is quite clear that the payment systems industry will not form a uniform response to these attacks and instead touts Europay, MasterCard, VISA (EMV) as more of a prayer than a solution.

The ability for the Intel and AMD X86 to host hypervisor kernels provides ECRs a superior ability to detect and stop these attacks; however, retailers will be in no mood to deploy such a response once they have already forked over most of their equipment upgrade budget to move to EMV.  Certainly ECR software developers will likely have some academic help.

Amit Vasudevan and his fellow researchers at CyLab, Carnegie Mellon University seem to have a clear sensible approach to any that care to listen about methods to control applications running on a platform processing sensitive data such as payer financial data. 

For example in:

“Requirements for an Integrity-Protected Hypervisor on the x86 HardwareVirtualized Architecture”

 by Amit Vasudevan, Jonathan M. McCune, Ning Qu, Leendert van Doorn  and Adrian Perrig  (from  CyLab, Carnegie Mellon University; Nvidia Corp; Advanced Micro Devices (AMD) Corp) (http://users.ece.cmu.edu/~jmmccune/papers/vasudevan_mccune_ning_leendert_perrig_sechyp_trust2010.pdf )

The researchers describe clear rules for implementing a hypervisor generally (which no one has yet done, and maybe extremely difficult to do but implementing just a fraction of them (which has been done) would significantly deter data scraping attacks).

The researchers provided another jewel:

“It’s an app. It’s a hypervisor. It’s a hypapp.”:Design and Implementation of an eXtensible and Modular Hypervisor Framework

By Amit Vasudevan, Jonathan M. McCune, and James Newsome (all from CyLab, Carnegie Mellon University, 2012)

(https://www.cylab.cmu.edu/files/pdfs/tech_reports/CMUCyLab12014.pdf)

The article describes design principles for creating the secure environment.

 AMD and Intel hypervisor modes are not compatible with each other so developers will need to write different versions, one for Intel’s “Separation Kernel Model” and the other for AMD’s “SVM – Secure Virtual Machine (PACIFICA)”.

 If these are successful (counters data scraping attacks) then users on compatible computers initiating payment for personal use might be able to implement similar approaches. If the costs to implement this type of approach prove to be cost effective then more trusted applications working with payment operating systems would increase the efficiency of managing sensitive data in hostile environments and quickly deploy to face future threats.

Next Blog: The Difference between DUKPT and EMV approach to Security

Will a Personal Electronic Device Data Standard Eliminate the Acquiring Function?

Let me (for the purposes of this post) define acquirer as any entity between a purchaser and the purchaser’s financial institution. This definition is far too broad for a typical discussion of the payment services industry; however it suits the point of this post quite nicely. The definition makes any part of the payment network providers (regardless of brand or size) an acquirer, It leaves an issuing FI or its authorizing agent, the sole party needed for  a financial transaction with a payer and it is a very scary concept to payment network providers.

To demonstrate the concept Diagram 26 shows the current retail payment system infrastructure present in many countries today.

Diagram 26: The Acquiring Function Infrastructure

And Diagram 27 shows an imaginary structure without an acquirer.

Diagram 27: Hypothetical Payment Hub without Acquirer

I ask my readers which diagram depicts a cheaper network easier to deploy and more adaptable to the emerging human communication methods.

The reason we cannot implement diagram 27 right now is because data transport standards encapsulating payment information from a personal electronic device (PED) do not exist. Such standards need to adapt a key management scheme such as DUKPT, a reasonable number of digits to be stored in secure areas of the PED for use as offsets, transaction counters, etc. and more importantly able to accommodate an astronomical number of individual PEDs.

Another reason we cannot implement diagram 27 right now is because of the insistence that payees pull payment from payer accounts instead of payers pushing payments to payee accounts. If we build the standards the more efficient push method of payment will come because it eliminates regulation E in the US and more importantly for the rest of the world it eliminates switching fees.

The standard needs much more detail than a reasonable encryption scheme and I can think of many elements that need careful consideration among technical folks from quite a few different industries, so the sooner, we build a standards technical committee, then the sooner we can build a payment hub that gives the security payers need at a fraction of the current costs.

Next Blog: Why queues containing payment data in the clear are the biggest target today