Cuando un cliente paga con su tarjeta, el sistema emisor del banco recibe un paquete de datos de transacción de la red de tarjetas, estructurado de forma rígida pero sorprendentemente escueto. Los campos están estandarizados, los valores son limitados y gran parte de lo que un usuario final espera ver en su aplicación (como nombres de comerciantes, logotipos, categorías reconocibles, ubicaciones exactas de las tiendas) simplemente no está en el mensaje. Todo, desde la claridad del extracto bancario hasta la toma de decisiones crediticias, se construye a partir de esta información bruta, lo que convierte la brecha entre lo que llega y lo que el cliente necesita en el problema de datos más importante de la banca minorista.
Cómo se generan los datos de las transacciones de la red de tarjetas
Toda transacción con tarjeta pasa por tres etapas diferenciadas: autorización, compensación y liquidación. La autorización es la verificación en tiempo real que se realiza en los segundos posteriores a que el titular de la tarjeta pague o introduzca su PIN. El terminal del comercio envía una solicitud a través del adquirente a la red de tarjetas (Visa, Mastercard, Amex, Discover), que la dirige al banco emisor para que decida si aprueba o deniega la operación. La mayoría de estos mensajes se basan en ISO 8583, el estándar que rige la mensajería de tarjetas desde 1987.
La compensación se produce más tarde, normalmente en lotes al final del día. Es el momento en que el adquirente presenta formalmente la transacción para el movimiento de fondos, y puede contener datos ligeramente diferentes o más detallados que el mensaje de autorización original.
La mayor parte de los datos que utiliza un banco para las funciones en tiempo real orientadas al cliente (notificaciones push, feeds en la aplicación, controles de fraude) provienen del mensaje de autorización. Ese mensaje fue diseñado para ser rápido en la infraestructura de telecomunicaciones de los años 80, no para ser legible por humanos.
Qué datos contiene un mensaje de pago
Un mensaje típico de autorización de tarjeta contiene un pequeño conjunto de campos que son relevantes para los productos bancarios posteriores. ISO 8583 hace referencia a estos mediante un número de elemento de datos; Visa los denomina "Campo x" y Mastercard "DE x", con una numeración ampliamente alineada pero no idéntica.
Los campos que el sistema emisor de un banco extrae de forma fiable incluyen:
- Número de cuenta principal (DE 2) - el número de la tarjeta, utilizado para identificar la cuenta.
- Importe y divisa de la transacción (DE 4 y DE 49) - el valor cargado y el código de divisa ISO 4217.
- Fecha y hora (DE 7 y DE 12) - cuándo se inició la transacción, en hora de red y hora local.
- Código de categoría de comerciante (DE 18) - un código ISO 18245 de cuatro dígitos destinado a clasificar la línea de negocio principal del comerciante.
- Modo de entrada del TPV (DE 22) - cómo se leyó la tarjeta: chip, sin contacto, banda magnética, manual, comercio electrónico.
- ID del adquirente (DE 32) - identifica al banco adquirente que enruta la transacción.
- ID del terminal del aceptador de tarjeta (DE 41) - el terminal donde se realizó el pago.
- ID del aceptador de tarjeta, también llamado ID de comerciante o MID (DE 42) - identifica al comerciante dentro del sistema del adquirente.
- Nombre y ubicación del aceptador de tarjeta (DE 43) - una cadena de texto libre, generalmente limitada a unos 40 caracteres, que contiene el descriptor del comercio, la ciudad y el código de país.
- BIN de la tarjeta - los primeros seis a ocho dígitos del PAN, que identifican a la institución emisora y al producto de tarjeta.
Eso es, esencialmente, la información en bruto. Es suficiente para que el emisor tome una decisión de autorización y registre una línea en el libro contable del titular de la tarjeta. No es suficiente para completar una pantalla de transacciones clara en una aplicación de banca móvil.
DE 43 causa la mayor parte del daño visible en los productos orientados al cliente. El adquirente o procesador lo completa como texto libre restringido: SQ *NOMBRE COMERCIO LDN, PAYPAL *ABOUTYOUSEC, WWW.SHOP.COM 4083334000 CA, o un nombre comercial simple con una etiqueta de ciudad. La mayoría de los bancos muestran esta cadena de datos sin procesar a menos que inviertan en enriquecimiento.
Lo que no se incluye
Igual de importante es lo que el mensaje de red no transporta. No hay un nombre de marca comercial claro, ni logotipo, ni dirección física verificada, ni desglose a nivel de producto de lo que se compró, ni una categoría de gasto orientada al consumidor. No hay información sobre si el comercio es una franquicia, una marca dentro de un mercado o un subarrendatario de un centro comercial. Rara vez hay una URL utilizable, nunca un número de teléfono y casi nunca un identificador de ubicación estructurado como un Google Place ID.
El campo MCC da pistas sobre el sector del comercio, pero fue diseñado para el cálculo de comisiones de intercambio, no para la categorización orientada al consumidor. La brecha se amplía en línea: cuando un cliente paga a través de una pasarela como Stripe, PayPal o Adyen, el descriptor a menudo refleja la pasarela en lugar del negocio subyacente, y el MCC puede seguir la clasificación del procesador.
Estas brechas no son errores en el protocolo de red. ISO 8583 fue creado para mover dinero, no para mostrar compras detalladas a un usuario. Llenar ese vacío es problema del banco.
Por qué los datos sin procesar varían entre redes
Dentro del ISO 8583 marco de trabajo, cada red de tarjetas mantiene sus propias extensiones y convenciones. Visa, Mastercard, Amex, Discover y JCB publican sus propias especificaciones que definen qué campos opcionales utilizan, qué subcampos completan y cómo se codifican los valores. Décadas de evolución independiente han hecho que las especificaciones de las redes tengan más diferencias que similitudes a nivel de campo.
Los adquirentes añaden otra capa de variación. La forma en que se formatea el nombre de un comercio en el DE 43, si se incluye la ciudad, si el código de país utiliza dos o tres caracteres y si los prefijos como Square SQ* o PayPal PP* se eliminan o se conservan: todo esto se decide a nivel del adquirente o del procesador. Una misma cadena comercial con múltiples adquirentes en diferentes países puede aparecer ante el emisor bajo una docena de formatos de descripción distintos.
La consecuencia es que una misma compra real, realizada en el mismo establecimiento y en la misma moneda, puede generar cadenas de datos sin procesar muy diferentes en el sistema del emisor, dependiendo de qué red y qué adquirente la hayan gestionado. Esta inconsistencia es la causa principal de la mayoría de los problemas de calidad de datos posteriores.
Por qué esto es importante para los productos de banca digital
Cada función orientada al cliente que interactúa con el flujo de transacciones hereda la calidad de estos datos sin procesar. Una lista de transacciones limpia, notificaciones push con contexto del comercio, búsqueda en la aplicación, filtros inteligentes, información sobre gastos, gestión de suscripciones, herramientas de PFM y presupuestos, evaluación de crédito, flujos de trabajo de fraude y disputas: todos ellos dependen de los mismos campos subyacentes.
Cuando el nombre del comercio es una descripción vaga, el cliente no puede buscarlo ni filtrarlo. Cuando el MCC es incorrecto, la información sobre gastos etiqueta erróneamente la categoría. Cuando la pasarela de pago oculta el comercio subyacente, la detección de pagos recurrentes no logra agrupar los cargos repetidos. El coste posterior se traduce en tickets de soporte, disputas por fraude amistoso, funciones abandonadas y clientes que se marchan silenciosamente a la competencia con aplicaciones mejor presentadas.
En la toma de decisiones crediticias, lo que está en juego es aún mayor. La evaluación de la asequibilidad bajo normativas como CCD2 en la UE depende de clasificar el gasto del cliente en ingresos, gastos esenciales y gastos discrecionales. Si los datos de las transacciones subyacentes son confusos e inconsistentes, cada capa del modelo de crédito se ve afectada. Los modelos de fraude siguen el mismo patrón a la inversa: dependen de detectar desviaciones en el conjunto habitual de comercios del cliente, ubicaciones inusuales o una mezcla de categorías atípica, y las tres señales se desmoronan cuando los comercios tienen nombres inconsistentes, faltan ubicaciones y las categorías se extraen únicamente del MCC.
De campos sin procesar a datos utilizables
Cerrar esta brecha requiere enriquecimiento: una capa de procesamiento deliberada que convierte los datos brutos de la red en resultados listos para el producto. Hace cuatro cosas que el mensaje de red no puede hacer.
Resuelve la identidad del comercioconvirtiendo SQ *KAFFEE 12 LDN, KAFFEE 12 LIMITED y KAFFEE12.COM en una única entidad comercial canónica con un nombre comercial claro, un logotipo de alta resolución y una jerarquía de ubicación verificada. aplica un modelo de categorización que va varios niveles más allá del MCC , capturando no solo "Alimentación y bebidas", sino también la diferencia entre un establecimiento de comida para llevar, un restaurante de alta cocina y una suscripción de café. completa los datos de ubicación a nivel de tienda en lugar de a nivel de sede central, de modo que la dirección que se muestra coincida con el lugar donde realmente se realizó la compra. Y detecta patrones en las transacciones para identificar suscripciones, domiciliaciones bancarias recurrentes y compras divididas que abarcan múltiples eventos de autorización.
Tapix se sitúa exactamente en esta capa. La API recibe datos brutos de tarjetas (descriptor, MCC, MID, ID de terminal, país, importe, divisa) y devuelve un objeto estructurado que contiene el nombre comercial limpio, un logotipo de 512x512, una categoría de cuatro niveles, coordenadas GPS, URL, número de teléfono, ID de Google Place, indicador de pasarela de pago y metadatos de CO2. Funciona con una precisión del 99,99 % y es utilizada por más de 90 bancos y empresas de tecnología financiera en todo el mundo, incluidos Société Générale, UniCredit, Erste, Revolut y bunq, procesando más de 1500 millones de transacciones al mes.
La cuestión no es la API en sí, sino lo que representa a nivel arquitectónico. Los bancos que tratan los datos brutos de las transacciones de la red de tarjetas como el final de la cadena de datos ofrecen productos al cliente con el límite de calidad establecido por la norma ISO 8583. Los bancos que los tratan como el inicio de la cadena —e invierten en una capa de enriquecimiento deliberada entre la red y el producto— obtienen una base sobre la que puede construirse cualquier funcionalidad posterior.
