Entre el 30 de septiembre y el 1 de octubre, Daviplata presentó bajos niveles de aprobación y después una indisponibilidad total dentro del ecosistema Bre-B. Otros actores del sistema, como la fintech Cobre, tuvieron que salir a aclarar públicamente que la falla no era suya. Ese episodio, ocurrido esta misma semana, es la versión real de exactamente el escenario que discutimos en nuestro webinar de aseguramiento de calidad para pagos inmediatos: en un ecosistema interoperado, el sistema solo es nuestro una parte.

El 30 de septiembre, cerca de las siete de la noche, Daviplata, uno de los participantes del sistema de pagos inmediatos Bre-B, empezó a mostrar niveles bajos de aprobación y demoras en las transferencias, tanto para quien enviaba como para quien recibía dinero. La situación se extendió durante horas. Al día siguiente, 1 de octubre, cerca de la una de la tarde, el mismo participante presentó una indisponibilidad completa que duró más de siete horas. Cobre, una fintech colombiana que opera como participante del ecosistema, tuvo que publicar en su página de estado que la afectación era externa, atribuible a Daviplata y a la infraestructura del Banco de la República, y aclarar explícitamente que no tenía relación con una falla en sus propios servicios.

Ese episodio, ocurrido esta misma semana, es la ilustración más clara posible de algo que discutíamos a fondo en vivo, mientras esta situación transcurría. Mauricio Buitrago, líder de automatización en Q-Vision, lo planteó así en esa sesión: en un ecosistema de pagos interoperado, cada institución solo controla una parte del flujo completo, y certifica contra reglas de un sistema que no le pertenece del todo. Lo que le pasó a Cobre esta semana es exactamente eso, llevado a la práctica: su infraestructura funcionaba correctamente, pero el cliente final no tenía forma de saberlo, porque la experiencia de usuario no distingue de quién es la falla.

Carol Ortega, líder de performance, lo dijo de otra forma en esa misma conversación: al final, para el cliente, es transparente quién tuvo el error. El cliente vive la falla en la aplicación que tiene abierta, sin importar si el problema está tres pasos más atrás, en un participante que ni siquiera conoce por nombre. Eso es precisamente lo que vivieron esta semana los usuarios de Bre-B que intentaron enviar o recibir dinero mientras Daviplata estaba indisponible: la mayoría probablemente nunca supo que el origen del problema no era su propio banco, ni la aplicación que tenían abierta en ese momento.

Esto conecta directamente con algo que Mauricio planteó como recomendación concreta: construir simuladores de los otros participantes del ecosistema que no se limiten a responder "todo correcto", sino que puedan reproducir exactamente lo que ocurrió esta semana: bajos niveles de aprobación, demoras, indisponibilidad total, antes de que ocurra en producción. El ambiente de certificación de un ecosistema de pagos inmediatos sirve para confirmar que los mensajes cumplen el estándar. No sirve, por diseño, para explorar qué pasa cuando un participante entero deja de responder durante siete horas en medio de un día hábil cualquiera.

Lo que hace que esta conversación no sea una preocupación hipotética es que la propia presidenta del sistema de pagos, Ana María Prieto, ya lo reconoció públicamente meses atrás: la expansión de Bre-B hacia comercios va a introducir nuevos patrones de fraude, en un entorno donde los controles todavía deben adaptarse a mayores volúmenes y nuevas dinámicas transaccionales. No es una advertencia externa. Es la directora del sistema diciendo, desde adentro, que el crecimiento trae consigo una superficie de riesgo que los controles actuales no cubren por completo todavía.

Esa advertencia ya se materializó de otra forma en los meses siguientes: desde marzo, las autoridades de seguridad de Bogotá han tenido que emitir al menos cuatro alertas distintas sobre campañas de smishing: mensajes de texto fraudulentos que suplantan a Bre-B para robar información bancaria, con oleadas documentadas en marzo, julio y agosto. Ninguna de esas campañas explota una falla técnica del sistema, erosiona la confianza que los usuarios depositaron en un nombre que ya reconocen, exactamente el tipo de escenario que Freddy Silva, líder de pruebas funcionales, describía en nuestro webinar como el verdadero cambio de mentalidad que necesita un equipo de calidad: dejar de pensar solo en si el flujo funciona, y empezar a pensar en qué pasa cuando alguien, deliberadamente, intenta que no funcione como se espera.

Freddy fue enfático en algo durante esa sesión: en pagos inmediatos no hay ventana de reversa. Un duplicado, un débito sin abono, una transacción rechazada sin explicación aparente (como reportaron usuarios de Bre-B durante un incidente similar en octubre del año pasado, coincidiendo con el pago de quincena) ya no son errores que se corrigen en el próximo despliegue. El dinero ya se movió, o el usuario ya vivió la incertidumbre de no saber si se movió, y ambas cosas generan el mismo nivel de desconfianza.

Ese incidente de octubre de 2026 tiene un paralelo casi exacto con el de esta semana: en ambos casos, el problema se originó en un participante específico del ecosistema, afectó a usuarios de múltiples bancos por igual, porque así funciona la interoperabilidad, y se resolvió en cuestión de horas. La diferencia entre un incidente que se vuelve un titular incómodo y uno que pasa casi inadvertido no está en la causa técnica. Está en qué tan rápido el ecosistema completo puede detectar, contener y comunicar lo que está pasando.

No hay forma de garantizar que un participante de un ecosistema de pagos interoperado nunca vuelva a fallar; eso excede lo que cualquier institución individual puede controlar. Lo que sí está dentro del control de cada participante es qué tan bien probó, de antemano, qué le pasa a su propia experiencia de usuario cuando el participante del que depende, ya sea un banco, una billetera digital o el directorio centralizado de llaves, deja de responder, responde tarde, o responde con un estado incierto.

Eso exige exactamente los tres frentes que discutimos en nuestro webinar, ahora con evidencia de esta misma semana que los respalda: simuladores capaces de reproducir la falla de un tercero, no solo su funcionamiento ideal; pruebas de rendimiento integradas en cada ciclo, no reservadas para un ejercicio trimestral aparte; y una disciplina de pruebas funcionales que ya no se pregunta únicamente si el flujo feliz funciona, sino qué tan bien se comporta el sistema propio cuando el resto del ecosistema no coopera.

La institución que ya tenga esa disciplina resuelta no va a evitar que el próximo Daviplata, el próximo participante, falle alguna vez. Va a evitar que esa falla ajena se convierta en una falla propia a los ojos del cliente que, al final, solo quiere ver que su dinero llegó.