Why card statements are so hard to read

Card statements look like they were designed for a mainframe because, in a sense, they were. The text you read travels inside a payment message whose layout was fixed decades ago, when every byte cost money. Almost every oddity on a statement comes from five pressures: a fixed-width field, a provider in the middle, a city squeezed into a code, a bank adding its own words, and nobody being responsible for how the result reads.

1. A name and a place share forty characters

Card payment messages follow the ISO 8583 standard, and the merchant's name and location travel in a single field, number 43, "card acceptor name/location". In the common layout it is forty characters wide: roughly 22 to 25 for the name, 13 for the city, and a short country code at the end. Networks and acquirers differ in the details, but the budget is always tight.

INTERNATIONAL HOUSE OF MOHAMMED BIN R AE

INTERNATIONAL HOUSE OF

The name filled its 22 characters. Whatever came after "OF" is gone, and the merchant is now a guess.

MOHAMMED BIN R AE

"Mohammed Bin Rashid City", cut to thirteen characters, then the country.

The cut is mechanical. It does not stop at a word boundary, so you get "SUPERMARKE", "PHARMAC" and "RESTAURAN". Spaces and punctuation count as characters too, which is why so many merchants drop them: "MCDONALDS", "ALMAYA", "TALABATUAE".

2. A payment provider takes part of the name

Small businesses often take cards through a payment facilitator: Square, PayPal, Stripe, Paymob, Geidea and many others. The facilitator is the merchant of record as far as the network is concerned, so it gets to write the line, and many put their own name first: SQ *, PAYPAL *, TST*. Those characters come out of the same tight budget, leaving even less room for the shop.

Marketplaces add a second layer. A purchase on Amazon from a third-party seller can read "AMZN Mktp" with no seller name at all, because the marketplace, not the seller, took your money. We wrote a separate guide to these prefixes.

3. Places become codes

Thirteen characters do not fit "Dubai Festival City", so the city field fills up with shorthand: airport codes such as DXB, AUH and CAI; mall initials such as MOE and DFC; district names; and sometimes a branch number. Country codes come in two-letter (AE) and three-letter (ARE) forms, and some providers put a phone number or a website where the city should be.

The result is that the end of a line is full of words that are real but not part of the merchant's name. Reading them as names is the most common mistake people and software make. "SHELL 1043 KARAMA" is a Shell station in Karama, not a company called Shell Karama.

4. Banks add their own words

Your bank decorates the line it received. Common additions are a transaction type (POS, PURCHASE, E-COM, CONTACTLESS), the last digits of the card, a date or time, a reference number and, for foreign purchases, the original amount and exchange rate. Each bank does it differently, so the same purchase reads differently on two people's statements, and the same bank can change its format when it moves to a new system.

PURCHASE 14/10 CARD 9921 CARREFOUR MOE DUBAI ARE REF 774120

PURCHASE 14/10 CARD 9921

The bank's own words: type, date and card.

CARREFOUR

The merchant.

MOE DUBAI ARE

The branch (Mall of the Emirates), the city and a three-letter country code.

REF 774120

A reference number, useful when you call the bank, meaningless otherwise.

5. Nobody owns the result

The merchant sees its own name in a dashboard, not on your statement. The provider optimises for its own fields. The network carries bytes. The bank prints what arrives. Nobody in the chain reads the finished line the way you do, so nobody is accountable for it being readable. Merchants who do care can set a clearer descriptor with their provider, and a few add a phone number or website for exactly this reason, but most never change the default.

What actually helps

• Read from the front. The merchant's name comes first, after any bank words and provider prefix. Words near the end are usually the branch or place.
• Expect missing endings. If a word looks cut off, it probably is. Search for the beginning of it.
• Use the amount and date. They narrow things down faster than the text does: check your email and app receipts from that day.
• Let software do the first pass. Paste the line into the playground; it shows which part is the merchant, which is the provider and which is the place.

If you build products on transaction data, the same five pressures are why a list of merchant keywords breaks in production. Our build-or-buy guide covers what that looks like over a year.