Críticas infundadas de la ABIF al SFA de Chile

A pesar de ser co-fundador de una Fintech, me siento lejos de tener una mala predisposición hacia la Asociación de Banco (ABIF) o los bancos en general. Por ejemplo, coincido en sus críticas a la Ley Antifraude, a pesar de las mejoras recientes que esta ha tenido.

Sin embargo, las críticas planteadas a la Comisión para el Mercado Financiero (CMF) de Chile sobre la Norma de Carácter General (NCG) que recientemente fue publicada, para regular la implementación y funcionamiento del Sistema de Finanzas Abiertas (SFA), me parecen infundadas.

Me refiero a la siguiente entrevista al presidente de la ABIF, publicada por Diario Financiero, en la que se critica la falta de gradualidad, cuidado insuficiente en la protección de datos y exigencia de disponibilidad inmediata de los servicios:

https://www.df.cl/mercados/banca-fintech/nueva-norma-de-finanzas-abiertas-de-la-ley-fintech-hay-riesgos-que-no

Sin adjetivos, sin mala onda y sin generalizar, vamos directo al análisis…

¿Falta gradualidad?

La norma establece primero un plazo de 24 meses sólo para preparación. Este periodo, si bien completamente legítimo desde una perspectiva legal, no está contemplado expresamente en la Ley Fintech, por lo que no puede sino entenderse como una concesión de parte de la CMF a aquellas voces que pedían mayor gradualidad. Durante todo este tiempo, el público no verá ningún servicio brindado por el SFA.

Luego vendrán otros 18 meses de implementación. Los 6 meses iniciales se ocuparán para la implementación de las primeras Interfaces de Programación entre Aplicaciones (API). Estas permitirán descargar datos de “Términos y Condiciones Generales” y de “Canales de Atención”. Es decir, datos que ya son públicos- no son “datos personales” - y, por lo tanto, su seguridad no es crítica. Esta etapa sólo se justifica desde la perspectiva de la gradualidad en la implementación del sistema. Sirve para probar las carreteras de información y las capacidades de los sistemas de distintos participantes para interactuar entre sí.

Recién 9 meses después de eso, vence el plazo para liberar un segundo conjunto de APIs, esta vez para permitir que las personas consientan el tratamiento de sus datos de Posiciones Financieras, Transacciones, Cuentas, Productos y otros, acotado a Personas Naturales. Y 3 meses después, lo mismo para personas jurídicas.

En paralelo con la liberación de datos para personas jurídicas, coincide en plazo de liberación de APIs para la Iniciación de Pagos.

Es decir, el último plazo, bajo el esquema de gradualidad definido por la CMF, vence durante el 2028.

Se ve que hay plazos holgados y que se diferencia entre etapas, partiendo por lo menos crítico y avanzando en sensibilidad. Además, nada impide que los participantes operen según los estándares definidos, en forma previa a los plazos límites y con servicios que se van liberando en lotes más pequeños. El mercado está en libertad de hacerlo, los plazos lo permiten y es mejor contar con la flexibilidad de elegir una planificación.

Por lo tanto, no me parece que haya fundamentos para decir que falta gradualidad.

¿Se protegen los datos?

La CMF ha definido que el SFA deberá implementarse según las recomendaciones de FAPI 2.0. FAPI es la sigla de “Financial-grade API” y son recomendaciones internacionales publicadas por el FAPI Working Group de la OpenID Foundation, fundación sin fines de lucro, que ha probado tanto su especialización, como su capacidad de hacer las cosas bien.

Estas son las exigencias más estrictas a nivel mundial y tienen pocas alternativas de referencia, pero las tienen. Por ejemplo, están las recomendaciones del Grupo de Berlín, que han seguido algunos países en Europa.

Tanto FAPI como las recomendaciones del Grupo de Berlín, definen modelos y estándares de seguridad para permitir que un Prestador de Servicios Basados en Información (PSBI o Prestador), obtenga el consentimiento de los usuarios y, luego, los datos de estos, que son custodiados por Instituciones Proveedoras de Información (IPI o Institución). De estas opciones, FAPI es la más exigente. Me podría alargar en esto, pero voy a dar un único ejemplo…

Los 2 grupos de recomendaciones comparten en la base un estándar ampliamente utilizado, que se llama OAuth 2.0. Este estándar tiene varios modos de operación, que se pueden agrupar en 3 categorías:

• Modelos embebidos: Toda la experiencia del usuario es controlada por el PSBI, lo que permite implementar las mejores experiencias para los usuarios, pero a cambio, el PSBI debe tener acceso al menos temporal, a las credenciales de los usuarios.
• Modelos con redireccionamiento: Los PSBI deben enviar a los usuarios a páginas o aplicaciones provistas por las IPIs, las que autentican al usuario y gestionan su autorización a un tercero, luego vuelven a enviar a los usuarios a las aplicaciones de los Proveedores. Esto permite implementar mecanismos de consentimiento en los que los Proveedores nunca tienen acceso a las credenciales de los usuarios. A cambio, la adopción del sistema depende de que las IPIs implementen buenas Experiencias de Usuario (UX) en la parte que les toca, es decir, en la autenticación y autorización. El problema es que no siempre se cumple con la implementación de buenas UX en las Instituciones. En Europa se han visto casos en los que estas experiencias son una verdadera burla, obligando al usuario a pasar por hasta 17 páginas web antes de lograr otorgar una autorización. La consecuencia de estas UX ha sido un nivel decepcionante en la adopción de los sistemas de finanzas abiertas.
• Modelos desatachados: Son modelos parecidos a los de redireccionamiento, pero permitiendo cambio de canales y ahorrando algunos pasos. Por ejemplo, el usuario puede declarar su intención de recibir un servicio en la página web de un comercio y en forma que parece mágica, la app de su banco en el celular le pregunta si quiere dar ciertos permisos.

Frente a estas opciones de modelo de UX, FAPI opta por la seguridad. En cambio, el Grupo de Berlín, que ha visto como los modelos con redireccionamiento pueden producir mala UX y baja adopción, recientemente ha optado por promover los modelos embebidos, esperando que así se consiga implementar mejores experiencias de usuario.

Es un gran dilema, seguridad vs adopción. No es que los modelos embebidos necesariamente sean inseguros, pero generan más puntos que auditar.

Dada la experiencia internacional, el Congreso de Chile tuvo que elegir entre encargar la gestión del consentimiento a los Proveedores o a las Instituciones. Y optó por los Proveedores, indicando que estos “… deberán adoptar mecanismos de autentificación del Cliente y obtener su consentimiento…”. Es fácil confundirse, por lo que aclaro que en todos los estándares que he mencionado hasta aquí, la autorización es gestionada por la Institución, no el Proveedor.

El texto de la Ley conduce naturalmente a que las Instituciones no participen del proceso de gestión del consentimiento. Por eso la norma de la CMF, en su versión en consulta, descartaba la posibilidad de que las Instituciones preguntaran por el consentimiento.

Formé parte de un grupo de personas que a través de asociaciones y gestiones por Ley de Lobby, impulsamos la idea de poner énfasis en la palabra “mecanismo” de la exigencia legal, y así permitir una interpretación en la que la Institución es el “mecanismo” mediante el cual el Proveedor termina de obtener el consentimiento. De esta forma, las Instituciones recuperaron un punto de control en el acceso a datos que se estaba perdiendo en el texto original. La CMF impulsó este cambio, a favor de la seguridad, tomando una posición que está al límite de lo que la Ley permite.

La norma también establece que habrá organizaciones o empresas privadas a cargo de acreditar condiciones de seguridad de los participantes del sistema. Esto es necesario para las certificaciones de Sistemas de Gestión de Seguridad de la Información, como la norma ISO 27.001, la certificación FAPI y otras certificaciones que, por su grado de especialización, la CMF no podría validar en forma más idónea que las empresas especializadas. Habría representado un riesgo de seguridad enorme que la CMF pretendiera adquirir esas competencias para jugar un rol más protagónico en la certificación de seguridad.

Con todo esto a la vista, me parece infundado decir que “es necesario generar un esquema de certificación con múltiples resguardos”, porque la norma ya lo tiene. Y también me parece infundado criticar que “el regulador no asume un rol activo, deja a los partícipes del SFA la responsabilidad de externalizar ese tipo de servicios, por ejemplo, subcontratar un certificado”. Esta es la forma normal de asegurar aspectos de alta especialización en certificaciones de seguridad, que incluyen gestión e implementación de procesos que requieren seguridad de la información.

¿Se exige demasiado en disponibilidad?

La norma exige que los participantes cumplan con un nivel de servicio del 99% mensual y 95% diario en cuanto a disponibilidad.

Lo normal en la banca es pedir 99.8% de disponibilidad cuando son exigentes y 99.5% cuando bajan la vara. Comparado con eso, la norma parte con una exigencia baja y es razonable pensar que, cuando el sistema esté estabilizado, la exigencia aumentará, para acercarse a los niveles que brindan mejor servicio.

Con estos números sobre la mesa, no veo la base que puede tener una frase como “debiera buscarse prioritariamente que el sistema se estabilice y garantice lo más posible que la interconexión sea adecuada. Esos dos conceptos debieron estar primero, antes de tener una disponibilidad”. Me parece que no se puede partir sin un mínimo y que el mínimo que se definió no es exigente. Por lo tanto, esta es una forma de buscar justo lo que se está sugiriendo hacer.

En resumen, me parece que en esta ocasión, la ABIF hizo públicas 3 críticas que no están bien fundadas.