ACH @ POS
I spoke last week with Elliott McEntee, President and CEO of NACHA about two current issues - NACHA’s reaction to “de-coupled debits” and the progress of the Secure Vault Payments program.
Decoupled Debit - Background
Decoupled debit programs, announced by both Capital One and HSBC (as issuers) and Tempo (as a processor) take a normal debit card, issued by a bank and a merchant co-branding partner, and stop the transaction short at the issuer - who does not have a checking account relationship with the cardholder. Instead, the issuer initiates a second, ACH debit transaction, which debits the cardholder’s account at their DDA bank.
The upshot of these transactions is that the debit card interchange is held by the issuer bank, (rather than flowing through to the DDA bank) and used, along with possible merchant contributions, to fund a relatively rich merchant-centric reward program. From the perspective of the consumer DDA bank, the transaction could take away “normal” DDA bank debit card transactions, which produce interchange revenue to the bank, and substitute a non-interchange bearing ACH transaction.
Recent industry “buzz” about de-coupled debit centered largely around the potential for Capital One - or other de-coupled debit card issuing banks - to poach debit transactions and their interchange from the consumer’s bank.
NACHA’s board, meeting last November, released a rules interpretation designed to clarify open questions around not only de-coupled debit but also other point-of-sale initiated ACH debits. (This would include programs such as ACH-enabled supermarket loyalty cards (e.g. Blackhawk’s “Fast Forward“, ACH-enabled drivers licenses (e.g. National Payment Card) and ACH-enabled merchant programs such as those offered by Tempo or Pay By Touch.)
McEntee explained that NACHA studied the issue to determine the whether or not these transactions were in compliance with NACHA rules. The biggest concern, McEntee said, was the risk management perspective. NACHA was concerned that programs such as this not unintentionally subvert risk management practices at NACHA or receiving banks (RDFI’s). Of particular concern was the possibility that the “real merchant” in a purchase transaction not be visible, and therefore not recognized by risk management systems, which may have flagged certain merchants for closer review. Banks were also concerned about the customer service perspective. Would the consumer be able to understand, looking at their bank statement, what the transaction was?
So what was the result? The rules interpretation released had three directives:
- First, the transactions must be classified as “POS” transactions, rather than using other ACH transaction codes
- Second, the transactions cannot represent an aggregation of underlying consumer purchases - e.g. three separate purchases at one (or more) merchants on a given day cannot be combined into a single ACH debit transaction
- Third, the “payee” in the ACH transaction, which is carried through to the consumer’s bank (and therefore appears on the consumer’s statement or online transaction listing) must be the underlying merchant, and not the card issuer: in other words, “Capital One” could not be the payee shown on the consumer’s statement.
These seemingly innocuous “interpretations” in fact pack quite a punch.
The first provision insures that these types of transactions can be isolated at the receiving (consumer) bank, and recognized as different from other incoming ACH debit transactions. This means that a bank could apply actions to those transactions that they don’t apply to other ACH debit transactions. What kind of actions? Well, a consumer bank might assess a fee to the consumer, for example, for that type of transaction. McEntee expressed skepticism that banks would actually do that - recalling the consumer outrage when banks tried fees to “steer” consumers to the use of signature debit over PIN debit at the point of sale. But still, the capability is now there. Other possible actions could include denying consumers debit reward points for those transactions, or even applying different overdraft policies. McEntee made clear that any actions like this are entirely in the individual bank’s domain. The NACHA network, in his view, has simply done its job by ensuring that these transactions, with their unique attributes, can be individually identified - and managed - by RDFI’s.
The second point is that the POS transactions cannot be aggregated. In some ways, this serves to strengthen the programs - presumably, consumer confusion will be less if they see a one-to-one relationship between their purchases and what appears on their statements. But aggregation might have been used by a de-coupled debit issuer to encourage a user to come online to the issuer, rather than their DDA bank, to see transactions listed - and this rule makes that less likely to happen. The same is true of the third part of the rules clarification - that the underlying merchant’s name is carried through to the consumer bank. This also reduces the chances that the issuing bank becomes the primarily online interface for consumers looking for transaction history. The identification of the “real” merchant also ensures that existing risk management systems will work with these types of transactions.
What was equally fascinating to us at Glenbrook is what the NACHA board did not do. Given that the board had authorized, for the first time, an interchange-like “authorization fee” for the Secure Vault Payments (SVP) pilot program (more on that below), it seemed like some other interchange-like fee might be applied to these POS transactions. After all, NACHA board banks (and other members) have seen PayPal successfully build a program that has the effect of keeping interchange-like revenue themselves while using interchange-free ACH WEB debits to access the consumer’s DDA bank. At Glenbrook, we have spoken with bankers who have rued the NACHA decision to permit WEB debits for PayPal-type transactions (although bankers like these transactions when used for other purposes, such as online payment of a credit card bill). So my question was, why not assess a fee on the ODFI of POS debits, and have that fee flow to the RDFI?
In short, McEntee said that this was not an issue which had come before the board - and the implication was that the NACHA board was not the proper venue to discuss the protection of consumer bank revenue streams. In his opinion, the SVP case is special because the consumer bank takes action to authorize - in effect guaranty - the transaction, not dissimilar to what they do when they authorize an interchange bearing debit card transaction. They play no similar role in a POS (or WEB) transaction, so, by that logic, an equivalent fee for a POS transaction would not make sense.
We moved on to a brief discussion of the SVP program.
Secure Vault Payments - Background
SVP is NACHA’s second attempt at a “credit push” program for online payments (the previous attempt was “Project Action”). SVP is designed to be used in consumer eCommerce purchases, online bill payment, and account-to-account transfers. A consumer at a participating eCommerce site would click on SVP as a payment option. They would be redirected (in a manner similar to Verified by Visa or MasterCard SecureCode) to their DDA bank, authenticate themselves to the bank (presumably with online banking credentials) and instruct the bank to “push” a payment to the merchant. The merchant would be protected from both NSF and fraud risk, and the consumer’s account information is not seen by the merchant. NACHA announced the “authorization fee” structure referred to above as a payment from the merchant/merchant’s bank to the consumer bank, to compensate the consumer bank for the authentication and guaranty service.
SVP is nicely designed, in our opinion, but it will take great effort - on the part of participating merchants, billers, and banks - to implement. This is a challenge for the program, and I asked McEntee how things stood.
He was encouraged, he said, by recent decisions by Metavante and Jack Henry to support the program. Specifically, this means that bank clients who are using the online banking applications of these vendors will be able to support SVP transactions, presumably with minimal effort on the bank’s side.
He also said that large banks, who had been notably absent as early supporters of SVP, are re-thinking the program in the light of the potential for authorization fee revenue. (Many large banks, we knew, were previously unenthusiastic about the potential of cannibalizing debit card revenue with no-revenue ACH debits). He anticipates more announcements and participation both from bank processors and from banks as the pilot progresses.
NACHA’s CEO Search
We also spoke about the search currently underway for McEntee’s replacement. The new CEO will have big shoes to fill: McEntee has been at NACHA for 20 years, and watched over a dramatic rise in both volume and capabilities at the network. According to McEntee, his successor will have the same challenge he has always faced: getting banks to work together, so that each bank individually, and their customers, can benefit from the use of what is now the only major bank-owned electronic payments network.
No comments:
Post a Comment