Apple y Goldman perdieron miles de disputas en un estado que nadie sabía que existía. Costó 89 millones de dólares.

En junio de 2020, Apple añadió un formulario al flujo de disputas de la Apple Card. Una cosa pequeña. Antes del cambio, tocabas "Reportar un problema", llegabas a una conversación de Mensajes con Goldman Sachs y tu disputa se tramitaba. Después del cambio, tenías que rellenar un segundo formulario una vez que el primer envío estaba hecho.

Esto es lo que hizo esa cosa pequeña. Si reportabas tu problema en Mensajes pero nunca completabas el segundo formulario, el sistema decidía que tu disputa estaba incompleta. Nunca se enviaba a Goldman. Nadie la investigaba. Jamás salía una carta de acuse de recibo. Y bajo la Regulación Z, Sección 1026.13, muchos de esos primeros mensajes eran Avisos de Error de Facturación válidos: del tipo que un acreedor está legalmente obligado a acusar en un plazo de 30 días y resolver en dos ciclos de facturación.

Miles de ellos simplemente se quedaron ahí. Enviados, pero sin ruta alguna. En octubre de 2024, la Oficina de Protección Financiera del Consumidor ordenó a Apple y a Goldman Sachs pagar 89 millones de dólares por ello, y prohibió a Goldman lanzar una nueva tarjeta de crédito sin un plan de cumplimiento creíble. He dedicado buena parte de mi carrera a las operaciones de disputas dentro de un emisor de tarjetas, y cuando leí esa orden no vi negligencia. Vi una máquina de estados con un agujero, y un agujero que todos los bancos que conozco tienen en algún punto de su propio flujo de trabajo en este momento.

Eso es de lo que quiero convencerte en este ensayo: tu sistema de disputas tiene estados muertos que aún no has encontrado, y la razón por la que no los has encontrado es que has estado probando en su busca en lugar de demostrar que no pueden existir. La solución es una técnica que a la mayoría de los banqueros nunca se les ha ofrecido —la verificación formal— y es la razón por la que construimos la práctica de verificación de cumplimiento financiero de Veriprajna en torno a ella.

El error de 89 millones de dólares fue un estado, no una equivocación

Permíteme ser preciso sobre lo que salió mal, porque la precisión es justamente el quid de la cuestión.

El flujo de trabajo de Apple-Goldman tenía un estado alcanzable que podías describir en una sola línea: la disputa estaba en FormA_Submitted AND FormB_Pending. Desde ese estado, no había transición a Investigation_Initiated. Ninguna. Un consumidor que se detenía tras el primer mensaje vivía ahí permanentemente: con derecho a un acuse de recibo por ley, y con derecho a nada según la propia lógica del sistema.

Las disputas no se perdieron. Estaban exactamente donde el sistema las había puesto. Al sistema simplemente nunca se le dijo que "aquí" era un lugar donde una disputa podía morir.

Cuando mi equipo recorrió esto por primera vez en una pizarra, un ingeniero dijo lo obvio: que era solo un error, del tipo que habríamos detectado en las pruebas. Le pregunté cómo. El flujo de Apple-Goldman era un punto de integración entre dos sistemas. La mayoría de los grandes emisores con los que he trabajado tienen de 10 a 15 sistemas que tocan una sola disputa: el portal VROL de Visa, el GCMS de Mastercard, la plataforma de gestión de casos, el libro mayor de la banca central, el sistema de generación de cartas, el feed de la agencia de crédito, el motor de crédito provisional y un puñado de colas de enrutamiento internas. Cada cambio de API, cada integración de socios, cada nueva función de producto abre caminos nuevos a través de ese laberinto.

Las pruebas comprueban los caminos que se te ocurrió anotar. Son, por definición, una lista de los fallos que ya imaginaste. El estado muerto de Apple-Goldman fue un fallo que nadie imaginó, que es precisamente la razón por la que ninguna prueba lo cubría. No puedes salir a base de pruebas de un problema que no puedes imaginar. Eso no es un fallo de proceso. Es un techo matemático.

¿Por qué no podíamos simplemente escribir más pruebas?

Perdí una tarde con esta discusión, así que déjame ahorrarte la tarde.

El contraargumento del ingeniero era razonable: escribir más casos de prueba. Cubrir más caminos. Subir la cobertura. Así que lo dibujé. Un flujo de trabajo de disputas no es una línea, es un grafo: ramas por tipo de disputa, por red, por si se emitió crédito provisional, por qué régimen de plazos aplica, por si un sistema socio acusó el traspaso. Cada rama multiplica la anterior. Un flujo con unas pocas docenas de puntos de decisión tiene más estados alcanzables de los que jamás escribirás pruebas, y los peligrosos son las combinaciones que nadie se sienta a enumerar porque parecen absurdas hasta que suceden.

Siguió un rato más. Entonces dibujé la explosión combinatoria —el número de estados duplicándose, y luego duplicándose otra vez— y se detuvo. No le ganas a un espacio de estados a base de pruebas. Se te acaban las monedas antes de que se te acaben los estados.

Este es el momento en que empecé a leer en serio sobre métodos formales, y la técnica que importa aquí tiene una descripción sencilla. Un verificador de modelos toma un modelo de tu flujo de trabajo y un invariante —una propiedad que siempre debe cumplirse— y luego explora todos los estados alcanzables, de forma exhaustiva, buscando uno donde la propiedad se rompa. Escribe el invariante como "toda disputa enviada llega al acuse de recibo en un plazo de 30 días", apunta el verificador al flujo de Apple-Goldman y te devuelve el estado muerto en segundos, junto con el camino exacto, paso a paso, que te lleva hasta él. Herramientas como TLA+ hacen esto para sistemas distribuidos; la misma lógica aplica limpiamente a un flujo de trabajo regulado con plazos estrictos.

Las pruebas muestrean los caminos que imaginaste. Un verificador de modelos visita los que no.

La colisión de plazos que nadie asume

La parte que quita el sueño a los gestores de disputas es peor que un solo estado muerto.

Una sola disputa de una tarjeta de doble red puede disparar tres o cuatro relojes regulatorios y de red al mismo tiempo. La Reg Z exige un acuse de recibo por escrito en 30 días y resolución en dos ciclos de facturación, con un tope de 90. La Reg E, que rige los errores de débito y de transferencia electrónica, funciona con un calendario completamente distinto: crédito provisional y resolución en 10 días hábiles, con una prórroga de 45 días naturales. La Resolución de Reclamaciones de Visa tramita los casos de Asignación hasta 70 días y los de Colaboración hasta 100. El marco de disputas de Mastercard tramita de 45 a 120 según el ciclo, y la industria describió su implementación como aún más difícil de absorber que la de Visa.

Cuando esos regímenes colisionan en una sola disputa, el cumplimiento se reduce a quien esté en el escritorio de disputas y recuerde qué plazo rige esa mañana. He visto a un analista sénior aplicar los tiempos de la Reg E a un error de facturación de la Reg Z porque los dos se confunden bajo el volumen, y esa confusión exacta es una de las infracciones que buscan los examinadores de la CFPB. A Citizens Bank lo citaron, en parte, por denegar avisos de error de facturación por falta de una declaración jurada. Los plazos no son flexibles. Son binarios. O acusaste el recibo en 30 días o no lo hiciste.

Y esta es la razón silenciosa por la que la verificación formal encaja con el cumplimiento financiero mejor que con casi cualquier otro dominio que se me ocurra: las reglas ya son matemáticas. Treinta días no es una cuestión de criterio. "Crédito provisional en 10 días hábiles" no es una impresión. Son restricciones temporales sobre una máquina de estados, y la lógica temporal se construyó para demostrar exactamente este tipo de propiedad: que a lo largo de todos los caminos posibles que una disputa puede tomar, ningún reloj se dispara jamás.

Primero construí lo que no era

Quiero contarte la versión que lanzamos que no funcionó, porque es la versión que la mayoría del mercado sigue vendiendo.

Nuestro primer instinto fue el monitoreo. Construir un sistema que rastrea cada disputa, vigila los plazos y se enciende en rojo cuando una está a punto de incumplirse. Tableros. Alertas. Una cola de crédito provisional con cuenta regresiva: 9 días, 23 horas, ya. Se demostraba de maravilla. Estaba orgulloso de él.

Luego se lo mostré a una responsable de cumplimiento en un banco piloto, y me lanzó un encogimiento de hombros cortés. Me llevó unos días entender ese encogimiento. Un monitor te dice que una disputa está muriendo mientras muere. Es una alarma de humo. Da por sentado que la disputa entró en el sistema para poder ser rastreada en primer lugar, que es precisamente la única suposición que Apple-Goldman hizo añicos, porque esas disputas nunca fueron rastreadas en absoluto; estaban en un estado que el rastreador no sabía que debía vigilar. El monitoreo es confesión después de los hechos. Es que el banco descubra su propio fallo un poco antes de que lo hiciera el examinador. Eso vale algo, pero no es lo que ella necesitaba poner ante su junta directiva.

El monitoreo te compra el fallo unos días antes de que lo haga el examinador. Nunca te compra el fallo que no puede suceder.

Ese encogimiento de hombros nos costó una reconstrucción, y fue lo mejor que le pasó al producto. El mercado está abarrotado de aquello que construí primero. FINBOA rastrea los plazos de la Reg E y automatiza el crédito provisional; es buena en ello. Quavo automatiza el procesamiento de disputas y publica cifras reales: una cooperativa de crédito alcanzó una tasa de automatización del 87 % en un mes. FIS procesa contracargos a través de los portales de las redes. Cada una de ellas automatiza o vigila las disputas que entran en el sistema. Ninguna de ellas demuestra que una disputa no pueda perderse antes de entrar.

¿Quién más está de verdad demostrando algo?

Tras la reconstrucción salí a buscar quién más estaba demostrando cosas, en lugar de vigilarlas, y la respuesta es casi nadie.

El único nombre serio es Imandra. Hacen verificación formal de verdad en servicios financieros —pruebas matemáticas de corrección— y entre sus clientes está el propio Goldman Sachs. Pero su mundo son los mercados de capitales: lógica de casación de bolsa, protocolos de negociación. El cumplimiento del consumidor, la Reg Z, los flujos de trabajo de disputas: no es a lo que apuntan, y con unos 5 millones de dólares de financiación total, no han apuntado ahí.

Mientras tanto, el capital se está volcando en el otro rincón del cumplimiento. Bretton AI, antes Greenlite, levantó una Serie B de 75 millones de dólares en febrero de 2026 y presta servicio a bancos regulados por la OCC, para KYC, antilavado de dinero e incorporación de clientes. La plataforma Sensa de SymphonyAI redujo los falsos positivos en el cribado de sanciones de un banco español en un 91,8 %. Alloy orquesta la identidad en más de 800 instituciones. Dinero real, ingeniería real: todo ello dirigido al delito financiero y a la incorporación de clientes, nada de ello a si tu resolución de disputas puede infringir una regulación.

Esa es la brecha, y no es estrecha. Los actores más cercanos al trabajo de disputas (FINBOA, Quavo) lo automatizan sin verificarlo. El único verificador (Imandra) trabaja en un mercado distinto. Combina esos dos y obtienes un rincón del campo en el que, por lo que puedo ver, nadie está parado: la verificación formal dirigida al cumplimiento de disputas del consumidor. Ese es el rincón al que entramos.

La frase que reconstruyó nuestra propuesta

Lo que finalmente hizo que el valor calara en mí no vino de un ingeniero. Vino de una exexaminadora con la que me senté.

Le pregunté qué quería en realidad tener en la sala durante una revisión de errores de facturación. No dijo "buenos tableros". Dijo, más o menos, que quería saber que el banco podía demostrar que su proceso no podía incumplir el plazo, no que normalmente no lo incumplía. Toda la postura cambia con esa sola palabra. La diapositiva de certificación para la junta directiva que dice "lo probamos y pasó" es una admisión de que solo comprobaste los caminos que se te ocurrieron. Una prueba dice algo categóricamente más fuerte: a lo largo de todos los caminos que el flujo de trabajo permite, el invariante se cumple.

Y los reguladores están caminando silenciosamente hacia esto por su cuenta. El Boletín 2025-26 de la OCC aclaró que cualquier método cuantitativo que impulse de forma material una decisión de riesgo o cumplimiento es un "modelo", y el boletín es explícito en que la sofisticación de la IA o del aprendizaje automático no la exime de validación. Léelo con atención: un enrutador automatizado de disputas es ahora examinable como un modelo, no solo como una herramienta operativa. Y la verificación formal es la validación de modelos más fuerte que existe. No muestrea el comportamiento. Demuestra la propiedad.

Al otro lado del Atlántico, la Ley de IA de la UE clasifica la IA de crédito y de solvencia crediticia como de alto riesgo, con un plazo estricto de cumplimiento del 2 de agosto de 2026, y un alcance extraterritorial que atrae a los proveedores estadounidenses que prestan servicio al mercado de la UE. La clasificación de alto riesgo significa que debes demostrar propiedades comprobables del sistema: exactitud, robustez, supervisión. Es decir, de nuevo, exactamente lo que una prueba entrega y una prueba de software no puede.

¿No es esto excesivo para una cola de disputas?

La gente me hace alguna versión de esto constantemente, así que déjame abordar de frente las tres objeciones honestas.

La primera es el costo. La verificación suena como un proyecto de ciencias, y la alternativa de la consultoría —una firma de las Cuatro Grandes rediseñando tu proceso— cuesta entre 500 000 dólares y varios millones y te entrega un proceso rediseñado que nadie comprobó matemáticamente. Contrasta eso con el riesgo. Apple-Goldman fueron 89 millones de dólares. La orden de consentimiento de Wells Fargo, por múltiples fallos entre ellos el manejo de disputas, ascendió a 3700 millones de dólares. No estás comprando la verificación frente al costo de una licencia de SaaS; la estás comprando frente a la cola.

La segunda es "nuestro volumen está bien". Se proyecta que los contracargos globales alcancen los 337 millones anuales para 2026 y que suban un 24 % hasta 2028, con tipos de disputa completamente nuevos por llegar, incluidas disputas de agentes de IA autónomos que compran cosas que los clientes nunca aprobaron. El escritorio manual que "lo maneja" hoy es el mismo escritorio donde el 42 % de las instituciones aún llevan el cumplimiento con procesos manuales, según el informe del primer trimestre de 2026 de Wolters Kluwer. El volumen creciente sumado a la memoria manual es cómo un estado muerto pasa desapercibido durante cuatro años.

La tercera es "pasamos nuestro último examen". También lo hicieron Apple y Goldman, presumiblemente, justo hasta que dejaron de hacerlo. Pasar un examen significa que un examinador muestreó tus caminos y no dio con el que estaba roto. Es el mismo problema de muestreo que las pruebas, con una insignia distinta.

Lo que creo ahora

Entré en las operaciones de disputas pensando que el cumplimiento era una disciplina de diligencia: gente cuidadosa, buenas listas de verificación, plazos cumplidos. Salí de ellas convencido de que la diligencia es la herramienta equivocada para un problema con esta forma. No puedes ser lo bastante diligente como para cubrir un espacio de estados que se duplica cada vez que alguien lanza una función. La gente cuidadosa de Apple y de Goldman no perdió esas disputas por descuido. Las perdió por un estado que nadie dibujó.

Así que la pregunta que le plantearía a cualquiera que dirija un escritorio de disputas no es "¿es cuidadosa tu gente?". Es más estrecha y más fría que eso: ¿puedes dibujar el estado en el que morirá tu próxima disputa perdida? Si no puedes dibujarlo, no puedes probarlo, y si no puedes probarlo, lo único honesto que queda es demostrar que no puede existir. Ese es el trabajo: demostrar que tus flujos de trabajo de disputas no pueden infringir la Reg Z, la Reg E y los plazos de las redes, en cada camino, antes de que un examinador encuentre el que se te escapó. Si esa es la garantía que de verdad necesitas, eso es lo que construimos.

Apple tenía miles de ingenieros y aun así un estado muerto. Los ingenieros nunca fueron la variable que faltaba. Lo era una prueba.