Workshop do Piloto de Jornada sem redirecionamento 2.2.0

Opa, boa tarde, pessoal.
Boa tarde, M.
Boa tarde.
>> Boa tarde, gente. Tudo bom?
Boa tarde. M.
Boa tarde,
Ah.
Boa tarde, pessoal.
Boa tarde.
>> Boa tarde. Boa tarde.
>> Boa tarde.
>> Boa tarde, pessoal. Eh, eu peço para que
a gente aguarde mais dois minutinhos e
aí a gente começa o nosso workshop.
Boa tarde,
Pessoal, acho que a gente já pode
iniciar. Já estamos aqui com 84
participantes, aguardamos 6 minutinhos e
a gente tem uma agenda longa pela
frente. Então, queria novamente desejar
boa tarde a todos vocês.
Eh, aqui a gente, né, a ideia a gente
ter uma conversa sobre a jornada de
redirecionamento. Qual é a pergunta? A
pergunta é o quê?
>> Áudio vazando aqui.
>> É, beleza. Vamos lá.
Eh, então, começando aqui o nosso
workshop, pessoal, eu queria primeiro
compartilhar com vocês a agenda dessa
conversa de hoje, também alguns recados
gerais. Eh, com relação à agenda, a
gente deve ter aqui uma introdução que
eu vou dar para vocês com relação a este
piloto. Em seguida, o Wendel, que é o
nosso especialista aqui em JR, vai falar
um pouco mais do produto e também das
funcionalidades que a gente tá incluindo
nesse versionamento. O Zé, também o
nosso arquiteto aqui da JSR, ele vai
explicar um pouco mais do ponto de vista
das especificações técnicas, né, e
também vai falar um pouco dos testes da
FVP que a gente vai ter durante o
piloto. Eh, a Débora e a Vivian aqui, as
nossas especialistas em seguida, vão
apresentar a jornada para vocês, né,
tanto a jornada do vínculo também como
do pagamento, seja o pagamento imediato
ou Pix automático. O Paulo, em seguida
vai falar um pouco mais sobre a
certificação Fidel. Eh, e eu volto com
vocês aqui ao final para falar um pouco
do cronograma desse piloto e também dos
próximos passos, tá? Então, a ideia é
que a gente consiga apresentar para
vocês eh as novas funcionalidades, né,
apresentar um pouco mais o produto e
falar mais no detalhe de como vai
funcionar esse piloto. E aí, antes de
começar, eu queria também passar para
alguns eh recados gerais. O primeiro
deles é que esse workshop ele tá sendo
gravado e ele será disponibilizado para
todos os participantes.
Eh, queria pedir que as dúvidas que
surgirem ao longo da nossa apresentação,
que elas sejam preferencialmente
encaminhadas aqui pelo chat. Então, que
vocês mantenham o microfone fechado ao
longo da apresentação. Ao final dela, a
gente vai ter também uma sessão
específica para dúvidas, onde vocês vão
poder abrir o microfone. Mas aí queria
só combinar essa dinâmica com vocês. Eh,
todas as dúvidas elas vão ser
respondidas. Se elas não forem
respondidas durante o chat, né, ao longo
da reunião, elas serão respondidas de
forma síncrona. Aí também serão
compartilhadas com vocês, tá? Eu vou
colocar aqui no chat também um
formulário e aí eu peço a gentileza de
todos vocês que preenchem que preencham
ao longo aqui do nosso workshop, um
formulário eh de mapeamento da
certificação Fidel. Eh, acabei de
colocar aqui no chat, peço que todos
vocês indiquem aqui qual organização
pertencem, org e que nos indiquem, né,
se vocês já estão com a certificação
Fidal em dia. Eh, e aí queria também
finalizar aqui dizendo que todo o
material dessa apresentação, ele também
será compartilhado com vocês junto com a
FAC e junto com a gravação.
É, então pessoal, acho que só
relembrando a todos, né, esse piloto
será acho que o terceiro piloto que a
gente tá, o quarto piloto que a gente
vai est fazendo, o primeiro que tivemos
aqui na associação foi também o de JCR,
só que a época para um grupo menor de
instituições. Piloto é uma política que
a gente tem aqui e que tem como alguns
objetivos, né, eh, principais. Primeiro,
a gente garantir o comportamento
funcional dos produtos e serviços do
Open Finance, a gente garantir também eh
um, né, uma jornada, uma experiência do
usuário fluida também, sem fricções ao
usuário final, garantir a qualidade dos
dados compartilhados e também reportados
por vocês aqui para pro perímetro
sindral, garantir a integração entre as
instituições com as ferramentas do
perímetro sindral. eh ferramentas essas
que são fundamentais para que a gente
possa ter um monitoramento do
ecossistema. E obviamente acho que
talvez o mais importante a gente
garantir a interoperabilidade aqui do
ecossistema, né, e reduzir a quantidade
de incidentes bilaterais. Então a
política de testes em produção, ela já
tá vigente, né? Acho que esse é eh
também um dado legal para compartilhar
com vocês. Dentre todos os pilotos
previstos para 2026, o piloto de JSR
2.2.0 zero deve ser o maior em termos de
instituições participantes e também
volumetria de testes, tá? Então a gente
tem 17 conglomerados que já operam JSR e
também vão fazer parte desse piloto para
testar as novas funcionalidades. Nós
temos 51 eh novos conglomerados, né, que
são novos entrantes e a gente tem ao
todo aqui 256 marcas detentoras
participantes no mínimo, né? se a gente
desconsidera eh enfim uma um grande
conglomerado, a gente vai deve ter
aproximadamente 2600 600 testes
funcionais aqui que vão ser executados
pela associação Openfirance e
aproximadamente também 100 jornadas de
UEX que serão monitoradas.
Eh, e aí para entrar um pouco mais no
detalhe, antes de passar aqui a palavra
aos meus colegas, eu queria deixá-los
ciente de quais são os critérios que a
gente deve monitorar nesse piloto, né?
Esses critérios eles seguem a risca ali
as diretrizes gerais do do da política
de testes em produção e eles vão estar
separados, né, entre detentoras e também
iniciadoras. Então, falando um pouquinho
mais aqui sobre as detentoras, a gente
deve ter, né, como primeiro item, eh, o
monitoramento da jornada de UEX, né?
Então, eh, a gente espera ali o
atendimento de requisitos mínimos do
guia, né, que já tá publicado. Eh, e a
gente deve, eh, validar aqui tanto o
vínculo do dispositivo para detentoras
como também a gestão do vínculo de
conta, incluindo, né, uma funcionalidade
que tá sendo incluída agora, que é a
edição de limites. Eh, a gente não vai
testar o a jornada de para todos os
participantes. Então aqui a gente eh vai
testar apenas para um grupo de controle
eh que inclui todas as instituições que
já operam a JCR, que vão precisar est
aderentes aqui, sobretudo a essas
alterações que ocorreram na área de
gestão do vínculo. E a gente também vai
selecionar ali as maiores os maiores
conglomerados dentro dos novos entrantes
para que a gente consiga também
monitorar essa jornada.
Para as detentoras, a gente também tem
uma etapa eh muito importante que é a
execução dos testes funcionais via FVP.
Então aqui a gente vai esperar o sucesso
completo em todos os testes para todos
os servidores de autorização daquele
conglomerado, tá? Tanto o PF quanto o
PJ, né? Então PJ é também um segmento
aqui que a gente tá incluindo agora.
Então, a gente deve ter 10 módulos de
vínculo mais pagamentos imediatos e a
gente deve ter seis módulos de vínculo
mais Pix automático, tá? Lembrando que
aqui os novos rent eles vão ter que
executar tudo de tudo para PFPJ. Quem já
opera JSR vai ter que executar tudo para
Pix automático, mas vai ter que executar
também para pagamentos imediatos para eh
PJ, tá bom? Então, a gente não vai
exigir de quem já opera a reexecução dos
testes para PF, mas PJ como tá sendo
adicionado nesse momento, a gente também
vai eh monitorar isso de quem já tem a
JS.
Eh, então é um pouco do que tá aqui na
obrigatoriedade, né? As instituições que
já participaram do piloto anterior, elas
estão dispensadas.
Eh, mas as instituições e também aqui um
ponto é que instituições que têm
dispense do Pix automático, obviamente
não precisam ter sucesso aqui nos testes
do Pix automático.
Eh, para as instituições que que for
possível a gente monitorar a jornada de
UEX, a gente também vai ter um teste
específico para validar o comportamento
funcional após a edição do limite do
vínculo, tá bom? Eh, então esse não vai
ser um teste que vai ser executado para
todas as instituições, vai ser um teste
executado somente para aquelas que forem
monitoradas ali em termos de jornada. Em
seguida, a gente tem aqui um indicador,
um item também importante que integração
com as ferramentas. E aqui a gente tá
falando da PCM. Isso vai ser válido para
todas as detentoras e também para as
ITPs. A gente espera um um pareamento
igual ou superior a 95%
com o envio de todos os additional
infos. Eh, isso aqui é super importante
pra gente conseguir monitorar o
ecossistema e a gente espera que todas
vocês estejam prontas aí para reportar
aqui paraa PCM. E aí a gente entra em
critério que a gente chama aqui de
engajamento, né, que são testes
bilaterais de liquidação do pagamento,
né? E aqui o que a gente espera é
realmente conseguir concluir um
pagamento iniciado a partir de um
vínculo de conta, tá? Isso eh precisa tá
bem claro para vocês. Eh, então as
detentoras vão precisar fazer liquidar
pagamentos com pelo menos 10 ITPs eh que
estejam participando desse piloto. E a
gente tem aqui uma volumetria mínima de
pagamentos, tá? Então, serão 100
pagamentos por produto, sem pagamentos
para pagamentos imediatos e agendados e
sem pagamentos pro Pix automático. Aqui
a gente tem um detalhamento. Então,
quando a gente fala de pagamentos
imediados e agendados, é mandatório
também que as detentoras ofertem o
agendamento. Então, a gente vai cobrar
aqui 30 pagamentos agendados. E para as
detentoras que ofertarem eh para o
público PJ, a gente vai exigir pelo
menos 15 pagamentos PJ. Eh, e pro Pix
automático, a gente tem aqui 30 first
payments e 70 recurring payments e
também a volumetria mínima de 15
pagamentos PJ. E ao final desse piloto,
nenhum ticket bilateral pode estar em
aberto aqui entre as instituições. A
gente também vai tá acompanhando isso
daqui e também vai ser um critério de
sucesso do piloto.
Quando a gente fala das ITPs, a gente
tem praticamente os mesmos itens, com
exceção da FVP, né? A FVP ela é testada,
ela testa apenas as APIs das detentoras.
Então não existe FVP para iniciadora.
Paraa iniciadora, o que que a gente tem?
A gente vai monitorar também a jornada.
Eh, a iniciadora, a gente vai monitorar
a jornada, tanto o vínculo quanto o
pagamento pros dois produtos, tá bom?
Então, se quiser ofertar pagamentos
imediatos agendados ou Pix automático,
vai ter um teste específico. E para
iniciador a gente também vai testar a
jornada por canal, tá bom? Então, se
qualquer iniciadora desejar ofertar
qualquer produto desses via JSR, por
exemplo, em desktop, vai ter um teste
específico para desktop. Se quiser
ofertar só para mobile, tudo bem. a
gente vai de qualquer forma exigir o
teste mobile, tá bom? Eh, lembrando que
aqui pro Pix automático, né, é
importante a gente ter ali a telinha da
recebedora e dizer que a, né, o vínculo
com a recebedora é de total
responsabilidade aqui da iniciadora, tá
bom?
Integração com as ferramentas é o mesmo
critério que vale para as detentoras,
95% de pareamento envio de 100% das dos
additional infos. E a gente tem também
aqui o critério de testes bilaterais,
tá? Na ponta da iniciadora, a
obrigatoriedade é com a realização de
pagamentos com as 20 detentoras, com 20
detentoras.
E dessas 20, 50% delas tem que ser
pertencentes aos conglomerados do grupo
de controle. Acabei de perceber que o
Foodnote não tá aqui, mas a gente
adiciona no material final e a gente
compartilha de com vocês quais são essas
instituições desse grupo de controle
aqui. Eh, e também eh, e aí olhando
paraa volumetria, também se mantém a
volumetria mínima de 100 pagamentos,
sendo pelo menos 30 pagamentos agendados
para quem ofertar e 15 pagamentos PJ, tá
bom? se a instituição iniciadora ofertar
esse serviço. Lembrando que a iniciadora
eh ela não tem participação obrigatória,
então ela tem ali a opção de indicar pra
gente o que que ela vai desejar ofertar
nesse piloto. Eh, um ponto importante
aqui que eu vou também frisar no final,
mas a gente já divulgou também no
informa. A gente pediu que todas as
iniciadoras que queiram participar desse
piloto, né, ou seja, que queiram ofertar
o Pix automático ou que queiram ofertar
pagamentos para desktop, eh, a gente
pediu que qualquer iniciadora que queira
participar que abra um ticket pra gente
no Service Desk até a data de 30 de
janeiro. Então, a gente ainda não tem a
informação de quais são as ITPs que vão
participar, porque essa janela ainda tá
em aberto. Eh, queria reforçar aqui o
pedido. Eh, e a data de 30 de janeiro
aqui, ela é importante para que a gente
consiga se planejar com relação à
execução desses testes de jornada, tá
bom? E para que a gente consiga também
compartilhar com o ecossistema quais vão
ser as ITPs que vão estar participando
eh em tempo.
Eh, pessoal, então acho que em termos de
critérios é um pouco disso. Eh, eu volto
a falar com vocês, né, cronograma, como
que vai exatamente funcionar, como que a
gente vai monitorar cada um deles no
final aqui da nossa agenda. Eh, mas eu
queria eh já começar compartilhando com
vocês o que que vai ser acompanhado
nesse piloto antes de passar aqui a
palavra pro Wendel. End é o nosso grande
especialista aqui em JSR e ele vai falar
para vocês um pouco mais aqui do que que
é eh esse esse serviço aqui na trilha do
Open Fence. Então, And, eu passo a
palavra para você. Posso só aproveitar
para tirar uma dúvida aqui, o Edu, antes
de você passar a palavra pro Eric, eu
vou pedir que final é se quiser mandar
no chat, mas se não para guardar e aí no
final a gente a gente responde, tá bom?
Então,
>> vale, Edu, obrigado. Aqui, eh, acho que
só dando um contexto, o desafio aqui do
Open Finance em relação ao produto de
jornada sem redirecionamento, ele é
muito grande. Ele é um trabalho feito a
várias mãos aqui. Eu sou só uma pessoa,
um interlocutor ali que participa com
grandes pessoas aqui nos grupos de
trabalho e da associação que tô dando
voz aqui para essa frente, tá? E aí,
seguindo aqui o a a apresentação, sem
mais delongas, eu queria que você eh
passasse aqui o primeiro slide. Acho que
aqui a ideia, pessoal, é apresentar aqui
um um macrocronograma da dos steps que a
gente teve para fazer a implementação do
produto eh a da JSR com Pix automático e
as demais melhorias, né? Então, de
lembrando aqui alguns dos steps que a
gente passou, a gente teve ali em maio
de 25 um cronograma eh com as
prioridades eh do Banco Central, eh
almejando ali o desenvolvimento tanto da
implementação do produto em si, como das
demais demais produtos pro ecossistema.
Eh, a gente teve também ali um trabalho
feito pela associação de consolidar
alguns itens que a gente tinha dentro do
nosso backlog, incrementar ao escopo do
produto, né? Até então, em setembro de
25 a gente constrói ali a nossa primeira
deliberação junto a aos participantes e
apresenta ela no CA. Essa deliberação é
o que traz ali o nosso cronograma, é o
que diz, o que é o que nos em relação às
entregas que são necessárias pro
cumprimento desse desafio aqui, tá? Em
outubro de 2025, a gente faz o
lançamento da primeira versão RC do
produto. É o momento que a gente tem
maior maturidade em relação a todos os
incrementos e melhorias que a gente vem
recebendo ali de inputs dos
participantes, né, entendendo ali a a a
evolução do produto e a gente solta esse
essa versão. Em janeiro de 2026, a gente
tem aqui o lançamento da versão estável,
eh, aonde a gente garante que tudo
aquilo que a gente veio aprendendo com
com os participantes, né, que eh, como
eu disse na no início da minha fala,
essa construção ela é feita a quatro
mãos, a gente faz ali o o lançamento da
versão estável muito com base em tudo
aquilo que a gente conseguiu
implementar, ouvir e evoluir ali o
produto como um todo. E aí, como você
bem colocou do a gente tem também ali o
início do piloto acontecendo em
fevereiro, né, onde a gente vai ter um
um período grande aqui de maturação, em
torno de 75 dias pra gente acompanhar eh
todas as instituições ali ou o desafio
maior que vão vão ser ali mais de 100
instituições, enfim, que a gente vai ter
aqui para poder fazer essa implementação
e conseguir dar ali o selo de de
autorização para para paraa publicação
do produto como um todo no em Mar
Aberto. E aí, por fim, a gente tem o Go
Live acontecendo do produto em abril.
Boa? E aí, se você puder passar aqui o
próximo slide, eh, eu trago aqui o a
ideia nesse, nessa apresentação não é
descer no nível ali sobre todas as
características do produto, mas dar um
um uma relembrada do que que é a
jornada, né? o o a jornada aqui, a a JSR
como um todo, né? Então, explicar aqui
para todos que o fluxo da da JSR ela
acontece em duas etapas. a gente tem a
primeira etapa que a gente chama de
vínculo de conta, aonde o usuário no
ambiente ali da ITP, ele é redirecionado
paraa detentora e ele faz o vínculo da
conta no qual ele quer fazer aquelas
transações junto com o ITP no qual ele
escolheu. aonde ele define dentro do
ambiente da detentora os limites
transacionais ali de cada uma das da dos
pagamentos que ele pode operar e e o
prazo de inspiração daquele
consentimento. Uma vez que isso foi
definido, tem o fluxo do pagamento, que
é a etapa em si do pagamento
acontecendo, sem o redirecionamento pro
ambiente da detentora. E aí, como o
mercado eh vem adotando, vem falando aí
como um todo, a gente tem alguma algumas
nomenclaturas para JSR, né? a gente tem
a nomenclatura que é falada como PIC por
aproximação, Pix por biometria, entre
outros. Então, esse fluxo aqui que eu
acabei de explicar numa visão bem alto
nível, é a jornada em si em relação à
sua aplicação, né? Eh, acho que
é isso aqui do E aí, enfim, para poder
apresentar aqui o próximo slide, eh,
olhando aqui com a evolução do produto,
dado o cronograma ali, os desafios que
foram propostos pra gente, a gente traz
aqui eh o os principais pontos que estão
sendo incrementados nessa nova versão. A
gente tem aqui a possibilidade de hoje
conseguirmos fazer pagamentos ali
através do PJ, né? Então a gente expande
a funcionalidade da JSR pro público PJ,
permitindo ali acesso aos pagamentos sem
ter a necessidade ali dos
redirecionamentos, utilizando toda a
estrutura do do Open Finance que a gente
tem. A gente também tem aqui a
possibilidade de criar novos vínculos,
né, com autorizações de consentimentos a
partir do desktop. é mais uma
possibilidade, é mais um meio para
conseguir operar esse fluxo como um
todo. A gente também tem aqui a condição
de edição de parâmetros, né? E essa
edição foi algo muito visto, dado todos
os aprendizados que a gente teve e todos
os inputs ali recebidos que eram
necessários ali ter, dar a flexibilidade
para o usuário, né? conseguir fazer a
edição dos do prazo de inspiração no
qual ele dava ali pro pro detentor ali
junto com o iniciador para que aquele
vínculo permanecesse ativo. E ao mesmo
tempo deixe tivemos também algumas
ponderações em relação possibilidade de
editar os limites transacionais eh que
são das eh transacionais das operações
de pagamento. Então aí a gente tá
falando de conseguir agora sem a
necessidade de criar novos vínculos,
conseguir fazer edições de limites das
transações ali operacionais que que esse
usuário tem ali definido junto com o seu
detentor, tanto da transação quanto o
limite diário. E aí por fim, nessa nessa
nova adição aqui da funcionalidade, a
gente fala do Pix automático.
Hoje o fluxo do Pixel automático, ele
ele já existe, ele já é operável e a
gente tá adicionando as mesmas
características de que já existe dentro
do tril do Open Finance na API de
pagamentos automático, né? A gente tá
trazendo essas mesmas características
aqui pro Open Finance. No final das
contas aqui a gente tá tá dando a opção,
né, do Pix automático do usuário ali
conseguir configurar débitos recorrentes
com valores fixos e variáveis, né? E aí,
eh, o que que isso traz de benefício
tanto pro usuário pagador quanto pro
usuário recebedor, né? Então, o usuário
pagador, uma vez que ele autoriza essa
essa transação, os débitos eles
recorrentes eles são feitos de forma
automáticas, né, na data certa, de forma
segura e transparente. Tudo isso com
base no consentimento que o pagador deu
ali ao recebedor. E o que que quais são
os benefícios que a gente traz também
pro recebedor nessa via aqui? O
recebedor, ele tem ali eh condições de
enviar os dados da cobrança através do
seu iniciador, né? Eh, o iniciador, por
sua vez, ele manda essas transações ali,
manda essas informações ao banco do
pagador com a definição ali da
frequência dos pagamentos, os limites
mínimos da cobrança que podem ser
transacionadas ali, é todo aquele acordo
eh negocial que é feito entre as partes.
E isso aí o o iniciador ele acaba só
operando conforme a negociação ali
repassada, né?
O o recebedor ele define ali as
frequências que os pagamentos podem
acontecer, se são pagamentos de forma
semanais, quinzenais, trimestrais,
anuais, entre outros. O limite mínimo
que ele pode ter ali de cada uma das
cobranças em relação ao que foi acordado
e a data de inspiração dessa
autorização. Essa agenda aqui com todos
esses eh itens ali, elas são enviadas
ali pelo iniciador ao banco do do
recebedor, né? Eh, e aí o recebedor, o
banco do o banco do pagador, perdão,
banco do pagador no dia ali da
liquidação, ele tenta fazer ali um
pagamento e caso haja alguma falha nessa
liquidação, o iniciador aqui, né, ele
pode eh persistir a cobrança dessa falha
em três tentativas em um período de 7
dias. Tudo isso dentro das regras
definidas entre as partes. No final, a
gente tá gerando aqui menos fricção,
mais mais eficiência e muito mais
inteligência aqui para todos os lados.
Acho que da minha parte e eu encerro
aqui dando esse overview geral de tudo
aquilo que a gente vem implementando. E
aí eu passo a palavra aqui pro meu amigo
Zé, que vai trazer toda a parte das
especificações técnicas aqui e os
incrementos que a gente teve aqui nos
últimos tempos. C você.
>> Beleza.
Obrigado, Wendel. Eh, boa tarde,
pessoal. Boa tarde a todos. Essa aqui é
um pequeno resumo do que que a gente vai
tratar aqui nessa sessão, tá? Então, não
vou me estender muito aqui porque a
gente tem bastante pontos para tratar.
Já vou pedir pro Edel passar ali para
pro próximo slide.
Eh, bom, engatando no gancho que o
Wendel soltou agora, né, da explicação
um pouco do que é o Pixel automático,
aqui a gente trouxe o mecanismo que vai
ser utilizado pelo os usuários da PI de
vínculo de dispositivo para poder
autorizar os consentimentos de Pix
automático a partir do dispositivo
vinculado, né? Eh, a gente criou um
point novo de autorização de
consentimentos a partir desse vínculo,
né, desse dispositivo vinculado e
autorizado.
Ele tem os mesmos moldes, digamos assim,
do end point que já existe hoje, né?
onde a gente passa ali o identificador
do consentimento do PEF e no B a gente
manda as questões do Fidel ou sinais de
risco, justamente para poder ter eh o
comportamento mais mais
próximo possível da do que já tinha ali
para ser uma implementação mais mais
suave para todos os nossos
desenvolvedores aqui que consomem nossos
nossas APIs.
Eh, pode passar, Edu.
Eh, falando um pouco mais do Pixel
automático, eh, o Pixel automático em
si, ele também tem limite, né? A
definição do produto Pix automático, ela
possui características de limitar os
valores que vão ser transacionados ali
dentro daquele consentimento. Eh, e o a
API de vínculo também tem, né, os
limites para serem transacionados de
acordo com o vínculo de dispositivo.
Então, pra gente poder entender como que
funciona esse tratamento entre os
limites do vínculo e os limites do
consentimento ali e como que eles se
intercalam, como que eles trabalham em
conjunto, a gente criou esse esse esse
slidezinho aqui, tá? Então, basicamente,
né, a gente tem esses quatro
quadradinhos aqui, né? O primeiro
quadradinho amarelo ali, ele trata do
pagamento inicial avulso, que também é
conhecido como pagamento da adesão, que
é aquele primeiro pagamento que o
usuário necessariamente tem que realizar
para poder passar a consumir um serviço,
tá? Então, por exemplo, você vai assinar
um serviço de streaming qualquer para
você poder passar a assinado, você tem
que realizar um pagamento inicial e
depois vão vir as recorrências nos
próximos meses, de acordo com a
periodicidade do serviço. Então, falando
desse pagamento inicial abuso, primeiro
ponto é que o limite diário do vínculo é
aplicado, tá? Então, se a gente observar
as documentações do arranjo Pix com
relação ao pagamento inicial avulso, ele
é considerado como um Pix normal, tá?
Por ser considerado como um pix normal,
ele vai estar sujeito aos limites do
vínculo, assim como qualquer outro pix
normal que eu digo, é pix do arranjo Pix
padrão sem ser do arranjo Pix
automático, tá? Então, Pixes do arranjo
Pix, eles
eh obrigatoriamente precisam ter o
limite do vínculo validado, tá? Tá?
Então esse aqui ele acaba sendo um Pix
normal, pagamento inicial avulso. Eh,
então ele tem tanto o limite do diário
do vínculo aplicado, quanto o limite por
transação. E para computar esse
pagamento, você vai computar do limite
do arranjo pits do usuário, tá? Então
todos esses esse tratamento
diferenciado, ele tem um motivo que foi
justamente isso que eu mencionei, né?
apesar de estar dentro do fluxo de
contratação de um serviço de Pix
automático, ele é um Pix normal.
Já falando das recorrências, esses sim
são pagamentos recorrentes em si e eles
têm uma regra de tratamento do do
limite que é bem diferenciado, né? A
gente pode observar ali que o tanto o
limite diário quanto o limite por
transação não se aplicam para esse para
para esses pagamentos recorrentes, né?
Eh, já os limites do consentimento em si
se aplicam, né? Então, o próprio
consentimento, ele vai ter o maximum
variable amount ali, por exemplo, que é
o valor máximo permitido, definido pelo
usuário. E esse sim vai ter que ser
considerado para as transações, né? como
se pras recorrências a gente olhasse pro
consentimento de Pix automático,
enquanto que para pagamentos do dia a
dia a gente olha pros limites do vínculo
ali, tá? E ele também consome o limite
do arranjo Pix, do arranjo Pix
automático, tá? não é do arranjo Pix
padrão, entre aspas, aqui, porque não
existe um arranjo Pix padrão, mas é como
a gente comumente chama para diferenciar
entre eles.
Eh, acho que importante, né, isso é um
ponto super importante de fato, que é
uma um comportamento
que só existe aqui no Open F com relação
ao Pix automático, que é a falha do
pagamento inicialo, não rejeitar o
consentimento, tá? Então, se a gente
observar as jornadas, se eu não me
engano, a jornada três e quatro de
contratação que tá disposto no manual do
arranjo Pix, do arranjo Pix, elas
contemplam o pagamento inicial avulso,
tá? Só que caso esse pagamento inicial
avulso falhe, toda o todo o processo de
autorização falha, enquanto que aqui no
Open Finance não, a gente entende que o
ITP ele pode fornecer outros meios pro
usuário pagar essa esse primeiro
pagamento, né, que não seja ali durante
a transação online. Então a gente prevê
que essa é uma possibilidade. Logo, eh,
entendemos que o consentimento em si,
ele não precisa,
eh, ser rejeitado ou cancelado ou
revogado por nenhum motivo, uma vez que
existem outros fluxos que o próprio ITP
também pode oferecer para esse cliente
manter essa autorização e que o cliente
do ITP também não perca a autorização e
nem necessite que o usuário faça toda
uma jornada de novo para autorizar um
novo consentimento com um novo pagamento
inicial, tá?
Eh, importante também ressaltar que o
valor mínimo definido pelo recebedor não
é validado durante a autorização do
consentimento, tá? Então, o valor mínimo
ele a gente não deve validar se o valor
do vínculo eh os limites do vínculo tão
dentro do
valor mínimo definido pelo recebedor,
que é o mínimo variable amount, né? Ele
é um campo permitido pelo Pix automático
pro recebedor declarar dentro da
autorização que ele tá pedindo para
aquele cliente qual o valor mínimo que
aquela que aquela autorização tem que
permitir ele de cobrar, porque senão,
dependendo do eh isso deve servir como
um piso paraa definição do valor máximo
do usuário, né? Então, se o um serviço,
por exemplo, a cobrança mínima para ele
é R$ 15
e o usuário colocar um limite abaixo de
R$ 15, aquele serviço não tem como
cobrar. Logo, esse campo ele é a
indicação do recebedor para como eh o
usuário deve se comportar na hora de
setar o seu próprio limite, tá? Para que
não haja uma interferência entre o que o
recebedor define e o que o usuário
define, tá bom? Você pode passar, Ed.
>> Agora falando de algumas pequenas
mudanças que tivemos em alguns sinais de
riscos ali na especificação, né? Tivemos
três sinais de riscos que foram
ajustados. A gente vai entrar no detalhe
de quais quais foram no próximo slide,
mas nesse daqui o importante é a gente
observar que a mudança nesses três
sinais foram para todos. os três sinais
que a gente vai conversar logo logo e a
mudança foi a mesma. Então, eh, para
quem já consome as nossas APIs aqui,
entende o conceito de restrição. Para
quem não consome, eu vou eu vou explicar
um pouco aqui. As restrições que estão
presentes nas nossas especificações,
elas são condicionalidades que devem ser
satisfeitas para que determinado
comportamento que tá descrito na
restrição seja atendido ou não. Por
exemplo, esse aqui que tá em tela, a
gente tinha os sinais, a gente tinha
alguns sinais que possuíam a seguinte
restrição, sinais obrigatórios quando o
sistema operacional do usuário for
Android ou iOS.
Só que quando a gente vai falar de
desktop, eh, desktop é um um cara um
pouco fora da curva, digamos assim, né?
Porque o desktop ele ele geralmente roda
em aplicações web, né? onde a gente tem
maior adoção de ferramentas de desktop.
Hoje em dia, atualmente, pelo menos são
aplicações web, são PWI,
são ferramentas que acabam não
interagindo diretamente com o sistema
operacional, né? E é uma uma página que
tá em cima de um navegador e o navegador
que interage com o sistema. Então, nem
todas as funcionalidades que uma
aplicação nativa que tem acesso à API do
sistema operacional em si, o vai ser
possível de ser realizado a partir de um
navegador, tá? Então, a ideia era que
essa condicionalidade, essa restrição,
ela fosse alterada para dar essa visão
de que aplicações que são nativas para
Android ou iOS, que têm acesso a a as
APIs proprietárias do sistema
operacional,
elas sim obrigatoriamente vão precisar
enviar esses esses sinais. já eh
aplicações web que não t acesso a essa
interface direta, elas não precisariam
mais enviar, mesmo rodando em sistemas
operacionais Android ou iOS, tá?
Eh, além disso, também teve um outro
campo de sinal de risco que foi o Device
ID, que a gente também ajustou antes. A
a especificação exigia que fosse uma
combinação entre a chave de assinatura,
o identificador do dispositivo e a conta
do usuário na instituição, se eu não me
engano. E agora não, agora a gente
flexibilizou a a geração desse C vai
condicionando ele a garantia de
unicidade. Então, a gente pode ter
algísticos
diferenciados, propostos por cada
instituição para que gere-se um
identificador único, muito semelhante às
regras que a gente tem hoje do payment
ID, tá? Que é o identificador dos
pagamentos. O identificador dos
pagamentos ele não é um ID, não, ele é o
identificador que as instituições
escolhem a maneira de preencher. O que a
gente tem são os conjuntos de de regras
de de
caracteres que são permitidos. de
tamanho máximo, etc. Mas dentro desse
conjunto, a geração, ela pode ser feita
eh com algoritmo próprio, sem exigir
necessariamente que seja feito da
maneira que a gente tinha na versão
anterior, tá?
Além disso, também a gente teve um
pequeno esclarecimento sobre os sinais
coletados durante a autenticação cross
platform, né? Então, temos as questões
das pesquis aqui dos dispositivos
autenticadores, né? Eh, quando um
usuário vai utilizar um um dispositivo
externo para autenticar, né, externo ao
que ele tá utilizando para acessar o
canal, a gente achou por bem esclarecer
na documentação de onde que deve ser
coletado esse sinal, porque a gente
sempre fala dispositivo, dispositivo,
dispositivo, mas se tiverem dois
dispositivos ao mesmo tempo, qual é o
dispositivo? Tá? Então a ideia era
justamente que a gente esclarecesse é o
dispositivo utilizado pelo usuário para
acesso ao canal e não o dispositivo
autenticador móvel externo utilizado
para assinatura. Tá bom?
Edu, você pode passar pro próximo, por
favor.
Aqui são os sinais de risco, né? Eh, o
device ID ele teve a alteração que eu
mencionei da permissão de algoritmos
enquanto o rot device, o eled time since
boot e o screw brightness sofreram o
ajuste do sistema da condicionalidade de
envio, tá? Que é agora ises são
atrelados a aplicações nativas e não
mais ao sistema operacional em si.
Eh, como eu mencionei, volta lá do
rapidinho, por favor, só para finalizar.
Como eu mencionei, os sinais de risco,
eles vão usar o a a análise dos sinais
deve considerar o dispositivo de acesso
ao canal, não autenticador externo. E a
gente permanece ali com a possibilidade
de caso esse ou esses sinais em tela ou
qualquer outros sinais de risco em tela,
eh, apresentem um risco de fato para
motor de fraude da instituição ali
detentora, que ela retorne como um risco
e não permita a autorização desses
consentimentos, tá?
Pode passar.
>> Perfeito. Agora, eh, falando sobre as
melhorias de tratamento, a gente teve a
inclusão do status 504, né, em alguns
pontes que ainda não existiam. Eh, com
base no essa adição foi feita com base
no manual de API, tá? Resolução BCB
número 315, se eu não me engano, de maio
de 25.
Essa resolução definia que as
especificações do Open Finance devem
prever um um tempo máximo de timeout e
em casos de time out, um erro específico
deveria ser retornado, que é o erro 504.
Então, acabamos por suprir essa esse
requisito regulament regulatório, tá?
Eh, além disso, a gente também adicionou
um novo código de erro, Origin Fid
inválida. Esse novo código ele foi
adicionado no end point de authoriz de
retwing concepts authorized, tá? Eh, eh,
ele já tava descrito no header esse
comportamento, mas a gente tinha um uma
orientação diferente, uma vez que a
gente não tinha ainda esse erro bem
descrito. Então a gente orientava que
caso esse essa validação não tivesse
sucesso, que fosse retornado o risco,
mas agora a gente já tem um erro
específico para ser retornado em casos
onde a a avaliação do Origem enviado
dentro do client,
ela não bate com o Orig informado
durante o processo de DCR, DCM da
instituição iniciadora, tá? Além disso,
também falando um pouco da segurança
ali, nós criamos três eh criamos dois
novos fluxos, basicamente, né, de
autenticação.
É, antes todos os end points dessa PI,
elas tinham apenas o escopo payments
ali, porque era o único, o único escopo
que iria ter acesso a a esses produtos,
né, uma vez que os v a esse produto, uma
vez que os vínculos só estavam atrelados
a API e pagamentos nesse no primeiro
momento. Só que agora, como a gente tem
a possibilidade de ter o vínculo
atrelado a API e pagamentos automáticos,
logo a gente também precisa ter a
geração de escopos aderente aos escopos
da API e pagamentos automáticos, tá?
Então, se vocês observarem agora os
fluxos de clients, eles vão ter três
possibilidades. Vocês vão poder
solicitar tokens com escopo somente
payments, tokens com escopo somente
recuing payments e tokens com ambos os
escopos, tá? depende do que a ITP
oferece pro seu cliente e do que ela
acordou com o cliente na ponta que vai
usar aquele vínculo, tá? Então, por
exemplo, se o cliente tem a se a ITP
acordou com o cliente, aquele vínculo
vai ser utilizado apenas para realizar
pagamentos ou agendamentos únicos ou
recorrentes, ela não precisa do escopo
de pagamentos automáticos, o empers, tá?
Mas da mesma forma que se ela combinar
que aquele vínculo que ela criou vai ser
usado só para autorizar consentimentos
de Pix automático, ela já não vai mais
precisar do escopo de payments. Agora,
se é um vínculo de propósito geral, né,
digamos assim, pro que tá sendo possível
de ser realizado até o momento, eh, que
ele vai usar para autorizar ambos os
tipos de consentimento, então ela já
pode pedir a geração daquele token do do
enrollment, né, do token do enrollment
em si, com os escopos já das duas APIs
para que ela possa usar aquele mesmo
token para acessar os dois a as duas
aplicações, tá?
Eh, só um lembrete, né? Aqui, como a
gente tem essa validação de origem, tá?
Então, se
houver uma mudança dentro do software
statement da instituição com relação aos
valores que estão dentro desse arrei do
Origin, eh é necessária a realização de
um novo processo de registro ou uma
gestão do processo de registro ali, tá?
A partir de um DCR ou um DCM.
Eh, falando agora da edição do vínculo,
tá? Eh, basicamente ele é um processo
simples, né? Eh, ele é feito diretamente
no ambiente do detentor, tá? Eh, não é
possível realizar através do ITP. Logo
vocês não vão ver alterações no SUEGER
em si, na especificação técnica da JSR.
para um IPP fazer uma solicitação de
edição de parâmetros, o que ele pode
fazer é a solicitação de revogação, né,
que muda de o estado, mas é um não é uma
edição dos dos valores transacionados e
nem do prazo de inspiração, tá? Essas
funcionalidades são exclusivas do
ambiente do detentor e devem ser
realizados por lá, tá? E aqui a gente tá
falando que é o usuário pagador, tá? ele
vai poder editar os campos transaction
limit, daily limit ou expiration date
time e ou tá todos esses daí no ambiente
do detentor. E ali o tipo de alteração
são exemplos apenas, tá? Não é
exaustivo. Eh, vocês podem observar
exemplos exaustivos para isso dentro do
ambiente da área do desenvolvedor. Nós
temos uma página lá com bastante mais
informação do que tá aqui em tela, tá?
Então a gente sugere que vocês consumam.
Ela foi publicada recentemente junto da
especificação da versão estável e tá bé
descrito o que que pode ser feito, em
que cenário pode fazer. Eh, um pequena
descriçãozinha ali da alteração para
auxiliar no entendimento. Então,
recomendo que esse material seja
consumido para um entendimento mais
profundo de como isso aqui funciona, tá?
Mas é isso, é basicamente o usuário
editando os parâmetros, algum desses
três parâmetros ou os três ou dois dos
três no ambiente do detentor.
E esperamos ali que que
seja refletido, né? Inclusive nós eh
alteramos ou o web hook também para
refletir esse essas mudanças, né? Então,
se vocês observarem agora a P web Hook,
ela possui tipos de notificação que é
declarado dentro do campo event type,
né? Então nós temos o data changed e o
status changed. No caso de data changed,
o ITP sabe que ele deve olhar para um
desses três campos para validar o que
que mudou dentro deles. E no caso de de
status changed, ela ele sabe que ele tem
que olhar pro campos pro campo status
daquele recurso e identificar a mudança
do estado em si, tá?
Pode passar, Educa. Agora falando um
pouco da FVP, pessoal, esses daqui são
os testes da FVP.
que serão executados durante o piloto
para validação das jornadas, tá? Então,
como vocês podem observar aqui, nós
temos uma categorização entre os
produtos e o uma as categorizações
acabou não sendo a melhor palavra,
porque a gente são a coluna chamada
categorias, né? Mas a gente tem uma
separação entre produto, módulo e
categorias, tá? nos produtos. Aí vocês
podem observar a correlação com o que o
Eduardo falou lá no começo, né, que são
pagamentos imediatos e agendados e Pix
automático. Então nós temos alguns
módulos que são dedicados para cada um
desses segmentos de produtos, digamos
assim. Além disso, nós também temos a
categoria aonde esses testes se
encaixam. O que é essa categoria? É
basicamente uma maneira nossa de agrupar
esses testes para que a gente consiga
também tratá-los em lote. Por exemplo,
ó, precisamos conversar sobre os testes
de garantia de erro. Então, já temos um
subgrupo bem definido que engloba tanto
os dois testes ali, tanto os dois
produtos, né, tanto pagamentos quanto
pagamento quanto Pix automático. Então,
é mais assim para facilitar as nossas
conversas e as nossas interações, tá?
Eh, os testes de garantia de erro vocês
vão perceber que eles terminam em erro,
tá? Então, eh, a gente mapeou ali o que
seriam os erros mais comuns na nossa
visão, pelo menos, que poderiam ocorrer
durante o processo, paraa gente garantir
que esses erros mais comuns estão de
fato sendo tratados da maneira que devem
ser tratados. Assim como a jornada, a
gente tem as garantias de jornada, elas
são justamente os caminhos felizes, né?
Porque a gente também precisa garantir
que o caminho feliz funciona, né? Porque
o nosso principal objetivo é que o
caminho feliz funcione, né? Os
tratamentos de erro eles são importantes
para dar visibilidade, né? dado que nós
somos um ecossistema, então os ITPs
precisam ter visibilidade do que de fato
aconteceu pro usuário poder também ter
essa mesma visibilidade que ele. Então é
isso que a gente tá tentando garantir
aqui, tá? Que us
consiga, mas se ele não conseguir, que
ele tenha uma informação clara do porque
ele não conseguiu quando isso for
permitido também, né? Porque existem
sinais, existem cenários aonde sinais de
riscos impedem eh esse prosseguir com
essas transações e a detentora não
precisa dizer exatamente qual sinal que
deu um problema, tá? Até porque senão
ela seria facilmente manipulável, não é
a nossa ideia aqui. Tá bom, Edu, você
pode ir pro próximo?
Não sei se tem um próximo. Ah, tá, tem,
né? Eh, coloquei esse último aqui só pra
gente fazer uma recapitulação antes de
eu passar pro pro próximo apresentador,
pessoal. Mas isso aqui é basicamente o
que que a gente vai olhar da
especificação, né? Vai olhar muito
criteriosamente
paraa autorização dos consentimentos de
fixo automático, o fluxo completo via
dispositivo vinculado, tanto da
realização da tanto da criação do
consentimento, né? Essa criação não
depende do vínculo, mas é importante
também que funcione. Eh, então, tanto da
criação do consentimento, quanto da
autorização desse consentimento a partir
do dispositivo vinculado, quanto do da
do pedido de agendamento de um
pagamento, quanto da liquidação desse
pagamento também que foi agendado e a
gente também vai tentar garantir o
pagamento inicial abuso, tá? O pagamento
da adesão. Também tem a questão das
coletas de sinais de risco de diferentes
plataformas. A validação dos limites
diferenciados também é um ponto super
importante aqui, tá? Então temos testes
também da FBP para esse ponto aqui, pra
gente garantir que os limites estão
sendo respeitados.
Eh, os tratamentos de timeouts também
foram adicionados e vão ser pontos que
vão ser validados também. E o fluxo de
geração de tokens de acesso, tá? Esse é
um ponto que que ele é importante dos
iniciadores passarem a se adequar ali.
Eh, vocês vão observar que existem
fluxos que permaneceram com o mesmo
escopo de antigamente, mas tiveram
apenas o nome descrito numa
especificação alterado, tá? Então, se
vocês precisarem fazer algum ajuste
interno, peço que observem isso, né?
Quem tiver integrações de de automação
com a nossa especificação também talvez
precisem prever esses outros fluxos ali,
tá? Mas é basicamente isso. E um pequeno
disclaimer, né? O 504 ele vai ser alvo
também ali do time de monitoramento
aqui, né, da associação, porque Timeout
indica bastante sobre a saúde do
ecossistema e a partir da inclusão dele,
nós vamos passar também a monitorar esse
campo, esse esse código de resposta.
Bom, eu acho que era isso do meu lado.
Agora eu passo a palavra aqui pro time
de UEX, acredito que seja Débora que vai
apresentar. Certo,
>> certo, Zé.
>> Certo.
>> Boa tarde.
>> Fica à vontade, Débora. Que te só.
>> Obrigada. Boa tarde, pessoal. Meu nome é
Débora, sou aqui do time de XD DTO e vou
falar para vocês agora tangibilizar essa
parte técnica em experiência do usuário.
Eh, então, como a gente comentou aqui
já, né, um dos nomes que esse produto tá
recebendo é o Pix por biometria. E um
resumo aqui do que a gente vai falar
hoje, né? A gente vai passar pelas
jornadas de pagamento que são Pix
imediato, Pix agendado e Pix automático.
Vamos falar sobre a jornada de
vinculação de conta, né, que é um
pré-requisito para que esses pagamentos
ocorram. Vamos falar sobre alguns
exemplos de erro, a gestão de contas
vinculadas e as boas práticas para
desktop. A gente organizou de um jeito
que vocês vão conseguir ver eh o que
exatamente vai ser monitorado no piloto.
Então, vamos lá. Eh, então primeiro, a
primeira jornada aqui do Pix por
biometria é o Pix imediato. Então,
imaginando aqui que o usuário tá ali no
e-commerce, né? Então, ele vai comprar
uma televisão, por exemplo, ele
seleciona o pagamento por Pix, ele já
fez uma vinculação de conta, seleciona o
vínculo de conta que ele quer usar. Por
exemplo, aqui a instituição Bratec,
visualiza as informações desse
pagamento, né? todas as informações que
já são disponíveis no já estão
disponíveis no guia do arranjo. Então, o
valor, a data, né, no caso de um
pagamento imediato seria a data de hoje.
Eh, a iniciador, enfim, eh, a forma de
pagamento, precisa receber a informação
de que ele precisa ter saldo e limite
disponível na conta selecionada para que
esse pagamento seja efetivado. Ele
confirma e pode confirmar essa transação
através da sua biometria, né? seja um
face, senha, enfim, eh a biometria que
ele utiliza, que ele cadastrou na
vinculação de conta que ele já fez
previamente. E aí, uma vez esse
pagamento confirmado, ele vê as
informações dessa efetivação e pode
acessar eh esse comprovante ali também
na área de gestão.
Eh, pode passar isso. Obrigada, Eduardo.
Eh, o Pix agendado é muito similar ao
Pix imediato, né? diferença que que o
usuário vai poder agendar esse
pagamento. Então, a gente simulou uma
jornada aqui numa ITP que também é uma
detentora. Então, o usuário acessa ali a
área Pix, seleciona a opção de pagar com
outro banco e nesse momento que ele
entra na jornada eh sem
redirecionamento, né? Então ele
seleciona aqui o vínculo também com a
Bratec e coloca que quer pagar com a
chave Pix, insere a chave Pix, visualiza
aqui o recebedor, seleciona o valor.
Pode passar, por favor, dupla.
Obrigada. Eh, antes de confirmar, ele
edita a data. Então, a data por padrão é
a data eh do dia, né? Nesse momento, ele
pode aqui alterar essa data. Então, se
ele quiser eh repetir essa
transferência, né, fazer ali pagamentos
recorrentes, ele pode alterar essa
transferência, definir a data que essa
autorização vai terminar, eh visualiza
aqui o resumo da do pagamento novamente
e precisa, de novo receber informação
sobre a necessidade de saldo limite
quando os pagamentos forem efetivados,
né? Então, não há validação de saldo
limite nesse momento, apenas quando os
pagamentos forem agendados, eh, quando
forem liquidados. Então, só um
minutinho, Edu. Ainda não. Isso. Então,
aqui ele vai mais uma vez eh utilizar a
chave de segurança que ele já cadastrou
lá no momento da vinculação de conta.
Vai se autenticar e vai ver aqui a
efetivação do agendamento, né? Mais uma
vez a informação de que ele precisa ter
saldo limite quando esses pagamentos
forem de fato liquidados. Prontinho.
Pode passar, Edu.
Obrigada. E aí o último pagamento que a
gente tem disponível paraa JSR é o
pagamento com Pix automático. Então
imaginando aqui que o usuário tá numa
plataforma de streaming, né? Vai fazer
assinatura aqui de um streaming. Ele
seleciona o pagamento com Pix
automático. Mais uma vez seleciona o
vínculo, visualiza ali as informações
dessa autorização, clica em confirmar,
né? coloca a chave eh de autenticação
que ele cadastrou e mais uma vez
visualiza aqui o resumo eh dessa
autorização de pagamento e pode ver o
comprovante na área de gestão.
Para realizar todos esses pagamentos
dessa forma simples, né, com biometria,
sem precisar sair do aplicativo, fazer
tudo na ITP, o usuário precisa antes ter
criado um vínculo de conta. E aí a gente
entra aqui na jornada de vinculação de
conta através do Pix automático. Então,
supondo mais uma vez que o usuário tá
ali na plataforma de streaming e decide
pagar com Pix automático, se ele não tem
um vínculo de conta e a ITP quer
oferecer esse serviço, nesse momento,
ela oferta pro usuário a possibilidade
do pagamento com Pix por biometria.
Então ela informa pro usuário para que
que é esse pag, para que que é esse
vínculo de conta, né? Então ele vai ser
utilizado ali para fazer os pagamentos
futuros. E importante dizer que é feito
com a segurança do OpenF. Se o usuário
aceitar, ele clica em conectar minha
conta. Nesse momento, ele seleciona a
conta que ele quer utilizar, né, a
instituição que ele vai utilizar. Tá?
Então, nesse caso, ele selecionou a
Bratec e aí a gente vai informar para
ele que ele vai ser direcionado pra
instituição detentora para continuar
esse vínculo. Então é importante dizer
aqui, informar pro usuário que ele tem
15 minutos para finalizar essa
transação. Então isso também vai ser
monitorado ali no piloto. Quando ele
chega na detentora, ele vai se
autenticar ali também vai logar, né,
conforme os padrões da instituição
detentora e vai visualizar os o resumo,
né, revisar as informações desse vínculo
de conta. Nesse momento, se ele tiver
mais de uma conta nessa detentora,
suponhamos ali uma conta corrente, uma
conta poupança, se as duas contas
estiverem aptas, ele pode aditar essa
conta, né, e selecionar uma outra
diferente da que ele já selecionou. Ele
pode também alterar o prazo dessa
autorização, né, que por padrão é 5
anos, mas ele pode mudar inclusive para
prazo indeterminado e pode alterar os
limites aqui, garantindo que o limite
diário sempre seja maior que o limite
por transação. Uma vez que ele
configurou, né, configurou também o nome
do dispositivo, caso o ITP, a detentora,
eh, possibilite isso, ele confirma e aí
é informado que vai voltar pra ITP.
Pode passar, por favor.
E uma vez que ele volta paraa ITP, ele
vai criar ali a sua chave, que é a chave
que ele vai utilizar para autorizar
esses pagamentos por biometria sem
precisar sair da ITP. Então, uma vez
criada essa chave, ele é informado sobre
a efetivação do vínculo, né? O
Pixpometria tá ativado e ele pode já
fazer os seus pagamentos e pode também
cancelar essa autorização na área de
gestão a qualquer momento. E aí, como
ele iniciou essa jornada através de um
pagamento, né, um Pix automático ali,
uma autorização, a gente oferece para
ele a opção de retornar para essa
jornada e finalizar o seu pedido. Então
ele clica em continuar. Pode passar,
Edu, por favor.
Ele clica em continuar, né? Voltando
aqui pra tela da informação de que o
vínculo foi efetivado e retorna pro pra
jornada de pagamento com Pix automático.
Então ele confirma o pagamento, né, que
ele já tinha iniciado, visualiza aqui os
dados, confirma, já usa a chave que ele
acabou de criar ali no vínculo de conta,
né, sua biometria, e vê o a autorização
confirmada e efetivada com todos os
dados eh previstos ali no guia.
pode passar e tu
e aí alguns erros que podem ocorrer, né,
que a gente eh vai testar ali também no
piloto, são erros, por exemplo, na na
parte do direcionamento e do
redirecionamento. Então, se ocorrer
alguma falha, né, tanto na ITP quanto na
detentora que impeçam o usuário de
transitar entre as instituições, ele
precisa receber uma tela com uma
mensagem clara para que ele saiba o que
que ele vai fazer, né? se ele vai tentar
de novo na ITP ou se, né, ele precisa
sair da detentora, voltar paraa ITP,
enfim, a gente precisa informar pro
usuário o que que aconteceu.
Eh, pode passar, por favor. Isso. E aí,
falando sobre a gestão, né, a gente já
sabe que na ITP não houve mudança na
parte de gestão, então os requisitos
continuam os mesmos. O usuário precisa
ter acesso à área de gestão de contas
vinculadas. Ao acessar um vínculo
específico, ele precisa ver ali qual é a
instituição detentora. eh associada à
aquele vínculo e visualizar todos os
dados que ele eh inseriu quando ele
criou aquele vínculo. O que ele pode
fazer na ITP é cancelar. É a única eh
alteração, né? A única ação que ele tem
com relação ao vínculo na detentora.
Pode passar, por favor. Obrigada. ele
também vai poder acessar esse vínculo de
conta, né, quando ele eh quando ele
clicar ali em um vínculo ativo ou
inativo, enfim, ele precisa ver o status
desse vínculo, né, qual é a instituição
iniciadora que está também associada a
esse vínculo. E aqui ele tem outras
opções, como o Zé e o Wendel já falaram,
que são as edições. Então ele não
precisa revogar o vínculo mais para
poder criar um vínculo novo. pode editar
aqui o prazo da autorização e pode
alterar os limites também, sempre
respeitando eh o teto, né? Enfim, o o da
transação sempre tem que ser menor que o
limite diário. Eh, além disso, ele
também pode cancelar esse vínculo na
detentora. Pode passar, por favor, Edu.
E aí, para finalizar, a gente tem a
questão do desktop, né? Todos os
requisitos eles se aplicam tanto paraa
experiência mobile quanto paraa
experiência desktop. A gente não tem
telas específicas para vínculo de conta,
né, para essas jornadas para desktop,
mas a gente tem uma página muito
importante, muito útil ali no guia,
falando sobre as boas práticas para
desktop, para garantir que a experiência
seja muito similar. Então, todas as
informações que estão no mobile precisam
estar no desktop, adaptadas ao tamanho
do dispositivo para que o usuário tenha
uma experiência fluida, né, uma jornada
simples, sem ficção, eh, e, enfim,
garanta, a gente garanta o sucesso dessa
jornada. Muito importante também lembrar
que a gente vai tá avaliando telas
adicionais, né, a jornada. Então, eh, é
essencial que o usuário consiga cumprir
essa jornada, finalizar essa jornada do
jeito que a gente idealizou, né? Então,
sem oferta de produtos, né, ou de
crédito, sem pedir confirmação extra,
né? Então, por exemplo, o usuário tá ali
na detentora, eh, e ele já se
autenticou, né? já já decidiu ali na ITP
que ele quer criar esse vínculo. A
detentora não pode criar uma barreira,
por exemplo, falando: "Ah, tem certeza
que quer continuar, né, que quer fazer
esse vínculo". Então, a jornada tem que
ser fluida, sempre garantindo a
segurança eh e a informação clara para
que o usuário saiba que que essa jornada
tem a segurança do Openfance, não gere
dúvidas nele. Então é isso, muito
obrigada e encerro aqui a minha parte.
Boa tarde, pessoal. Eh, vou falar um
pouco aqui da certificação Fidon, né? Ã,
acho que como todo mundo já passou um
pouco aqui na apresentação, o a jornada
de sem direcionamento acontece em duas
etapas, né? O vínculo do dispositivo e
depois o comando dos pagamentos que
acontecem posteriormente, né?
E a gente quando fez esse fluxo
preocupou muito em segurança, né? A
gente precisava manter o alto padrão de
segurança que já existe no Open Finance
com a adoção do FAP, que é o fluxo com
redirecionamento, com redirecionamento,
né? E aqui a gente introduzindo fluxo
sem direcionamento, como isso iria
funcionar, né? Então, nesse mecanismo,
durante o vínculo do dispositivo, é
feita uma jornada FAP tradicional, né,
com o redirecionamento em que o vínculo
é criado e embutido uma nova tecnologia
para possibilitar que as as aprovações
do pagamento ocorram de forma
simplificada, sem precisar do
redirecionamento, acontece apenas com
sinais, né, que são capturados ali no
dispositivo do participante, né, o Fidel
é a tecnologia que habilita isso, né? E
da mesma forma que a gente é bastante
rigoroso
com a certificação de segurança FAP, que
a gente exige que todo mundo se
certifique para poder operar no
ecossistema, aqui também com FID a gente
exige que os servidores Fido, né, ali
dos detentores de conta também sejam
servidores certificados, né? Então aqui
eu quero passar com vocês quem precisa
da certificação, eh, quem precisa
realizar de fato o processo de
certificação, né? Qual como funciona um
pouco desse processo, falar do custo,
né? E e depois como vocês participantes
comprovam pro ecossistema que fizeram
essa certificação.
Então, quem precisa da certificação?
Todo detentor, né, que for implementar o
fluxo JSR. Então todos eles vão precisar
de um autorization server que implemente
o file e esse servidor precisa estar
certificado, tá? Agora não significa que
todo mundo vai precisar ir lá na F
Alliance e fazer a certificação do seu
servidor, né? Na verdade, a gente aqui,
diferente do FAP que a gente exige que
todo mundo de fato se certifique, a
gente está possibilitando que quem
contratar uma ferramenta
ou solução já certificada, essa
certificação é válida. as instituições
que fizerem o seu próprio servidor Fidel
ou customizaram o servidor FID
existente, né, modificando o core dele
com mudanças significativas ali, esses
sim precisam ir na F Al própria
certificação, porque eles ã
precisam, vocês precisam desse servidor
certificado, né? E qual é a
certificação, né? Certificação Fido 2 do
tipo server é o servidor que vai
funcionar. E essa certificação F ela tem
vários níveis, né? E dependendo do tipo
de segurança de se você funciona com
dispositivos A ou B, se você tá
certificando dispositivo, né? O nível de
certificação aqui que a gente tá
exigindo é o mais básico, que é o
certificação funcional.
Poder avançar, não.
>> Eh, e como funciona o processo de
certificação da FL, tá? Então, tudo
começa de forma muito similar a a do
FAP, né? você começa fazendo uma
validação própria, né? Você baixa a
ferramenta que eles disponibilizam, faz
o download dela, instala ela, né?
Executa os testes localmente.
E quando você terminar com sucesso todos
os testes e você terminar tudo com
sucesso, tá? Não pode ter erros, você
vai passar para uma segunda etapa que
chama teste de interoperabilidade, tá?
Esse teste de interoperabilidade é um é
uma sala que ele eles colocam todo mundo
que estão tentando se certificar, né? Ã,
para fazerem testes entre si, para
garantir que o servidor consegue se
comunicar ou dispositivo, depende do que
você tá certificando. Aqui no nosso
caso, o servidor, né? Consegue se
comunicar corretamente, está
interoperável com qualquer servidor, né,
que esteja ali, né? Uma vez esses testes
sendo realizados, a certificação é
emitida, né? E daí vão ter passes
possíveis que ah, olha, eu quero eh usar
a marca F, divulgar ela, então vocês têm
que preencher algum termo, algumas
coisas nesse sentido, tá? Mas os três
passos relevantes são esses, né? Você
fazer o auto teste, agendar e executar o
teste de interoperabilidade e daí emitir
o certificado.
Se puder avançar aí, por favor.
Eh, bom, como que é a autovaliação de
conformidade, tá? Então, como eu falei,
você, o próprio participante realiza,
né? H, uma vez que o teste foi executado
com sucesso pela própria ferramenta,
você submete o teste para file Alliance,
né? E tem um prazo que para você poder
fazer o teste de interoperabilidade,
você tem que ter terminado essa auto eh
avaliação 14 dias antes, tá? Então eles
pedem esse prazo de antecedência, né?
Ah, é exigido pro agendamento que todos
os testes tenham sido feitos com
sucesso, né? incluindo serviços de
consulta, metadados ali, que serviços
que eles disponibilizam, tá? Ã, e para
usar essa ferramenta, você precisa estar
cadastrado na FA Lance, um cadastro que
você submete para eles, né, eu desejo, e
um dia útil eles aprovam esse cadastro,
daí você consegue fazer o download da
ferramenta, tá? Então, eh, no próprio
site da Fest Balance tem todo o caminho
ali que vocês vão usar, tá?
Eh,
bom, eu acho que que o título ficou
errado, né? O o agendamento do teste ah
de interoperabilidade, tá? Então, como
eu falei, eles querem garantir que a sua
solução funciona com qualquer outro
servidor FID ou dispositivo Fido, né?
Então eles montam salas, né? Um fórum em
que os participantes vão testar ali
entre eles, tá? Eh,
o teste é realizado remotamente, tá?
Essa sala é remota. Eh,
e eles disponibilizam uma semana ali
antes um pré-teste, né, que os
participantes ou que vão participar
desse fórum podem entrar já começar
alguns testes entre si, preparar
ambiente, o que for necessário para no
dia ter sucesso, tá? Ã, esse é um evento
que ele tem datas definidas, né? Então,
a Fal Alliance geralmente faz esse esse
evento a cada 3 meses, né? Ã, mas se não
tiver quórum, ele é adiado pro próximo
evento, tá? O que pro nosso ecossistema
é um problema, né? Essas datas fixas
geralmente não funcionam bem, tá? No
casa, com o geralmente prazo ou desejo
que os participantes têm aqui, né? Eles
e nisso, né? Eles disponibilizam uma
alternativa que é o teste sob demanda,
né? Então eles têm algumas regras sobre
esse teste sobre demanda eh pode ser
agendado pela própria FA Lance. Eles
distribu eles têm um formulário que é
preenchido e vocês pedem esses testes
sobre demanda, né? Geralmente eles
recomendam juntar um grupo, né, para
facilitar e e então vamos combinar entre
algumas instituições aqui fazer esse
teste em tal data, tá? Uma
possibilidade. Isso gera uma economia
porque esse teste sobre demanda, ele tem
um custo, né, ã, adicional, tá? E se
juntar o grupo vai pagar um valor só da
taxa e o grupo pode dividir, tá? Mas se
não tiver um grupo, for fazer sozinho
esses testes também é possível, né?
H, o cronograma desses testes de
interoperabilidade marcados pela F
Alliance não foi divulgado ainda para
2026, né? O último o último teste
aconteceu em dezembro de 2025.
Então, deveria acontecer ali para março
o próximo teste conjunto ali, tá? Mas
como não foi divulgado, né? Eh, e a
gente tem um cronograma aqui bastante
apertado, eh, talvez o caminho seja de
fato fazer o teste sobre demanda, tá?
ã falando um pouco de custos, tá? Ah,
a certificação ela tem um custo, tá? Da
mesma forma de FAP ali, tá? Um custo em
dólar, tá? Eles dividem da mesma forma,
tem tem os membros, né? Você pode ser
uma instituição que é membro da Fliance,
você paga uma taxa anual para ser
membro, né? Nesses casos tem um desconto
da certificação, né? Então, se você for
certificar muitos servidores ou muitos
dispositivos, geralmente vale a pena ser
membro. Não acredito que não seja o caso
da maioria dos nossos participantes, né?
Para não membros, o custo é um pouco
maior, né? Eh, custa 90.000, ó, $9.000
por certificação, tá? Então, uma
certificação custa custa $9.000. Existe
uma opção que eles chamam de
certificação derivativa, né? mas que ela
exige hã que
o fornecedor do autorization server
esteja em conjunto com você na
certificação, né? Na verdade, você tá
contratando um um servidor de
autorização que que é certificado, mas
vai mexer no cor dele descaracterizando
ele, então ele deixa de ser certificado.
Ã, ou tem alguma questão do seu
ambiente, né? E e essa certificação
derivativa é uma extensão, né, de uma de
uma certificação anterior que até essa
aqui, olha, não, essa implementação
também é certificada, ela é bem mais
barata, né? Mas precisa ter um servidor
já certificado com o e atestado ali na
implementação com o fornecedor, tá? O
caso comum aqui, né, provavelmente vai
ser o pagamento dos $9.000 para
certificação, tá? E opcionalmente, né,
quem quiser pode adotar o uso do celo
Fido, né, isso eh tem só um uns termos
para serem combinados ali com a FA
Lines, não é nada demais, tá? E também
tem essa opção para você aparecer no
site, para você poder usar também no seu
site que você tem esse selo.
Ã,
uma vez que você está certificado, você
precisa comunicar ao ecossistema essa
certificação, tá?
Então, na mesma forma que a gente faz
pro FAP ali no diretório do
participantes, na aba de certificação do
do servidor de autorização, né, você vai
ter a opção de cadastrar outros perfis
de de segurança ali, né? E o file do
server é um deles, né? E vocês vão
precisar preencher uma URL dizendo qual
é a sua certificação. Se você fez uma
certificação própria, a sua certificação
vai aparecer ali num na lista de
servidores
certificados da FLI, né? Então você usa
a URL para essa lista ali do F certified
products, né? Se você usar um servidor
de terceiro certificado,
você pode pôr a URL do produto que você
tá utilizando. Tem que ser o site do
produto da transition server, mostrando
que aquele produto é um file do server.
H certificado, tá? Então no diretório
vocês precisam registrar que estão
devidamente certificados, tá?
Eh avançou,
a gente tem alguma questão aqui, tá? Ã,
no FAP a Associação Open Finance fez uma
relação de parceria, né, com a Open
Connect. A gente é sustain.
Hã, então tem todo um uma conversa sobre
volumes de certificações, planejamento
de certificações, descontos que acontece
com a a Open Connect. Com a Fid Alliance
a gente não tem isso, tá? No caso do da
certificação Fidel os participantes
devem buscar por conta própria essa
certificação, tá? A gente não intermedia
nenhum processo, nem de solicitação, de
agendamento, pagamento, emissão de
certificado, nem nada, tá? A nossa única
exigência aqui da associação é que vocês
tenham um servidor certificado. Como
vocês vão obter esse servidor
certificado? Eh, ou como vocês vão fazer
esse processo de certificação? Eh, eh, é
com vocês, tá? O participante, tá?
Então, ã, obviamente a gente apoia em
algo que precisar, mas a gente não faz o
processo por vocês, tá,
pessoal? É isso que eu queria falar de
certificação.
Acho que vamos pros próximos passos
aqui, né?
>> Boa, Paulo. Obrigado.
Eh, tô vendo duas mãozinhas levantadas,
mas peço para que vocês esperem um
pouquinho e daqui a pouco a gente entra
para dúvidas, tá, pessoal?
Eh, vou continuar aqui falando sobre o
cronograma do piloto também, os próximos
passos, ou seja, o que que a gente
espera eh desse piloto, como que deve
funcionar o processo de restrição de
usuários, né, restrição de recursos e
habilitação de usuários para testes,
como que vai ser o acompanhamento que a
gente aqui como associação Openfance vai
fazer junto aos participantes, tá? Em
linhas gerais, eu queria reforçar aqui a
data. Então, o piloto oficialmente
inicia em 6/02/2026.
E o Go Live dessa funcionalidade tá
previsto aqui para 22 de abril. Vão ser
75 dias em que a gente vai tá fazendo,
né, os testes da maneira mais exaustiva
que possível.
Então, em termos de cronograma, pessoal,
eh esse também é um cronograma que a
gente já divulgou anteriormente. A gente
tá ainda numa etapa, né, de planejamento
desse piloto antes que ele inicie. Eh, o
workshop tá acontecendo hoje, dia 23.
eh, no dia 30 de janeiro, no final da
semana que vem, eh, a gente tem preview
aqui duas datas importantes. A primeira
é a data limite para abertura de contas.
Que que é isso? Eh, durante o piloto, a
associação Open Finance, ela vai
executar testes para as instituições,
né? Só que para que ela faça isso, o
nosso fornecedor precisa ter uma conta
aberta com essas instituições. A relação
de contas abertas do fornecedor, ela tá
disponível já no painel, no no
quicksite. Então depois a gente
compartilha também com vocês. Caso
alguma instituição eh não tenha ainda
viabilizado uma conta aberta com
fornecedor, ela terá que executar esses
testes por conta própria. E aí, se
alguém quiser ainda aproveitar essa
próxima semana para tentar contatar o
fornecedor e tentar viabilizar uma conta
para que ele execute o teste por vocês,
a gente pede que isso aconteça até o dia
30 de janeiro, porque na semana seguinte
vai ser quando a gente vai fechar as
volumetrias exatas, né, de de dos grupos
de teste. Então, quando a gente 30 de
janeiro é também a data em que as ITPs
vão ter que eh reportar aqui paraa
associação o seu interesse em participar
do piloto. Então, se uma ITP já oferta
JSR, ela não precisa participar desse
piloto, a menos que ela deseje ofertar
melhor, se uma ETP já oferta pagamentos,
né, imediatos agendados via JCR, ela não
precisa participar desse piloto a menos
que ela queira ofertar esse produto
também em ambiente desktop. Se quiser
ofertar em desktop, ela precisa abrir um
ticket e a gente vai fazer as
validações. Eh, se uma ITP deseja
ofertar o Pix automático, seja em
mobile, seja em desktop, vai ter que
abrir um ticket também pra gente
conseguir fazer eh esse acompanhamento,
tá bom? E aí eu peço aqui que o ticket
seja que seja aberto a um ticket por,
né, por interesse de participação, então
produto mais canal, no caso das ITPs,
até o dia 30 de janeiro, tá bom? O
ticket ele pode ser aberto ali na
categoria de processo de onboard,
interesse de participação, iniciadora.
Eh, isso também tá ali no portal do
desenvolvedor.
No dia 6 de fevereiro é a data
regulatória de início desse piloto e é
também o marco, né? O piloto ele vai
começar com a publicação das API no
diretório de participantes, tá bom? Eh,
e aí aqui tem uma observação que eu
queria fazer com todos vocês. Eh, isso
também era algo que tava ali na
comunicação que a gente enviou
anteriormente. Eh, novos entrantes estão
autorizados a antecipar a publicação da
API, né? Então, a partir do dia 2 de
fevereiro. Por quê? Porque a gente
gostaria de utilizar as instituições
para poder homologar FVP e a gente ter
mais segurança de que no início do
piloto a ferramenta, né, todos os testes
já vão ter sido aqui validados em
produção pela estrutura, né, e a gente
depende, obviamente, de uma instituição
eh que já tenha, já esteja em produção.
O caso de instituições que já possuem a
API de vínculo do dispositivo no
diretório hoje e que vão precisar
atualizar a versão dela, eh essa
antecipação ela não tá autorizada porque
esse é um versionamento minor, então tem
quebra de contrato. Então novos
entrantes, caso queiram se voluntariar,
antecipar para que a gente possa
utilizá-los a para fim de homologação da
FVP, eh a gente pede que, né, que
antecipem aí a publicação a partir do
dia 2 de fevereiro. quem já opera, essa
autorização, ela não existe, tá bom? No
entanto, para quem já opera o JSR
também, isso vai valer pros novos
entantes, a gente recomenda, né, que
quem for publicar ali no dia 6 de
fevereiro, que é a data regulatória, se
possível, que faça a publicação da API
até o meio-dia, para que a gente possa
na parte da tarde também já iniciar a
homologação da FVP. Então vocês veem que
a partir eh do dia 9 é onde iniciam os
testes aqui eh em produção. Então do dia
9 até o dia 11 é uma data que a gente já
previu em cronograma para fazer essa
homologação da ferramenta. O que
significa que a gente definiu
internamente aqui os nossos critérios de
qualidade, que as instituições não serão
notificadas durante esse período de
homologação da FVP, a menos que a gente
tenha aqui confiança, né, de que os
testes estão maduros o suficiente para
isso. É, e aí a partir, né, e aí então
as execuções com todo mundo começa a
partir do dia 9, né, a gente já espera
que todo mundo tenha realizado a
publicação da API eh na data regulatória
do dia 6. A partir do dia 9, a gente
começa os testes e a gente vai segmentar
esses testes de acordo com as categorias
que o Zé comentou anteriormente. Então a
gente separou aqui em dois bloquinhos.
Primeiro o bloquinho de vínculos mais
pagamentos e depois o bloquinho de
vínculo mais Pix automático. Então até o
dia 27 de fevereiro é quando a gente vai
estar fazendo teste de
interoperabilidade para todo mundo. Esse
teste eh vai tá sendo executado pela
associação para todas as instituições
que a gente tem conta aberta. Quem a
gente não tem conta aberta vai ter que
executar esse teste com data limite em
27 de fevereiro. Se chegar nessa data e
a gente eh, né, e a gente acompanhar que
alguma instituição não executou com
sucesso o teste, essa instituição vai
ser notificada pelo Service Desk, tá
bom? Eh, a gente vai retestar o teste de
interoperabilidade com redirecionamento
via desktop, é, no dia 9 de março pra
gente também garantir, né, que jornadas
iniciadas em desktop sejam concluídas
ali com sucesso pelas detentoras, tá
bom? Eh, e aí a gente tem aqui os outros
bloquinhos, tá? Então, garantia de
jornada, que é o cenário feliz do Zé, eh
ele também vai ser executado eh para as
detentoras entre dia 9 e 27 de
fevereiro. E o teste de garantia de
erros, ele vai ser executado até o dia 6
de março, tá bom? e também um teste de
longa duração, que é quando a gente
consegue validar ali o pagamento
integralmente.
Eh, paraas instituições em que a gente
for fazer eh o monitoramento da jornada
e que a gente vai testar a edição do
vínculo, a gente também vai ter aqui uma
data onde a gente vai fazer um teste na
FVP para ver se o comportamento tá
funcional, tá aderente após essa edição
do vínculo. E esse teste na FVP vai
acontecer ali no final de março, eh,
depois do nosso prazo de validação de
UX. Eh, então a gente começa testando o
vínculo mais pagamentos imediatos e
agendados. Em seguida, a gente vai
testar ali os testes do Pix automático,
seguindo essa mesma ordem. Então,
garantia de jornada primeiro, que é o
cenário feliz, garantia de erros e, por
fim, garantia eh ali no teste de longa
duração. E a gente espera que todos
esses testes aqui eh eles ocorram até o
dia 13 de março. Então, ali no meio do
piloto, a gente já quer ter feito a
primeira rodada de testes para todas as
instituições que a gente tem conta
aberta. E é também a data que todas as
instituições que a gente não tem conta
aberta vão ter que executar por conta
própria. Eh,
ainda em fevereiro a gente começa também
as validações de ex do das ITPs, tá bom?
Então, todo ITP que queira participar,
seja ofertando pagamentos desktop ou
Pixático Desktop ou Pixático mobile, vai
ter vai ter que declarar pr gente até o
dia 30 e até o final de fevereiro a
gente espera conseguir fazer a execução
eh dos testes de jornada para as ITPs. E
aí no início de março, durante as duas
primeiras semanas, a gente vai estar
validando ali eh as jornadas das
detentoras, tá bom? Então, metade de
março a gente termina essas validações
das detentoras e em seguida a gente faz
ali os testes via FVP de após a edição
do Vinc.
A gente previu nesse cronograma também
alguns marcos para o engajamento
bilateral, né? Então, eh, como eu também
comentei anteriormente, um dos nossos
critérios são os testes bilaterais entre
as instituições. Esses testes, todos
eles vão ocorrer com restrição de
usuários. Eh, e aí a volumetria vai
depender, né, do cenário de cada
instituição, mas a gente previu aqui
alguns marcos percentuais, tá? Então,
marcos de 30%, de 50%, de 80% desses
testes bilaterais para que a gente
consiga chegar no final do piloto e todo
mundo tá 100% em todos os nossos
critérios. E a gente também previu aqui
eh um período de sala de guerra e também
de envio de plano de adequação. Eh, a
gente peria previu aqui algumas datas
intermediárias, né, já a partir da
metade do piloto para que a gente
consiga acompanhar mais de perto as
instituições. Então, a gente pode
convocá-las para participarem aqui de
agendas bilaterais com a gente. Ou vocês
podem também receber uma notificação via
ServiceBC, exigindo um plano de de
adequação, né, uma justificativa de não
atendimento dos requisitos até essas
datas aqui intermediárias, tá bom? Eh,
então acho que em termos de cronograma é
um pouco disso. 6 de fevereiro é a data
que todo mundo tem que publicar a API. A
partir do dia 9 a gente começa a testar
vocês via FVP. Os testes bilaterais,
eles também estão autorizados a iniciar
a partir do dia 9. Eh, e vocês devem,
né, se ater ali a a volumetria mínima
para cada produto.
E aí, de novo, queria aqui ressaltar se
alguma, se algum 90 quiser voluntariar,
antecipar a publicação, pode fazer. Peço
também que nos comunique, caso queira
fazer isso. A gente utilizará essas
instituições para tentar homologar a FVP
quanto antes para que a gente consiga
iniciar o piloto já com a ferramenta
completamente validada. E de novo, né,
independente se for antecipar a
publicação da API, a gente pede para
todos aqui, inclusive quem já opera JSR,
que se possível faça a publicação no dia
da data regulatória até o meio-dia, para
que já no período da tarde do dia 6 a
gente consiga começar alguns testes.
Aí em seguida, eu queria reforçar aqui
com vocês eh o processo de restrição de
recursos e habilitação de usuários. Eh,
esse piloto ele vai acontecer
exclusivamente com restrição de
usuários, tá bom? Então, nenhum teste
aqui eh vai acontecer com cliente real.
Eh, as ITPs têm a responsabilidade de
restringir essas funcionalidades aos
clientes reais, né, aos usuários finais.
Só que eh a ITP ela vai depender aqui da
detentora para indicar, né, para
conseguir ler qual, né, o que que ela
deve restringir. Então, a gente tem um
processo que ele já foi divulgado ali na
política de testes em produção do Open
Fancy. É a primeira vez que a gente vai
estar rodando ele eh full, então queria
reforçar aqui com todos vocês. Eh, a
gente tem então aqui uma dependência das
duas pontas, né? Então, as provedoras de
dados e serviços, que aqui nesse caso
são as detentoras, elas têm a obrigação
de fazer a publicação no diretório de
participantes. No momento que elas fazem
a publicação no diretório de
participantes, como a gente tá falando
aqui de um novo produto ou uma nova
funcionalidade, vocês devem incluir o
que a gente tá chamando de metadado
dentro da família da API. Esse metadado
é um recurso novo no diretório, então a
gente vai conseguir eh enxergar se
aquela família de API tem alguma
especificidade. Então, a gente vai criar
dois tipos de metadado. Um metadado
chamado em homologação, novos recursos e
um segundo metadado chamado em
homologação. Então, toda detentora no
momento que publicar a API ou atualizar
a versão da API, vai ter que também
preencher este metadado, tá bom? Se você
é um novo entrante, você vai preencher o
metadado em homologação. Se você já
opera, o que tá em homologação vai ser
apenas as novas funcionalidades.
Além disso, então, além de publicar e
preencher e configurar o metado, a
detentora vai ter que indicar paraa ITP
quais usuários poderão ser habilitados
ali para fazer esses testes em produção.
Então, a gente já disponibilizou um
formulário, ele tá no portal do
desenvolvedor e as as detentoras elas já
podem eh enviar para esse formulário a
relação de os usuários testadores, né,
as pessoas que vão ser responsáveis ali
por acessar as ITPs para fazer os testes
bilaterais. São quatro informações ali
que a gente pede nesse formulário, que é
o CPF do usuário, o e-mail, o orged e o
nome da instituição. O campo de e-mail,
ele é opcional, então tem uma ITP aqui
em específico que ela utiliza essa
informação para conseguir autorizar os
seus os seus usuários, tá bom? Eh, e o
formulário ele já tá ali. Eh, como é que
a ITP vai saber quem que ela pode
habilitar ou não? ela vai ter que
implementar uma lógica para validar o
metadado naquela família de API. Eh,
dessa forma que eu comentei. Então, se é
um novo encante, né, se o metadado é
homologação, novos recursos, a ITP só
vai restringir o Pix automático, a PJ e
o desktop. Se a o metadado é em
homologação, a ITP vai restringir
completamente ali as funcionalidades aos
seus clientes finais. E aí depois de
validar a o metadado, a ITP vai ter que
consultar uma base que a gente vai
disponibilizar através de uma PI, que na
verdade a gente já abriu ticket para
todas as ITPs com as credenciais dessa
PI, que é onde as ITPs vão conseguir
consultar quais são esses usuários que
estão habilitados eh para fazer esses
testes e que essa jornada pode ser
liberada para eles, tá bom? Então, é
basicamente esse o processo. Queria
reforçar aqui as obrigações de cada
ponto. Então, as detentoras vão ter que
publicar a API, configurar o metadado
enviar a relação de usuários testadores
e as ITPs vão ter que implementar a
lógica de restrição e consultar ali a
relação de quais usuários têm que ser
habilitados. Lembrando que eh essa
consulta ela vai acontecer através de
uma API que a gente já compartilhou com
as ITPs. Caso alguém aqui não tenha
recebido, pode abrir um ticket pra gente
no Service Desk que a gente compartilha
as credenciais.
Por fim, queria reforçar aqui o
acompanhamento, né? Então, todo o
acompanhamento desse cronograma que eu
falei com vocês, né, desses indicadores,
ele vai acontecer, a gente vai ter um
painel onde vocês mesmos vão poder
acompanhar o atingimento ou não desses
indicadores. E a gente tem agendas aqui
semanais que elas vão ser obrigatórias,
eh, né, elas vão ser de participação
obrigatória de todos vocês. E são
agendas, né, exclusivamente pra gente
tirar dúvidas dos participantes para que
vocês também possam se ajudar, tá bom?
Essas agendas vão acontecer todas as
sextas, das 15 às 16 horas, começando
ali a partir da primeira semana do
piloto no dia 13/02, indo até uma semana
após o fim do piloto, no dia 22 de maio.
E além disso, a gente tem um grupo no
WhatsApp, caso queiram participar. O
Qcode é esse. É um grupo também pra
gente agilizar eh algumas dúvidas, mas
dúvidas gerais a gente sempre pede que
formalizem via service desk.
Eh, pessoal, acho que é isso que a gente
tinha para passar para vocês. Agora sim,
eu abro para dúvidas. Lucas tá com a
mãozinha levantada. Eu passo a bola para
você.
>> Boa tarde, pessoal. Eh, apenas para
confirmar a informação, que o Paulo
trouxe em relação à certificação Fida,
eh, eu como detentora de contas, se
utiliza um fornecedor que já tirou essa
certificação lá na Fliance,
não necessariamente eu preciso tirar uma
outra certificação que seja derivada lá.
Eh, eu posso utilizar, no caso, essa
certificação do meu fornecedor lá no
cadastro do diretório, correto?
Perfeito. Você pode usar a certificação
do fornecedor, tá? A certificação
derivada geralmente é quando você quer
ter um servidor próprio customizado, se
o que deriva de um fornecedor, né? Não
sendo a solução do fornecedor mesmo,
apenas com configurações ali para
funcionar, a certificação dele é válida.
>> Combinado? Obrigado,
>> boa tarde. Eh, é sobre uma dúvida sobre
a publicação da API. A gente já é
participante ali da da JSR
e hoje a gente tá na versão
>> hoje a gente tá na versão 2 1.
Eh, e aí na verdade 2 10. E aí a gente
tem que fazer atualização para 220. Essa
atualização da da versão é que nesse
momento é que vai tá vai estar
habilitada essa configuração de
restrição que você falou aí no último
slide, ou seja, vai ter essa opção nova
ali no do diretório para cadastro da
API. Na hora que a gente atualizar para
22, vai aparecer essa opção pra gente
flegar eh o servidor de autorização e
colocar o metadado, certo?
Perfeito. Então, lá no dia 6 de
fevereiro, quando você atualizar a
versão da API, aí vai ter uma opção lá
de metadado daquela família de API, tá?
Então, a opção vai est vinculada à
família da API e vai ter e vão ter esses
dois valores aqui que eu suteio. Como
você já participou do primeiro piloto,
então para você é homologação, novos
recursos.
>> Beleza? Obrigado.
Eh, João,
>> João, se você está falando, eu não te
ouço.
>> Perdão, pessoal. Minha internet tá
oscilando um pouco aqui. O Edo, a a
minha pergunta vai em linha com a
anterior, só para confirmar talvez o
entendimento. Eh, pelo menos
anteriormente nós tínhamos que manter
duas versões durante o piloto, certo? Se
eu entendi corretamente, agora vai ser
apenas uma versão. E a distinção das
ITPs para esse ponto vai ser através do
metadato. É isso mesmo?
É médio. Na verdade, a gente tem dois
tipos de versionamento. Versionamentos
major, onde a gente prevê um período de
convivência entre duas APIs e
versionamentos minor. Nesse caso, a
gente tá fazendo um versionamento minor
da API de vínculo do dispositivo. Então,
quem já tem a API vai ter que inativar a
anterior e só ativar a nova, tá bom? E
aí a configuração do Do.
Obrigado.
>> Nada,
pessoal. Mais dúvidas?
>> Beatriz.
>> Boa tarde, pessoal.
Eh, boa tarde, Eduardo. Eu tenho uma
dúvida com relação,
desculpa, com relação à obrigatoriedade
da detentora. O piloto geralmente tudo
no Openfenção é obrigatório, né? Eh,
sendo opcional
participar no caso da ITP e o momento
que ela opta em participar, ela passa eh
ela passa a ser obrigada a fazer algumas
alguns marcos e tudo mais.
No caso, nos últimos comunicados, até no
ano passado, eh, em um dos informes foi
dito que, ah, no caso da deten da da da
iniciação era facultativo para se
cadastrar no ano passado para participar
do piloto. Agora vocês estenderam o
prazo até o dia 30/01, caso as
deniciadoras, as ITPs ainda tenham ou
algum algumas outras têm interesse em
participar. Nada é tensão, continua
sendo obrigatório a participação do
piloto. É isso, correto?
A implementação aqui da da JSR, ela tá,
nesse caso, ela está ampliando a
obrigatoriedade de participação. Então,
a regra aqui é que toda detentora de
conta que tem a participação obrigatória
lá no arranjo Pix vai ter que
obrigatoriamente também eh
disponibilizar API e vínculo de
dispositivo. Então, se você é uma
detentora que se encaixa nesse
requisito, então a sua participação no
piloto é obrigatória.
Compreendido. Entendi.
>> Tá bom. E aí, caso não se enquadre nisso
e esteja dentro do nosso acompanhamento,
aí você pode abrir um ticket pedindo
dispensa pra gente. Tudo bem? Maravilha.
Continua então sendo detentor, obrigada
no Pix, continua obrigatoriedade. Não
preciso indicar em nenhum um canal que
eu quero participar porque pressupõe-se
que já somos obrigados a participar.
Entendi.
>> Perfeito.
>> OK. Obrigado.
>> Imagina,
Andério.
>> Oi. Eh, eu sou do banco ág, nós somos
detentores, tá? Será que você pode
explicar melhor esse lance do metadado?
Porque para mim não ficou claro o nosso
papel quanto detentora.
>> Uhum. Obrigada. O metado, é o seguinte,
você vai, você como detentora, você vai
ter que publicar a API lá no diretório.
E aí no dia da de publicação da API,
você vai selecionar selecionar a IPF
militar, IP versão e vai ter uma nova
opção lá que chama-se metadw. E aí você
vai clicar nessa opção e vai ter o valor
aqui de em homologação. Como você é uma
nova detentora, você vai ter que flegar
esse valor eh que vai tá lá dentro do do
family type. E aí a gente e aí é só isso
que você precisa fazer,
>> tá? E só que isso daí eu tô fazendo em
sandbox ou em produção?
>> Isso já é em produção. Tá bom.
>> Ah, tá. Quando eu publicar PI mesmo, né?
Exato, exato. Entendi. Obrigada,
>> Patriz. Eu não sei se você tá com uma
nova dúvida ou se ainda é a mão
anterior.
>> Não, só tinha esquecido de abaixar,
desculpa. [risadas]
>> Tá bom, tranquilo,
pessoal. Algo mais?
Tá claro para todos aqui o
funcionamento?
Maravilha. Então, queria só reforçar o
pedido que eu fiz aqui no início, não
sei se estavam todos. Eu enviei um
formulário pedindo que vocês indicassem,
né, se já possuem a certificação Fidal.
Importante aqui também pra gente ter
esse acompanhamento prévio ao piloto,
relembrar o que o Paulo falou. A
certificação Fidal, ela é um requisito
obrigatório para JSR. Eh, e aí peço que
quem ainda não preencheu que eu faça. Eu
compartilhei novamente aqui o formulário
no chat.
Eh, já temos o
o grupo no WhatsApp. a gente tem a nossa
página centralizada também ali com as
diretrizes desse piloto.
Se tiverem dúvidas adicionais, vocês
podem abrir um ticket no Service Desk
ou, né, ou eventualmente também mandar
ali uma mensagem no grupo do WhatsApp e
a partir do dia 13 a gente inicia as
nossas agendas recorrentes de
acompanhamento. Em breve vocês devem
receber eh a o convite para essa
reunião, tá bom? A gente vai disparar
para todos os administradores do
diretório.
Eh, Beatriz e Andreia. Beatriz.
>> É, última pergunta é só sobre a
disponibilização do material da do
workshop. Por onde que qual canal que
vai acontecer?
>> A gente vai mandar um informe, tá?
Compartilhando os links,
>> tá? Só posso fazer mais uma pergunta?
>> À vontade, gente. Tem 20 minutos ainda.
>> Legal. Eh, como foi no modelo lá de
Pixel automático, tal, nós tínhamos a
relação de ITPs que estavam disponíveis
pra gente fazer esse toda essa troca.
Aqui também vai ser igual, a gente vai
ter a relação dessas ITPs que a gente
possa fazer os pagamentos, tal.
>> Perfeito. Sim. Aqui no dia 30 é a data
limite que as ITPs têm para dizer que
querem participar e aí na semana
seguinte a gente consegue consolidar e
compartilhar com vocês.
>> Ah, perfeito. Obrigada.
Maravilha, pessoal. Se não tem nenhuma
dúvida adicional, então acho que a gente
pode encerrar por aqui. Eh, o último
lembrete que eu queria dar é que na
terça-feira a gente vai ter a
disponibilização do motor estável de
JSR.
Eh, essa versão do motor, ela vai ter
algumas alterações relevantes, então
todo mundo vai ter que reexecutar pelo
menos algum novo teste. Peço que vocês
fiquem atentos ali aos informas. Eh, e
lembrar que os novos entrantes têm que
submeter o plano completo, eh, né, o
sucesso completo em todos os planos de
JSR para ter a certificação, tá bom?
Quem já opera é só executar o teste.
Modelo é simplificado. Novo entrante tem
que executar todos os testes de todos os
planos de JSR que a gente também já
divulgou para conseguir obter a
certificação e conseguir publicar em
tempo ali do
do cronograma. Eric,
>> o Eduardo, boa tarde. Eh, vocês vão
disponibilizar em algum em forma os
testes específicos que a gente vai
precisar reexecutar por caso de eh
instruções participantes?
Sim, a gente divulgou, acho que a gente
mandou um lembrete nessa semana,
eh, reforçando os testes, tá? Mas eu vou
confirmar aqui e eu posso compartilhar
no chat. Não sei se alguém tem de
pronto, mas eu coloco aqui no chat
também último informe.
>> Muito obrigado.
>> Perfeito, pessoal. Então é isso, desejo
uma boa tarde a todos. Até mais.
>> Tchau. Boa tarde.
Boa tarde a todos.