Para estar de acuerdo con las directrices legales relacionadas con el intercambio de datos, las instituciones necesitan ofrecer un medio para que los usuarios, es decir, sus clientes, puedan autorizar el uso de datos personales para los fines relacionados con Open Finance.

Es el titular, es decir, la persona a quien se refieren los datos, quien debe, si lo desea, al ser cuestionado, de forma explícita e inequívoca, autorizar que su información sea utilizada, en el momento de la oferta de productos y servicios, gratuitos o no.

Flujo de Consentimiento

En Open Finance debe existir un recorrido que englobe un conjunto de requisitos mínimos que deben seguir las instituciones participantes con el objetivo de guiar su implementación y garantizar una experiencia de cliente adecuada y estandarizada, enfocándose en el recorrido del usuario para intercambiar datos e inicio de pagos.

1. Institución receptora: responsable de iniciar el flujo, en este punto el usuario es "estimulado" a compartir sus datos con algún propósito, por ejemplo, un análisis de crédito, apertura de cuenta, contratación de un préstamo, etc.
2. Institución transmisora: responsable de proporcionar los datos, debe ofrecer la gestión del consentimiento para los usuarios.
3. Usuario: titular de los datos, tiene la capacidad de permitir o no el intercambio.

El flujo comienza en la receptora, el usuario desea de alguna manera utilizar servicios, ya sea un agregador financiero o una tienda.

El usuario informa:

1. Alcance de los datos a compartir.
2. Finalidad del intercambio.
3. Institución de origen de los datos.
4. Plazo del intercambio.
   

La receptora debe:

1. Realizar el descubrimiento de la institución transmisora en el directorio central.
2. Realizar el onboarding en la institución transmisora.
3. Crear la "intención" de consentimiento.
4. Efectuar el redireccionamiento.
   

Esta etapa se utiliza para preparar el consentimiento y consiste en crear un objeto en la institución transmisora. Dentro de este consentimiento, la receptora colocará los permisos que desea acceder y algunas informaciones opcionales como la expiración del consentimiento, por ejemplo.

La transmisora protege sus endpoints con OAuth 2 basado en la RFC6749 y RFC6750, incluso el endpoint de creación de consentimiento, lo que significa que la receptora necesitará un token de acceso para crear el objeto de consentimiento. La receptora es el cliente OAuth 2 y desea crear un recurso y entonces deberá usar el flujo de client_credentials.

Descubrimiento de instituciones

Open Finance establece una estructura central de gobernanza donde se agregan todas las informaciones necesarias para que algunos pasos sean completamente m2m (machine to machine) sin la intervención humana.

Las instituciones, entonces, pueden consultar APIs del directorio para saber dónde están disponibles los endpoints necesarios para el flujo, por ejemplo, la receptora puede consultar información de la transmisora y así lograr crear el consentimiento, URIs de redireccionamiento, generación de tokens de acceso, etc.

Onboarding en las Instituciones Transmisoras

Una vez que la receptora conoce las URIs necesarias, debe registrarse en la institución transmisora. Open Finance  Financial-grade API Security Profile 1.0 define un proceso automatizado en que la receptora hace este registro en la transmisora, llamado Registro Dinámico de Clientes, basado en la RFC7591.

Crear la "intención" de consentimiento

El consentimiento del titular del dato es el principal elemento de seguridad en el flujo de intercambio de datos. Sin embargo, los datos están almacenados en la institución transmisora y no en la receptora, que en ese momento desea "ir a buscarlos". De esta forma, la autorización del intercambio debe suceder en la transmisora, la receptora aún no posee esta autorización, solo un esbozo del pedido que contiene el alcance, plazo, etc.

Para este "esbozo" de un consentimiento, el perfil de seguridad lo llama intención de consentimiento. Aún faltan algunos pasos necesarios en el flujo para que el consentimiento sea concedido, o autorizado. Este enfoque utiliza un estándar llamado Financial-grade API: Lodging Intent Pattern. La información más importante en este punto es el identificador único del consentimiento retornado por la transmisora, con él las instituciones pueden tener una información en común y el flujo podrá continuar en la transmisora.

Redireccionamiento

La receptora, de posesión de las informaciones necesarias como: alcance de los datos, plazo, etc., puede entonces enviar a su cliente a la transmisora para que pueda ser autorizado y el acceso a los datos deseados sea liberado. Este proceso utiliza el flujo de autorización del OAuth 2 conocido como Authorization Code Grant.

La transmisora debe ser capaz de identificar al usuario y la intención de consentimiento, para que esto sea posible, la receptora monta una solicitud de autorización que contiene los parámetros necesarios:

1. Identificador del cliente (obtenido en el paso de registro dinámico).
2. Tipo de respuesta que desea recibir de la transmisora (resultado del flujo deseado, en este caso el authorization code, será importante en la efectivación del consentimiento).
3. Otros parámetros de seguridad específicos del OAuth 2 (pueden ser detallados en artículos futuros).
4. Identificador del consentimiento.
   

Durante el flujo ocurren dos redireccionamientos, este primero tiene el objetivo de Autorizar a la receptora en la búsqueda de los datos y Autenticar al usuario para garantizar la seguridad. El segundo lo veremos en otros artículos. A continuación, sigue un diagrama macro que muestra los componentes involucrados durante este proceso:

1. El Motor de Consentimiento gestiona el consentimiento de intercambio de datos, iniciaciones de pagos y de todas las demás operaciones previstas por Open Finance que requieren consentimiento, cumpliendo así las definiciones del Banco Central en todas las transacciones.
2. El Authorization Server garantiza la seguridad de las operaciones de Open Finance, certificando la autorización de todas por medio de la implementación de reglas de OAuth 2.0, OpenID Connect y FAPI-RW, igualmente cumpliendo con todas las regulaciones del Banco Central.
3. La API Platform es responsable de garantizar los contratos regulatorios, logs, auditoría, etc. También ofrece gobernanza de las APIs, ya que los requisitos están en constante evolución.
   

En este artículo describimos el flujo de consentimiento mediante redirección, un estándar utilizado en Brasil, en América Latina el flujo de consentimiento debe seguir estándares similares. Lo más importante es que cada componente tecnológico trabaje para ofrecer seguridad y un viaje centrado en el usuario.