El Sistema de Finanzas Abiertas de 🇨🇱, en simple.

Hace pocos días (Abril de 2024) la CMF (el regulador local) publicó el primer borrador de norma para el SFA (Sistema de Finanzas Abiertas). Es la versión chilena del "open finance" y tiene sabor propio, aunque con bastante influencia del modelo de Brasil.

Pero antes de analizar esa normativa de manera más detallada, es clave entender los elementos centrales, que vienen de la ley publicada un año antes.

La sopa de letras de los participantes del SFA y qué rol cumplen

Por economía de texto, uno termina hablando en siglas para describir a esos actores. Tal como nadie quiere escribir a cada rato Sistema de Finanzas Abiertas, y entonces le decimos SFA. También decimos:

• PSBI, para ahorrarnos decir "Proveedor de Servicios Basados en Información". Serán los principales "consumidores" de información en el sistema. Entraremos en detalle en la siguiente sección.
• PSIP, más corto que "Proveedor de Servicios de Iniciación de Pago". Su rol parece obvio, pero la idea de iniciación de pago es bien genérica. Así que será mejor detallar con casos de uso (también en otra sección dedicada).
• IPC, en lugar de "Institución Proveedora de Cuentas". Es interesante que no les digamos bancos. Y perfectamente correcto, porque la verdad es que no solo los bancos hoy proveen cuentas. Hay de tarjetas/cuentas prepago, cooperativas, emisores de tarjetas de créditos, etc.
• IPI, por "Institución Proveedora de Información". Acá ya no solo son cuentas. Son literal las instituciones financieras que guardan info que es de las personas. Las aseguradoras, por ejemplo, también proveerán información en el SFA.
• PSC, que significa "Proveedor de Servicios de Certificación". En realidad la Ley Fintec no hace mención a ellos, pero jugarán un rol importante como veremos más abajo. Son empresas que se dedican a emitir certificados para la Firma Electrónica Avanzada (FEA, otra sigla más bien desafortunada), o para firmar facturas, y también algunas para certificados de sitios web.

¿Por qué la ley inventa estos términos? Resulta que PSBI, PSIP, IPC e IPI son roles en el SFA. Son sombreros que se pueden poner las instituciones. Una institución puede usar varios sombreros (por ejemplo los bancos son evidentemente IPCs y también IPIs). Por supuesto que cada rol lo juegan muchas instituciones (la ley describe en bastante detalle qué tipo de instituciones están obligados a ser IPIs e IPCs, por ejemplo).

Lo más simple: compartiendo información.

Antes de complicarnos la vida, mejor mirar el SFA de manera sencilla. ¿Para qué lo inventamos? En simple, para permitir que las personas otorguen a ciertos terceros (regulados) el acceso a su información y a sus cuentas (que no tan casualmente residen en una institución financiera regulada). ¿Por qué y para qué? Mil razones (tener un lugar centralizado para administrar finanzas, conseguir una mejor tasa para un crédito, demostrar su solvencia financiera, mover los destinatarios de transferencias de un lado a otro, etc, etc). La gracia de un SFA es que entrega la infraestructura para decenas de casos de uso.

Esto se ve así:

Arriba están los "clientes" del sistema financiero. Puse emojis de personas, pero la verdad también podrían ser personas jurídicas (empresas, por ej.)

Abajo a la izquierda, las IPIs. A la derecha, los PSBI. Que por cierto, uno los tiende a imaginar como fintechs (ya que el SFA ocupa buena parte de la Ley Fintec), pero la verdad es un sombrero que se pueden poner prácticamente todos los participantes del sistema. De hecho es evidente que los bancos (obligados a entregar información) debieran aprovechar el sistema para obtener información también. O sea, además de IPI e IPC, los bancos seguramente serán PSBI (La hoy poco efectiva portabilidad financiera pasará a ser parte del SFA, por cierto).

¿Y qué significan las flechas entre los actores? Hay varias relaciones simplificadas en inocentes flechas. Veamos:

• Las personas ya son clientes de los IPC, y por lo tanto los IPC tienen obligaciones importantes. Por ejemplo, no es llegar y entregar la información de sus clientes sin autenticarlos debidamente.
• Los PSBI tienen alguna relación también con las personas (el servicio que le prestan o le van a prestar) y en el marco del SFA están obligados a pedir un consentimiento que está bastante regulado. No vale dejar un checkbox marcado en letra chica, por dar un ejemplo. Más aún, el uso de la información a obtener tiene que limitarse al uso que se describa en ese consentimiento. Si te pido tus datos para ordenarte las finanzas, no puedo usarlo para cotizarte créditos con terceros, por ejemplo.
• Y entre PSBI y el IPC tienen que comunicarse. Que suena muy simple pero está lleno de detalles técnicos importantes. Para eso es importante que se autentiquen entre sí (o alguien podría enviarles o recibir la información que no corresponde, ya llegaremos a ese punto). Clave que además validen que ambos están activos en el SFA (de esta forma, la CMF tiene maneras de suspender o incluso expulsar a un participante del SFA). La comunicación tiene que ser segura y todos tienen que hablar ojalá el mismo idioma (via algún estándar de APIs, sigla con la que no me voy a meter hoy), o sino sería la torre de babel y nada de esto funciona.

En ausencia de un SFA, esto igual ocurre. Las personas le pasamos la clave del banco, la AFP, la AFC (o peor aún, ¡la clave única!) a los que quieren acceder a la info. Ellos en general usan robots web (scrapers) para obtener la información de la misma forma que la obtienes tú (via la web o la app de la institución donde "vive" tu info). El SFA, si se implementa adecuadamente permite que esto ocurra en un ambiente de mayor confianza y supervisión.

Ahora, implementarlo adecuadamente es menos simple de lo que parece, como puede atestiguarse mirando cómo le ha ido a otros países. Es un sistema lleno de delicados balances. Por ejemplo, un excesivo énfasis en seguridad (o en seguir una secuencia determinada de pasos) termina con demasiada fricción. Que lleva a los usuarios a seguir entregando claves para que quienes quieren acceder a la información sigan con sus robots.

Los pagos.

Nos faltan varias siglas para cubrir ahora la iniciación de pagos.

Mas de alguien pensará que basta reemplazar PSBI → PSIP, IPI → IPC, y listo. Pero no. Incluso antes de ir al diagrama, vale la pena mencionar algunas diferencias.

• Mover plata es cosa seria. Cuando pagas con tarjeta se suele pedir un segundo factor de autenticación, por ejemplo. De manera más genérica, se le llama Autenticación Reforzada de Clientes (ARC en español, SCA en inglés) a la idea de pedir esa confirmación adicional para por ejemplo doble-chequear que quien instruye el pago es realmente el dueño de la cuenta y no alguien que le adivinó o robó la clave. Entonces el IPC probablemente aplicará una autenticación reforzada acá (que puede no ser tan necesaria para información que no sea demasiado sensible).
  • En el futuro espero comentar lo complejo que puede ser esto para los pagos desde personas jurídicas, pues las sociedades pueden determinar reglas arbitrariamente complicadas sobre cuantas personas (y qué personas) deben autorizar un pago (o firmar un cheque) para que sea válido.
• Los PSIP están obligados a regularse. Los PSBI participan de forma voluntaria.
• La iniciación de pago no conlleva costo para los PSIP. Es decir, los IPC no cobran por su rol en el SFA. La parte de datos en cambio podría permitirle a los IPIs cobrarles a los PSBI (después de ciertos umbrales que la norma va a definir).

Pero además de esos comentarios generales, a la hora de diagramar el flujo, no basta con que fluya la información entre PSIP y IPC.

¡Falta mover la plata!

Además nos falta otro actor, que es hacia donde se mueve la plata. Porque la iniciación de pagos se parece a los adquirentes el mundo de tarjeta de crédito. Los adquirentes existen para atender a los "comercios" (merchants), que son los que venden productos o servicios y por eso quieren aceptar pagos. Los iniciadores de pagos (PSIP) provee un riel alternativo para aceptar estos pagos.

Entonces incluyamos ese flujo de la plata y el rol del comercio:

Porque el iniciador es quien...bueno, "inicia" el pago. Pero se completa a través de una transferencia de fondos electrónica cuenta a cuenta.

Excepto que, por razones prácticas, en Chile varios iniciadores de pago (esos que te piden la clave del banco para hacer pagos) suelen recaudar en cuentas propias. Entonces la Ley Fintec permite que por un tiempo limitado (72 horas) — y bajo ciertas reglas que tiene que definir el Banco Central — la plata no viaje directo a una cuenta del Comercio sino que se vaya a una cuenta del PSIP, que pasa a tener un rol en la cadena de pagos, "tocando la plata". Entonces queda así:

Por cierto: Shinkansen Payouts es una linda solución para que los futuros iniciadores de pago (y PSPs en general) automaticen esa última línea azul con la que envían el dinero a las cuentas de centenas, miles o más comercios.

Y Shinkansen Payin Notifications les permite detectar en tiempo real la entrada de dinero en sus cuentas recaudadoras, sin necesidad de crear robots webs que se rompen con cambios de los bancos y con los que cuesta manejar las reversas.

La última sigla.

Ya sólo nos queda cubrir los PSC. Que como mencioné al comienzo, es un bonus track. No están mencionados en la Ley Fintec, pero es evidente que cumplirán un rol clave en que el sistema sea seguro. Porque a la hora de cifrar y firmar comunicaciones en internet, los certificados digitales son pieza clave de esa infraestructura.

En Shinkansen sabemos harto de eso, porque los incorporamos en nuestra tecnología desde un comienzo. A veces hacen las APIs un poquito más incómodas (ya no basta una simple API Key para integrarte y mover plata), pero por lo mismo son más robustas y seguras (¡ya no basta una simple API Key para mover plata!).

Los PSC, en general, se dedican fundamentalmente a emitir certificados. Los certificados son una combinación de 3 cosas:

• Información sobre el dueño del certificado (ej: Nombre o Razón Social, identificador fiscal, dirección de correo, etc).
• Una "llave pública" que cualquiera puede ver. Pero que gracias a la magia de la matemática y la tecnología reciente, permite a cualquiera verificar (o descifrar) archivos o mensajes que sólo pudo haber firmado (o cifrado) el dueño de otra llave, la "llave privada". Esa llave privada no se incluye en el certificado.
• Finalmente, el certificado está firmado por una llave privada del ente certificador. Y existe un certificado que contiene la llave pública respectiva. De esa forma, hay una cadena de confianza en la que uno puede verificar que el certificado realmente fue generado por un PSC específico (o por un PSC en quien confía un PSC en que tú confías, y así sucesivamente — permitiendo que existan cadenas de confianza, no tan distinto de lo que hacemos en el mundo de papeles físicos con notarios o conservadores).

(Puesto así, el trabajo de los PSC suena simple. La verdad es que tienen que hacer todo esto de manera muy segura y además tienen que proveer infraestructura para revocar certificados mediante protocolos súper bien definidos ante situaciones anómalas — como que alguien extravió o le robaron su llave privada — y luego distribuir esta información a través de protocolos como OCSP)

Volvamos a la primera mitad del artículo, cuando recién empezamos a hablar de la sopa de letras y la relación entre PSBI y IPC. Ahí les contaba que:

Es importante que [los participantes] se autentiquen entre sí (o alguien podría enviarles o recibir la información que no corresponde, ya llegaremos a ese punto). Clave que además validen que ambos están activos en el SFA (de esta forma, la CMF tiene maneras de suspender o incluso expulsar a un participante del SFA)

(Vamos a llamarle "participantes" a PSBI, PSIP, IPC, IPI)

Una solución que permite que cada participante del SFA autentique a sus contrapartes es la siguiente:

1. Cada participante tendrá que generar sus propias llaves privadas (de esa forma, nadie más puede haber estado en posesión de esa llave, habilitando lo que en la industria le decimos el "no repudio"). El participante luego va donde un PSC (probablemente aquellos certificados por el Ministerio de Economía para las soluciones de firma electrónica avanzada) para que les genere un certificado. Este proceso es como declarar: "Yo, PSC, certifico que quien me trajo esta llave pública realmente es tal o cual persona y/o representa a tal o cual empresa".
2. El participante registra el certificado en un directorio central (administrado o delegado por el regulador, en este caso la CMF). Es como la vieja guía telefónica o páginas amarillas.
3. El regulador probablemente firma este certificado y luego lo deja a disposición del resto de participantes, que es como declarar "Yo, CMF, certifico que recibí por vías oficiales este certificado de este participante y quien presente la llave privada que calce con esta llave pública, será considerado como el participante válido para el identificador XYZ" (el identificador puede estar o no estar en el certificado).
4. Todos firman o cifran sus mensajes usando sus llaves privadas y validando o descifrando con las llaves públicas de los certificados.

Esquemáticamente se ve así:

Esto no es parte de la Ley Fintec, y tal vez podría resolverse de manera diferente. Pero por la experiencia que tenemos en Shinkansen con medio millón de mensajes de APIs firmados al mes, creemos que la solución definitiva debiera ser muy similar a esto.

Que la verdad, se parece bastante a la firma de facturas electrónicas. Quizás la única gran diferencia — más allá de formatos y medios de comunicación específicos —  es que el universo de "firmantes" es súper reducido. Y por eso creemos que se puede hacer una mejora en seguridad manteniendo la llave privada sólo en poder del participante que la utiliza.

¿Y cuándo?

La verdad falta tiempo para que el SFA esté operando. Asumiendo que la norma requerida es publicada a mediados de 2024, se iniciará un proceso que podría tomar hasta varios trimestres como periodo de implementación. Ahí recién estará vigente la norma. Y luego transcurridos 6, 12, 18 o más meses adicionales irán entrando al sistema distintos actores y mecanismos (ej: las APIs públicas de consulta sobre sucursales van primero, la iniciación de pagos se demora más, las aseguradoras entran al sistema como IPIs más adelante aún). Siendo optimistas, tendremos el SFA en vigencia a fines de 2025 y operando realmente en el 2026. O el 2027.

Pero el momento para prepararse, tanto en lo regulatorio como en la infraestructura tecnológica y operacional, comienza ahora.