The Merchant Identity Gap: The Hidden Payment Data Problem

The transaction is there. The merchant is not.

A customer opens their bank's mobile app and searches for "Starbucks" to check last month's coffee spend. The search returns nothing, even though they visited the establishment three times that week. The transactions exist in the database, posted by the acquirer as SBUX. To the customer, these are the same thing. To the bank's search engine, they are completely unrelated strings.

This is not just a user experience inconvenience. Every unrecognized transaction is a potential call center inquiry—and the costs accumulate: inflated support volumes, lower customer satisfaction (CSAT) scores, broken spend categorization, and customer churn to competitors. For institutions building personalized financial management (PFM) tools or AI-powered advisors, the stakes grow even higher. If your system cannot reliably identify which merchant a transaction belongs to, every recommendation built on top of that data inherits the same blind spots. The merchant identity gap is a fundamental data problem—and it sits at the foundation of every personalized financial experience a bank or fintech wants to build. By serving as a unified data foundation, MongoDB directly addresses this gap through advanced semantic resolution capabilities, enabling organizations to intelligently harmonize raw transaction data into unified, queryable merchant identities.

A three-dimensional issue

The gap compounds because customers do not transact within a single market. Every time a customer travels, shops on a foreign platform, or pays for an overseas subscription, their bank receives merchant strings from acquirers in that market—in whatever script, language, or naming convention those acquirers use. Three distinct but related challenges drive this:

• Script and language mismatch: Merchant names may arrive from payment networks in the original language and script, depending on the market and acquirer where the transaction occurred. For example, a Chinese-speaking customer searching for 星巴克 (Xīng bā kè, the Chinese name for Starbucks) will find no match against the merchant name captured as SBUX (or STARBUCKS or its variant in romanized form). The underlying issue is straightforward. Unless the merchant name is captured in the customer’s familiar script, or the application maps the search term to the merchant name through translation, no amount of string matching will bridge the gap. This challenge extends to any market where customers naturally search in a script different from the romanized form that payment networks deliver. Arabic, Japanese, Korean, Thai, and other languages all present the same structural problem.
• Colloquial alias divergence: In Brazil, McDonald’s is also affectionately known as “Méqui”—yet no pattern match on MCDONALDS would ever surface it. This is not an edge case. In every market, customers develop colloquial names for the brands they frequent, and those names bear little resemblance to the strings that acquirers deliver. Unless those colloquial aliases are explicitly cataloged and mapped, they remain permanently invisible to any search built on merchant name matching alone.
• Cross-subsidiary inconsistency: The same merchant arrives from different acquirers as completely different strings. 7-Eleven, for example, can appear as SEVEN-ELEVEN, 7-ELEVEN, 7-11, or even SEI depending on the market and acquirer. It’s all the same brand, but none match each other exactly. Without a canonical identity that unifies these variants, subsidiaries across markets can’t see that their customers are spending at the same merchant.

Translation tables and manual mapping cannot scale. A bank across multiple markets faces hundreds of thousands of entries, each requiring human curation, each growing stale as merchants change names or register under new acquirers. Regular expression matching fares no better. Partial matches produce too many false positives, cannot resolve aliases the rule writer never knew existed, and cannot generalize across scripts. The alias space is linguistically open-ended. No rule set ever will be.

A bank headquartered in northern Asia, with subsidiaries spanning multiple countries, languages, and scripts, hit exactly this wall. Its conversational AI assistant could not reliably answer a question as basic as "How much did I spend at Starbucks last month?" The engagement that followed shaped most of the architecture below.

The solution: Semantic resolution on a unified data foundation

The merchant identity problem is semantic, not syntactic. Two strings refer to the same merchant, not because they share characters, but because they refer to the same real-world entity: Requiring a model that understands meaning across linguistic boundaries.

Generative AI models trained on multilingual corpora resolve this by embedding merchant strings into a shared semantic vector space. Starbucks, SBUX, 星巴克 or even 星咖啡 (Star Coffee, a local Chinese alias of Starbucks) cluster together regardless of script because they refer to the same entity. The model infers equivalence from meaning, not character matching.

At the core of this solution is a master merchant catalog. It's the authoritative reference store that holds every known merchant with its canonical name, all known aliases across markets and scripts, and its vector embedding. This catalog is the single source of truth the entire system reasons from. MongoDB serves as the unified intelligent data foundation underlying this catalog. It stores each merchant as a single document with its descriptor variants, canonical name, aliases, and vector embedding, all co-located and queryable in one operation. Each transaction is persisted with a canonical merchant identifier linking it to the master merchant catalog. That link is what allows search, aggregation, and conversational retrieval to operate on merchant meaning rather than raw network strings.

The architecture operates in two coordinated layers—one that continuously resolves and enriches merchant identities, and one that surfaces those identities in real time to customers and AI systems. These two pillars are:

Pillar 1: Merchant alias enrichment

The descriptor layer feeds a three-step escalating pipeline:

1. Fuzzy matching: Incoming descriptor strings are checked against the master merchant catalog using MongoDB Search fuzzy matching. Known aliases, including local script variants and colloquial names written back from prior gen AI resolutions, resolve instantly without an LLM API call.
2. Semantic vector search: Unmatched strings escalate to a semantic layer. Descriptors are embedded using Voyage AI's voyage-3-large (or voyage-finance-2 for deeper financial domain precision) and matched against the master merchant catalog via MongoDB Vector Search. A reranker refines candidates by true relevance. Teams preferring a more integrated path can use MongoDB's auto-embedding capability.
3. Gen AI write-back: When no confident match exists, the gen AI model uses retrieval-augmented generation (RAG)—retrieving known merchant examples from the master merchant catalog—to generate a canonical merchant name and the most relevant local alias for the market. Resolved aliases write back to the master merchant catalog, improving future match rates and reducing LLM reliance over time.

Pillar 2: Merchant query and search

With canonical identities and local aliases indexed, MongoDB Search enables customers to search in their own language and find their transactions regardless of how the original descriptor arrived. Patterns include intent extraction (a gen AI chatbot parses natural language into structured MongoDB Search parameters), text-to-MQL (the model generates a MongoDB Query Language pipeline directly, with governance controls advisable in regulated environments), and the MongoDB MCP Server for mature agentic deployments.

What makes these patterns viable at scale is the data platform underneath them. The merchant catalog must store rich, variable-length records with aliases that grow over time in unpredictable scripts, serve vector similarity searches alongside structured queries, and do all of this within a single consistent system. And do it all without synchronization overhead across the enrichment pipeline, search layer, and conversational interface. MongoDB's document model and native search capabilities align naturally. Descriptor variants, aliases in any script, and vector embeddings are co-located in a single document and queryable in one operation—no data copies to drift, no separate vector store, no schema migrations when a new market or script is added.

Figure 1. Semantic resolution on a unified data foundation with MongoDB. (Simplified conceptual POV for illustrative purposes)

What this unlocks

When the merchant identity gap is closed, the customer who searched for Starbucks and found nothing finally gets their answer—and so does every customer searching in their own language and local aliases. The operational payoff is immediate. You have fewer disputed transaction calls, repaired spend categorization, and PFM tools that actually reflect how customers spend. For institutions investing in AI, it is the precondition for a conversational assistant that can reliably answer, "How much did I spend at Starbucks last month?" across every market a customer has visited. Every resolved transaction enriches the catalog, so the system improves continuously over time.

This gap doesn't require a global footprint to matter. Any bank processing transactions across multiple acquirers or serving customers who search in their own language is already exposed. When those customers travel and spend overseas, every unresolved gap compounds, and the cost of inaction scales with it. Those who close this gap now carry that advantage into every customer experience they build next.