El Decreto 0368 publicado por la Superintendencia Financiera de Colombia este pasado abril del 2026 no solo creó una obligación regulatoria, abrió un mapa de oportunidades que pocas instituciones han empezado a leer con detenimiento. Saber que el Open Finance es obligatorio es el punto de partida. Entender cómo monetizarlo, quién debe liderarlo internamente y qué implica para industrias más allá de la banca es lo que separa a las organizaciones que llegarán bien preparadas de las que llegarán corriendo.

En el artículo pasado te contamos sobre las diferencias entre Open Finance y Open Banking, cómo se ha implementado en otros mercados y su alcance. Este artículo está dirigido a quienes ya tienen el contexto básico del SFA colombiano y quieren ir un nivel más profundo.

Las dos oportunidades de monetización más claras

El Decreto establece una regla que define el modelo de negocio del SFA: los proveedores de datos pueden cobrar por el uso de su infraestructura, pero no por los datos en sí mismos. Esa distinción parece técnica, pero tiene implicaciones estratégicas profundas. Significa que la rentabilidad del Open Finance depende directamente de qué tan eficiente y bien diseñada sea la arquitectura que cada entidad construya, y de qué tan claramente defina su oferta hacia los terceros que la consuman.

Hay dos líneas de negocio donde esa ecuación se vuelve concreta de forma más inmediata.

Pagos cuenta a cuenta (A2A): infraestructura para un modelo que ya probó funcionar

La iniciación de pagos está explícitamente en el cronograma mínimo de estandarización que el Decreto le encarga a la SFC. Esto significa que Colombia tendrá, en los próximos 18 a 24 meses, la infraestructura legal y técnica para que terceros autorizados (comercios, plataformas digitales, entidades del Estado, proveedores de servicios de pago) inicien transferencias directamente desde la cuenta del usuario, sin necesidad de pasar por las redes de tarjetas tradicionales.

El modelo de pagos A2A no es una apuesta a futuro. Es una realidad documentada en mercados que llevan varios años de implementación. En el Reino Unido, los pagos de banca abierta crecieron un 72% interanual en 2024, con 31 millones de transacciones procesadas solo en marzo de 2025. Esos volúmenes no surgieron del cumplimiento regulatorio: surgieron de instituciones que diseñaron sus APIs pensando en quién las iba a consumir y bajo qué estructura de costos.

En el contexto colombiano, los casos de uso más inmediatos son pagos de facturas de servicios públicos, impuestos municipales, desembolsos de crédito, pagos en comercio electrónico y transferencias de nómina. Todos comparten una característica: son sectores donde el costo y la fricción de los esquemas de pago tradicionales es un dolor real tanto para las entidades como para los usuarios finales.

La particularidad del mercado colombiano es que ya existe una base de adopción digital sobre la cual el modelo A2A puede escalar rápidamente. Nequi y Daviplata han normalizado las transferencias digitales para millones de colombianos que antes operaban en efectivo. Esa cultura de pago digital es el terreno fértil sobre el cual el SFA puede construir, siempre que las APIs estén bien diseñadas y los modelos de precio sean accesibles para los terceros que las consuman.

Para una entidad financiera, la pregunta no es si va a exponer APIs de iniciación de pagos, el Decreto lo hace obligatorio. La pregunta es si va a diseñarlas como infraestructura de cumplimiento o como producto que comercializa activamente hacia comercios, PSP y plataformas. La diferencia entre las dos decisiones es la diferencia entre un costo operativo y una fuente de ingreso.

Identidad y KYC como servicio: monetizar lo que ya se construyó

La segunda oportunidad es menos obvia pero potencialmente más rentable para las entidades que sepan verla.

Las instituciones financieras colombianas llevan años invirtiendo en procesos de conocimiento del cliente: validación de identidad, verificación de ingresos, análisis de comportamiento transaccional, cumplimiento SARLAFT y PTEE. Esa inversión produjo activos de datos de alta calidad que hoy viven dentro de cada entidad, sin ninguna forma de monetización externa.

El Decreto incluye la información de vinculación del cliente como categoría estandarizable dentro del SFA. Esto crea la base técnica y legal para que las entidades ofrezcan APIs de identidad verificada a terceros que necesitan ese servicio: fintechs de crédito que quieren reducir el fraude en onboarding, plataformas de arriendo que necesitan verificar a sus arrendatarios, aplicaciones de empleo que quieren validar perfiles financieros, marketplaces que necesitan confirmar la identidad de sus vendedores.

El modelo de valor es directo: el tercero paga por la verificación instantánea y reduce su costo de onboarding y su tasa de fraude. La entidad financiera monetiza una capacidad que ya tiene y que ya costó construir. El usuario obtiene un proceso más rápido y sin fricción. Los tres actores ganan y el Decreto lo habilitó expresamente.

Lo que requiere diseño deliberado es el empaquetamiento. Una API de identidad verificada no es simplemente exponer los datos del cliente con consentimiento: es definir qué atributos se verifican, bajo qué condiciones, con qué niveles de certeza y a qué precio. Ese diseño de producto es el trabajo que separa a las entidades que tendrán una línea de negocio del KYC como servicio de las que tendrán una API que nadie termina consumiendo.

Los desafíos reales: lo que el Decreto no resuelve

El mandato es claro. La implementación no lo es. Las entidades que subestiman la complejidad técnica y organizacional del SFA son las que terminan pagando el costo más alto, en tiempo, en recursos y en deuda técnica que se acumula con cada ajuste normativo.

Los estándares técnicos nacionales aún no existen. El Decreto encarga a la SFC definir todos los estándares técnicos, tecnológicos, funcionales y operacionales del SFA, con un cronograma que debe publicarse antes de octubre de 2026. Hasta que esos estándares no existan, las entidades enfrentan una decisión de arquitectura con información incompleta. La forma de gestionar ese riesgo no es esperar, es construir sobre marcos internacionales ya consolidados como FAPI 2.0, OAuth 2.0 y OpenID Connect, que históricamente los reguladores latinoamericanos han adoptado como referencia. Las entidades que construyan sobre esos estándares estarán alineadas o requerirán cambios mínimos cuando la SFC publique los suyos. Las que construyan sobre soluciones propietarias tendrán que rehacer.

La infraestructura heredada es el cuello de botella más subestimado. Una parte significativa del sistema financiero colombiano opera sobre cores bancarios que no fueron diseñados para exponer datos a través de APIs en tiempo real. Conectar esos sistemas a una capa de APIs moderna, sin interrumpir la operación diaria, es un reto de arquitectura que requiere tiempo, expertise específico y una estrategia de integración cuidadosa. No es un problema que se resuelva con un proyecto de dos meses. Las entidades que hoy no tienen claridad sobre cómo van a conectar su core a las APIs del SFA van a encontrar que ese problema consume la mayor parte del tiempo disponible una vez que los estándares se publiquen.

El consentimiento es más complejo de lo que parece. El Decreto establece un esquema de doble verificación: el tercero receptor debe obtener autorización del usuario, y el proveedor de datos debe confirmar esa autorización antes de compartir la información. Adicionalmente, cualquier acción que otorgue, modifique o revoque una autorización requiere autenticación fuerte. Este diseño es robusto desde el punto de vista de la protección del usuario, pero tiene implicaciones significativas para la experiencia de usuario: un flujo de consentimiento mal diseñado genera abandono y desconfianza. Uno bien diseñado genera adopción y diferenciación. El diseño de esos flujos requiere la colaboración de equipos de producto, tecnología y compliance desde el inicio del proyecto, no como validación al final.

El modelo de negocio no surge solo de la implementación técnica. El Decreto permite cobrar por infraestructura basado en volumen de consultas, con criterios objetivos y en igualdad de condiciones para todos los terceros receptores. Eso es el marco legal. El modelo de negocio concreto (qué cobrar, a quién, bajo qué condiciones, con qué estructura de contratos) es una decisión de producto y estrategia que cada entidad tiene que tomar deliberadamente. Las entidades que dejan esa decisión para después de publicar sus APIs terminan en una de dos situaciones: APIs que nadie consume porque el precio está mal calibrado, o APIs que se consumen masivamente pero generan costos operativos que no se recuperan.

El talento especializado es escaso y compite con múltiples sectores. Implementar el SFA con los estándares de seguridad que exige el Decreto requiere perfiles con expertise en OAuth 2.0, FAPI, gestión del ciclo de vida de consentimientos y arquitectura de APIs financieras. Ese perfil es escaso en el mercado colombiano y está en demanda simultánea de múltiples industrias que están atravesando procesos similares de apertura de datos. Las entidades que no tienen esos perfiles internamente necesitan decidir hoy si los van a desarrollar, contratar o adquirir a través de partners tecnológicos, porque en 12 meses, ese mercado de talento va a estar aún más competido.

Quién tiene que liderar el SFA dentro de las organizaciones

Una de las decisiones más reveladoras que toma una organización frente al Open Finance es a quién se lo asigna. Las implementaciones que fracasan suelen ser las que lo trataron como un proyecto de un solo equipo.

El SFA es estructuralmente transversal. No puede ser solo un proyecto de tecnología, porque las decisiones de arquitectura tienen implicaciones de negocio que tecnología no puede resolver sola. No puede ser solo un proyecto de compliance, porque el cumplimiento normativo sin una visión de producto produce infraestructura sin destino. No puede ser solo un proyecto de producto, porque los casos de uso más ambiciosos quedan bloqueados por limitaciones técnicas que nadie mapeó desde el inicio.

Las organizaciones que están llegando bien preparadas al Open Finance en otros mercados comparten una característica: tienen un equipo transversal con representación real, no nominal, de al menos cuatro dominios.

Tecnología y arquitectura es quien define cómo se conectan los sistemas existentes a la nueva capa de APIs, qué estándares se adoptan y cómo se gestiona la evolución tecnológica a medida que la SFC actualiza sus requisitos. Su participación desde el inicio no es opcional: las decisiones de arquitectura tomadas sin su involucramiento son las que generan deuda técnica más cara de resolver después.

Compliance y riesgos gestiona la alineación con el Decreto 0368 y con las leyes de protección de datos (1266 de 2008 y 1581 de 2012), administra el régimen de consentimiento y autenticación fuerte, y coordina con la supervisión dual de la SFC y la Superintendencia de Industria y Comercio. En el contexto colombiano, donde la regulación de datos personales y la regulación financiera se superponen dentro del SFA, este rol tiene una complejidad particular que requiere experiencia en las dos materias simultáneamente.

Producto e innovación define los casos de uso que justifican la inversión. ¿Cuáles son las tres categorías de datos que hay que exponer primero? ¿Qué terceros son los consumidores más probables de las APIs? ¿Qué modelo de precio es viable para esos consumidores y al mismo tiempo recupera los costos de infraestructura? Sin respuestas concretas a esas preguntas, el SFA se convierte en infraestructura construida para cumplir, no para generar valor.

Negocio y estrategia conecta la capacidad técnica con los objetivos comerciales de largo plazo: qué segmentos nuevos se pueden atender, qué alianzas con el ecosistema fintech tienen sentido, cómo posicionar a la entidad como proveedor preferido de APIs en el mercado. Es el rol que convierte el SFA de proyecto en estrategia.

La visibilidad ejecutiva de este equipo no es un detalle organizacional, es un predictor de éxito. Los proyectos de SFA que quedan enterrados en la jerarquía de un solo departamento son los que se retrasan, se recortan en presupuesto y llegan al deadline con una implementación mínima que nadie quiere consumir.

Qué cambia para cada tipo de institución

Bancos y establecimientos de crédito

Para la banca tradicional, el SFA es simultáneamente una amenaza y una oportunidad, dependiendo de cómo se posicione. La amenaza es real: compartir datos de clientes con terceros reduce la ventaja de información que los bancos han tenido históricamente. La oportunidad es igualmente real: los bancos tienen los activos de datos más ricos del ecosistema financiero colombiano, y el SFA les da la infraestructura legal para monetizarlos.

Los bancos que lleguen al SFA pensando en minimizar el cumplimiento van a perder en los dos frentes: pagarán el costo de implementación sin capturar los ingresos posibles, y verán cómo terceros construyen productos sobre sus datos sin que ellos participen del valor generado. Los que lleguen pensando en maximizar el valor tendrán una línea de ingreso en pagos A2A, una oferta de KYC como servicio y una posición de plataforma en el ecosistema que sus competidores fintech no pueden replicar fácilmente.

Cooperativas, SEDPE, AFP y entidades especializadas

Para estas entidades, el primer mensaje es de paridad: el Decreto aplica con los mismos plazos que para los bancos más grandes del sistema. No hay gradualidad por tamaño ni por tipo de licencia en los plazos principales.

El segundo mensaje es de oportunidad diferenciada. Estas entidades operan en segmentos donde la brecha de información es el obstáculo principal para ampliar cobertura de forma rentable. El SFA les da acceso a datos transaccionales de sus usuarios en otras instituciones (con consentimiento) que pueden transformar radicalmente la precisión de sus modelos de riesgo. Para una cooperativa que quiere crecer en crédito a microempresarios, poder verificar el comportamiento transaccional de un solicitante en su banco principal es la diferencia entre rechazar una solicitud por falta de información o aprobarla con un modelo de riesgo más justo y preciso.

Fintechs y entidades no vigiladas

El SFA redefine el modelo operativo de las fintechs colombianas que dependen de datos bancarios para construir sus productos. El Decreto crea la figura de Tercero Receptor de Datos No Vigilado, que permite a fintechs acceder a datos bancarios de sus usuarios de forma legal, estandarizada y estable, bajo esquemas voluntarios y cumpliendo los requisitos de la Circular Básica Jurídica de la SFC.

Esto reemplaza dos alternativas que hoy son el estándar en el mercado: los acuerdos bilaterales con cada banco (costosos, lentos y no escalables) y el screen scraping, que es frágil técnicamente, crea riesgos legales y regulatorios crecientes, y tiene los días contados en Colombia tal como ocurrió en Brasil.

Pero las fintechs no son solo consumidoras en este ecosistema. Si tienen datos propios de valor (historial de comportamiento de usuarios en su plataforma, datos de pagos, información de billeteras digitales) el marco de esquemas voluntarios del Decreto les permite monetizar esos datos como proveedoras hacia terceros que los necesiten. Esa posibilidad de estar en los dos lados del mercado es una de las características más interesantes del SFA para el ecosistema fintech colombiano.

Más allá de la banca: industrias que el SFA impacta directamente

El alcance del Open Finance en Colombia va más allá del sistema financiero vigilado. Hay industrias adyacentes que se verán afectadas (en su mayoría, positivamente) por la disponibilidad de datos financieros estandarizados y de APIs de identidad verificada.

Retail y comercio electrónico: Las APIs de iniciación de pagos reducen directamente el costo de procesamiento de transacciones para comercios. Un e-commerce que hoy paga comisiones de redes de tarjetas puede migrar a un modelo A2A con costos estructuralmente más bajos. Adicionalmente, las APIs de identidad verificada reducen el fraude en compras en línea, uno de los costos más significativos del comercio digital en Colombia.

Proptech y plataformas de arriendo: La verificación de ingresos y el historial financiero de arrendatarios es uno de los procesos más costosos y lentos del mercado inmobiliario colombiano. Las APIs de KYC como servicio pueden reducir ese proceso de días a minutos, con mayor precisión y menor fraude.

Recursos humanos y plataformas de empleo: La verificación de ingresos históricos, la validación de estabilidad laboral a través de patrones transaccionales y la confirmación de identidad son procesos que las plataformas de empleo y las empresas de selección realizan hoy de forma manual. El SFA los convierte en servicios de API consultables en segundos.

Seguros: Las aseguradoras están en la lista de entidades obligadas del Decreto, pero también son consumidoras naturales de datos enriquecidos del SFA. El historial transaccional de un usuario puede informar modelos de suscripción más precisos, especialmente en seguros de vida, salud y SOAT, donde el perfil financiero del asegurado es un predictor relevante de riesgo.

Sector público: La iniciación de pagos tiene aplicaciones directas en recaudo de impuestos municipales, pago de servicios públicos y desembolsos de programas de transferencias condicionadas. Las entidades del Estado que hoy procesan pagos a través de redes costosas e intermediarios múltiples tienen en el SFA una infraestructura para reducir esos costos significativamente.

El momento de actuar

El Decreto 0368 está vigente. Los estándares técnicos llegarán antes de octubre de 2026. El plazo de 12 meses para implementar cada categoría empieza a correr desde ese momento.

Las organizaciones que hoy tienen claridad sobre su arquitectura, sus casos de uso prioritarios y su modelo de costos van a llegar a ese momento en posición de ventaja. Las que esperen a que los estándares estén publicados para empezar a prepararse van a descubrir que 12 meses no es suficiente para hacer bien lo que requiere entre 8 y 14 meses en proyectos bien gestionados.