Pisp: quais as vantagens e como se tornar uma iniciadora de pagamentos no Brasil

Bom, deixa eu me apresentar aqui para a gente começar. Eu sou o Rafael Esquerdo, sou gerente de produto aqui na Sensedia. Venho trabalhando nessa frente de Open Finance junto com o nosso time aqui desde 2019. Trabalho junto com o Rodolfo, nosso arquiteto.

Fala aí, Rodolfo, você vai se apresentar.

Bom dia mais uma vez. Sou o Rodolfo Cruz, bem atuando aqui na Sensedia como arquiteto nas frentes de Open, principalmente nessa frente de Open Finance, virado para Open Bank, desde o início, construindo umas coisas legais aqui, estudando e acompanhando essa evolução do mercado financeiro do Brasil.

A ideia hoje aqui é a gente fazer um papo aqui, trazer algumas perspectivas que a gente vem tendo ao longo desse tempo de implementação. Então, falar um pouquinho de como está o cenário hoje do mercado PIX, como que as iniciadoras de pagamento aqui no Brasil estão surfando essa onda do Open Finance. Trazer um pouquinho do cenário, alguns números para a gente se localizar ali, se situar no mercado. E aí o Rodolfo vai trazer para a gente também alguns desafios técnicos que a gente tem enfrentado na implementação dessas APIs e dessa nova jornada de pagamento que as iniciadoras estão trazendo para o mercado.

Bom, para a gente começar, falar rapidamente aqui sobre a Sensedia, o que a gente tem feito, por que a gente está falando desse assunto também. Rodolfo, se você puder passar para o próximo slide.

Então, a Sensedia é uma empresa de integração moderna, ela oferece produtos e serviços no ramo de APIs, integração, microserviços, governança. E aí a gente vem atuando bem forte nessa vertical de Open Finance, Open Insurance. Então, a gente teve a oportunidade de estar participando ativamente dos GT de especificações do Open Finance Brasil. Então, a Sensedia foi escolhida como um dos parceiros do Bacen para ajudar nas especificações das APIs. Então, a gente tem a oportunidade de participar ativamente do ecossistema, tanto ajudando nas especificações, dando feedbacks que a gente vem tendo com os nossos clientes. Então, a gente consegue atuar bastante nesse ramo de Open Finance. Então, é por isso que a gente está vindo falar sobre iniciação de pagamentos aqui hoje com vocês.

A gente vai falar especificamente da fase 3 do Open Finance Brasil. Então, a gente sabe que o Open Finance Brasil é dividido hoje em quatro fases. Rodolfo, pode passar o slide, por favor.

O Open Finance Brasil é dividido em quatro fases hoje:

Fase 1

Fase 2

Fase 3

Fase 4 (aguardando especificação e implementação)

A fase 1, fase 2 e fase 3 já estão implementadas por diversas instituições. A gente está aguardando a especificação e a implementação da fase 4, que fecha todo esse escopo de Open Finance aqui no Brasil. E a gente vai focar bastante no serviço de iniciação de pagamento, que é o que a fase 3 traz hoje para a gente explorar, principalmente o serviço de iniciação de pagamentos.

Alguém está com o microfone aberto? Então, a gente vai focar bastante na fase 3, na fase de pagamentos, onde os serviços de iniciação de pagamento foram especificados e mostrados ao mercado. Então, a ideia aqui é mostrar um pouco desse momento. O que o Open Finance e o Pix trouxeram atualmente para o mercado, que fez com que a gente trouxesse esses assuntos aqui para vocês. A gente vê isso sendo bastante comentado no mercado hoje.

Então, a gente observou que o Bacen vem puxando a agenda regulatória, ele é o órgão que define o cronograma de implementação do Open Finance e do Pix. Então, ele vem com uma agenda regulatória de incentivo à competição no mercado bem forte. A gente vê isso acontecendo. O Pix é um próprio exemplo disso. O Open Finance também.

Mais recentemente, o Bacen trouxe novidades sobre os processos de onboarding, os processos de autorização de novas instituições a funcionarem como instituições financeiras. Então,a gente observa que o órgão regulador vem promovendo essa competição, que é o prometido na agenda, desde o começo dessa gestão. Vindo lá desde o começo dessa gestão do Bacen. E aí essa movimentação do órgão regulador traz de fato a inovação. A gente vê movimentação no mercado, várias movimentações no mercado. Principalmente com o uso do Pix, a gente vê uma adesão dos usuários brasileiros ao Pix. São muitas vantagens para quem usa o Pix, é de graça. Então a gente vê esses números aumentando. Recentemente o Bacen trouxe no seu fórum Pix alguns números. A gente vai passar por eles aqui sobre o uso do Pix e sobre o aumento desse uso. Mas a gente vê também que hoje a maioria dos brasileiros utiliza o Pix para pagar suas contas.

Um dado interessante aqui, a Capa fez uma pesquisa no mês passado. Ela entrevistou mais de duas mil pessoas em relação ao Pix para tentar entender o uso do Pix. E a gente viu que 94% das pessoas que foram entrevistadas utilizam o Pix. E de toda essa galera que utiliza o Pix, muita gente utiliza para pagar contas online. Então quase 70% dessas pessoas utilizam o Pix para pagar contas online. Eu particularmente tenho usado muito o Pix para pagar várias contas. Os estabelecimentos têm oferecido, tanto os comércios eletrônicos quanto os estabelecimentos físicos, descontos para quem paga com Pix. Então isso mostra um pouco da força que o Pix está trazendo para os meios de pagamento no Brasil.

E aí o Open Finance surfa um pouco dessa onda. Então a agenda do Open Finance hoje está muito atrelada ao que o Pix vem fazendo. Hoje já é possível se fazer uma transação via Pix. A gente sabe que o Pix garantido, Pix recorrente e Pix agendado também fazem parte da agenda do Open Finance. Então o Open Finance vem pegando carona nessa onda do Pix. A gente também já consegue ver, nesse ano, algumas experiências com pagamentos via Open Finance. Então tem alguns sites, algumas plataformas que já vêm oferecendo esse novo meio de pagar.

Então a gente viu recentemente a Kabum, que é uma das empresas lá do grupo Magalu, prometendo incorporar esse novo meio de pagamento no seu site. O Mercado Pago também, que foi um dos primeiros casos de uso do Open Finance, já vem incorporando esse novo meio de pagar nos seus parceiros, nos seus comércios eletrônicos. E recentemente também a gente viu a Twitch, que é uma plataforma para gamers, disponibilizando pagamento via Pix Open Finance. Então a gente começa a ver o uso desse novo meio de pagamento já em grandes varejistas, em grandes plataformas. Isso é muito bom, isso mostra para a gente que apesar de um início, a gente ainda está no início desse novo meio de pagamentos, dessa inovação, a gente já começa a ver isso chegando na ponta para o usuário final. E a promessa é que esse uso seja cada vez maior, dada a experiência que o iniciador de pagamento traz para essa jornada de pagar e de receber dos clientes. E a gente vai mostrar um pouquinho mais aqui da jornada e o que ela promete fazer.

Bom, aí a gente trouxe um pouquinho de alguns números aqui para se situar no mercado de Pix e de iniciação de pagamento. Então como eu falei, em setembro agora o Fórum Pix trouxe alguns números para o mercado do uso do Pix e também do Open Finance. Então em agosto agora a gente ultrapassou pela segunda vez consecutiva a barreira de 2 bilhões de transações Pix-mês. Então julho e agosto foram dois meses consecutivos que o número de transações Pix ultrapassou os 2 bilhões de transações mês, que é um número bem expressivo. E aí uma curiosidade, o dia que obteve mais transações Pix, a gente obteve quase 89 milhões de transações Pix em um único dia. Então isso demonstra a força do usuário final quando utiliza o Pix e como eles vêm utilizando o Pix. E aí uma informação, um dado interessante que a gente observou nos dados do Bacen é que as transações de pessoas para estabelecimentos comerciaisteve um destaque grande. Então no período de 12 meses aqui a gente teve 408 milhões de transações P2B, né? Person to Business. Isso mostra um pouco daquela pesquisa da CAP que eu trouxe, né? Que quase 70% das pessoas que foram entrevistadas utilizam PIX para pagar, para fazer compras online, né? Compras na internet. Então, esse número de transações P2B vem aumentando. Em agosto agora, a gente teve um aumento de 22% em relação a esse total de 408 milhões. Então, a adoção do PIX no comércio eletrônico e até em estabelecimentos físicos vem sendo notada, vem aumentando. E aí, isso deixa a gente animado, né? Porque justamente a experiência do iniciador de pagamento que promete diminuir a fricção que hoje existe nesses pagamentos via PIX.

E aí, a gente vê ali um número talvez um pouco ainda pequeno, mas já é um número considerável de transações via iniciação de pagamento. Então, desde que as iniciadoras foram criadas pelo Bacen, a gente tem hoje autorizadas a funcionar como iniciadora de pagamento no Brasil, 14 instituições. Aqui estão algumas delas, né? Nessa imagem. Mas essas 14 instituições já foram responsáveis por mais de 200 mil transações desde abril desse ano. A gente é possível ver lá no relatório do Bacen que essas iniciadoras têm mantido uma média de 50 mil transações mês desde abril. Então, esse número tende a aumentar. A gente já viu que no mês agora de agosto, que foi o último dado que foi reportado, a gente já aumentou um pouco esse patamar. Foram mais de 60 mil transações no mês de agosto, iniciadas por iniciadores de pagamento, nessa nova jornada de pagar que o Open Finance está proporcionando.

E aí, bom, essas 14 instituições têm que passar por um processo de homologação, de pedido de autorização pelo Bacen. E aqui a gente trouxe um pouco desses passos, né? O que é necessário hoje para se tornar uma PISP no Brasil, né? Quais são os passos necessários para ser habilitado como iniciador de pagamento e poder incorporar essa nova jornada de pagamento, né? Então, acho que o primeiro passo ali é um pedido de atuação como iniciador de pagamento para o Bacen, né? Então, instituições financeiras que já participantes, já habilitadas pelo Bacen ou não, devem pedir autorização para funcionar como uma iniciadora de pagamento. Então, esse é o primeiro passo, né? Esse passo pode demorar alguns meses ali, o Bacen tem um processo de autorização que pede várias comprovações, tanto da empresa quanto tecnologicamente falando. Mas a gente viu também ali um pouquinho antes que o Bacen vem simplificando esses processos, né? Então, esse é o primeiro passo.

E aí, obrigatoriamente, um segundo passo é a instituição ser aderente ao arranjo PIX, né? Então, ela obrigatoriamente tem que ser participante do arranjo PIX. Aqui tem uma curiosidade que a gente vem observando que o Bacen tem pedido, né? Na verdade, ele tem exigido das instituições que uma vez elas aderentes ao arranjo PIX, elas têm 10 dias para poder entrar no ecossistema de Open Finance. E é um prazo bastante apertado, então a gente viu uma estratégia ali de algumas empresas de, em paralelo, começar a executar esses passos. Então, pedir o processo para o Bacen, pedir adesão ao PIX e, em paralelo, também já começar o desenvolvimento das jornadas do Open Finance. Então, esse prazo a gente viu também que pode ser negociável, né? Algumas instituições conseguem negociar com o regulador esses 10 dias. Então, é uma curiosidade ali da adesão ao PIX e adesão do Open Finance.

E aí, depois que, então, a instituição está habilitada a funcionar como iniciadora de pagamento, ela está aderente ao PIX, ela começa a sua jornada dentro do Open Finance. Então, o primeiro passo é se cadastrar no Diretório Central do Open Finance como uma instituição de pagamento aderente à fase 3, a fase de pagamentos, e aí começar os processos de certificação. Então, hoje, as instituições financeiras têm que se certificar dentro do Open Finance, garantir que as APIs estão aderentes à regulação, às especificações queo Open Finance disponibilizou para as instituições. E aqui tem alguns pontos interessantes. O Rolovo vai entrar um pouco mais em detalhe sobre custos dessas certificações e custos em geral de entrar no ecossistema do Open Finance, mas existem esses custos, né?

E aí, bom, uma vez cadastrado e certificado, o ecossistema de Open Finance exige que uma iniciadora de pagamento comprove testes com três detentores de conta, né? Então hoje existe um processo de on-boarding de iniciadores de pagamento, é um processo formal de testes, né? Então são escolhidas ali três instituições detentoras de conta para que seja feita uma integração e seja comprovada ali a funcionalidade mesmo da iniciação de pagamento via Open Finance.

Posso fazer uma pergunta, Rafael?

Pô, claro, pode.

A detentora precisa fazer algum processo especial para trabalhar com as iniciadoras de pagamento? Tem que fazer alguma burocracia especial ou simplesmente a partir do momento que tem iniciadoras de pagamento elas podem trabalhar comigo como detentora?

As detentoras de conta passam pela mesma etapa aqui de cadastro no diretório e certificações do Open Finance. Então, uma vez que você passou pelo cadastro e pelas certificações, você já está apto a ser uma detentora. Não necessariamente você precisa se testar com três iniciadoras ou algo do tipo, né? Então as detentoras ficam ali on hold esperando os testes, mas já aptas a entrar em produção com as suas APIs de pagamento.

Tá, então supondo que eu já tenha isso e eu tenho, tá cadastrado, tenho o sistema lá em produção e tudo mais. Eu não preciso então de nenhum convênio com iniciadora. Basta que alguém na iniciadora envie para mim como detentora uma transação e eu não vou ter mais nenhuma pendência em termos de processos junto ao Open Banking, né?

É, na teoria não, tá? Na teoria não. O que a gente tem visto na prática? A gente tem visto algumas instituições que somente habilitam detentoras de conta nos seus aplicativos após testes. Então, a gente viu muito o mercado pago ali, né? O ecossistema hoje possui várias instituições detentoras de conta, mas, por exemplo, quando você entra no mercado pago, você vê apenas algumas. Então, a gente vê algumas iniciadoras de pagamento adotando a prática de testar com várias detentoras e aí para isso existe um processo formal mesmo no Zendesk lá do Open Finance, no Service Desk do Open Finance, para abrir esse teste bilateral. Então, as iniciadoras têm demonstrado interesse em testar com as detentoras antes de liberar as detentoras em seus aplicativos. Eu acredito que isso seja, eles estão fazendo isso porque seja melhor para o cliente final, né? A experiência de escolher uma detentora que realmente vá funcionar e aí evitar problemas de interoperabilidade e tal.

E essa iniciativa é parte de qualquer um dos lados? Essa iniciativa parte muito da iniciadora, da iniciadora pedindo os testes com detentoras.

Tá bem, obrigado.

De nada. Fique à vontade. A gente vê também muita conversa informal, assim, né? Então, o ecossistema é bem unido, assim, a gente vê bastante testes sendo feitos, além dessas três detentoras que são obrigatórias também.

Tá, mas não são todas as iniciadoras que exigem isso, certo?

Não, não, não são todas. Formalmente, não são todas.

Tá bem, obrigado, viu?

De nada. Tranquilo.

Bom, e aí, falando dessa jornada, né? O que essas 14 iniciadoras que estão habilitadas hoje no Bacen, elas implementaram e o que a jornada traz pra gente hoje como grande promessa de mudança na forma de pagar, né? Então, hoje, quando você vai fazer uma transação Pix, né? Você geralmente paga por QR Code ou usa a funcionalidade do Pix Copy Cola, né? Então, existem alguns pontos de fricção ali na qualo usuário tem que sair do aplicativo, entrar em outro aplicativo pra finalizar. E aí, a jornada de iniciação de pagamento vai outro aplicativo para finalizar e aí a jornada de iniciação de pagamento promete remover essas dificuldades, vamos dizer assim, essas barreiras ali na jornada atual de pagamento com três etapas simples, que partem de redirecionamentos ativos que a gente fala.

Então, para exemplificar essa experiência, você está fazendo uma compra ou pagando alguma conta ali no seu aplicativo, aqui na imagem denominada pela loja A, e aí você é redirecionado para o seu banco, do detentor de conta na qual o fundo vai ser removido da sua conta e transferido para outra conta. Então, esse redirecionamento ativo faz com que você seja encaminhado para a sua detentora de conta. E aí, um simples consentimento é dado ali, então você confirma aquela transação Pix e aí você é redirecionado de volta para a loja inicial que você estava, ou para o aplicativo inicial. Então, tudo isso é feito automaticamente, o que garante uma jornada um pouco mais fluida do pagamento.

Hoje, acho que o principal desafio do Pix é justamente a jornada de pagamento, né? A gente vê o pessoal que trabalha com Pix tentando otimizar essa jornada e tentando fazer com que ela seja mais fluida. Então, a jornada de iniciação de pagamentos via Pix promete trazer esse ganho para o usuário final, uma experiência mais fluida. E aí, diminuir a fricção, aumentar a conversão e aí criar também novos modelos de pagamento, novas jornadas de pagamento.

Então, para que detentoras de conta e iniciadoras de pagamento implementem essa jornada, elas têm que implementar as APIs, as APIs especificadas pelo Bacen, e também implementar uma jornada padronizada de telas. Então, o Bacen disponibilizou lá o guia de experiência do usuário, na qual as instituições obrigatoriamente têm uma jornada padronizada desse pagamento via iniciador. Então, esse também é um outro desafio para as instituições, implementar as APIs e a jornada padronizada.

E aí, bom, essa jornada pode ser implementada em vários casos de uso, em vários momentos de pagamento. A gente já observou, conversando com outras empresas, com clientes e conversas também com outros especialistas, a gente já observou várias jornadas possíveis de implementação. Então, hoje é basicamente onde tem pagamento via Pix é possível implementar uma jornada de iniciação de pagamento via Open Finance, com aquela experiência que a gente acabou de ver, de redirecionamentos ativos.

Alguns insights aqui, algumas coisas que a gente vem observando:

Jornadas de recarga de cartão pré-pago, ou de recarga de celular também, são jornadas que hoje são oferecidas via Pix e podem ser otimizadas com essa nova jornada.

A própria jornada de depósito, a gente já viu isso em várias instituições, então criou-se lá uma nova funcionalidade de depósito, na qual você traz fundos de uma outra instituição para a instituição que você está pedindo, que você está logado.

Checkouts de comércios eletrônicos, então geralmente onde tem uma jornada de checkout é possível implementar essa nova experiência de pagar com redirecionamentos.

E aí, plataformas, a gente viu o caso da Twitch, mas plataformas também de Bank as a Service ou de Payment as a Service, as jornadas as a Service, a gente vê várias empresas incorporando mais um meio de pagamento hoje, oferecendo esse meio de pagamento Pix Open Finance em suas plataformas.

E aí, bom, esses casos de uso, essas jornadas trazem vários desafios, implementar as APIs e as jornadas de tela não é algo extremamente complexo, mas também não é algo trivial. Então, acho que a ideia aqui é eu passar um pouco a bola para o Rodolfo agora e a gente iria entrar um pouquinho mais no técnico, nos desafios e as necessidades técnicas para se tornar uma PISP e poder implementar essa jornada de pagamento que a gente falou até agora.

Então, Rodolfo, pode assumir aí, cara. Beleza, mais uma vez, bom dia, obrigado aí pela participação de todos, né? Essa manhã aí conosco. Então, vou falar um pouco sobre os desafios,mas com um viés um pouco técnico de um implementador de uma PISP, tá? Esse desenho aí é um desenho bem big picture de como funcionaria um fluxo simplificado para uma solução de iniciação de pagamentos. Mas observa que essa caixa do meio aí, muita coisa acontece para que esses redirecionamentos, essas integrações possam fluir de forma com que todo mundo consiga interagir entre si. Então, para que isso aconteça, existem regras a serem respeitadas, existem padronizações que têm que ser seguidas, tanto por iniciadoras quanto por detentoras. E quem definiu isso foi todo esse GTs que fizeram o Open Bank junto com o Diretório Central. Então, foi algo construído a quatro mãos com instituições, com pessoas que foram chaves dentro dos GTs, empresas importantes que participaram, grandes instituições financeiras, instituições financeiras também nem tão grandes, mas que deram contribuições técnicas para isso. Então, para que fosse fluente a integração do Open Finance como um todo, não apenas para fazer trade, mas para todas as fases que por aí vêm.

Então, no primeiro momento, o primeiro tato técnico que a gente tem com Open Finance, de forma geral, não só com o PISP, é você ter que fazer seu onboarding no Diretório Central. Como o Esquerdo já antecipou, você tem que ter um cadastro, você tem que cadastrar sua organização de alguma forma, então você vai ter que imputar alguns dados, tem um processozinho minimamente burocrático ali para isso. E depois, agora aqui sim, já focado mais na questão da PISP, você tem que cadastrar sua declaração de software. A declaração de software, um termo também chamado de software statement, lá no Diretório Central, é um cadastro que você faz, ele é um cadastro que fica dentro da sua organização, então você tem lá sua instituição financeira e você pode ter várias declarações de software para essa mesma instituição financeira.

Seria o equivalente, fazendo uma analogia aqui um pouco, não tão profunda, mas rasa do que seria essa comunicação, imagina que seja uma comunicação cliente-servidor, então a declaração de software, que seria como se eu estivesse cadastrando alguns clientes ali para a minha organização, porque esses dados da declaração de software ali, dentre eles compõem uma coisa muito importante que é para o ecossistema, que são seus certificados. Então você tem sua organização cadastrada, você tem sua declaração de software configurada, chegou o momento de você ter os seus certificados para poder estar em compliance com todo o ecossistema do Open Finance.

Então a gente tem lá do lado direito os certificados, por exemplo, certificado servidor, certificado front-end, que para o contexto de PISP não são os mais importantes agora, e sim a gente focar um pouco nesses certificados BRC, que é o certificado de assinatura, e o BRK, que é o certificado de transporte. Então fazendo aqui uma correlação, digamos que a organização, o certificado BRC está para a organização, e o certificado BRK está ali para a declaração de software.

Então a gente vê muito o caso de uso, por exemplo, de instituições que são PISPs e querem trabalhar com empresas parceiras que não são instituições habilitadas a serem PISPs. Então o que acontece? Ela cadastra ali várias declarações de software, cada um com seu certificado, para que essas parceiras consigam se integrar com o ecossistema utilizando a instituição, como se fosse a provedora principal. Então uma forma de segregar isso, seus parceiros, seus clientes, seus clientes internos também, é através da declaração de software.

E a gente tem dentro do Open Finance, esses dois principais certificados, que é o certificado de transporte. Esse certificado de transporte é utilizado principalmente para a gente garantir aquela camada de segurança, fazer handshake. Então eu como cliente, também certificado de transporte, também chamado de certificado de cliente, ele é um certificado que a gente usa como cliente para poder fazer handshake, ou seja, criar um túnel mutuo TLS seguro entre instituições que fazem parte do ecossistema. Então a instituição, imagina que o Banco do Brasil queira se comunicar com o Bitcapital, essa comunicação via túnel mutuo TLS, certamente o Banco do Brasil vai ter que enviar os certificados dele de transporte para que esse handshake seja feito com sucesso. Então esse é um certificado muito importante para a questão da interoperabilidade, comunicação entre instituições.

E a gente tem um outro certificado também, que é bastante importante, principalmente para os fluxos de autenticação, segurança que a gente tem, que é o BRC, que é o certificado de assinatura. Então esse certificadoé feito principalmente para a gente fazer assinatura de payloads. Então, trazendo aqui, por exemplo, um fluxo que é bastante comum no Open Finance, quando a gente vai criar, por exemplo, um consentimento de fase 3, a gente precisa assinar ele, encryptar para garantir que esse payload chegue lá fechado, que não haja nenhum man in the middle. Então a gente usa esse certificado aqui para poder fazer a assinatura de payloads, assinatura de request over para fazer um fluxo de OAuth 2 de autorais, por exemplo. Então esse certificado é muito importante para esses fluxos de assinatura e muitas vezes também até para a criptografia de payloads.

E aí os certificados do mundo Open Finance não são emitidos assim por qualquer instituição. Então ela tem que ser uma emissora aceita pela ICP Brasil. O algoritmo aceito pelo certificado é apenas o RSA de 2048 bits e o digester de hash de certificado tem que ser o SHA-256. Então isso é um padrão que não muda, não existe variação para essas chaves de certificado. E para cada certificado ainda tem uma particularidade. Então o TRK aqui tem que ser emitido em uma cadeia V10.

Então quando você vai lá na sua emissora para emitir o certificado é muito importante que ela saiba se ela já tiver convivência no Open Banking, ela tem que ter essa correlação de que se eu estou emitindo certificado de transporte ele tem que ter a cadeia V10 e tem os atributos que são obrigatórios a ter nesse certificado.

O que são esses atributos? São metadados certificados. O certificado por si só já tem alguns metadados, que é a expiração, algumas chaves internas. E o Open Finance adicionou alguns certificados para garantir também algumas coisas com relação à interoperabilidade, para eu poder saber com que instituição estou conversando e coisas do tipo. Então tem metadados que identificam:

Qual é o software statement a qual eu estou me comunicando.

Qual é a organização.

Qual é o nome da organização.

Então tudo isso já vem para cá no certificado. Quando eu fecho uma comunicação no TLS com outra instituição, ela através do certificado já sabe prontamente com quem ela está conversando. Eu não preciso abrir um payload de uma mensagem para eu poder ver que eu estou conversando com a instituição A ou B. O certificado por si só já diz bastante coisa.

E a gente tem o certificado RCO, que já trabalha em cima de uma cadeia V5. Então é uma dica de ouro, que muitas instituições, às vezes por questão da gestão de certificado, deixam para fazer essa emissão muito em cima do prazo de expirar. Então, as entidades que são emissoras desses certificados, trabalhando ali às vezes com prazo curto, pode acontecer porque basicamente é um processo um pouco manual, humano, de emitir, por exemplo, um BRK que é numa cadeia V5 ou um BRC na cadeia V10. E isso aí vai indisponibilizar a sua solução, porque não vai funcionar. Porque tanto a parte que é conta PISP, dando como exemplo aqui, tem esses certificados desse padrão, mas a parte que é detentora vai validar se você está trabalhando em cima desses mesmos padrões. Então, você pode causar uma indisponibilidade total se você não emitiu os certificados seguindo realmente os padrões definidos. Isso aí tudo é documentado lá no portal do Open Finance. Tem o GitHub na parte de segurança que fala exatamente tudo sobre certificados.

Então, é muito importante que a pessoa responsável pela instituição financeira, tanto detentora quanto PISP, tenha muito conhecimento sobre isso, faça uma gestão boa de expiração de certificados. Certificados são anuais, para que não aconteça esse tipo de problema e não cause indisponibilidade à sua instituição em uma renovação de certificado eventual que possa vir a acontecer.

Outra coisa também interessante de fazer é que nós estamos falando de compra de certificado. Então, as empresas que hoje fizeram boarding dentro do ecossistema de Open Finance, parceiras, provedores, emissoras desses certificados são essas:

CertSign

Acerbo

Serasa

Solute

Ambas emitem certificado tanto da cadeia V10 quanto da cadeia V5. Quando a gente está falando de ambiente produtivo, a empresa tem que comprar um certificado. Pode ser um certificado autoassinado, não tem que estar toda a cadeia de CA lá, tudo certinho. Quando a gente fala de ambiente sandbox, os certificados já podem ser emitidos pelo próprio diretório central. Então, lá no diretório central tem uma tela, você pode, é um wizard, você pode emitir tanto certificado BRK quanto BRC à vontade. É um certificado autoassinado lá por eles e funciona para o ecossistema de sandbox. É importante saber isso porque lá na parte que a gente vaifalando de certificação, a gente vai falar por que a gente tem que fazer emissões constantes de certificados, principalmente nas fases de certificações. Beleza, tenho feito meu on-board, tenho meus certificados contratados, cadastrados já no Open Bank, lá no diretório central. Uma coisa que a gente tem que saber fazer como BISP, é saber integrar com o diretório central.

Então, imagina que eu tenho uma solução BISP, eu sou implementador BISP, eu tenho uma solução, eu tenho minimamente que saber conectar as APIs do diretório central para eu poder me comunicar com o mundo externo. Então, o diretório central é um centralizador de informação, como o próprio nome diz, diretório central. Então, nele tem as informações mais importantes que você precisa para poder integrar com outras instituições.

Então, no diretório central tem a lista de participantes, que, por exemplo, é um dado aberto, um GET que você faz em uma determinada URL, que tem lá um JSON com todos os participantes cadastrados no diretório central, tanto de sandbox quanto de produção. E para cada participante cadastrado, tem lá todos os seus dados. Então, que dados são esses?

Os dados de Authorization Server, quais recursos dos Authorization Server deles respondem ou não.

Os dados de Well-Known do Authorization Server, que daqui a pouco eu explico um pouquinho mais o que seria isso.

Então, são dados para você conhecer os outros participantes do Open Finance. Além disso, são dados abertos. Então, é fácil de você comunicar quando o dado é aberto. Você faz um GET em uma API, não precisa se preocupar com questões de segurança, nada do tipo. É TLS simples, então, tranquilo. Tem alta disponibilidade para o diretório, esses dados participantes, porque é um arquivo no bucket, lá S3, então ele já era. Toda a questão de disponibilidade de arquivos estáticos lá. É um arquivo que ele é feito reload dele de tempos em tempos.

Então, o que o diretório central sempre orienta? Dados primordiais para integração, que você faça a sua camada de cache em RUM. Porque você não depende ponto a ponto do diretório central. Uma eventual oscilação você vai conseguir resolver dentro de casa. Então, é bom sempre avaliar nas integrações com o diretório, sempre avaliar se é caso de você cachear a informação ou de você buscar sempre o real-time. Então, é realmente caso a caso, não existe uma fórmula mágica para te falar qual endpoint que você quer checar e qual que não. Porque se você quiser certas informações ali em tempo real, realmente você não vai conseguir um cache de longa duração.

A gente tem também as APIs de service desk. Então, a partir do momento que você está incluso dentro de um contexto de Open Finance, do ecossistema, você tem que responder pela interoperabilidade e você também pode questionar a interoperabilidade com outras instituições. Se eu estou tendo um problema, eu como instituição A, tendo um problema na instituição B, a forma legal, oficial de eu me comunicar com ela é através do service desk.

A gente sabe que tem uma política de boas práticas entre as instituições que permite com que eu faça uma comunicação bilateral. Então, se eu conheço uma instituição A, conheço o ponto focal da instituição B e ele se dispor na camaradagem a conversar comigo e resolver o problema ali de prontidão, joia. Esse geralmente é o melhor caminho para se resolver mais rápido. Mas muitas instituições já estão com o seu capacity técnico debilitado para poder atender outras fases, para poder refazer fases anteriores que tiveram que fazer às vezes com alguns débitos técnicos decorrentes dos prazos que foram pouco apertados lá no começo. Hoje a gente já está um pouco mais estabilizado com relação a cronogramas.

Então, tem uma instituição que está com o seu capacity técnico todo já alocado. Então, o meio legal de se fazer isso, que você vai ter resposta é o service desk, porque aí já incide em SLAs regulatórios. Então, a instituição tem que responder a você, senão ela vai responder isso aí oficialmente perante a BACEM, Open Banking, etc.

E existem alguns APIs do diretório também, como por exemplo a API de Software Statement Session, que está correlacionado àquele cadastro de software, que é um item primordial para você, por exemplo, fazer o DCR. O que é o DCR? É um processo de você, como instituição cliente, client, PISP, se cadastrar nas instituições detentoras, machine to machine. Então, o seu microserviço aqui de PISP, seu serviço, sua aplicação, seu software, se cadastrando em outra instituição, precisa desse dado de Software Statement.

E ele tem um TTL de 5 minutos. Então, minimamente a cada 5 minutos, quando você for fazer um DCR, você vai precisar pegar esse dado quente para poder fazer esse post lá na outra instituição e cadastrar seu cliente lá, para assim você poder se comunicar com esse Authorization Server de forma totalmente automática, digamos assim. Então, para isso você precisa

Para que você consiga gerar um Software Statement Access, você precisa gerar uma comunicação mútua TLS e você precisa gerar um access token com as credências para assim você poder acessar essa API do software.

stateful session. Então observe que aqui já é a importância de você utilizar seu certificado BRK para poder fechar a comunicação mútua TLS e por aí vai.

E uma coisa que está no forno, está quente, é a questão do PCM, que é uma plataforma de coleta de métricas. Antes, o contexto do diretório central fazia pooling nas instituições para poder pegar os dados de métricas das instituições, de indisponibilidade, de outras dessas instituições. Então era feito um pooling do diretório, era um para N. Então o diretório ia lá de tempos em tempos, havia alguns requisitos lá, requisitos não funcionais, que de 30 em 30 segundos ele batia lá para poder ver como é que estava o status de todas as APIs. Então, cada instituição tinha que desenvolver, ainda está válido isso hoje, porque o PCM ainda está em release candidate, mas veio com a ideia de substituir principalmente também isso, mas tem outras pegadas que eu vou explicar um pouco.

Então o diretório central, os bancos não querem mais fazer pooling, eles querem que você notifique eles tudo o que está acontecendo. Existem duas formas de fazer isso:

Você pode fazer de forma unitária.

Você pode fazer em batch, em lote.

Hoje, se não me engano, está definido o lote de 100 chamadas, então você diariamente ali, você vai ter que, minimamente, no final do dia, informar o diretório central, olha, tudo o que aconteceu em todos os meus endpoints regulatórios e de integração. Endpoint regulatório que a gente faz são aqueles endpoints que estão dispostos lá no Swaggers, no Open Finance, e os endpoints de integração são os endpoints de comunicação com o Authorization Server, esse tipo de situação. Então, tudo isso tem que ser reportado ao diretório central. Então, a partir daí ele vai conseguir tanto o PISP, quanto o detentora precisa ter isso implementado em casa. Então, praticamente o módulo que vocês vão ter que se preocupar em fazer para responder o diretório, existe uma marca de estado para o PCM, então você tem que se preocupar com o retry, tem que se preocupar se deu erro, o que você vai fazer com isso. Então, já embarca também uma complexidade bem grande para as PISPs e para as detentoras também. Então, o PCM é uma coisa que tem que estar no radar de todos.

E aí a gente tem a questão da interoperabilidade. A interoperabilidade, pela experiência que a gente teve com vários parceiros integrando tanto entre si quanto com todo o ecossistema, é uma coisa que no início tinha uma complexidade altíssima para todos os participantes do Open Bank. Porque, apesar da documentação estar lá, tinha muitas páginas de documentação que tinham interpretação dúbia. Então, uma instituição interpretava que tinha que ser A, outra instituição interpretava que tinha que ser A mais B. E isso não pode acontecer quando a gente está falando de integração de ecossistema de forma padronizada. Se é padrão, tem que ser padrão, todo mundo tem que saber se comunicar sem que haja esse tipo de interpretação.

Então, a interoperabilidade lá no começo do processo de onboarding das instituições no ambiente produtivo de Open Bank, dependeu muito de comunicação bilateral. Então, a gente precisava bastante juntar duas instituições numa sala de trabalho para poder fazer acontecer. Então, era time técnico, time de negócio trabalhando em conjunto para a gente fazer acontecer isso. Hoje está bem estável essa parte de interoperabilidade. Já foi pior nessa situação. Hoje são poucos casos. As instituições já conseguem se resolver entre si.

Então, outra complexidade de uma PISP é saber conversar com vários vendors de detentoras. Então, cada detentora pode ter sua solução ali. Aqui eu estou exemplificando o Authorization Server. Então, cada detentora pode ter seu vendor de Authorization Server, certificado FABRDW. E aí a PISP, se ela quiser ser uma PISP altamente interoperável, ela tem que minimamente saber conversar com todos esses formatos de Authorization Server. Lembrando que não é cada um escolhe a forma que vai lidar em si. Existe ali um contexto dentro das especificações de segurança do Open Finance que te dá algumas possibilidades. E existe o Authorization Server que faz apenas uma, que faz duas, que faz três. Então, minimamente tem que fazer uma. Então, existem essas possibilidades. Por isso que eu falo que a PISP tem que conhecer todas as possibilidades para ser altamente interoperável.

Para quea interoperabilidade aconteça de forma fluente, a gente precisa de padrões. Então, para que os padrões aconteçam, foi abordado dentro do Open Finance. Essa questão foi abordada dentro do Open Finance pelos GTs de segurança, junto com consultorias externas, tendo como espelho e inspiração o Open Banking de UK, da Europa, do Reino Unido. Então, trouxeram o OpenID junto com esse FAP, API, que é um profile do OpenID que foi desenhado para financial, ou seja, para bancos, financeiras. Então, dentro desses protocolos, existem várias RFCs que dão suporte para que essa interoperabilidade aconteça.

Outra coisa que é muito importante que se tenha conhecimento é que se você for implementador, você vai ter que ter um conhecimento muito profundo. Se você é implementador de PIS, não usar nenhum player, você vai ter que ter um conhecimento profundo de questões de segurança, interoperabilidade. Você vai ter que realmente mergulhar nesse mundo de RFCs, que é uma leitura um pouco também difícil para a maioria das pessoas. Não é uma coisa tão comum, antigamente a gente geralmente pegava a motorization server ali, utilizava ele e se virava para ter essas RFCs implementadas, a gente era apenas usuário. Hoje a gente precisa ser um pouco além disso, sendo um implementador Open Banking, tanto detentor quanto PIS.

E aí, voltando um pouco sobre a questão de certificados e certificações, então quando eu crio minha declaração de software, essa é a tela que a gente faz, o caso de declaração de software, eu posso cadastrar lá os meus BRcats. Ele é do BRSil da organização, então o BRSil está a nível de organização, que é o nível acima. O software estende-se a esse BRSil, que é o certificado de assinatura, e eu posso cadastrar meus certificados de transporte. Então, se tratando do contexto de certificação, eu estou aqui em sandbox, eu cadastrei um certificado auto-assinado, então não gastei nada para poder criar esse certificado, nem para usar ele, nem para ativar. Preciso rodar o motor do OpenID para poder gerar minha certificação. Essa certificação tem um custo de 5 mil dólares por submissão, se você não for membro da comunidade do OpenID. Se você for membro, mil dólares à submissão. Submissão é por item, então imagina que eu tenho uma detentora e uma PISP, e eu quiser submeter vários itens ao mesmo tempo, eu vou pagar os 5 mil dólares. Se eu submeter item a item, são 5 mil dólares por submissão. Então é bom ter isso em mente para poder economizar.

E nas renovações, os comitês do Open Finance sempre tentam negociar descontos perante o OpenID, sempre rolam os códigos de desconto, então é sempre bom estar de olho nos informativos do Open Finance, de olho em todos os e-mails que eles mandam, de olho no Confucius, de onde mantém toda a parte de comunicação, para vocês poderem não perder. Então como instituição, sempre rola algum desconto ou outro nos períodos de renovação.

Isso aqui é uma interface do motor funcional do OpenID. Então ele é self-service, você imputa lá seus dados. Agora voltando um pouco no passo atrás, eu gero meus certificados lá em sandbox. Isso aqui é rodado na infraestrutura de sandbox. Por quê? Eu tenho que imputar dentro do motor do OpenID, tanto PISPs quanto detentoras, os meus certificados, inclusive a chave privada. Então quando eu faço a publicação do meu teste, a sua chave privada vai estar exposta. Por isso que é importante a gente gerar certificados lá no diretório central em sandbox, porque depois que eu exponho esse teste para submissão, ele vai ficar público para qualquer um acessar. O interessante é eu expurgar os certificados que já foram utilizados. Por uma questão óbvia de segurança, porque a sua chave pública vai estar exposta e qualquer um poderia se passar por você num contexto de multa ou TLS, por exemplo.

Então as certificações que você tem que ter como PISP é de rely pass. Nessa certificação ele valida algumas coisas como:

Request usando o PAR, que é a Push Authorization Requests.

Isso aqui faz parte do OpenID Connect, mais o ALF, no profile de FAP do Open Finance Brasil.

Encripted do request, o object do ID token, algoritmos de hash, claims JWT, nonce.

São coisas que a PISP precisa gerar que são validadas, claro, lá na detentora. Mas a PISP é que é a geradora de certas informações. Então isso é validado pelos testes das certificações funcionais de rely pass.Então minimamente a PISP tem que ter conhecimentos bem legais com relação a essas especificações, a OpenID Connect e nesse profile de FAP. Existe um canal, que é o Open Banking Brasil RP que é o Mint Group no Slack. Esse canal, você pode pedir a sua inclusão lá. E lá é uma comunidade mesmo, onde a galera se ajuda nas dúvidas dos testes funcionais de rely parties. Lá saem códigos também promocionais para você se cadastrar. Então existe um conteúdo lá interessante. Tem gente, inclusive, da Waden lá. Não é só do nacional, do Brasil. Existe gente lá de todo lugar. São implementadores de PISPs, são implementadores de fase 2, que são TPPs, que precisam ter certificação. Então lá é o lugar mais interessante de você obter conteúdo quente sobre certificações e implementações de rely parties.

Um último tema que eu quero trazer aqui é sobre sincronização de dados para TPPs e PISPs. O Open Banking tem esse leque aí de que a comunicação que é assíncrona, a gente não é informado em momento nenhum de como o que aconteceu lá do outro lado. Então, lembrando que são duas instituições totalmente diferentes, infraestrutura diferente, e a instituição detentora não tem conhecimento de como te informar também. Por quê? O Open Banking não padronizou esse tipo de comunicação bilateral em determinadas situações. Então a forma que foi resolvida pelo Open Banking para que a instituição PISP tenha acesso à informação quente é fazendo pooling. E aí a gente entra num contexto de algumas problemáticas que o pooling pode trazer. A gente pode chegar dentro de um requisito de rate limit que a gente vai ser barrado, imaginando que a sua solução tem uma volumetria muito alta. Então o rate limit hoje definido para esse tipo de GET, por exemplo, de PIX Payments, é de:

300 TPS global

50 TPS por instituição financeira

8 TPS por IP

Qualquer um desses que atingir primeiro, a instituição detentora pode te dar um 429 lá falando que você já atingiu seu rate limit. Então a questão da sincronização dos dados é um desafio também para a gente poder não fazer pooling em excesso, não fazer pooling em falta de pooling também vai te deixar sem saber o que fazer no fluxo. Ele é importante para o fluxo, principalmente para questões de pagamento. Ele é importante e eu digo até que é obrigatório você ter isso, senão a gente não consegue fechar o PIX em si, o pagamento, sem saber o status de como está na outra instituição. Então esse é um ponto que eu trago de atenção também para os implementadores PISPs. Não só PISP também, fica aí como um itenzinho também para as TPPs de fase 2 também. Isso aqui é um problema que a gente passa bastante.

Então em resumo, esses são os key words de algumas problemáticas que a gente trouxe aqui no decorrer da apresentação, falando sobre o desafio da gente poder implementar a jornada, então a jornada de tela, você tem que ter uma equipe multidisciplinar no seu time, uma equipe de negócio, uma equipe técnica. Você não pode ter uma jornada diferente do que está especificado pelo GT de experiência. Você pode mudar um pouco, mas você não pode trazer uma experiência diferente porque a ideia do Open Banking é que o usuário se sinta utilizando de forma transparente diante de todas as instituições e tal, sem sentir muito o impacto de que está usando situação diferente. Então ele tem que se sentir no Open Banking independente da instituição que ele esteja.

Integração com o diretor central é um outro desafio. A interoperabilidade é um desafio também a ser suportado. Certificados, certificações e a questão da sincronia dos dados fazendo o pooling. Esses são os principais desafios que a gente vem passando. Cada desafio desse aqui seria um bate-papo imenso que a gente teria, eu teria um prazer de fazer com vocês no futuro próximo, no próximo café, que a gente pode falar um pouco mais da parte técnica, um pouco mais da parte de negócio também e ir mais profundo em cada item desse que realmente tem muito conteúdo por vir.

Agora vamos abrir aí um tempinho, falando bastante coisa aqui para a galera, ver se tem algumas perguntas aí da galera para a gente responder. O Rodolfo Diego mandou aqui durante a fala uma pergunta, ele perguntou, o Diego Calasanz, ele perguntou qual a diferença para o consumidor final e para o estabelecimento em fazer ou receber um pagamento via Pix tradicional e o Pix Open Finance? Eu diria que para o consumidor final, achoque o grande ganho ali, a diferença é na jornada, na experiência. Então ele vai ter uma experiência mais fluida, ele vai ter uma experiência mais simples e aí isso pode fazer com que ele tome a decisão de não desistir de uma compra, por exemplo. Então hoje as principais fontes de melhoria são justamente na jornada, a pessoa decide não comprar porque eu tenho que sair do meu aplicativo e ir para outro aplicativo, copiar o QR code. Então acho que para o usuário final é a experiência em si. Para o estabelecimento, bom, oferecer um novo meio de pagamento e também fazer com que essa... usufruir dessa menor fricção do usuário. Então a desistência nos carrinhos, nos checkouts, ela tende a diminuir. É isso que está todo mundo esperando com essa nova experiência. Então no momento final de comprar, você não se importar muito com a experiência de comprar, ela ser o mais simples possível. Acho que essa é a tendência, participando de outros fóruns, a tendência é que o fluxo de pagamento seja praticamente invisível no futuro e a PISP traz já um passo para a gente chegar lá. Isso é um futuro talvez de médio e longo prazo, mas a PISP nessa nova experiência já otimizou a jornada fazendo esses redirecionamentos. Então para o estabelecimento é aumentar a conversão, aumentar a conversão nas suas vendas, nos checkouts.

Beleza, se alguém tiver mais alguma pergunta, fique à vontade. Vamos ver se tem mais alguma aqui. Bom, aqui tem uma pergunta: quanto tempo demora em média para configurar e certificar uma PISP no Open Finance Brasil? Acho que a gente falou um pouco disso ali no começo, mas esse processo pode demorar alguns meses, então a gente vê em média de 3 a 6 meses, dependendo do engajamento da instituição em desenvolver as telas e tal, mas os processos também ocorreram em paralelo. Então o pedido de autorização, a adesão ao arranjo PIX, as certificações e os testes em produção podem demorar de 3 a 6 meses. A gente vê uma média boa de 3, 4 meses mais ou menos para a entrada em produção.

Tem outro aqui também, falando sobre se é necessário gerenciar os consentimentos, mesmo sendo uma PISP. É até uma dúvida bem comum, porque quando a gente fala em gerenciar consentimento, a gente fala do motor de consentimento, se tratando de uma PISP, você não precisa ter um gerenciamento tão granulado do consentimento quanto uma detetora. A detetora tem que garantir as transições de máquina de estado ali, fidedignas com o que está especificado no Open Finance. As PISP, ela minimamente tem que ter os estados atualizados, então tem que manter sim, ou seja, uma cópia do seu lado, até para você poder saber qual é o estado real daquele consentimento para você poder usar, para poder fazer o PIX, consumir aquele consentimento e coisa do tipo. Então, para você precisar inclusive reduzir a questão do pool, então seria uma orientação que sim, que tenha.

O Adelino aqui perguntou também: o fato de dar o consentimento para um agendamento pode dar mais flexibilidade para conseguir os crediários? Adelino, eu diria que sim. A gente vê o PIX garantido, você fazer uma transferência PIX agendada sem ter saldo na sua conta. Então isso vai te proporcionar poder fazer uma compra sem ter o dinheiro. Acho que é o crediário que você quis dizer, né? Crediário é um termo bastante usado no comércio físico, assim, né? Você faz o crediário em alguma loja e vai lá todo mês pagar. Acho que o PIX garantido que tem por debaixo dos panos ali, o agendamento, você pode sim fazer uma compra sem ter o dinheiro de fato ali naquele momento. Então, com certeza, flexibiliza essa possibilidade de crédito, o crediário que você mencionou.

‍