La Ingeniería detrás de la Interoperabilidad: Conectando Directorios Centralizados y Federados sin fricción
Para el usuario final, la promesa de Bre-B es simple: escribir un número de celular y enviar dinero. Para el ingeniero de pagos, esa simplicidad esconde uno de los desafíos arquitectónicos más complejos del ecosistema: la orquestación en tiempo real entre múltiples Directorios Federados y un Directorio Centralizado (DICE). Si la sincronización falla, la inmediatez desaparece.
En el nuevo esquema de pagos inmediatos de Colombia, la “Llave” (alias) es el activo más valioso. Ya sea un número celular, un correo electrónico o un código alfanumérico, este dato es el enrutador que define a dónde va el dinero. Pero a diferencia de los sistemas cerrados, Bre-B exige que esta llave sea única y resoluble en todo el sistema financiero nacional en milisegundos.
¿Cómo se logra esto técnicamente sin crear cuellos de botella? La respuesta no está en una base de datos gigante, sino en una arquitectura distribuida y sincronizada de alta precisión.
La Arquitectura: No es una sola base de datos, es un ecosistema
El modelo definido por el Banco de la República no centraliza toda la operación, sino que federa la responsabilidad para ganar eficiencia. Entender esta distinción es vital para cualquier equipo de tecnología bancaria:
- El Directorio Federado (La Capa de Borde): Cada Sistema de Pago de Bajo Valor Inmediato (SPBVI), como Transfiya o Redeban, administra su propio directorio. Aquí residen las llaves de los clientes de sus entidades participantes. Es la primera línea de consulta para operaciones Intra-SPBVI (dentro de la misma red).
- El Directorio Centralizado – DICE (La Fuente de la Verdad): Operado por el Banco de la República, es el repositorio maestro. No procesa el pago, pero gobierna la existencia de la llave. Su función crítica es asegurar que una llave (ej. un número de celular) no esté duplicada en dos bancos diferentes y resolver el enrutamiento para operaciones Inter-SPBVI (entre redes distintas).
El Reto de Ingeniería: Sincronización en Tiempo Real (JSON y API REST)
El desafío no es consultar; el desafío es mantener la consistencia. Cuando un usuario registra su celular como llave en su Banco A, esa información debe viajar al Directorio Federado del SPBVI y replicarse inmediatamente en el DICE.
Si este proceso no es atómico, corremos el riesgo de colisiones de llaves. La ingeniería detrás de esto se basa en estándares estrictos de mensajería:
- Conectividad: Se utilizan conexiones API-REST para la comunicación entre los participantes, los Directorios Federados y el DICE.
- Formato de Datos: El intercambio se realiza bajo estándar JSON, permitiendo una estructura ligera y rápida, esencial cuando el time-out para resolver una llave es de apenas 5 segundos.
Resolviendo la “Llave” en Milisegundos
Cuando se inicia un pago, el sistema no “busca” al usuario por su nombre; ejecuta una consulta técnica de alta velocidad.
- Consulta Local: El sistema verifica primero en el Directorio Federado.
- Consulta Centralizada: Si la cuenta destino está en otra red, la consulta escala al DICE.
- Respuesta: El directorio devuelve la información técnica necesaria (Entidad receptora, tipo de cuenta cifrada) para construir el mensaje de pago ISO 20022 (pacs.008).
Todo esto debe ocurrir de forma invisible. Si la latencia de red o el procesamiento de la base de datos supera los umbrales definidos, la experiencia de “pago inmediato” se rompe.
Gestión del Ciclo de Vida: CRUD en un entorno distribuido
La fricción técnica suele aparecer no en el pago, sino en la gestión de la llave. La regulación de Bre-B exige procesos claros de Registro, Modificación, Cancelación y Portabilidad.
El caso de uso más crítico es la Portabilidad: Un usuario decide mover su “Llave” (celular) del Banco A al Banco B. Desde la ingeniería, esto implica una transacción compleja:
- El Banco B solicita el registro.
- El DICE detecta que la llave ya existe en el Banco A.
- Se debe ejecutar un proceso de desvinculación y nueva vinculación casi simultáneo para evitar que el usuario quede “innacesible” para recibir fondos. La normativa exige que, tras un cambio, la llave esté operativa para recibir pagos en máximo 2 horas, pero la infraestructura debe estar preparada para hacerlo en tiempo real.
Cómo lo abordamos en Kuvasz
En Kuvasz Solutions, entendemos que los Core Bancarios tradicionales no están diseñados para gestionar esta lógica de directorios distribuidos ni la mensajería JSON/ISO 20022 a la velocidad que exige Bre-B.
Nuestra plataforma Brizmo actúa como el orquestador inteligente. No solo conecta con el SPBVI; gestiona la lógica de las llaves. Brizmo mantiene la coherencia de los datos, maneja los reintentos en caso de time-outs y asegura que la mensajería hacia el DICE cumpla con los estándares de seguridad y sintaxis exigidos por el Banco de la República.
La interoperabilidad no es magia; es arquitectura bien ejecutada.
Conectar directorios centralizados y federados requiere precisión quirúrgica en el manejo de datos para que, al final del día, el dinero llegue a donde tiene que llegar, en segundos.
Kuvasz Solutions es una compañía con más de 17 años de experiencia en infraestructura transaccional en América Latina. Acompañamos a bancos, procesadoras y grandes comercios en la modernización de sus plataformas de pago, combinando operación de misión crítica, integración y productos especializados.
Fuentes:
- Arquitectura de Directorios Federados y Centralizado (DICE).
- Estándares técnicos API-REST y JSON.
- Procesos de gestión de llaves y portabilidad.
