Merchant name inconsistency seems to be the rule in raw transaction data. A single global brand can appear as twenty or more distinct strings in a bank's transaction feed. Same merchant. Same card. Sometimes the same store on the same day. The descriptors land differently anyway. It is a structural property of how card payments work, and any product built on top of unresolved transaction data inherits the inconsistency by default.
For data and product teams, this is the gap between what raw payment networks deliver and what every downstream system needs to function. The fix is merchant entity resolution: the discipline of treating a merchant as a stable real-world entity rather than as whatever bytes happen to arrive in the description field.
Merchant name inconsistency with dozens of variations
Consider a hypothetical week of card spend at one global retailer. Across a bank's portfolio, the same merchant might appear in the raw feed as:
- STARBUCKS STORE 12345
- STARBUCKS #12345 LONDON
- SBUX*PRAGUE WENCESLAS
- SQ *STARBUCKS COFFEE
- STARBUCKS COFF
- STRBKS 4577 GBR
- STARBUCKS-PARIS LV
- WWW.STARBUCKS.COM
- STARBUCKSCOFFEE EMEA LTD
- PAYPAL *STARBUCKS
- ADYEN STARBUCKS DE
- STARBUCKSCARDRELOAD
Twelve variants in one coffee chain. None of these strings are wrong, exactly - each was generated by a legitimate process within the payment network. They just have no machine-readable connection to one another. Without resolution, a banks database treats them as twelve distinct merchants, which is enough to break any feature that depends on knowing where a customer spends their money.
Root cause 1: the description is merchant-set and unvalidated
The single most important fact about transaction description is that card networks do not enforce them. The descriptor field is populated by the merchant or their acquirer when the transaction is submitted. There is no central authority validating that "STARBUCKS" is spelled consistently, that location codes follow a standard, or that the same legal entity uses the same descriptor across all of its terminals.
This decentralisation is done by design. Acquirers each have their own onboarding flows. A franchisee of a global brand fills out their own merchant agreement, which feeds their own descriptor format. A processor in one market may concatenate the brand and city; a processor in another may pad with terminal IDs; a third may abbreviate to fit a legacy field length. Every link in the chain has its own conventions, and none of them coordinate.
The result is that the descriptor is a free-text artefact of whoever set up that specific terminal or checkout flow.
Root cause 2: character limits and shortening
Card network specifications still carry hard character limits on description fields, with the legacy soft limit of 22 characters being the most prominent. Some downstream systems impose stricter limits - bank statement printing systems, SMS notification gateways, and older core banking platforms can each cut the string further before it reaches the customer.
The problem is - limitation is silent and inconsistent. A merchant called "Starbucks Coffee Company UK Ltd" might appear in one system as STARBUCKS COFFEE COMPA, in another as STARBUCKS UK, and in a third as SBUX UK LTD - depending on which processor, where, and using which abbreviation rules. None of these strings cleanly match the trading name a customer would recognise. None of them cleanly matches each other either.
The harder problem is that truncation removes the very signal that string-matching algorithms rely on. Once "Starbucks Coffee Company" becomes "STARBUCKS COFF", the characters that distinguish it from a hypothetical "Starbucks Conference Centre" or "Starbucks Convenience" are gone.
Root cause 3: legal entity vs. trading name vs. parent company
The entity recorded in the description is rarely the brand the customer thinks they paid. Three layers of identity often mix in the descriptor field.
The legal entity is the company registered with tax and regulatory authorities - often a regional subsidiary or holding structure. "Amazon EU SARL" handles much of European Amazon spend; the customer just sees "Amazon".
The trading name is the public brand customers recognise. This may differ from the legal entity in obvious ways (Google's many properties trade under different names) and in subtler ways too.
The parent company sits above both. Amazon Web Services, Amazon Marketplace, Whole Foods, Audible, and Twitch are all part of the same parent. "AMZN MKTP US" and "AWS EMEA" land in the same statement and look like unrelated merchants.
This matters because every layer is legitimate, and every layer can appear in the description depending on how the payment was set up. A consumer recognises the trading name. A credit risk team needs to aggregate at the parent level. A compliance team may need the legal entity. The descriptor field collapses all three into a single string with no metadata to indicate which layer is being used. Resolving back to a coherent merchant identity requires external reference data that the payment network simply does not provide.
Root cause 4: acquirer and processor prefixes
Payment processors often add their own codes to descriptors, creating synthetic name variants that have no connection to the underlying merchant. The classic examples are easy to spot: PAYPAL *MERCHANTNAME, SQ *COFFEESHOP, SP *STORE, STRIPE.SNL *VENDOR. The processor's identifier hijacks the most prominent position in the string, and the actual merchant is moved to whatever space remains after the change.
This pattern is especially common in card-not-present and gateway-mediated transactions. As card-not-present volume continues to grow as a share of total card spend, the descriptor field is increasingly dominated by intermediaries rather than the underlying merchants. A user looking at their statement sees the gateway, not the seller. A bank's analytics system sees a portfolio that looks like it spends heavily at "PayPal" and "Stripe" rather than at the thousands of real merchants those processors front for.
The technical effect is that two structurally identical purchases - the same customer buying from the same online merchant on consecutive days - can produce wildly different descriptors depending on which gateway routed the transaction. Resolving the real merchant behind a gateway alias requires its own dedicated logic: pattern recognition trained on processor-specific quirks, fallback inference from MCC and amount, and structured lookups against gateway-merchant directories.
Why merchant name inconsistency breaks downstream banking products
Unresolved merchant inconsistency is not a cosmetic issue. It affects the foundation that every transaction-aware product is built on.
Spending analytics show duplicates and noise: A customer's "top merchants" view fragments the same brand across half a dozen rows. Year-in-review summaries undercount loyalty. Analyses can't reliably segment customers by spend pattern because the same pattern looks different in the data depending on how each transaction was descriptor-formatted.
Categorisation fails at the franchise level: When the same merchant appears under multiple names, category logic has to apply itself many times across many variants, and any inconsistency in the underlying MCC spread into inconsistent category assignment. This is one of the more visible failure modes - it is also the one that most directly affects why banks display wrong merchant names in user-facing apps.
Subscription detection misses recurring spend: Recurring payment logic depends on grouping transactions by merchant and identifying cadence. If the same subscription bills under three different gateway-prefixed descriptors over a year, the bank's subscription view either misses it entirely or, worse, surfaces three "different" subscriptions.
Credit signals get diluted: For any consumer lender or BNPL provider relying on transaction data, merchant fragmentation directly weakens the input signal. Income aggregation, expense categorisation, and behavioural risk scoring all assume that merchant-level patterns are stable. They are not stable in the raw data.
Support and disputes become more expensive: Customers who cannot identify a charge call the bank. Mastercard's 2025 State of Chargebacks report attributes around 45% of all chargebacks to first-party (friendly) fraud, with transaction confusion (cardholders not recognising a descriptor) cited as one of its main drivers.
The compounding effect is what makes this worth solving at the infrastructure layer rather than feature-by-feature. Every product team that builds against the raw descriptor ends up only reinventing partial solutions.
Solving it with merchant entity resolution
Merchant entity resolution is how banks fix merchant name inconsistency at the data layer - by treating a merchant as a stable real-world entity. The signals that matter are the ones the descriptor alone cannot give you:
- Merchant ID and POS terminal ID, which are stable across descriptor variations from the same merchant location.
- MCC code, which narrows the merchant category even when the name string is corrupted or cut.
- Geolocation, which differentiates between same-named merchants and confirms identity for merchants with weak descriptors.
- Acquirer and processor identifiers, which let resolution logic strip prefixes and identify gateway-mediated transactions for separate handling.
- Historical descriptor patterns, which let the system recognise a new variant of a known merchant the next time it appears.
The output is a canonical merchant identity that persists across descriptor changes, gateway switches, terminal rotations, and corporate restructuring. Once that identity exists, every downstream product can attach to it: a clean transaction feed, accurate categorisation, reliable subscription detection, defensible credit decisioning.
This is the layer Tapix maintains for banks and fintechs across 112+ markets. The merchant database covers more than 800,000 unique merchants, with cross-validation across descriptor, MID, MCC, and location running on every transaction. Accuracy is held at 99.99%, and a feedback API lets banks push end-user corrections back into the model so that new variants get resolved across the whole client base.
The strategic point for banks is that merchant entity resolution is not a feature. It is the prerequisite for every transaction-aware feature, and it is increasingly the prerequisite for compliance - Visa's Enhanced Merchant Data mandate takes effect in January 2027 and Mastercard's AN4569 has been in force since October 2023. Banks that have not built or licensed a canonical merchant layer will spend the next two years discovering exactly how many of their downstream products silently depend on it.
