Reforming Retail

How Privacy Laws and Payment Acquirers Are Screwing Offline Merchants

If you’ve had the misfortune of following privacy laws you’d understand why the largest technology companies actually love them:

They’re complicated as hell, expensive to follow, and benefit those with resources and political clout.

There’s perhaps no more prominent privacy law than GDPR in Europe, which in our view is tantamount to a nothing-burger but boy does it incur a lot of costs. How much? Well, if you extrapolate from a few quotable figures, it’s likely in the tens of billions of dollars when you start accounting for the long tail outside of the world’s 500 largest corporations.

The real asymmetry with privacy laws is between offline and online merchants, where the former is at a distinct advantage to the detriment of the latter.

With online transactions the consumer is entering their contact information. To decrease payment costs, merchants typically ask consumers for their address (called AVS, address verification, in payments parlance) in addition to their name and card information. The merchant will also collect an email for a receipt, and the smarter ones are grabbing phone numbers for “order status updates”.

All of this means that online merchants are obtaining customer consent for marketing purposes, appending this data to build more robust customer profiles and to better understand information that will lead to improved marketing ROI.

In the offline world, there’s a lot less to work with. We’re going to get in the weeds a bit here, but do follow along.

When a customer pays with a credit card offline, there are three tracks of data on the magnetic stripe. These are referred to as Track 1, Track 2, and Track 3 data. All that we need to be concerned about for the purposes of this article are Track 1 and Track 2 data.

Using Wikipedia we can get a good summary of the different tracks and what data is contained therein.

Card readers (ie terminals) almost always read Track 1 or Track 2 data, and sometimes they read both in case one track is unreadable. The minimum cardholder account information needed to complete a transaction is present on both tracks.

Track 1 has a higher bit density (210 bits per inch vs. 75), is the only track that may contain alphabetic text, and hence is the only track that contains the cardholder’s name. Here are the fields in format B of Track 1:

  • Start sentinel 
  • Format code=”B”
  • Primary account number (PAN) 
  • Field Separator 
  • Name 
  • Field Separator 
  • Expiration date 
  • Service code
  • Discretionary data 
  • End sentinel 
  • Longitudinal redundancy check 

Track 2 was developed by the banking industry (ABA). Track 2 is written with a 5-bit scheme (4 data bits + 1 parity), which allows for sixteen possible characters, which are the numbers 0-9, plus six characters. Track 2 data is smaller and sufficient to complete a transaction – keep this in mind as we get to our next section.

  • Start sentinel
  • Primary account number (PAN)
  • Separator 
  • Expiration date 
  • Service code
  • Discretionary data
  • End sentinel 
  • Longitudinal redundancy check 

Track 2 data is the prioritized track for authorization. That means if a processor can only grab one type of data they’ll grab Track 2. Track 1 data by itself can lead to a downgrade, resulting in higher payment rates for the merchant (which a lot of processors don’t have a problem with since it’s much more lucrative, but it’s bad practice and payments consultants will fix the issue). Merchants are neither required to store nor print customer names on receipts to satiate the card brand rules, making processors even less likely to send cardholder names to software providers like POS systems.

Thus many processors prefer Track 2 for the simple reason that it contains less data and the payload is therefore smaller.

That’s well and good, except a processor won’t get cardholder name from Track 2 data. Few processors will bother parsing Track 1 data for cardholder name to concatenate with Track 2 data, totally neglecting to capture this information. If they do capture it, point to point encryption, a “requirement” due to the ruse that is PCI security standards, often means that the processor won’t pass this data to software partners in order to keep software companies “semi-integrated”, a euphemism for data-impotent since cardholder name has nothing to do with PCI garbage.

It’s true that payment device manufacturers could share some of this blame, as they can also control what card data gets passed to an integrated software partner, but the certifications for device applications are done with the processors, and we’ve yet to hear of a processor asking a device manufacturer to build an app that makes cardholder names easier to collect.

The problem this creates for offline merchants is that the processor will now only share the last 4 digits of a card and no other identifying information. So while online merchants are getting virtually every useful piece of data on their customers, traditional merchant acquirers can’t be bothered to collect better customer data “cuz it makes the data bigger”. That’s like refusing to store historical data “cuz it costs more than $0”.

Except anyone with a modicum of intelligence knows that historical data offers all sorts of optionality to build and train new data models, some that you undoubtedly can’t think of today, so data should absolutely be stored. It’s not like data storage costs are going up either – on average data storage costs are decreasing by 30% a year.

Tying back into privacy laws, dumbass legislation like GDPR implicitly disallows the sharing of customer information from offline transactions because the customer isn’t even given an interface to opt in, but of course it’s perfectly fine to collect it for online transactions.

It’s like the world is colluding against offline retailers.

Privacy laws are hard to change because political careers are built on nonsensical mandates that keep voting bases appeased for the next election cycle, but there’s nothing that prevents us from holding processors responsible for their ignorance here. Who knows if this is willful ignorance, but it’s just another black eye for an industry that’s been begging for class actions on counts of fraud for years.

Add comment

Archives

Categories

Your Header Sidebar area is currently empty. Hurry up and add some widgets.