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.
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):
La Solicitud: Estás en el checkout de una tienda o en una pasarela de pagos.
La Iniciación: La pasarela de pagos, actuando como un iniciador (PISP), se conecta vía API directamente con tu banco.
La autorización: Tu banco te pide (quizás con tu huella dactilar en tu celular) que apruebes enviar el dinero.
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:
Usuario A: abre su app bancaria
Introduce la clave Pix del receptor
Confirma el monto
SPI liquida la operación
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:
Autenticación: Usuario confirma identidad vía app bancaria (biometría o PIN).
Consentimiento: Acepta compartir datos vía API (ej. PSD2-style en open banking).
Procesamiento: Sistema central valida fondos, liquida en tiempo real.
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.
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:
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}
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.
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.
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
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.
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.
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:
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.