Monkey Bytes: A collection of Curated Commentary

PANs and the Magstripe

I was doing some research into magstripes and some of the innovative security features that have been applied over the years to frustrate the fraudsters. You can read about the security features on the page about Magstripe Security Features on the website.

Here is something that I hadn’t seen before, though it has been sitting in my card collection (yes!) since we connected Link to 4B in Spain and SIBS in Portugal. It’s interesting, so I thought I would share.

You can see for yourself that the PAN embossed on the front of the card is not the same as the one encoded in the magstripe. The magstripe encodes for the BIN, but that’s needed for routing, followed by the Woolwich Account Number, then a delimiter (“=”), the Expiry Date and a second delimiter. I wonder if the Luhn check digit is being used on the magstripe PAN, which would mean linking the account number generation algorithm to the BIN, but that wouldn’t be unheard of.

As far as I can tell from ISO 7813, the second delimiter a non-standard data structure, but ATMs are generally only interested in the data up to the first delimiter, and you can turn off the Luhn check in the FIT table.

It worked in the ATM at the airport in Alicante, and I got the cash, but …

There are lots of anomalies and nuances in card transaction processing that get overlooked or even ignored as most payment professionals operate primarily across the business and UX layer rather than the application layer.

Sometimes we get away with it.

Following a standard approach means that features are future proofed against updates that could eliminate or restrict the usability gained from choosing the non-standard approach. Tesco experienced the impact of following a non-standard approach with the Finest Credit Card.

However, we can only follow the standard approach IF we know what that standard approach is and we understand how it all fits together – sadly, many of us do not!

See the LinkedIn post here.

Payments are complex

It’s not until you lift the lid on the reality of payments that you realise just how complex they are. I’m not just talking about the trickiness of getting the authorisations to work, although lifting the lid for troubleshooting has become increasingly difficult with E2E encryption. I’m really talking about how aligning payment system logic with business logic goes over the heads of many: “It’s only a payment, how hard can it be?”

It goes over the heads of most business people, it goes over the heads of most payment people, and it certainly goes over the heads of people selling payment products and services to people buying payments products and services, and often the differentials are subtle. Usually, by the time the true nature of the logical misalignment between business needs and payment capabilities becomes evident, the cash has changed hands, payment solution bought and sold, job done!

If people were to think before they do, do due diligence and then review, down the road problems would be avoided, but we don’t need to do that do we? Payments are easy, aren’t they? How hard can it be?

Read the full LinkedIn post here.