Twenty lines that mean nothing at a glance
Pulled straight from the searches behind our 2026 study of 35,171 unrecognizable charges, here are twenty of the descriptor strings people typed in, exactly as their banks printed them:
WM2TMBOBZBHZJIL · HDXCDLKC3ECMDEN · HUIYUNLQ7QW · D5CNQNGKP3EGSFM · YJAFPWST3ICXIAV · SUYZ9ONC9LQB5WK · CJNWEHP0KZA4U2N · WNS4FM4IEVRJVP5 · USBFCTICHAR · ICPAYMENT · USXAPMERGE · WIINTERACTI · INTLCONSERDEBIT · CP*SHOPPING · 2PSCDAYTON · CITYOFOAKSST1739 · DIGILYNXSOL · VISTVISUALS · REDWOODRVBG · YELLOWF8V3S
Faced with a wall like this, the instinct is to assume fraud. Most of the time it isn't. These are ordinary charges wearing the compression scars of a system never designed for a human to read.
The anatomy of a random-looking code
A descriptor is a short text field — often twenty-two characters or fewer — that has to survive several handoffs: the merchant names itself, a payment processor rewrites that, the card networks impose their own formatting, and finally your bank truncates whatever is left. Each step can mangle the name further.
That pipeline produces four recognizable species, and almost every string above is one of them:
- The random token — high-entropy runs of letters and digits (WM2TMBOBZBHZJIL, D5CNQNGKP3EGSFM, YJAFPWST3ICXIAV) are internal transaction or order IDs with no human-readable name attached. The hardest to trace.
- The processor prefix — CP*SHOPPING splits at the asterisk into a CP processor tag and a SHOPPING merchant fragment; ICPAYMENT and USXAPMERGE read as processor or aggregator labels rather than storefronts.
- The location fragment — 2PSCDAYTON and CITYOFOAKSST1739 embed a place (Dayton; a "City of Oaks" store #1739). A city or store number is a real lead even when the brand is missing.
- The clipped brand — VISTVISUALS, REDWOODRVBG, DIGILYNXSOL, USBFCTICHAR: squashed, vowel-dropped remnants of a business name. Sound them out and a candidate often surfaces.
The twenty, decoded
Read through that lens, the wall sorts itself into two piles:
- Decodes with effort — CP*SHOPPING, 2PSCDAYTON, CITYOFOAKSST1739, USBFCTICHAR, WIINTERACTI, INTLCONSERDEBIT, ICPAYMENT, USXAPMERGE, REDWOODRVBG, VISTVISUALS, DIGILYNXSOL, YELLOWF8V3S: a prefix, a place, or a clipped name gives you a thread to pull.
- Effectively opaque — WM2TMBOBZBHZJIL, HDXCDLKC3ECMDEN, HUIYUNLQ7QW, D5CNQNGKP3EGSFM, YJAFPWST3ICXIAV, SUYZ9ONC9LQB5WK, CJNWEHP0KZA4U2N, WNS4FM4IEVRJVP5: pure tokens with no embedded meaning, where the descriptor alone won't identify the merchant.
We're deliberately not pinning a confident brand on each string — inventing one would be worse than useless. The honest output of decoding is a category and a next step, not a fabricated answer.
Take one from the first pile and walk it end to end: CP*SHOPPING. The asterisk is the seam. Before it, CP is a processor or platform tag — the company that actually ran the card, not the storefront you shopped with. After it, SHOPPING is what's left of a merchant name once that processor's system truncated it to fit a fixed-width field. Read on its own, the fragment could belong to almost any retailer; read as a processor-plus-remainder pair, it tells you the real merchant sits one layer behind the tag on your statement, and that CP is where a search or a support call should start if the amount doesn't ring a bell. That two-step read — split at the mark, then treat each half as its own clue — is the entire method behind every string in the first pile. It never hands you the exact store name. It hands you where to look next, which is the only thing a compressed descriptor was ever going to give you.
What every one of them has in common
None of these lines is trying to deceive you. Each is the residue of a merchant name compressed past legibility — which is why unidentifiable charges are the second-largest category in our data at 37.9% of all lookups. The confusion is structural, and it falls hardest on small merchants and foreign or online-only sellers whose names never had a clean path through the network to begin with.
When your charge looks like one of these
Work it in this order:
- Split it at any asterisk and read the halves as processor and merchant.
- Extract any place or number — a city or store ID is a searchable lead.
- Match the amount and date to your receipts, app histories, and subscriptions before assuming the worst.
- If it's a pure token with no clue and no matching purchase, stop decoding and start disputing: contact your bank, because some descriptors genuinely can't be traced from the statement alone.
Say the line in front of you reads INTLCONSERDEBIT for $42.17. Splitting it at an asterisk goes nowhere — there isn't one — so step one is a dead end. There's no obvious city or store number either, so step two comes up empty too. Step three is where it actually resolves: pull up your bank app and your email receipts side by side and look for a $42.17 charge on that date, not for a name — the amount and date survive the compression even when the merchant name doesn't. If a genuine five-minute pass turns up nothing, that's the signal to stop guessing and move to step four: call the number on the back of your card and let the bank's own merchant lookup do the work a twenty-two-character field never could.
Decoding isn't about cracking every string. It's about knowing, quickly, which ones will yield to a minute of reading and which ones are your bank's job — and not mistaking either for fraud along the way.