How to read a bank statement descriptor: prefixes, merchant names and codes explained

Every charge line on your statement — the descriptor — is assembled from parts, and once you can name the parts, most "mystery" charges stop being mysterious. This is the anatomy lesson: who writes each piece, what it tells you, and how to dissect any line in seconds.

Who actually writes the descriptor

Not your bank, mostly. The merchant registers a billing name with its payment processor; the processor may add its own prefix; the card network passes it through; and your bank may prepend its own transaction labels (POS DEBIT, CHKCARD, VIS). By the time the line reaches you it's three parties' shorthand concatenated into ~25 visible characters.

The anatomy, piece by piece

Take a typical line: SQ *BLUE BTTL 0412 SAN FRANCISCO CA

• Processor prefix — SQ * means Square processed it. Prefixes are the highest-signal fragment because they're standardised: PAYPAL */PP* (PayPal), TST* (Toast — restaurants), APPLE.COM/BILL (App Store billing), GOOGLE * (Play/Google services), AMZN MKTP (Amazon marketplace), WL * (Worldline), IC* (Instacart), and dozens more — each catalogued with reliability notes in the prefix guide.
• Trading (DBA) name — BLUE BTTL: the merchant's registered billing name, usually truncated and often different from the brand on the door. This is the piece you're really trying to identify.
• Store/reference number — 0412: outlet number, terminal ID or order fragment. Useful for the merchant's support team; noise for you.
• Location fragment — SAN FRANCISCO CA: sometimes the purchase location, but for online and chain merchants it's frequently head-office or the processor's registered city. A city you've never visited is not by itself evidence of fraud.
• Contact fragment — many descriptors carry a phone number or bare domain instead of a city. That's the merchant inviting you to contact them before disputing — use it.

Bank codes vs merchant descriptors — two different puzzles

Fragments like DD (direct debit), SO (standing order), FPO/FPI (faster payments), ACH, PPD, ATM and INT describe the payment mechanism, not the merchant. They come from your bank's side and answer "how did the money move?" — helpful context (an ACH/PPD pull means a company you authorised is debiting you), but the merchant identity still lives in the descriptor text beside them. Our statement reading guide covers the code families in full.

Why descriptors get mangled

• Length limits — the standard field is painfully short; words lose vowels and endings.
• Legal vs brand names — the cafe you know may bill as its owner's registered company.
• Soft vs hard descriptors — the pending (authorisation) name and the posted (settlement) name can differ; judge the posted one. More in the pending charges guide.
• Aggregated billing — app stores and platforms bill many services under one descriptor; APPLE.COM/BILL is the canonical example.

The dissection method

1. Strip your bank's own labels (POS DEBIT, CHKCARD…).
2. Check the front for a known processor prefix — it tells you the rail and narrows the merchant type immediately.
3. Treat the next fragment as the trading name; expand abbreviations mentally (BTTL → Bottle).
4. Use amount and date as corroboration — a 9.99/12.99 monthly recurrence is subscription-shaped regardless of the name.
5. Search the exact string, asterisks included — or paste it into the identifier, which matches against thousands of catalogued descriptors and their known variations, with a confidence level on every answer.

For a whole statement, skip the line-by-line work: one upload runs this dissection on every row and flags the recurring, duplicated and fee-shaped lines while it's at it.