O processo de integração da API Open Banking corresponde ao momento de conexão dos sistemas internos e banco de dados das instituições com a solução de open banking. Isso permite que as transações de dados possam ocorrer de forma segura, de acordo com as especificações regulamentadas pelo Banco Central
(BC), que é o órgão regulador do open banking Brasil.
Em síntese, o Open Banking é uma iniciativa global que permite o compartilhamento de dados, mediante consentimento do cliente, com outras instituições. Neste ano, o Banco Central definiu que agora essa iniciativa se chama Open Finance, substituindo o Open Banking. A mudança, que é apenas nominal, facilita o entendimento do público e reforça a ideia de sistema financeiro aberto, justamente porque o Open Finance inclui produtos bancários tradicionais e também serviços financeiros como câmbio, seguros e previdência.
Com isso, a tendência é que o mercado financeiro se torne cada vez mais competitivo, permitindo que os participantes ofereçam melhores serviços e criem novos modelos de negócio.
Com a segunda fase do Open Banking sendo implementada em ciclos, é necessário garantir que esse processo de comunicação entre as instituições receptoras e transmissoras possa ocorrer de forma segura.
Pensando nisso, quais são os principais desafios do desenvolvimento da API open banking? Como fazer a integração da API open banking com os sistemas legados? Como garantir que a sua solução é ágil e escalável? Para conferir essas e outras respostas é só continuar acompanhando o post!
- Integração da API open banking com sistemas legados
- Integração da API open banking: cumprimento de SLA
- Segurança
- Implantação da API open banking
- OPUS TechTalks: Open Banking: APIs e integração ágil a legados
Integração da API Open Banking com sistemas legados
A integração da API Open Banking pode ser realizada de várias formas, isso porque ela depende do sistema de retaguarda e do banco de dados que já é utilizado pela instituição. Antes de apresentarmos alguns modelos de integração, é importante ressaltar que:
– Do ponto de vista das integrações, o open banking funciona como um canal de exposição de dados (claro, mediante consentimento do cliente);
– É necessário converter a visão de um sistema para uma visão padronizada de mundo;
– Uma arquitetura tradicional afeta o desempenho das requisições do open banking;
– Ter que realizar uma mesma tarefa mais de uma vez pode trazer, a longo prazo, impactos negativos para o desempenho e custo-benefício dos seus sistemas internos.
Com isso em mente, abaixo você confere alguns modelos de integração:
Integração da API Open Banking por banco de dados
Esse tipo de integração pode ser realizada independentemente da idade do sistema legado. Isso porque, basicamente o que ocorre é:
– A requisição de informação para a instituição transmissora;
– Confirmação do consentimento e autenticação;
– O processamento do dado no sistema interno;
– Transformação do dado para o formato do open banking
– Retorno da informação para a instituição receptora.
Entretanto, quanto maior a quantidade de dados processados nesse sistema interno da instituição, mais problemas esse modelo pode causar, porque ele acaba aumentando o acoplamento, impactando na escalabilidade, manutenção, no fluxo da operação e até no custo-benefício.
Como já comentamos acima, o Open Banking é apenas um dos canais de exposição de dados, o que eventualmente pode sobrecarregar e afetar a performance do seu sistema.
Integração via API
Esse tipo de integração pode ser utilizado para REST ou SOAP. O que acontece nesse modelo é que os dados requisitados no open banking são acessados e processados por meio de uma orquestração de APIs.
Isso significa que é possível criar uma ordem para essas chamadas, de forma que os dados se comuniquem apenas via API, podendo chamar então a API 1 e 2, apenas uma de cada vez ou somar os resultados de APIs diferentes. Essa orquestração vai depender da configuração dos sistemas legados e de qual a melhor forma de representação desses dados.
Porém, assim como o modelo de integração via banco de dados, nem sempre as integrações via API são capazes de refletir as informações de forma padronizada e ordenada, conforme as necessidades do open banking, o que pode aumentar o tempo total da requisição.
Integração por mensageria de fila
Nesse modelo, a ideia é criar uma fila de requisições, que viram mensagens dentro do sistema interno. Portanto, é como se cada solicitação virasse uma “carta”, o sistema da instituição lê essa carta e prepara o que está no pedido. Em seguida, ele envia uma carta resposta, que é recebida pelo open banking e transmitida ao receptor.
A integração por mensageria de fila possui menos acoplamento do que os outros dois que apresentamos acima. Entretanto, para o open banking existe uma solução ainda melhor: a integração com sistema de barramento de serviços.
Integração da API open banking com sistema de barramento de serviços
Nesse modelo, é como se a instituição colocasse todos os seus sistemas legado em barramento, criando um sistema único que se integra diretamente ao open banking.
Não existe um modelo único para o barramento. Cada instituição/negócio possui a sua forma de organização e para isso vai precisar de um formato de barramento específico.
A maior vantagem desse modelo é a liberdade para trocar sistemas com mais agilidade. Como já comentamos no início desse tópico, sistemas antigos podem impactar negativamente o open banking e adotar o modelo de integração por barramento pode ser uma oportunidade para fazer um upgrade tecnológico.
Isso porque, nos outros modelos será sempre necessário refazer as integrações a cada troca – não só para o open banking, mas para qualquer outra integração que existir dentro da instituição com aquele determinado sistema. Ou seja, essa troca é arriscada, porque existem muitas conexões que precisam ser refeitas.
No barramento, é necessário fazer apenas uma troca de integração, porque todo os outros pontos já estão interligados com o barramento e não com o sistema em si. Até mesmo por isso, o modelo de integração por mensageria de fila acaba não sendo tão eficiente nesse quesito.
Integração da API Open Banking: cumprimento de SLA
O Banco Central é o órgão responsável por definir os SLAs (Service Level Agreement) ou Acordos de Nível de Serviço dos serviços prestados no open banking. Um SLA nada mais é do que o tempo de resposta máximo aceitável para completar uma requisição ou o suporte de uma quantidade mínima de TPS (Transações Por Segundo).
Os tempos de repostas máximos no Open Banking Brasil são 1000, 1500 ou 4000milissegundos dependendo da criticidade da requisição e 300 TPS. Como o tempo começa a ser contado a partir do momento que a requisição foi feita, o tempo de resposta e escalabilidade do seu sistema interno vai impactar diretamente na sua capacidade de cumprir ou não o SLA exigido pelo BC.
Por isso também, o sistema de barramento de serviços pode ser considerado o melhor para a integração da API open banking com os sistemas legados, porque ele entrega um valor de performance mais agressivo do que os outros modelos.
Durante a fase dois do Open Banking, existem duas estratégias que você poderá adotar para ser mais ágil na hora de cumprir os SLAs. São elas: replicação do banco de dados e escalabilidade horizontal ou vertical.
Replicação de banco de dados: quanto maior for o número de requisições que precisam ser checadas no sistema de retaguarda, maior será o tempo do processamento dessa solicitação. Portanto, você pode replicar o seu banco de dados e integrá-lo com o open banking, simplificando o caminho de uma consulta de informação. Esses ambientes intermediários já contém os dados processados, o que então economiza tempo, necessitando apenas da confirmação do consentimento, leitura e envio das informações, considerando que o tempo de um processamento é superior ao de uma leitura.
Escalabilidade horizontal: adicionar mais servidores.
Escalabilidade vertical: adicionar mais recursos ao hardware.
A limitação de capacidade de um sistema legado está relacionada ao quanto um servidor é capaz de processar dados. Portanto, existe também um limite para a escalabilidade, de modo que essas alternativas podem tornar o sistema mais ágil para a fase dois, mas as requisições vão continuar gastando o tempo do processamento.
Na fase 3 do open banking, com o início das movimentações financeiras é pouco provável que essas alternativas consigam sustentar as requisições. Isso porque, uma requisição de pagamento não funciona com uma replicação de banco de dados, por exemplo.
Nesse momento, é possível operar em sistemas de fila, com estrutura similar ao de mensageria, o que não é ideal, mas já é uma estrutura que possui menos acoplamento.
Além disso, é importante ter em mente que as requisições são dinâmicas ou mesmo sazonais. Ou seja, o seu sistema não vai sempre operar no pico, porém o que é necessário garantir é que ele seja capaz de suportar esses momentos.
Essas regras, como já comentamos, são definidas pelo Banco Central e após as fases de implementação elas passarão por um período de amadurecimento e adaptação. Após esse período, é provável que o descumprimento dessas regras se converta em medidas punitivas.
Entretanto, com o mercado financeiro se tornando mais competitivo, aqueles que oferecem os melhores serviços acabarão ganhando mais destaque entre os clientes. Portanto, aprimorar os sistemas legados e escolher um bom método de integração, que permita a escalabilidade, é importante não apenas para cumprir as exigências do BC, mas também para se manter bem-posicionado no mercado e acompanhar as evoluções do ecossistema.
Segurança
Como você já conferiu no nosso post sobre gestão de consentimento, esse tema é crucial quando falamos em segurança no open banking.
Isso porque, é necessário assegurar que o compartilhamento está sendo autorizado pelo titular dos dados e também a segurança interna da chamada.
Uma integração na qual os sistemas confiam plenamente um no outro pode acabar criando aberturas para ataques ou mesmo ações mal-intencionadas. Portanto, esse momento requer atenção redobrada de todos os envolvidos. Mecanismos de autenticação entre o open banking e o sistema de retaguarda podem garantir que somente uma chamada será feita, por exemplo.
Outra forma de garantir um nível maior de segurança é ter plug-ins de integração bem escritos.
Implantação da API Open Banking
Normalmente, um dos maiores desafios do desenvolvimento de uma API aberta, como é o caso da API Open Banking, é justamente que as especificações precisam ser bem definidas, para garantir que as integrações possam acontecer de forma correta.
Entretanto, como no Open Banking Brasil, essas especificações já foram definidas pelo Banco Central, o trabalho que acontece agora é o de entendimento do negócio, para definir como a instituição vai expor os dados financeiros para o mundo.
Isso porque, é necessário assegurar que as instituições receptoras e transmissoras possam se comunicar corretamente, de maneira que o recebimento e o fornecimento de dados seja feito com segurança.
De maneira simplificada, para que uma transação de informação possa acontecer no open banking é necessário:
- Que o banco de dados da instituição esteja integrado à solução de open banking de maneira a expor essas informações de forma padronizada;
- A confirmação de que todos os dados necessários estão nesse banco de dados;
- Que a camada de proteção, seja capaz de realizar transações com segurança;
- Uma gestão de consentimento eficiente, para garantir que é realmente o titular dos dados que está autorizando o compartilhamento;
- Que as regras da LGPD e do consentimento no open banking estejam sendo seguidas.
É importante destacar que, geralmente, os sistemas de banco de dados das instituições não costumam refletir as informações de forma padronizada. Portanto, os esforços dos grupos de trabalho de open banking do Banco Central estão focados nesse tema, para que os dados possam ser expostos de forma a espelhar melhor a realidade.
A API open banking é feita utilizando o padrão RESTful, que é um estilo de arquitetura que precisa atender aos seguintes critérios:
- Interface uniforme (Uniform Interface);
- Stateless;
- Cacheable;
- Uso do modelo cliente-servidor (Client-Server) nas requisições HTTP(S);
- Sistema de responsabilidade em camadas (Layered system).
O Swagger é uma linguagem utilizada para descrever APIs REST, usando JSON, formado por um conjunto de ferramentas de software open source para projetar, construir e usar serviços da Web RESTful.
Além disso, é sempre importante reforçar a necessidade de utilização de um API gateway, que como o próprio nome sugere, funciona como um portão, que controla as solicitações de entrada e faz o repasse para os sistemas responsáveis.
No open banking, como existem vários tipos de solicitações e respostas que podem ser requisitadas, o api gateway permite uma melhor organização, garantindo os mecanismos de segurança corretos e buscando as informações nos lugares adequados.
Depois de realizada a integração com a camada de segurança, chegou a hora de integrar a API open banking com os sistemas legados. Nesse momento, as instituições estão apenas expondo os dados de forma ordenada no ecossistema do open banking.
Portanto, se a sua solução de open banking foi desenvolvida com a utilização da arquitetura de microsserviços, a implantação dela será feita nesse momento da integração com o sistema. Tudo para garantir que a comunicação entre as instituições possa acontecer de forma segura.
Opus TechTalks – Open Banking: APIs e integração ágil a legados
A segunda fase do Open Banking, que vai permitir compartilhamento de informações entre as instituições, já está sendo implementada no Brasil! Para que o compartilhamento de dados aconteça de forma segura a sua solução de open banking precisa se integrar com os seus sistemas internos (legado).
Pensando nisso, Marcelo Feltrin, Head Of Business Development e Alexandre Perugini, convidaram Bruno Samora, Gerente de Produtos na Matera, para falar sobre o tema, compartilhando dicas e boas práticas para que a sua integração da solução de Open Banking seja um sucesso!
Assista agora mesmo:
