The payments data illusion

Payments data is not that useful beyond payment processing

A message to my subscribers:

I realize my posts may be a grind to get through at 8-10 pages each. I just don’t seem to be able to write short posts. I always include a Key Insights section at the end to summarize the takeaways, but you may never have made it that far to find it. Going forward, I am moving the Key Insights section to the front of each post. Those pressed for time no longer need to slog through all my precious detail. If time allows I will reorganize all prior posts, so you can easily curate the ones relevant to you.

Key Insights

• Both incumbents and insurgents have claimed that payment message data is a valuable asset — most often to justify synergy in a merger or acquisition

• The emergence of AI has amplified these claims, as AI assumes more data is always better than less data

• Payment messages have little content useful beyond authorization, clearing and settlement of payments. That is true for both Card Messages (ISO 8583) and ACH messages

• Payment messages have a poor record in analytics use cases as they lack SKU

  • Useful in fraud detection, although identity solutions are more effective; performance improves when supplemented with merchant SKU data

  • Uninspiring for Offers; without SKU they are useless to the big CPG marketers and of limited value to retailers

• Payment message data is not proprietary to any one party

  • 3+ parties see every message just to authorize, clear & settle the payment

  • Increasingly accessible to third-parties via Open Banking

• Message data is subject to privacy concerns and the “creep factor” if not used transparently

Introduction

This topic is a pet peeve of mine. I often see payment companies announce their intention to use card transaction data for some non-payments purpose, like marketing or offers. This rarely works, but the announcements keep coming. They have gotten worse with the rise of AI, with the assumption that all data is useful data.

Unfortunately, card messages are not that useful beyond card processing: They lack SKU-level information, their content is not proprietary, and proposed use cases may conflict with privacy restrictions. ACH messages face the same challenges.

Card messages lack SKU-level data

All card transactions use the ISO 8583 message format — which typically includes only the essential data for clearing and settlement. The longest field is the transaction description that appears on the customer statement. The rest is mostly codes representing the merchant ID, account number, acquiring bank code, transaction types, etc. The message also includes the amount, date and time, etc.

An 8583 doesn’t contain anything about what was purchased, i.e., SKU data. In card-speak, SKU data is called “Level 3 data”; Level 3 is commonly used in commercial products such as Purchasing Cards; however, it is rarely used for consumer transactions.

Most consumer-focused merchants won’t share Level 3 data because they don’t want competitors or third parties to see their detailed sales. For example, when MasterCard bought the data analytics firm Applied Predictive Analytics (APA), one limitation on the purchase was that MC couldn’t co-mingle the SKU-level data from APA with general MasterCard transaction data — It had to be kept at arm’s length. Private Label Credit Cards do get SKU data but have contractual limitations on its use. Similarly, online installment lenders, like Affirm, get SKU to use in underwriting. When shared, SKU data can only be used on behalf of the merchant it came from.

Without Level 3 data, most “offers” or marketing use cases are not compelling. Cardlytics (CDLX) has tried, but the results are uninspiring. They had a great idea: Distribute merchant offers to consumers via banks and cards. Banks target the offers using their customer demographic data, but that data is never seen by the merchant. Instead, offers are redeemed when the associated payment card is used at the offering merchant. Most major banks are members of the Cardlytics network – so the offers can reach most banked consumers.

For example, if a customer showed a pattern of fast-food purchases, they might be presented with an offer for 5% off on their next visit to a particular QSR. Redeemed offers get a statement credit, which does not show on the receipt.

The challenge is that card data can reveal the frequency of customer visits to a merchant or merchant category (MCC), and it can tell you how much they spent, but it can’t tell you what they bought. The SKU limitation reduces the pool of offers and makes those offers too generic:

• Without SKU, CPG manufacturers can’t make offers. CDLX doesn’t know if someone visiting a drug store bought toothpaste, let alone whether it was Crest or Colgate. In QSR, you know they bought food, but you don’t know what items

• Without SKU, offers are only at the merchant level: x% off the entire purchase or y% off the next purchase. It is an incentive to visit the store, but can’t be targeted to specific products

• Without SKU, targeting is crude. A large share of consumer spend is at retail giants like Walmart, Target, Costco or Amazon that sell a wide assortment of merchandise. What do you know about a customer that spent $100 at Amazon? They could have bought anything from groceries to electronics to clothing. Almost everyone shops at those merchants, so their payments data provides limited insight for customer targeting

Cardlytics is run by smart people, and virtually the entire banking industry bought into the concept – including me. Despite near-universal bank coverage and wide merchant distribution, CDLX has annual gross revenue of ~$300M and a market cap under $250M. It has not turned a profit in recent quarters. In other words, the financial markets have valued payments data for marketing purposes at under $250M.

Payments data is useful for fraud detection, but is a second best option

Payments data is used effectively for fraud detection. One of the earliest applications of AI techniques that I can recall was the HNC Falcon (issuing) and HNC Eagle (acquiring) neural networking software.  These solutions are part of Fair Issac today.  Virtually every large card issuer and acquirer installed that software to detect fraud. Another early example was American Express’s “Authorizers Assistant” tool that helped a human approve gray area transactions.

Today, AI-based ancestors do an improved job. For Example, Riskified’s tag line is “Building a safer ecommerce world through the power of AI”; Riskified’s competitors like Signified and Accertify do the same kinds of analysis. Visa’s Cybersource is a more venerable solution addressing the same problem. All of them examine a card transaction, supplement it with merchant data, and advise on whether to approve it. Solutions of this kind are essential to keeping bad guys out of eCommerce.

Notably, all these solutions work for merchants who do share SKU, but that data cannot be used beyond the merchant’s own needs. The only data that leaves the merchant is the standard 8583 message.

Outside eCommerce, the industry did not defeat card fraud using payments data or sophisticated analytics. PIN Debit was always more secure than Signature Debit because the customer had to enter a PIN. The PIN generally the customer holding the card owns the card. “Everyday spend” merchants steered to PIN debit to keep costs down. More recently, the industry added EMV chips to all cards and EMV readers to all POS devices. EMV reduced POS fraud by 75%+ -- with most of the remaining fraud from cards with no chips or merchants with old, non-EMV hardware. Data had nothing to do with it.

A similar phenomenon is happening online. At JPM I did a detailed study of online fraud for Apple Pay transactions. Fraud levels were barely above zero. When there was fraud, it was generally because a crook had socially engineered someone in the value chain to gain control of a consumers mobile number. How does Apple Pay kill fraud? All transactions are biometrically authenticated. The card networks have tried to reduce online fraud with PIN numbers, but consumers and merchants resist the added friction.  Many merchants do ask for the CVV number, which proves the buyer has the card in hand — and again, does not rely on data analytics.

So, payments data is critical for fraud prevention, but it is not the best solution. Being able to authenticate the consumer and the card is more effective.

3+ parties have access to the same payments data

The whole point of the 8583 standard is to allow all parties in the value chain to process it.  In addition to the merchant, the transaction is seen by at least 3 intermediaries.

• The acquirer sees every transaction processed by its merchants; but, acquirers don’t know anything about the cardholders so it is hard to use that data for marketing analytics; the biggest merchants have 2+ acquirers for redundancy, so even the primary acquirer only sees a fraction of the total volume

• The network sees every transaction processed by cards that carry its brand. However, networks know little about merchants or cardholders. The patterns they see are useful for fraud pattern detection, but lacks demographics on either end for targeting. Even the biggest network only sees 60% of market volume

• The issuer sees every transaction from their cardholders, but even the biggest issuer touches only ~25% of industry cardholders and may not have all their activity. Most issuers have under 10% share of cardholders. Issues also have limited insight into merchant demographics.

Other intermediaries might sit in the value chain, such as ISVs at the merchant end, wallets at the consumer end, processors behind either the issuer or the acquirer, and various kinds of gateways. They all see the same 8583 message content.

This is somewhat like the parable of the blind men and the elephant [look it up]. Every member of the value chain sees the same data on a fraction of the total transactions. And all of them think that data is proprietary. Nobody has a comprehensive data set, and, as we saw, even if they did, the data is of limited utility.

The networks have the most data – Visa alone sees ~60% of transactions. But despite deep investment pools, they have no “data” business. It is not for lack of trying, but lacking meaningful insight on cardholders or merchants, all that transaction data is difficult to monetize.

Amex does see the end-to-end transaction data and has consumer demographics, but it also lacks a meaningful data business. It has Amex Offers, but that is not big enough to disclose in public financials. And after it spun out its small business acquiring in Opt Blue, it no longer has direct links to smaller merchants. The bigger merchants that Amex directly acquires are least likely to share SKU.

Amex owned the Accertify fraud service for 15 years, but that was spun out early in 2024 – indicating a lack of synergy with the mother ship. In its press release, Amex said: “American Express will continue to operate its own industry-leading fraud prevention programs, which consistently achieve the lowest U.S. fraud rates among major card networks.”. So Accertify was not for Amex’s internal benefit, but solely a service for merchants.

Privacy constrains some use cases

A very creative Fintech executive I know found a way to capture SKU data at his merchants. He was planning to approach CPG companies for an offers opportunity through his platform. We asked whether that would be welcomed by cardholders. He said it is a fine line between delight and the “creep factor” when you use consumer data without advance customer permission.

This is not limited to payments data. Apple’s App Tracking Transparency program (ATT) of the last few years requires IOS Apps to get formal permission to use a consumer’s data for targeted ads. It is opt-in rather than opt-out. Apple’s rules require clear consent, not implicit consent:

“You must use the AppTrackingTransparency framework if your app collects data about end users and shares it with other companies for purposes of tracking across apps and web sites. The AppTrackingTransparency framework presents an app-tracking authorization request to the user and provides the tracking authorization status.”

Many consumers did not opt in. This reduced the valuation of many ad-based online businesses, including Facebook. The lesson is clear: consumers are uncomfortable with such marketing efforts and may not participate when given a choice.

Washington is also concerned about the storage and use of consumer data given the risk of data breaches and misuse. The Cambridge Analytics saga and the Equifax breach are two examples that heightened concerns.

So even if payments data had better content, using that content might be challenging.

Open banking will make the data widely available

Finally, payment transactions are about to become a “commons”. The CFPB just published final “1033” regulations for Open Banking:

“Transaction information, including historical transaction information in the control or possession of the data provider. A data provider is deemed to make available sufficient historical transaction information … if it makes available at least 24 months of such information.”

These regs largely codify the commercial terms that banks and data aggregators already agreed to: The customer can give permission to a Fintech so that an aggregator can lift data out of a bank account or card account – but the Fintech must be transparent about what is taken and use it only for the disclosed purpose. The Fintech must also secure that data.

Notably, 1033 is limited to products subject to Reg Z & Reg E, in other words, Credit Cards and DDA accounts.

That means third parties can see payment transaction data if they can convince a consumer to let them. This is not new: products like Mint.com have been around for years. Mint’s proposition is: “Link your accounts from more than 17,000 financial institutions and view your connected transactions across them in one place.”  Third parties have been lifting such data for a long time, but generally using screen scraping rather than APIs.

The emergence of API technology has accelerated adoption of data aggregation to reduce onboarding friction, provide advice, compare prices, etc. Few of these use cases analyze basic payments message data to improve outcomes – because there isn’t much insight to uncover.