Piloto Pix Automático - Workshop Open Finance Brasil (11/04/2025)

Boa tarde, pessoal. Só dar mais uns
minutinhos aqui para não dar tempo mais
gente entrar. Depois a gente já começa,
tá?
Boa
tarde, tarde.
Boa tarde.
Boa tarde. Boa tarde. Boa tarde. Boa
tarde. Boa
[Música]
tarde.
chegou nós
Só
uma boa tarde pessoal para quem entrou
agora. Só vamos dar mais uns dois
minutinhos aqui para dar mais um
tempinho pro pessoal entrar. Logo a
gente já começa.
Boa tarde pessoal.
Pessoal, já dei uns minutinhos aqui a
mais para quem chegou atrasado conseguir
entrar. Acho que a gente consegue
iniciar aqui já, tá? Então,
primeiramente, boa tarde, seja todo
mundo bem-vindo. Esse é mais um
workshop, agora dessa vez sobre o piloto
de PX automático. Então, antes da da
gente entrar na agenda em si, alguns
recados importantes aqui. Primeiramente,
eh, sobre os objetivos do workshop, a
gente tem dois grandes objetivos aqui
nessa agenda. Então, primeiro é deixar
todo mundo alinhado com as informações
que já temos sobre o piloto de PIC
automático, então deixar as instituições
a par. E o segundo grande objetivo é a
gente esclarecer dúvidas aqui que vocês
podem ter durante essa agenda com as
informações já divulgadas. Então, eh, a
gente conseguir apoiar as instituições
com eventuais dúvidas aqui sobre o
piloto. Além disso, algumas
informações importantes também. A
primeira que esse workshop, como de
costume, ele tá sendo gravado e no
futuro a gente vai disponibilizar a
gravação no canal do YouTube do Open
Finance Brasil. E a segunda mensagem
importante também é que as dúvidas a
gente a gente vai sugerir que elas sejam
enviadas preferencialmente via o chat
dessa agenda. Então tem pessoal
responsável aqui que vai estar ajudando
na na responder. E se por acaso no final
da agenda ainda tiverem algumas dúvidas
remanescentes, a gente tem um tempo ali
disponível, reservado para esclarecer
essas dúvidas com vocês, beleza? Então
acho que apresentando aqui quem vai quem
vai apresentar essa agenda. Então sou
Iago, analista aqui da DTO do PF Brasil.
Quem vai me ajudar aqui na na agenda de
hoje é o Wendel, é PM aqui do GT
Serviços. Então, já indo sobre a agenda
em si, a gente separou a agenda em seis
partes. Então, compartilhar primeiro uma
introdução ao Pix automático, falar
exatamente o que que é o Pix, alguns
conceitos mais gerais, mais amplos. De
seguida, a gente vai falar um pouco
sobre os conceitos do piloto, o que que
a gente eh espera das com as
instituições, validações de PCM, eh
validação de liquidações, hum, enfim. Aí
falar sobre a restrição de usuários.
Então, por ser um piloto tem que ter
restrição de utilização dessas
informações, explicar como como isso vai
funcionar essas restrições, falar como a
nós estruturas vamos fazer validações
com as instituições, sejam detentoras ou
iniciadoras, passar sobre um pouco por
cima sobre o cronograma dessas
validações e por último que nem
comentei, deixar um tempo reservado no
final para tirar ainda eventuais dúvidas
das instituições aqui. Então, já indo
para a primeira pauta, já passo a
palavra aqui pro Wend para dar um pouco
mais sobre o contexto do PX automático.
Então, fica à vontade. Wend, obrigado,
Iaco. Boa tarde a todos. Acho que
primeiro aqui eh parabenizar aqui a
todos sobre o desafio aqui da
implementação, né? dizer que esse
produto ele foi concebido ali muito com
o apoio da da interação do do dos
participantes aqui da associação, com a
o apoio aqui do grupo de produtos como
um todo, né, ali, eh, na figura do
Edson, do José, da Vanessa, do Henrique,
que apoiaram a gente aqui, juntamente
com os demais times cross aqui, né, todo
o time do secretariado, eh, Sucesso do
Participante, entre outros. Eh, sem
muitas delongas aqui, eu vim comentar um
pouco eh sobre a linha do tempo aqui do
do desafio que a gente percorreu para
poder fazer a entrega do produto, tá?
Para para pro ecossistema, para vocês
aqui participante em relação a ao
desafio aqui encontrado. Então, eh, sem
mais deslonga, aqui a gente iniciou o
desenvolvimento aqui em junho de 2023. a
gente eh recebeu as diretrizes iniciais
do Banco Central para iniciar toda a
construção do produto Pix automático,
né? Eh, em agosto de de 23, a gente
delibera aqui, seguindo as regras da
convenção, cronograma de implementação
no antigo CD, né? E hoje ele passa a
CCA.
Em novembro de 2028, a gente teve ali
uma pausa na na no
desenvolvimento do produto muito eh em
linha com algumas necessidades que a
gente precisava receber ali do do
regulador eh oriundas ali da trilha do
Pix, né? Então, tanto a parte do
catálogo de mensageria quanto o guia de
UX, a gente precisava dessas informações
para conseguir construir aqui o nosso o
nosso produto aqui na na estrutura do
Open Finance. Em agosto de 24, o Banco
Central lança ali as ines 508, 511, 513
ali contendo todas as informações
necessárias, tanto do catálogo de
mensageria quanto do guia de UX. e a
gente retoma os nossos trabalhos aqui na
estrutura do Open Finance de modo a a
construir aqui o produto, né? Eh,
novamente a gente volta ali no CD eh
para deliberar o novo cronograma,
colocando as datas e o alvo ali paraa
entrega do produto. Em dezembro, a gente
lança a primeira ou a gente lança a
versão beta do aqui do do produto Pix
automático, né?
Eh, em março a gente faz o lançamento eh
após todos os aprendizados que a gente
tem aqui, os procedimentos eh da da
convenção entre lançar uma
especificação, ter um ambiente de
sandbox, eh a gente consegue aprender
ali com os inputs dos participantes. A
gente faz o lançamento da nossa versão
estável do produto.
Eh, agora em abril a gente inicia o
piloto eh de acordo com aquilo que tinha
sido planejado lá em novembro de 2024 e
a gente espera em em 2025 ter o go live
aqui para para todo mar aberto, conforme
todas as orientações que vão ser
repassadas aqui dentro do do
workshop. Pode ir lá, Iago, por favor.
Boa. Eh, a ideia aqui é dar uma visão
bem em alto nível, uma introdução
eh sobre o Pix automático, né? Dizer o
que que é o produto, por que que ele
surgiu, qual o problema ele soluciona e
quem deve ofertar essa solução aqui, tá?
Então, o que que é o Pix, né? Ele, o
Pixel automático aqui, ele é um serviço
que permite programar pagamentos
recorrentes, né, eh, pelo pagador com
valores fixos e variáveis, de forma
automatizada, somente com uma com uma
única autorização. Então, é ter a
condição ali de fazer diversos
pagamentos sempre com consentimento do
usuário paraa realização aqui do do dos
pagamentos de um serviço no qual o eh
usuário pagador eh negociou com o
recebedor aqui, tá? Eh, por que que ele
surgiu? Ele surgiu para facilitar ali
pagamentos recorrentes. Então, a gente
tem diversos casos de usos e diversas
aplicabilidades que eles podem ser
tratados, desde dos exemplos que foram
colocados aqui, energia, telefone,
escola, academias, condomínios,
assinatura, entre outros. Acho que a
ideia aqui com com o passar do tempo é
enxergar do mercado como o produto vai
se evoluindo, como ele vai se moldando.
Pra gente compreender aqui a magnitude
do do produto em si.
Qual que é o problema que que a gente
tenta aqui solucionar, né? Eh, ele pode
ser utilizado em múltiplos modelos de
negócios, né? Como eu comentei, ele é
aplicável para para diversos setores e
portes, né? Então, é, são os casos de
uso que o mercado vai encontrando, que
podem ser endereçados aqui dentro.
o o recebedor, uma vez que ele utiliza
essa solução aqui do Pix automático via
Trigop fines, o recebedor ele começa a
ter uma previsibilidade de valores, né,
sobre eh os valores a receber e e ao
mesmo tempo ele não tem mais aquela
questão de gerar ali convênios eh entre
concessionárias e bancos para poder ter
todo a informação dos pagamentos que ele
vem a trabalhar, uma vez que tudo isso
ficaria dentro do trilho do do Pix
Finance, eh é uma eh gera uma maior
facilidade, conveniência e praticidade
na utilização do serviço pro usuário
pagador. Tudo isso a gente acaba eh
tendo aqui pro pro propagador em relação
à sua utilização. Quem que deve oferecer
aqui o serviço? E aí olhando aqui muito
no âmbito da do nosso perímetro aqui do
Open FC, né? Então a oferta pelos
iniciadores, ela é opcional, né? Eh,
entretanto, pros detentores de conta que
prestam servir para cliente PF, ela é
obrigatória.
Eh, enquanto é que pro público PJ ela, a
oferta ela não é obrigatória pelo
detentor, mas ele para ele poder não ter
essa obrigatoriedade, ele deve solicitar
ali o optout junto ao arranjo Pix para
não entrar oferecer esse produto aqui no
pro paraa sua base de clientes. Acho que
como regras gerais aqui que a gente tem
eh para paraa utilização do serviço, a
conta do recebedor obrigatoriamente tem
que ser uma conta PJ, tá? Isso aqui é
uma é uma uma premissa que a gente tem
que trabalhar e adotar aqui pro pro
nosso fluxo de desenvolvimento, pro
produto. E a conta do pagador, ela pode
ser tanto PF quanto
PJ. Acho que é isso aqui, tá Iago?
Boa. Fala contigo, meu amigo. Boa.
Obrigado, Wendon. Então, já agora, um
pouco, falamos um pouco sobre, num
contexto mais geral sobre o que
exatamente é o PX automático, a gente
queria entrar agora um pouco mais sobre
exatamente que que vai ser esse piloto e
falar um pouco das regras que já
divulgamos ou ainda estamos iremos
divulgar em breve aqui. Então, sobre o
conceito de piloto, alguns pontos
importantes aqui, né? Então, qual que
são exatamente os objetivos do piloto?
Então, não só esse piloto, mas o
conceito de piloto em si, ele vem pra
gente conseguir garantir um
funcionamento interoperável. e o
ambiente produtivo das instituições
estarem de de acordo com as
especificações em pleno funcionamento.
Então, com isso, com esse ambiente de
piloto antes do
Gocipar eh problemas em ambiente
produtivo, consegue marcar agendas
bilaterais, seja da estrutura com as
instituições, seja agenda bilaterais
entre as próprias instituições. Então, o
conceito de piloto em si, igual
funcionou muito bem pro piloto de JSR,
ele tem esse objetivo de exatamente
mitigar essas falhas em ambiente
produtivo anteriormente ao Gove. Então
aqui falando um pouco mais sobre as
responsabilidades das instituições nesse
período de piloto, separando em duas
partes aqui. Primeiro com relação às
detentora de contas, as instituições que
até duas semanas antes do final do
piloto não atingirem os critérios que a
gente vai passar já já, elas vão ser
convocadas para um war room, uma sala de
guerra, pra gente fazer um
acompanhamento e pra gente ver a
apresentação e o acompanhamento desse
plano de ação para correção desses
indicadores, a correção desses critérios
ainda pendentes. E se por algum motivo
esses critérios ainda não forem
atingidos até o final do piloto, as
detentoras elas podem não ser listadas
pelas iniciadoras em ambiente produtivo
depois do Golive, né? Então, esses
critérios precisam ser atingidos pelas
detentoras até até o final para não
correrem esse risco. Falando agora das
iniciadoras até 5/05, se as iniciadoras
elas não tiverem a jornada disponível, a
gente não vai fazer as validações de
justiça e consequentemente as
iniciadoras não vão participar do piloto
e consequentemente elas não vão não vão
poder disponibilizar a funcionalidade de
produção até posteriores definições de
regras. Então, além disso, exatamente
igual as detentoras, se até duas semanas
antes do final do piloto, as iniciadoras
ainda tiverem critérios pendentes, ainda
não tiverem atingidos indicadores que
vão se passar já já, elas também vão ser
convocadas para sala de guerra junto com
a estrutura para acompanhamento de
planos de ação para correção dessas
dessas pendências. E por último, se até
o final do piloto as iniciadoras mesmo
assim não tiverem atingido esses
critérios, elas não vão poder
disponibilizar ela funcionalidade e
ambiente produtivo. Então agora indo um
pouco mais sobre os detalhes desses
critérios, a gente tem paraas
iniciadoras detentoras critério de
validação de justiça, que a gente vai
entrar um pouco mais detalhe mais paraa
frente. Tem paraas detentoras, as
validações vão ser feitas pela FP
automática e pela FVP manual. Então aqui
para todos esses critérios aqui na tela,
a gente tá analisando dois horizontes.
Um horizonte de um critério para
abertura de ticket, notificação das
instituições, um critério também para a
sala de guerra, que seria a convocação
para a a instituição apresentar um plano
e acompanhamento da correção desses
indicadores paraa estrutura. Então,
esses dois critérios de justiça FP, a
gente vai entrar um pouco mais detalhes
mais paraa frente. Então, só dar um
contexto que a gente vai acompanhar esse
esses dois indicadores. E para PCM, além
de acompanhamento das taxas de
conversão, taxa de sucesso e erro, a
gente vai simular o que a gente fizemos
no piloto de JSR. As taxas de pareamento
elas têm que ser pelo menos 95% de
pareamento, sen não vai estar passível
de abertura de ticket, de notificação
com as com as informações para correção
e também posterior convocação para sala
de guerra. E com relação às additional
infus, então isso daqui é um critério
novo quando se comparado ao pelo JCR, as
instituições elas obrigatoriamente têm
que virar 100% dos additional infos
necessários. Então se não enviar 100%
dos additional infos, a instituição vai
receber ticket, vai ser notificada e se
duas semanas antes do final do período
do piloto, ela tiver menos de 95% de
additional infas, ela também vai ser
convocadas paraa sala de guerra. H sobre
a volumetria de pagamentos liquidados,
eu vou falar já já. queria falar sobre
sobre o último tópico antes sobre
tickets e baterais aqui. Se as
instituições elas antes do final do
período do piloto elas tiverem tickets
bilaterais mesmo que dentro do SLA e
ainda assim os tickets não tiverem
encerrados, exemplo, dois dias antes do
eh do final do piloto, a instituição ela
tiver um ticket lateral, que o ticket,
por mais que esteja dentro dessa não
esteja encerrado, a instituição ela vai
ser convocada também para uma sala de
guerra para um acompanhamento e entender
exatamente o que que tá acontecendo.
Agora, indo sobre a penúltima linha
sobre os 200 pagamentos liquidados aqui,
a gente, conforme divulgamos também as
instituições, tanto as detentoras quanto
as iniciadoras, tem que ter pelo menos
200 pagamentos liquidados, ou seja, pelo
menos 30 com first payment e 170 com
requery payments. Então aqui tem um uma
nota de rodap também que para para as
detentoras esses 200 pagamentos tem que
ser pelo menos com 30% das perdão da com
as iniciadoras tem que ser pelo menos
30% com as marcas detentoras e para as
iniciadoras tem que ser pelo menos com
50% das iniciadoras. Então, acho que só
colocando um pouco mais de informação
sobre esses 200 pagamentos liquidados, a
gente teve muitas dúvidas com relação a
isso. Então, a gente gostaria de
esclarecer um pouco mais exatamente como
que vai funcionar esse
acompanhamento e desses pagamentos
liquidados. Então, como aqui a gente a
gente tem esse limite mínimo de 170
pagamentos requins
identificados, ah, aqui a gente
recomenda que as instituições ativem
esse esse número quanto antes, pois com
os agendamentos eles podem ser feitos de
2 a 10 dias úteis antes do final do
piloto. No final, no começo de junho, se
ela já tiver esse critério, já está
garantido. Mas se por acaso, exemplo,
dois dias antes do final do piloto, ela
ainda não atingiu, ela não vai conseguir
atingir esse número de recur payments
pelo fato do de ter o tempo de
agendamento para de fato conseguir fazer
essa liquidação. Então recomendação aqui
é atingir esses números o quanto antes
para não ficar dependendo desses desses
tempos de agendamento para
contabilização. O segundo ponto é esse
acompanhamento, ele vai ser feito com
base nos dados trafegados pela PCM,
reportados pelas instituições. Então
aqui se por acaso tiver falhado nesses
reportes, tiver falhando no
acompanhamento com a PCM, a gente não
vai conseguir identificar. Então as
informações vão estar disponíveis no
painel de acompanhamento do piloto, que
a gente também vai divulgar em breve.
Então a ideia aqui é esses 200
pagamentos estarem já identificados e
bem reportados para acompanhamento no
painel no painel do piloto. E por
último, é que cada instituição é
responsável por atingir os próprios 200
pagamentos liquidados. Então aqui uma
detentora de contas, por exemplo, eu vou
ter meus usuários liberados em ambientes
produtivos pelas iniciadoras, que vou
falar já já. Então eu mesmo tenho que
garantir esses 200 pagamentos
liquidados, consigo com meus usuários de
teste em ambiente produtivo utilizar as
iniciadoras para atingir esses
pagamentos liquidados. Então para as
ITPs, exatamente a mesma coisa. Então
cada instituição responsável por atingir
esses 200 pagamentos.
Agora, já indo pro próximo tópico,
tópico sobre a restrição de
usuários aqui, como vai funcionar
exatamente, né? Então, ponto importante
aqui, o ponto mais importante aqui é que
as iniciadoras Opa, claro, mudou,
desculpa, mudou a tela. Inverteu
minuto. Consegue ver agora?
Agora foi boa.
Legal. Tá. Então, dando sequência aqui
sobre a restrição de usuários, né? O
ponto importante aqui sobre a restrição
de usuários é quem deve fazer a
restrição dos usuários para controle em
produção são as iniciadoras de
pagamento. E as detentoras de conta,
elas têm que liberar a funcionalidade
para toda a base de usuários. E como vai
funcionar isso daqui? Eh, ontem, eh, dia
10, a gente enviou para as instituições,
para as detentoras que estão
participantes do piloto, um e-mail pro
formulário para preencherem os CPFs e
CNPJs dos usuários que vão participar do
piloto. Então, a ideia é que é até
semana que vem as instituições
disponibilizarem esses usuários. A gente
vai fazer um consolidado desses
usuários, passar paraas iniciadoras.
Então aqui os usuários, não só das
detentoras, mas também das iniciadoras,
usuários do Banco Central e da
associação, pessoas que vão fazer os
testes de UX e também de FVP, a gente
vai fazer o consolidar dessas
informações, repassar para as
iniciadoras e as iniciadoras de novo vão
ficar responsáveis por fazer essa
restrição de usuários para sim fazerem a
liberação dos usuários para detentoras.
Acho que um resumo aqui dos pontos
importantes é as iniciadoras que tm que
fazer a restrição dos usuários que podem
acessar a funcionalidade e as detentoras
de conta que tem que liberar a
funcionalidade para toda a base de
usuários de acordo com os usuários que
foram liberados pelas detentoras,
associação, pelo Banco Central e por
membros também cadastrados pelo pelas
iniciadoras de transação de pagamento.
Beleza? Então, acho que só fazendo um
comparativo também com o último piloto
de JSR. Eh, a diferença aqui é que no
último piloto tinha uma liberação eh
parcial da própria base das iniciadoras.
Aqui não vai acontecer isso, vai ser
apenas para esses usuários habilitados e
compartilhados por esses por esses esses
quatro esses quatro bases das detentoras
da associação, iniciadoras e do Banco
Central.
Então, acho que dando sequência aqui
sobre as validações que a estrutura vai
fazer com as com as instituições, acho
que antes de passar sobre as validações
em si, é importante a gente dar um
contexto de de como que está funcionando
o Pix automático. Então, um dos grandes
desafios aqui como estrutura que a gente
tem para esse piloto de Pix automático é
a volumetria. Então, a gente tem 141
marcas de 113 instituições diferentes.
Então, a gente tem 16 testes na FP, ã,
por exemplo, e fazer as validações com
todas essas marcas, ela fica
praticamente inviável. Então, pelo
volume, pela quantidade de testes, a
gente necessariamente teve que segregar
as detentora de conta em em três grupos
pra gente ser mais ou menos exaustivo
com cada uma delas. Então, paraa
detentora de contas, a gente fez essa
separação em três grupos. A primeira
marca, as primeiro grupo são as marcas
priorizadas que o fornecedor ele tem
conta aberta. Então aqui eu vou passar
já na sequência quais são essas marcas
priorizadas. Então as instituições
estavam perguntando exatamente quais são
essas marcas, mas nós vamos passar aqui
também vamos divulgar posteriormente,
mas vamos saber quais vão ser essas
marcas priorizadas. Então são as marcas
mais relevantes por ecossistema aqui do
Open Finance, então elas vão ser uns
testes mais exaustivos. A gente tem o
segundo grupo, são as demais marcas que
o fornecedor responsável pela execução
de UX e da FVP, ele tem conta aberta.
Então a gente vai fazer essas validações
com com as contas abertas pelo
fornecedor. E o terceiro grupo são as
detentoras de conta das marcas que o
fornecedor ele não possui conta aberta.
Então aqui a gente vai passar exatamente
o que cada um vai vai precisar atingir
como validações de X FVP. E falando
também sobre as iniciadoras, a gente vai
ter por volta, com base no formulário
que a gente divulgou para as
iniciadoras, a gente teve uma margem de
sete a 11 TPS que falaram que vão
participar do piloto de Pix automático.
Então vamos passar o K, vamos lá para
cada uma delas. Então que nem comentei,
vou passar primeiro sobre quais são
essas marcas priorizadas, depois falar
sobre o que que seriam testado para cada
um desses grupos. para as marcas
priorizadas aqui a gente são ao todo, um
minuto, são 19 marcas PF, 16 marcas PJ.
Então, de novo, a gente pegou as
principais instituições do ecossistema,
então as instituições participantes da
ESTINTA IN441, a gente pegou as marcas
mais relevantes de cada uma dessas
instituições, tanto PF quanto PJ.
Colocamos aqui como as marcas
priorizadas para terem testes mais
exaustivos de UX e também validação da
FP. Então, essa é a primeira página das
marcas
priorizadas e a segunda página das
marcas priorizadas. Então, se quiserem
depois pegar a gravação no YouTube para
ficarem mais fácil ou até tirarem um
print aqui para ficar mais fácil também,
está sem problemas. Mas de novo, isso
aqui a gente vai divulgar para saberem
exatamente que que quais são as marcas
priorizadas ou não. Agora seguindo, o
que exatamente vamos testar primeiro
para essas marcas priorizadas? Então, as
detentórias de conta as marcas
priorizadas, que são essas marcas que eu
acabei de mostrar anteriormente, elas
vão ter duas validações. Validações
executadas pela FP, a ferramenta de
validação e produção e as validações de
justiça. Então, a primeira parte sobre a
FVP, a gente vai ter três ambientes
executados de forma variada. Então, aqui
falando dos ambientes iniciado pela FVP,
que não é o ambiente da detentora, tá?
Então, iniciado via desktop na FVP, via
Android e via iOS. Então aqui a gente
vai executar ao todo 16 cenários já
confirmados. Então são todos os cenários
da FVP e tem ainda dois testes de longa
duração que ainda estão em discussão e
ainda sem uma previsão de
disponibilização da FVP. Então uma vez
disponibilizado esse ST de longa duração
que vão testar os reties em ambiente
produtivo, vamos testar também a
liquidação dos dos agendamentos, uma vez
disponibilizado esses testes, a gente
faz vai fazer essas validações com essas
marcas.
Então aqui na FVP ã uma grande diferença
que a gente vai ter com as outras
execuções da FVP ou até uma grande
diferença pro último piloto de ATCR é os
testes eles vão continuar iguais, então
vão ser executados pelo fornecedor
contratado que tem conta aberta com
essas instituições. Mas os retestes, uma
vez que as instituições têm esses
ticketes abertos, os retestes eles podem
ser obtidos sucesso pela própria
instituição. Então, exemplo, supõe que
uma instituição, ela teve uma falha no
cenário de edição de consentimento da
FVP. A instituição foi notificada,
recebeu um ticket com o nome do teste
que teve essa falha. A partir do momento
que a instituição teve ticket aberto, se
na execução da FP aberta que a própria
instituição executa e tem sucesso, a
gente vai conseguir contabilizar
exatamente que a instituição teve essa
conta aberta e o ticket da própria
instituição vai ser encerrado. Então,
diferente das últimas execuções em que
só o fornecedor podia ter obter o
sucesso nos retestes para encerramento
desses tickets, aqui a gente tá abrindo
uma margem para as instituições também
obterem sucesso nesses retestes e
consequentemente esses tickets serem
encerrados. Então, acho que de novo
aqui, a uma vez os tickets abertos para
instituições, elas executando e depois
da abertura do ticket elas terem
sucesso, as instituições não precisam
fazer nada e a gente vai conseguir
identificar e os testes e os tickets vão
ser encerrados para as instituições, tá?
Então, abrindo um parênteses aqui, esse
essa margem para ter sucesso.
Encerramento dos tickets não é só para
as marcas superiorizadas, mas para todas
as marcas, mas só queria deixar claro
que vai ser um comportamento um pouco
diferente do que a gente tá fazendo no
último piloto e nos ciclos recorrentes
da FVP.
Então, sobrevp das marcas priorizadas,
esse foi o cenário geral. Agora, falando
sobre as validações de X para essas
marcas priorizadas, a gente vai testar
dois ambientes, ambientes
disponibilização da jornada, tanto
Android quanto iOS, e vamos testar um
cenário de autorização de um novo Pix
automático. Então aqui também vão ser
dois segmentos, tanto PF quanto PJ, para
autorização de um Pix automático. Então
aqui vão ser, por exemplo, quatro testes
com cada marca. para validação desse
cenário de autorização desse pagamento
automático. Então, eh, essas são as
validações de FVP e de X que vamos ter
com as marcas priorizadas. Agora, dando
sequência, falando ainda sobre as
instituições em que o fornecedor ele tem
conta aberta, mas não são aquelas marcas
priorizadas que a gente colocou na lista
alguns slides lá, slides atrás. A
diferença aqui é que vamos testar apenas
FVP. O fornecedor, de novo vai executar
três ambientes de forma variada,
desktop, Android e iOS, aqui ambiente de
inicialização da FVP. Porém, aqui a
gente vai testar um cenário menos
exaustível, cenários mais relevantes,
que seriam os dois cenários de
interoperabilidade e dois cenários de
garantia de jornada. E acho que de novo
o mesmo funcionamento, como eu expliquei
antes, os testes e execução, uma
primeira vez vão ser realizados pelo
fornecedor contratado. E os retestes,
uma vez a instituição ela tendo. Se ela
executar o teste por conta, obter
sucesso, o ticket ele vai ser encerrado
de forma automática. Então acho que de
novo, a diferença dessas demais marcas
para aquelas priorizadas que foi
mostrada antes é que aqui a gente não
terão validações de justiça para essa
para as demais marcas que o fornecedor
possui conta aberta. E por último, só
para fechar o ciclo, os grupos das
detentoras de conta aqui são as marcas
em que o fornecedor ele não tem essa
conta essa conta aberta. Então aqui as
instituições elas vão ser responsáveis
pelos próprias execuções. Então aqui é
um ambiente que a instituição ela tem
que ela é a escolha da instituição, ela
pode iniciar no FPVCTP, Android iOS
indiferente. E a instituição ela tem que
obter sucesso em todos os testes da FP.
Então a instituição que o fornecedor não
possui conta aberta, a instituição ela
tem que ter o sucesso em todos em todos
esses cenários. Ah, aqui esse esse
último ponto de testes aqui tá
incorreto, seria a execução por por
parte das instituições, das marcas sem
conta aberto por um fornecedor. Então,
com fornecedor não tem como tá aberto,
um fornecedor não tem como executar.
Beleza? Só fazendo uma correção aqui no
material.
E hoje no hoje não sei se já foi
disponibilizado via informe ou ainda vai
ser disponibilizado, mas essas
informações de como acessar, quais
marcas o fornecedor ele possui conta
aberta, quais marcas o fornecedor não
possui conta aberta, também já tá
disponível no painel de acompanhamento
dessas dessas contas.
Então, encerrando esses três grupos das
detentoras, falamos sobre as marcas
superiorizadas, as demais marcas com
conta aberto pelo fornecedor e por
último aqui as marcas da detentora de
conta em que o fornecedor não possui
conta aberta. Então, dando
prosseguimento agora falando sobre as
validações a serem
realizadas com as ITPs, aqui vão ser
realizados testes em dois ambientes, em
dois ambientes das iniciadoras. Então,
vão ser realizados testes em ambiente em
Android e teste em ambiente iOS. Aqui
vão ser feitos dois testes no ambiente
de gestão. O primeiro teste é uma
autorização de um novo Pix automático e
o segundo teste é uma autorização, é uma
revogação dessa autorização que foi
concluída. Então aqui vão ser testado de
novo dois segmentos também, tanto
segmento PR quanto segmento PJ. Acho que
em resumo aqui as iniciadoras elas vão
ter quatro testes, perdão, elas vão ter
2 x 2 x 2 vão ter oito testes para para
serem realizados na Android, iOS,
autorização, revogação, PF e PJ. Então,
é, Igo, posso complementar uma
informação aqui? à vontade. Eh, os
cenários aqui a gente vai ter um que é a
autorização do novo Pix, então do da
nova autorização e depois é a parte de
gestão. Então, a gente vai ver se
consegue, não é só a revogação, a gente
vai ver se consegue eh atualizar o valor
máximo do pagamento, se consegue
atualizar a data do primeiro pagamento,
eh aí depois se a gente consegue
configurar o, se a gente consegue
cancelar aquela autorização, tá? Então,
não é, tem uma parte aqui de gestão do
consentimento que vai ser feito aqui só
pro pra parte das ITPs, porque pra parte
das detentoras eh a área de gestão vai
estar disponível só em 16 do6.
Boa, muito obrigado,
Fabinho. Então, aqui passamos um pouco
sobre as validações, tanto das
detentoras quanto das iniciadoras.
Acho que aqui a gente queria só
compartilhar com vocês como vai ser mais
ou menos o cronograma proposto para
todas essas validações, tanto das
detentoras quanto das iniciadoras.
Então, acho que é só retomando um pouco
o calendário que já foi divulgado, as
instituições ela tem até o dia 21 desse
mês para fazerem a publicação das APIs
no diretório dos participantes e no dia
22 vai ser o início do piloto. As marcas
priorizadas vão ter as execuções de ã
vão ser vão ter três execuções dos
cenários de
interoperabilidade. Hum. Vão ter depois
a execução dos demais cenários de teste,
então as execuções das marcas
priorizadas ter execução exaustiva da
FVP, tem as execuções do test de longa
duração, que ainda está em discussão e
ainda sem uma previsão disponibilização
desses testes. E os as validações de
justiça elas vão começar todas a partir
dia 6 de maio. Então acho que de novo
aqui ponto importante para para as
validações de justiça, elas vão começar
só a partir de 6 de maio. Então aqui as
iniciadoras, por exemplo, que não
disponibilizarem as jornadas até do dia
5, elas não seriam participantes do
piloto. Então aqui agora pr as demais
marcas que não são as priorizadas, aqui
a gente vai executar quatro testes.
Então dois cenários de
interoperabilidade, dois cenário de
garantia de jornada. E aqui é as
instituições também que não tm conta
aberta, elas vão ter até o dia 22 de
maio para fazer para ter o sucesso e em
todos os testes da FVP aberta. Então
aqui as demais marcas que não são
priorizadas vão ser executadas a partir
do dia 19. E as instituições e que o
fornecedor não tem conta aberta, elas
têm que ter o sucesso até o dia 22 de
maio em todos os cenários de testes da
FVP aberta, pois notificação as as
instituições de conta aberta vai
acontecer no dia
23/05. E além disso, desses testes já
programados para FVP, a gente tem uma
margem no final do piloto de 200 testes,
de 200 testes para eventuais novas
necessidades de execuções FVP. Então, e
se por algum motivo, por exemplo, a
gente identificar que uma marca
específica, por mais que ela já tenha
passado um cenário de
interoperabilidade, ela por algum motivo
ainda estável ou não deixou de funcionar
alguma alguma alguma jornada, a gente
tem essa essa margem pra gente fazer
essa solicitação de execuções sobre
demanda da
FP marcas a gente entender como
necessário. Então é uma margem aqui pra
gente conseguir focar em algum em marcas
que a gente tem como necessário no final
do piloto. E por último ali, igual eu
comentei, as iniciadoras vão ter o a
validação das jornadas a partir do dia 6
de maio e essas validações devem ir até
o dia o dia 30. Então o ponto, duas atas
importantes para iniciadora seria a
disponibilização da jornada até o dia
5/05 e a solicitação de retestes com as
evidências, se tiverem falha, elas têm
que ir pelo menos até dia 9/06. Então,
depois disso, não vai conseguir fazer o
reteste dessas dessas validações de Xi
para as
iniciadoras. Então, acho que aqui eu
falei muito, acho que agora que nem
comentei a ideia. Opa, não é a parte das
dúvidas, ainda tem algumas considerações
aqui, perdão. Então, acho que algumas
considerações adicionais antes paraas
dúvidas aqui do pessoal é eh com relação
às relação do iniciador, do recebedor,
alguns pontos importantes. Então, aqui
não é permitida a oferta de produtos
reais, então instituições em em que a
organização do conglomerado iniciadora
tiver não possuem contrato firmado por
do pis automático, ela não vai poder
oferecer esses produtos de forma real.
Então aqui a gente abre margem se a
instituição quiser fazer um teste,
utilizar, olha, vou fazer essa
utilização só para ver se o produto tá
funcionando em ambiente produtivo,
beleza? Mas ela não tá não é
extremamente vedado utilizar o produto
de forma real, como um produto já em
funcionamento aqui. Não é não é possível
utilizar essa funcionalidade ofertando
um produto real. Então segundo ponto que
eh o vínculo com a empresa recebedora é
de total responsabilidade da instituição
iniciadora. Então aqui os agendamentos,
por exemplo, fica total a cargo das
iniciadoras a fazer essas solicitações
pros pagamentos serem serem enviados.
Então os agendamentos ficam total
responsabilidade da iniciadora e não da
empresa recebedora.
O terceiro ponto é que é que as
ITPs é a gente recomenda que as
instituições, as ITPs iniciadoras elas
ofertem cenários variados, então first
payment e recording payments, até porque
um dos critérios que a gente avalia é a
disponibil é a contabilização da
liquidação dos pagamentos imediatos e
dos agendamentos. Então a gente a gente
recomenda que essa variação desses
cenários eles sejam eles sejam possíveis
até para testar diferentes
possibilidades com sem um first payment,
com sem um agendamento, até para ver a
funcionalidade funcionando ou não e pra
gente contabilizar ambos os cenários na
PCM para atingir os critérios de 200
pagamentos liquidados.
O quarto ponto é que por se tratar de um
ambiente produtivo e por se tratar de um
que os valores eles não vão ser
tornados, eh a gente recomenda que as
necessadoras utilizem baixos valores de
pagamentos. Então, de novo, aqui os
valores eles não vão serornados, são
valores de ambiente produtivo e por isso
a gente é recomendado, altamente
recomendado que seja utilizado baixos
valores de pagamento. E por último,
algumas duas considerações gerais, não
só sobre a relação iniciador e
recebedor, é que os consentimentos que
forem gerados durante o período de
piloto até o dia 15/06, todos eles devem
ser revogados compulsoriamente. Então
aqui não seria a exclusão do histórico
do consentimento, mas a revogação desses
consentimentos tem que ser feitos até o
final do
piloto. E por último, antes de abrir
para dúvidas, eh aqui o limite a ser
utilizado nos testes do piloto é o
limite geral do arranjo e não o limite
específico do Pix automático. Então esse
limite específico do Pix automático
ainda tá em implementação e por hora ser
utilizado o limite geral do arranjo para
as instituições. Então acho que agora
sim vou abrir espaço aqui para
dúvidas. Fabi, fique à vontade. Aí
pessoal, eh eu quero só reforçar aqui
alguns pontos especialmente da parte das
iniciadoras. Então vamos lá. Eh, as
iniciadoras eh precisam disponibilizar
uma jornada que inicie numa eh,
simulando ali a jornada da recebidora.
Pode ser uma jornada simples, essa
primeira página vai ter que ser
responsável por essa parte.
Eh, e aí o e vai ter que ter a jornada
inteira disponibilizada da parte da
iniciadora vai ser cobrado a parte da do
consentimento si e a parte de gestão. As
iniciadoras que a gente não tiver o link
de acesso e não tiver com o acesso
liberado até 5 de maio, não serão
consideradas participantes do piloto.
Fabi, minha jornada vai tá pronta no dia
7 de maio, vai tá fora, tá? A gente tem
que, a gente vai começar os testes no
dia 6, a data limite paraa gente receber
os links de acessos liberados para pros
usuários é dia 5 de maio, tá? E aí vai
ser testado com sentimento e gestão
detentoras. A gente não vai testar a
área de gestão porque vai ter que est
pronto só ali junto com o trilho do Pix
mesmo, no dia eh no dia 16 de junho. Eh,
e aí essa parte aqui que a gente tava
falando do pagamento, vamos lá, dentro
do Pix
automático, eh o usuário não é que nem
quando eu faço um pagamento normal, eu
escolho o valor e eu escolho para quem
eu tô pagando. Aqui a gente vai ter uma,
vou falar aqui, vai ter uma instituição
que vai usar um recebedor, um CNPJ, que
vai ser uma ONG. Então, todos os
pagamentos feitos serão
doações. Eh, esse dinheiros, para eu
fazer meu teste, esse dinheiro não vai
voltar para mim. Isso dinheiro vai paraa
ONG e não tenho, eu não consigo ficar
configurando quem vai ser o recebedor
num contexto de Pix automático. O
usuário final também não configura quem
é o recebedor. E aqui tem uma parte de
integração recebedor, iniciador. Então
aqui também não dá para ser algo tão
personalizável. Então cada iniciadora
vai ter que escolher pelo menos um
recebedor. E os pagamentos que forem
feitos. Aí eu vou até usar
aqui
eh o exemplo do Robson que fez a
pergunta aqui. Se o Robson fizer um
teste como usuário final que for para
essa ONG, Robson não vai ter acesso a
esse dinheiro de volta. Então o que a
gente tá pedindo aqui paraas
iniciadoras, como esses valores não são
parametrizáveis ali dentro, você pode
configurar qual é o valor máximo, mas
você não escolhe qual é o valor de cada
pagamento que você faz. Então, a gente
tá pedindo aqui paraas iniciadoras eh
terem ali a disponibilização também, a
gente vai até discutir isso na semana
que vem junto com os GTS, mas
disponibilizar um valor baixo do
pagamento. Então, se a iniciadora
configurar ali um pagamento recorrente
de R$ 1.000, o dinheiro não volta, vai
assim, a gente vai ter um problema aqui
na execução dos testes, tá? E aí a gente
também o o a recorrência do pagamento
também depende muito do recebedor, né?
Então, vamos lá. Se eu tô eh a maior
parte do serviço, se eu for ter uma
parceria com uma escola ou com um
serviço de telefonia ou um streaming,
alguma coisa assim, lembrando aqui não
pode ser um produto real, mas a
recorrência do pagamento também não é o
usuário final que acaba escolhendo,
acaba sendo algo inerente ao produto que
tá sendo contratado, né? Aqui não vai
ser nenhum produto real sendo
contratado, mas o que eu tô querendo
dizer não é parametrizável. Então, a
gente queria ver aqui se as iniciadoras
conseguirem disponibilizar alguma forma
da gente poder testar pelo menos semanal
e mensal. Eh, seria muito interessante
aqui pra gente conseguir estressar os
casos aqui no piloto, tá? Então é por
isso, então tem esses pontos de atenção
porque é diferente dos outros tipos de
pagamento que a gente teve até hoje aqui
dentro do Open Finance, essas
informações elas vêm do produto, elas
não vêm do do usuário optando o que,
como, quando, quanto que vai ser o
pagamento. Ela define o valor máximo,
né? É, deixa eu ver se ficou mais claro
aqui essa parte.
Boa. Obrigado,
Fabi. Tô vendo aqui no chat que tem
muitas dúvidas ainda. Não sei se tem
alguma dúvida que não foi respondida. Se
alguém quiser falar aqui, fica à
vontade. Diga lá, Hugo.
Eh, duas duas perguntas inicialmente,
né? Vamos por partes. Eh, nas marcas
prioritárias que apareceram lá, apareceu
a marca da caixa, tá? Na eh mas a caixa
tem duas marcas. Caixa tem caixa na são
três. Caixa cliente sem conta, caixa tem
e caixa. Eh, quando colocou caixa lá é
só a marca caixa ou tá falando
conglomerado caixa?
Aqui é marca caixa, Hugo. Então, marca
caixa. Então, seria só a caixa. Então,
isso, exatamente. Tá. E na segunda
pergunta, né, eh, em relação ao
cronograma, a gente vai ter o ambiente
já produtivo do piloto a partir do dia
22 agora. Só que as ITPs elas só vão
começar assim no pior cenário a
disponibilizar a partir do dia 5. Então
entre dia 2 e o dia 5 eu só consigo
testar
FVP. Se eu precisar testar
o o que que eu fiz como detentora, eu só
consigo testar via FVP. Não consigo
testar utilizando todo o o arranjo
utilizando uma uma ITP, né?
Exatamente, Hugo. Então aqui até o dia
5, que é a data limite das iniciadoras,
eh, até o dia 5, as iniciadoras já podem
ter disponibilizado a as jornadas.
Então, no melhor dos casos, no dia 22,
elas já vão ter disponibilizado a
jornada, mas se até lá nenhuma tiver
disponibilizada, a FVP, ela vai atuar
como vai poder utilizar ela para fazer
testes utilizando a FP como iniciadora,
tá? Tá. Tá? E apareceu uma terceira, uma
terceira questão aqui. Eh, se por algum
acaso eu já tiver com o meu ambiente já
pronto aqui para testar tudo mais, não
tem iniciador, isso é isso é certo. Eu
posso utilizar FVP como teste e a partir
de, por exemplo, a semana que vem.
Sim, exatamente. A FP já vai est
configurada com os testes na versão
estável, então a instituição ela já pode
utilizar FP para fazer as validações.
Acho que de novo aqui, para as
instituições que o fornecedor possui
conta aberta, o primeiro teste vai ser
necessariamente pelo fornecedor. Então,
se eventualmente tiver falha, forne, a
gente vai abrir ticket pra instituição e
a instituição, assim, ela pode
reexecutar por conta própria, ter
sucesso para encerrar o ticket, mas nada
impede da instituição por conta própria
de executar para antecipar eventuais
falhas e pegar alguma correção, tá? Já
já estamos tentando pensando nisso já.
Obrigado. É ótimo.
Legal, João Pedro, fica à vontade.
Perfeito. E boa tarde. Tudo joia? O meu
é só um ponto, mas especificamente pode
ser que às vezes você comentou e eu que
não me atentei, mas com relação às
notificações, já que a área de gestão
ela só vai ficar ali para as detentoras
de contas no início do Gol Live, né? Eh,
fica subentendido então que a
notificação ela não necessariamente
precisa ser implementada agora, porque a
gente pelo pelo que eu tinha entendido,
né? É algo opcional, tem que ficar com
opcional para detentora e o usuário pode
habilitar na área de gestão. Tanto que
área de gestão só sai de
16. Fica subtendido então com a
notificação também só fica nesse cenário
ou eu compreendi algo errado nesse
ponto? Não sei se vocês conseguem me me
validar isso. A parte de notificações
das detentoras vai ser é esperado que
esteja pronto a partir de 16/06, tá?
Então a gente não vai fazer nenhuma
validação desse aspecto nesse momento.
Perfeito. E aí, só um segundo dúvida,
Fabi. Eh, quando a gente fala da FP, eu
entendo que a partir do dia 22 já começa
a rodar os testes, né? Se eu entendi
corretamente. Só o SLA que não ficou
claro para mim. Eh, ele vai seguir o que
já tem hoje ou por que que eu tô
perguntando isso? Que eu lembro que para
JSR a gente teve uns pontos específicos
que os tickets que caíssem era o ideal
era responder até em dois dias úteis.
Não sei, não sei se aqui a gente vai ter
um cenário parecido por fix automático
ou se os SL vão ser diferentes com
relação a à FVP e os tickets que a gente
receber bilateral de bilaterais, né? Tá?
Eh, pessoal, os tickets eh da FVP vão
seguir o modelo padrão. Eh, o que acabou
acontecendo dentro de JSR, o Banco
Central acabou determinando que, eh, em
alguns casos os tickets de JSR deveriam
ser tratados em dois dias úteis, mas
isso não foi uma determinação aqui da
estrutura e também não foi não acabou
mudando no na própria plataforma do
Service D que não mudou o SLA. Então
aqui nós não estamos prevendo a mudança
da SLA. Tem só uma ressalva que é na
etapa na etapa final do do cronograma as
instituições vão eh Iago consegue voltar
lá naquela tabelinha das regras do do
Warroom. Aqui a gente precisa que as
instituições estejam com os tickets
resolvidos até o final do piloto, tá?
Então, independente da SL, a ideia é
terminar o piloto com nenhum ticket
bilateral pendente, se não vai ser
sujeito a a warroom. Mas aqui a gente
também, caso o Banco Central entenda e
queira estabelecer eh um SLA um pouco
menor para algum cenário específico, aí
aqui a gente não tem visibilidade, tá?
Então pode ser que aconteça.
Perfeito. Obrigado,
Artur. Fica muito Opa, Iago, uma
pergunta em relação ali ao CS de
interoperabilidade, é uma palavra
difícil. Eh, a gente
tem a documentação em relação à
convivência, entendo que seja em relação
ali às às duas rotas, né? A gente tava
tentando levantar esses requisitos aqui.
A gente não tem,
por exemplo, criação numa V1 e consulta
pela V2 desse consentimento criado na
V1, tá? você falou sobre isso. Esse esse
aqui ele é sobre transferências
inteligentes. Ele não entra nessa parte
que aqui a gente tava focando no Pix
automático. Eh, e aí é a mesma PI, né,
de pagamentos automáticos, que tem dois
produtos separados dentro. Eh, a V1 ela
tinha só o produto de transferências
inteligentes. A AV2 ela vai ter o Pix
automático e transferências
inteligentes. Aí aqui esse aí eu não sei
o Wendels é se vocês já quiserem
responder, mas senão ia sugerir abrir um
ticket bilateral pra gente um tickete
pra estrutura pra gente conseguir tratar
isso aqui. É melhor, Fabi. A gente tá
vendo aqui que tem alguns tickets que
tão tão chegando pra gente, outros a
gente já conseguiu ir respondendo aqui
durante o
o workshop, mas eu acho que via de regra
para deixar documentado, seria bom ter
um ticket aqui. Perfeito, perfeito. A
gente abre aqui, então. Obrigado,
pessoal. Eh, eu acho que logo, só
complementando a informação, pessoal,
boa tarde. Logo logo vai ser lançado um
informa sobre a retrocompatibilidade
também, tá?
com a decisão do GT Serviços ali do que
foi necessário fazer para manter a
retrocompatibilidade das consultas.
Tá perfeito. Valeu,
boa. Beleza, Alexandre, fica à vontade.
Boa tarde. Eh, eu queria entender aqui
eh a questão do ali dos da necessidade
de 200 pagamentos liquidados. Não ficou
muito claro para mim. É, o que que e
considerando que o piloto é pra gente
testar em produção os cenários, né? Eh,
a princípio a gente não tem 200 cenários
diferentes. Então, eu queria entender o
que que o que que levou essa necessidade
de tantos pagamentos liquidados, visto
que não tem tantas variações, tantas
variações assim, o que que a gente
ganha, mas qual é a diferença entre ter
um teste de cada cenário e ter vários e
vários testes de um mesmo de um mesmo
cenário?
Aqui é pra gente conseguir estressar
mesmo, tá? É pra gente conseguir ter uma
volumetria mínima aqui durante o piloto
pra gente conseguir entender se as
implementações estão funcionando
adequadamente. Então, não vão ser vários
cenários, eh, mas a ideia é que consiga
ter 200, mesmo que seja do mesmo
cenário, tá? Que consiga fazer 200
pagamentos. Então, a ideia era a gente
conseguir ter uma volumetria mínima para
trazer a confiabilidade na
implementação.
Hugo,
eu de novo. Uma pergunta. Eh, como é que
o pessoal que vai fazer os testes vai
saber qual ambiente vai ser testado
desktop ou ou app? Eu pergunto isso
porque ficou definido que nesse primeiro
momento no piloto não precisaria
desenvolver em todas as a as
plataformas, né? Se tivesse um a maior
uma parte o canal principal, se fosse o
app, poderia ser desenvolvido só no app.
Se fosse uma questão e PF ou PJ, tem lá
as definições. Eu sei que tem que ter o
handoff, mas isso não implica de que a o
testador da FVP lá não vá saber qual que
vai ser o ambiente que ele tem que
testar. Então, se eu desenvolver só em
app, ele vai acabar testando em desktop
e eu posso estar recebendo um ticket
desnecessariamente, vamos dizer assim.
Certo? Acho aqui o Hugo. Então, diga lá,
Fabisca, manda lá. Eu aqui sobre falando
sobre esse caso aqui do FVP aqui o
ambiente que a gente tá falando é o
ambiente da iniciação de da FVP, tá?
Então aqui a NFP, por exemplo, vai ter
pode ser iniciado via desesop Android
iOS a gente só fazer esse handoff pro
aplicativo. Aí aqui a gente não vai
testar eh todos esses 18 cenários em
desktop, iniciando no desktop, todos os
cenários em Android, não vai ser isso.
Então esses 18 cenários vão ser
variados, tipo, iniciando em desktop,
iniciando em Android, iniciando em iOS.
Aí aqui acho que abuição fazer sem
handoff. Então aqui a gente vai variar
esses cenários da FVP como iniciadora.
Beleza? Ficou claro?
Mas acho que um tem um ponto adicional
aqui, é, Hugo, a instituição ela pode
optar por não desenvolver a ela precisa
obrigatoriamente disponibilizar a
jornada no seu canal principal, mas não
significa que é o o usuário vai ter que
continuar a jornada de onde ele começou.
Então, vamos lá. Eh, vamos supor que o
canal principal aqui da caixa é o
aplicativo. Eh, você não precisa
desenvolver o browser, mas se eu inicio
uma jornada no browser, eu preciso ter
um randoff, eu preciso ter um mecanismo
para ser levado pro aplicativo. O
usuário não pode ficar perdido no meio
do caminho. Então, da mesma maneira, se
eu
tenho eh se o meu o meu principal é o
browser, eu posso não disponibilizar no
aplicativo, mas eu preciso garantir que
se o usuário começar de um aplicativo ou
de um browser, ele vai ser redirecionado
pro browser. Então, pode não ser
desenvolvido no canal final, mas o a
instituição é responsável eh por guiar o
cliente até o seu canal principal. Se
não for esse.
Compreendido,
Otávio.
Oi, gente, boa tarde. Tudo bem? Eh, eu
fiquei uma dúvida ali se Iago pode
voltar ali no cronograma, por
favor, ali que a gente fala ali dos
testes da FVP e tudo. Isso aí nas
detentoras, nas demais marcas. Eh, eu
fiquei com uma dúvida na seguinte forma,
eh, relacionado ali os lançamentos ali
do do pixel automático. Veja se eu tô se
eu tô com entendimento correto, tá? Eh,
a gente vai ter aqui esses testes da
FVP, as execuções ali, por exemplo,
executar os testes de cenário da
interoperabilidade, executar todos os
cenários de teste para
instituições. Eh, vai ser validado o
lançamento ali paraa detentora também
ali a nível de de extrato. Isso vai ser
um cenário de teste válido ou isso não
tá dentro ali do não contempla a FVP
ainda? Falando ali de demais marcas, tá?
Não sei se pode ter a divisão aí entre
marcas priorizadas e e demais marcas,
sabe? Certo? Aqui acho que tem, coloquei
aqui em backup um resumo desses testes.
As demais marcas elas vão ter que
executar. A gente vai executar na
verdade esses quatro primeiros testes
aqui, né? Então é o primeiro é o
agendamento que não vai ter um sem
cancelamento e um primeiro pagamento.
Vai ter um primeiro pagamento imediato
agendamento semanal criado e cancelado.
E tem dois cenários de garantia de
jornada. Então
estamos de meses foi torturada pelo país
pela esposa desadamente por misericórdia
mas a outra parte mantível e
obriança. Em resumo aqui as demais
marcas elas vão ter a execução desses
quatro primeiros testes. Então, dois
cenários de interoperabilidade com sem
cancelamento, com o sem agendamento
dessas dessas recorrências também
incluindo essa edição de consentimento.
Então aqui ela não vai ser validada a
liquidação em si. Então tipo são dois
são quatro testes que eles vão fazer até
esse agendamento, mas as liquidações
elas não vão não vão ser validadas.
Então acho que aqui é um teste que ele
vai ter uma duração de 15 minutos. a
gente vai verificar se o agendamento nos
testes que ele faz no agendamento, se o
agendamento ele foi de fato feito, mas a
liquidação dos agendamentos por serem em
dias posteriores a FPA por hora não faz.
Então que é exatamente um cenário desses
TED de longa duração que a gente tá
ainda em discussão em desenvolvimento,
mas em resumo é as as demais marcas não
vão ter essa verificação desse TED de
longa
duração. Ficou claro?
Ficou sim. Eu tava brigando com mudo.
Ficou. Ficou assim. Obrigado, cara. Por
nada, Vinícius. Lá. Boa tarde. Eh, eu
gostaria de saber se as demais marcas
irão receber um guia de
UX, por mais que não serão passar pel
não vai passar pela validação, mas irão
receber um guia ou não? ou vai receber o
guia do iniciador.
Eh, Vinícius, o guia de UX ele é o guia
igual para todo mundo, tá? O que a gente
não vai fazer é o guia de UX, é a mesma
documentação para todos. Aqui a gente
vai testar para ver se a IUX dessas
marcas priorizadas e das iniciadoras tá
de acordo com L partes do guia. Eh, mas
o guia, esperamos assim, todas as
instituições para todas as marcas devem
estar seguindo o guia. Aqui é só a
questão de priorização, quem a gente vai
testar isso ou não.
Perfeito. Obrigado,
Vinícius,
obrigado. Respondeu. Ah, era você que
tinha falado agora. me nomes. André,
obrigado. Sou eu agora. Eu tinha feito
uma pergunta no chat que era sobre a
quantidade de CPFs, né? Já me
responderam que não existe uma
quantidade mínima. Acho que isso é bem
preocupante para instituições menores.
Ã, mas eu queria fazer mais uma pergunta
agora, que é em relação às iniciações.
Fazendo uma conta de padaria aqui, eh, a
gente tem mais ou menos 7 a 11 TPs para
200 detentoras, né? Mais de 200
detentoras. E eu queria só entender um,
acho que não ficou tão claro para mim o
processo para a gente poder chegar no
número de 200 pagamentos. Eh, vamos
dizer se a gente tem algum problema numa
primeira requisição da ITP e a gente não
é mais priorizado por ela em outras
tentativas, né? Ela também só precisa
fazer 200 pagamentos. Então, qual que é
a expectativa de fluxo para que a gente
consiga chegar a todas essas 200
detentoras nesses 200 pagamentos?
André, a expectativa é que os times das
detentoras se mobilizem e façam os
pagamentos, tá? Por isso que a gente tá
pedindo a lista de assim, pode, não tem
uma lista mínima de CPF, você pode
indicar uma pessoa, essa uma pessoa vai
ter que ser responsável por garantir que
vai ter os 200 pagamentos ali. Então
assim, vai pode rolar um teste da FVP
que vai contar ali nesses 200
pagamentos. Pode eh a própria iniciadora
pode usar uma detentora que vai
contabilizar também. Posso até puxar
aqui para mostrar para vocês como que a
gente tem o, como que tá o painel hoje,
eh, de JSR, que acho que vai ser bem
parecido. Eh, posso, vou puxar a tela
aqui, tá, Iago? À vontade. Boa, pessoal.
Aqui é outro produto, tá? Então, mas só
para fazer um paralelo, a gente criou
aqui para para jornada sem
redirecionamento. As instituições têm
acesso a a esse painel. Aqui a gente tem
a taxa de consentimento, de criação de
vínculo, a taxa de criação de pagamento
e a liquidação. Aqui embaixo a gente tem
como que tá a quantidade de vínculos
para cada uma das detentoras e para cada
uma das ITPs. A gente tem a taxa de
sucesso dos vínculos, a taxa de
pagamento, a quantidade de pagamentos
iniciados e a taxa de pagamentos criados
com sucesso e os liquidados. Aqui,
imagina que a gente vai ter uma tabela
dessa, a gente vai colocar uma coluna
adicional, que é a taxa, o quantidade de
pagamentos liquidados, que é basicamente
os pagamentos iniciados vezes essa taxa
de pagamento. E no final do piloto, a
gente espera que todo mundo tenha pelo
menos 200 aqui. Então é, se eu sou uma
detentora, nenhuma, eu não fui chamado
nenhuma vez, eu preciso mobilizar o meu
time, usar as iniciadoras, a solução que
as iniciadoras disponibilizaram, o FVP,
e mobilizar meu time com tempo hábil
para que no final do piloto tenha esses
200 pagamentos. Até porque a gente tá
falando que aqui a gente vai ter 140
marcas eh de detentoras que vão estar
participando. As iniciadoras vão ser vão
precisar garantir que cada uma fez 200
pagamentos, mas ela não é responsável
por garantir que as 140 marcas vão ter
200 pagamentos cada, tá
certo? Aí, só mais uma dúvida. A, já é
esperado que as ETPs elas tenham uma
experiência de usuário eh que seja
liberada só para esses usuários
restritos que a gente passou CPFs ou
seria solicitações via backend? Sim, não
vai ter
uma, como que a gente vai ter aqui, tá?
Vamos lá. Sim, as iniciadoras precisam
disponibilizar uma jornada. Eh, a
jornada ela inicia no recebedor, aí o
usuário é redirecionado pro pro
iniciador e depois vai pro detentor,
segue o fluxo normal. A jornada do
recebedor, ela pode ser muito simples,
tá? Pode ser ali um front end só para
começar isso. A gente não vai validar se
tá seguindo guia, se não, nem tem no
guia a parte do recebedor em si, tá?
Isso a gente só precisa ter um ambiente
para dar um start. Pode ser, por
exemplo, parecido com motor de testes,
algo só para colocar uma parametrização
mínima. Aí o usuário vai pra página do
iniciador. Aqui a gente vai testar essa
jornada. Ela tem que tá disponível até
dia 5 de maio para todas as iniciadoras.
Quem não disponibilizar tá fora do
piloto. E aí todo o fluxo e a parte de
gestão também desse dessa autorização
também tem que estar disponível. E aí
aqui, eh, nesse período de piloto, ele
também vai ser diferente do de JSR,
porque não vai ser liberado para usuário
real, não vai ter base de clientes, não
pode ter um produto final, porque o
lançamento oficial desse produto, ele
vai ser em 16 de junho. Só que o que a
gente tá fazendo aqui é queremos
garantir que dia 16 de junho vai tá tudo
redondo. Então, eh, por isso que a gente
precisa tanto dessa mobilização dos
times. As detentoras vão ter que
disponibilizar a jornada para toda a
base de usuários. Quem vai filtrar quais
são os usuários que t acesso ou não são
as ITPs, tá? Então vou usar aqui o
exemplo. O Gustavo tava tirando dúvida
aqui, então vou usar o exemplo da Belvo.
Então aqui a expectativa é
o as detentoras não vão filtrar
usuários, mas o time da Belva, o time da
iniciador, o time da Plug, o time eh da
Finet aqui, eles serão responsáveis por
liberar apenas para a base de usuários
que a gente
disponibilizar, tá? E aí, por isso que é
importante a gente receber essa base
aqui, porque quando uma detentora quiser
atualizar a base, a gente vai precisar
que as iniciadoras atualizem ali também
os seus controles.
Fabi, deixa eu só também tentar fazer um
complemento aqui num talvez aqui na
pergunta do colega. Eh, acho que não sei
se ficou claro para mim, ele também
queria entender a relação ali, como que
ele vai conseguir saber se ele atingiu
aquilo que é necessário dentro dos 200
pagamentos imediato ou dentro do
percentual entre pagamentos imediatos e
e agendamentos recorrentes ali, né? Acho
que tem tinha um ponto, foi até um ponto
que eu conversei com Iago mais cedo ali,
né, Iago? as instituições deveriam estar
enviando a as iniciadoras deveriam estar
enviando a relação dos pagamentos de 10
a 10 de 2 a 10 dias antes do
encerramento do piloto para poder
atingir essa volumetria que é esperável,
né? Se você quiser naquele ponto ali
também acho que é legal.
Boa. Aí aqui Wend até bom ponto. Então a
gente vai fazer o acompanhamento ali. O
painel que eu tinha mostrado. A gente
ainda tá construindo o painel de Pix
automático, mas ele vai ter uma
segmentação entre o que é first payment
e o que é recurring payment, tá? Então
você vai conseguir ver dessa, desses 200
se conseguiu atingir ali os os 30 first
payments e
170 eh recurring pra gente para
conseguir ter essa segmentação. E aí,
ótimo ponto aqui, o recurring ele
precisa ter o ele tem o tempo de
agendamento que é feito de 2 a 10 dias
úteis, eh, é, acho que é 2 a 10 dias
úteis corridos, se eu não me engano. Eh,
então, pras instituições se programarem
para não deixar pro último dia e fazerem
esses pag fazerem esse essa
solicitações.
É dois a 10 dias corridos da Fabi. Não
são úteis
não. Eh, William.
Boa tarde, pessoal. Acho que só uma
dúvida também relacionada a essa
quantidade de pagamentos, né? Esses 200
pagamentos devem ser realizados só para
entender se são 200 pagamentos por marca
ou por organização. Até porque eu vi
aqui que minha casa vai ter mais de uma
marca ali na listagem. Só para entender
esse ponto, pessoal. Aqui a gente não
consegue hoje fazer a segmentação por
marca dentro do dentro do painel, porque
a PCM ela é por organização, então é por
conglomerado aqui, tá?
Perfeito.
Obrigado. Só mais um ponto.
Aproveitando, esse painel que você
mostrou, vi que era de JSR, mas vai ter
um desse de pixel automático para as
organizações também. Vai, tá em
desenvolvimento.
Perfeito. Obrigado. Imagina.
Gabriel. Eh, pessoal, boa tarde. Eu
tenho uma dúvida muito parecida com a
dúvida do André agora, com relação aos
200 pagamentos. Eu imagino que é a
dúvida de todo mundo, na verdade, tá
todo mundo perguntando sobre isso.
Eh, do lado da detentora aqui, vocês
falaram: "Ah, beleza, ela vai, ela vai
ter que disponibilizar o time para poder
garantir esses 200 pagamentos e tudo
mais. Eh, tá pacífico na minha cabeça
isso. Só que duas coisas. Eh, a
detentora, ela vai disponibilizar uma
lista de CPFs, né, de funcionários para
poder participar disso. E aí isso vai
ser compartilhado com as ilustradoras
para poder, enfim, eh, vamos pô assim, o
recebedor emitiu uma dívida em nome
desses funcionários, né? Falou num jeito
meio simplório aqui. Só que isso não é
obrigado da parte das adizadoras, né? No
caso assim, eh, vamos supor, a gente tem
10 detentoras, cada detentora indica um
funcionário, ou seja, vou ter 10
funcionários. As iniciadoras, elas podem
escolher só cinco desses funcionários
para poder fazer isso, né? Elas vão ver
obrigatoriamente pros 10. Porque a minha
dúvida é, assim como o André disse, a
gente tem muito mais detentora, né? Tem
muitas detentoras, então, eh, e a
obrigação fica muito em cima dela, né?
Eh, ela que que corre risco de não ser
exibida depois, caso ela não liquide não
liquide os 200 pagamentos. Então assim,
a minha dúvida é, se eu sou a detentora
X, o que que garante para mim que eu vou
receber um, esses pagamentos e dois que
eu vou receber no prazo eh a tempo, né?
Porque a gente tem não só first payment,
a gente tem recording payments também.
Então, se a iniciadora demorar para
lançar um pagamento para mim, eu
obviamente vou também demorar para
pagá-lo e aí talvez nem dê tempo de eu
fazer o recoring payment. Então, essas
dúvidas para mim não estão muito claras.
Se você esclarecer, eu agradeço
tá bom. Eh, Gabriel, aqui, eh, vamos lá.
Se aí, a iniciadora não pode escolher,
eh, se você indicou 10 funcionários, ela
vai ter que liberar pros 10
funcionários. Se forem solicitados eh 20
pagamentos, a iniciadora vai ter que
depois fazer ali seguindo o fluxo normal
dos 20 pagamentos, tá? Não tem uma uma
escolha aqui. Se por acaso não for feita
o agenda, vamos lá. você fez ali
uma autorização de um pagamento semanal,
caso ele não ocorra, é por uma questão
de problema bilateral, é um problema de
implementação técnico. Então a gente
precisa dessa conversa entre as casas
para garantir que a solução tá
funcionando, mas não tenho um vou
priorizar um em detrimento do outro.
Entendi. Então, todos os os CPFs que
foram disponibilizados por todas as
detentoras, todos eles vão receber, né?
Vão receber o Eu não entendi o que vão
receber. É o receber que eu digo é
porque o recebedor lá da ponta da
iniciador, ele é que eu não sei o termo
que vocês estão usando, mas ele vai meio
que emitir uma dívida em nome de alguém,
certo?
Eh, então esse esse alguém seria o
pagador. O pagador tá no lado do
detentor aqui nesse nesse piloto, né?
Não. Eh, vamos lá. A gente tem, eu vou
vou dar um exemplo aqui. Vamos lá. tem
um streaming. O streaming ele seria o
recebedor. E aí o recebedor fez uma
parceria com uma iniciadora para fazer o
Pix automático. E aí você, como usuário,
Gabriel, vai usar uma instituição para
você assinar esse streaming. E aí você
quer que o dinheiro saia da sua conta de
um banco. Sim. Então você não vai, eles
não vão configurar vários instituições
ali no equivalente ao streaming. O
streaming vai ter uma conta só que a
iniciadora vai definir qual vai ser a
conta que vai receber o dinheiro. E aí o
que vai ter é você como usuário, quando
for simular que tá assinando esse
serviço, vai escolher a sua conta do
dinheiro e aí isso não vai ter bloqueio
nenhum.
É para aparecer todas as listas. É para
aparecer a lista completa de marcas.
Sim. Eu digo, eu, eu digo do sentido do
pagador. O, o dinheiro do pagador tem
que sair de uma conta, sabe? É, é nesse
sentido que eu tô falando. Sim. Dinheiro
do pagador.
Essa essa detentora, a detentora do
pagador, ela tem que garantir a liquid.
Claro também, tá, Gabriel?
É o quê? Desculpa, desculpa. Desculpa te
interromper, eu falei que para mim
também não ficou claro a sua pergunta
aqui em relação ao que é
esperado. Ô, ô, pessoal, eu posso se eu
entendi, eu eu acho que a dúvida é não,
a própria, o próprio usuário da
detentora, ele vai simular a parte do
recebedor, certo? Eu não preciso esperar
que alguém vá lá e faça para
mim. É assim, né? Então, eu sou de uma
instituição do CCRED. A a conta de
débito vai ser a dos créditos, mas eu
vou entrar na página da detentora e vou
criar um consentimento para mim, certo?
Não, eu não preciso que alguém faça para
mim ou preciso.
Mas aí você tá abstraindo o papel do do
recebedor barra iniciadura. É porque eu
entendi, essa é a dúvida do de quem tava
falando ali, né? Eu precisaria que
alguém fosse pegar e criar um
consentimento para como pagador poder
dar o consentimento, né? É, eu acho,
você vai criar o consentimento, tá?
Desculpa cortar. Você vai criar o
consentar o consentimento, só que você
vai criar com a ajuda de algum
iniciador. Sim, com algum iniciador, mas
eu não preciso que vá o recebedor ou o
iniciador lá clicar comigo na na no
ambiente, certo? Não, não, não precisa.
Então eu mesmo vou entrar lá, vou
contratar o streaming, né? Eu fui lá e
contratei o streaming. Eu não precisei
que ninguém fosse lá e fazer um pedido,
né? Não, na verdade a a iniciadora vai
disponibilizar um ambiente ali de teste
também, né? Uma página aonde você vai
configurar
toda ah vai poder ser até R$ 100, por
exemplo, todo dia tal. Então, a própria
detentora, o usuário que tá testando da
detentora, vai ter acesso ao ambiente da
iniciadora, a configurar todo esse
pagamento e aí depois a in fica a cargo
da iniciadora enviar a solicitação da
liquidação ali pra detentora. Então, a
gente não vai a gente não vai eh
precisar depender da iniciadora fazer
essa essa parte, entende? Então nós da
detentora mesmo aqui vamos poder eh ao
saber, né, quais são as iniciadoras que
estão participando aqui, acessar os
ambientes que eles vão disponibilizar
ali para configurar tudo e testar os
pagamentos certinho? É, para mim ficou
claro, essa era a visão que eu tinha,
tá? Desculpa. Eh, mas aonde que eu vou
fazer as as aprovações? Você tá dizendo
que você não vai receber nenhum tipo de
notificação ou não vai receber do
iniciador, pro detentor nenhuma
informação. E aí quando eu for entrar no
nas instituições ali que eu tenho conta
que são detentoras, vão existir
consentimentos criados com os parâmetros
que foram definidos aqui dentro do
piloto. É isso, Carol? Carol? Não, não.
Eu acho, Wend, que a dúvida era se a
gente precisaria aguardar ou o iniciador
ou o recebedor aqui no papel do
streaming que a Fabi deu deu o exemplo,
se a gente precisaria que eles eh eh
fizessem a primeira ação ali, né? Então,
que eles eh eh mandassem algum tipo de
configuração anterior ao usuário. E aí a
gente entende que não, né? Então, tendo
os CPFs cadastrados ali, a lista de CPFs
do de que vão participar, a iniciadora
vai liberar essa funcionalidade para
esses CPFs. Esses mesmos CPFs vão ter
acesso ao ambiente da iniciadora para
fazer toda a configuração. Então, a
gente não depende nem do recebedor e nem
da iniciadora, de uma ação inicial da
iniciadora para fazer esse teste
acontecer.
Exatamente. É essa a minha dúvida mesmo.
Obrigado, beleza. Entendi. Entendi. Eh,
eu eu tenho eu tenho uma eu tenho mais
uma dúvida aqui. É, eu acho que tá
pacificado aqui. Eu acho que a gente
Não, eu acho que é isso mesmo. Tá aí. É,
eu tenho mais uma dúvida aqui, Vittor.
Você puder voltar ali na na página que
tava sobre os 200 pagamentos, só para
clarificar um ponto. Eh, esses 200
pagamentos aqui, eu não sei se ali na Eu
não sei, Fabi, se a gente tem essa
clareza na PC, na no FVP, desculpa, a
FVP ela vai fazer esse fim a fim, ou
seja, através da FVP, eu também vou
gerar solicitações de liquidação. que eu
não ficou claro daqueles daqueles
cenários que estavam previstos ali de
teste da na pela FVP, se esses 200
também fazem parte ali da conta, tanto
paraa FVP quanto para pros testes feitos
fim a fim aqui entre iniciadora e
detentora fora da FVP. Perfeito. Esse
até fiz uma errata aqui. Vamos lá. Que
acontece? A gente tem o post, o post pix
payments que vai criar o pagamento. A
gente vai ter depois o get Pix Payments
para ver qual é o status da liquidação.
Hoje os testes da FVP eles duram 15
minutos. Eles não pegam o status
posterior de um agendamento que
aconteceu ali vários dias depois. Então,
mesmo a gente podendo usar FVP hoje, eh,
como a gente não consegue fazer o get
dias depois, eh, isso não vai para PCM,
então acaba não sendo contabilizado. A
gente tá desenvolvendo, deve ficar
pronto durante o piloto, ele lá pro meio
do piloto, um teste de longa duração que
vai conseguir fazer isso, mas a
princípio, pelo menos nesse começo, não
vai dar para usar os testes da FVP paraa
liquidação, tá? Porque a gente não vai
que a gente não consegue fazer o get.
A gente consegue só o do first
payment, tá? Acho que só acho que só
complementar, mas o first payment não
vai ser contabilizado nos 200, então é o
que eu tô entendendo.
É isso, Carol. Acho que só
complementando aqui, FP, ela tem teste
que faz o cancelamento e que de fato faz
a liquidação, mas para ser
contabilizada, ela tem que ter esse get
para ser contabilizado na PCM. Então,
como FP são testes de curta duração, ela
não vai fazer esse get para ver se foi
contabilizado os agendamentos, tá? Mas
não tem first payment imediato na PCM.
Sim, first. O first payment entendo que
sim, mas os agendamentos eles não vão
ser contabilizados.
Mas o first payment conta é como um
deles, então, certo?
Sim. Se for liquidado, sim. Avp ela tem
t que faz eh tem na hora que faz o getp
vai fazer o envio, né? Tá beleza.
Exatamente.
Beleza. Iago.
Obrigada. Lembra do nosso projetinho da
FS?
Tá, pessoal, acho aqui, não sei se mais
alguém tem alguma dúvida, acho que
demais eh mais agradecer a participação
de todo mundo aqui. Então, se tiverem
mais dúvidas, h, solicita que essas
dúvidas sejam encaminhadas via service
desk aqui paraa estrutura, pra gente
responder lá pelo pelos próprios
tickets. Acho que de novo, só reforçando
algumas mensagens, é, esse workshop
aqui, ele foi tá sendo gravado, então a
gente vai pegar essa gravação e vai
colocar no YouTube do Open Finance
Brasil. E qualquer outras eventuais
dúvidas nos encontramos à disposição via
Service Desk. Então, demais, acho que
obrigado pela participação aqui de
todos. Esperamos que tenha sido uma
agenda produtiva aqui para esclarecer as
dúvidas de todo
mundo. Demais, muito obrigado aqui
todos. Uma boa tarde. Boa tarde.
Obrigado. Boa tarde, pessoal. Obrigado.
Boa tarde. Boa tarde. Tchau. Tchau.
Boa tarde. Obrigado.