Café da Manhã com Especialistas - Sensedia Open Banking

Fala gente, bom dia. Bom dia. Bom dia. Estamos com 68 pessoas atentas. Bom pessoal, desculpe o atraso aí, a gente teve alguns problemas técnicos aqui. Vou até pedir para a Roberta, que é do time da Sensedia, nos ajudar aqui a passar os slides. Então ela que vai me ajudar aí.

Bom pessoal, primeiramente, bom dia a todos aí. Hoje pessoal, a gente vai falar sobre uma visão técnica de Open Banking. Esse evento aqui é um evento organizado pela Sensedia, um evento mensal, que a gente traz os especialistas aqui do time da Sensedia para falar de temas específicos, temas técnicos relacionados a diversas abordagens aí que a gente trabalha. Bom, eu sou o Rafael Rocha, eu sou Head de Solutions aqui na Sensedia, e hoje a gente vai falar especificamente aí do tema de Open Banking. Beleza? Roberta, por favor.

Gente, vamos lá. Eu vou falar sobre, primeiramente, aqui posicionar o que a gente vai comentar, o que a gente vai falar da agenda. Roberta, você puder ir passando aí os itens e abrindo para mim, por favor?

Bom, primeiro aí pessoal, a gente vai falar sobre Open Banking, uma contextualização. Então como a gente vai falar especificamente aqui de uma visão técnica, o intuito aqui não é passar para vocês o que é Open Banking, mas ser uma visão bem macro disso. Depois a gente vai apresentar aqui uma Big Picture sobre uma visão arquitetural de Open Banking, onde nessa visão arquitetural tem os principais elementos de uma arquitetura de Open Banking. A partir dessa visão geral, dessa Big Picture, pessoal, a gente vai detalhar e falar um pouco de cada uma dos componentes ou desses elementos dessa arquitetura. Então a gente vai falar de:

APIs

Segurança

Compartilhamento

Consentimento

Integrações, e integrações com Core Banking, integrações com diretório central, plataformas

E no final a gente fala um pouquinho sobre a Sensedia, como a Sensedia pode ajudar vocês aí, se vocês estiverem buscando um auxílio aí nessa jornada de Open Banking. Beleza?

Bom, falando aí sobre Open Banking, pode passar, Roberto. Bom, pessoal, Open Banking, de novo, a ideia aqui não é passar para vocês o que é, por quê, mas sim o mais importante nesse momento. Obviamente, no contexto de oportunidades, Open Banking tem diversas oportunidades de negócio, de criação de produtos, de ecossistemas e por aí vai. Não é o intuito, nesse momento, a gente falar disso. Então o que eu trouxe aqui, pessoal, é uma visão só de cronograma para vocês entenderem a questão da regulação. Então esse é o principal ponto, porque várias instituições, nesse momento, estão buscando soluções de Open Banking para atender a questão da regulamentação e da regulação em torno de Open Banking no Brasil.

Então, falando de cronograma macro, basicamente a gente teve em fevereiro a fase 1, para os bancos S1 e S2. Agora em julho a gente tem a fase 2, fase 3 em 30 de agosto e 15 de dezembro fase 4. O que é fase 1, pessoal? Fase 1 são dados estáticos, são informações sobre canais de atendimento, produtos, serviços relacionados à conta depósito, crédito e etc. Então são informações basicamente estáticas e do que a gente chama de Open Data, ou seja, de domínio público. Já a partir da segunda fase a gente fala de dados relacionados aos clientes. Então são dados de transações, cadastros e entre outros. Já a partir da fase 2, então começa a questão do consentimento. Então tem toda uma questão de uma jornada de consentimento que para as instituições poderemcompartilhar os dados, tem que passar por toda essa jornada de compartilhamento. A partir da fase 3, pessoal, a gente está falando então de iniciação de pagamento e créditos. Nesse momento também tem a jornada de compartilhamento, a jornada de permissionamento de uma certa transação ali. Atualmente o PIX é um dos primeiros que já foram liberados pelo Bassem. E por último, pessoal, outros produtos na fase 4, a gente está falando de outros produtos, serviços, transações e etc.

Bom, pessoal, só uma visão, panorama geral aqui, essas datas são importantes porque é o que as instituições estão olhando fortemente agora, então num primeiro momento falando disso, olhando para isso, para ir num segundo momento ou até em paralelo já tentar fomentar novos negócios ou dar um sentido de negócios também para dentro desse contexto de Open Banking.

Roberta, por favor.

Pessoal, então vou falar aqui da Big Picture. Primeiramente, eu vou posicionar vocês da seguinte forma. Bom, como vocês sabem, existem os dois lados das instituições que estão dentro desse cenário de Open Banking. Tem um cenário que tem a camada da consumidora da informação, que é o que na fase 2 a gente chama de receptora, ou na fase 3 que é a iniciadora do pagamento. Então essas empresas se posicionam nesta camada consumidora. Então estão aqui as provedores de pagamento, estão as fintechs, estão os bancos e etc. E na outra camada, a camada provedora, que é onde a regulação pega. Então onde as instituições têm que se posicionar como provedora da informação, do dado ou do serviço, no caso da fase 3, serviço de pagamento. Então essas instituições são aquelas instituições S1, S2, enfim, todas as instituições financeiras que têm conta ou que está registrado lá no Banco Central. Então essas são a camada das provedores. É assim que a gente se posiciona, se a gente for pensar no Open Banking em camadas.

Roberta, por favor.

Aí tem uma camada, a camada regulatória, que aí entra o sandbox do Bacem, entra também o diretório central e entra também toda a camada de gestão. Então toda essa camada regulatória hoje, as instituições se comunicam diretamente. Por exemplo, para fazer o registro para obter o certificado, o software statement e por aí vai. Ou seja, toda a interação, as instituições se conectam direto, elas fazem todo esse onboarding diretamente com essa camada regulatória. Então desde registrar a instituição, desde registrar o software statement, desde usar o sandbox, porque hoje a questão do sandbox é da camada regulatória, ou seja, do Banco Central. Então neste sandbox é onde tem a camada do banco modelo, onde tem as APIs, onde vai ter uma massa de dados, onde vai ter todo o processo de onboarding, de uso no modelo sandbox. Tem obviamente todo o cadastro, o diretório central, onde de fato está o catálogo dos endpoints, onde estão todas as informações, onde estão as chaves, os statements, enfim. E tem toda essa camada de gestão, onde essa gestão faz gestão, por exemplo, do ressarcimento, que é algo que está para vir. Como fazer o ressarcimento? Então tem todo o motor de ressarcimento, o motor de aprovação também, o motor de validação em torno de toda essa jornada das instituições.

Bom, aí do lado dessa camada da regulação, que é a figura hoje aqui do Banco Central do Brasil e onde todos os grupos estão trabalhando, os grupos de trabalho estão trabalhando nesta camada, surge aí a camada de fato de Open Banking, que é onde as instituições, tanto provedoras como consumidoras, se conectam a essa camada de Open Banking. E quais são, dentro dessa camada de OpenBanking, quais são os principais elementos? O primeiro elemento é APIs, como acredito que a maioria de vocês saibam, toda a intercomunicação entre a instituição receptora, iniciadora de pagamento e a camada provedora é via APIs. Então existe todo um contexto de APIs, uma série de APIs que estão sendo definidos, então esse é um elemento primordial nessa arquitetura.

O segundo elemento, pessoal, como eu já mencionei, é toda a gestão da jornada e gestão de fato do consentimento dos clientes. Então uma camada de Open Banking tem que se preocupar em ter essa capacidade de fazer toda a gestão.

O terceiro principal elemento está relacionado à segurança, no que tange à autorização, no que tange à autenticação, entre outros elementos. A gente vai falar um pouco mais no detalhe aqui em termos técnicos do que é esperado, mas enfim, todos os modelos de autenticação estão nessa camada de segurança.

Dentro também da arquitetura de Open Banking tem um elemento fundamental que é a conexão com o legado, a conexão com o Core Banking, ou seja, da conexão onde estão de fato os dados, por exemplo, da fase 1 e fase 2, e onde estão ali os serviços relacionados à iniciação de pagamento, créditos e por aí vai. Então tem esse elemento fundamental que é a conexão com o Core Banking ou com o legado.

Além disso, obviamente, uma camada de Open Banking tem que prever essa conectividade com a camada regulatória. Então aí desde prover a integração de obter os dados e as informações do diretório central, por exemplo, e também prover todas as interfaces para que o Bacen, para que essa camada regulatória venha consumir dados como métricas e elementos como esse.

Pode passar, Roberto, por favor. Pode ir para o próximo.

Bom, pessoal, então explodindo ali, a gente vai falar sobre APIs.

Fase 1. O que é fase 1? Fase 1 é abertura e disponibilização de dados públicos. É o que eu falei, Open Data, geralmente estáticos, relacionados a canais de atendimento, aos produtos bancários, serviços bancários e etc. Os recursos que tem hoje, se vocês veem lá no GitHub, no portal do desenvolvedor, vai estar lá discriminando, vai ter o Swagger na versão 3.0 desses recursos de APIs. Então os recursos aqui, eu estou falando de recursos de API, que são os recursos que devem ser implementados nessa primeira fase. Então a gente está falando aqui de basicamente status, outages e métricas, são dados relacionados aos SLAs e a toda a camada de monitoramento dessas APIs. E aí os recursos relacionados a de fato os dados Open Data, são os recursos relacionados a canais e produtos e serviços. E aí se vocês entrarem lá no site do desenvolvedor, no portal do desenvolvedor, vai ter o Swagger, vocês podem baixar o Swagger, é o Swagger oficial dessa fase 1. Então está lá, está todo discriminado corretamente.

Bom, falando ainda de uma perspectiva técnica, quais são os padrões relacionados à fase 1? São os padrões, basicamente todas as APIs, elas estão no modelo RESTful, esse é o modelo padrão, isso foi amplamente discutido desde as primeiras conversas de que o Banco Central não ia criar um novo padrão e sim reusar padrões de mercado, e é isso o pessoal que tem sido de fato. Então a escolha mais do que óbvia pelo padrão de APIs RESTful, o modelo de especificação já na última versão, nas últimas versões aqui do OpenAPI Spec, que é o Swagger, na versão 3.0, e aí tem elementos de H2S também nessas APIs RESTful, então isso é explícito se vocês olharem lá na documentação que tem que prever os metadados, que tem que prever todos os recursos de link e tudo que é mais relacionado a H2S. E obviamente uma questão do ponto de vista semântico, deversionamento, então usando o versionamento semântico 1.0.1, ou seja, major, minor e o patch ali. Então isso é a versão. E o patch ali, né? Então, isso é um versionamento semântico, né? Na camada de segurança, pessoal, da fase 1, essa camada mais tranquila, né? Em termos de segurança, porque são dados open data. Então, deixa muito explícito que não há uma forma específica de... Está muito mais em aberto, né? O que se recomenda é usar TLS 1.0, é ter uma camada de firewall também na frente da instituição, é possivelmente criar um elemento de autenticação baseado em JWT, né? E, obviamente, o que se sugere também é que tenha uma camada de proteção baseada em padrões de mercado, como o API Management, como gateways e etc. Além de elementos, por exemplo, de permissionamento, de habilitar cores, por exemplo, para que essas APIs, obviamente, sejam muito mais consumíveis aí pela camada de front-end, né?

Pode seguir, Roberto. Pode ir clicando aí, por favor, para abrir as outras caixas desse canvas aqui, pessoal. Ponto importante aqui dos recursos não funcionais, tá, pessoal? Então, disponibilidade de 95,9.5 em três meses, tá? Performance de um segundo e meio para as APIs de canais e serviços, tá, pessoal? E alguns limites aqui, como, por exemplo, limites relacionados a 300 transações por segundo ou 500 requisições por minuto para cada receptora da informação, tá?

Pessoal, todas essas informações aqui que eu trago de recursos, de padrões, de segurança, tá tudo descrito lá no detalhe no portal do desenvolvedor, tá? Então, tem até mais detalhes sobre os requisitos não funcionais lá no portal, depois eu deixo o link para vocês aqui, caso vocês não tenham o link do portal do desenvolvedor, tá?

Bom, além dos recursos não funcionais, na fase 1 não tem o consentimento, como eu comentei, é open data, né? São dados estáticos, até os modelos de segurança são mais flexíveis, né? Como eu disse aqui na questão da segurança.

Bom, pessoal, e de recomendação técnica, tá? Isso não tem no site do desenvolvedor, isso é recomendação técnica da Sensedia, nós que estamos desenvolvendo soluções de open banking para diversos clientes aqui no Brasil. O que a gente tem recomendado, né? Primeiro, pessoal, recomendação número 1 para essa fase 1:

A criação de uma camada de virtualização ou de cache de performance. O que significa isso? Significa que, como são dados open data, são dados estáticos, né? Ao invés de bater diretamente lá no core banking ou no sistema transacional, cria-se uma camada, né? Uma camada de virtualização, uma camada de normalização, mas essa camada de normalização já otimizada para leitura, né? Esses dados vão ser, obviamente, além de estar também em uma infraestrutura separada, enfim, e também já pensando nesses requisitos não funcionais, a gente está falando aqui de 300 TPS, por exemplo, e coisas do tipo. Então, o que se recomenda é se fazer algo nessa linha, né? Criar uma camada de virtualização e uma camada de cache. Então, ter camada de cache ali. Alguns gateways têm cache já embutido. Então, por exemplo, pode-se criar essa camada de banco de dados e uma camada de cache na frente do banco de dados, tá? Isso que a gente tem recomendado para os nossos clientes. Estou falando da fase 1.

Pessoal, gateway de APIs também, fundamental, porque a gente está falando aqui de monitoramento, por exemplo, de disponibilidade. A gente está falando de throughput, a gente está falando de throttling. Então, esse throttling, por exemplo, configurar 500 requisições por receptora. Geralmente, um gateway tem essa possibilidade, um API manager. Um API manager que embute, obviamente, um gateway dentro da solução, dentro de uma plataforma de API management. Tem ali a opção de eu criar essas regras de throttling, que são fundamentais, obviamente, para a gente respeitar os limites que estão sendo estabelecidos aqui também e economizar recursos e por aí vai, enfim. São uma série de benefícios. Então, o uso de gateways para throttling e para segurança, porque o gateway já tem o TLS, já tem alguns recursos relacionados a firewall, por exemplo, tem suporte a JWT, tem suporte a cores e por aí vai. Então, geralmente, o gateway é um gatewayde APIs que já embarca todas essas tecnologias que são de uso do padrão do Open Banking. Suporte a RESTful, suporte a OpenAPI Spec. Suporte a RESTful, suporte a Open API spec e por aí vai. Bom, além disso, o API management, diferente do gateway que tem um uso mais do ponto de vista do runtime, o API management de mercado pessoal geralmente vai ter ali recursos adicionais no que tange a dashboards para acompanhamento dessas métricas, dessas SLAs, recursos também para alertas em tempo real caso tenha um outage, por exemplo, ou enfim, infringir alguma métrica.

Olá, Roberto, vamos para o próximo slide, por favor? Pode ir abrindo todos aí? Bom, pessoal, fase 2, tá? Fase 2 aqui, então, abertura de dados de clientes. Aqui a gente está falando de dados de clientes, né? Dados cadastrais, informações de transações de conta, informações de cartão, produtos, de crédito de conta, etc. Isso se reflete nos recursos, os mesmos recursos de altas métricas continuam, porque são recursos de monitoramento que devem ser providos para que o BACEN venha consumir essas informações. Então, esses três continuam.

O que está em asterisco aqui? Aí já começa a entrar as APIs relacionadas ao consentimento, aos recursos relacionados aos recursos consentidos, ou seja, a lista de informações. Já tem os endpoints relacionados a:

Dados cadastrais

Dados de cartão

Dados de conta

Dados de operação de crédito

De novo, tudo lá detalhado, swagger, com todos os detalhes dessas APIs, desses recursos lá no site. O que muda aqui em termos dos padrões em relação à primeira fase são praticamente os mesmos. O que existe aqui na fase 2, desculpa pessoal, em deputência a partir da fase 3. Então, ele se mantém os mesmos padrões. O que muda é na questão da segurança aqui. Então, a partir da fase 2 exige-se FAPRW.

Então, o que é o FAPRW? O FAPRW é um profile dentro da especificação de OpenID Connect. E o que ele tem? Ele vai ter, primeiro, ele infere que tem que ter o suporte ao MTDS, que tenha suporte a todas, o ID token tem que ser baseado em JWT, e que, obviamente, tem todas as claims em torno do permissionamento, ou seja, já tem o suporte em relação à questão do consentimento aqui. Então, esse é o elemento. Além, obviamente, de requer a autenticação baseada, FAPRW pode ser usado em conjunto com o ALF e, obviamente, em cima do OpenID Connect.

O que entra aqui também já é o Dynamic Client Registration, que é, basicamente, como as instituições pedem, então, as credenciais, fazem os registros e obtêm as credenciais e os tokens de acesso para toda a infraestrutura de OpenBank. Então, já na fase 2, já tem que se prever suporte a esses padrões aqui de segurança.

Do ponto de vista de requisitos não funcionais, praticamente são os mesmos requisitos. O que muda, pessoal, é que o consentimento, o consentimento parte a ter a questão da receptora mais a transmissora, ou seja, a receptora do dado e a transmissora, passa a ter também a questão da gestão do consentimento, então, passa a ter a possibilidade de dar aí todo o poder de prazo, revogação, atualização e renovação.

Então, aqui já entra, em termos de solução técnica, prover conjunto de APIs para que os canais se pluguem às APIs de consentimento ou mesmo que usem telas já no formato como, por exemplo, a gente pode oferecer aqui, que a gente chama de white label, que são telas, já que as telas do consentimento precisam ser previstas seguindo o grupo de experiência, então já tem um modelo de layout a seguir, um modelo de experiência do usuário a seguir. Então, tem essa camada de telas para fazer toda a jornada, desde dar a possibilidade do consentimento até, obviamente, dar o poder para a gestão do consentimento. Então, de fazer lá, por exemplo,a revogação e tudo mais.

Bom, o que a gente recomenda, então, tecnicamente aqui? Uma solução de consentimento. Recomenda então tecnicamente aqui uma solução de consentimento. Então essa solução de consentimento é padronizada de mercado. Então faz sentido, obviamente, uma opção. Pode construir tudo dentro de casa ou usar um produto, ou usar uma solução já pronta de consentimento que já implementa todas essas regras que já foram estabelecidas do ponto de vista do consentimento, que já tem todas essas capacidades de fazer autenticação, de registrar a intenção do consentimento, de registrar de fato o consentimento, de dar o poder da gestão. Então uma solução engloba isso. Essa solução de consentimento engloba tela, camada de API, regras, camada de dados para guardar todas as informações relacionadas ao consentimento do cliente. Então essa é uma primeira recomendação.

As outras recomendações em torno de API Gateway Manager continuam da mesma forma aqui. Além, obviamente, também a gente sugere as camadas de normalização, ou seja, criar aquelas camadas que, como são dados, esses dados podem ser otimizados, criar uma camada de dados, uma camada de normalização com os dados do cliente dentro de uma infraestrutura apartada. Essa é uma recomendação também para a fase 2. E, obviamente, também o uso já de plataforma de Open Banking. As plataformas de Open Banking já vêm com essas capabilities de implementar esse modelo de segurança, de implementar o consentimento, de implementar, enfim, todos os recursos relacionados ali às fases e o que o regulador está pedindo.

Pode ir para a próxima, Roberto, por favor. Pessoal, falando fase 3 agora. Fase 3 é iniciação de pagamento. Por enquanto, pessoal, o que está entrando aqui? Está entrando o Pix. Ontem, a última vez que eu vi lá no site do desenvolvedor, o Pix era o que estava disponível atualmente. Bom, além do pagamento, o que muda, então, em relação à fase 2? Primeiro, muda do ponto de vista de padrões. Tem a questão da indepotência. O que é esse tipo de recurso de indepotência? Permitir que, obviamente, transações sejam efetuadas de maneira repetida, sem que se altere o estado final. Isso é indepotência. Então, tem que prever, por conta de a gente estar falando de integração de sistemas, a gente estar falando de questões relacionadas a arquiteturas distribuídas e por aí vai. Isso justifica a indepotência. Então, tem que se prever a questão da indepotência aqui para os recursos de pagamento, por exemplo, do Pix.

O segundo, além disso, o que muda em termos de segurança? Que entra o CIBA. O CIBA é o profile, é uma extensão do profile aqui, do FAPI, onde ele foca na parte da autenticação. Então, é uma autenticação autoassinada, que também já prevê os claims, já no formato de ID token. E é isso que o CIBA prevê, essa camada de autenticação, autoassinada neste modelo, obviamente, para permitir que esse modelo de autenticação, que permitisse a execução de serviços relacionados aqui ao Pix.

Bom, pessoal, o que muda do ponto de vista de consentimento? Muda, as telas mudam. Não sei se vocês já viram, eles disponibilizaram já o protótipo e o protótipo muda. Muda a figura da iniciadora e da detentora, ao invés da receptora e transmissora. E o consentimento, pessoal, é por transação, diferente de quando você compartilha os dados, o consentimento tem um prazo de compartilhar e você ter posse daqueles dados. Aqui não, cada transação tem um consentimento diferente e apartado. Bom, basicamente é isso. As recomendações também continuam sendo as mesmas, plataformas de open banking que já suportam esse modelo de consentimento individual, esse modelo que suporta CIBA, por exemplo, já é recomendado nesse contexto aqui.

Pode seguir, por favor, Roberto. Vamos lá, pessoal, segurança. Podemudar, Roberto. Vou dar uma acelerada aqui, pessoal, porque a gente tem alguns minutos. Bom, modelo de segurança, pessoal, eu comentei os padrões:

OpenID Connect

ALF

FAP

RW

CIBA.

Esse é o protocolo standard padrão de mercado. Implementação, o que a gente recomenda? Existem algumas implementações que são, inclusive, reconhecidas como já são certificadas, por exemplo, pela instituição OpenID Connect, FAP, CIBA, por exemplo. Então, do ponto de vista da visão de implementação, a gente recomenda algo, por exemplo, o GLU, que é uma das opções. Tem um modelo Enterprise e tem um modelo Open Source, que é, inclusive, o que a Sinncydia usa na nossa solução de Open Banking.

Então, o GLU Server 4.2, na versão Jensen, que é a versão Open Source. Se vocês procurarem Jensen GLU, você vai ter a versão Open Source do GLU Server 4.2, que já tem o suporte nativo para FAP, RW e CIBA, bem como já é certificado pelo OpenID Connect como software Open Source, já implementando esses protocolos. Fica aqui a recomendação para vocês, algo nessa linha aí, usarem algo já certificado, tá, pessoal? Seguir, Roberto, por favor.

Bom, pessoal, aí eu vou falar um pouco do consentimento. Aqui no consentimento, pessoal, a gente tem várias capacidades aqui que devem ser implementadas, né? Então, o consentimento certamente é a parte, eu diria, a parte mais crítica aqui, né? Porque tem várias capacidades que a gente precisa implementar, desde:

a intenção do consentimento

da criação do consentimento

ou da intenção que é o pattern, o intent pattern

prever a primeira intenção do consentimento

provisionar

revogar o consentimento

ou mudar a expiração

regras em torno de validação

enfim, troubleshooting

configurações em torno desse engine, desse motor

toda a possibilidade de prover leitura

toda a possibilidade de prever a exposição via eventos, né?

A nossa solução, pessoal, é a gente tem o motor de consentimento e que tudo que acontece nesse motor de consentimento, a gente pluga num pub-sub, numa fila, né? Então, por exemplo, a intenção do consentimento, a revogação do consentimento, enfim, tudo relacionado, qualquer alteração no estado do consentimento, basicamente é publicado um evento numa fila e aí as instituições se plugam para observar aquele evento e tomar uma ação, né? Desde fazer análise anti-fraude, desde tentar criar uma campanha para o cliente que está abrindo os dados para outra instituição, por aí vai, tem diversos usos em torno de saber por que aquele cliente está consentindo, né? Então, prover a conectividade desse motor via APIs ou via modelos de pub-sub, de eventos via pub-sub, por exemplo, é fundamental numa estratégia de ter um modelo de consentimento extensível aqui, né, pessoal? Além, obviamente, de ter de auditoria e de integração com as questões de segurança e autorizações, são capacidades fundamentais, né?

Pode passar, Roberto, por favor. Aí, um pouco do fluxo, pessoal, pode ir passando aí, Roberto. O fluxo aqui, pessoal, esse é o fluxo de consentimento, dentro desse fluxo de consentimento a gente tem a visão da instituição receptora, então, por exemplo, em azul aí, pessoal, vocês observam, desde o início da jornada de compartilhamento, ele seleciona:

isso

fica aí, obrigado

seleciona o banco como transmissora

seleciona qual o tipo

configura o prazo

confirma e redireciona para o banco, né?

Todo esse fluxo está implementado e é de domínio público, tá, pessoal? Toda essa especificação já é de domínio público, né? E aí, onde que entra aí a questão da arquitetura de consentimento? Então, tem uma camada de telas, tem uma camada de gateway e tem a camada do back-end, lá embaixo, né? Então, na camada de consentimento, que é onde a gente estava comentando muito de uma solução de consentimento, né? Uma plataforma de consentimento,ela vai prover uma tela, ela vai prover muitas vezes o white label e ela vai prover integrações via APIs com o back-end, né? Então, toda a parte ali de OpenTK, depois trazer os dados para a tela para o cliente avaliar, confirmação, registro da confirmação, fazer um redirect lá para a transmissora, para a receptora, né? E, de fato, a receptora efetivar uma transação, chamando a API do OpenBanking, e essa API do OpenBanking fazendo a validação, por exemplo, do consentimento, né? Além de fazer a validação da autenticação baseada em FAP e CIBA, além disso, também fazendo a validação, por exemplo, se existe um consentimento válido.

Então, tem dois steps básicos. Depois que tudo isso acontece, pessoal, na efetivação daquela transação, existe, obviamente, a autenticação e autorização, depois a validação do consentimento. Passou por esses dois fluxos, aí sim vai para o back-end, vai para efetivar o PIX, vai para, enfim, trazer os dados ali conforme. Pode seguir, Roberto, por favor.

Pessoal, aí uma visão do consentimento também do ponto de vista de gestão do consentimento, né? Então, através dos canais, o cliente de vocês precisam disponibilizar a listagem de consentimento e permitir que essa listagem possa ser revogada ou possa ser alterada os consentimentos. E, obviamente, que toda essa camada de visualização, essa camada de front, faz toda essa integração via camada de APIs, de um gateway de APIs, e por si só isso aí bate lá no core banking, no back-end da instituição. Pode seguir, Roberto.

Gente, falando agora um pouco aqui de integrações, né? O que a gente recomenda do ponto de vista de, primeiro, de integrações, a gente faz integrações com diretório, tá? Então, existem duas formas, né? O diretório, ele vai fazer uma integração, então, se vocês lembram, os recursos de todas as fases, né? Que são os recursos de APIs para status, de altas e métricas, né? Esse, o diretório, o Banco Central, o regulador, ele vem a cada 30 segundos, ele vem bater nessas APIs para avaliar o status dos altas e as métricas, né? Então, tem um, do lado do diretório, tem um polling, né? Coletores lá que estão fazendo a cada 30 segundos esse HTTP polling, né?

E aí, essa camada de status, né? O que a gente recomenda, né? Primeiro, a gente recomenda aqui que exista coletores, existe toda uma capa, toda uma camada de microservices, onde essa camada de microservices dentro dessa camada de Open Banking, ela que vai até o back-end, por exemplo, coletar, por quê? Existem métricas relacionadas à sua camada de APIs, que um gateway de APIs entrega, mas tem outras, por exemplo, altas, programação de altas. O gateway não tem isso, né? Então, geralmente, vai ter que ir para um outro sistema. Então, tem que ter, recomenda-se que tenha uma camada de serviços, de workers e de coletores que vão até o back-end, por exemplo, trazer os dados relacionados a métricas, a altas, que no que tange a camada de back-end.

Toda essa camada de back-end, então, de microservices, ela coloca numa view, num banco de dados, onde nessa view de banco de dados, vai oferecer, vai estar no formato otimizado para leitura das APIs, de status de altas, etc., que também tem SLA, né, pessoal? Além disso, nessa camada de Open Banking, a gente tem que prever fazer os call-outs das APIs do diretório e do service desk, né? O que significa isso? Trazer questões dos SSAs, das software statements, as assertions, por exemplo, que faz parte de toda a parte do registro dinâmico, né? Então, todas as informações, bater na API do diretório, trazer essas informações para dentro de casa, para otimizar todo o processo, né?

Então, assim, todo o processo, por exemplo, o processo de autenticação, o processo de registro, né? Às vezes, nos pode fazer todo esse caminho direto, né? Por questões de, obviamente, de atender performance, né? Então, a recomendação é que você tenha call-outs que trazem essas APIs, que trazem dados dessas APIs do diretório, bem como também report service desk, caso, por exemplo, alguma métrica, altas, ou qualquer coisa do tipo, aconteça dentro da infraestrutura de Open Banking, que se registre via API do service desk lá um incidente ou alguma coisa relacionada a isso daí, tá? Isso é oque a gente recomenda em torno da camada de integração.

Bom, e aí o Core Banking Connectors, né? Então, dentro dessa infraestrutura, a gente tem que prever a conectividade com o core banking, né? O que a gente recomenda, né? O que a gente tem feito, né? Primeiro, né? O que são conectores, né? O conceito de conectores que a gente tem implementado e tem recomendado a implementação.

A gente tem recomendado, primeiramente, obviamente, os conectores têm essa capability, aqui embaixo, se vocês verem, né? O conector tem que ter, primeiro, né? A capacidade de prover uma interface já no Swagger do Open Banking, tá? Tem que ter uma capacidade de transformar. Por quê? Por vezes, a gente vai ter que se conectar lá com o back-end para trazer os dados à quente, né? Se essa for a decisão, porque como eu falei, né? Você pode, fase 1, fase 2, pode trazer, se o seu back-end está preparado, né? Você pode se conectar diretamente com o back-end do core banking e se já tem uma API pronta do outro lado, uma interface, um serviço, HTTP, alguma coisa do tipo, então você pode criar essa normalização.

Então, essa normalização à quente acontece com esses conectores de core banking. Então, tem uma interface, já a interface do Swagger do Banco Central, no Open Spec. Tem que ter uma capacidade aqui, esse conector tem que ter essa capacidade aqui de transformar e tem que ter essa capacidade aqui de, de fato, ter a conectividade com o core banking, né? Ou seja, dependendo do tipo de interface, seja SOAP, seja HTTP, seja RFC, seja, enfim, banco de dados, o que for, né? Tem que ter essa capacidade de se conectar para fazer a tradução do protocolo de comunicação, né?

Então, isso que a gente recomenda é a criação desse tipo de conectores para fazer essa intermediação para os core banking ali, de onde está a informação que a gente vai trazer das fases aí, né? Ou se conectar via PIX, por exemplo, né?

Em termos de implementação, pessoal, de implantação, o que a gente tem recomendado é que esses conectores fiquem implantados dentro da infraestrutura, plantados dentro da infraestrutura. O que a gente recomenda, obviamente, o modelo cloud para essa camada de open banking, né? Obviamente, por quê? Já tem todos os recursos relacionados, já que é uma camada open, né? Já que é uma camada aberta, né? Mais do que justo usar e abusar dos recursos de cloud, né? Então, a gente fortemente recomenda ter o gateway aqui e esse conector, né?

Então, o gateway, o que ele vai fazer, né? O gateway vai receber, vai tratar aqui os tokens do FAB-CIBA, toda a parte de autenticação, né? Throttling, MTLS, tudo é o gateway que faz, né, pessoal? E aí, obviamente, o conector tem essa responsabilidade de fazer a tradução aqui do core banking ou do modelo do core banking, né?

Então, o que a gente recomenda é que esse conector fique na infraestrutura do cliente, obviamente, né? Estando numa DMZ, né? Ou estando numa rede ali de saída para uma rede de saída da infraestrutura do cliente, né? Então, aqui, obviamente, pode ser um premise, pode ser uma VPC dele, pode ser em qualquer ambiente do cliente aqui, não precisa ser colocation de fato aqui não, tá, pessoal? É só uma recomendação.

Obviamente, o outro modelo, né, pessoal, é fazer todo esse setup dentro da infraestrutura do cliente, né? Então, desde os gates, consentimento e por aí vai, né? A gente tem menos visto o que acontecer, né? A maioria tem optado por colocar na nuvem, por ter todos esses benefícios que já é conhecido aqui. Eu nem vou me alongar muito e falar sobre cloud aqui, né? Pode passar.

Bom, gente, aí, falando de plataforma, né? Então, tudo isso, né? O que eu comentei, né? Em termos de plataforma, a plataforma já tem tudo isso, né? Então, esse é o benefício, né? Já estar pronto para acelerar. Como vocês viram no começo, a data tá ali, né? Tá logo ali, né? Então, obviamente, uma plataforma de open banking, ela tem um gate embarcado, ela tem gestão do consentimento, ela tem um authorization server e, além disso, a plataforma, o que a gente recomenda é que tenha muito mais do que o básico, do que o mínimo, né?

De ter, por exemplo, as questões relacionadas a N outros modelos de segurança, a suporte, a gestão e a governança, relatórios e etc., né? Então, ter uma visão muito mais analítica do que tá acontecendo. Então, ter relatórios quanto a isso, né?Ter uma série ali de informações de log em tracing. Como eu disse, né? Ter a possibilidade também de processar eventos, porque por vezes a gente vai precisar guardar, por exemplo, esses logs por cinco anos, por exemplo, então a gente pode usar um modelo eventual para cada transação que passa pelo Open Banking, vai lá para um data center, vai lá para algum lugar. Além disso, tem toda a integração que está vindo aí para o ressarcimento que pode ser via evento, então cada transação, um evento, e esse evento vai dentro do contexto de ressarcimento, vai ter os eventos relacionados para que as instituições possam fazer o ressarcimento quando o ressarcimento chegar. Questões relacionadas à otimização e etc.

Então uma plataforma de Open Banking tem todos esses elementos que eu comentei, e muito mais do que isso também, todas as integrações e etc. E é uma plataforma muito mais, e também recursos, por exemplo, como PCA e por aí vai. Então o que a gente recomenda é ter plataformas, se você já tem uma plataforma de Open Banking que embarca o API Management, que embarca gateways de APIs e muito mais, então além do Open Banking, a gente tem todo esse tipo de arcabouço para atender, como eu disse, não só o regulatório, mas também o que vem depois do regulatório. Algumas empresas já estão pensando nisso, que é como ter proveito negocial na coisa, criar produtos, criar ecossistemas.

E aí elementos aqui serão fundamentais, a gente está falando de elementos aqui como Dev Portal, elementos adicionais a toda essa infraestrutura. Então o que a gente recomenda é uma plataforma para acelerar, que já traga, obviamente, toda a regulamentação já embarcada. Então já tem um Authorization Server embarcado com FAP, CIBA, com todos os recursos que são fundamentais em uma estratégia de Open Banking para atender a regulação. Pode passar ainda.

Bom, além disso, pessoal, a solução completa a gente recomenda, obviamente, além do componente de software, a gente recomenda também o componente humano. A gente está falando aqui de inteligência, de consultoria, de serviços profissionais e etc. Numa solução completa. Por quê? Por vezes, a nossa solução, além de ter todos esses elementos de segurança que eu comentei, suporte à especificação, já ter todas as tecnologias embarcadas, muito mais do que isso, prover, por exemplo, um sandbox para uma estratégia além regulatória. Ou seja, eu quero, na minha estratégia de Open Banking, estou utilizando as APIs que são do regulatório, além disso, já estou abrindo, já estou criando as APIs aqui para criar um ecossistema, criar parcerias, ou lançando o meu produto junto com o Open Banking.

Então, um sandbox, por exemplo, para que as outras instituições, fintechs, etc., consigam usar esses serviços além de Open Banking, é o que a gente recomenda pensar também, avaliar também numa estratégia completa. Esse é do ponto de vista dos elementos técnicos.

Mas, além disso, a gente, do ponto de vista de serviços, do ponto de vista de estratégia de Open Banking, a gente recomenda, por exemplo, ter um olhar sobre estratégia mesmo. Então, além do regulatório, o que eu posso fazer com esses dados? Se eu entrar na fase 1, na fase 2, que tipo de insights eu posso ter? O que eu vou fazer com esses dados? Que tipo de elementos eu posso ter? Que tipo de proveito, de que tipo de produtos eu posso ter baseado nisso?

Então, ter um olhar mais estratégico, a gente recomenda também, avaliando a questão de possibilidades já de negociar, ou seja, de já estar na frente e já compartilhar as informações, compartilhar serviços e por aí vai. Então, olhar de forma estratégica, aqui a gente tem uma recomendação fundamental sobre a estratégia como um todo de Open Banking.

Além disso, a gente fala aqui no outro ladode governança, falar de governança no sentido de que as APIs, toda essa infraestrutura, ela é crítica. Então, não basta atender o regulatório, atender a data de 30 de agosto, por exemplo, da fase 3. A gente precisa ter como vai ser o modelo de governança, de atualização, de troubleshooting, de operacionalização, e por aí vai. São diversas questões que a gente precisa avaliar aqui do ponto de vista de governança e pensar nesse modelo operacional, ciclo de vida, catálogo, versionamento e por aí vai. Então, sugiro fortemente que vocês avaliem também essa questão da governança de APIs pós-regulatório.

Além disso, ter um olhar sobre o que a gente chama de API Care aqui, mas é toda a estratégia de sustentação. Como que vai ser a estratégia de sustentação? Por exemplo:

As APIs, quando um alerta for emitido por sua plataforma, como que o time de sustentação vai abordar?

O que ele vai fazer?

Quem que ele vai abordar?

Como que ele vai repassar para o time de back-end, por exemplo, se for um problema no time de back-end?

O que ele vai fazer para atacar a camada de APIs ali, caso seja um problema?

Enfim, toda pensar na estratégia de sustentação e de operação dessa plataforma. Isso que a gente chama aqui na Cincidia de API Care, de ter esse cuidado com o API.

E por último aqui, pessoal, ter a visão do Developer Experience, que é também, de novo, junto com o Sandbox, olhar para as questões mais relacionadas ao Developer Experience, a como as instituições que vão usar esse novo serviço, essas novas APIs, as instituições vão fazer essa, vai ajudar em toda essa jornada, esse on-boarding. É isso.

Gente, é isso. Rapidamente pela Cincidia, aqui um minutinho. Cincidia, empresa brasileira, mais de 500 pessoas, foco em API, Open Banking, Open Finance em geral, escritórios do mundo inteiro. Temos vagas, tá pessoal? Pode passar aí. Eu já abri para perguntas aqui, né pessoal? Clientes aqui, pessoal, diversos setores, financeiro é onde a gente tem muitos clientes, mas fora a nossa plataforma de Open Banking, a nossa plataforma de APIs, Open Management, atende a todos os setores aqui da indústria e da economia nacional. Pode passar aí. E é isso.

E como eu comentei, né, Cincidia tem essa oferta, tem essa, só para concluir, né, tem essa oferta de Open Banking, tem a plataforma de integração, API Management e tem todos esses serviços que eu mencionei aqui de consultoria especializados que vão ajudar aí na estratégia, podem ajudar, obviamente, vocês aí na estratégia de Open Banking. Beleza, gente? Isso aí, tá meu contato aí, pessoal.

Vou pedir para o pessoal me ajudar aqui com as questões. Oi, Rocha, bom dia a todos, aqui é a Flávia do time de marketing da Cincidia. Rocha, a gente teve uma pergunta aqui falando a respeito de se a tela de consentimento fica na nuvem. Nós já respondemos aqui no chat, mas se você quiser complementar, pode ficar à vontade. Sim, ela pode ficar na nuvem, né? Depende do deployment que, no caso da Cincidia, a solução da Cincidia em si, ela é nuvem. Então, ela fica deployada, fica implantada na nuvem e ela é gerenciada pela Cincidia. Então, toda a solução é gerenciada pela Cincidia. Obviamente, se você for utilizar de outras soluções ou implementar, obviamente, todas essas telas de consentimento, essa camada de consentimento, você tem a liberdade, obviamente, de escolher o deployment. Mas, especificamente da Cincidia, é o modelo nuvem que a gente está adotando por padrão. Legal.

Pessoal, tem mais alguma pergunta a respeito do conteúdo? A gente pode responder mais duas ou três aqui para não estourar muito tempo? Se quiserem abrir o microfone também, fiquem à vontade. A Galera, tem perguntado bastante aqui sobre a apresentação. Ela está sendo gravada e vai ser enviada por e-mail para vocês. perguntado bastante aqui sobre a apresentação, ela tá sendo gravada e vai ser enviada por e-mail para vocês, tá?

Bom, acredito que a gente tá sem perguntas agora, mas Rocha, você fica à disposição para tirar dúvidas depois, né?

Tá até os contatos aqui. Tem os contatos aí, pessoal. Pode contactar lá, QR Code aqui, redireciona para lá. E aí a gente fala mais sobre o assunto.

Valeu, pessoal. Muito obrigado. Bom dia e bom resto de semana a todos.

‍