Por favor verifica tu e-mail para tener acceso completo al Hub haciendo click al link enviado a youremail@gmail.com
Reenviar correo de verificación
💣 Viene el entrenamiento intensivo en pagos instántaneos más completo de Latam. Reserva tu cupo en nuestro Fellowship

¿Cómo funciona el consentimiento del usuario para compartir sus datos en el Open Finance? by Sensedia

July 24, 2024
Por
Sensedia
Sensedia
Modern Integration Platform
📷
LFH
En este artículo, Sensedia detalla más sobre los requisitos técnicos del Open Finance. Vamos a discutir los principales componentes y cómo interactúan para definir una experiencia de usuario única con enfoque en seguridad.
Contenido para Usuarios 🔒

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.

Las opiniones compartidas y expresadas por los analistas son libres e independientes, y de ellas son responsables sus autores. No reflejan ni comprometen el pensamiento u opinión de Latam Fintech Hub, por lo cual no pueden ser interpretadas como recomendaciones emitidas por la platafomra. Esta plataforma es un espacio abierto para promover la diversidad de puntos de vista sobre el ecosistema Fintech.

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.

Las opiniones compartidas y expresadas por los analistas son libres e independientes, y solamente sus autores son responsables de ellas. No reflejan ni comprometen el pensamiento o la opinión del equipo de Latam Fintech Hub y, por lo tanto, no pueden interpretarse como recomendaciones emitidas por la plataforma. Esta plataforma es un espacio abierto para promover la diversidad de puntos de vista en el ecosistema Fintech.

Este contenido es solo para
usuarios Prime 👑 del Hub.

Hacer upgrade ▸
Apoyado por:
Conoce la plataforma de API´s más completa para Fintechs
Contacta al equipo
No items found.

Fintechs en
tendencia del Hub

No items found.

Ecosistema Fintech

¿Alguna novedad que quieras compartirnos?
escrÍbenos a hola@latamfintech.co
¿Alguna novedad que quieras compartirnos?
escrÍbenos a hola@latamfintech.co

Más Makers Imparables ⚡

Makers
Paytech 💳
Billetera virtual ligada a una APP y Tarjeta, que permite tener una mejor relación y control de tu dinero en línea.

Más Insights

Por
Transfi
Transfi
Powering the world’s payments
Paytech 💳

Nuestra comunidad

WHATSAPP
✨ Nuevo!
Tenemos un canal de Whatsapp donde contamos todos los movimientos en la industria.
Usuario pRIME 👑
Acceso ilimitado. Desbloquee la cobertura exclusiva, entrevistas con CEOs, eventos especiales y más.
Activar suscripción
RESUMEN SEMANAL
Todas las semanas envíamos a tu email un resumen con todos los avances en el ecosistema Fintech.
Abrir el Blueprint
Grupo de SLACK
Tenemos un grupo de Slack con todos los miembros registrados del Hub para que sigamos conversando.
uNIRSE AL GRUPO