.avif)
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.
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.
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:
La receptora debe:
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.
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.
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.
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.
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:
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:
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.
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.
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.
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:
La receptora debe:
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.
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.
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.
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.
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:
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:
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.
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.
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.
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:
La receptora debe:
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.
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.
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.
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.
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:
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:
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.
🤩 Forma parte del único programa de entrenamiento en Neobanking de Latam. Más información aquí
