Técnico

Catégorisation de transactions

Categorización de transacciones bancarias

Etapa que transforma un concepto en bruto ("CB CARREFOUR 23/04") en una categoría útil ("Alimentación › Supermercado"). Pieza invisible pero crítica para PFM, BFM, scoring y contabilidad automática.

Definición

La categorización de transacciones transforma una operación en bruto (concepto técnico, importe, fecha) en una categoría útil: "Alimentación › Supermercado", "Transporte › Uber", "Salario".

Es una pieza invisible pero crítica para cualquier caso de uso que consuma datos de AIS: PFM, BFM, scoring de crédito alternativo, contabilidad automática, detección de fraude, embedded finance.

El problema: conceptos en bruto ilegibles

Un extracto típico contiene líneas como:

  • CB SNCF MOBILE 24/04 0612345678
  • VIRT SARL XYZ COMM/AVR2025
  • PRLV EDF FACT N12345678
  • CB CARREFOUR EXP 23/04 75011 PARIS
  • CB AMZN MKTPL DUBLIN IE

Tal cual, es inutilizable. Hay que inferir la categoría, el comercio real y la naturaleza del gasto.

Reglas, ML, híbrido

Tres enfoques, todos en uso:

  • Reglas deterministas — regex y tablas de correspondencia ("CARREFOUR" → Supermercado). Precisas en lo conocido, incapaces de gestionar nuevos comercios.
  • Machine learning supervisado — modelos entrenados con decenas de millones de conceptos etiquetados, capaces de generalizar ("CARREF EXPRESS PARIS" sin entrada explícita).
  • Híbrido — reglas para los casos seguros, ML para lo desconocido, y un bucle de retroalimentación (recategorización manual → reentrenamiento).

Los líderes (Bud, Yodlee, Tink, Heron Data) son todos híbridos, con modelos propietarios entrenados con cientos de millones de transacciones.

La taxonomía: ningún estándar

No existe una taxonomía universal. Cada actor define la suya, normalmente en 2 o 3 niveles:

  • N1 — grandes familias (Alimentación, Transporte, Vivienda, Salario, etc.).
  • N2 — subcategorías (Supermercado, Restaurante, Panadería).
  • N3 — precisiones (cadena comercial, tipo de producto).

Los MCC (Merchant Category Codes, ISO 18245, 4 dígitos asignados por las redes) ayudan pero no bastan: a veces son erróneos o demasiado genéricos (el código 5411 "Grocery Stores" cubre tanto a Carrefour como a un kebab).

Criterios de calidad

  • Coverage: porcentaje de transacciones categorizadas (frente a "Otros"). Objetivo > 95%.
  • Accuracy: porcentaje correctamente categorizado. Objetivo > 90% en N1, > 80% en N2.
  • Latencia: idealmente < 100 ms por transacción para el tiempo real.
  • Multilingüe / multipaís: un actor paneuropeo debe ser igual de preciso en FR, DE, IT, ES, PL.
  • Estabilidad: no recategorizar de forma distinta la misma transacción de una llamada a otra.

Caso profesional: la categorización contable

Para el BFM y la contabilidad automática (Pennylane, Qonto, Indy), el ejercicio es más complejo: hay que vincular la transacción a un plan contable (PCG, NIIF), gestionar el IVA (deducible o no, tipos variables), producir líneas de asiento y conciliar automáticamente transacciones y facturas. Así, una línea "FOURNITURES BUREAU" (material de oficina) debe convertirse en "Cuenta 6064, IVA 20% deducible".

Lo que la categorización no es

  • No es el enriquecimiento: la categorización infiere la categoría; el enriquecimiento añade logo, geolocalización, MCC y ficha de empresa. Dos capas distintas, a menudo combinadas.
  • No es un servicio regulado: no se requiere ninguna autorización de la ACPR para categorizar; un AISP que categoriza sus propios datos sigue siendo AISP.
  • No es universal: los conceptos, los MCC y los comportamientos difieren por país; un modelo global rara vez iguala a un modelo por país.
  • No es estática: cada nuevo comercio (TikTok Shop, un nuevo operador) debe aprenderse de forma continua.

En el ecosistema PSD2

La categorización no forma parte de la PSD2 stricto sensu (que solo define el transporte de los datos), pero es el principal valor añadido por encima del AIS: sin ella, los datos siguen siendo conceptos en bruto. Es lo que justifica el modelo de negocio de los agregadores y de las soluciones de PFM/BFM.

Ejemplos concretos

  • Líderes: Bud (UK), Heron Data (UK, enfoque profesional), Yodlee (US, comprada por Envestnet), Tink (Suecia, Visa), Bridge y Powens (FR), MX (US).
  • Bankin' / Lydia / Linxo: a menudo se apoyan en el motor de Powens o de Bridge; Bankin' tiene también su motor histórico.
  • Pennylane: categorización contable (PCG), OCR de facturas y conciliación automática, con una precisión declarada por encima del 95%.
  • Heron Data: se posiciona en el scoring B2B calificando los flujos de una pyme para evaluar su salud financiera.
  • Límite conocido: las transferencias P2P son las más difíciles de clasificar — un "VIRT JEAN DUPONT" sin contexto sigue siendo inclasificable; muchos PFM las dejan "por clasificar".
  • Coste: típicamente de 0,001 a 0,01 € por transacción en los líderes — significativo sobre millones de transacciones al día, de ahí la internalización en los grandes actores.
  • Evolución: uso de LLM para categorizar conceptos inéditos en zero-shot (probado en Heron, Bud) — más precisión en la cola larga, pero un coste de inferencia superior.

Fuentes

Profundizar

En el blog

Lecturas más completas para ir más allá de la definición.

7 de abril de 2026
técnico

Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código — Leer el artículo

Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación.

6 de abril de 2026
regulación

Entender la PSD2: lo que cambia para sus clientes y su negocio — Leer el artículo

Todo lo que un directivo, un product manager o un equipo de negocio debe entender de la PSD2 (DSP2). Actores, consentimiento, oportunidades, sin jerga técnica.