Financial Transaction Categorization at Scale Using LLMs and Custom Embeddings
mercado_libre · Finance · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: financial transaction enrichment
Mercado Libre needed to categorize and enrich massive volumes of financial transaction data across Latin America, where Open Finance unlocked access to data but country-specific formats, languages, merchant codes, and naming conventions made manual rules brittle and hard to scale.
Constraints:
- Transactions arrive in many languages, formats, contexts, and country-specific dialects.
- The financial data sits in regulated systems and must respect privacy, ethics, security, and fairness requirements.
- Regex and merchant-code rules were expensive to maintain and fragile when merchant names changed.
- The system needed to evolve from quarter-scale batches to near-real-time weekly processing.
- External LLM APIs introduced long-term latency and cost pressure at hundreds-of-millions scale.
Architecture
Mercado Libre evolved the enrichment pipeline through three architectures: country-specific regex and MCC rules, GPT-3.5/4o-mini-assisted labeling with human validation, and finally custom BERT-style semantic embeddings trained on regional financial text. The final system runs on MELI infrastructure such as Fury and DataMesh, uses model-agnostic orchestration to integrate improved LLMs, and relies on local semantic categorization to deliver faster, cheaper, near-real-time transaction understanding.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR open-finance-transaction-sources["Open Finance transaction sources"] --> datamesh-and-fury-infrastructure["DataMesh and Fury infrastructure"] datamesh-and-fury-infrastructure --> llm-assisted-labeling-workflow["LLM-assisted labeling workflow"] llm-assisted-labeling-workflow --> human-validation-loop["Human validation loop"] human-validation-loop --> semantic-categorization-engine["Semantic categorization engine"] llm-assisted-labeling-workflow --> semantic-categorization-engine datamesh-and-fury-infrastructure --> semantic-categorization-engine semantic-categorization-engine --> personalization-and-financial-insights["Personalization and financial insights"]
Components
| Component | Role | Interacts with |
|---|---|---|
Open Finance transaction sources |
Provide raw financial transaction data voluntarily shared by users through authorized Open Finance systems. | DataMesh and Fury infrastructure |
DataMesh and Fury infrastructure |
Hosts the core MELI data and orchestration infrastructure used by enrichment workflows. | Open Finance transaction sources, LLM-assisted labeling workflow, Semantic categorization engine |
LLM-assisted labeling workflow |
Uses prompts, batch processing, and LLMs to generate categorization labels for financial transactions. | DataMesh and Fury infrastructure, Human validation loop, Semantic categorization engine |
Human validation loop |
Reviews GenAI-generated labels to maintain control, precision, traceability, and data quality. | LLM-assisted labeling workflow, Semantic categorization engine |
Semantic categorization engine |
Runs custom BERT-style embeddings trained on regional financial text for low-latency semantic categorization. | DataMesh and Fury infrastructure, Personalization and financial insights |
Personalization and financial insights |
Uses enriched categories for personalized financial narratives, credit models, and discrepancy feedback loops. | Semantic categorization engine |
Data flow
Open Finance transaction data enters MELI's data infrastructure, is transformed by financial data enrichment workflows, receives LLM-assisted and human-validated labels during model development, and is later categorized by custom semantic embeddings that map regionally varied merchant names and transaction text into structured categories for personalization, credit, and financial insight products.
Why this architecture
MELI moved from rules to LLMs because regex and MCC categories could not handle the region's language and merchant variability. It then distilled LLM knowledge into custom embeddings because external LLM calls were accurate but too costly and slow for hundreds of millions of weekly transactions, while embeddings preserved semantic understanding in a faster local form.
Models used: GPT-3.5 Turbo · GPT-4o-mini · Gemini · Claude · BERT-style semantic embeddings · Fury · DataMesh
Scale
- The system categorizes millions of transactions.“categorizing millions of transactions relied heavily on handcrafted rules based on regular expressions (regex)”article, stated
- GPT-3.5 raised accuracy from about 60% to over 80%.“deliver over 80% accuracy with the right setup, far surpassing our regex-based approach (which hovered around 60%).”article, stated
- The LLM phase reduced operational costs by 75%.“We also slashed operational costs (down 75%) and scaled up transaction categorization: from tens of millions per quarter to tens of millions per week.”article, stated
- Custom embeddings lifted accuracy from 80% to 90% while reducing operational costs by more than 30%.“we boosted our global categorization accuracy from 80% to 90%, and further reduced operational costs by more than 30%.”article, stated
- The architecture supports near-real-time responses for millions of transactions.“it now allows us to respond in near real time (NRT) to millions of transactions”article, stated
Alternatives considered (roads not taken)
Country-specific regex and MCC rules.
Rejected because: They produced inconsistent categories, required constant local tweaks, and became unsustainable under new data volume.
Train a specialized corpus from scratch.
Rejected because: The source says that would be expensive and raise privacy concerns at the time.
Rely solely on external LLM APIs.
Rejected because: External LLM calls had latency and cost problems at hundreds-of-millions weekly transaction scale.
Lock the system to one LLM model.
Rejected because: MELI wanted a flexible, model-agnostic design that could incorporate GPT-4o-mini, Gemini, Claude, and future models.
Patterns
human-in-the-loop-gate (financial labeling quality)
MELI combined GenAI-generated categorization decisions with expert validation to preserve control, precision, and traceability.
fine-tuning-adaptation (domain semantic embeddings)
MELI trained BERT-style embeddings on regional financial text so similar merchants and spending contexts cluster despite language variation.
cost-aware-routing (LLM-to-embedding optimization)
The architecture uses cheaper, faster embeddings for real-time operation after LLMs helped build the semantic foundation.
data-quality-loop (financial category feedback)
The envisioned system can detect discrepancies between official MCC codes and semantic categories and ask users to confirm feedback.
Tradeoffs
Use LLM-assisted human validation before deploying custom embeddings.
Chose GenAI prompts plus expert feedback over Fully automatic LLM labels.
Rationale: Financial categories affect decisions for millions of users, so precision, traceability, ethics, and control mattered.
Distill LLM intelligence into custom embeddings.
Chose Locally trained semantic embeddings over Querying LLM APIs for every transaction.
Rationale: Embeddings preserved semantic categorization while improving latency and cost for near-real-time usage.
Keep the enrichment architecture model-agnostic.
Chose Flexible model-agnostic architecture over One fixed provider/model.
Rationale: The system could adopt GPT-4o-mini and test Gemini/Claude as the AI landscape shifted.
Gotchas (what bit them)
Manual rules broke on local language and merchant-name variation.
Root cause: Latin American transaction descriptions used different dialects, country conventions, and merchant naming changes.
Resolution: MELI moved toward GenAI and then semantic embeddings trained on regional financial text.
MCC codes could be wildly inaccurate.
Root cause: Merchant category codes were manually reported and did not always reflect the true purchase context.
Resolution: Semantic categorization replaced brittle code/rule reliance with contextual transaction understanding.
External LLM APIs became expensive and latent at scale.
Root cause: The workload grew to hundreds of millions of weekly transactions.
Resolution: MELI distilled semantic intelligence into local embeddings for faster, cheaper real-time operation.
Evaluation
MELI evaluated successive generations by categorization accuracy, operating cost, throughput, and ability to support near-real-time semantic categorization while retaining human validation for financial data quality.
Metrics: Regex baseline accuracy around 60% · GPT-3.5 Turbo accuracy over 80% · 75% operational cost reduction · Custom embedding accuracy 90% · Additional operational cost reduction over 30% · Tens of millions per quarter to tens of millions per week · Near-real-time response capability
Outcomes
- Transaction categorization moved from regex rules with about 60% accuracy to LLM-assisted workflows above 80%.
- Custom embeddings reached 90% global categorization accuracy with more than 30% additional cost reduction.
- The system scaled from tens of millions per quarter to tens of millions per week and supports near-real-time transaction understanding.
The case reports millions to hundreds of millions of transactions, tens-of-millions weekly throughput, and near-real-time response expectations across LATAM financial data.