Llegaste al límite. Tienes el query más optimizado que has escrito en tu vida: índices compuestos, particiones por fecha, CTEs anidados, vistas materializadas. Y aun así, ese reporte de balance financiero aparece en pantalla después de 20 minutos. Tu CEO lo abre cada lunes por la mañana. Cada lunes, un Slack o correo electrónico incómodo.

Este no es un problema de código. Es un problema de arquitectura. Y la buena noticia es que tiene solución —una solución que tiene nombre, historia y que hoy vive en producción en empresas desde startups hasta Amazon.

Se llama CQRS. Y hoy te cuento, ¿qué es y cómo funciona? Así se aplica en un sistema financiero real para lograr una mejora de más de 50 veces en el tiempo de respuesta de nuestros reportes críticos.

1. El problema real detrás del query lento

Antes de hablar de la solución, entendamos el problema correctamente. Porque no es solo que “el query es lento”.

Cuando tu base de datos supera los 100 GB, técnicamente estás en territorio de big data. Y el problema con big data no es almacenarlo; es que las bases de datos transaccionales tradicionales fueron diseñadas para una cosa muy específica, y esa cosa no es generar reportes analíticos sobre millones de registros históricos en tiempo real.

Lo que tu BD transaccional hace bien

• Registrar una venta nueva al instante

• Actualizar el saldo de un usuario

• Buscar un registro exacto por ID

• Garantizar que dos procesos no choquen (ACID)

• Operaciones de milisegundos en filas individuales

Lo que te está pidiendo el negocio

• Balance Sheet de los últimos 12 meses

• Revenue por categoría, por región, por hora

• Conciliaciones cruzando millones de transacciones

• Reportes que unen 40+ tablas

• Análisis sobre años de datos históricos

Estás forzando a tu base de datos a hacer algo para lo que no fue diseñada. Y el resultado es predecible: contención de locks, I/O saturado, timeouts y un reporte que tarda más que una reunión de roadmap.

La raíz del problema

Estás usando la misma base de datos para escribir operaciones transaccionales en tiempo real y para leer reportes analíticos masivos. Estas dos cargas de trabajo tienen necesidades radicalmente opuestas —y están peleando por los mismos recursos.

2. ¿Qué es CQRS?

CQRS son las siglas de Command Query Responsibility Segregation. En español: Segregación de responsabilidades entre comandos y consultas.

El concepto fue formalizado por el arquitecto de software Greg Young alrededor de 2010, inspirándose en el principio más simple de CQS (Command Query Separation) de Bertrand Meyer, que dice:

“Un método debería ser un comando que realiza una acción, o una consulta que retorna datos —nunca ambos.”

CQRS lleva esta idea al nivel arquitectónico. No solo separamos los métodos: separamos los modelos de datos, las bases de datos y los sistemas enteros según si su propósito es escribir o leer.

Un ejemplo practico

Imagina que tienes una sola caja registradora que sirve para cobrarles a los clientes y para generar el reporte contable de fin de mes. CQRS dice: usa una caja para cobrar (operaciones en vivo) y usa un sistema separado —optimizado para ello— para generar los reportes. Cada uno hace lo suyo, y los dos lo hacen mejor.

3. La analogía que lo explica todo

Piensa en un restaurante de alta rotación.

En la cocina, hay un sistema de comandas: cada mesero escribe el pedido, el chef lo ejecuta. Aquí la prioridad es velocidad, exactitud y consistencia. Si dos mesas piden el mismo plato, los pedidos no pueden mezclarse. Esto es el modelo de escritura: transaccional, secuencial, fuerte en garantías.

Ahora imagina que el dueño quiere saber cuál fue el plato más vendido el último trimestre, en qué mesa se genera más ticket promedio y a qué hora hay más rotación. Si le pregunta al chef en medio del servicio, el restaurante colapsa. Por eso existe la oficina del contador: toma los mismos datos (las comandas del día), los procesa en otro lugar y genera los reportes sin interrumpir la cocina.

CQRS es exactamente eso: la cocina sigue funcionando a máxima velocidad, y la oficina analítica trabaja con una copia de los datos —optimizada para responder preguntas complejas.

4. La arquitectura en detalle

Veamos cómo se ve esto en la práctica con el flujo completo de datos.

El lado de escritura: Commands

Todo lo que modifica el estado del sistema pasa por aquí. Un pago registrado, una factura emitida, un usuario actualizado. Estos son comandos: tienen intención clara y el sistema garantiza que se ejecutan correctamente, de forma atómica y consistente.

La base de datos de escritura es una BD transaccional clásica —típicamente PostgreSQL o MySQL. Está optimizada para escrituras rápidas, integridad referencial y concurrencia segura. Aquí viven tus garantías ACID.

El lado de lectura: Queries

Todo lo que solo consulta datos vive aquí. Un reporte de balance, el revenue por categoría, una conciliación histórica. Estas son consultas: no modifican nada —y necesitan hacerlo sobre grandes volúmenes de datos sin interferir con la operación.

La base de datos de lectura es una BD analítica, orientada a columnas —como ClickHouse, BigQuery, Redshift o DuckDB. Puede hacer en segundos lo que una BD transaccional haría en minutos, porque fue diseñada exactamente para eso.

El puente: Change Data Capture (CDC)

El mecanismo que mantiene ambas bases de datos sincronizadas se llama CDC. Cada vez que algo cambia en la BD de escritura, ese cambio se captura y se replica en la BD de lectura —en tiempo casi real, sin impactar el rendimiento del sistema principal.

5. Un caso real: de 27 minutos a 30 segundos

Trabajando en un sistema core bancario de puntaje crediticio, nos encontramos con este problema de frente. El reporte de Balance Sheet cruzaba decenas de tablas y agregaba años de datos históricos sobre una base de datos PostgreSQL que también estaba sirviendo todas las operaciones transaccionales en vivo.

Tiempo de generación antes de CQRS: 27 minutos.

• 27 min antes — OLTP solo

• 30 seg después — CQRS

• 54× en mejora de performance

La solución fue implementar CQRS sobre la infraestructura existente: replicar las tablas relevantes hacia una base de datos analítica columnar mediante CDC y redirigir las consultas de reportes para que se ejecutaran ahí —sin tocar el sistema de escritura ni el código de negocio.

El tipo de query que cambió todo

-- La misma query. Diferente motor. Eso es CQRS.

SELECT
    account_id,
    sum(debit)           AS total_debit,
    sum(credit)          AS total_credit,
    sum(debit - credit)  AS balance
FROM account_move_line
WHERE date >= '2024-01-01'
  AND company_id = 1
GROUP BY account_id
ORDER BY account_id;

-- En PostgreSQL (OLTP):   ~27 minutos
-- En BD columnar (OLAP):  ~30 segundos

El query no cambió una sola línea. Lo que cambió fue sobre qué motor corría.

6. ¿Cuándo sí y cuándo no aplicar CQRS?

CQRS no es una bala de plata. Es una herramienta poderosa con un costo real de complejidad operacional. Usarla mal puede crearte más problemas de los que resuelve.

✓ Úsalo cuando...

• Tus reportes tardan más de lo aceptable y optimizar el query ya no ayuda

• Tu BD transaccional se satura cuando alguien ejecuta un reporte pesado

• Tienes más de ~50–100 GB de datos con crecimiento constante

• Los patrones de lectura y escritura son radicalmente distintos

• Puedes tolerar datos con un pequeño delay (segundos o minutos)

• Tienes capacidad para operar y monitorear dos bases de datos

✗ No lo uses cuando...

• Tu app es simple y tu BD es menor de 10–20 GB

• Necesitas consistencia instantánea al 100% en todo momento

• Tu equipo no tiene experiencia en sistemas distribuidos

• Estás en etapa de validación de producto (premature optimization)

• No tienes observabilidad para detectar problemas de sincronización

7. ¿Cómo empezar sin romper producción?

La belleza de CQRS es que puedes adoptarlo incrementalmente. No necesitas reescribir tu sistema. El camino de menor riesgo:

• Identifica tu candidato piloto. El query más lento, más crítico, con mayor impacto en el negocio. Ese es tu punto de entrada.

• Levanta una BD analítica. ClickHouse, BigQuery, Redshift, DuckDB: los managed services reducen la operación inicial a casi cero. Empieza con una instancia pequeña.

• Configura el pipeline CDC. Debezium, AWS DMS, ClickPipes, Airbyte. Replica solo las tablas que necesita tu query piloto — no toda la BD de golpe.

• Redirige ese único query. El resto de tu sistema no cambia. Solo el reporte piloto apunta a la BD de lectura.

• Mide y valida. Compara tiempos. Verifica que los datos coinciden entre ambas bases. Documenta el delta de sincronización.

• Expande gradualmente. Agrega más queries y más tablas según el ROI real que vayas viendo. No migres todo de una vez.

Ejemplo, para que me entiendas

La migración incremental reduce el riesgo a casi cero. En ningún paso modificas el sistema de escritura ni tocas la fuente de verdad. El rollback es trivial: si algo falla en la BD de lectura, simplemente vuelves a apuntar el query al sistema original. Es una de las pocas apuestas arquitectónicas donde el downside está completamente acotado.

En mi experiencia

Si tu reporte tarda 20 minutos, el problema no es el query. El problema es que estás usando una herramienta de construcción para hacer trabajo de análisis. CQRS es el reconocimiento arquitectónico de que leer y escribir son problemas fundamentalmente diferentes —y merecen herramientas diferentes.

No es magia. Es separación de responsabilidades aplicada a escala de datos. Y cuando lo ves funcionar —cuando ese reporte que torturaba los lunes de tu C-Level o Stakeholder aparece en 30 segundos— entiendes por qué es uno de los patrones más influyentes de la ingeniería de software moderna.

El siguiente paso es tuyo. Identifica ese query e identifica de qué tabla o base de datos estamos hablando. Empieza pequeño. Mide todo; eso te ayudará a dar una idea si el escalamiento necesita segregación de responsabilidades o simple optimización.

¿Tienes preguntas?

Si estás evaluando implementar CQRS en tu stack —sea cual sea el motor analítico que consideras— deja tu pregunta en los comentarios. En el próximo artículo entro a los detalles de configurar CDC desde PostgreSQL: el WAL, los replication slots y los gotchas que nadie te cuenta hasta que estás en producción.

Hoy ya hace más de 13 años que inicié mi carrera profesional como desarrollador de software; como podrás calcular, hace 13 años, la información no era tan libre como lo es ahora, era mucho más difícil encontrar información sobre sistemas y programación en general.

Eso sumado al nivel de penetración que tenía el internet y el hecho de que tener una computadora en casa, para la mayoría de familias, era algo realmente difícil. Por sus precios, disponibilidad y, si era como en mi caso, por la zona donde vivías, quizás era más difícil aún.

¿Pero… cómo es que borraste una base de datos completa sin antes hacer backup?

Hace 13 años, cuando se pensaba en desarrollar un sitio web, muy probablemente se pensaba en usar WordPress o Joomla para desarrollarlo; era raro y hasta extraño el sitio web que no operaba con alguno de estos CMS.

Justo para esa época, se popularizó el uso de hosting compartido, que no era más que un servidor que corría un software (cPanel en la mayoría de los casos) que permitía asignar recursos a diferentes usuarios dentro de un mismo servidor.

Tener una cuenta cPanel era como tener un apartamento alquilado en un edificio; una empresa te ofrecía un segmento pequeño dentro de un servidor dedicado o VPS que ellos administraban, y tú compartías recursos con otros usuarios, como la IP, RAM, storage (entre otras cosas) y podías alojar allí tu sitio web con LAMP (Linux, Apache, MySQL y PHP) sin mayor problema.

¿Por qué no hice backup?

Esto tiene muchas posibles respuestas, y los que vivieron esa época lo pueden tener más claro, pero los que no tuvieron la oportunidad, en esa época los backups eran:

1. Era muy costoso; tener una cuenta con unos pocos megas ya era algo estándar y, cuando se tenía presupuesto, se contrataba más almacenamiento para poder alojar pesados archivos Flash u otros archivos multimedia.

2. No todos los proveedores lo ofrecían; de hecho, el tener opciones de backup (bien sea manual o automático) no estaba disponible en las primeras versiones de algunos paneles de gestión (como cPanel), por lo que muchos lo que hacían era descargarse un .sql de toda la base de datos y copiaban el código mediante FTP.

3. El flujo de desarrollo no tenía stages; hoy en día es imposible pensar en algún sistema que no tenga tan siquiera un ambiente adicional al de producción. Pero en esa época, hablando claramente: si no te alcanzaba para un sistema de backup, menos para una cuenta adicional donde tener una réplica para desarrollo.

4. Falta de interés en presencia web: Aunque puede que hoy sea diferente en muchos sentidos, hace 13 años tener un sitio web era “un lujo” de algunos negocios que podían permitirse tener presencia en internet. Los costos asociados a tener y mantener un sitio web hacían que muchos prefirieran publicitarse en radio, televisión o incluso Páginas Amarillas y Guías Telefónicas.

¿Qué sitio web era… y cómo lo restablecí?

El sitio web era de una estación de radio en la que trabajaba en ese entonces; vale destacar que desde los 8 años hasta los 23 años mi vida estuvo muy ligada a la radio, televisión y medios de comunicación masiva.

Recuerdo que esos eran de los pocos clientes que existían para este tipo de tecnología para ese tiempo, ya que con el auge de los sitios web, los servicios de streaming para estaciones de radio también se popularizaron mucho.

Principalmente, las estaciones de radio miraban de cerca la posibilidad de extender su cobertura y ampliar su masa de oyentes y clientes mediante estos canales digitales, no solo a nivel de streaming, sino también en las noticias que se podían publicar allí.

¿Por qué borré la base de datos?

Recuerdo que fue porque el cliente lo necesitaba; tenía otra página web alojada en su cuenta de cPanel. En ese tiempo, algunas personas hacían este tipo de cosas: un usuario contrataba una cuenta para 2 o 3 sitios web en cPanel y podía desarrollar varias páginas web dentro del mismo alojamiento.

Esto puede sonar contradictorio, pero por eso digo “algunos”, y estas personas tenían muchos motivos para tener cuentas con la posibilidad de tener 2 o 3 sitios web. Recuerdo que en ese entonces, esto lo hacía porque con el proveedor que tenía ofrecía cuentas con streaming incluido para los que pagaran este tipo de cuenta. Y sí, era más valioso que tuvieran un backup y no 6 páginas, pero ¿qué les puedo decir?, así eran esos tiempos.

En este caso puntual, la estación de radio tenía una web principal que yo desarrollé y necesitaban una segunda web para usarla de sitio web exclusivo para móviles (recuerden que eran años previos al 3G, y los famosos dominios m.turadio.com, lo normal de la época).

¿Dónde surgió el problema?

Esta nueva web que yo realicé no necesitaba una web exclusiva para celulares móviles, porque la que yo desarrollé ya tenía soporte para eso; yo analizaba los headers y, según el navegador y OS, entregaba una web u otra desde el mismo WordPress, y eso era muy potente para la época. Ya que no necesitaba subdominios o cosas adicionales, incluso se adaptaba según el navegador o resolución de pantalla.

Recuerden que en ese entonces el rey de los navegadores en móviles era Opera Mini, y los exploradores de los nuevos Android (en ese época nuevos aún) eran muy diferentes a Opera Mini, y eso hacía las diferencias entre las webs; casi que se desarrollaba una web para cada navegador y dispositivo.

El borrado ocurrió justamente porque en las bases de datos en cPanel tenían nombres similares, algo como: turadio_web101radio y la otra base de datos era algo como turadio_w3b101radio. Ya que para ese entonces se usaba una herramienta llamada Softaculous, que aún hoy en día existe y es usada para generar las instancias de WordPress y otras herramientas.

No solo yo la usaba, sino quizás quien hizo esa primera versión de la web, y por eso quizás se generó similar el nombre de las bases de datos. Lo que me confundió y terminé borrando la base de datos equivocada.

¿Fue muy costoso reestablecerlo?

Aquí viene el giro de la historia, porque la verdad no fue tan complejo, y aunque en ese entonces yo acostumbraba a trabajar 100% live, es decir, todos los cambios se realizaban directamente sobre el sitio web en producción, este era un proyecto que tenía relativamente poco funcionando. Cerca de 3 meses para ese momento, si mal no recuerdo bien.

En ese entonces yo usaba un viejo laptop VIT (Venezolana de Industria Tecnológica) para desarrollar, y en ese i3 de 2-3.ª generación con XAMPP correctamente (sí, olvídate de Docker, en ese entonces XAMPP era la forma y el método ideal) ejecutaba el desarrollo base de plantillas y plugins.

A los 17 años, realmente ya tenía como 10 años programando. Recuerdo que mi primer “sistema” estaba escrito en C, y era una calculadora desde terminal que logré copiar de una enciclopedia vieja y desarrollar en una IBM con Windows 2000 que tenía en mi casa. En esa enciclopedia se explicaba algo de sistemas, y en ella estaban capturas de pantalla de cómo hacerla, pero no se confundan, no estaba todo el código, solo capturas de algunos segmentos.

Así que siempre tenía una “base” de los datos a modo de demostración en mi laptop, así que eso sirvió mucho. Pero creo que más que eso, sirvieron muchísimo algunas acciones que tuve, como:

• Comunicar correcta y eficientemente lo que pasó: Recuerdo que en ese momento me dije algo como: “No importa lo que pase, los llamo y les digo que borre la base de datos”.

• Serenidad y control de daños: No se debe confundir estar sereno con “no importa”; son dos cosas totalmente diferentes. Cuando estás sereno, puedes medir y tomar acciones de forma más correcta; eso facilita el control de daños y poder dar soluciones realmente eficientes.

• Compromiso con una solución real: porque justamente no todas las soluciones son las más eficientes o indicadas para una solución real; por eso es importante tener claro lo que se quiere lograr y, según eso, desarrollar una forma de hacerlo funcionar.

• Asumir consecuencias: Creo que sin esto no hubiera podido llegar a donde estoy, pero recuerdo que en ese momento lo primero que tenía claro era que iba a tomar las consecuencias de lo que pasó y solucionarlo.

La primera desvelada profesional que tuve

Sí, no les voy a mentir diciendo que mágicamente pude hacer algo que solucionó todo y resolvió el problema; eso no pasó y, por ganar más lectores, no diré lo contrario. Recuerdo que fue la primera vez como programador ya profesionalmente; me quedé toda la noche despierto restableciendo todo.

Y no se confundan, digo que fue la primera vez porque antes lo hice, pero solo por diversión, y en esta ocasión fue porque tenía claro que era un compromiso profesional que cumplir antes con quien me contrató para desarrollar su sitio web.

Terminando de ajustar y reconstruir todo unas 10 horas luego, ya que todos los archivos y scripts quedaron intactos, pero temas relativos a ajustes, configuraciones y personalizaciones se perdieron.

Cosas que cambiaron desde ese día

Muchas, la verdad, no les voy a mentir, creo que, además de anecdótica, esa experiencia fue traumática, y la forma en la que desarrollaba cambió desde ese día.

Fueron varias, pero pueden detallarse en:

• Sin documentación, es imposible avanzar: sé que es quizás algo burocrático, pero esto es indispensable en todo proceso. Si quieres que algo salga bien, primero documenta; eso te sirve para aclarar tus ideas y dejar claro cómo van a ser las cosas desde el inicio.

• Todo Plan A debe tener un Plan B: no importa el cambio que realices, siempre tienes que tener la noción clara de lo que puede llegar a fallar, y debes tomarte el tiempo de tener un plan de respaldo en caso de que no salga como esperas.

• Confía en ti siempre: si te fijas, solo tenía 17 años, y excluirme en eso posiblemente no me hubiera llevado a donde estoy, porque sin compromiso y profesionalismo es imposible que alguien crea en ti. Nadie creerá en ti si tú mismo no lo haces primero, bajo cualquier circunstancia.

Pero eso nada más no es suficiente; recuerda siempre estar en lugares donde puedes cometer errores sin miedo a perder tu empleo solo por eso, y sí, esto tiene asteriscos, no es que todo lo que hagas va a estar mal, pero es importante que siempre comuniques las cosas de forma clara y eficiente.

Si estás comunicando todo oportunamente, y siguiendo todo según la documentación y convenciones, lo esperado es que, si algo llega a fallar, puedas tener la oportunidad de identificar el fallo, documentarlo y adquirir la experiencia suficiente para que este tipo de cosas no pasen nuevamente.

Facebank es uno de los bancos más utilizados por freelancers de toda Latinoamérica, no solo por su facilidad de uso, amplias características y formato 100% digital. Sino porque ha demostrado ser un banco estable y confiable para todos sus clientes en los diferentes países de Latinoamérica.

Este banco destaca por un soporte muy bueno, según mi experiencia personal. Ofrece un servicio base de cuentas bancarias, ahorro y crédito importante, pero sin lugar a dudas su estabilidad y servicio como PipolPay lo hacen destacar.

El gran beneficio: Euros a tu cuenta en Dólares

Hasta hace poco, mover dinero desde Europa hacia bancos americanos o con base en Puerto Rico solía implicar comisiones altas de bancos intermediarios y swaps de divisas poco favorables.

Con esta nueva actualización:

• Sin costo: Las transferencias por montos iguales o inferiores a 2,000€ no tienen costo de recepción por parte de Facebank.

• Conversión automática: El dinero se acredita directamente en tu cuenta en Dólares (USD).

• Rapidez: El tiempo estimado de acreditación es de hasta 2 días hábiles.

¿Cómo recibir tu pago? (Datos necesarios)

Para que la transferencia llegue correctamente y no sea rebotada (lo cual podría generar cargos adicionales), debes proporcionar los siguientes datos a la persona o empresa que envía el dinero:

1. Beneficiario: Prisma FACEBANK.

2. IBAN: (Este dato lo encuentras dentro de tu banca en línea o app de Facebank específica para Europa).

3. Concepto de la transferencia (CRUCIAL): Aquí es donde muchos fallan. Debes indicar exactamente:

   • FFC + Tu Nombre Completo + Tu número de cuenta Facebank.

   • Ejemplo: FFC Juan Pérez 6352XXXXXX

Nota de seguridad: Asegúrate de completar estos datos correctamente en el campo de “información adicional” o “concepto” para evitar demoras en el proceso.

Compartir José Carrillo

Pros (Ventajas)

• Ahorro en montos bajos: La ausencia de comisiones para transferencias menores a 2,000€ es ideal para pagos recurrentes pequeños.

• Eficiencia de costos: Al eliminar intermediarios, se reducen las tarifas ocultas que suelen aplicar los bancos corresponsales.

• Optimización para Freelancers: Es una solución perfecta para quienes trabajan con clientes en la Zona Euro (España, Alemania, Francia, etc.), facilitando el cobro de honorarios.

• Simplicidad operativa: Menos actores involucrados suele traducirse en una mayor rapidez en la acreditación de los fondos.

Contras (Desventajas o Limitaciones)

• Costo escalable: Si el monto supera los 2,000€, se aplica un tarifario adicional, lo que puede reducir la competitividad del servicio para operaciones grandes.

• Restricción geográfica estricta: El hecho de que deba provenir exclusivamente de bancos europeos limita su uso para clientes en EE. UU., Asia o Latinoamérica.

• Rigidez en la información: Existe una dependencia crítica del campo “Concepto”. Un error manual en este apartado puede derivar en retrasos, rebotes de fondos o procesos de soporte tediosos.

• Limitación de red: Al no usar canales tradicionales (o al saltarse intermediarios), se pierde la flexibilidad de recibir fondos de entidades fuera del circuito europeo especificado.

Mi análisis como experto

Este movimiento de Facebank busca competir directamente con plataformas como Wise o Revolut, ofreciendo la ventaja de tener el dinero en una institución bancaria establecida y conectada al sistema americano. Para quienes desarrollamos proyectos o gestionamos servicios internacionales a Europa, reducir la fricción de los pagos transatlánticos es fundamental para la escalabilidad.

Si tienes clientes en la Unión Europea, esta es, sin duda, una de las opciones más rentables a día de hoy.

Suscríbete ahora

¿Necesitas ayuda configurando tu cuenta?

Si ya eres usuario de Facebank y no encuentras tus datos para recibir transferencias SEPA (Europa), déjamelo en los comentarios y puedo preparar un tutorial rápido de dónde encontrar tu IBAN en la plataforma.

¿Ya probaste esta función? ¿Qué tal fue tu experiencia con la tasa de cambio? ¡Te leo!

Si estás dando tus primeros pasos en el mundo de la tecnología, es muy probable que uses los términos “programar” y “desarrollar software” como si fueran sinónimos. Pero, si queremos hablar con propiedad y proyectar una carrera sólida, debemos entender que no son lo mismo.

En mi experiencia, esta distinción es el primer muro físico con el que choca un profesional cuando llega a una compañía real. Aquí te explico por qué.

El Programador: El artesano del código

La capacidad principal de un programador es escribir código. Es quien tiene la destreza técnica para realizar pruebas, optimizar funciones y llevar ese código a un alto nivel de ejecución. Es una pieza indispensable, pero es solo una parte del rompecabezas.

El Desarrollador de Software: El arquitecto del sistema

Un desarrollador va mucho más allá de “picar código”. Es alguien que entiende el ciclo completo desde la concepción de la idea. Para ser un desarrollador integral, debes dominar conceptos que ocurren “detrás de escena”:

• Arquitectura y Bases de Datos: Cómo se estructura y se almacena la información.

• Ciberseguridad y Autenticación: Proteger la integridad del sistema.

• Resiliencia: La capacidad de un sistema para tolerar fallos sin que ocurra una caída crítica que deje inoperativo, por ejemplo, a un banco.

Suscríbete ahora

La paradoja del Senior: Menos código, más pensamiento

Algo que sorprende a muchos es que, a medida que avanzas en tu carrera, programas menos.

• En un nivel Junior, el porcentaje de codificación es alto porque estás experimentando.

• En un nivel Senior, el tiempo dedicado a escribir código puede bajar hasta un 20%.

• Como Líder Técnico, ese porcentaje se reduce aún más debido a las responsabilidades de liderazgo y estrategia.

El resto del tiempo se invierte en leer documentación, diseñar soluciones, participar en metodologías ágiles (como Scrum) y planificar con el equipo (PMs, QAs, TLs).

Mi consejo si estás empezando

No caigas en la trampa de la “deuda técnica eterna” por no documentar o no planificar. Si quieres destacar:

1. Aprende a leer código ajeno: Antes de escribir el tuyo, entiende cómo resuelven problemas los demás.

2. Planifica antes de actuar: No lances la primera línea de código sin tener claras las bases y la escalabilidad.

3. Entiende el negocio: Un desarrollador que comprende el producto es mucho más valioso que uno que solo sigue instrucciones técnicas.

Como suelo decir: No es lo mismo saber hacer flechas que ser selección nacional de tiro con arco. Programar es una herramienta; desarrollar es el arte completo.

Imagina poder pagar una cuenta en un restaurante o transferir dinero a un amigo en segundos, sin importar el banco de cada uno, las 24 horas del día, solo con tu número de celular, correo electrónico o un nombre de usuario. Esto ya es realidad en países como Brasil y Colombia gracias a innovaciones como PIX y BRE-B, impulsadas por tecnologías como el open banking y open finance.

Durante décadas, el procesamiento de pagos digitales estuvo dominado por un modelo relativamente simple: un usuario paga con una tarjeta y una red de intermediarios procesa la transacción. Visa, Mastercard, procesadores, adquirentes y emisores participan en la operación. Operaciones que pueden llevar días en terminarse; incluso para hacer una simple transferencia, se dependía en gran medida de la interoperabilidad de distintas operaciones, incluso entre un mismo país.

Durante décadas, el sistema financiero global funcionó bajo un modelo de “silos autónomos y cerrados”. Tu dinero y, más importante aún, tus datos financieros, vivían encerrados en la bóveda digital de tu banco. Si otra aplicación quería interactuar con ese dinero, el proceso era lento, costoso y estaba lleno de peajes tecnológicos.

Ese modelo fue relativamente exitoso, pero también tiene limitaciones claras, que a 2026 son más visibles que nunca:

• Costos elevados de procesamiento

• Tiempos de liquidación de uno a tres días

• Dependencias de redes privadas

• Baja inclusión financiera en algunos mercados

¿Qué es Open Banking y Open Finance?

El open banking no es más que una herramienta que permite a los bancos compartir datos de cuentas y datos de pagos de forma segura con terceros autorizados, usando APIs estandarizadas. Esto habilita servicios como la iniciación de pagos directos desde apps externas, mejorando la competencia y la innovación.

Antes de continuar recuerda suscribirte

Con esta acción me ayudas a seguir generando contenido especializado con este que estas mirando ahora con mayor frecuencia y detalle al respecto.

Suscríbete ahora

Open finance va un poco más allá: extiende el intercambio de datos a seguros, inversiones y pensiones, creando ecosistemas financieros completos centrados en el usuario. En Latinoamérica, open finance está en auge, con Colombia volviéndolo obligatorio en 2026 para estandarizar APIs y pagos. A diferencia del open banking (enfocado en pagos y cuentas), open finance crea productos personalizados, como saldos agregados de múltiples bancos en una sola app.

Todo esto ha dado origen a que en los últimos años haya surgido una alternativa poderosa: los pagos A2A (Account-to-Account). En lugar de pasar por redes de tarjetas, el dinero se mueve directamente entre cuentas bancarias. Siendo una de las claves de esta tecnológia la inicialización de pagos dentro del Open Banking.

Y es aquí donde entran sistemas como:

• Pix en Brasil

• Bre-B en Colombia

• UPI en India

• SEPA Instant en Europa

• FedNow en USA

Todos comparten una idea central: crear infraestructuras públicas de pagos instantáneos interoperables.

La Iniciación de Pagos (PIS): Elimina al intermediario

Dentro del Open Banking, hay un superpoder específico llamado Iniciación de Pagos (o PIS, por sus siglas en inglés: Payment Initiation Services). Y esta es posiblemente una de las formas menos explotadas del Open Banking, sobre todo en Colombia, donde todo lo relativo a estas tecnologías es muy nuevo. Esto funciona más o menos así:

Históricamente, los pagos en línea han sido dominados por las tarjetas de crédito y débito. El modelo de las tarjetas funciona “jalando” el dinero. Cuando compras algo, el comercio le pide a su procesador que “jale” el dinero de la red de la tarjeta (Visa, Mastercard...), que a su vez le pide a tu banco que lo apruebe. Hay al menos cuatro intermediarios en esa cadena, y cada uno cobra una comisión. Además, este proceso de liquidación puede tardar días en completarse a nivel contable.

La Iniciación de Pagos cambia las reglas del juego a un modelo de “empuje” (Push) de Cuenta a Cuenta (A2A):

1. La Solicitud: Estás en el checkout de una tienda o en una pasarela de pagos.

2. La Iniciación: La pasarela de pagos, actuando como un iniciador (PISP), se conecta vía API directamente con tu banco.

3. La autorización: Tu banco te pide (quizás con tu huella dactilar en tu celular) que apruebes enviar el dinero.

4. La ejecución: El banco “empuja” el dinero directamente a la cuenta del vendedor a través de rieles de pago en tiempo real.

¿El resultado? El dinero viaja en segundos de la Cuenta A a la Cuenta B, los costos de procesamiento se desploman al eliminar a los intermediarios tradicionales, y el riesgo de fraude disminuye drásticamente porque la autenticación se hace directamente en el entorno seguro de tu propio banco. La infraestructura tecnológica necesaria para soportar esto requiere una escalabilidad masiva, capaz de procesar miles de transacciones concurrentes por segundo sin un solo fallo de base de datos.

Anatomía de los pagos inmediatos: Tabla comparativa global

Antes de sumergirnos en los servidores y el código, veamos cómo se posicionan los grandes jugadores del mundo con respecto a infraestructura. Esta tabla resume las diferencias clave entre los sistemas de los que hemos hablado:

Comparativa de Sistemas de Pagos Inmediatos (RTP)

• Pix (Brasil)

  • Arquitectura: Centralizada bajo el Directorio DICT del Banco Central.

  • Liquidación: Realizada en menos de 10 segundos.

  • Iniciación: Multimodal a través de Llaves (alias), códigos QR y NFC.

  • Interoperabilidad: Total, garantizada por mandato regulatorio.

  • Costo: Gratuito para personas naturales.

• Bre-B (Colombia)

  • Arquitectura: SPI y Directorio Central orquestado por el Banco de la República.

  • Liquidación: Objetivo de menos de 20 segundos por transacción.

  • Iniciación: Basada en llaves, códigos QR y URLs de pago.

  • Interoperabilidad: Total y obligatoria por regulación.

  • Costo: Bajo costo o gratuito según la normativa vigente.

• FedNow (EE. UU.)

  • Arquitectura: Operada directamente por la Red de la Reserva Federal.

  • Liquidación: Liquidación bruta en tiempo real (segundos).

  • Iniciación: Integración directa a través de canales bancarios.

  • Interoperabilidad: Fragmentada, ya que la adopción es voluntaria para los bancos.

  • Costo: Varía según las políticas de cada entidad bancaria.

• PSD2 / SEPA Inst (Europa)

  • Arquitectura: Sistema descentralizado con infraestructura RT1/TIPS.

  • Liquidación: Confirmación en menos de 10 segundos.

  • Iniciación: Uso obligatorio de APIs estandarizadas (PISP).

  • Interoperabilidad: Total bajo mandato de la Unión Europea.

  • Costo: Depende de la estrategia comercial de cada banco.

Pix: el experimento financiero más exitoso de América Latina

Si hay un sistema que ha demostrado el potencial de este modelo, es Pix, desarrollado por el Banco Central de Brasil. Pix fue lanzado en 2020 y permite realizar transferencias instantáneas las 24 horas del día, todos los días del año.

Las transacciones se liquidan en cuestión de segundos mediante el Sistema de Pagos Instantáneos (SPI) operado por el banco central brasileño. En el sistema Pix, cada usuario puede registrar una clave Pix, que funciona como un alias de su cuenta bancaria, y puede ser:

• Número de teléfono

• Correo electrónico

• Número de identificación fiscal

• Clave aleatoria

• QR dinámico

Estas claves permiten enviar dinero sin necesidad de conocer el número de cuenta, siendo su flujo típico de una transacción Pix extremadamente simple:

1. Usuario A: abre su app bancaria

2. Introduce la clave Pix del receptor

3. Confirma el monto

4. SPI liquida la operación

5. Usuario B: recibe el dinero inmediatamente

Las transacciones suelen completarse en menos de 10 segundos, y es por eso que su adopción ha sido masiva. Pix superó al efectivo y a las tarjetas como medio de pago más usado en Brasil y maneja trillones de reales al año. Brasil lidera con APIs GraphQL, webhooks y Kubernetes para escalabilidad, integrando PIX en agregadores que muestran saldos de 15 bancos.

Este éxito tiene varias razones:

• Costo cero para usuarios

• Interoperabilidad obligatoria

• Infraestructura pública

• Experiencia de usuario extremadamente simple

¿Cómo se inicializan pagos en Pix?

Inicializar pagos en Pix sigue un flujo simple, y al usar estándares tecnológicos como Open Banking y Open Finance, la inicialización de pagos en otros países que implementan la tecnología debería ser, cuando menos, similar:

1. Autenticación: Usuario confirma identidad vía app bancaria (biometría o PIN).

2. Consentimiento: Acepta compartir datos vía API (ej. PSD2-style en open banking).

3. Procesamiento: Sistema central valida fondos, liquida en tiempo real.

4. Confirmación: Notificación push instantánea.

Para este fin, en Pix con Open Finance, se utilizan flujos embebidos sin redirects que mejoran la conversión móvil. Técnicamente, involucra rate limiting, monitoreo real-time y certificados digitales, pero para usuarios es tan fácil como escanear un QR. Brasil lidera con APIs GraphQL, webhooks y Kubernetes para escalabilidad, integrando PIX en agregadores que muestran saldos de 15 bancos.

Pix demostró que los bancos centrales pueden crear plataformas tecnológicas tan eficientes como las redes privadas, y ha logrado una alta penetración justamente porque en Brasil, a diferencia de Colombia, no existen impuestos o tasas a las transferencias bancarias, como sucede en Colombia con el famoso 4x1000.

Bre-B: el equivalente colombiano inspirado en Pix

Colombia está construyendo su propia infraestructura de pagos instantáneos con Bre-B, desarrollado por el Banco de la República y el apoyo de algunas instituciones privadas como Bancolombia, Redeban y otros grandes jugadores. Bre-B es un sistema interoperable que permite enviar dinero entre entidades financieras en tiempo real, sin importar el banco o billetera digital del usuario.

La lógica de funcionamiento es muy similar a Pix, los usuarios registran una llave, que puede ser:

• Número de celular

• Documento de identidad (o número de identificación fiscal para empresas)

• Correo electrónico

• Identificador alfanumérico

Una vez registrada la llave, enviar dinero es tan simple como introducirla en la aplicación del banco. El sistema fue diseñado para resolver uno de los problemas históricos del sistema financiero colombiano: la falta de interoperabilidad entre proveedores. Pero su adopción total se ha visto marcadamente menos pronunciada que en Brasil por cosas como los impuestos a transacciones interbancarias como el 4X100.

Antes de continuar recuerda suscribirte

Con esta acción me ayudas a seguir generando contenido especializado con este que estas mirando ahora con mayor frecuencia y detalle al respecto.

Suscríbete ahora

Sin embargo, antes de Bre-B, muchas soluciones funcionaban en silos, y aunque llegó a existir una solución de operatividad interbancaria llamada TransfiYa, esta era de origen privado, el consorcio ACH. Que llegó a materializarse en algunas:

• Billeteras digitales: como Movii, Nequi, Daviplata, Dale! entre otras más.

• Bancos: siendo los principales Bancolombia y Davivienda, pero integrando un alto porcentaje de usuarios en su conjunto.

Bre-B crea un directorio centralizado de llaves y un mecanismo de liquidación instantánea, permitiendo que todas las entidades se conecten a una infraestructura común.

Esto significa que una transferencia puede completarse en segundos entre cualquier entidad participante.

Bre-B no es un solo sistema: es una capa de interoperabilidad que actúa como hub central entre los sistemas de pago de bajo valor (SPBV) ya existentes en Colombia. El Banco de la República opera el núcleo del directorio de llaves y los estándares de mensajería, mientras las entidades administradoras de sistemas de pago de bajo valor (EASPBV) como Transfiya, Entrecuentas (Redeban), Visionamos y Credibanco actúan como nodos de conexión.

Diagrama de flujo de un pago Bre-B: los 9 pasos

Desde que el usuario pulsa “Pagar” hasta que el destinatario recibe la notificación, ocurren al menos 9 operaciones técnicas distintas en menos de 10 segundos. Este es el flujo completo, diferenciando el caso P2P (persona a persona) del caso PISP (pago desde un tercero):

¿Cómo debería ser un flujo detallado con PISP (Iniciación por tercero)?

Cuando el pago es iniciado por una aplicación de tercero (un e-commerce, una fintech, una app de mensajería), se agrega una capa de consentimiento regulada por la Circular 004/2024 de la SFC:

1. Comercio/App: El usuario elige “Pagar con cuenta bancaria” en el checkout. La app del tercero crea una solicitud de consentimiento con monto, descripción y TTL (tiempo de vida).

   • POST /open-finance/v1/payment-consents — {amount, description, expiresIn}

2. SFC/Directorio: El Tercero Receptor de Datos (TRD) está inscrito en el Directorio de Participantes administrado por la SFC. Se valida su identidad con mTLS + certificado digital emitido por entidad certificadora homologada.

3. App usuario: El usuario es redirigido (o la app embebe un WebView/SDK) hacia la interfaz de su banco para autenticación fuerte (SCA: biometría + factor adicional). La pantalla es 100% del banco, nunca del tercero.

4. Banco pagador: El banco valida la identidad, debita la cuenta y emite la instrucción de pago hacia el nodo EASPBV correspondiente con el mensaje ISO 20022 pacs.008.

   • Authorization Code Flow → access_token → POST /payments

5. Bre-B Core: El motor de enrutamiento resuelve la llave destino en el DICT-CO, identifica el banco receptor y encamina el mensaje. La liquidación ocurre en el Sistema de Compensación Electrónica (CEC) del BanRep.

6. Comercio/App: El banco del pagador emite un webhook al PISP con el estado del pago. El comercio actualiza el estado del pedido en tiempo real. El usuario ve la confirmación sin haber salido del flujo de compra.

   • POST [webhook_url] — {status: "ACSC", endToEndId, timestamp}

Comparación técnica profunda: estándares y seguridad

Esta comparativa demuestra que los modelos de Colombia y Brasil están adoptando los estándares de seguridad más rigurosos (FAPI 2.0/1.0) y la mensajería más robusta (ISO 20022). Esto posiciona a la región como un referente en modernización financiera frente a la fragmentación que todavía enfrenta el ecosistema europeo.

Bre-B / Open Finance Colombia

• Protocolo API: REST/JSON basado en el estándar ISO 20022.

• Autenticación: OAuth 2.0 con especificación FAPI 2.0.

• Seguridad: mTLS obligatorio para todas las conexiones.

• Firma de Mensajes: Utiliza JWS (RS256/PS256).

• Consentimiento: Explícito, trazable y revocable por el usuario.

• Infraestructura: Directorio centralizado bajo la SFC (en construcción) y Sandbox regulado en desarrollo.

• Mensajería: Estándar ISO 20022.

• Estado de Pagos: Recurrentes (PISP) y transfronterizos no disponibles actualmente.

Pix / Open Finance Brasil

• Protocolo API: REST/JSON + ISO 20022.

• Autenticación: OAuth 2.0 + FAPI 1.0 Advanced.

• Seguridad: mTLS obligatorio.

• Firma de Mensajes: JWS (PS256).

• Consentimiento: Explícito, granular y con tiempo de vida (TTL) definido.

• Infraestructura: Directorio centralizado (BCB — DICT) y Sandbox regulado operativo.

• Mensajería: ISO 20022 (específicamente pacs.008, 002 y 004).

• Estado de Pagos: Pix Automático programado para 2025; pagos transfronterizos en fase exploratoria.

UPI India

• Protocolo API: REST con una combinación propia de XML/JSON.

• Autenticación: Sistema propio (UPI 2.0) con PIN.

• Seguridad: TLS 1.2 o superior.

• Firma de Mensajes: Firma propiedad de la NPCI.

• Consentimiento: Implícito mediante el uso del PIN de UPI.

• Infraestructura: Directorio centralizado (NPCI) y Sandbox disponible.

• Mensajería: Híbrido entre ISO 8583 y JSON propio.

• Estado de Pagos: Soporta UPI AutoPay y pagos transfronterizos activos en más de 20 países.

Open Banking UK

• Protocolo API: REST/JSON bajo el estándar OBIE.

• Autenticación: FAPI 1.0 Advanced.

• Seguridad: mTLS más certificados eIDAS.

• Firma de Mensajes: JWS (PS256).

• Consentimiento: Explícito con renovación obligatoria cada 90 días.

• Infraestructura: Directorio centralizado (OBIE Directory) y Sandbox funcional.

• Mensajería: JSON propio definido por OBIE.

• Estado de Pagos: Soporta VRP (Variable Recurring Payments) y transferencias SEPA/SWIFT.

PSD2 Europa

• Protocolo API: REST/JSON (altamente fragmentado entre bancos).

• Autenticación: OAuth 2.0 (sin requerimiento estricto de FAPI).

• Seguridad: TLS 1.2+ (mTLS solo recomendado).

• Firma de Mensajes: JWS (opcional según la entidad bancaria).

• Consentimiento: Explícito con autenticación reforzada (SCA) cada 90 días.

• Infraestructura: Fragmentada por país; cada banco gestiona su propio Sandbox.

• Mensajería: Múltiples estándares (STET, Berlin Group o propios).

• Estado de Pagos: Recurrentes en diseño (PSD3) y SEPA Instant para transfronterizos.

¿Cómo debería ser conectar tu aplicación o negocio a Bre-B?

Dependiendo de tu rol en el ecosistema, la ruta de implementación varía significativamente. Existen tres perfiles principales: Entidad Financiera (banco, billetera), EASPBV (nodo conector) y Tercero Receptor de Datos / PISP (fintech, comercio, app). A continuación, la hoja de ruta para el perfil más relevante para nuevos actores: el PISP/TRD.

Obtén más de José Carrillo en la app de Substack

Disponible para iOS y Android

Descargar la app

Estado actual (marzo 2026): La iniciación de pagos por terceros (PISP) en Colombia está en fase de regulación. La Circular 004/2024 estableció las bases de Open Finance, pero el decreto que habilitará el PISP obligatorio (URF, 2025) está en proceso de implementación con cronograma de 12 meses desde su promulgación formal. Los pasos aquí descritos mezclan lo que ya está activo y lo que está en la hoja de ruta inminente.

Esto debería pasar, paso a paso:

1. Definir el modelo de participación: Determina si actuarás como Proveedor de Servicios de Iniciación de Pagos (PISP) —que ordena pagos— o como Agregador de Información (AISP) —que solo lee datos de cuentas. Para Bre-B, el caso de uso es PISP. Si no estás vigilado por la SFC, necesitarás operar a través de un Tercero de Confianza (EASPBV certificada: ACH Colombia, Redeban, Credibanco).

   • El modelo indirecto (vía EASPBV) es la ruta práctica para startups y comercios hoy. El modelo directo requiere registro en el Directorio de Participantes de la SFC.

2. Revisión regulatoria y constitución legal: Si actúas como PISP directo, necesitas inscripción formal en el Directorio de Participantes de la SFC. Requisitos previos: personería jurídica constituida en Colombia, políticas documentadas de tratamiento de datos personales (Ley 1581/2012 y Ley 1266/2008), política de ciberseguridad alineada con la Circular Básica Jurídica de la SFC, y suscripción al marco de consentimiento del ecosistema.

   • Para PISP indirecto (vía nodo): firma de contrato comercial y técnico con el EASPBV elegido (ej. ACH Colombia / Transfiya, Credibanco). Ellos actúan como tu puerta de entrada y validan tu cumplimiento.

3. Obtención de certificados digitales homologados: Todas las comunicaciones entre tu sistema y el ecosistema Open Finance / Bre-B deben ir firmadas y cifradas con certificados emitidos por Entidades de Certificación Digital habilitadas en Colombia:

   • Camerfirma Colombia — Cámara de Comercio de Bogotá (token + HSM)

   • GSE (Gestión de Seguridad Electrónica) — token + servidor HSM

   • Andes SCD — Certificación digital en token

   • Certicámara — Entidad de certificación SIC-homologada

   • Necesitarás: un certificado de autenticación de cliente (mTLS) para las llamadas a APIs, y un certificado de firma de mensajes (JWS) para firmar los payloads ISO 20022.

4. Configuración de la infraestructura técnica base: El stack técnico mínimo para participar en el ecosistema.

   • Seguridad:

     • TLS 1.3 en todos los endpoints expuestos

     • mTLS para llamadas hacia APIs de bancos / EASPBV

     • HSM o equivalente para almacenamiento de claves privadas

     • Rotación de certificados: máx. 1 año (Circular 004)

   • API Gateway:

     • OAuth 2.0 Authorization Server (ej: Keycloak, Auth0, AWS Cognito)

     • FAPI 2.0 Security Profile (recomendado; FAPI 1.0 Adv. como mínimo)

     • Rate limiting + circuit breakers

   • Mensajería:

     • ISO 20022 parser/builder (librería: isoxml, Prowide, etc.)

     • JWS signing con RS256 o PS256

     • Idempotency keys en todos los POST de pago

   • Trazabilidad:

     • endToEndId único por transacción (UUID v4)

     • Logs inmutables (audit trail) — retención mín. 5 años

     • Webhook receptor con retry exponencial + dead-letter queue

5. Integración con el nodo EASPBV o con las APIs bancarias: Vía ACH Colombia / Transfiya: ofrecen un SDK y documentación API REST. El flujo para pago P2P incluye: resolución de llave (GET /alias/{key}), creación de orden de pago (POST /transfers), y consulta de estado (GET /transfers/{id}).

   • Vía Credibanco: integración orientada a e-commerce y comercios físicos, con soporte QR. Dock (su socio tecnológico) provee la plataforma cloud-native que simplifica la integración.

6. Implementar el flujo de consentimiento del usuario: La Guía de Experiencia de Usuario publicada por la SFC (disponible en finanzasabiertas.superfinanciera.gov.co) establece lineamientos obligatorios para la pantalla de consentimiento: lenguaje claro, datos mínimos necesarios, duración del consentimiento visible y mecanismo de revocación accesible. No es opcional: el incumplimiento es sancionable.

   1. El flujo mínimo de consentimiento para un PISP: (1) Presentar claramente “quién pide el acceso y para qué”, (2) El usuario selecciona el banco donde está su cuenta, (3) Redirección segura al banco para autenticación fuerte (SCA), (4) Retorno a tu app con el token de autorización, (5) Ejecución del pago, (6) Notificación de resultado.

7. Pruebas en sandbox y certificación técnica: Cada EASPBV mantiene su propio ambiente de pruebas. Con respecto a Open Finance, la SFC tiene un sandbox temporal en fase de construcción. Los casos de prueba obligatorios incluyen: pago exitoso, pago rechazado por fondos insuficientes, llave no encontrada, timeout del banco, intento de pago duplicado (idempotency), y revocación de consentimiento en tránsito.

   1. Adicionalmente, la Circular 009/2025 estableció que las entidades deben completar sus ajustes de arquitectura, seguridad y tecnología. Para TRDs nuevos, el EASPBV, que actúa como Tercero de Confianza, realiza una validación técnica de onboarding antes de habilitar el acceso a producción.

8. Go-live y monitoreo continuo: En producción, el monitoreo es parte del cumplimiento regulatorio. Debes tener: alertas en tiempo real para transacciones fallidas, tasas de éxito por banco (>95% es el benchmark del sector), latencia P95 por endpoint, y un proceso documentado de gestión de incidentes con notificación a la SFC en eventos mayores. Los logs deben conservarse por un mínimo de 5 años.
   

   Sé parte de los que apoyan con su suscripción más contenido especializado como este.

Certificaciones necesarias para operar dentro de Bre-b

Operar en el ecosistema de Open Finance y Bre-B en Colombia requiere el cumplimiento que combina registros regulatorios, certificaciones técnicas internacionales y adherencia a normas de seguridad de la información. Las certificaciones necesarias son:

1. Registro Directorio de Participantes SFC: Emitido por la Superintendencia Financiera de Colombia, la inscripción obligatoria para operar como TRD (Tercero Receptor de Datos) o PISP en el ecosistema. La SFC administra el directorio y define los requisitos. Aplica el marco del Decreto 1297/2022 y la Circular 004/2024.

2. Registro RNNP / SIC: Emitido por la Superintendencia de Industria y Comercio, el Registro Nacional de Bases de Datos ante la SIC. Obligatorio para cualquier entidad que trate datos personales de colombianos. Base legal: Ley 1581/2012 y Decreto 1074/2015. Incluye política de privacidad, aviso de privacidad y contratos de encargo de tratamiento.

3. Certificado Digital mTLS + Firma JWS: Emitido por Camerfirma (GSE, Certicámara o Andes SCD) el Certificado X.509 es emitido por entidad de certificación digital homologada en Colombia. Requerido para autenticación mutua en las APIs del ecosistema. Vigencia máxima: 1 año. Requiere HSM para las claves privadas en entornos de producción.

4. Habilitación EASPBV (si aplica): Emitido por el Banco de la República para entidades que quieran operar como nodo conector del sistema (EASPBV). Requiere autorización del BanRep, capital mínimo demostrado, infraestructura técnica certificada y plan de continuidad de negocio en un proceso de 6–12 meses.

5. Vigilancia SFC (entidades reguladas): Emitido por la Superintendencia Financiera para bancos, billeteras electrónicas (SEDPE), compañías de financiamiento y fintechs con captación. Requiere autorización de funcionamiento, relaciones de solvencia, y cumplimiento de la Circular Básica Contable y Financiera. No aplica a todos los participantes.

Esto sin incluir las certificaciones técnicas internacionales (fuertemente recomendadas), como:

1. ISO/IEC 27001:2022: Sistema de Gestión de Seguridad de la Información. La Circular 004/2024 exige controles alineados con esta norma. No es obligatoria la certificación formal, pero sí la implementación de sus controles. Para TRDs directos, la certificación es virtualmente requisito de facto para el onboarding con bancos.

2. PCI DSS v4.0: Si tu plataforma también procesa tarjetas o almacena datos de tarjeta (CHD), PCI DSS es obligatorio. Para iniciación de pagos Bre-B puro, no aplica directamente, pero la mayoría de los integradores de pagos lo tienen como estándar de referencia para la evaluación de riesgo.

3. FAPI 2.0 Conformance (OpenID): Financial-grade API Security Profile. Es el estándar de seguridad de OAuth 2.0 para APIs financieras que exige la SFC. La certificación formal de conformidad con OpenID Foundation demuestra que tu servidor de autorización cumple el perfil FAPI 2.0, lo que simplifica la negociación técnica con bancos.

4. SOC 2 Type II: Auditoría de controles de seguridad, disponibilidad, integridad de procesamiento y confidencialidad. Muy solicitado por bancos colombianos en sus procesos de due diligence para fintechs que quieren integrar sus APIs. No es regulatorio, pero es el estándar de facto del sector.

5. ISO 22301 — Continuidad de negocio: La SFC exige planes documentados de continuidad de operaciones para entidades del ecosistema de pagos. La norma ISO 22301 es el marco de referencia. Para EASPBV, el BanRep exige disponibilidad mínima documentada del 99.9%.

Teniendo en cuenta todo lo anterior, crear una infraestructura de este nivel es construir una autopista digital. Es complejo, requiere certificaciones rigurosas y una arquitectura de nube tolerante a fallos. Sin embargo, el esfuerzo técnico se justifica por el resultado: tomar un sistema financiero históricamente lento y fragmentado y convertirlo en una herramienta ágil que empodera la economía de toda una región, conectando cuentas corporativas extranjeras con el talento local en cuestión de segundos.

Este tipo de implementaciones es viable y sería sumamente productivo, sobre todo para pasarelas de pago que ya operan en el país, y cuentan con gran parte de los requisitos técnicos y legales para comenzar a ejecutar este tipo de servicios a usuarios finales naturales o jurídicos. Sé que este tema puede ser extenso y sobre todo te agradezco leer hasta aquí; la invitación es a dejar tu comentario y compartir.

Referencias documentales de este artículo

Este cronograma refleja el paso de un modelo de adopción voluntaria (iniciado en 2022) hacia un esquema de obligatoriedad que alcanzará su madurez entre 2025 y 2026. Para los equipos técnicos, el reto inmediato es el cumplimiento de la Circular 009 de 2025, que establece las bases de seguridad necesarias para la interoperabilidad total que propone Bre-B.

Ministerio de Hacienda y Crédito Público (MinHacienda / URF)

• Decreto 1297 de 2022: Reglamentación de la arquitectura de finanzas abiertas (Open Finance) e interoperabilidad en el sistema financiero.

• Unidad de Proyección Normativa y Estudios de Regulación Financiera (URF): Proyectos normativos para la transición hacia la obligatoriedad del ecosistema Open Finance (H1 2026).

Superintendencia Financiera de Colombia (SFC)

• Circular Externa 004 de 2024: Estándares técnicos, tecnológicos y de seguridad para la implementación de APIs.

• Circular Externa 009 de 2025: Instrucciones sobre el cumplimiento de arquitectura de seguridad y estándares técnicos mínimos.

• Normativa de Open Finance: Compendio de instrucciones para entidades vigiladas sobre la adopción de finanzas abiertas.

Banco de la República (BanRep)

• Circular Reglamentaria Externa DSP-465: Operación del Sistema de Pagos Inmediatos (SPI) y registro de llaves en Bre-B.

• Sistemas de Pago - Bre-B: Información general sobre la infraestructura de pagos de bajo valor y el go-live transaccional.

• Foros de Sistemas de Pago: Documentación técnica y presentaciones sobre la hoja de ruta de interoperabilidad y QR.

La inteligencia artificial no es una tecnología nueva; de hecho, surgió en 1956 desde el Dartmouth Summer Research Project on Artificial Intelligence, realizado en Dartmouth College, una universidad privada de artes liberales e investigación ubicada en Hanover, Nuevo Hampshire, Estados Unidos.

La idea, en principio, y en términos fáciles de entender, era que “cada aspecto del aprendizaje o cualquier otra característica de la inteligencia puede describirse con tal precisión que una máquina puede ser construida para simularlo”.

En la actualidad

El resurgimiento moderno de la IA se asocia principalmente a un paper de 2017 de Google titulado Attention Is All You Need. Ese paper introdujo la arquitectura Transformer, que cambió completamente cómo se entrenan los modelos de lenguaje.

Todo lo demás inició en 2018 con BART (padre del actual Gemini) y luego en 2019 con la salida de GPT-2, hasta el 2022 cuando OpenAI lanza ChatGPT. La primera inteligencia artificial realmente completa y funcional, con la que se podía conversar mediante lenguaje natural en un chat.

¿Por qué la inteligencia artificial es tan importante?

Sucede que desde 2022 la inteligencia artificial no ha dejado de crecer, evolucionar y aumentar su capacidad. Eso no es un secreto oculto para nadie, tanto, que se han escuchado casos donde incluso se ha usado para consulta por profesionales altamente calificados como jueces e incluso médicos.

Eso en sí mismo no es algo malo. La inteligencia artificial es, a día de hoy, una herramienta sumamente potente que permite extender las capacidades de cualquier profesional.

Eso hace que, para muchos oficios, la inteligencia artificial se convierta en un punto crítico de aprendizaje. Empleos como los de traductores a día de hoy no se ven tan necesarios, sobre todo porque hasta las inteligencias artificiales más básicas son capaces de hacer traducciones altamente exactas y adecuadas de muchos idiomas.

Estas traducciones, por poner un ejemplo, van desde el mismo idioma pero con diferente acento o dialecto, hasta idiomas altamente completos como el japonés y el mandarín, o idiomas más universales como el inglés, de forma simple y directa.

¿Y por qué son los programadores los que se van a quedar sin empleo?

Así como el ejemplo anterior de los traductores (que es un ejemplo muy frecuente en este tipo de debates), otros oficios son vistos como “prontos a desaparecer”, pero ¿es esto posible?

Bueno, desde mi punto de vista, NO. No creo que esto pase. Pero es naturaleza humana buscar posibles puntos de destrucción y alertarse, por ello. Y no está mal, pero tampoco es bueno dejarse llevar por el descontrol masivo sin tener un contexto adecuado.

Cuando se habla de trabajos altamente especializados, estos no van a desaparecer, es prácticamente imposible y te doy un ejemplo:

En muchos países del mundo, de primer, segundo y tercer mundo. Existe el “Originalism” o “interpretación auténtica”. Donde, si una ley es (principalmente) antigua o desconocida, se puede consultar con el propio legislador; puede aclarar su significado, porque fue quien la creó.

En estos casos, siempre se necesita interpretación directa de un humano. Por lo que la inteligencia artificial se vuelve una herramienta muy potente para entender contextos generales; sin embargo, específicamente, en casos como este, se necesita (según sea el caso) un traductor o intérprete.

Entonces, ¿por qué surge este mito?

Puede ser por la alta capacidad de las inteligencias artificiales en generar código; son capaces de hacerlo, pero en teoría un chimpancé también podría escribir la Biblia según el teorema del mono infinito.

Aquí la pregunta es: ¿realmente estamos en ese punto donde la inteligencia artificial nos puede reemplazar?, y la respuesta práctica es NO. Mi observación al respecto es que, en el momento en que la inteligencia artificial sea capaz de hacer eso, el mundo colapsará sobre sí mismo.

En un mundo donde todos los trabajos los puede hacer una inteligencia artificial sin intervención humana y con alta eficiencia, ¿qué sentido tiene la humanidad si todo lo puede hacer una inteligencia artificial?

Pues, quien no se adapta está condenado a la extinción; no lo digo yo, lo dijo Darwin. Y hoy más que nunca tiene un gran sentido.

Pero, ¿qué podemos hacer?

Como te dije, adaptarnos. La inteligencia artificial es una herramienta excepcional, altamente capaz (aunque su eficiencia no es óptima), que nos permite ir más allá, con mayor capacidad.

Mira que los ciclos se repiten; con la invención de la computadora se creía que no era necesario ya un matemático o físico. Lo que antes era algo altamente reservado como el estudio de estas ciencias puras y su especialización, a día de hoy es considerado un requerimiento obligatorio y universal desde niños en la escuela.

Como programador y profesional altamente calificado, mi recomendación es: ¡Adáptate! Si dejas pasar la oportunidad de hacerlo, estarás condenado a perder tu trabajo, pero no por la inteligencia artificial, sino por alguien que sí es capaz de usarla de forma eficiente.

Cuanto más especializado estés en un área en particular, entenderás que la inteligencia artificial sabe menos de lo que creemos.

¿Cuántos empleos se van a perder por la inteligencia artificial en el sector tecnológico?

Muchos, realmente, se van a perder muchos empleos; eso no es algo que esté en discusión. Pero lo que también pasará es que se generarán muchos más, incluso más de los que se van a perder.

Yo particularmente, conozco personas que han perdido su trabajo como diseñadores y desarrolladores de sitios web en WordPress por el hipe que tiene la inteligencia artificial. Pero en su totalidad, esos mismos amigos ahora hacen flujos completos, altamente complejos en N8N usando inteligencia artificial para todo tipo de cosas.

Incluso, ahora ganan más que antes y tienen ingresos de forma estable y constante, y claramente son más que antes. Pero ellos se adaptaron; solo conozco a una persona que no lo hizo y realmente cambió de carrera. Sin embargo, bueno, no lo juzgo, realmente no le gustaba programar; ahora está haciendo lo que le gusta como Trader, e incluso él usa un bot de inteligencia artificial.

Ya para finalizar, solo te puedo decir: Comienza hoy mismo a aprender a usar la inteligencia artificial a tu favor, porque si no, alguien la usará en tu contra. Muchas gracias por tu atención, espero que este post sea de tu agrado y no dudes en dejar tu comentario y compartir.

Apóyame para seguir generando contenido

Suscríbete y recibe contenido nuevo de forma prioritaria, público contenido nuevo con mucha frecuencia y suscribiendote me permites llegar a más personas.

Subscribe now