Pagos inmediatos en Colombia: lo que exige la integración

Por el equipo de Automatización e Integración de Redsis · Octubre 2026 · 6 min de lectura

Bre-B: el punto de inflexión

El 6 de octubre de 2025 entró en operación Bre-B, el sistema de pagos inmediatos interoperado de Colombia, administrado por el Banco de la República. Su diseño tiene dos piezas centrales: un directorio centralizado de llaves (DICE), que identifica la cuenta de cada cliente para recibir pagos, y un mecanismo de liquidación (MOL), que mueve los recursos entre la entidad que envía y la que recibe. El sistema está disponible 24/7/365 e interconecta a los operadores privados de pagos de bajo valor bajo reglas comunes, preservando las inversiones que cada uno había hecho.

La adopción ha sido acelerada. Según el Banco de la República, a enero de 2026 Bre-B ya había procesado más de 370 millones de transacciones por cerca de 59 billones de pesos. Para mayo de 2026, según cifras reportadas por Infobae, el sistema sumaba 34,9 millones de usuarios registrados, más de 105 millones de llaves activas y hasta 5 millones de operaciones diarias, con transacciones que se completan en 6 a 8 segundos, por debajo del máximo regulatorio de 20 segundos.

Una llave puede ser un número de celular, un correo, un documento de identidad u otro identificador autorizado. Al iniciar una transferencia, el sistema valida la llave, verifica la cuenta de destino y ejecuta la liquidación en segundos.

Lo que los pagos inmediatos le exigen a la integración

Detrás de una transferencia de ocho segundos hay una cadena de sistemas que deben hablar entre sí sin fallar: canales digitales, cores bancarios, antifraude, directorios de llaves, operadores y mecanismos de liquidación. Esa cadena impone requisitos que muchas arquitecturas de integración tradicionales no fueron diseñadas para cumplir:

• Disponibilidad permanente. No hay ventana de mantenimiento nocturna ni cierre de fin de semana.
• Latencia de segundos, de punta a punta. Cada salto entre sistemas consume parte de un presupuesto de tiempo muy corto.
• Cero pérdida de mensajes. Un pago no puede perderse ni procesarse dos veces.
• Seguridad en el perímetro. Cada entidad participante es un punto de conexión que debe autenticarse y protegerse.
• Gobierno de API. Versiones, cuotas, credenciales y monitoreo para decenas de consumidores distintos.

Una arquitectura por capas con IBM Cloud Pak for Integration

IBM Cloud Pak for Integration reúne en una plataforma nativa de contenedores, pensada para entornos híbridos, las capacidades que exige una operación de pagos en tiempo real. En el proyecto que acompañamos, cada componente tiene un papel definido:

• IBM API Connect para crear, asegurar, gestionar y publicar las API que consumen los bancos participantes.
• IBM DataPower Gateway para la seguridad y el cifrado de extremo a extremo en la puerta de entrada de las transacciones.
• IBM App Connect Enterprise para integrar sistemas y orquestar la lógica de los flujos de compensación.
• IBM MQ para la mensajería con entrega garantizada y única, que preserva la integridad de cada operación.

Sobre esa base, el proyecto apunta a tres pilares: exposición controlada de API para los bancos participantes, orquestación confiable en tiempo real de los flujos de compensación y dominio de llaves y alias bajo lineamientos de seguridad de la industria.

Cinco lecciones para integrar pagos en tiempo real

1. Separar responsabilidades por capa

Gestión de API, seguridad de gateway, orquestación y mensajería resuelven problemas distintos. Mantenerlas en capas separadas facilita escalar cada una según su carga, aislar fallas y cambiar una pieza sin tocar las demás.

2. Diseñar para la idempotencia

En un sistema distribuido, los reintentos son inevitables. Cada operación debe poder recibirse más de una vez sin generar un pago duplicado, y la mensajería con entrega garantizada es la base para lograrlo.

3. Tratar las llaves como datos críticos

Una llave es, en la práctica, la puerta a una cuenta. Su registro, modificación y consulta deben seguir controles de seguridad estrictos, con trazabilidad completa y protección frente a enumeración y fraude.

4. Medir el presupuesto de latencia

Si el estándar exige completar una operación en segundos, cada componente debe tener un objetivo de tiempo propio y visible en el monitoreo. Así, cualquier degradación se detecta antes de que afecte al usuario.

5. Probar como en producción

Picos de quincena, días sin IVA o fechas de pago de nómina generan cargas muy superiores al promedio. Las pruebas de desempeño y de resiliencia deben reproducir esos escenarios, incluidos los fallos parciales, antes de salir a producción.

Un proyecto en marcha

La implementación con el operador sigue en curso, y esperamos compartir resultados medidos cuando concluya. Lo que ya es claro es que los pagos inmediatos han elevado el estándar para toda la industria: cualquier entidad que quiera participar en ese ecosistema necesita una capa de integración diseñada para el tiempo real, la seguridad y la disponibilidad permanente.

¿Por dónde empezar?

Si su entidad está evaluando cómo conectarse al ecosistema de pagos inmediatos o cómo modernizar su capa de integración, vale la pena empezar por un diagnóstico de la arquitectura actual: dónde se pierde tiempo, dónde hay puntos únicos de falla y cómo se gobiernan hoy las API. En Redsis combinamos más de 25 años de experiencia en plataformas de misión crítica para la banca, como IBM Platinum Partner, con soluciones de integración como IBM Cloud Pak for Integration.