See Finexer’s Enrichment API in Action.
95%+ accuracy, <100ms, 100M+ merchants - test it on your data.
Merchant data enrichment exists because bank feeds are unreadable without it. Your user bought a coffee at Pret A Manger. Their bank feed says SQ*PRET A MANGER.
Your user ordered from Amazon. Their feed says AMZN MKTPL*A12B3.
Your user paid for something via a card terminal. Their feed says WL*AMZ MKTP.
A finance ops lead cannot tell what category to assign. A reconciliation engine cannot match it to a vendor. A PFM app cannot display a recognisable name.
Merchant data enrichment is the API layer that converts those strings into something a system – or a human – can actually use.
This comparison covers how five merchant data enrichment APIs handle that problem: what they take as input, what they return, and where each fits depending on your use case and UK market focus.
“The string in the bank feed is not the merchant name. It is the acquirer’s transaction descriptor, truncated to 25 characters, prefixed with the payment processor code, filtered through whatever POS software the terminal was running. Enrichment APIs exist because that string is not usable without processing.” – Yuri, Finexer
TL;DR
Merchant data enrichment takes a raw bank transaction descriptor and returns a clean merchant name, category, logo, domain, and location. Plaid Enrich is US-first, strong on card data. Yapily Data Plus bundles enrichment with Open Banking AIS, solid for UK+EU. Snowdrop MRS is a pure-play specialist built on Google Maps. Finexer’s Transaction Enrichment API is built into the UK bank data feed – enrichment happens at source, not as a post-processing step.
Why Are Bank Transaction Descriptors So Cryptic?
The string in the bank feed is set by the acquiring bank at the point of sale, not by the merchant. Three things make it unreadable.
Payment processor prefixes. Card terminals from Square prefix every transaction with SQ*. Worldline uses WL*. Stripe appears as STRIPE* or ST-. These codes identify the payment processor, not the merchant. Enrichment strips this prefix to isolate the underlying merchant name.
Character truncation. The ISO 8583 standard – which governs card transaction data – allocates 22 characters maximum for the merchant name field in the transaction record. A merchant named “Pret A Manger” becomes PRET A MANGER or PRET A MANGA depending on which part gets cut off – the UK high street name loses its tail. UK Faster Payments provides a reference field with more space, but card acquirer truncation remains the primary source of noise.
Acquirer codes and sub-merchant identifiers. Amazon’s marketplace transactions carry sub-merchant identifiers like MKTPL*A12B3 – that alphanumeric suffix is a fulfilment code, not part of the merchant identity. Enrichment APIs strip and normalise these to return Amazon as the clean merchant name.
The process to enrich merchant data typically runs three steps: tokenise the raw string (remove processor prefix and sub-merchant noise), match the cleaned token against a merchant index or knowledge graph, and return structured output – clean name, category, logo URL, domain, and location where available.
The full scope of transaction data enrichment extends beyond merchant identification to counterparty detection and payment pattern analysis, but merchant name resolution is the core problem this comparison addresses. UK platforms building on Finexer’s transaction enrichment API receive this output in the same AIS response, without a separate enrichment call.
What Does Merchant Data Enrichment Actually Return?
Before comparing providers, it is worth mapping exactly what a complete merchant data enrichment response covers. Most merchant data enrichment APIs return some combination of:
- Clean merchant name – human-readable, normalised. SQ*PRET A MANGER → Pret A Manger
- Merchant category – MCC code and/or taxonomy label. Coffee Shops, Food & Drink, Cafes
- Logo URL – brand logo for display in transaction lists or notifications
- Domain / website – bluebottlecoffee.com
- Location – latitude/longitude, address, city when available
- Payment processor – identifies whether Square, Stripe, PayPal etc. intermediated
- Recurrence signal – whether the transaction pattern suggests a subscription or one-off
Not every merchant data enrichment provider returns all of these fields. The gap between providers is most visible on three dimensions: long-tail merchant coverage (smaller UK SMEs, local businesses), B2B transaction context (invoices, supplier payments), and what happens when the match fails.
How Do the Five Providers Compare on the Same Raw String?
Below is how each provider’s merchant data enrichment handles three representative raw strings a UK platform might receive.
SQ*PRET A MANGER – UK café payment via Square terminal AMZN MKTPL*A12B3 – Amazon Marketplace purchase WL*AMZ MKTP – Amazon via Worldline acquirer (different string, same merchant)
| Provider | SQ*PRET A MANGER | AMZN MKTPL*A12B3 | WL*AMZ MKTP |
|---|---|---|---|
| Finexer Enrichment | Pret A Manger · category · merchant ID · <100ms via AIS feed | Amazon · category · merchant ID · structured JSON | Amazon · category · merchant ID (acquirer prefix stripped) |
| Plaid Enrich | Pret A Manger · category · logo · location | Amazon · category · logo · counterparty (marketplace) | Amazon · category · logo (may vary by acquirer string) |
| Yapily Data Plus | Pret A Manger · category · logo · recurrence · payment processor: Square | Amazon · category · logo · processor identified | Amazon · category · logo · processor: Worldline |
| Snowdrop MRS | Pret A Manger · logo · address via Google Maps · category | Amazon · category · logo · location data | Amazon · category · logo (geo-enriched if location available) |
Note: Exact merchant data enrichment outputs depend on the merchant index version, whether location context is available, and whether the transaction is card-present or card-not-present. The table shows the expected output shape for well-known merchants - long-tail and local merchants vary more significantly by provider.What I Feel
The strings that reveal the most about a provider’s merchant graph quality are not the Amazon and Starbucks transactions. Those every enrichment API gets right. The revealing strings are the local solicitors firm, the regional cash-and-carry, the niche B2B supplier that appears as CSG*MERIDIAN SVC PRTL in a UK business account. That is where the difference between a consumer-trained merchant graph and a UK SME-specific merchant data enrichment layer becomes visible in production.
How Do the Five Providers Differ Structurally?
Beyond what they return for a given string, the providers differ structurally in how merchant data enrichment fits into the broader integration.
Finexer Transaction Enrichment is structurally different from the others. Enrichment is a layer built into Finexer’s Open Banking AIS data feed, not a post-processing API you route transactions through separately. When a UK bank transaction comes through the AIS connection, enrichment happens at source – returning merchant identification, category, and structured output in the same response, under 100ms, against a 100M+ merchant database.
The UK-first design means the merchant graph reflects UK bank transaction patterns specifically – Faster Payments references, UK SME supplier names, UK-specific processor strings.
Plaid Enrich operates as a standalone merchant data enrichment API that accepts any transaction data – including from non-Plaid sources. You POST the raw transaction description and receive structured output. It processes 500 million transactions daily and its personal finance category taxonomy reached over 90% accuracy on its own benchmarks.
The primary limitation for UK platforms is geographic: Plaid’s merchant graph is US-weighted. UK long-tail merchant identification – smaller retailers, local B2B suppliers, UK-specific payment patterns – performs below the headline accuracy figure. Pricing is a per-enriched transaction with a sales conversation required for production access.
Yapily Data Plus is an add-on merchant data enrichment layer on top of Yapily’s Open Banking AIS connection. You cannot use it without a Yapily AIS integration. Within that constraint, it is well-suited for UK and European platforms – the ML models are trained on UK and EU transaction data, and the taxonomy includes 140 categories for business accounts specifically.
Output includes merchant name, logo, MCC, recurrence signal, and payment processor identification. For platforms already using Yapily for data access, Data Plus removes the need to route transactions through a separate enrichment provider.
Snowdrop MRS API is the pure-play merchant data enrichment specialist in this group. Founded in 2013, processing over 1.6 billion transactions monthly, built on Google Cloud and powered by Google Maps data. The company reports match rates up to 98% on its own benchmarks – self-reported figures, independently unverified, but consistent with their positioning as accuracy-first.
Snowdrop is enterprise-gated: trusted by Nationwide, Sabadell, and PKO Bank Polski, but not designed for fast startup integration. Their strength is location-enriched merchant data – every match is grounded in Google Maps POI data, which is particularly valuable for consumer banking apps that display transaction locations. ISO 27001 and SOC 2 Type II certified.
| Provider | Integration model | UK merchant coverage | Key output fields | Best fit |
|---|---|---|---|---|
| Finexer Enrichment | Built into AIS feed, UK bank connection | Strong UK, 100M+ merchants, <100ms | Name, category, merchant ID, structured JSON | UK accounting, ERP, reconciliation platforms |
| Plaid Enrich | Standalone API, any data source | Good on major brands, weaker on UK long-tail | Name, category, logo, location, counterparty | US-primary platforms, card issuer data |
| Yapily Data Plus | Add-on to Yapily AIS (not standalone) | Strong UK + EU | Name, logo, MCC, recurrence, processor | Platforms already using Yapily for data |
| Snowdrop MRS | Standalone API, enterprise sales | Strong, geo-enriched via Google Maps | Name, logo, address, category, location | Consumer banking apps, high-volume enterprise |
How Does Finexer’s Transaction Enrichment API Work?
Finexer’s merchant data enrichment is not a separate API call after data collection. It runs as part of the AIS bank data feed itself. When a transaction arrives from a UK bank connection, Finexer’s enrichment layer resolves the merchant descriptor before the data reaches the platform.
What this changes for a platform building on UK bank data:
- No secondary API call – enrichment is returned in the same JSON response as account data, not as a separate post-processing step requiring a second integration
- UK transaction patterns natively – the merchant graph is trained on UK Faster Payments references, UK acquirer string formats, and UK SME naming patterns – not normalised from a US-first dataset
- 95%+ accuracy against a 100M+ merchant database, under 100ms latency – meaning enrichment does not introduce latency into the data pipeline
- Structured output – clean merchant name, category code, merchant identifier – ready to feed directly into reconciliation, categorisation, or display layers
What Finexer enrichment does not cover: sanctions screening, PEP database lookups, adverse media, or beneficial ownership – those are separate compliance layers. Finexer enrichment is merchant-identification and categorisation only.
Platforms building on UK business account data will find the B2B data enrichment tools comparison useful alongside the integration model differences above.
FCA-authorised AISP and PISP (FRN 925695). PSD2-compliant. Usage-based pricing, commercial terms agreed based on use case. 3 to 5 weeks of hands-on onboarding support.
“The merchant data enrichment quality that matters is not on the Amazon transactions. Every provider gets those right. The signal is in how a provider handles the 30% of transactions that are regional suppliers, local merchants, and UK-specific payment patterns. That is the long tail that breaks reconciliation workflows.” – Yuri, Finexer
Which Platform Type Should Use Which Provider?
PFM and consumer budgeting apps. Snowdrop MRS is purpose-built for this – the Google Maps integration produces location-enriched, logo-rich output that consumer apps display directly in transaction lists. For consumer-facing UK Open Banking apps, Yapily Data Plus is also strong given the UK+EU bank data foundation.
Accounting and ERP platforms. Finexer enrichment is designed for this use case specifically – B2B transaction patterns, UK Faster Payments references, and the ability to handle the supplier and vendor strings that appear in business account feeds rather than consumer spending. The transaction categorisation depth matters most here – business accounts need category granularity that consumer-trained graphs do not always provide. For platforms already in the Yapily ecosystem, Data Plus covers this reasonably well.
Card issuers and banks that want to enrich merchant data from their own card transaction feeds. Plaid Enrich accepts non-Plaid data – you can POST your own card transaction strings and receive enrichment. This makes it the natural choice for a bank or card issuer that already holds its own transaction data and wants to add an enrichment layer without changing the data collection infrastructure. Snowdrop MRS operates in this space as well, with Nationwide as a documented customer.
UK SaaS platforms building on Open Banking AIS. Finexer is the provider in this group where merchant data enrichment is integrated directly into the bank data connection. For a UK platform that is using Open Banking AIS as its primary data source and needs enrichment on the same feed, Finexer removes the secondary integration step entirely.
Honest note: enrichment quality on long-tail UK merchants varies across all providers - small regional businesses, local service providers, and niche B2B suppliers will not resolve correctly every time.The recommendation is to test each provider against your own historical transaction data, weighted toward the merchant types that affect automated financial data categorisation accuracy most in your specific use case.
What is merchant data enrichment?
The process of converting a raw bank transaction descriptor into structured merchant information – clean name, category, logo, domain, location. Enrichment APIs take the cryptic string from the bank feed and return data that a system or user can actually interpret and act on.
Why are bank transaction strings so hard to read?
They are set by the acquiring bank, not the merchant. ISO 8583 card transaction records allow only 22 characters for the merchant name. Payment processor prefixes (SQ*, WL*, STRIPE*) identify the terminal provider, not the merchant. Sub-merchant identifiers (MKTPL*A12B3) are fulfilment codes. Enrichment APIs strip all of this noise and resolve to the actual merchant.
How does Finexer enrichment differ from standalone enrichment APIs?
Finexer enrichment runs within the Open Banking AIS data feed – returned in the same response as transaction data, not as a post-processing step. No second API integration required. The merchant graph is built on UK bank transaction patterns, not normalised from a US dataset.
Which enrichment API is best for UK SME transaction data?
Finexer and Yapily Data Plus are the strongest for UK SME merchant identification – both trained on UK transaction patterns. Plaid is US-weighted; strong on global brands, weaker on UK long-tail. Snowdrop is strong on consumer-facing location-enriched data. Test each on your own historical transaction sample before committing.
Stop routing UK bank strings through a separate enrichment step – Finexer’s Transaction Enrichment API resolves merchant data at the AIS source.
About the Author
Yuri
Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.