APIs para Open Banking - Fabio Rosato | Sensedia

Olá pessoal, tudo bem? Bom, primeiramente obrigado por vocês estarem aqui participando de mais essa talk do evento, que está recheado de conteúdo bem bacana. Bom, minha ideia aqui é falar sobre quais são os principais pilares de sucesso quando a gente fala de APIs para o mercado de Open Bank.

Para quem não me conhece, sou o Fábio Rosato, diretor da Sensedia. A Sensedia é uma empresa especializada em APIs. A gente tem uma plataforma, tecnologia de gestão de APIs e com capabilities, com questões específicas para atender todos os aspectos da regulamentação de Open Bank, principalmente no que tange segurança, controle e governança dessas APIs. E a gente tem um braço de consultoria especializado no assunto, que vai desde a estratégia de negócio, como que a gente deriva isso em APIs, no design, na implementação e até depois na operação, depois que as APIs estão prontas.

É uma empresa que está há bastante tempo no mercado, a gente é reconhecida por algumas consultorias mundiais, como o Gartner e o Forrester, que posicionam a Sensedia como visionário e com uma oferta bem relevante comparado a outros players globais. Hoje nós temos mais de 100 clientes que utilizam a Sensedia, então baseado principalmente no Brasil, que é a nossa matriz, mas também com operações e negócios em outros países da América Latina, como Peru e Colômbia e o que na Europa, que inclusive é considerado o berço do Open Bank. Então a gente tem muita lição aprendida dessa operação nossa com o mercado de UK.

A gente também organiza um dos maiores eventos de APIs do mundo, que é o Apix, nesse ano particularmente por conta de todo o problema da pandemia. Esse evento foi remanejado e esse ano ele não vai acontecer, está previsto para o começo do ano que vem. Mas eu já deixo aqui o gancho para vocês irem acompanhando como é que vai estar a agenda do Apix, que é um evento bem bacana, sempre com bastante novidade para todo mundo.

Esse é o posicionamento do Forrester. O Forrester fez uma análise com várias empresas que possuem ofertas de estratégia de APIs e de serviços relacionados a esse assunto. Observando várias empresas globais, muito parecido com o Sensedia, obviamente algumas com tamanhos bem maiores. E a Sensedia foi posicionada como líder. Ou seja, a gente pode dizer que a Sensedia é uma empresa líder quando a gente fala de estratégia de APIs, de serviços relacionados. E dentro desses estudos, a verticalização é um ponto relevante das análises. Especificamente a oferta de OpenBank foi fortemente citada pelo Forrester. E um outro ponto é que eles avaliam também como é a satisfação dos clientes que utilizam o Sensedia ou o serviço de consultoria, a tecnologia. E no geral a taxa de satisfação é bem relevante. Isso foi pontuado nesse relatório. Essa última edição aqui foi no ano passado, em 2019.

Essa é a nossa carteira de clientes. O mercado financeiro, especificamente banco, mercado de pagamentos e seguro, que compõem todo o arcabouço, o arranjo de serviços financeiros. Ele é um arcabouço grande, bastante relevante. Tem desde empresas mais tradicionais até empresas nativas digitais. Onde a gente vem criando soluções inovadoras e pensando em APIs não como algo técnico, mas especificamente como que eu posso gerar valor para o negócio. O grande mindset que a gente tem levado para esse mercado é olhar a API como uma oportunidade de negócio, não como uma interface de programação que muitas vezes a gente vê por aí, que são verdadeiros fios desencapados. Aqui é pensado em uma estratégia, como é que você pode tirar o máximo de valor. E a gente tem umplaybook específico para quando a gente fala de implantação de OpenBank. Desde a estratégia, passa pelo design das APIs, baseado para atender os requisitos das regulamentações, do OpenBank, né? questões de segurança, governança, e depois que você está operando a API, aí você tem um lado bom, cara, tem a API, mas e depois? Como é que eu vou operar? A gente vai falar um pouquinho aqui na frente, quais são as principais questões relacionadas à operação também. Esse é um dos pilares aqui, já antecipando para vocês, né?

Eu dei uma procurada aqui no Google, como é que está a tendência de OpenBank no Google Trends, né? Especificamente aqui, olhando mais globalmente, se é a pesquisa global, você vê que ela vem numa curva ascendente, porque vários países do mundo estão tratando do tema, você tem mais movimento de mídia, de buscas relacionadas ao assunto, então você vê que a tendência que vem crescendo, né? Especificamente o Brasil, você vê um movimento mais forte aqui no ano passado, gerando esse raio-x aqui no finalzinho de 2019, e principalmente agora, nesse momento que a gente está, essa pesquisa é bem recente. Fiz há poucos dias para colocar aqui no slide para vocês.

Tem uma curiosidade, deu uma caída aqui, coincidiu com o momento do distanciamento social, eu imagino, e o pessoal já está com preocupações, outras preocupações, e não especificamente de OpenBank. Mas a gente volta a dar um pico aqui, significa que as coisas estão voltando, e as pessoas estão encaixando novamente a agenda.

Bom, mas entrando especificamente no... Quais são os pilares de sucesso das APIs para OpenBank? O primeiro é que eu considero que a gente fala de estratégia de negócio. Se a gente pegar hoje, praticamente é difícil você encontrar alguém no mercado financeiro que não tenha algum tipo de API, seja para resolver algum problema de integração interno, ou seja para atender um próprio canal interno, um canal mais estrito de uso das funções dos produtos financeiros. É bem comum hoje você se deparar com esse cenário.

Mas a gente acredita que existe um cenário em que você pode ir se tornando cada vez mais aberto. A gente fala de OpenBank, para uma boa parte das pessoas a gente pensa na regulação. Os bancos S1, S2, agora como está no cronograma, eles vão ser obrigados a abrir as APIs. E quem quiser consumir essas informações, essas APIs, vai ter que dar a contrapartida de abrir as suas informações também. Esse é um cenário que você olha apenas pelo aspecto da regulamentação. Você não está olhando como você pode efetivamente usar as APIs e fazer dinheiro, fazer novas receitas, criar um efeito de rede, que quanto mais aberto você está, maior isso é possível.

Então a gente olha aqui, o mercado dos bancos mais tradicionais, geralmente com uma base cliente mais robusta, sólida, entregando segurança, confiança para quem está colocando o dinheiro ali naquele banco. E você tem um cenário em que alguns bancos, principalmente os digitais, eles já nascem muito baseados em APIs, seja para atender seus próprios canais digitais, seja lá sua própria app mobile para poder adquirir um cartão de crédito e fazer as transações.

Ou cenários em que alguns bancos já criam um conceito de marketplace, ou seja, ele comercializa o próprio produto dele, mas ele também comercializa o produto de uma outra instituição financeira, que eventualmente não é o core business dele, mas ele aproveita o canal digital dele, os clientes da base dele, para poder fazer esse movimento. Aí tem um modelo de negócio de compartilhamento de receita, depende muito de como está estruturado esse marketplace. Esse é um cenário que as APIs fazem total sentido também. Como é que você conecta para fazer uma transação do produto ou para buscaruma informação? As APIs entram ali no jogo. E se você quer crescer de forma bem significativa o marketplace, essas APIs precisam ser simples, têm que ir para uma estrutura de capacidade de plugar fácil para que você consiga movimentar rapidamente novos negócios com os novos parceiros. Então você tem um caminho de maturidade que é bem interessante, quando a gente fala de bancos que expõem funções, seus produtos como APIs, para que fintechs ou empresas do varejo que estão em uma jornada específica ali numa app ou no canal digital, possa oferecer aquele produto naquele momento daquela jornada para tornar conveniente o usuário daquela aplicação.

Então a gente vai falar um pouco de um case ali para frente, onde tem uma oferta de câmbio que quem tem uma fintech ou quem tem um aplicativo e quer colocar aquele produto de câmbio naquele momento, ele pode acessar essa função, esse core bancário, sem destoar demais a experiência do usuário, o X, etc. Isso a gente chama de bank as a service. Você tem um conceito de open platform, que é quando você realmente abre suas APIs, permite que experimentações sejam feitas ali, novos negócios sejam criados, num cenário muito mais aberto. A gente tem alguns cases nesse sentido também.

Então você sai de um cenário de bastante robustez, confiança, os próprios canais digitais, e você vai para um cenário onde você tem vários parceiros, então você deixa de ser B2C, passa a ser B2B, ou B2B2C, onde você cria um efeito de rede, de conexões. Obviamente, isso traz um grande desafio de modelo de negócio.

Então o principal ponto aqui é que a jornada de APIs não começa pelas questões técnicas, ela começa muitas vezes pelo desenho de negócio, e como que você deriva depois em APIs, é um caminho que é mais fácil de você trilhar, o mais difícil realmente é você estabelecer esse modelo de negócio, que muitas vezes está por trás da regulamentação.

Esse é um exemplo de um mapa de modelo de negócio dentro do cenário de open platform, onde você permite conexões e você tem uma troca de valores ali, seja financeiro ou seja de algum tipo de produto, no caso o Facebook. Ele é uma empresa que fornece mídia, mas ela não cria nenhum conteúdo. Então o usuário é o consumidor desse conteúdo, mas tem quem publica, tem gente que quer publicar lá, aproveitar a timeline para poder exibir sua marca, e tem os desenvolvedores que criam aplicações em cima da plataforma do Facebook para que os usuários tenham novas experiências ali dentro daquela plataforma.

Ou seja, a ideia do Facebook é atrair todo mundo para dentro dela, e dentro de um cenário de facilidade, obviamente com o modelo de negócio desenhado. O que eu ganho por publicar um conteúdo ali? Eu tenho que pagar para colocar um ad, mas na verdade eu vou ter um benefício da audiência. O usuário tem o benefício de consumo do conteúdo. Os desenvolvedores eventualmente podem fazer dinheiro por estar construindo essa aplicação plugada no Facebook. Obviamente isso aqui é um exemplo de uma Big Tech, mas pensa que no lugar do Facebook poderia ser uma instituição financeira, um banco. E aí esse modelo de negócio, esse mapa, ele tem que ser considerado um dos primeiros pontos de partida.

Isso aqui é só um exemplo de um framework que você pode utilizar para poder fazer esse desenho de modelo de negócio. Existem outros, mas esse é um bom ponto de partida de quando a gente fala de estratégia de open banking, além da regulamentação.

E aí você tem dentro do conceito de APIs, você tem alguns modelos de negócio que podem ser aplicados. Aqui tem alguns exemplos:

API que é efetivamente grátis, ou seja, você está oferecendo aquela transação, aquele dado, sem eventualmente ganhar nada diretamente por isso.

Modelos de negócio que pensam nisso, mas obviamente por trás ela está diretamente pensandoem como monetizar.

Modelos de negócio que você paga pelo uso, ou seja, por cada transação ou por um pacote de transações você tem uma certa bilhetagem. Se você está consumindo um produto, pensando num produto financeiro, você pode ter uma parte, uma comissão pelo consumo daquele produto, pela compra daquele produto financeiro, o que a gente chama de revenue share. Você tem um conjunto de possibilidades de modelo de negócio que são aplicadas em cima de APIs que são produtos que você pode lançar a mão dentro do cenário de Open Banking.

Isso aqui é um exemplo de como as plataformas digitais, pensando que um banco pode se tornar uma plataforma digital, qual é o poder de capitalização. Comparando qual é o tempo de vida das empresas aqui, as empresas mais tradicionais e as empresas digitais, o número de funcionários que essas empresas têm e o valor de mercado que elas possuem. Quando você vê essas empresas digitais que têm um ganho de escala enorme, elas criam um efeito de rede onde todo mundo está se beneficiando daquela plataforma, você tende a ter um modelo de negócio super escalável e com um valor de mercado absurdamente maior comparado a empresas tradicionais que não se posicionam como efetivamente uma plataforma. E aqui estamos na era das Big Techs.

Então quando você olha as 10 principais empresas em termos de valor de mercado, você vê o quanto as empresas de tecnologia dominam e o que tem de comum em todas elas é o efeito de rede, o efeito de plataforma. Eles criam capacidade de conexão, eles geram valor pelo dado, pelo volume de transações, pessoas criando conteúdo, criando aplicações em cima dessas plataformas ou vendendo produtos como é o caso da Amazon. Mas a metade do que é vendido na Amazon não é especificamente da Amazon, são de outros vendors que colocam os produtos no marketplace. Tudo isso é possível por conta do efeito de rede onde as APIs estão ali disponíveis para poder facilitar essas conexões de novos entrantes, novos participantes plugados e transacionando, fazendo novos negócios.

Então a gente tem um case aqui bem legal que é do Banco Toppaz, que inclusive é contado muito para o amigo Klein, que está aí nas rodinhas de Open Bank também. E o Banco Toppaz se posicionou como Banking as a Service. Então é um case bastante interessante dentro de um modelo de maturidade de Open Platform muito grande, onde ele segue aquele cenário que eu falei para vocês anteriormente. Você consegue dentro da sua app uma jornada de viagem, por exemplo, se você tem uma fintech de um aplicativo de viagem, você poderia incorporar ali um produto financeiro do Banco Toppaz sem destoar demais a experiência de UX e de uso do aplicativo. Então a gente tem as APIs inclusive, elas são utilizadas internamente para poder alavancar novos produtos. A partir do momento que você tem um arcabouço de APIs, sejam elas internas ou mais restritas, você ganha muita agilidade para criar. Então você tem os benefícios que o Banco Toppaz ganhou. E efetivamente, os números aqui de negócio dizem por si só. Saímos de um volume de contratos mensais bastante insignificante de um cenário super escalável, 120 para 65 mil novos contratos dentro desse conceito de Banking as a Service. É um cenário espetacular.

Um outro case que se posiciona bastante dentro desse cenário de plataformas mais abertas, baseado em APIs, é o Cielo QR Code. Você tem a capacidade de pagar nas maquininhas da Cielo usando alguns desses aplicativos que estão aqui embaixo. E esse volume de aplicativos de wallets tem crescido dia a dia, porquea API é simples, é fácil de plugar. Ela foi feita para que o onboard fosse muito facilitado desses novos parceiros. Então, qualquer uma dessas wallets, eu tenho o aplicativo do Banco Bradesco, eu consigo fazer um pagamento no meu cartão de crédito, débito, usando a leitura de QR Code do meu aplicativo do banco, que está linkado ao meu cartão de crédito. Então, eu elimino o cartão de crédito. Já está numa linha de eliminar o plástico, seguir a linha de tendência de pagamento sem contato que a gente vê absurdamente acontecendo na China. E esse produto permite várias jornadas que agora, no momento da pandemia, a gente tem visto muito, como os QR Codes nas lives das TVs. Isso tudo é a tendência e, na verdade, nesse momento agora, ele está fazendo esse tipo de produto alavancar cada vez mais, mudando o comportamento do consumidor.

Bom, o segundo pilar de sucesso que a gente considera é a governança. Ou seja, como é que você garante que, dado que você tem o desenho de uma linha de negócio, sabe quais são as APIs que você vai construir, como é que você, de fato, constrói essas APIs, quais são os padrões tecnológicos que você vai utilizar. Esses padrões estão aderentes à regulamentação, não estão? Se não estão, quais são os gaps que existem e como você adequa para que todo mundo que está dentro desse ciclo de construção das APIs até efetivamente a publicação estejam aderentes a esses requisitos. Então, a governança de APIs, de Open Bank, é um subset de outras governanças que existem dentro das empresas, especificamente do mercado financeiro. As governanças têm de ser bastante intensas, até por conta de ser um mercado muito regulamentado. Então, ele é um subset onde você tem que, obviamente, atender quais são os requisitos regulamentares que existem, dar esses padrões para quem está construindo essas APIs e depois operando elas ali na frente.

Então, as recomendações que a gente traz para quando a gente fala de governança é sempre tratar a API como um produto, porque ela vai evoluir. A partir do momento que você lança uma versão 1, melhorias vão ser necessárias, alguns problemas serão encontrados e você vai precisar corrigir. Como é que você garante que esse fluxo, desde a ideia até a colocada em produção, está bem estruturado, bem correto e as pessoas estão seguindo as normas e colocando isso com a segurança necessária, com todos os atendimentos e requisitos, logando as informações que precisam ser logadas, com todas as trilhas de auditoria que são necessárias quando a gente fala desse tipo de governança. Então, esse arcabouço bem definido. Dentro dessa estrutura, nascem alguns papéis. E o principal deles é o que é o gestor, o dono das APIs, quem é responsável por entender do negócio, comunicar isso para as equipes técnicas para que efetivamente ela seja colocada de fato no ar dentro do modelo de negócio que foi estabelecido. Então, esse é um dos novos papéis que nascem.

E o papel do API Product Manager é principalmente gerenciar o backlog de APIs. Ou seja, quais são as APIs que estão no meu roadmap, o quão prontas elas estão em relação ao que eu tenho no meu backend de sistemas. Se o meu backend não está preparado, eventualmente o meu esforço para publicar essa API é maior. Quais são os drivers estratégicos da minha companhia? Ou seja, o que eu estou procurando? Gerar nova receita, criar novos produtos, otimizar processos. Se eu tenho isso bem mapeado, eu consigo criar um mapa de priorização. Ou seja, as APIs que são mais fáceis de expor dentro do cenário que ela vai gerar mais valor para o negócio, provavelmente elas têm que ser as primeiras a serem implementadas. Ou seja, o esforço é baixo, mas eu vou conseguir fazer mais dinheiro com ela. Então, a função desse novo papel é justamente colocar isso de forma ordenada,com os pesos adequados dentro da estratégia da companhia que é específica para cada um. A primeira coisa que tem que fazer é mapear quais são os drivers de valor estratégico que a companhia tem e fazer esse mapeamento das oportunidades de APIs que estão surgindo no backlog.

E dentro de companhias muito grandes, a gente fala de governança, a gente tem um risco grande de centralizar demais as decisões. Ou seja, tudo que envolve APIs tem que passar por um comitê, por um centro de excelência, que vai determinar quais são as regras, se estão seguindo as regras, se não está. Isso tudo dentro de um cenário em que você quer se posicionar como plataforma, ter diversas APIs que não sejam só as APIs para atender a regulamentação, que é a exposição dos dados, transações, que é ter mais coisas ali. Ou seja, realmente a API vai ser o seu produto, você vai ser realmente uma plataforma aberta. Decentralizar é a melhor estratégia. Então você pode até nascer centralizado com uma governança mais bem estabelecida para garantir que as primeiras coisas estão saindo ok, mas você já tem que pensar imediatamente como é que você descentraliza isso.

Então algumas políticas precisam ser mudadas dentro da governança, dentro do processo de ideação até design e publicação das APIs. E você com ferramentas, com processos, isso é bem factível de você conseguir. E aí você acaba ganhando escala e obviamente time to market é o mais importante quando você está num momento de grandes mudanças como a gente está agora.

Então se a gente for falar de governanças, principais responsabilidades, a gente definir quais são as regras do jogo, quando a gente fala de APIs, quando a gente fala de Open Banking, olhando para a regulamentação. O Banco Central já definiu parte das regras do jogo, algumas ainda estão para serem definidas, mas tem as suas.

Quais são os critérios de segurança? Quais são os requisitos de segurança que você vai colocar na sua API para atender não só a regulamentação, mas efetivamente para garantir que você está expondo o dado com segurança e atendendo o compliance? Essas APIs estão com condições de performar? Quais são os limites que você precisa estabelecer de consumo para ela? Se você tiver um volume grande de acesso, um pico, como é que você lida com isso? Você está preparado? Quais são as regras do jogo? Se você precisar reusar essa API em outros canais, para outros dispositivos, essa API está preparada para isso? Quais são os critérios?

Então é um conjunto de responsabilidades que dentro do pilar de governança tem que ser desenhado e estabelecido. Então você vai desde uma governança que tem mais comando e controle, até aquelas que você vai dando mais agilidade para determinados times ou BUs, dando mais autonomia para que esse ciclo não se torne moroso, a governança não seja um gargalo ali na frente. Então você consegue estabelecer isso e para cada companhia de um jeito, na verdade. Não tem uma regra que seja única, não serve para todas.

E esse ciclo, a governança é responsável por garantir que exista o ciclo de aprendizado e evolução. Então você definiu um padrão, mesmo que seja centralizado, esse padrão está atendendo, ele precisa ser evoluído, esse processo precisa de ajustes. Se eu estou num processo distribuído, onde tem vários times trabalhando ao mesmo tempo, com determinada autonomia, esse ciclo de aprendizado faz mais sentido ainda.

Todo mundo está sabendo quais são os requisitos de segurança que têm que ser aplicados nas APIs, como é que eu faço para garantir que efetivamente a API está sendo publicada com os requisitos de segurança. Essas APIs estão sendo monitoradas, existe um painel de controle mapeando eventuais problemas. Tudo isso tem que estar dentro de um ciclo de aprendizado e evolução contínua.

E o terceiro pilar aqui importante, quando a gente fala de APIs para o Open Banking, é segurança. A primeira coisa que todo mundo fala é expor o dado, umaAPI, quais são os riscos, quais são os problemas. A notícia boa é que hoje as APIs são tão seguras quanto você acessar o seu banco. Seguras enquanto você acessar o seu banco ali por uma app, né? Se bem desenhada, se você tiver o cuidado de colocar os requisitos de segurança e aplicar com as tecnologias existentes, elas são totalmente seguras, né? A gente tem, vez ou outra, algumas notícias de que o problema de segurança é bem comum, né? Esse é um exemplo do ano passado, no Hackathon, que alguns times tinham que fazer tentativas de invasão em alguns produtos, e o carro da Tesla era um deles, estava participando do Hackathon, e o pessoal conseguiu, o time lá, ele conseguiu, do computador, alterar, colocar mensagens na tela do Tesla. Eles invadiram ali, conseguiram fazer essa alteração. Então, isso é bem comum de acontecer.

Então, quando você está falando de segurança, você tem alguns tipos de ataque que você tem que se defender. Isso é específico de quem está exposto na internet, não são pessoas tão específicas de APIs. Os tipos de ataque incluem:

Negação de serviço.

Alguém tentar roubar sua identidade.

Algum código malicioso ali tentando obter algum dado do seu back-end, injetando para ver se consegue fazer um retorno de dado diferente.

Mas para todos esses itens, você já tem um conjunto de features de segurança que garante que você está com o seu canal seguro, que você está com a autenticação, se quem está acessando é quem deveria, se ele está autorizado a acessar aquele dado. Se alguém interceptar sua mensagem, aquela mensagem está efetivamente criptografada, ou seja, ele não vai conseguir obter aquele conteúdo ali de forma fácil.

Para quem quiser saber um pouco mais detalhes técnicos, mais para o pessoal de tecnologia, tem um QR Code aqui, você pode ler, tem um webinar no YouTube, na verdade é uma apresentação do Apix do ano passado, falando sobre questões de segurança com mais profundidade. Isso é mais para quem está olhando para o aspecto técnico da segurança.

O quarto pilar nosso de sucesso para as APIs de OpenBank é a operação. Se você passou pela parte de negócio, estabeleceu a governança, desenhou as APIs, implementou, publicou elas com todos os requisitos de segurança, a boa notícia é que você tem uma API. Tem uma notícia que agora ela está operando, ela precisa estar escalável, com disponibilidade, eventualmente ela pode estar tendo erro, quem está olhando para esses erros, como é que isso está funcionando.

E muitas vezes você está exposto só aos tsunamis digitais, quando você está vendo agora as lives a todo momento no YouTube, as lives sertanejo, para quem publica um produto digital ali nessas lives que chegam a ter milhões de pessoas no mesmo tempo, você pode ter picos de acesso na API e ela precisa estar preparada para poder responder a esses picos. Precisa estar robusto o suficiente para poder escalar e garantir que você não está perdendo aquela oportunidade, aquele momento daquela campanha.

Então o pessoal fala muito do momento da Black Friday, que é para o pessoal de varejo. Hoje em dia com o avanço dos canais digitais, muito mais agora do que antes, basicamente quase todo dia ou toda semana é uma Black Friday. Você está a todo momento suscetível a picos, conforme você lança campanhas e o pessoal mais suscetível a consumir produtos digitais e consumir produtos e etc, sem sair de casa.

Então você tem um conjunto de informações que precisam ser coletadas e que dê suporte para essa operação. Então se a API está no ar, você tem alguém que dá suporte para essas APIs, qual é o tempo médio de resolução dos problemas, quem está, se o desenvolvedor lá da ponta está te acionando, qual é a média de satisfação que esse cara tem com o seu atendimento. Você tem que efetivamentetratar a API como se fosse um produto digital e dar todos os insumos e coletar todas as informações para que você tome ações estratégicas e otimize ao máximo essa operação no dia a dia. E qual é a quantidade de chamadas com sucesso? Qual é a taxa de erros que existem nas APIs? Esses erros estão mais do lado dos sistemas, onde quem está consumindo, se quem está consumindo está consumindo com muito erros, poder contactar esse parceiro, alguém que está plugado nessa API e transacionando com você e dizer, olha, você está consumindo API com um problema aqui. Se o Banco Central pediu a auditoria dessas informações, desses logs, ter condições de entregar isso de forma bastante facilitada. Esse é um exemplo desse tipo de relatório.

Quando você olha para o UK, existe um diretório de API de open banking dos bancos que estão, de alguns bancos que estão expondo as APIs, atendendo a regulamentação de UK. Aqui embaixo tem o link que vocês podem acessar, esse tipo de gráfico aqui. Esse aqui ele mostra qual é a disponibilidade média das APIs dos bancos que estão expondo as APIs de open banking lá em UK. Você vê que há uma certa variação aqui, essa é obviamente uma média. E você consegue ver também outras métricas, como qual é a quantidade de chamadas de sucesso que obteve nas APIs de open banking lá em UK. Você vê que é uma crescente aqui bem forte. Abril foi o único mês que na verdade ele não cresceu, ele caiu. Isso pode ser um reflexo da pandemia, o pessoal mais contido em relação aos negócios como um todo. Mas você vê uma crescente, isso é bem legal.

E você consegue ter uma visão de chamadas de APIs, por exemplo, por bancos. Quem são os bancos que mais estão respondendo com sucesso? Não em termos de taxa, mas em termos de quantidade e volume absoluto. Esse gráfico consegue mostrar efetivamente isso. Então você consegue ver quem está provendo mais informação no open banking. Prometiu os outros que não estão consumindo. Ou não deve estar consumindo, ou ninguém está consumindo, deve ter uma base pequena de clientes. Então esse aqui é um gráfico bem interessante. E você consegue ver também as falhas. E aqui na verdade o grande ponto é a exposição da marca. O quanto você está exposto na maior parte das vezes a API não está disponível. Ou você está chamando e ela está com algum erro de negócio ou com alguma falha técnica. Isso tende, conforme o ecossistema vai ganhando maturidade, isso tende a prejudicar bastante a marca da instituição financeira que não está atendendo os requisitos de disponibilidade e de resposta adequada, sem problemas, sem erros.

Você consegue fazer um olhar especificamente em determinado banco. Eu quero ver como é que estão as métricas aqui desse banco especificamente que está publicado nesse diretório. Então você consegue olhar inclusive por produtos financeiros, por categorias de informação. Desde a conta, o extrato, quais os produtos. Você consegue fazer essa segmentação. Então por trás a gente vai falar um pouco mais para frente, você precisa ter produtos, tecnologia, que suporte você controlar e ter esses números de forma bastante facilitada. Não precisa ser uma rocket science para você extrair esse número e poder publicar ou até mesmo fornecer para o Banco Central, quando ele necessitar desse tipo de informação para a auditoria. Para ver se você está atendendo.

E o quinto ponto como pilar de sucesso que a gente chama de developer experience. Como eu falei lá para a operação. O lado bom é que você tem APIs. O outro é que você tem que operar, garantir que ela está disponível, garantir que ela está respondendo com sucesso, sem taxas de erro. Mas na prática, parceiros ou outros bancos vão querer se plugar nessa API. Se você está olhando para o aspecto da regulamentação apenas, developer experience talvez não seja a principal preocupação sua. Mas se você está com uma estratégia, um modelo de negócio, pensando como é que você está distraindo valor de fato de outras APIs que compõem o seuarcabouço de open banking, seu posicionamento como bank as a service, marketplace ou open platform, esse pilar é super importante. Você tem que simplificar ao máximo a vida do desenvolvedor. Documentação super atualizada. Como é que você faz para se registrar, ganhar uma chave, um token num ambiente de sandbox? Você poder brincar com as APIs, fazer as suas implementações. Depois, como é que você ganha uma chave de produção? Se você tiver alguma dúvida ali de como consumir API dentro dos produtos financeiros, a maior parte das aplicações de negócios, as APIs estão bem desenhadas, tecnicamente está ok, mas o modelo de negócio do produto ali é mais complicado. Você tem um canal de acesso? Com quem você fala? Como que você fala? É por telefone, por WhatsApp, por Slack ou por um chatzinho no próprio portal? Tudo isso tem que ser endereçado dentro do pilar de Developer Experience.

Então, ele vai desde o processo de onboard do desenvolvedor, criar o registro no portal de desenvolvedores, ganhar uma chave de acesso. Você poder fazer, testar ali o consumo da API sem ser billetado, num ambiente que seja de testes. Depois, efetivamente, você ganhar uma chave de produção. Pode ou não passar por um processo de homologação, isso depende muito de como está desenhado esse processo de Developer Experience. Você conseguir saber quais as chamadas que você fez, se o desenvolvedor está consumindo a API de um banco, você saber quais chamadas você fez, se elas foram com sucesso, com erro, quais são os logs dela. E se o banco está publicando novas versões, alterações, como é que é esse processo de comunicação? Como é que é essa governança? Você lança uma versão nova de APIs, se tem um conjunto de parceiros, outros bancos plugados nessa API, você não pode quebrar essa conexão. Essa governança tem que ser bem pensada. Você mantém duas versões no ar, comunica que tem uma versão nova e pede para o pessoal migrar, faz um esforço de processo de migração, se for necessário. Isso faz parte desse processo de comunicação e interação com o desenvolvedor que está consumindo a API.

Então, o Developer Experience está muito na linha do consumo da API. Quem está de fato lá do outro lado consumindo, seja uma fintech, um outro banco, um parceiro ou seus próprios canais digitais com diversos times internos, cada um responsável por uma jornada. E o ponto em comum dessa experiência são os portais desenvolvedores. Então, são alguns exemplos aqui de portais que são de clientes da Sensedia, como a Cielo e a Elo. A gente tem diversos outros no mercado financeiro. Mas se vocês entrarem lá, você vai ver documentação super bem detalhada. Você conseguir ver os detalhes técnicos das APIs, poder entrar num ambiente sandbox e fazer alguns tipos de chamadas e brincar ali para depois, de fato, você entrar em produção e se tem uma habilitagem aí o jogo começa a valer.

Bom, o sexto pilar são as métricas. Então, depois que você estabeleceu tudo, o que você pode usar para ver se a sua estratégia está sendo uma estratégia de sucesso? Aqui você tem alguns exemplos de métricas que você pode utilizar, categorizada por:

Métricas de negócio

Métricas de experiência do desenvolvedor

Métricas mais operacionais

Algumas eu mostrei no pilar de operação. Especificamente as métricas de negócio são interessantes. Se você está olhando para o modelo de API, de Open Platform, como modelo de negócio efetivamente. Então, você pode falar, cara, quanto está vindo de receita através desse canal aqui de API? Essa pode ser uma métrica. Se tem um produto que você paga mensalmente por ele, utilizando esse canal de APIs, qual é a receita recorrente mensal? A gente chama de MRR. Você pode montar estratégias para crescer esse número, esse indicador. E aí passa por você ter retenção, aquisição de novos consumidores daquele produto, daquela API. Você reter quem está consumindo para você não perder. Criar produtos adjacentes ali para que quem compra passe a pagar mais por ele. Essa é uma número bastante interessante, bem típico de empresas modelo SaaS. Você pode fazer uma métrica que é número de parceiros. Se no primeiro momentoeu não estou interessado em receita, eu estou interessado em ter um conjunto de parceiros grandes para poder montar o meu ecossistema. Um conjunto de parceiros grandes para poder montar o meu ecossistema, eventualmente se eu lanço um produto novo, qual é a receita que esse produto está me gerando, se a receita está nova. São alguns exemplos de métricas do segmento de negócio. Você pode estabelecer outras, e aí se baseando em outras métricas de outros tipos de negócio, que eventualmente caiba nesse tipo de modelo de open banking, de open platform.

Aqui tem algumas outras, especificamente de developer experience, você pode mapear, montar um funil do onboard do desenvolvedor:

Quanto tempo ele demora para se registrar no portal.

Criar uma chave.

Testar a API e depois entrar em produção.

Você mapeando esses lead times, você consegue identificar onde estão os gargalos e melhorar o processo para que aquela etapa lá se encurte. Quanto mais rápido ele fizer o onboard, se a sua API está atrelada ao modelo de negócio, mais rápido você vai conseguir gerar valor e fazer a coisa girar.

Aqui são, novamente, lá do repositório de open banking UK, você consegue ter essa visão de painéis, elas são métricas mais operacionais aqui, mais como as outras, onde você vê o indicador de disponibilidade média das APIs que estão publicadas lá no diretório com os bancos que têm as APIs de open banking:

Qual é o tempo de resposta médio em milissegundos.

Você vê aqui o tempo de resposta médio muito bom.

Qual é a porcentagem de chamados que são com sucesso.

O volume total de chamados, são números bem interessantes de você olhar.

Obviamente lá no repositório você tem vários bancos, todos eles publicando suas APIs e mandando essas informações. Mas isso faz sentido para você que está expondo. Então, qual é o seu tempo médio de disponibilidade, tempo médio de resposta, quantidade de chamadas. Então, tudo isso se você não tem uma estrutura de tecnologia para suportar e de governança, você acaba se tornando muito difícil de você extrair e exibir.

E quando você passa a fazer esse acompanhamento, extrair essas métricas, você vai perceber que elas também te fornecem informações de negócio. Como eu falei, se você lançou uma campanha na live de um produto financeiro, um QR code, você consegue ver pelo comportamento dos chamados APIs, se aquela campanha está tendo sucesso, se está, quais são os problemas operacionais que estão tendo e se isso efetivamente está surtindo efeito. Você tem o efeito colateral de poder extrair comportamento de negócio no momento que você começa a coletar isso e com as tecnologias corretas.

Bom, sobre cores de tecnologia, tem bastante coisa envolvida no detalhe. Eu não vou entrar muito nos aspectos técnicos, mas eu queria dizer os pontos principais. A gente está saindo de um cenário de baixa complexidade, um cenário para o mercado financeiro de multi-experiência, ou seja, tem muita coisa que está, muitos canais no qual eu posso consumir um produto financeiro ou fazer uma transação ou um serviço financeiro. Eu saí de um canal único para múltiplos canais e chego aqui para canais que eventualmente a gente nem saiba mais quais são. Eu posso usar o meu Google Home, a minha Alexa para perguntar qual é o saldo da minha conta corrente ou até mesmo usar um aplicativo tradicional.

O grande ponto é que as APIs podem ser o canal único de comunicação com todos esses canais que estão relacionados com os clientes que estão ali na ponta fazendo o consumo desse produto financeiro, seja diretamente ou seja em uma jornada totalmente distinta. Quando a gente compra alguma coisa, a gente usa um Uber, um iFood, você está consumindo um produto financeiro, uma transação ali para poder fazer o pagamento. Se você está comprando uma, fazendo um roteiro de viagem no TripAdvisor, você tem a opção de, ou deveria ter, a opção de comprar um seguro viagem ali na ponta e resolver todo o seu problema ali do seu roteiro de viagem, que é o que nesse momento a gente está proibido de fazer. Se liberar, muita gente que gosta de viajar, acho que vai ser a primeira coisa que vaifazer ali na frente. E o que mais? As próprias APIs que os seus canais estão consumindo, eles têm potencial e devem ser as mesmas APIs publicadas para parceiro, não tem por que ser diferente. Você tem que ter capacidade de tecnologia para poder lidar com um parceiro e com diferentes canais consumindo a mesma API, isso é totalmente possível e factível de uma forma bem simples. Você aumenta a complexidade, múltiplos canais, vários parceiros e as APIs são o ponto central de conexão.

A Sensedia, como eu falei, ela tem uma plataforma de tecnologia de gestão de APIs com questões específicas para OpenBank, template para atender a regulamentação, questões já pré-definidas de segurança, tanto para o canal da chamada API quanto para a autenticação, autorização e também segurança na mensagem, causando intercepto no meio do caminho e conexão com os backends. A gente sabe que os produtos já estão criados, na maior parte das vezes, nos bancos, a não ser que seja um banco novo que esteja criado. Como é que você conecta em uma base de dados, em um determinado sistema, em uma EFN e expõe isso de uma forma de APIs para o mundo novo, seja para atender a regulamentação, seja para você efetivamente fazer negócio. Novamente, a tecnologia vem para facilitar.

Então, quando você olha assim, tem bastante preocupações relacionadas à exposição de APIs ou para o platform, a tecnologia tem que ser usada efetivamente para você ganhar tempo, agilidade, confiabilidade, segurança. Você vai fazer isso da melhor forma possível ali na ponta e continuar garantindo a marca, a segurança que as instituições financeiras devem ter ali na ponta.

E aí, aqui é só tipo de exemplos. É muito fácil você criar uma API tecnicamente. Isso é muito simples, porque a tecnologia que a gente tem hoje é bastante trivial. Todo o processo de governança estabelecido, quais são os modelos de segurança que vão ser utilizados, os componentes, a rastreabilidade de auditoria que vai ter. Dependendo da tecnologia que você tem e dependendo do desenvolvedor que está fazendo isso, ele pode ou não usar isso para publicar uma API. E aí, por processo, você consegue barrar. Essa API não está atendendo por testes, por qualidade, por penteste. Você consegue dizer, cara, essa API não está atendendo e não vai ser publicada. Mas as ferramentas vêm para facilitar, inclusive, isso.

Aqui tem um exemplo de completude, do quanto que a API está preparada para ser publicada. Você consegue com esse tipo de ferramenta dizer, olha, toda API que for publicada aqui no banco precisa atender requisitos de segurança de canal, autenticação, autorização e criptografia na mensagem. E além de log, auditoria e etc. E ofuscar dados que não deveriam, porque não está autorizado, não tem um consentimento de acesso dado pelo cliente daquela informação. Esse tipo de requisito você pode configurar em uma ferramenta de governança como essa e ela vai dizer, olha, essa API está atendendo tais e tais requisitos que você determinou aqui para a publicação dessa API. Se tiver 100% ok, você publica. Se não tiver, ele vai te informar, cara, está faltando ainda algumas peças e você não vai poder publicar, porque é um processo de governança que estabelecido ele não consegue avançar.

Inclusive, a rastreabilidade. Quem chamou a API, quando chamou, qual foi a função da API que foi chamada, qual informação que foi pedida e qual foi o sistema interno do banco que respondeu essa informação. Você conseguir ter essa rastreabilidade, tanto para você fazer análise de impacto, como para até mesmo ter logs de informações de auditoria para garantir que você está atendendo o compliance do tipo de regulamentação de Open Bank que é bastante importante. Aqui é um exemplo de visão de logs de auditoria, inclusive de quem alterou a API e quem não alterou.

Bom, então para resumir, esses são os sete pilares de sucesso que eu gostaria de compartilhar com vocês. Então, desde a parte de estratégia de APIs que não seja só atender a regulamentação de Open Bank, que a gente olhe como oportunidade de negócio, que é a primeira dica aqui. Passando por governança,segurança, depois que você publicou a API, você tem um problema bom, que é operar essa API no dia a dia. Como é que você faz? Depois de ser publicado, aí você tem um problema bom, que é operar essa API no dia a dia. Como é que você faz para garantir o melhor onboard de parceiros e ouvidores que vão consumir essas APIs? Quais são as métricas que você pode acompanhar e as principais tecnologias aqui centrais para poder suportar a estratégia?

Bom, para quem quiser mais detalhes, tanto técnico quanto de negócio, eu recomendo fortemente entrar no blog da Sensedia, nesse endereço, ou você pode ler o QR Code aqui que está disponível. E aí eu estou super à disposição para tirar dúvidas, tanto agora durante o evento aqui, como depois também tem logo na sequência o meu e-mail. Vocês podem entrar em contato ou pelo contato do site da Sensedia também. Estamos super à disposição para compartilhar mais experiências que a gente tem do cenário financeiro, cenário de Open Bank, Bank as a Service, Marketplace, que é um cenário bem robusto que a gente vem construindo já há bastante tempo aqui na Sensedia.

Bom, eu agradeço fortemente a presença de todo mundo e fico à disposição para qualquer dúvida, qualquer problema que vocês queiram tratar. Tá bom? Valeu, pessoal.

‍