Cada vez que se utiliza una tarjeta, ya sea al acercarla, deslizarla o introducir los datos en línea, se genera un flujo de datos de transacciones sin procesar entre bastidores. Los bancos, los procesadores de pagos y las empresas de tecnología financiera reciben estos datos, pero muy pocos logran hacer que sean útiles de inmediato.
Este artículo explica qué son los datos de transacciones, de dónde provienen y por qué son el punto de partida para crear cualquier producto de pago que realmente sea útil para los usuarios.
De dónde provienen los datos de transacciones
Los datos de transacciones no tienen una única fuente. Fluyen desde diversas partes del ecosistema de pagos, y cada fuente los entrega en un formato ligeramente distinto y con un nivel de detalle diferente.
Las redes de tarjetas (Visa y Mastercard) se sitúan en el centro de la mayoría de los flujos de pago de los consumidores, dirigiendo los mensajes de autorización entre los bancos adquirentes y emisores, al tiempo que transmiten un conjunto estandarizado de identificadores y metadatos.
¿Quieres saber más? Lee nuestra guía de cumplimiento para Visa y Mastercard.
Los procesadores de pagos y las pasarelas capturan los registros de las transacciones en el punto de aceptación. Sus datos suelen ser más ricos en detalles a nivel de terminal, pero varían en estructura según el adquirente, el país y la configuración del terminal.
Los bancos adquirentes son responsables de asignar identificadores como el ID de comercio. Sus registros incluyen datos de liquidación junto con los de autorización, lo que significa que la misma transacción puede aparecer de forma distinta en diferentes etapas del ciclo de compensación.
Los proveedores de banca abierta ofrecen una cuarta vía. A través de licencias AISP, los bancos y las empresas de tecnología financiera pueden acceder a datos de transacciones de otras instituciones (a menudo en formatos diferentes y con ciertos campos faltantes), lo que hace que el enriquecimiento de datos sea más importante y, a la vez, más complejo.
La consecuencia práctica es que un mismo evento de pago subyacente puede verse diferente según la fuente que haya generado el registro. La inconsistencia está presente desde el principio.
¿Qué son los datos de transacciones?
Los datos de transacciones son la información bruta generada automáticamente por un sistema de pago; el registro se crea cuando se inicia un pago y se procesa a través del ciclo de liquidación. Incluyen transacciones con tarjeta (ya sean de débito, crédito o prepago), transferencias bancarias entre cuentas y, cada vez más, datos de banca abierta que fluyen a través de canales regulados de intercambio de información. A menudo se utilizan indistintamente como datos de pago, aunque ambos términos pueden tener significados ligeramente distintos según el contexto.
El problema es que rara vez responden a la pregunta que se hace un usuario al abrir su aplicación bancaria: "¿En qué me he gastado esto y dónde?".
¿Qué datos se incluyen?
Cuando un banco o una empresa fintech recibe datos de transacciones de una red de tarjetas, normalmente incluyen un pequeño conjunto de campos estandarizados. Usemos un ejemplo real: una compra en un supermercado Tesco en Praga. Los datos brutos que recibe un banco podrían ser así:
- ID de TPV – 832216
- ID de comercio – 180520062
- Descriptor – TESCO PRAHA EDEN
- MCC – 5411
- Ciudad – PRAHA
- País – CZ
Eso es prácticamente todo. Sin logotipo. Sin dirección exacta. Sin categoría confirmada. Sin URL. Solo un número de terminal, un identificador de cuenta, un nombre de texto libre, un código de cuatro dígitos y una ubicación aproximada. Esta es la materia prima con la que deben trabajar los bancos y las fintechs. Ahora, profundicemos más.
Explicación de los campos clave
¿Qué es un ID de TPV?
Un POS ID (identificador de punto de venta) es el identificador único de un terminal de pago específico dentro de una tienda; cada caja tiene el suyo. Es útil para la conciliación y la detección de fraudes a nivel de adquirente, pero no para identificar dónde compró un usuario.
¿Qué es un ID de comercio (Merchant ID)?
Un ID de comercio es un identificador único asignado a un comercio por el banco adquirente cuando se le autoriza a aceptar pagos con tarjeta, ya sea un MID directo para empresas con suscripción completa o un sub-MID bajo un agregador de pagos. El problema es que los MID no son estables: un minorista como Tesco posee múltiples MID a través de diferentes relaciones de adquisición y países, y las migraciones de terminales pueden generar coincidencias falsas o conexiones perdidas.
¿Qué es un código MCC?
Un MCC (código de categoría de comercio) es un número de cuatro dígitos que describe el tipo de negocio principal de un comercio, especificado por la norma ISO 18245 y desarrollado originalmente para la declaración de impuestos. Se asigna cuando un comercio configura un terminal de pago: Tesco tiene el MCC 5411 (supermercados), una gasolinera el 5541. Los MCC determinan las tasas de intercambio, señalan comercios de alto riesgo y activan las recompensas de las tarjetas. El problema es que suelen ser incorrectos, estar desactualizados o ser demasiado generales, y no existe un estándar universal.
Aprenda sobre qué son los códigos MCC y por qué los necesita para una categorización fiable.
¿Qué es un descriptor de pago?
El descriptor es el nombre del comercio en texto libre que aparece en el registro de la transacción, establecido durante la configuración del terminal. La misma tienda Tesco puede aparecer como "TESCO PRAHA EDEN", "TESCO STORES CZ" o "TESCO SUPERSTORE" dependiendo del adquirente, el firmware del terminal y los datos de incorporación del comercio. En el caso de las grandes cadenas, a menudo contiene números de tienda o nombres abreviados.
¿Qué son la ciudad y el país?
La ciudad y el país son los campos de ubicación más generales en los datos de transacciones sin procesar, transmitidos por la red de tarjetas como parte del mensaje de autorización y entre los campos más fiables del paquete de datos. Su utilidad es limitada: una ciudad puede contener docenas de sucursales del mismo comercio, y el país por sí solo no aporta nada a la identificación del comercio. Ambos son más valiosos como señales de apoyo para la coincidencia de tiendas durante el enriquecimiento, no como identificadores independientes.
Por qué fallan los datos de las transacciones
Los datos de las transacciones fueron diseñados para el procesamiento de pagos, no para la experiencia del usuario. Los campos que contienen (POS ID, Merchant ID, MCC, descriptor) son suficientes para autorizar, enrutar y liquidar un pago. Nunca se pensaron para la experiencia de usuario, por lo que el resultado es evidente:
El mismo comercio aparece como muchas entidades diferentes. Una cadena de supermercados con tiendas en todo el país puede tener docenas de ID de comercio (uno por cada relación de adquisición o región), cientos de POS ID (uno por terminal) y múltiples variantes de descriptor. Desde la perspectiva de los datos sin procesar, todos parecen comercios distintos.
Las categorías son incorrectas o demasiado generales. Un MCC 5999 ("Venta al por menor diversa y especializada") no le dice casi nada. Incluso un código más específico como el 5411 (Supermercados) no distingue entre una tienda de conveniencia de barrio y un supermercado completo. Y debido a que los MCC pueden asignarse erróneamente y rara vez se actualizan, a menudo no reflejan en absoluto el negocio real.
El contexto falta por completo. Los datos de las transacciones sin procesar no contienen logotipos, direcciones precisas, sitios web, coordenadas GPS ni identidad de marca. Para un banco que construye un feed de transacciones moderno, esto significa que cada pago es una hoja en blanco: un número de referencia en busca de significado.
Las consecuencias son significativas: una mala categorización de gastos en las herramientas de finanzas personales, historiales de transacciones desordenados e irreconocibles, análisis poco fiables tanto para el banco como para el usuario final, y una erosión general de la confianza en el producto. Afortunadamente, hay una salida.
Hacer que los datos de las transacciones sean útiles
Para que los datos brutos de las transacciones sean útiles en un producto (una aplicación bancaria, una herramienta de gestión financiera personal o una plataforma de préstamos), deben enriquecerse. El enriquecimiento consiste en tomar los identificadores brutos (posId, merchantId, descriptor, MCC, ciudad, país) y resolverlos en un conjunto de atributos estructurados, legibles y prácticos.
Lo que un producto realmente necesita de una transacción es:
- Un nombre comercial limpio y coherente nombre del comerciante: el nombre de la marca que el usuario reconoce, no la cadena de referencia interna de un adquirente
- Un logotipo de alta resolución logotipo: listo para mostrarse en formatos circulares y cuadrados en una interfaz de usuario
- Un categoría verificada categoría: no el MCC, sino una categoría seleccionada (por ejemplo, "Supermercados", "Moda", "Transporte") con etiquetas adicionales para una mayor precisión
- Datos de ubicación del minorista: dirección postal, coordenadas GPS e, idealmente, un ID de Google Places que pueda vincularse a un mapa
Esta es la brecha entre lo que ofrecen los pagos y lo que requieren los productos de banca digital. Cerrar esa brecha es el objetivo del enriquecimiento de datos de transacciones.
Cómo funciona Tapix
Tapix es un ecosistema de API REST diseñado específicamente para realizar este enriquecimiento. Toma datos brutos datos de pago : transacciones con tarjeta, transferencias bancarias o datos de banca abierta, y devuelve información estructurada y enriquecida sobre el comercio y el establecimiento donde se realizó el pago.
El modelo de datos que utiliza Tapix refleja la jerarquía real del mundo de los pagos:
- Un comercio es el propietario de la marca: Tesco, Shell, Amazon o una cafetería local. Los comercios poseen uno o más establecimientos.
- Un establecimiento es una ubicación física o en línea específica, por ejemplo, una sucursal concreta de Tesco. Cada establecimiento cuenta con una dirección, coordenadas GPS, una URL de sitio web, un ID de Google Places y una categoría.
- Un terminal TPV o pasarela de pago es el punto de aceptación específico dentro de un establecimiento, identificado por un ID de TPV o una referencia de pasarela de pago.
Cuando un banco envía a Tapix una transacción sin procesar (que incluye cualquier combinación de posId,merchantId,descriptor,ciudad, y país si está disponible), Tapix lo resuelve en un shop.uid. Ese identificador de tienda puede utilizarse entonces para recuperar el conjunto completo de datos enriquecidos: el nombre y logotipo del comercio, la dirección de la tienda, su ubicación GPS, su ID de Google Places, si se trata de una tienda física u online, y tanto una categoría principal como etiquetas detalladas extraídas de una taxonomía de más de 25 categorías y 350 etiquetas.
Incluso cuando solo hay datos parciales disponibles, por ejemplo, solo un posId y merchantId : Tapix intentará resolver la tienda, devolviendo un shop.uid si encuentra una coincidencia o un identificador sin resolver que se resolverá a medida que la cobertura de Tapix se amplíe.
Entonces, ¿cuáles son los siguientes pasos? Tapix admite tres vías de enriquecimiento según su fuente de datos: transacciones con tarjeta a través de Visa o Mastercard, transferencias bancarias mediante estándares como SEPA, BACS/Faster Payments y CERTIS, y datos de banca abierta accedidos a través de licencias PSD2 AISP. En los tres casos, el resultado es el mismo: una identidad coherente y estructurada para cada pago, lista para ser mostrada, categorizada y analizada.
