
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
Tabla de contenidos
- ¿Qué es Open Banking y Open Finance?
- La Iniciación de Pagos (PIS): Elimina al intermediario
- Pix: el experimento financiero más exitoso de América Latina
- Bre-B: el equivalente colombiano inspirado en Pix
- ¿Cómo debería ser conectar tu aplicación o negocio a Bre-B?
- Certificaciones necesarias para operar dentro de Bre-b
- Referencias documentales de este artículo
¿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.
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:
[fusion_table fusion_table_type=»2″ fusion_table_rows=»» fusion_table_columns=»» awb-switch-editor-focus=»» margin_top=»» margin_right=»» margin_bottom=»» margin_left=»» hide_on_mobile=»small-visibility,medium-visibility,large-visibility» class=»» id=»» render_logics=»» animation_type=»» animation_direction=»left» animation_color=»» hue=»» saturation=»» lightness=»» alpha=»» animation_speed=»0.3″ animation_delay=»0″ animation_offset=»»]| Característica | Pix (Brasil) | Bre-B (Colombia) | FedNow (EE. UU.) | PSD2 / SEPA Inst (Europa) |
|---|---|---|---|---|
| Arquitectura Central | Directorio DICT (Banco Central) | SPI y Directorio Central (Banrep) | Red de la Reserva Federal | Sistema descentralizado / RT1 |
| Tiempo de Liquidación | < 10 segundos | < 20 segundos (objetivo) | Segundos | < 10 segundos |
| Disponibilidad | 24/7/365 | 24/7/365 | 24/7/365 | 24/7/365 |
| Enfoque de Iniciación | Llaves (alias), QR, NFC | Llaves, códigos QR, URL | Integración bancaria directa | APIs estandarizadas obligatorias |
| Interoperabilidad | Total (mandato regulatorio) | Total (mandato regulatorio) | Fragmentada (Adopción voluntaria) | Total (mandato regulatorio) |
| Costo para el Usuario | Gratuito para personas | Regulación de bajo costo/gratis | Depende del banco | Depende del 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 4×1000.
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.
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}

Como lo puedes ver, la implementación de Open Banking y Open Finance en Colombia es realmente prometedora, pero sobre todo, hay que entender que existen retos aún de implementación a nivel legal (legislativo) e incluso técnico; la implementación es realmente viable y, de hecho, desde los ojos de una persona que ya ha probado estos sistemas de integración, se ha vuelto una necesidad urgente. Una solución adaptada a las características y requerimientos de la modernidad en Colombia.
Comparación técnica profunda: estándares y seguridad
| Dimensión técnica | 🇨🇴 Bre-B / OF Colombia | 🇧🇷 Pix / OF Brasil | 🇮🇳 UPI India | 🇬🇧 Open Banking UK | 🇪🇺 PSD2 Europa |
|---|---|---|---|---|---|
| Protocolo API | REST/JSON + ISO 20022 | REST/JSON + ISO 20022 | REST + XML/JSON propio | REST/JSON (OBIE Std.) | REST/JSON (fragmentado) |
| Autenticación OAuth | OAuth 2.0 + FAPI 2.0 ✓ | OAuth 2.0 + FAPI 1.0 Adv. ✓ | Propio (UPI 2.0) ◑ | FAPI 1.0 Adv. ✓ | OAuth 2.0 (sin FAPI req.) ◑ |
| Seguridad TLS | mTLS obligatorio ✓ | mTLS obligatorio ✓ | TLS 1.2+ ✓ | mTLS + eIDAS cert. ✓ | TLS 1.2+ (mTLS recomendado) ◑ |
| Firma de mensajes | JWS (RS256/PS256) ✓ | JWS (PS256) ✓ | Firma propiedad NPCI ◑ | JWS (PS256) ✓ | JWS (opcional por banco) ◑ |
| Consentimiento | Explícito, trazable, revocable | Explícito, granular, TTL | Implícito en UPI PIN | Explícito, 90-day refresh | Explícito, 90-day SCA |
| Directorio centralizado | SFC (en construcción) ✓ | BCB — DICT ✓ | NPCI ✓ | OBIE Directory ✓ | Fragmentado por país ✗ |
| Sandbox regulado | En desarrollo (SFC) ◑ | BCB Sandbox ✓ | NPCI Sandbox ✓ | OBIE Sandbox ✓ | Cada banco su sandbox ✗ |
| Estándar mensajería | ISO 20022 | ISO 20022 (pacs.008/002/004) | ISO 8583 + JSON propio | JSON propio (OBIE) | STET / Berlin Group / propio |
| Pagos recurrentes (PISP) | No disponible aún ◑ | Pix Automático (2025) ✓ | UPI AutoPay ✓ | VRP (Variable Recurring) ✓ | En diseño (PSD3) ◑ |
| Pagos transfronterizos | No disponible ✗ | Exploratorio ◑ | UPI-PayNow (SG), 20+ países ✓ | SEPA Instant ◑ | SEPA / SWIFT ✓ |
¿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
- Seguridad:
- 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
| Hito regulatorio | Norma | Fecha | Estado | Aplica a |
|---|---|---|---|---|
| Decreto 1297 — Open Finance voluntario | Min. Hacienda | Jul 2022 | Vigente ✓ | Todas las entidades SFC |
| Circular 004 — Estándares técnicos OF | SFC | Feb 2024 | Vigente ✓ | Entidades vigiladas SFC |
| Planes de adopción API remitidos a SFC | Circular 004 | Ago 2024 | Completado ✓ | Entidades ya con OF propio |
| Lanzamiento Bre-B — registro de llaves | BanRep DSP-465 | Jul 2025 | Activo ✓ | Entidades conectadas (227) |
| Bre-B transaccional — go-live oficial | BanRep | Oct 6, 2025 | Operativo ✓ | Entidades conectadas |
| Cumplimiento estándares arq./seg./tech OF | Circular 009/2025 | Feb 8, 2026 | Fecha límite reciente ◑ | Todas las entidades vigiladas SFC |
| Decreto OF obligatorio (URF) | URF / Min. Hacienda | H1 2026 (est.) | En proceso ◑ | Todo el sistema financiero |
| Instrucciones SFC para OF obligatorio | SFC (post-decreto) | +6 a 9 meses post-decreto | Pendiente ◑ | Entidades y TRDs |
| PISP obligatorio — iniciación de pagos | SFC (post-decreto) | +12 meses post-decreto | Pendiente ◑ | Bancos + PISP habilitados |
| QR interoperable P2P Bre-B | BanRep | H1 2026 (est.) | En desarrollo ◑ | Personas naturales y comercios |
| Fin gratuidad transacciones (usuario) | BanRep | 2029 | Futuro — | Usuarios finales |
José Carrillo
Programador y desarrollador de software, tengo más de 10 años de experiencia y actualmente soy Tech Leader, creador de contenido y divulgador tecnológico.
- Publicado
- 8 de marzo de 2026
- Tiempo de lectura
- 21 minutos
- ID del artículo
- 1606
- Última actualización
- 24 de marzo de 2026
- Categorías
- Etiquetas
- Bre-BOpen BankingOpen FinancePix
- Estadísticas
- Sincronizando...Cargando...Cargando...


