Recentemente foi lançado o seguinte site: https://openbankingbrasil.org.br/, que visa trazer algumas informações importantes sobre o Open Banking no Brasil.
Quando comparado a PSD2, e UK, o Open Banking do Brasil tem alguma similaridades, mas ainda algumas ações que podem ser desafios para nosso mercado, e é sobre isto que este post vai falar.
Desafios do Brasil
Diferente da Europa, Austrália, UK, no Brasil nós temos uma grande proliferação de vários players que quando junto, podem representar a figura do "core bancário", ou seja, não é somente um, dois, ou três e sim vários fornecedores para diferentes áreas do banco como: Conta-Corrente, câmbio, investimento, on-boarding/cadastro, crédito, tesouraria etc.
Em nossa experiência já integramos inúmeros players distintos, entre eles:
Sinqia
AltBank
Exchange
Simply
CRK
etc
Cada um destes, e de outros inúmeros outros produtos/soluções, possuem sua forma de integração, alguns deles já possuem APIs, outros, porém, ainda contam com informações em componentes de bancos de dados como Stored Procedures, Views, Triggers, e até mesmo ainda em sistemas legados em plataformas de mainframes.
Levando em consideração a agenda acima da adoção, nós temos alguns Bancos que foram obrigados a entregar a fase 1 na data do dia 01/02/2021, porém, existem ainda vários outros bancos que vão perseguir essa corrida. O mesmo serve para todas as fases. Como nós acreditamos no modelo aberto de informação, este post visa compartilhar um pouco de nossa visão de como é possível implementar do ponto de vista técnico todos os objetivos de negócios em cada fase.
Fase1
Alguns bancos basicamente capturaram views, ou mesmo ETLs, para expor isto como APIs para o mercado, seguindo diversos modelos. Em alguns clientes, usamos mecanismos de eventos com motores de mensageria como RabbitMQ e Kafka para centralizar dados, persistindo os dados em base de dados relacionais, e em alguns casos usando a plataforma MongoDB:
Também existem Softwares de mercado, que oferecem APIs, e desta maneira, existem formas de criarmos serviços compostos, sejam com microserviços, ou até ferramentas que podem levantar serviços no modelo cloud-native.
Em alguns clientes, é interessante já ter esses acessos protegidos por API Gateways, especialmente para implantar políticas que protegem os backends/APIs, especialmente de acessos inesperados, ou até mesmo bots. É parte de nossa recomendação, que mesmo informações públicas, o acesso seja protegido por um API_KEY, e que limite ao número X acesso em N tempo.
Fase 2
Na fase 2, os consumidores poderão compartilhar(consentir) e disponibilizar suas informações entre instituições bancárias.
Para que isto serve? Imagine quando você for tentar abrir uma conta num Banco A, ao invés de ter que informar tudo de novo, a gente poderá simplesmente dizer: Vou conectar com minha conta do Banco B.
Consequência: Maior comodidade para os correntistas, todas as informações de forma mais rápida e eficiente.
Pontos de Atenção: É importante que agora com a LGPD (Lei Geral de Proteção de Dados), as instituições possam atentar que o correntista(dono das informações) deve estar de acordo com esse compartilhamento (consentimento), e que também deve ser capaz de revogar a qualquer momento este consentimento.
Principais Tecnologias Necessárias/Recomendadas
Para esta fase, é importante que a organização tenha em mente alguns conceitos e tecnologias:
a) Provedores de Autenticação OAuth2 : É importante que seu provedor de Autenticação possa estar aderente ao OAuth2, pois como a interoperabilidade será feita por APIs, é importante que as transações (requisições) e informações (scopes, tokens), possam ser protegidas por estas soluções. É extremamente mais fácil lidar com os IdPs, quando estes estão conectados a repositórios federados de identidades.
b) Consentimento : Para atender a LGPD, e também levando em consideração que alguns bancos são filiais de bancos europeus (GDPR), é extremamente importante que o correntista possa ter a capacidade de "consentir", mas também revogar o uso das suas informações, e que a instituição possa manter um "recibo" de que esta ação foi solicitada.
c) Composição de Serviços : Para atender as demandas de agregação de informações, pode ser interessante ter uma solução de busca de informações em diversas fontes, sejam de forma síncrona ou assíncrona. Eis que nesse cenário o uso de processamento com CDC (Change Data Capture) com Kafka, ou mesmo chamada a diversos endpoints, e armazenando num serviço de cache central pode ser uma grande alternativa.
d) Segurança de APIs : De acordo com o Gartner: "Até 2022, as APIs serão os maiores vetores de ataques por Hackers", e como saber se suas soluções estão realmente seguras contra falhas de segurança e com o máximo de prevenção a ataque de hackers. A OWASP criou as Top 10 recomendações para segurança de API, e é muito importante que você atente que segurança não deve ser pensada apenas quando os serviços estão em produção, e que algumas vezes, o primeiro ataque pode ser o útimo. Ter suas APIs protegidas é fundamental.
Vamos abordar a Fase 3 e Fase 4, na parte 2 deste post. Se quiser falar com agente, por favor, não deixe de nos escrever em https://www.skalena.com/contato, temos muito ainda para falar como ajudar na sua jornada de Open Banking.