Por qué ese número importa hoy en Perú

El contexto peruano presenta una oportunidad única: la Superintendencia de Banca, Seguros y AFP (SBS) publicó su Hoja de Ruta para el Sistema de Finanzas Abiertas (SFA) en 2025, estructurando hitos claros hasta 2029 y más allá. La regulación aún no obliga, pero sí indica el camino: los estándares técnicos se publicarán en 2026 y la primera ola masiva de implementaciones se prevé para finales de 2027. Lo cierto es que si un banco, una fintech o una empresa de servicios financieros espera a que la regulación sea definitiva para comenzar, pondrá en marcha su proyecto en 2026 y llegará a la fecha clave de 2027 solo con un avance parcial. En cambio, quienes actúen ahora llegarán a esa etapa con sistemas operativos, casos de uso funcionando y relaciones sólidas con un ecosistema de terceros ya establecido.

Esta diferencia es más que una cuestión de meses. Es una cuestión de posicionamiento estratégico en el mercado. Perú cuenta con una base digital robusta: el 92% de hogares tiene acceso a internet móvil, se reportaron más de 6,600 millones de transacciones digitales en el primer semestre de 2025, y dos billeteras digitales lideran con 19 y 14 millones de usuarios cada una. Más del 75% de las entidades financieras ya ofrecen APIs de uso externo y solo el 33% de adultos acceden a créditos formales, lo cual revela un espacio enorme de crecimiento y diferenciación. El open finance no es solo una tendencia: es una ventaja competitiva lista para ser aprovechada.

Un desglose realista de fases, recursos y decisiones críticas

Fase 1: Diagnóstico y Mapeo (2-3 meses)

El primer reto recae en mapear el core bancario: entender los flujos, sistemas legacy y definir la arquitectura de integración. Es la fase menos predecible y la más sensible a la experiencia del equipo. Muchos sistemas legacy carecen de documentación completa y dependen del conocimiento tácito de personal clave. En la práctica, equipos sin experiencia previa pueden gastar hasta tres meses sólo en entender y documentar lo existente antes de escribir la primera línea de código.

Fase 2: Modelado de Consentimientos y Framework Legal (1-2 meses)

El modelo de consentimientos tiene implicancias técnicas y legales complejas. No es solo un reto de desarrollo: implica coordinar entre los equipos de legal, producto, UX y seguridad para definir flujos claros, pedir datos de forma transparente y proteger los intereses del cliente. Esta fase suele subestimarse, pero un consentimento mal modelado puede requerir rediseño profundo una vez las capas superiores ya estén desarrolladas.

Fase 3: Implementación de Autenticación Fuerte y Pruebas de Seguridad (2-3 meses)

Implementar autenticación avanzada bajo estándares internacionales, como FAPI 2.0, requiere más que integrar sistemas de login: implica crear una arquitectura sólida y someterla a pruebas de penetración y ciclos de auditoría. Intentar acelerar esta fase es un riesgo significativo; los errores salen a la luz al ser auditados, y su corrección puede incrementar drásticamente los costos y el tiempo.

Fase 4: Definición del Esquema de Comercialización y Estrategia de Monetización (1-2 meses)

Un error común es tratar los APIs abiertos solo como un costo. El verdadero valor de Open Finance surge cuando se concibe como canal de ingresos: modelos freemium, tarifas por volumen, acceso diferenciado y colaboraciones con fintech. Definir esta estrategia desde el principio es vital, dado que el marco peruano estimula modelos flexibles y diferenciadores.

Fase 5: Integración, Ajustes, Pruebas Piloto y Go-Live (2-4 meses)

Es la etapa para ajustes finales, validaciones con usuarios reales, pruebas con terceros autorizados y adaptación de la integración según feedback y cambios regulatorios incipientes. Aquí, tener frameworks preconstruidos acelera el proceso y reduce la probabilidad de retrabajos.

Hoja de ruta práctica: Desafíos para los roles clave y sus departamentos

• C-Level: Deben definir si Open Finance es prioridad estratégica, supervisar la alineación entre innovación, TI y negocio, y medir retorno no solo financiero sino posicional.
• Director de TI/Transformación Digital: El reto es anticiparse a los estándares, construir sobre frameworks internacionales y mantener la arquitectura adaptable.
• Líderes de Implementación TI / Jefes de Desarrollo: Gestionan los detalles operativos, priorizan consentimientos, autenticación, integración y pactan con áreas legales, seguridad y negocio para evitar deuda técnica futura.

Cada departamento enfrenta desafíos concretos. TI lidia con la integración de APIs y la gestión de sistemas legacy. Producto y negocio enfocan en la definición de casos de uso y monetización. Legal garantiza la transparencia y conformidad en los consentimientos. Seguridad vela por la fortaleza en cada punto de acceso y la preparación para auditorías inminentes.

¿Equipo interno o tercerización? Valor, riesgos y resultados esperados

Construir internamente es la reacción natural, pero tiene costos ocultos: reclutar especialistas en FAPI 2.0 o arquitectura de APIs financieras lleva entre 3 y 6 meses en un mercado donde este talento es escaso. Los errores típicos de una primera implementación suelen ser consentimientos mal modelados, capas con bajo nivel de abstracción y estándares de seguridad insuficientes. En una fase de regulación aún indefinida, estos errores salen caros: cuando la SBS publique sus estándares, corregir implica rediseñar procesos críticos para el banco.

Por eso, tercerizar con equipos especializados (como Finerio + Nisum) ofrece ventajas concretas:

• Frameworks probados de consentimientos, autenticación y modelos comerciales que reducen el tiempo de implementación hasta en un 50%.
• Capacidad de absorber cambios regulatorios mediante la actualización en la capa de integración, sin tocar el core.
• Liberación de talento interno para iniciativas de negocio con retorno directo.
• Experiencia demostrada en integración sobre sistemas legacy típicos de la banca peruana —evitando la complejidad y el riesgo de intentar migrar o reemplazar el core.

El resultado concreto: los proyectos ejecutados con partners que ya cometieron y solucionaron errores en otras implementaciones de la región tienden a terminar entre un 30% y 50% más rápido. En un proyecto estimado de 12 meses, eso representa entre 4 y 6 meses de ventaja real en el mercado. No es solo tiempo: son relaciones con el ecosistema ya maduras y un modelo de ingresos activo mientras otros todavía construyen la base.

La importancia de actuar hoy: Ventaja competitiva y evitar la trampa del “esperar la regulación”

La ventana competitiva está abierta ahora y pronto se cerrará. Los bancos, fintechs y financieras que comprometan recursos y visión en este momento no se limitan a cumplir con la regulación futura; definen las condiciones de integración con el ecosistema fintech, con plataformas de crédito y con marketplaces. Quienes entren cuando la SBS publique los estándares competirán por el mismo talento, enfrentando sobrecostos, tiempos ajustados y menos margen innovador. Con más del 75% de entidades con APIs externas, pero apenas un tercio de adultos con crédito formal, Open Finance ofrece casos de uso inmediatos como:

• Colocación de créditos basada en scoring enriquecido por datos transaccionales.
• Personalización de productos financieros.
• KYC como servicio, abaratando el onboarding de nuevos usuarios en fintechs.
• “Banking as a Service” para exponer capacidades clave a terceros.
• Iniciación de pagos, alineándose a futura regulación del BCRP.
• Agregación de cuentas para ofrecer visión financiera unificada.

Estos casos pueden y deben activarse antes que la regulación lo exija: la arquitectura montada sobre frameworks probados internacionalmente se adapta, no se reconstruye, al llegar los esquemas técnicos locales.