Open banking: qué es, cómo funciona y su estado en Colombia

Qué es el open banking

Open banking es la práctica de que un banco publique APIs estandarizadas mediante las cuales un tercero, con autorización explícita del cliente, puede leer información de sus cuentas o iniciar un pago desde ellas. Tres palabras hacen el trabajo pesado: APIs (el canal), estandarizadas (el mismo canal en todos los bancos) y autorización (el cliente en el centro).

Lo que reemplaza es lo que había antes: raspado de pantalla con las credenciales del cliente, archivos planos enviados por canales no auditables, o integraciones bilaterales negociadas una por una. Todas esas rutas funcionan a pequeña escala y ninguna es segura, trazable ni escalable.

Los dos casos de uso originales

• Acceso a información de cuentas. Leer saldos, movimientos, titularidad y detalles del producto. Habilita agregadores, verificación de ingresos, originación de crédito y gestión de finanzas personales. En la terminología europea, el rol se llama AISP (Account Information Service Provider).
• Iniciación de pagos. Ordenar una transferencia desde la cuenta del cliente sin pasar por la red de tarjetas. Habilita pago por transferencia en comercio electrónico, recaudo y débito recurrente autorizado. El rol es PISP (Payment Initiation Service Provider).

Ambos casos comparten la misma arquitectura de confianza: el tercero nunca ve credenciales del cliente, el banco autentica al cliente directamente, y lo que viaja entre las partes es un token de acceso con alcance limitado.

Cómo funciona por dentro

El flujo canónico tiene cinco pasos y siempre es el mismo, sea Londres, São Paulo o Bogotá.

1. El tercero solicita autorización. La aplicación del tercero registra ante el banco una solicitud con el alcance exacto de lo que necesita —qué datos, para qué, por cuánto tiempo—. En FAPI 2.0 esto se hace por Pushed Authorization Request (PAR), así los parámetros nunca viajan por la barra de direcciones del navegador.
2. El cliente se autentica en su banco. No en la app del tercero: en el dominio del banco, con sus propios factores de autenticación. El tercero nunca ve la clave.
3. El cliente otorga el consentimiento. El banco muestra en lenguaje claro qué se pide y quién lo pide. El cliente acepta o rechaza, y esa decisión queda registrada con alcance, propósito y vigencia.
4. El banco emite un token. Un token de acceso acotado al consentimiento otorgado, atado criptográficamente al cliente que lo va a usar —vía mTLS o DPoP— para que robarlo no sirva de nada.
5. El tercero consume la API. Con ese token llama los endpoints de datos o de pagos. Cada llamada queda en el audit trail del banco, ligada al consentimiento que la habilita.

El cliente puede revocar en cualquier momento, y la revocación tiene que propagarse: el token deja de servir, no simplemente se marca en una tabla.

De dónde viene: la evolución global

El open banking no nació de una innovación tecnológica sino de una decisión de política de competencia. Los reguladores concluyeron que la asimetría de información entre bancos y todo lo demás bloqueaba la entrada de competidores, y forzaron la apertura.

La lección que Colombia tomó de esa secuencia es doble: fijar el estándar técnico desde el regulador para evitar la fragmentación europea, y abrir el alcance más allá de la banca desde el primer día para no tener que legislar dos veces.

Open banking en Colombia: el estado real en 2026

Quien busque "open banking Colombia" encontrará que el término regulatorio local es distinto. En Colombia no existe una norma de open banking: existe un sistema de finanzas abiertas, y la banca es una parte de él.

La secuencia normativa

• Decreto 1297 de 2022 — primer marco, de adopción voluntaria, modificando el Decreto 2555 de 2010.
• Circular Externa 004 de 2024 (7 de febrero de 2024) — estándares técnicos y de seguridad obligatorios: OAuth 2.0, FAPI 2.0, ISO 20022 y el diccionario de datos de la SFC.
• Circulares 009 de 2025 y 001 de 2026 — dos prórrogas de 6 meses cada una al régimen de transición, que lo llevan a 30 meses desde la Circular 004.
• Decreto 0368 de 2026 (7 de abril de 2026) — hace el sistema obligatorio para todas las entidades vigiladas por la SFC.

Qué significa para un banco colombiano

Que el proyecto no es "abrir APIs de cuentas". Es construir simultáneamente el rol de proveedor de datos —exponer información propia bajo estándar— y el de tercero receptor —consumir datos de otras entidades para mejorar originación, agregación y retención—. Y que el perímetro incluye seguros, así que el banco con negocio de bancaseguros tiene open insurance en el mismo alcance.

Para una fintech el cálculo es inverso: el Decreto 0368 le abre por ley el acceso a datos que antes tenía que negociar entidad por entidad, siempre que se inscriba en el registro de terceros receptores y cumpla los requisitos de consentimiento.

Beneficios y riesgos reales

Lo que gana el ecosistema

• Crédito para quien no tiene historial. El comportamiento transaccional verificado sustituye documentos que buena parte de la población informal no puede presentar.
• Menos fricción en onboarding. Los datos de vinculación viajan con el cliente en lugar de repetirse en cada entidad.
• Pagos más baratos. La iniciación desde cuenta evita la cadena de intercambio de tarjetas.
• Competencia por producto y no por captura. Cuando el cliente puede irse con sus datos, retenerlo exige un producto mejor.

Lo que hay que administrar

• Superficie de ataque nueva. Cada API expuesta es un vector. De ahí el nivel de exigencia de FAPI 2.0 y la autenticación mutua con certificados.
• Consentimiento como riesgo legal. Un consentimiento mal capturado, sin propósito o sin vigencia, es un incumplimiento de las Leyes 1266 de 2008 y 1581 de 2012 antes que un problema técnico.
• Fatiga de autorización. Si pedir permiso es tedioso, el cliente abandona. El diseño de la pantalla de consentimiento define la conversión del ecosistema completo.
• Costo de conformidad continua. El estándar cambia; mantener la certificación es una operación permanente, no un proyecto que se cierra.

Cómo empezar un proyecto de banca abierta

1. Define en qué roles vas a operar. Proveedor de datos, tercero receptor, o ambos. La respuesta duplica o no el alcance técnico.
2. Inventaria tus datos contra el diccionario de la SFC. El trabajo invisible del proyecto es mapear tu modelo interno al estándar; suele ser el que más tarda.
3. Decide construir o integrar la capa de seguridad. FAPI 2.0, PAR, DPoP, mTLS y rotación de certificados no son código de negocio y no diferencian a nadie.
4. Diseña el consentimiento antes que la API. Alcance granular, revocación propagada, versionado y registro inmutable. Es lo primero que audita el supervisor.
5. Publica un sandbox. Ningún tercero integra a ciegas; sin sandbox, tu API existe pero no se usa.
6. Instrumenta desde el día uno. Audit trail por acceso, latencia por endpoint y disponibilidad, porque son la base de los reportes de seguimiento a la SFC.

Los pasos 3 a 6 son idénticos para cualquier entidad del país. Es exactamente la capa que Opensurix entrega ya construida, para que el equipo interno gaste su tiempo en los pasos 1 y 2, que sí son propios del negocio.

Preguntas frecuentes