Secure Vault Payments - A Bank-Centric Alternative Payment System

Introduction

Ken Myles of NACHA recently stopped by Glenbrook Headquarters to talk about NACHA's Secure Vault Payments (SVP) and to show us a demonstration. We've long been interested in learning more about SVP because it is built around the "pus h" model of payments, which is inherently less risky than the "pull" model heavily used in the United States today for customer-not-present ecommerce transactions.

Push vs. Pull Payments

Understanding this difference is crucial. With pull payments as currently in use, the consumer must provide the merchant (or biller) with their payment details (name, account number, etc.). The merchant then uses that information to "pull" the payment from the consumer's account at the consumer's bank. When it works (and there are lots of pull payments done this way every day), it's a thing of beauty.

At the physical point of sale, payment cards make it fast and easy for the consumer to provide the necessary details to the merchant. Indeed, card-based pull payments at the physical POS work so well that the consumer’s bank guarantees the merchant good funds. The card issuer bears any risk of fraud or consumer credit loss.

However, in the customer-not-present ecommerce environment, both the available technology and the supporting operating rules are different - and that creates new opportunities for fraud (for which merchants are liable, in almost every case) and higher risk management and operational expenses - primarily for merchants but also for the consumer's bank. Since payment details must be shared with the merchant, the pull payment environment leaves the consumer potentially vulnerable to identity theft if their sensitive payment details are ever compromised through a merchant or processor card data breach. Yes, consumers know they are protected, that there is zero-liability on bank cards, and so on -- but it is still an experience that most Americans would much prefer to avoid.

With push payments, the consumer directly authorizes the purchase with their bank, who then pushes funds from the consumer's account directly to the payee (the merchant or the biller). Funds pushed in this manner are often referred to as "good funds" because they have to be in the consumer's account for the payment to complete and the funds cannot be reclaimed through a subsequent chargeback or otherwise reversed. Push payments can also simpler for the merchant to manage because they are not involved in collecting and managing payment details, nor do they have to worry about the consumer "fat-fingering" their payment details as they enter them on the keyboard. This is especially attractive to merchants and billers that have been using electronic check data (bank routing number and account number) to pull payments from consumer's checking accounts using ACH debits.

Meet the Players

As a reference, it's useful to compare the Secure Vault Payments to the card-based payment systems in heavy use by eCommerce merchants and direct billers. First, let's start with terminology:

• The "authenticating bank" in SVP is roughly analogous to the card issuing bank. It's where the customer keeps "good funds" - typically in a checking account. The authenticating bank is responsible for obtaining the buyer's payment authorization, pushing the payment to the merchant, and handling all customer service issues.
• The "sponsoring bank" in SVP is similar to the merchant acquiring bank. This bank holds the merchant's settlement account (similar to the "merchant account" in card payments), "vets" merchants into the SVP system, and helps reconcile expected to actual funds received. The sponsoring bank also forwards any service-related chargebacks on to the merchant. Of course, with SVP, because funds are pushed, there are no fraud chargebacks.
• The role traditionally played by the card companies (rules, branding, and switching) is split between NACHA (rules and branding) and eWise Systems (transaction switching). Unlike the world of cards, there is no net settlement managed through the "hub". Instead, funds are simply pushed from authenticating banks to sponsoring banks using ACH. Only settlement data flows through the switch.

When everything works, the result is a successful "vault" transaction.

How Secure Vault Payments works

The consumer goes to a website (ecommerce retailer or online biller) and selects "Secure Vault Payments" as the payment method. Secure Vault Payments is another payment acceptance mark alongside Visa, MasterCard, PayPal, and others.

Inside the checkout flow on the website, an intelligent widget prompts the consumer for the name of their bank and autofills the full name. For example, as the user types W-E-L, it dynamically expands to Wells Fargo Bank, N.A. The widget recognizes trademarks and common nicknames - WaMu expands to Washington Mutual, etc. The user verifies their bank name, clicks okay, and is redirected to their bank for login.

In the background the merchant sets up the SVP transaction with eWise, gets the correct web address for the authenticating bank, and then redirects the user in their web browser to their authenticating bank - passing along to the bank's website the necessary transaction data. NACHA has clearly thought long and hard about how this should work and has made significant strides from the original vision of just presenting to the consumer a "raw" pulldown of participating banks.

At the authenticating bank website, the consumer uses their existing online banking userid/password credentials when they are presented with a login screen that is similar, but not identical to their normal online banking login screen. It is not identical because the current SVP rules do not allow the authenticating bank to use the purchase authorization step to cross-sell other banking products to the consumer or to let the consumer wander off into the broader online banking environment. The consumer, after all, is logging in to authorize payment, not to check today's interest rates. Presumably the authenticating bank will be using their existing two-way authentication methods to prove the authenticity of their website to the consumer to prevent successful phishing attacks.

Once authenticated by their bank, the consumer selects their funding source and clicks on "pay". But there's a little bit more to that as well. The consumer has access to any funding source that is tied to their online banking environment -- which could include their checking account, their savings account, or any available credit lines.

In addition to giving the consumer the option of selecting a funding source, the authenticating bank also shows the available balance or credit line for each alternative. This gives the consumer clear insight into their current debit and credit positions, and may lead to a more deliberate selection of funding source. Knowing how much money you actually have to spend might be a pleasant surprise, and may drive higher levels of spending if NACHA can work out an easy way to go back and forth between the checkout process and the payment step. It's conceivable that some consumers will opt to purchase more once they see how much money they have available.

Back to the transaction flow. After selecting "pay" the authenticating bank provides a real-time purchase authorization back to the SVP switch. The consumer is then seamlessly redirected back to the merchant site. Behind the scenes, the merchant checks with the switch that a proper authorization has been completed, provides a receipt to the consumer, and ships the goods. Funds are pushed overnight via ACH from the authenticating bank to the settlement account at the sponsoring bank, and then, if required, pushed again the next night via ACH from the sponsoring bank to a revenue account at the merchant's primary bank.

SVP authorization fees, payable to the authenticating bank, are deducted from the settlement amount paid to the merchant, as are various NACHA fees. Sponsoring banks are also free to markup the acceptance service they provide to merchants and billers. NACHA publicly announced the SVP fee structure in 2007.

Glenbrook's Reaction

NACHA is positioning Secure Vault Payments as an alternative payment system, like Google Checkout or PayPal, but one that has been developed by the banking industry.

At a high-level, this positioning makes good sense. SVP is a new way to reach and enable consumers that are not comfortable giving their payment data directly to merchants and billers to pay online. The basic transaction flow does not ride existing card payments "rails" and requires merchants (and their processing partners) to integrate a new payment system into their checkout flow. SVP is a new payment method that needs to be reconciled, a new payment method for customer support to handle, and a new payment method for merchants to risk manage. (Even with payment "guaranteed", merchants will still need to risk manage vault transactions.) If banks in the US ever wanted their own alternative payment system, they've got one now - thanks to NACHA!

We've also heard some concerns about Secure Vault Payments potentially adding too much friction to the checkout flow. We don't think that will be an issue. The SVP transaction flow is not really materially any different than the PayPal transaction flow, with the consumer redirected out of the checkout process to authenticate the purchase and select a funding source. The wallet-like functionality in SVP may actually streamline the payment process when compared to directly entering DDA bank routing and account information at the merchant or biller website.

Given the NACHA pedigree, it's also interesting that Secure Vault Payments makes such minimal use of ACH. ACH is not used for anything more than moving funds between parties after the fact. Of course, that's exactly what ACH was designed to do, so it's refreshing to see something actually used for what it was intended and not artificially taken in a direction it was never designed for.

As a payment system, Secure Vault Payments really is an entirely new animal. Push payment systems have been around for years in other countries around the world. We know they work and are popular with consumers - but this is the first time the banking industry in the US has defined such a system for consumer payments. The big distinguishing characteristic of SVP is not that it is push payments, but push payments with both the real-time authentication of the consumer by their bank and known availability of good funds. That means merchants can ship goods right after purchase has been completed, without fear of fraud-related chargebacks, knowing that good funds will arrive in two days.

In spite of these strengths, it’s certainly not a certainty that Secure Vault Payments will gain sufficient traction in the short term. The well-known chicken and egg challenge of payments is still alive and well -- before consumers can buy or pay using SVP, their bank has to integrate and offer the option. At Glenbrook, we've long advocated that new payment systems target enablers before going to market in a big way, and that's what NACHA seems to be doing. NACHA has completed integration deals with leading online banking platforms such as Metavante, Fidelity and Jack Henry. By removing the technical hurdles financial institutions may face when integrating SVP, joining the payment network becomes a business decision on the part of the bank. We'll be measuring early progress by the number and type of enablers that continue to sign up to support Secure Vault Payments on behalf of their bank customers.

NACHA also has an opportunity to segment its go-to-market strategy among eRetailers, billers, and government. Different markets, different payment economics, and different adoption drivers. Specific category pricing, for example, has already been established for these three categories. Secure Vault Payments just went live in Q2 2008, and early results seem to show there is traction in the education market. Perhaps major universities can encourage their banking partners to adopt SVP in order to better support tuition payments.

At Glenbrook, we're going to be thinking some more about Secure Vault Payment economics. For authenticating banks, SVP might turn some bill pay transactions (that are currently an expense to the bank) into vault payments (that earn the bank revenue). Billers, we suspect, are also going to find the SVP pricing model interesting when they factor in what they are already spending to manage ACH exceptions, NSFs, and the other back office costs associated with pulling money via ACH. Good funds matter - and SVP provides that "glue".

Perhaps the real story here turns out to be that the industry took their eye off the Secure Vault Payments ball too quickly. While most were thinking SVP was yet another online payment method for eRetailers (with little economic incentive compared to signature debit), it just might turn out to be a valuable payment method for online billers.

---

Comments?

---