Open banking dejó de ser una conversación de innovación y empezó a ser una conversación regulatoria. En el Perú, la SBS lleva varios años trabajando el marco; el Banco Central también juega un rol en el sistema de pagos. La pregunta para una institución financiera ya no es “¿open banking sí o no?” sino “¿qué postura institucional asumimos antes de que nos la pidan?”
Este artículo no es una guía técnica. Es lo que esperamos que el directorio de una caja o un banco pueda responder cuando llegue la inspección o cuando un fintech socio toque la puerta.
Las cuatro preguntas que el directorio debería saber responder
Sin importar el grado de avance regulatorio en cada momento, hay cuatro preguntas que ya hoy son razonables. Si el directorio no puede responder en términos institucionales claros, la institución está en posición reactiva.
1. ¿Cuál es nuestra postura sobre exposición de APIs?
Tres opciones legítimas existen y todas son defendibles:
- Habilitadores tempranos — nos abrimos antes que nos obliguen, capturamos posicionamiento, asumimos costo de infraestructura más caro.
- Cumplidores cuando la regulación lo exija — esperamos el marco final, ejecutamos en plazo, no asumimos posicionamiento de líder.
- Mínimos viables defensivos — exponemos solo lo estrictamente requerido, priorizamos minimizar superficie de ataque y carga operativa.
Las tres son posturas válidas. Lo que no es válido es no haber elegido. “No hemos discutido el tema” le dice al regulador que no hay gobernanza sobre la decisión.
2. ¿Qué datos estamos dispuestos a compartir y bajo qué condiciones?
Open banking no es “compartir todo.” Es un ejercicio de granularidad: qué datos del cliente, con qué consentimiento, con qué terceros, durante cuánto tiempo, bajo qué auditabilidad.
Una institución bien gobernada tiene esto explícito incluso antes de exponer la primera API. La taxonomía típica:
- Datos básicos del cliente — para los que la ley ya define consentimientos.
- Datos transaccionales — más sensibles, requieren consentimientos más finos y revocables.
- Datos de comportamiento e inferencia — los más sensibles, normalmente no se exponen.
Sin esta taxonomía, cada solicitud de API se convierte en una conversación nueva. Con ella, las decisiones se toman en plazo razonable.
3. ¿Cómo gestionamos el riesgo de los terceros que consumen nuestras APIs?
El supuesto naïve es: “la regulación define quién puede consumir, nosotros simplemente exponemos.” La realidad es más compleja: aunque el regulador licencie a los terceros, el riesgo reputacional de un incidente en uno de ellos toca a la institución que expuso la API.
Las preguntas concretas que deberían estar respondidas:
- ¿Qué tipo de due diligence haremos sobre cada tercero antes de habilitarlo?
- ¿Qué SLAs y obligaciones contractuales vamos a exigir?
- ¿Bajo qué condiciones revocamos acceso?
- ¿Cómo monitoreamos el uso para detectar anomalías?
Esto no se resuelve con un comité. Se resuelve con política escrita, aprobada por directorio.
4. ¿Cómo se ve un incidente en un tercero, y cómo respondemos?
El escenario: un fintech consumidor de tus APIs sufre un incidente y tus datos —técnicamente, datos de tus clientes— quedan expuestos.
¿Quién declara el incidente al regulador, vosotros o el tercero? ¿Cómo notificáis a vuestros clientes? ¿Cuánto tiempo tenéis para detener el acceso? ¿Qué pasa con la confianza del público cuando ven el nombre de vuestra caja asociada al incidente, aunque vosotros no hayáis fallado?
Un plan de respuesta para este escenario debe existir y debe haberse simulado, no solo redactado.
Lo técnico viene después de lo institucional
Es tentador empezar por la tecnología: “compramos un API gateway, implementamos OAuth 2.0 FAPI, montamos el consent management.” Esa conversación es legítima pero llega tarde si las cuatro preguntas de arriba no tienen respuesta.
El orden razonable:
- Postura institucional — directorio, escrita, fechada.
- Marco de gobernanza — quién decide qué, en qué plazo, con qué evidencia.
- Taxonomía de datos — qué se comparte, con qué consentimiento.
- Arquitectura técnica — API gateway, identidades, consent, observabilidad.
- Operación — onboarding de terceros, monitoreo, respuesta a incidentes.
Empezar por la arquitectura técnica sin los cuatro pasos previos es exactamente la causa de los proyectos de open banking que se quedan a medias en muchas instituciones de la región.
Qué hacer este trimestre, sin importar el calendario regulatorio
Aún si la fecha de cumplimiento es el próximo año o el siguiente, hay tres cosas que el directorio puede hacer ya:
- Convocar una sesión de directorio dedicada al tema. Una sola, con material previo. Salir de ahí con postura institucional escrita.
- Asignar un dueño ejecutivo. No un comité, una persona que rinde cuentas trimestralmente al directorio.
- Solicitar un diagnóstico de madurez. Saber dónde está la institución hoy vs. dónde necesita estar al término del plazo regulatorio. Con priorización y costo.
Las instituciones que llegan a la fecha límite con tres trimestres de trabajo acumulado son las que ejecutan ordenadamente. Las que llegan con tres meses son las que improvisan y heredan deuda técnica de largo plazo.
En 2PSECURE acompañamos a directorios de instituciones financieras en la definición de postura institucional frente a open banking, y en el roadmap técnico que se deriva. Si tu institución todavía no tiene respuesta clara a las cuatro preguntas de arriba, conversemos.
¿Te resultó útil? Compártelo: