Building merchant recognition yourself: what the first year looks like

Every team that shows transactions to customers eventually asks whether to build merchant recognition in-house. It looks like a weekend project: a list of brand keywords, a few patterns, a logo per brand. The first demo works. This guide is about the year after the demo, so you can make the decision with the real costs in view. We are obviously not neutral, so we have tried to be specific rather than persuasive.

Week one: the keyword list

You collect the hundred brands that make up most of your customers' spending, write a keyword or pattern for each, and match descriptors against them. On famous brands this works well, because famous brands write their names consistently. The demo shows Netflix, Careem and Carrefour with logos, and everyone is happy.

Month one: the long tail

Real statements are mostly not famous brands. Local restaurants, independent shops, clinics, schools and small online stores make up a large share of lines, and each appears only a handful of times. A keyword list cannot cover them, and every new market brings a new set. Coverage plateaus, and the remainder shows up as raw descriptors next to your nicely logoed ones.

Month three: false positives

Keywords match too much as well as too little. "SHELL" matches a fuel station and a seafood restaurant. A short brand name matches inside a longer one. A person's name in a transfer matches a business. Each false positive is worse than a miss, because it puts a wrong logo next to a real transaction. You add exceptions, then exceptions to exceptions.

SHELLFISH HOUSE JUMEIRAH DUBAI AE

SHELLFISH HOUSE

A restaurant. A keyword rule for "SHELL" calls it a fuel station.

Month six: the world keeps changing

• Brands rename, and the old name lingers on descriptors for years alongside the new one.
• Merchants switch payment providers, and their descriptor changes shape overnight: a new prefix, a different city field.
• New providers appear in your markets, each with its own format.
• Banks change their own formats when they migrate systems, adding new words to every line.
• Logos and websites change, and some merchants close.

None of this is hard on its own. Together it is a permanent maintenance load that nobody planned for.

Month twelve: the review queue

To get past the plateau, teams add a manual review step: someone looks at unmatched lines and adds merchants. This is where the real cost sits. It needs a person who knows the market, tooling to review quickly, a way to verify what was added, and a way to push corrections everywhere a merchant appears. It is a small operations team, not a feature.

When building makes sense

Building in-house is reasonable when:

• Your transactions come from a small, fixed set of merchants, for example a closed-loop card or a single marketplace.
• You only need categories, not merchant names and logos, and can accept "Other" for a large share.
• You already run a data operations team for a market no provider covers well.

When buying makes sense

• Your users shop everywhere, in one or several countries.
• You show merchant names and logos to customers, where a wrong answer is visible.
• You would rather spend engineering time on your product than on keeping a merchant list current.

If you do evaluate a provider

Run a few hundred of your own real lines through it, from the regions you serve, and judge it on precision when it answers, honesty when it does not, and how it treats transfers and personal names. Our enrichment guide has a checklist. You can test DescriptorAPI the same way: the playground needs no account, and the batch endpoint takes 100 lines per call. You pay only for lines where we find a merchant.