As I sit down with my coffee this morning I’m asking myself what are the key questions to answer:
- What is the Plaid service? What innovation have they created?
- Is it a threat to V/MA?
- What merchants/Consumers will use it?
- What do banks think of this? Can they stop it?
What is Plaid Payments service?
Per yesterday’s WSJ article, Plaid is rumored to be creating an ACH payments service to support Stripe, Square and others. In January 2019 Stripe and Plaid collaborated on a 0.8% (80 bps) ACH payment service that is available to Stripe’s customers today (see article). In this model PLAID provided the account ownership/authentication and stripe managed the transaction risk/ODFI relationship.
There are 2 big options on what is going on
- Plaid is expanding its API set and back-end to create a white label (turn key) Pay By Bank Service (independent of Stripe) with risk data integrated from a new partner (ex PayPal)
- Plaid is a partner in a new bank service – Either RTP or Pay with Zelle for eCommerce Transactions.
This later one could indeed be a threat to V/MA. Given that Money2020 is next week, my guess is that we find out by Tuesday.
As I related previously, top merchants have been itching to create a new payment scheme based on decoupled debit (ie MCX). Banks have also been working to create a new mobile payment scheme for the last 12 yrs (see TCH/RTP and Payments Civil War).
If it is a bank service (option 2), the banks will be shooting for pricing at a premium to debit (think 200bps). To achieve this banks would have to give on CNP fraud and holdback. A top 3 US retailer told me “there is no way we are paying a premium to debit.. We have managed fraud down to 3 bps and are not going to encourage consumers to adopt another payment instrument with unknown rules and decision making.. V/MA are the devil we know”.
Pay by RTP/Zelle makes sense, but the logical partner is not Plaid, it is Stripe. Neither TCH (owner of Akoya) nor Early Warning (owner of Zelle) needs account ownership verification (Plaid’s central service). So either Plaid accidentally jumped the gun and leaked something they shouldn’t have. Or pay by bank is a new organic service not related to bank efforts.
Today’s blog will thus be focused on Plaid’s challenge in creating an organic Pay by Bank without Bank support. If it turns out to be a bank service then the banks will work with all partners integrating eCom merchants.
What are Plaid’s innovations?
- They have done a great job at creating a ubiquitous API set and access to almost every US bank (via screen scraping).
- APIs for businesses in need of account verification. 2 Years ago, PayPal was Plaid’s biggest customer, using their service “instantly” tie bank accounts to PayPal.
- Definition of services and standards to access bank information (ie FDX). Prior to Plaid every bank had their own format and access mechanics, as the old OFX standard developed by Microsoft and Intuit died with the PFMs (see blog).
- Plaid “doesn’t store data”. It gets bank data every time it is requested, with one big exception: your banking login and password. Most consumers (like me) didn’t realize that Plaid kept your bank login credentials and continued to feed PayPal your balance information daily/weekly.
- Partnerships. Banks are terrible at partnerships. Plaid is not… start ups that need bank integration have an easy choice: deal with Plaid or 3,000 separate banks that will EACH take 3 yrs to make a decision.
- An ODFI that has accepted Plaid’s fraud controls and is willing to bet their bank license on initiating these payments.
- Perhaps a new risk data source (ie PayPal).
What does Plaid still need?
- Bank support. With no shared value, no direct integration and a “competing service” that cannibalizes V/MA revenue Plaid is playing with fire. Banks are working to get Zelle accepted in eCom and also to get their own RTP service running. I can’t imagine US banks getting on board with this. If I were Plaid I would focus on another geography.
- Direct Bank Integration. As of 12 months ago, PLAID had 100% screen scraping with top banks and less than 5 banks directly integrated (see my old blog). Today the top banks are telling PLAID that they must source the data from Akoya (see blog), and Akoya/Bank integration is being completed this quarter.
- Bank agreements/revenue share terms. I’m not aware of a single bank that has economic terms established with Plaid. Why do Banks allow Plaid to scrape? The general response is “we want to support services our consumers value and recognize that account data belongs to the consumer”. The “bank agreements” that Plaid has are few and related more to privacy/consumer protection (no shared economics). For example, a top 3 bank found that cyber criminals preferred to use the PLAID APIs to test bank credentials, that bank had white-listed PLAID scraping bot (to the amusement of the cybercrooks). The bank had to push through risk/fraud controls for PLAID to keep the connection.
- Consumer permission to store and use bank credentials for EACH service.
- Consumer and Bank permission to use banking data for a given service. Permissioning and use is complex. Not only does Plaid need to track where bank data is being used, but HOW. The banks insist on having a “kill switch” for each service supported by Plaid, and some level of DD on each requestor.
- A Tier 1 ODFI. If the current ODFI initiates daily payments that are a significant portion of their total assets there is an issue for other banks processing these requests.
- Merchant holdbacks/risk integration. Most consumers are more concerned about their CC PAN than their ACH account number. Today’s bank ACH risk systems and merchant/ODFI risk platforms are not tuned to eCommerce transactions. PayPal is by far the leader here. PayPal does hold a stake in Plaid, and PayPal has been looking to monetize their risk engine.. If Plaid is able to use the PayPal risk engine for ACH Pay by Bank it would be truly unique.. But that doesn’t mean the banks will support it.
Is this a threat to V/MA?
Pay by Bank has been available through Stripe/Plaid since Jan 2019. While there are merchant incentives to have consumers pay this way (80 bps), there is no consumer incentive. In the US Reg Z consumer protections on use of credit card are complete and well understood.
V/MA also settle on ACH (blog), but over the last 60 yrs they have built deep integrations into the banks and created a shared economic model that incents consumers, banks and merchants to participate. Visa/MA are a network with rules, consumer protections, service agreements, security standards, underwriting, certifications. Each member of the network is a licensed bank with ability to assume and manage risk.
Will consumers use it?
Payment adoption is driven by frequency of use: eCommerce/marketplace, grocery, gas and transit are all areas where new payment methods have developed. Changing consumer behavior is very very hard (ex US contactless use) and typically takes a 20% “value” change.
US consumers understand Bank bill pay and would rather initiate recurring ACH through their bank in order to avoid managing each individual merchant billing against their transaction account. In other words there are no incentives for either Consumers, nor enough “value” to move intermediaries.
Internationally, Pay by Bank has seen success in markets like Germany (Sofort now part of Klarna) and currently Australia’s central bank is pushing this scheme in NPPA. India’s effort UPI is by far the most advanced, with the central bank acting as the “PLAID” and providing the regulatory framework to force all banks to adopt (see blog). BNPL is a far greater threat to V/MA than PaybyBank. Whereas BNPL improves both conversion and the size of the funnel (underwriting/qualified customers), Pay by Bank has only a merchant value proposition.
Let me attempt to make the Plaid bank pitch:
- We understand you have other things you would like to have in place like RTP and Pay with Zelle.. but we want to create something too.
- We are going to allow your customers to initiate payments from their accounts with you by using their bank credentials. We will log in, verify address and amount in account. You don’t need to do anything .. (other than handle customer complaints and fraud)
- We won’t pay you anything, but hey your customer asked for it.
- Sure the customer could have used their debit card to do this, but then the merchant would have to pay you.. This way they only pay us.
- No we don’t really have a fraud/risk engine yet, but we convinced our ODFI that your account had the money and we’re really not concerned about fraudsters having both account number and bank credentials. If they do.. hey thats your problem.
- We are not really great at telling you when we are going to scrape for authorizing a transaction vs scraping to fill in data for Mint, so please just allow it all.
- Why are we doing this? Well because it is possible.. Don’t be concerned.. We convinced the customer to do it and you don’t have a problem with that right?
Banks are well positioned to block account access, deny ODFI transactions, reverse ACH payments (60 day window). and educate consumers of risks.