The hardest category
Most confusing descriptors still contain a fragment of something readable — a truncated name, a processor prefix, a city. Then there is this:
- WM2TMBOBZBHZJIL
- HDXCDLKC3ECMDEN
- D5CNQNGKP3EGSFM
- SUYZ9ONC9LQB5WK
- CJNWEHP0KZA4U2N
Those are real descriptor strings people brought to us, screened so that only machine-generated codes appear. There is no merchant name in them. There is nothing to search for in the ordinary way.
In our data, 37.9% of lookups fall into the unidentifiable bucket — charges where the merchant could not be determined from the descriptor. Opaque codes like these are its hardest core.
Where opaque codes come from
Internal reference numbers. A billing system populates the descriptor field with its own transaction ID because nothing forced it to use a readable name. The customer-facing effect is invisible from inside the merchant's system.
Gateway and aggregator defaults. Some platforms emit a per-transaction or per-account identifier by default, and it stays that way unless the merchant configures otherwise. Many never do.
Legacy and institutional systems. Utilities, municipal services, insurers and government payments frequently run on old software with fixed-width fields and no notion of a friendly name. Some of our real examples look institutional for exactly this reason: CITYOFOAKSST1739, INTLCONSERDEBIT, USBFCTICHAR.
Semi-readable hybrids. A middle tier carries a hint: CP*SHOPPING, ICPAYMENT, DIGILYNXSOL and VISTVISUALS. Enough to guess an industry, not enough to name a company.
Working the problem
Since searching the name is unavailable, use everything around it.
1. The amount is your strongest handle
Search your email for the exact figure including cents — "$47.99". Receipts survive in inboxes long after the memory of the purchase has gone.
2. The date, with drift
Posting can lag the purchase by one to three business days. Look at a window, not a day.
3. Does it recur?
Scan back several statements for the same string or the same amount. A monthly rhythm means a subscription or a service agreement, which narrows the field enormously. A single occurrence usually means a one-off purchase.
4. Rule out the small stuff
Charges under about a dollar are frequently card-verification holds that will drop off. Repeated tiny charges from an unfamiliar source are a different matter, and worth reporting promptly.
5. Ask the other cardholders
Shared and authorized-user accounts account for a large share of "nobody here bought this."
6. Call the bank and ask three specific questions
The full merchant name as the network recorded it; the merchant category code; and the merchant's city and country. The MCC is the one people never think to request, and it identifies the industry even when the name means nothing.
Reading what little signal there is
Opaque strings are not uniformly opaque. Some shapes carry a hint worth acting on:
| What the string looks like | What it often indicates |
|---|---|
| All letters and digits, 12–16 characters, no spaces | A gateway or billing-platform transaction reference |
| A recognisable word buried in noise (SHOPPING, PAYMENT, MERGE) | A platform default with a partial description |
| A place name plus digits (a city, a state abbreviation) | Municipal, utility, or a local authority payment |
| Letters that abbreviate an institution (USB, INTL, CONSER) | A bank, insurer or institutional biller |
| A short prefix, an asterisk, then noise | A processor whose merchant field was never configured |
None of these is conclusive. All of them narrow the question from "what is this?" to "what kind of thing is this?", which is the question your bank can answer from the merchant category code.
The subscription test
Before assuming the worst, establish whether it repeats. Pull three to six months of statements and look for the same string, or the same amount, at a regular interval.
- Same amount, monthly rhythm — a subscription or service agreement, however unreadable the name. Check app stores, then your inbox for renewal notices around those dates.
- Same amount, annual — an easy one to miss entirely, and the most common cause of a charge that feels like it came from nowhere.
- Varying amount, regular rhythm — a utility, an insurer, or a usage-based service.
- Once only — a one-off purchase, which is the hardest case and where the amount-search matters most.
This single check resolves a large share of opaque codes, because a recurring charge implies a relationship you established at some point, and that gives you something to search your email for.
When to stop investigating and act
Report promptly, without further investigation, if:
- The charge is one of several unfamiliar ones appearing together
- It follows a card loss, a data-breach notice, or a phishing message you responded to
- Small test-sized amounts are appearing from sources you do not recognise
- It recurs after you have already established you have no relationship with the merchant
Those patterns are worth more than the appearance of the string. A single opaque code, at a plausible amount, on an account with no other anomalies, is much more likely to be a badly configured merchant than a compromise.
The uncomfortable part
Some charges do not resolve. The descriptor carries no recoverable information, the amount matches no receipt, and the bank's own record adds only a category code.
At that point the question stops being "what is this?" and becomes "did I authorize it?" If you conclude you did not, the deadlines that apply run from the date the statement was sent, and on a debit card your maximum liability rises the longer you wait. Investigating for another month is not a neutral choice.