Jornada sem redirecionamento (JSR) - Workshop Open Finance Brasil (13/08/2024)

E aí
Fabi Olá tudo bom pessoal boa tarde aqui
só
dando uns minutinhos aqui pra gente
começar perfeito então encaminha aí o
e-mail para o link para todo mundo aí
dos times de
vocês boas tardes tudo bom pessoal
ock quer
colocar acho que vale né Tem uma
musiquinha de espera aqui né pessoal
Olá boa tarde
[Música]
h
[Música]
[Música]
[Música]
[Música]
pessoal geralmente a gente sempre espera
uns CCO minutinhos mas acho que a gente
já tá com 200 pessoas aqui na sala Eh
vamos Começando aqui então primeiro
queria agradecer a presença de todo
mundo acho que conforme os outros
modelos de workshop que a gente tá
fazendo aqui eh esse workshop vai ser
gravado a gente vai disponibilizar a
gravação depois vou pedir para dúvidas
eh levantarem a mão e pode mandar no
chat também que a gente vai respondendo
aqui no paralelo Qualquer coisa a gente
ou responde na durante a apresentação ou
responde pelo chat E se sobrar alguma
dúvida a gente vai fazer um compilado
adicionar no material que a gente vai
compartilhar com vocês depois tá então
primeiro Boa tarde aqui teremos o o
workshop que vai ser bem dividido aqui
então a gente tem um super time para
apresentar Então a gente vai ter o
Felipe o nick O Wendel o Zé o Paulo
Thomas o Cristian e eu aqui a gente vai
passar por alguns temas aqui da agenda
eh queria agradecer muito eh a
participação de vocês não só aqui no
workshop mas também para todo o
desenvolvimento do produto
eh e os temas que a gente vai tratar
hoje tá então primeiro a introdução à
jornada sem redirecionamento então o que
que é essa jornada sem redirecionamento
por que ela existe Quais são os casos
que ela viabiliza Quais são as
funcionalidades dela e a gente vai
entrar num aspecto mais técnico então
detalhamento das especificações e
apresentação do swager
depois a certificação do Servidor fidal
então é a o o servidor fidal ele é uma
novidade aqui que entra com a jornada
sem redirecionamento então o que que é o
protocolo fidal Como que você faz a
implementação como que é a questão da
certificação eh depois o a gente vai
entrar no tema aqui sobre o desafio para
as iniciadoras Então quais são as
complexidades Como que o que tem de
diferente de uma jornada de iniciação de
pagamento tradicional O que que a gente
vai ter num aor de conformidade
funcional Então quais são os testes que
vão ser exigidos paraa certificação eh
aqui já voltado para as detentoras e por
último o que que é esperado das
instituições Então como vai ser o
processo de certificação a gente vai ter
uma etapa nova que é o piloto Então a
gente vai entrar no detalhe aqui então
para começar queria passar a palavra
aqui pro Felipe e pro
Nick perfeito pessoal boa tarde bom
então acho que essa dinâmica vai ser
interessante aqui pra gente tirar
principalmente dúvidas do ecossistema né
que tá acompanhando aí a Desde o ano
passado a gente trazendo novidades eh
regulatórias aqui e autorreguladas
também eh e a gente espera realmente
trazer aqui no final né um fac até bem
completo trazendo bastante das questões
que a gente observou aqui nesse último
ano para para que a gente possa
realmente esclarecer todas as dúvidas Tá
bom então Eh sem mais delongas aqui e
trazendo aqui essa essa esse histórico
né Acho que não não é todo mundo que tem
realmente visibilidade disso né mas a
gente teve ali eh o banco central
estabelecendo essas diretrizes aqui do
da do que hoje né seria a jornada sem
redirecionamento eh ali em abril né e
maio a gente já teve ali um KickOff da
da jornada des redirecionamento né aqui
como um um grupo dentro do Open finance
Nossa Squad né E essa Squad aqui tá
trazendo Exatamente Essa apresentação
aqui para vocês esse workshop né e aqui
a gente eh logo em seguida né até
relativamente rápido a gente já teve ali
uma deliberação no conselho trazendo
essa espinha dorsal que a gente vai
apresentar aqui hoje né então tivemos
ali em seguida o lançamento da versão
1.0 dessa api nova de vínculo de contas
né eh e agora recentemente a gente teve
então o lançamento da resolução que traz
aí o as regras regulatórias né sobre a
jornada sem direcionamento então agora
no começo desse mês a gente teve a a
resolução 406 407 ali ela eh trouxe
também aqui um as diretrizes com relação
ao que a gente vai ter aqui como piloto
né então teremos um piloto já com 99%
aqui da detentoras participantes do
ecossistema do Open finance já nesse ano
mesmo em novembro e é esperado um go
Live para toda todo o cidadão para toda
a população aqui em fevereiro do ano que
vem então pode passar por favor
Fabi Afinal então como vai ficar o ux
disso que a gente tá apelidando aqui de
pix por biometria né então mostrando
diretamente já de cara aqui para quem
nunca viu essa jornada funcionando uma
vez configurado tudo como que fica então
pro cidadão para pra pessoa lá na ponta
então imaginando um caso em que você aí
tá num e-commerce né daí vai fazer aí a
compra de um de um
eletrodoméstico aí você pode ir passando
tá Fabi que tem bastante slide a a o a
pessoa clica em comprar e ela vai então
selecionar para utilizar o saldo de uma
das contas que ela já havia conectado
aqui e feito o pareamento do dispositivo
pode
passar Então essa pessoa vai confirmar
né então confirma ali eh no estilo pix
mesmo né então para quem Da onde a forma
de pagamento aqui via esse Open finance
com o dispositivo sendo utilizado para
autorização e aí uma vez clicando em
autorizar aí que vem realmente a grande
novidade que a gente tá inserindo aqui
enfim o open finance Brasil tá sendo
realmente Pioneiro em trazer isso pro
mundo Open no mundo né que é utilizar o
sistema fidal Essa é a tela fidal então
aqui é o dispositivo do usuário que tá
sendo utilizado para verificar se o
usuário realmente ele ele quer fazer
aquilo né então ele confirma né pode
passar e é isso o pagamento Tá Feito
então Fica muito simples né e de fato
sem redirecionamento Mas como que isso é
possível então você pode passar por
favor Como que essa jornada inteira
consegue ser tão fluida assim né com tão
poucos passos e sem redirecionamento
pode
passar graças a essa tecnologia que Eu
mencionei o fidon né então fidon é uma
tecnologia que relativamente já é
relativamente é velha na verdade né já é
conhecida aqui do do ecossistema de
desenvolvimento web né Eh está
amplamente disponível em dispositivos
Android IOS Windows Mac e e Chaves USB e
o que que isso de fato faz isso dá a
possibilidade de você utilizar um
dispositivo hardware para parear e ser
colocado ali num servidor de autorização
fle como o que o usuário utilizará como
autenticador então utilizando realmente
uma chave fidal pré né cadastrada ali e
pareada você realmente vai poder fazer
aqui eh transações eh utilizando
realmente uma chave que tá representando
eh você perante aquele itp perante
aquele detentor de conta né então é
importante eh observar aqui que existe
então um fluxo bem padronizado aqui o
open finance para fazer este pareamento
pode passar
Fabi então mostrando aqui como esse
fluxo de fato funciona eh dentro aqui do
ambiente do da instituição do iniciador
né você coloca qual é a sua conta que
você gostaria de parear aqui no
utilizando realmente o o open finance
pode
passar e aí sim um fluxo com
redirecionamento tradicional como que a
gente já conhece utilizando as mesmas
eh bases tecnológicas que nós temos aqui
no open finance para redirecionar o
usuário para instituição detentora de
forma segura né e colocando aqui pro
usuário então que ele vai fazer a
autorização para o vínculo de um
dispositivo né o dispositivo nesse
exemplo aqui é o próprio celular de
Alice né então el tá autorizando a que
esse dispositivo e com essas datas aqui
né de prazos e limites possa de fato ser
utilizado para aprovação de pagamentos
no ambiente do itp Então pode
passar e o redirecionamento de volta a
uma vez autorizado realizar este vínculo
aqui no Passo oito é feito então um
gesto fid para o vulo vínculo ser
efetivado Então pode passar Nick eh vem
uma pergunta aqui no chat que acho que
vale a pena responder agora como o
usuário chega na tela de vincular a
conta do iniciador na primeira compra
dele é só um ponto eu acho que vale a
pena a gente deixar as perguntas lá
paraa parte de fac porque a gente vai
ter uma cadeia aqui já de várias
perguntas mas por favor mandem todas as
perguntas não esqueçam delas que aí a
gente realmente responde todas de uma
vez só acho que vai ficar uma dinâmica
melhor pode ser Fabi boa fechou CTO
quase 500 pessoas aqui na sala e aí eu
chama aqui o meu caro Felipe para
apresentar sobre esses conceitos bases
aqui que realmente trouxeram a gente até
esse ponto na jornada sem
redirecionamento favor FIP Maravilha
obrigado Boa tarde a todos bem para
aqueles que não me conhecem Meu nome é
Felipe Barros eu sou gerente de
estratégia em tecnologia na Accenture E
também faço parte do Squad jcr Gostaria
de compartilhar aqui com vocês um pouco
sobre o conceito do serviço e principais
casos de uso e em primeiro lugar eu eu
diria que a jornada sem redirecionamento
ela é uma inovação no processo de
pagamentos atualmente quando realizamos
pagamentos online especialmente via PX é
comum que a gente seja redirecionado
para um ambiente do banco para completar
a transação isso envolve Sair do site ou
do aplicativo onde estamos fazendo a
compra e entrar na interface do banco né
O que pode que pode ser uma etapa
demorada e propensa a abandono de compra
com a jornada sem redirecionamento a
gente tá introduzindo uma nova forma de
realizar pagamentos é um serviço que
permite que o pagamento seja feito
diretamente no ambiente do e-commerce ou
no aplicativo do itp sem que o usuário
seja precisa acessar o canal do banco e
tudo acontece acontece de maneira
integrada e fluida sem a necessidade de
redirecionamento simplificando de forma
significativa a jornada de pagamento
especialmente via PX esse produto ele
ele surgiu com o propósito principal de
melhorar a experiência do usuários nos
serviços de pagamento é uma forma de
pagamento fácil simples instantânea sem
complicações e sem interrupção e claro é
importante falar também que com toda a
segurança necessária Vale ressaltar que
a iniciação de pagamento sem
redirecionamento ela passa por um
processo rigoroso de autorização de
forma que as transações continuem
seguras respeitando as regras de
negócios que permitam aos bancos barrar
pagamentos via PX em caso de suspeita de
irregularidade e falando sobre um pouco
qual problema soluciona o primeiro deles
como Nick e eu já abordamos aqui o
cliente não precisará mais sair do
e-commerce para realizar o pagamento E
além disso Vale ressaltar que essa
tecnologia é inclusiva porque ela pode
permitir que uma parcela da população
que não tem acesso a produtos de crédito
eh eles têm uma experiência de compra
mais eficiente e acessível eu pedi aqui
Fabi para você passar pro próximo slide
por
gentileza legal agora eu queria focar um
pouco mais sobre alguns casos de uso que
exemplificam o poder desse serviço
pagamentos em comerce aqui como falamos
antes o cliente pode finalizar sua
compra diretamente no site do
comerciante em apps de mobilidade como
apps de transporte US os usuários
poderão pagar suas corridas diretamente
no aplicativo sem a necessidade de abrir
um navegador ou ser redirecionado para
algum tipo de interface bancária em
marketplaces que conectam compradores e
vendedores em uma única plataforma eles
podem capturar esses os benefícios desse
serviço o pagamento ele pode ser feito
de forma direta entre as partes sem
complicações e simplificando a
experiência tanto de compra quanto de
venda doações e campanhas de
financiamento coletivo a ausência de
redirecionamento simplifica o processo
pode permitir que doadores contribuam
diretamente sem Barreiras
adicionais transações entre usuários aos
aplicativos de pagamento social podem
habilitar transferências de dinheiro
entre usuários de forma rápida e simples
e isso é ideal para para caso de divisão
de contas ou envio de dinheiro para
amigos e familiares de maneira
instantânea e finalmente a jornada sem
redirecionamento também pode ser
integrada em pagamentos presenciais é o
caso de um cliente pagando com qrcode ou
via NFC diretamente do aplicativo do itp
sem ir a um terminal de pamento O que
torna as transações mais rápidas e
seguras tá a gente queria aqui dar um
Panorama geral sobre alguns exemplos né
de como a jornada sem redirecionamento
pode ser ser aplicada em diferentes
contextos de forma proporcional ao
usuário o pagamento de forma mais fluida
segura e inclusiva tá eu concluo aqui
minha parte agradeço a atenção de todos
me coloco à disposição para tirar
dúvidas no final do workshop vou passar
aqui a palavra para pro José que é o
nosso especialista em a p e vai falar um
pouco sobre os pontos técnicos que que
viabilizam essa
solução Boa tarde pessoal eh eu sou o
José José Chavier trabalho na Cídia como
arquiteto de sistemas atua ali dentro da
estrutura da Squad como especialista de
apis eh eu vou navegar com vocês aqui
dentro dos principais pontos que a gente
tem na especificação tá os pontos
técnicos eh antes eu só queria balizar
um conhecimento aqui para ficar todo
mundo na mesma página que é para assim a
gente recebeu bastante perguntas
relacionadas a isso então eu acho que
vale a pena a gente gastar um minutinho
aqui para isso que é a diferença entre o
vínculo e o consentimento tá é
importante a gente ressaltar que como o
nick falou o vínculo ele representa um
dispositivo que o cliente autorizou que
consentimentos fossem autorizados a
partir dele né que acontece aquela troca
de Chaves comun que deixou bem claro e é
assim é só pra gente deixar claro que
isso é o vínculo o vínculo é a vontade
do cliente e autorizar o dispositivo
enquanto que o consentimento ele ainda
continua sendo a vontade do cliente em
realizar a transação tá então o vínculo
é a permissão do cliente para um
dispositivo específico enquanto o
consentimento é a vontade do cliente em
realizar a transação Então os dois
continuam existindo
normalmente tá
eh dito isso eu vou entrar na explicação
da máquina de de estados Fabi Você pode
passar por
favor perfeito aqui na máquina de estado
como vocês podem ver nós temos seis
estados diferentes né
são cinco estádios Inter são quatro
Estados intermediários e dois finais né
de estados finais a gente tem o ejected
e o revoked os outros demais são
intermediários alguns com prazos
determinados e outros com prazos
indeterminados né Eh
falando um pouco aqui do início
né O que é o que é o enrollment o que é
o vínculo o vinco ele é um recurso
criado dentro da detentora né que ele
passa por um processo de autorização
como o nick mencionou antes então ele
tem o fluxo de autorização
eh e após a autorização ele pode ser
utilizado pelo cliente né a máquina de
estados ela tenta representar esse todas
as etapas desse fluxo Inclusive a etapa
em que é permitido o uso tá Então a
gente tem como primeira etapa o a o aing
Risk signs né que é quando o iniciador
eh a partir da manifestação da vontade
do cliente faz um post dentro da
detentora que é o post enrollments que a
gente vai passar na P Já já esse
enrolment ele cria o recurso o recurso
nasce com estado aing risky signos
eh ocorre então ali o envio dos sinais
de risco pro
vínculo dentro desse estado e ele passa
para wearing account holder
validation esse estado ele representa a
autorização expressa do cliente tá então
o cliente nesse estado ele vai ser
redirecionado pro ambiente da detentora
e ele vai precisar eh autorizar aquela a
criação daquele vínculo entre o
dispositivo o cliente a itp e a conta de
débito específica tá eh
uma vez que que o usuário autoriza esse
esse vínculo o vínculo passa pro estado
a enrollment né que é o estado em que o
iniciador vai solicitar pro usuário a
criação das credenciais fel que vão ser
utilizadas nesse init Então vai ser
exibido pro usuário a a solicitação né
que pode ser ele vai poder responder
depend eu acredito que depende do
sistema operacional e algumas outras
coisinhas que ele pode de utilizar a
biometria ou a senha do celular
ou leitura facial Então dependendo do
sistema
operacional e uma vez que esse enrolment
é enviado que essa credencial Fido é
enviada pro detentor o detentor aplica
algumas validações e estando tudo certo
esse enrollment vai para authorized e
permanece em authorized até que chegue a
data explícita de inspiração definida
pelo cliente ou que algum que algum um
alerta ou alguma coisa aconteça dentro
do detentor ou do iniciador né
internamente que exige a revogação desse
vínculo ou até mesmo a vontade explícita
do cliente de entrar em um dos dois
aplicativos tá ele vai poder revogar o
vínculo a partir de qualquer um das duas
pontas Então ele pode entrar tanto no
iniciador e revogar o vínculo quanto no
detentor e revogar o vínculo
eh acho que é isso acho que a gente pode
passar pro próximo Fabi por favor
eh falando um pouco dos end points em si
agora da api né Eu tentei separar eles
aqui vocês podem ver que é um conjunto
pouco grande alguns Alguns eu criei
algumas categorias aqui pra gente poder
ter uma digamos assim uma noção mais
simples do que é que é aplicável cada um
dos end points tá então durante o
processo de enrollment de criação do
vínculo né a gente tem a utilização
desses quatro end points Eles não estão
em ordem tá aqui de utilização mas a
gente utiliza os quatro né o iniciador
ele cria um enrollment a partir do post
enrollment eh o involv Como Eu mencionei
antes ele nasce em a Risk signos esses
esses sinais de risco são enviados a
partir desse post enrolment enrolment aí
de Risk signos né após isso o usuário
coleta as credenciais do eh cria as
credenciais junto do usuário né e envia
as credenciais pro detentor essa parte
antes de criar a credencial ele precisa
fazer um F registration options para
entender quais são os tipos de
credenciais aceitas no authentication no
authorization server do do detentor eh
com isso ele envia as credenciais no f
registration depois tá Eh caso
o caso o iniciador queira consultar um
vínculo já existente ele pode fazer uma
consulta a partir do id específico no
get enrollment enrollment ID como Eu
mencionei a revogação ou a rejeição
podem ser feitas a partir das duas
pontas Então se o iniciador quiser
revogar ou rejeitar um vínculo ele pode
chamar a partir do patch involvement ID
eh para autenticar um dispositivo
durante a jornada de iniciação de
pagamento o detentor vai precisar
utilizar o fid signing options né ele
vai pegar o o as opções de login do
detentor para ele poder vai tá a
autorização e no momento de autorizar o
consentimento ele vai ter um campo aqui
dentro do autoriz que ele vai mandar o
file do assertion e ele vai mandar tanto
a solicitação de autorização quanto os
dados da
chave por favor Fabi pode ir para
próximo aqui agora falando um pouco dos
fluxos de autenticação e autorização que
a gente colocou na na page involvement
né eu separei aqui o que é o que é
client cre e e os scopes utilizados né
então para esses primeiros cinco end
points aqui todos eles utilizam-se do
fluxo client credentials tá com escopo
de pagamentos os o fidal registration
options e o fal registration el
utilizam-se de authorization Code com
aqueles scopes específicos enquanto que
o consent consent de autoriz ele
também utiliza authorization code porém
ele tem um scope a mais que é o nrp
consen tá esse scope ele é para poder
Esse scope ele é para deixar claro que
aquele consentimento tá sendo autorizado
a partir da jornada sem
redirecionamento lá durante no momento
da liquidação do pagamento também vai
ser repassado esse mesmo scope e vai
poder ser feito o Mat do consentimento
porque se for uma requisição originada
no na jornada Obrigatoriamente o b do
pagamento vai receber o conente ID Então
você vai poder entender que aquele é um
NR enroll um nrp consent para aquele
consent ID específico e você vai poder
fazer o match para poder autorizar
eh acho que é isso Fabi por favor pro
próximo aqui é para assim a page
involvement Ela ainda tá passando por
melhorias né a gente ainda vai Popular
ali o header dela deixar ela bem
parecida com com o headed Up aí de
pagamentos então ter todas as
orientações ali então eu achei melhor
trazer essa clareza do que é os motivos
de revogação e os motivos de rejeição
que estão presentes ali dentro
justamente para não dar essa impressão
que não que não tem né validações assim
só porque não tá no header
então aqui é para deixar claro que a api
ela tem dois duas digamos assim reje
dois motivos de cancelamento possíveis
né que um deles é a rejeição e a outra e
o outro é a revogação a revogação se
difere da rejeição no fato de que você
só pode revogar algo que já foi
autorizado tá então se já tem um um
vínculo autorizado você só vai revogá-lo
se o vínculo não foi autorizado ainda
você rejeita tá então falando aqui dos
motivos de revogação que a gente tem na
pi a gente tem o revogado manualmente
que significa que o usuário entrou
explicitamente no aplicativo do detentor
do ou do iniciador e solicitou a
revogação a gente tem revogado por
validade inspirada né Que o usuário
definiu uma data de inspiração e a data
foi atingida o refogado falha
infraestrutura porque dentro do detentor
aconteceu algum problema no banco alguma
coisa assim ele perdeu os dados daquele
vínculo ele precisa oficializar isso e
revogar isso pro iniciador também ter
ciência que ele não vai mais poder usar
eh revogado segurança interna né caso um
vínculo já autorizado depois de uma
verificação secundária foi identificado
em um outro momento qualquer que aquela
conta de débito eh tá com suspeita de
fraude alguma coisa assim então o tanto
o iniciador quanto o detentor tem
capacidade de revogar por esse motivo tá
eh e a gente também tem um revogado
outro né Porque assim a gente não tem
como ser tão exaustivo assim em todas as
razões então caso alguma razão não
esteja mapeada aqui de revogação você
pode preencher esse revogado outro e
mais detalhe Você pode adicionar no
campo additional
information próximo Fabi por favor
aqui são os motivos de
rejeição como eu falei anteriormente
eh os motivos de de de rejeição eles
precisam ocorrer antes do consentimento
ser autorizado antes dele ser autorizado
a gente tem as três etapas anteriores né
que a gente viu lá na máquina que é o
aing Risk sign a validation e ating
enrollment esses três estatos precisam
já estar mapeados como motivo de
rejeição caso Aquele caso o o processo
necessário não tenha sido seguido
durante o tempo determinado lá na
máquina a gente tem 5 minutos para
Sinais de risco 15 minutos para para
validação do cliente e mais 5 minutos
pro envio do enrollment tá já o máximo
challenge atingido ele é uma política da
própria detentora que assim a gente aqui
não determinou uma regra de quantidade
de challenges eh se o protocolo tiver o
peço que o o próximo que vier me
complemente Mas eu acredito que não
tenha
eh uma quantidade máxima permitida de
tentativas pelo protocolo eu acho que
fica a cargo de cada instituição a gente
não determinou aqui também nenhuma
política específica sobre a quantidade
de challenges permitido para cada para
cada tentativa de vínculo tá então fica
a cargo da instituição definir essa
regra o rejeitado manualmente significa
que digamos naquela tela de autorização
ali o o usuário não tenha autorizado ele
tenha clicado em rejeitar então foi
rejeitado manualmente especiamente pelo
usuário durante a autorização
dispositivo incompatível por quê Porque
o como vocês viram a a coleta do do F
ele não necessariamente precisa ocorrer
no início do da jornada tá então caso o
iniciador crie por exemplo um um
enrollment e na hora de coletar ele
perceba que aquele dispositivo não é
compatível com a coleta
ele pode simplesmente rejeitar aquele
enrollment por dispositivo incompatível
tá e Vida que Segue
eh falha infraestrutura Então se Ocorreu
algum problema dentro dos sistemas
internos tanto da iniciadora quanto da
detentora para processar aquela
solicitação de vínculo né eles
podem rejeitar por falha infraestrutura
segurança interna segue a mesma lógica
da revogação né então se durante a o
vínculo você identificar que uma uma das
pontas ali ou a ponta recebedora ou se a
detentora tiver uma não tiver confiando
muito nas informações que estão vindo
ela pode rejeitar por segurança interna
aquele vínculo eh rejeitado por falha no
Hybrid Flow quer dizer que alguma coisa
na comunicação entre as instituições que
utilizam especificamente tá essa é a
grande diferença entre o fal
infraestrutura e o Hybrid Flow
infraestrutura ele é dentro das próprias
instituições ou em comunicações com
sistemas externos da instituição apenas
da da instituição e não com a iniciadora
tá
então qualquer problema que dê dentro
dos sistemas internos ou de terceiros da
instituição fica como falha a
infraestrutura agora se der um problema
na comunicação entre a instituição e a
iniciadora falha Hybrid Flow tá eh
rejeitado falha fid então deu algum
problema dentro dos autoriz server
durante o processo de validação ele pode
ser rejeitado por esse motivo se deu
algum problema dentro do do
authorization server do fid né D
do F e o rejeitado outro é porque a
gente não
foi da última vez né a gente não tem
assim a Audácia de dizer que foi
exaustivo então e tá aí para caso a
gente caso algum dos motivos não mapeado
soor você pode preencher utilizando
additional information para explicar
melhor os
motivos pro próximo
Fabi aqui agora falando um pouco dos
limites pessoal assim também foi algo
que a gente recebeu bastante
questionamento ali da da das casas
durante os últimos meses né Eh um pouco
ficou Tava um pouco confuso sobre como
trabalhar com esse limite porque
geralmente para pagamentos o limite ali
para quem olha o swip onde dimite é
definido no iniciador E aí é transitado
e aqui é diferente então aqui é para
dizer que realmente é diferente tá aqui
durante a jornada o limite ele se vocês
olharem o post invol ele é um conjunto
de informações ele não possui informação
de limite o limite ele é definido pelo
usuário tanto o limite diário a gente
tem dois na p o diário por transação os
dois precisam ser definidos pelo usuário
e eles são definidos pelo usuário eh no
durante a autorização tá então ali na
tela de autorização ele vai ter a opção
de colocar um prazo para para para
validade ele vai ter a opção de definir
ele não vai ter a opção ele deve definir
é obrigado a definir um limite Diário de
transações e um limite por transação
tá
eh agora Em que momento a Em que momento
a iniciadora vai conseguir ter acesso a
essa informação né como eu falei após a
autorização o usuário já deve ter
colocado a gente tem ali no get
enrolment enrolment ID os dois Campos
então se você consultar você vai ver que
tem uma restrição informando que após a
autorização do vínculo aqueles dois
Campos São obrigatórios Então a partir
dali a iniciadora vai poder saber
exatamente
eh quanto foi o vínculo definido pelo o
vínculo já o limite definido pro vínculo
pelo usuário eh Em que momento que esses
erros devem ocorrer tá
eh a gente tem os dois cenários né a
gente tem os pagamentos que são
imediatos e a gente tem os pagamentos
que são agendados
eh como o usuário pode nesse meio
tempo entrar em um dos ambientes de
gestão e alterar o limite do vínculo
por exemplo
eh a gente não não tem como validar os
limites Em momento de Em momento de
concentimento pros agendados tá porque
Qual qual é o ponto aqui se eu tenho um
limite diário esse limite diário só pode
ser validado no dia que aquele pagamento
vai acontecer então para agendados para
pagamentos originados pela jornada
agendados eh só deve ser feito a
validação no de limite no dia da
liquidação
tanto transacional quanto
diário já
pro pros pagamentos imediatos não
conforme que tá previsto no header da P
de pagamentos deve ser feita a validação
conforme o funil do consentimento tá
então para qualquer um dos dois casos
Independente se o erro do relacionado ao
limite acontecer durante o consentimento
ou durante o pagamento o motivo de
rejeição vai ser o mesmo tá a gente
possui ali o valor acima limite e esse
deve ser o motivo de rejeição utiliz
usado para manifestar esse esse
extrapolo do limite tanto transacional
quanto
diário eu acho que esse é meu último né
Fabi é isso acho que agora eu passo a
bola Paul isso pa tá com você Boa tarde
pessoal para quem não me conhece eh sou
Paulo Moraes eu sou líder de integração
e de apis aqui do Diretoria de
Tecnologia do Open finance ã acho que a
gente já falou um pouco do da jornada
falamos um pouco da api aqui h o meu
foco é falar da da obrigação de
certificação que a gente tem de
segurança né então fazer um um para aqui
com o que a gente fez pro fap e trazer
aqui pro mundo de Fido tá acho
que dando um passo aqui atrás olhando
Unos grandes blocos de arquitetura Eu
trouxe um desenho que a Fido
disponibiliza um pequeno ajuste ali para
trazer pro nosso mundo né ã do lado do
iniciador né vai o cliente com o
dispositivo
ã com o seu aplicativo aliem que ele vai
utilizar para iniciar o pagamento né
então ele tem um um celular um
computador que tem um autenticador fid
que vai receber os gestos e vai fazer
toda a dinâmica para efetivar um
pagamento né
ã e o servidor do iniciador aqui e e
aqui tem um comentário que tem um termo
aqui utilizado que é o rel par RP aqui
né no mundo fap rel par são os os
detentores de conta né aqui no mundo
Fido é o iniciador de pagamentos a
explicação para isso tá é que R par é é
eh o participante de confiança quem vai
autenticar ou quem vai receber os sinais
de segurança e vai identificar quem é o
cliente né quando a gente fala no mundo
fap quem tá fazendo essa esse processo é
o detentor de conta né ele está fazendo
fap ali está cliente está se
autenticando no seu ambiente ele or
rilar em par né quando eu tô no mundo
Fido aqui os gestos de segurança vão ser
Cap ados
ã após obviamente depois de todo o
processo de de de enrollment ali né de
registro de
dispositivo durante a jornada de
pagamento em si quem vai verificar os
sinais de segurança né vai ser o Fido
que está no iniciador né então por isso
ele rá em par né
ã o detentor ele vai ter os seus
servidores que vão receber os sinais as
mensagens dizendo efetu esse pagamento e
ele vai ter que validar os sinais de
segurança que estão vindo né Eh para
determinar se Ok sigo em frente com esse
pagamento ou não né então esses dados
essa assinatura Fido é válida
ã esse esse tenho toda a minha régua de
segurança de antifraude ele sendo
aplicado e aprovo ou não né E para isso
né o detentor de conta vai ter que ter
um servidor fidal do seu lado né fazendo
as validações dos das mensagens que
estão chegando os do sinal Fido que tá
chegando ã para aprovar esse pagamento
tá
Então existe uma peça nova que os
detentores vão ter que instalar do seu
lado para habilitar todo este protocolo
todo esse pagamento ã de jornada sem
redirecionamento se eu poder avançar por
favor
então é uma peça nova que tá atrelada a
segurança não é autenticação é um sinal
de risco que tá chegando né mas que por
se tratar de uma segurança de um de
movimentação financeira Exige uma
certificação tá então quem precisa se
certificar ter a certificação né quem
precisa ter a certificação né Ah todos
os detentores de conta que vão estar Ah
implementando o fluxo de jornada sem
redirecionamento né tem a in
especificando quais são ali que vão
participar né Ah então eu como detentor
de conta e que forneço jornada sem
redirecionamento preciso ter um servidor
Fido certificado né agora quem precisa
certificar eu preciso fazer uma
certificação né Eh aqui diferente do fap
que a gente exigiu que todo mundo
tirasse uma certificação né Eu preciso
de uma certificação ã que valida que a
minha solução minha arquitetura a gente
chamou de solução única né deployment
único minha arquitetura como um todo
precisa ser certificada aqui no no Fido
como o Fido não tá servindo como
processo de autenticação em si né o o
processo de autenticação aconteceu lá na
enrollment eu fiz o fap tradicional aqui
o fid tá se comportando como se sinal de
risco né então a certificação aqui vai
poder ser feito
ã pela ferramenta né então eu vou poder
contratar um servidor Fido já
certificado e tá tudo certo né ou eu vou
usar uma biblioteca Fido já certificada
para montar aqui meu servidor e está
tudo certo né Essas pessoas essas
empresas não vão precisar de uma
certificação você usar uma ferramenta já
certificada eh você vai herdar essa
certificação e vai poder utilizar sem
problemas quem precisa certificar quem
decidir fazer a sua própria solução n
olha não quero usar uma solução f de
mercado aqui não quero usar uma
biblioteca já aprovada quero fazer a
minha né nesse caso você vai ter que
tirar sua certificação de servidor então
se você optar seguir o caminho de
difícil né que você vai ter todo
controle e gerar o seu próprio servidor
você precisa também dar esse passo da
certificação FAB avançar por favor
Então como que é o fluxo de certificação
tá
ele ele tem alguns passos tá ele tem um
roteiro a ser seguido né ele começa de
forma muito similar a que a gente faz
hoje pro pro fap pro funcional né Você
tem um motor que você baixa
ã e faz uma autov validação uma
autocertificação ali então você roda
Passa nos testes quando tá tudo pronto
né Você tem um relatório testando que
você está com conforme unidade com
aqueles testes né só que aqui existe um
passo adicional que eles chamam de teste
de
interoperabilidade então uma vez que
você passou nesses testes autotestes né
Você precisa agendar um teste de
interoperabilidade para participar de um
teste de interp abilidade que vai ser
feito com todo mundo que naquela janela
eu vou falar um pouco disso tá e deseja
tirar a certificação F Então vai ter
instituições que vão est certificando
servidor vai ter instituições que vão
estar certificando autenticadores ou vão
estar autenticando ou certificando um um
um aplicativo né
ã e e e você como eh detentor que fez a
sua própr implementação de servidor vai
precisar certificar com esse grupo né Eh
é agendado esse teste ele é executado
uma vez que você
ã é aprovado nesse test de operabilidade
você faz um uma submissão né com todos
os materiais e um termo e h recebe a sua
certificação tá vou entrar um pouco em
detalhes nos próximos slides ali tá
então ele tem um passo ali que é
novidade pra gente que é um teste de
interoperabilidade
ã com players real não necessariamente
do Open finance mas de todas as todas as
instituições globais que desejarem se
certificar no período tá eh para mim se
eu puder
avançar bom t questão de conformidade tá
então o próprio participante realiza
eh você terminando um teste é uma
ferramenta bem simples ali você faz os
testes você submete pela ferramenta o
resultado dos Testes e você precisa
concluir todos esses testes 14 dias
antes do teste de interoperabilidade e a
conclusão não é a submissão tá a
conclusão é você ter submetido e ter
sido aprovado né então 14 dias antes do
teste de interoperabilidade você precisa
ter realizado esse processo de ser
aprovado submeter e receber um OK você
passou nos testes Auto executados aqui
né
ah e esses testes inclui todos a parte
funcional né todos os testes funcionais
ali tem que ser executados com sucesso e
existe uns testes que também são
relativos ao serviço de metadados tá Ah
falar um pouco desse serviço de
metadados da F tá então
ah hoje fazendo um paralelo aqui com FAP
a gente tem o nosso diretório em que a
todas os participantes cadastram as suas
certificações né dizendo que olha eu
estou certificado eu estou apto aqui
está meu certificado ou aqui está meu
meu meu meu comprovante de certificação
né ã no Fido eles têm algo similar né Eh
esse serviço de metadados onde todas as
soluções eh
certificadas estão registradas né então
você pode comoção consult tá né Eh se
aquela implementação é é válida se
aquela certificação Está ok se ele
realmente tem a certificação nível dois
de autentificador né então é um serviço
em que você consulta e tem toda a base
de soluções fid tá ã e você precisa
estar apto né a se integrar com esses
metadados aqui tá
eh eh tem um tem um porém aqui a
ferramenta de conformidade ela não é ela
ela é gratuita é aberta Só que você tem
que fazer um cadastro para poder
utilizar esse cadastro geralmente demora
um dia útil ali para eles aprovarem tá
então se vocês estão se planejando fazer
a própria implementação
eh saibam que você vai ter que eh buscar
todo mundo que vai usar a ferramenta ali
fazer esse cadastro para poder ter
acesso quanto antes tá
ã feito o teste de auto autoavaliação de
conformidade eh se puder passar Fabi Ah
no teste
de interoperabilidade né vai ser um
fórum amplo que nem eu comentei né com
todos os implementadores que se desejam
certificar no período né Independente se
ele quer certificar como servidor se ele
quer certificar como autorizador tem
várias vários tipos de certificação ali
no Fido tá
ã Então você precisa participar desse
fórum né e ele é um requisito funcional
da certificação Então você tem que
passar por esse passo sem isso você não
não consegue o certificado né é um teste
realizado remotamente
eh e a implementação testada tem que ser
a mesma tá que foi utilizada na
autoavaliação tá você inclusive assina
quando vai fazer o o processo de
certificação um termo dizendo que você
fez uso da mesma solução tá algo bem
similar a que a gente faz no fap né que
a gente certifica em homologação e f e
assim um termo dizendo que é a mesma
solução que eu vou pôr em produção aqui
também a mesma mesma coisa tá uma semana
antes da data de amente eles fazem um
pré-teste eles chamam todo mundo que vão
participar do teste de participação
opcional né e a intenção desse pré-teste
é troca de figurinhas Olha o meu
servidor É esse aqui esses aqui são os
metadados deles esse aqui é como você
acessa ele essas são as urls para para
pros participantes se prepararem pro
teste que vai acontecer na semana
seguinte tá então é bastante
recomendável entrar nesse pré-teste ã e
tem um porém que se o evento não atingir
o número de implementadores que sustente
sua execução né o número mínimo de
participantes
o evento é cancelado e Aguarda a próxima
data que é 90 dias tá a cada 90 dias
então Ah então temos um problema temos
datas agendadas né então ali embaixo eu
ten as datas a próxima e janela é de 16
a 20 de Setembro Mas se eu falar que 14
dias antes você precisa já ter passado
nos testes a gente tá falando que no
começo de setembro você tem que ter
terminado todas as sua implementação e
já ter passado no motor de autoavaliação
né e feito todo o processo de submissão
e inscrição aqui para esse teste de 16 a
20 de Setembro algo extremamente corrido
né extremamente difícil a gente tá
falando ali de duas semanas aqui né duas
três
semanas existe uma alternativa e daí o
próximo teste aconteceria em Dezembro né
isso não não respeitaria nossas datas
regulatórias ali né existe uma
alternativa que a fid dá né de fazer
testes sobre demanda né contatando
diretamente a fid Alliance tá então e a
gente consegue se desprender dessas
datas tá a única coisa que vai ter
alguns requisitos a serem cumpridos que
é existir
eh as contrapartes necessárias para
execução do teste tá E daí você pode
usar como contraparte soluções Fido já
certificadas né já existem n
certificações fidos n soluções fid já
certificadas que poderam ser usadas para
isso né então acredito que não seja uma
grande dificuldade tá E aqui como
ecossistema a a dto tá estabelecendo uma
conversa com a fid para entender né como
que a gente poderia talvez criar um
grupo intermediário né para para quem
desejasse certificar Tá então não é
garantido né que a gente consiga essa
data intermediária vai depender de
volume de instituições se certificando
né ã mas a gente vai tentar apoiar nesse
processo ã Mas isso não impede também
que alguém que tenha dese já entre em
contato com a f Alliance já tente
entender e marcar uma data por contra
própria tá
E poder avançar Fabi
Ah bom após passar nos testes tanto de
autoavaliação como de interoperabilidade
você faz a submissão né pra certificação
a certificação custa 9000 para quem não
é membro da F Alliance né 000 para quem
é
membro e daí certificações segu mudei
meu servidor mudei algum aspecto da da
minha solução você pode renovar por 00
tá
E aqui não não achei nenhum material mas
se você criar seu servidor a partir de
outro não sei se
você poderia utilizar esse preço mais
barato tá
E talvez seja melhor daí como usar o
outro servidor né se ele atender para
você já aproveitar da certificação deles
tá então é é um valor mais mais alto do
que a certificação fap eh mas ele não é
um valor que vai ser exigido de todo
mundo é só de quem eh resolver fazer a
sua própria implementação tá
ã Além disso se caso você como
instituição que fez a implementação
quiser usar o sel Fido precisa eh de uma
autorização comercial ali da F é um
formulário simples que preenche e e e
entra em acordo ali com eles tá e por
último eh tem o último passo né que eu
já ter que cadastrar no metadatos
ã os dados do Servidor tá então é
serviço de metadados do fid Lines né que
é um repositório Centralizado que tem
todas as declarações
de das certificações das ferramentas
utilizadas os status as certificações
como que tá os dados e conformidade de
segurança de cada implementação ali né
que você pode utilizar para verificar e
e o ecossistema vai utilizar para
verificar ã
se os participantes estão com uma
solução certificada tá então que que a
gente vai exigir tá
eh no diretório o seu autorisation
server hoje você já cadastra a
certificação fap né você vai cadastrar
também a certificação fid que pode ser ã
a certificação Fido da solução que você
tá utilizando né então tô utilizando uma
solução de mercado ou de um fornecedor e
ele é certificado tá aqui o ID dele né
de certificação e a gente vai validar
isso nesse metadados tá ã ou ã o o seu
certificado que você tirou por conta
própria tá ã o processo de o processo de
cadastro é o mesmo do processo que é
utilizado hoje pro fap a única coisa que
a gente ainda tá definindo é como que a
gente vai fazer Qual informação a gente
vai utilizar ali do serviço de metadados
para garantir a uniti cdade e e e e e
essa identificação da para validação Tá
mas eh a gente vai soltar um material
específico para isso assim que tiver
definido né falando olha vai ser o ID do
Servidor que você vai nesse Campo daí
solta um manualzinho de como cadastrar
no diretório da certificação F Tá mas o
como é requisito do J direcionamento
essa
certificação precisa desse cadastro e a
gente vai
validar se tá todo mundo
compli é isso de certificação aqui
prazos extremamente corridos para quem
quiser fazer a sua própria implementação
mas existem dezenas de soluções Fido
ã prontas tá bibliotecas que são
disponibilizadas Open sources Já
certificadas que vocês podem olhar ver
se faz sentido obviamente aqui como é
sistema a gente não recomenda nenhuma né
assim essa aqui pode usar que é segura a
gente não vai dar recomendação mas
existem bibliotecas boas ali bibliotecas
de grandes empresas também disponíveis
servidores de grandes empresas vale a
pena vocês olharem o que tá lá
disponível ã para ver se faz sentido ao
invés de passar por todo esse processo
num prazo extremamente curto
então
Eh Obrigada
pa passar agora pro Thomas para falar um
pouco sobre visão iniciadora
aqui muito obrigado Fabi Boa tarde a
todos eu sou o Tomás eu sou aqui do
Google pay eh eu trabalho no time
técnico Mais especificamente no time de
parcerias eh eu já trouxe aqui nesse
primeiro slide né Já tô entregando o
ouro foi um anúncio que a gente fez aqui
a imprensa algumas semanas atrás com a
nossa interface da Carteira do Google
onde a gente traz a jornada sem
redirecionamento como uma feature aqui
disponível para público atualmente a
gente tá integrado a duas detentoras de
conta
eh e a gente tá fazendo um rollout
progressivo aqui pros usuários num
trabalho em conjunto então eh eh eu sei
que o nick trou no começo desse workshop
O que é a jornada regulatória O que é
esperado Num caso de uso de checkout e
aqui eu trago o produto que aqui a minha
casa produziu eh dentro dessa parceria
Claro eh onde a gente traz essas
features do PX pra carteira do Google e
aqui operando no modelo de itp pura a
gente não tem a questão de de conta de
pagamentos ou uma conta transacional e
no Google então a gente tá gando essa
responsabilidade para essas detentoras
de conta e aqui atuando apenas como uma
iniciadora de pagamento nessa ilustração
a gente vê um fluxo de pagamento via
dict então Eh inclusive é um dos temas
que que eu vou querer abordar depois e
aqui também
eh dentro dessa ilustração a gente vê o
que dentro desse processo né de
pagamento por uma para uma chave PX vai
existir o conceito do consentimento da
autorização idle e da efetivação do
pagamento igualzinho se espera pela
jornada de yx mas aqui com a cara da da
minha casa que implementa e e também um
pouquinho mais sobre essa tela inicial
né só para
eh dar um pouco mais de pano de fundo do
contexto que a gente vem trazendo essa
implementação eh hoje a carteira
trabalha já com diversas eh diferentes
formas de pagamento então falando de
cartões de débito crédito e o PX encaixa
aqui também na nossa leitura como uma
possibilidade muito interessante de
forma de pagamento expandindo aqui o
acesso dos usuários hoje não é todo
mundo que tem um celular com capacidade
de pagar com cartão via aproximação
então trazer o pix como uma forma de
pagamento tem Total sinergia aqui com os
objetivos da da carteira Fabi por
gentileza você puder passar para segundo
slide Eu juro que a minha apresentação é
curtinha então só contando um pouco mais
da história né de como a gente conseguiu
fazer esse lançamento produtivo eh a a
casa sempre teve como objetivo eh
oferecer e fazer um onboarding como itp
para jornada sem redirecionamento apenas
por julgar e por critérios aqui internos
eh que a gente gostaria de prover essa
jornada como a jornada ideal
eh algumas dificuldades surgiram por
conta disso né uma vez que eh a própria
certificação no arranjo pxs eh eu tinha
um problema de ou da galinha aqui para
eu conseguir fazer a a certificação do
arranjo pix usando o k tester a todas as
ferramentas que aqui PR todo mundo deve
ter familiaridade eh eu preciso com a
jornada sem redirecionamento eu
precisava de um contrato bilateral que
exigia que eu já tivesse certificação
então a gente teve que adaptar aqui o
processo de onboarding desenvolver um
client temporário com redirecionamento
aqui totalmente compliant com a versão
vigente da pay de pagamentos na época
para conseguir obter certificações
necessárias realizar o processo de
onboarding e depois migrar oficialmente
pro processo de onboarding paraa jornada
sem redirecionamento apenas eh e aqui os
requisitos eh são os requisitos básicos
para todas as itps além desse dessa
certificação do próprio pix e de reliant
parties do da Open foundation que são as
duas principais aqui pro âmbito do Open
finance e a algumas também eh aqui a
jornada a perdão a jornada sem
redirecionamento ela não tem nenhuma
diferença muito gritante com relação a
API de pagamentos v4 aqui para
pagamentos imediatos Então as mesmas
estruturas que regem aqui o
funcionamento e a boa governança dos
dados
eh operacionais dessas apis elas valem
tanto para uma quanto para outra de de
maneira igual então munido aqui de uma
implementação para API de pagamentos a
api da jornada sem redirecionamento né a
a o Family type enrollment ele surge
como um complemento desse Framework né
então a gente enxerga api Family Type
enrollments como um Framework que
permite essa autorização de
consentimentos sem o redirecionamento do
usuário a sua detentora de conta no
momento do pagamento ali no meu slide
anterior né naquela ilustração eu não
trago o processo de vínculo de
dispositivo apenas porque eu não
consegui aprovação para trazer esse
material público mas e alguns usuários
já devem ter tido essa experiência
eh continuando na nossa jornada aqui
falando Mais especificamente sobre jsr
minha casa optou por fazer a
implementação por hora apenas para
dispositivos Android na carteira do
Google e dentro dessa linha assim a
implementação a integração né com uma
com o client fid em si foi muito simples
uma vez que a gente tem tanto a
implementação pública do Android quanto
a implementação dos endpoint tanto de
registro quanto de assinatura regidos
pela mesma especificação Fido 2 eh
compartilhado aqui publicado pela w3c
então é muito prático é muito simples
fazer esse mapeamento entre a plataforma
autenticadora e um servidor F do
compatível eu acho que vale
esse vale só atentar aqui né a a dois
conceitos principais ao conceito de
Origin e o ID da reli Party que eles
estão idos aqui dentre as deliberações
da
Squad com um funcionamento um tanto
quanto especial nada difícil mas um
tanto quanto especial ainda assim onde
ID ele vai est relacionado ao como o
name do certificado da ICP Brasil da
instituição iniciadora Então existe essa
correspondência aqui de Campus e o
Origin ID ele ele se refere ao aqui cada
plataforma cada forma tem a sua
definição mas no caso do Android ele é
uma combinação que acaba identificando
Qual que é o aplicativo que está sendo
autorizado ou os aplicativos que a itp
está declarando eh possuir tal que serão
utilizadas as credenciais fid então eh
só um um pontinho de atenção porque
apenas pela especificação w3c talvez não
fique tão claro como você se encaixa no
mundo Open
finance um outro aí já pulando pro
próximo tópico eh a o os sinais de risco
da jornada sem redirecionamento a gente
como itp tem a o entendimento de que é
essencial pro bom funcionamento dessa
tecnologia apesar do fil já já trazer a
a a garantia de usuário presente e
várias outras validações que essa
tecnologia tem por objetivo atingir eh a
gente tem algumas características
adicionais que trazem bastante valor no
processo da detentora de Cont conta
realizar aprovação ou negação de uma
tentativa de de pagamento pix e e e acho
que um destaque principal aqui que eu
dou para para esse processo de extração
dos sinais de risco no caso do Android
né que se aplica a minha casa é
integração com a play integrity api essa
api Eu recomendo para ela é uma API de
uso público também e também é ela não é
obrigatória de ser utilizada mas ela
facilita bastante a gestão de alguns
sinais de risco tais como identificar
dispositivos emulados eh permissão de
Rot dentro de um dispositivo em
particular então Eh ela já vem com uma
série aqui de verificações que facilitam
bastante a a compreensão né e a extração
desses sinais de risco para enviar para
as nossas detentoras de conta parceiras
eh então sumarizando né Eu acho que a a
a história que eu queria quia trazer
aqui hoje como como de desafios na
verdade a jsr ela não é um desafio
apartado do ponto de vista da itp ela se
encaixa muito num fluxo onde exista a
API de pagamentos e coexista com esse
Framework de de autorização sem o
redirecionamento
eh Mais especificamente né Então
finalmente trazer mais alguns pontinhos
extras aqui que foram bastante
desafiadores paraa nossa casa até a
gente chegar nesse momento de anúncio
produtivo Eu acho que o contrato
bilateral ainda existiu assim bastante
eh ele exigiu perdão bastante esforço eh
de ambas as casas iniciadora e detentora
para convergir numa numa redação que
fosse aceitável de ambos os lados até
por por ser um assunto relativamente
novo então acabou tendo bastantes eh eh
rodadas de negociação eh e um um outro
ponto eh que vale também bastante a pena
insistir é também no mapeamento e nos
comportamentos de risco nessa gestão por
lado da itp e e digo isso porque a gente
tem esse compartilhamento de sinais
entre itp e detentora mas o risco ele é
sempre gerido eh pelas duas partes né
então não existe uma delegação dos
comportamentos suspeitos ou de risco
necessariamente da itp para paraa
detentora isso é é um trabalho feito
sempre em conjunto E aí como por exemplo
a gente eh chegou a explorar mais cedo
aqui no workshop a questão do dos
limites transacionais então poderia
existir um cenário onde o limite é
atingido o vínculo é desfeito faz um
novo vínculo que teria um novo limite e
assim sucessivamente para extrapolar o o
limite se for algo legítimo não
Teoricamente não teria tanto problema
aos olhos da especificação mas a itp ela
tem a oportunidade de implementar eh
mecanismos de seguranças eh adicionais
tais como rate limit por exemplo então
ditar quantas quantos vínculos um
usuário pode realizar num determinado
dispositivo ou quanto tempo é eh exigido
entre dois vínculos ou mais ou ficar
atento a essa questão de limites
transacionais então Existem várias eh
várias linhas de de pesquisa aqui dentro
da minha casa para tentar complementar
aí esses mapeamentos de comportamentos
de potenciais abusos ou comportamentos
de atividade suspeita e acho que um dos
últimos pontos aqui que eu queria trazer
é que minha casa eh por adotar esse
modelo de itp pura eh hoje para fornecer
eh efetivamente pagamentos na internet
na vida real a gente tem uma dependência
muito forte com serviços de dict o que
deve eh O que é bastante natural para
todas as itps acredito eu só que como
uma itp pura eh depender de serviços
para prover os serviços do Open finance
depender de serviços do arranjo que não
são do Open finance ainda eh causa um
pouco de estranheza principalmente pro
meu time que não tá familiarizado aqui
com os meios de pagamento no Brasil
então e essa é mais um ponto aqui e
interno meu que é uma uma dificuldade
para nós explicarmos pros times
internacionais
O Di não faz parte do Open mais uma uma
questão
de de compreensão aqui da nossa da nossa
indústria e acho que com isso eu
finalizo aqui a minha a minha historinha
de como é que chegamos ao ambiente
produtivo pessoal Muito obrigado aqui
pelo pelo
convite muitíssima obrigada agora quer
chamar
aqui canal por por favor Olá pessoal
tudo bem E me chamo Christian trabalho
na ragen aqui na parte de conformidade
né então envolve tanto motor de
conformidade quanto Moc e aideia a gente
trazer aqui um overview das Ferramentas
que também eh a intenção que elas também
façam parte facilit em toda a jornada de
desenvolvimento ali das casas né acho
que um ponto legal da gente ressaltar de
início né que todos os pontos de
certificação que o Paulo trouxe aqui né
e do outros pontos duas outros pontos da
Fido também é que ali a gente tá falando
da certificação do Servidor Fido né
quando a a gente eh toda toda a
estrutura das apis que a gente tem a
estrutura de certificação que a gente
tem aqui acho que a Fabia vai falar um
pouquinho mais depois mas isso se mantém
né então são certificações apartadas
dado que a gente tá introduzindo esse
esse novo ator né que é essa parte do F
dentro dos apis e também é importante
ressaltar dessa divisão de de
responsabilidade né então a gente por
estar testando a parte funcional o nosso
foco é testar dentro do motor
certificação funcional a parte funcional
né então toda essa parte de Fido
obviamente que tá contido dentro da pi
tá tá tá contido dentro do motor tá tem
as validações no mock Bank só que o foco
principal é validação funcional né eh e
aí acho que um Último Ponto também que
eu vou passar aqui rapidamente depois
mas que ess essa é uma API que de novo
né por a gente conter essa nova
tecnologia dentro da api né que essa
parte de Fido eh a vocês vão ver que os
payloads eles eh eles mudam um pouco não
mudam payload né assim mas dentro do
payload você vai ter Campos tem que ter
base 64 tem que ter Campos que são
assinados então tem especificidades do
payload né porque acho que anteriormente
tinha uma Divisão muito clara ali entre
eh o que era toda a parte de segurança e
etc né e agora isso Acabou entrando um
pouco dentro do payload pela
característica do produto como o pessoal
bem comentou aqui né então bastante
atenção ali com relação a formatos dos
Campos né o pelot tem que ser assinado e
dentro do pelod assinado ainda você vai
ter alguns outros pontos ali né mas em
resumo eh acho que vale a pena prestar
bastante atenção ali na descrição dos
Campos como que é feito e tudo mais mas
todas essas validações estão contidas
dentro do motor lá e vocês vão recebendo
os erros conforme foram implementando
também para para facilitar
Mas falando da certificação funcional
pessoal então é aqui dando contexto né
aqui do lado esquerdo primeiro tanto
motor quanto mbank já estão disponíveis
na versão 1.3.1 o Moc inclusive tá
disponível na versão 2.0 também e o
motor da acho que nas próximas semanas
agora já também a versão 2.0 a versão
Beta vai sair então já tá disponível
para quem tá implementando quem quer
interagir com Moc para entender para
entender a jornada já tá disponível né
um ponto importante também de ressaltar
é que a gente fez uma alteração recente
né que acho que inclusive foi foi foi
informada também né ali no pro
ecossistema com relação a aos end Point
né então para eu começar o teste Eu
Preciso registrar o meu endp dentro do
diretório né porque o motor de
conformidade agora ele pega as APS do
diretório né então se antes de iniciar o
teste tem que ir lá no diretório sendbox
faz o registro das das da das urls né
para para promotor de conformidade
conseguir acessar e fazer as chamadas eh
de acordo né né a versão da 1.3 ela vai
continuar ativa né então a gente vai
lançar 2.0 1.3 fica lá estática e 2.0
vai evoluir conforme a a a a a
especificação evoluir também né então
versão Beta versão RC está e tudo mais e
também acho que Vale ressaltar que os
testes foram desenhados para facilitar a
implementação da pi né então a gente tem
testes de vários estádios da pi né Tem
teste que testa só o vínculo de conta
tem teste que vai testar só o vínculo de
conta e pagamento então eh tem teste que
só vai usar as três primeiras chamadas
de os três primeiros endp né não vai não
vai até o registro e essa estrutura foi
pensada também para facilitar toda a
jornada a questão dos Marcos e tudo mais
né Então acho que vale a pena também eu
vou mostrar depois no gitlab lá lembrar
o pessoal como que a gente olha onde que
a gente vê os testes mas dá dá uma
olhada até o planejamento do imagino das
sprints para casar com os Marcos e tudo
mais é bem válido né Mas no geral né O
que que a gente vai est testando né acho
que a gente vai ter acho que talvez
depois a gente tenha alguma eh alguma
algumas interações mais técnicas né mas
aqui de alto nível que vai ser testado
né tanto cenários felizes quanto
infelizes um total de 25 cenários Então
são 25 módulos de testes né Acho que não
são 70 da v4 mas às vezes a de de dados
ali a gente acaba tendo cinco ou seis
então são 25 módulos eh cenários felizes
né a gente tem a gente dividiu aqui
também os cenários acho que para dar
mais visibilidade do que tá sendo
testado né em interoperabilidade
garantia de jornada garantia de erros e
limites do usuário eh em cenários
felizes quando a gente fala de
interoperabilidade garantia de jornada
né quando a gente fala que cenários de
interoperabilidade é basicamente a
jornada principal né então o vínculo do
dispositivo vínculo do dispositivo mais
pagamento eh que inclusive são os dois
testes aqui que a gente comentou né E aí
quando a gente fala de garantia de
jornada são jornadas a gente acaba indo
um pouquinho mais para digamos assim pra
borda da jornada né então mandando
Campos profissionais alguns outros
algumas outras validações pra gente
garantir que a jornada o cenário feliz
vai estar funcionando completamente né
então eh a gente tem esses cinco
cenários né de a gente vai mandar o
motor manda tudo correto espera as
respostas corretas espera o vínculo do
dispositivo espera o pagamento e aí
quando a gente vai paraos cenários
infelizes a gente tem ali garantia de
erros e limite do usuário e garantia de
erros é basicamente testes de validações
valida a mensagem de erro e valida se a
se a validação tá tá sendo executada
também ali do lado da da detentora de
conta né então a gente tem 17 cenários a
maioria dos cenários Então são esses
cenários onde a gente o motor vai estar
mandando algum dado errado na sequência
a gente já fala dos cenários aqui né mas
o motor vai estar mandando alguma
informação errada alguma informação que
não deveria estar passando e vai esperar
um erro eh de volta né E aí é justamente
esse ponto também que que demanda
bastante atenção ali né Qual o formato
do campo como que ele tem que ser
enviado e todas todas essas outras
validações que geralmente já são feitas
né E a gente tem cenários de de limites
do usuário também que são esses três eh
que a gente basicamente vai estar
testando limites que são definidos pelo
usuário né então acho que o Zé comentou
aqui a questão dos limites né que é
obrigatório a in a iniciadora não manda
o o o usuário ele é é obrigado a a
definir esses limites dentro da
detentora
eh e aí a gente vai testar basicamente
esses limites né então a gente vai pegar
esse limite tentar fazer um pagamento
acima do limite tentar fazer exceder o
limite Diário de pagamentos né E aí
tanto na parte tanto agendado que o o Zé
comentou ali diferenças né tanto
agendado que o pagamento tem que ir para
agendado quanto pagamento imediato que
tem que ser rejeitado então todas ess
essas características ali né então um
total de 25 testes como a gente falou né
eles estão divididos e e quebrados ali
também para até para acompanhar a
jornada de desenvolvimento né aí fabí
pode passar pro próximo slide por
favor e na prática O que que a gente tá
testando né dentro daquelas eh daquelas
várias eh daqueles vários grupos que a
gente falou né então quando a gente fala
de vínculo do dispositivo né verificar
se o dispos pode ser vinculado com
sucesso ao banco então a gente faz toda
toda a jornada de vínculo do dispositivo
eh garantir que o vínculo do dispositivo
não é bem sucedido quando tem problema
de identicação do usuário então a gente
o usuário ele é redirecionado né da
primeira vez né para fazer o vínculo do
dispositivo aprovar o vínculo do
dispositivo que na sequência vai ser
enviada as chaves então quando tem
problema ali a gente não consegue
completar né então garantir também ali a
proteção da jornada eh o vínculo do
dispositivo pode ser cancelado né então
tem aí o o end Point de Patch enrollment
né uma vez que o vínculo seja feito seja
aprovado eu posso chamar mais p o Pat
enrollment se revogar né então toda a
parte de vínculo do dispositivo somente
né Sem interagir com a parte de
pagamentos ainda eh ali aí tem os testes
de web Hook também de web Hook acho que
é interessante comentar que eh como são
consentimentos de longa duração né Eu
acho que o web Hook geralmente nas APS
de pagamentos elas estavam atrelados à
substituição de um pulling né então a
gente podia a iniciadora podia tinha a
opção de fazer o pulling ou ela podia
esperar o webhook para fazer a chamada
como aqui né a gente tá tá lidando com
consentimentos de longa duração né então
pode ser uma um vínculo do dispositivo
que vai durar um ano ou mais etc né
Eh eu
posso eh não tem como ficar fazendo um
pulling né então ele não substitui o
pulling Ele é a única maneira da
iniciadora de fato saber eh qual que é
quando o dispositiv quando o vínculo foi
revogado né então tem essa
característica digamos assim um pouco
diferente né do que ela não substitui um
pulling ela é o único o único método da
iniciadora saber que o que foi revogado
né mas os testes seguem a lógica normal
dos Testes web Hook ali né
e pagamento sem redirecionamento aí
começa a interação entre o vínculo do
dispositivo e o pagamento em si né então
certificar com um pagamento sem
redirecionamento não pode exeder os
limites como eu comentei eh confirmar
que o pagamento sem redirecionamento não
pode ser concluído se o vínculo
dispositivo não for bem sucedido então a
gente faz um vínculo dispositivo com
alguns problemas aí depois tenta fazer o
pagamento usando esse vínculo eh e
garante ali que o vínculo não vai que o
pagamento não vai ser executado né Eh
assegurar que um pagamento sem
redirecionamento é realizado com sucesso
se o vínculo do dispositivo atente
indicação do usário foram bem sucedidas
então aqui é o cenário feliz né a gente
faz o vínculo com sucesso na sequência
faz todo o pagamento com sucesso e
certificar que o pagamento não é
realizado se a autenticação for feita de
um dispositivo diferente do que foi
vinculado do usuário né e a dispositivo
diferente é o que a gente faz é
basicamente a gente troca assinatura de
Chaves as chaves que estão assinando ali
o eh as informações né então basicamente
a gente
eh vincula um dispositivo e depois tento
fazer um pagamento por um outro
dispositivo né que é um dispositivo fake
né na prática o motor de conformidade
ninguém você não precisa abrir um outro
dispositivo nem nada mas isso tudo Tá
mocado lá dentro do motores interações
eh e aí eu vou pegar a tela aqui
rapidinho pessoal só para mostrar como
que mostrar o motor e o mock aqui
funcionando né vou pegar a tela aqui
rapidinho tá bom Fabi tá bom fica à
vontade
eh aqui aí pessoal só passando aqui pelo
gitlab primeiro né aqui é o gitlab que é
o repositório do motor na parte de wik
aqui a gente tem duas partes que são
importantes pra gente A primeira é a
parte do da documentação dos planos de
teste a gente não vai passar ela aqui né
mas tá aqui em fase três pagamento sem
redirecionamento aqui embaixo tem uma
lista né que é jcr 2.0 tem a da 1.3.1 e
tem a 2.0 né Essa 1.3.1 ela é a lista
com todos os planos de teste a
documentação que a gente geralmente faz
aqui né então eu vou abrir aqui na Ah tá
aqui então tem a documentação com todos
os todas as chamadas o que que é feito e
tudo mais então também acho que super
válido o pessoal dar uma olhada aqui
para planejamento da implementação
também quais as validações que são
feitas obviamente não implementar
baseada no motor né mas saber como são
as chamadas a sequência das chamadas e
também tem a parte do mock Bank aqui
embaixo né então é o mock Bank tá
implementado ele funciona como outro
participante ele tem sandbox tá
registradas apis Então quem quiser
interagir pode interagir aqui embaixo na
parte do mock Bank né nessa parte aqui
de payment initiation eh vocês vão
conseguir acessar também hoje mbank já
tá passando em todos os testes eh contra
de jsr né então Vocês conseguem aqui
embaixo ter o Jon que é usado na
configuração do teste né então Quero
rodar o motor contra o mckb para
entender a chamada das API isso é
possível também né É só descer aqui
embaixo abrir aqui né Tem configuração
para 3 v4 pagamentos automáticos e
Jornal Sem redirecionamento É só abrir
aqui copiar abrir o motor de
conformidade colar o Jon ali né deixa eu
abrir
aqui um
minutinho Então cola colo aqui né Jeison
aqui no caso já tava com essa informação
né seleciona o plano de teste né o plano
de teste é um plano só ele tá aqui
embaixo junto com os testes de fase três
né então quando a gente abre aqui
descendo né Tem uns testes fase três
sandoo pagamento sem redirecionamento
Eh aí aqui já tá tudo apontando para
mabank né então crio o plano eu tô com
todos os testes aqui para executar né
vou executar o teste Core aqui de de
pagamentos só pra gente ver funcionando
também E aí de novo né acho que a gente
tá falando aqui sobre toda a jornada
aqui no motor né como tanto m tá
implementado quanto o motor já tá já tá
disponível também é possível verificar
toda a jornada né então quero ver como
que isso funciona na prática né tudo
isso que a gente tá comentando Quais são
as chamadas Deixa eu só fazer o
redirecionamento
aqui
lado confirmar enrollment Voltei pro
Motor e aqui na sequência a gente vai
terminar todo o teste né então Eh aqui
embaixo ess eh dá para ver todas as
chamadas que têm que ser feitas né então
a chamada né a chamada do Token E aí na
sequência aqui embaixo né a chamada do
Token a chamada do post enrollments Qual
que é o request Como que é o response
então de novo né aqui ferramentas que a
intenção é justamente ajudar aqui na
jornada de desenvolvimento das casas
conforme pessoal for implementando né E
aí Eh mckb tá disponível o motor tá
disponível não 1.3.1 a 2.0 deve sair
agora na sequência e Ah acho que um
ponto importante também só para
mencionar que o campo orage né que o que
o Tomás mencionou agora a pouco ele tem
que ser registrado dentro do diretório
né então dentro do software Statement
você tem um campo que é software Origin
uris né para você selecionar qual que é
URI ali da do Origin e esse campo
precisa ser registrado no diretório
também pro teste né então acho que é um
um ponto de atenção também para Antes de
iniciar o teste fazer esse registro lá e
acho que é o comportamento que vai se
refletir também em produção né
Eh e acho que da minha parte era
basicamente isso pessoal no geral motor
e Moc estão prontos eh acho que a
recomenda né que o pessoal usa ali se
quem quiser já testar hoje né já pode
pegar a configuração que tá lá no gitlab
roda o motor contra o Moc para ver as
chamad das apis ver o funcionamento e
tudo mais e acho que é isso ficamos à
disposição também para tirar qualquer
dúvida da certificação no gitlab como a
gente geralmente faz volta para você aí
Fabi Obrigada
Cris pera aí deixa eu puxar a tela aqui
de novo
pessoal E agora o que que é esperado das
instituições dentro desse processo Então
acho que quando vocês viram o cronograma
a gente tem uma etapa adicional Então
acho que a gente tem algumas etapas aqui
dentro do fluxo né então a gente tem a
concepção do produto então
desenvolvimento da primeira versão das
especificações desenvolvimento do motor
que é o que vai servir de insumo pro
desenvolvimento das apis pelas
instituições a gente já passou por essa
etapa então aqui agora as instituições
esperado que as detentoras já comecem o
seu desenvolvimento e aí a gente entra
na etapa amarelinha aqui que é o de
maturidade então é quando o ecossistema
recebe avaliações de propostas sugestões
de melhorias algumas dúvidas Então tanto
no desenvolvimento do motor quanto no
desenvolvimento das apis pelas
instituições se tiver qualquer dúvida se
encontrar qualquer problema em alguma
etapa abre um ticket pode ser o ticket
no gitlab ah ali o o ISO pode ser o
ticket no service desk os dois são
tratados iguais
eh levanta aqui para ecossistema a gente
vai ver é uma questão na especificação
se sim vai pro pro grupo ali de de specs
para fazer a avaliação da da correção e
da da melhoria se não for a gente vê se
é um problema no motor e faz também o
fluxo aqui de atualização e nesse meio
tempo a gente espera que as instituições
vão desenvolvendo as apis executando os
testes e passando nos Marcos conforme o
cronograma esperado depois a gente entra
no no final do do ciclo a gente entra na
etapa de certificação então depois dos
100% a gente lança a versão estável das
apis ajusta o motor paraa versão estável
eh do motor então de acordo com essa
última versão das apis As instituições
têm que executar com sucesso os testes
nessa última versão vai ter que ter a
certificação completa funcional então
com a abertura do Ticket no service desk
a gente processa essa certificação E aí
a gente vai entrar nessa nova etapa que
é o piloto o piloto eh o os moldes dele
ainda tão em definição a gente ainda tá
fechando alguns detalhes antes de
divulgar para vocês mas a ideia é que
tudo esteja em produção eh conforme foi
especificado eh já com a integração com
a PCM então é é go Live completo jornada
completa existente o que deve acontecer
nesse período Muito provavelmente é uma
redução dos usuários que que vão ter
acesso a essa funcionalidade Então vai
ter uma restrição e a gente vai fazer
testes implementar algumas eh alguns
controles para garantir que tá realmente
tudo funcional mas não é uma entrada
parcial em produção tá então dia 14 de
novembro para jcr é esperado que as
detentoras estejam completamente em
produção pra gente poder fazer essas
validações tanto bilaterais quanto a
estrutura fazendo as validações e a
gente possa fazer qualquer correção
qualquer ajuste fino eh antes de 28 de
Fevereiro que é quando a gente vai ter o
go oficial
eh que entra
no que entra para todos os usuários aqui
eu vi que tem uma dúvida se essa a
certificação é a do Bacen ou f do
Alliance essa daqui é o fluxo da
certificação funcional tá então é aqui
da
estrutura certificação funcional com
abertura de Ticket no service desk e pro
go aqui pro piloto é esperado que já
tenha a certificação o servidor F
certificado tá então o fluxo de
certificação ou já tenha passado pelo
fluxo de certificação do F Alliance aqui
também ou que tenha o servidor terceiro
ali o servidor que já já esteja
certificado
algumas dúvidas aqui tá como funciona o
ciclo de maturidade aqui as instituições
são corresponsáveis pelo ecossistema tá
então a qualidade do lançamento dos
produtos As instituições também são
responsáveis então é fundamental que
qualquer feedback melhoria problema seja
notificado pro ecossistema o mais rápido
possível pra gente poder ter tempo de
ação tá tempo de de reação então que a
gente possa fazer ajustes ou dar o
retorno consiga destravar
eh o ponto em questão
eh a gente espera que as instituições
iniciem o desenvolvimento quanto antes
então as especificações já tão
disponíveis o motor já tá disponível
então o tempo tá curto a gente tá
trabalhando aqui para tentar evitar
grandes paralelismos com outras versões
Então foi uma dor que aí já foi
levantado antes então é é realmente para
poder colocar energia pra gente lançar
um produto o mais redondo possível a
gente tem os Marcos os Marcos acho que
quem já tá aqui no ecossistema mais
tempo já tá acostumado Então são datas
estipuladas para as instituições
passarem numa quantidade específica dos
Testes eh pra gente garantir que eh as
instituições já estão desenvolvendo com
antecedência que a gente tá alinhando
que qualquer feedback que a gente
consiga receber os feedbacks com a
antecedência eh necessária se a gente
tiver alguma mudança no motor de conform
idade por causa de mudança na
especificação ou por causa de um
feedback recebido a gente pode ter
mudanças que são mais ou menos
restritivas uma mudança menos restritiva
vou dar um exemplo é quando tava
aceitando erro 400 e pode aceitar 400
agora e ou
422 quando a gente tá se tornando menos
restritivo quem tava passando no teste
continua passando não muda nada na vida
quando a gente tem uma mudança que é
mais restritiva a gente tava aceitando
400 e agora vai aceitar só o
422 Então quem tava passando no teste
deixa de passar a gente chama isso de
Breaking Change ou mudança
eh mudança mais restritiva aqui então
quem tava passando no teste antes vai
ter que ajustar sua implementação e vai
ter que passar no teste de novo Quando a
gente tiver alguma mudança desse tipo
vai ser
notificado a certificação Ela vai ser do
a certificação com completa Então vai
ter abertura de Ticket no service desk
aí para no momento da abertura do Ticket
tem que ter a um log só com sucesso em
todos os testes para colocar ali como
anexo de acordo com a última versão dos
Testes
eh o piloto é como eu tinha comentado
com vocês então A ideia é que a gente
Garanta que as apis publicadas as
integrações com as ferramentas foram
feitas da maneira adequada e os detalhes
de como vai funcionar a gente vai
divulgar posteriormente Então tá em
debate pelos grupos técnicos e depois
precisa ir para pras aprovações aqui
dentro do conselho do Banco Central mas
tá em andamento aqui
eh e aí eu vi também a pergunta sobre as
iniciadoras tá as iniciadoras que
queiram participar elas precisam mandar
um e-mail pro openfin pdz @bb.com
para indicar a intenção de participação
não tem uma certificação aqui específica
para eh as iniciadoras mas assim que
elas entrarem em produção é esperado que
esteja com todas as integrações
completas tá então integração com a PCM
também para entrar em produção antes de
14/11 precisa ter o contrato bilateral a
partir de 14/11 o contrato bilateral não
é mais
obrigatório a questão do go Live
eh a instituição ela vai ter ter que ela
já vai ter publicado tudo para o piloto
então o go live em si ele vai ser só o
ajuste para retirar a restrição do
público alvo Muito provavelmente mas os
detalhes também a gente divulga
posteriormente eh e alguns pontos de
atenção aqui tá as instituições elas
precisam desenvolver baseado nas
especificações e não no motor de
conformidade Então a gente tem o motor
de conformidade tem o mbank ali são
ferramentas que são para servir de apoio
pro desenvolvimento mesmo a gente pede
para a documentação oficial ela é a
especificação tá então se você achar
algum ponto que tá divergente por acaso
dentro do motor A Gente Tem trabalhado
muito para isso não acontecer mas às
vezes eh tá passível de erro tá então se
tiver alguma divergência abre um ticket
tá O importante que é foco nas
especificações eh sempre que a gente tem
uma atualização da versão Então a gente
vai sair
de uma beta um para uma beta do a gente
tem um tempo de reação do motor também
tá então tempo de atualização a gente
vai avisando vocês sempre que tiver uma
nova versão da especificação Quando que
o motor vai est disponível paraa versão
correspondente e se alguma atualização
eh impactar algum dos Marcos de sucesso
a gente tá acompanhando isso sempre
dentro da estrutura aqui dentro do Squad
sandbox e a gente passa as devidas
orientações paraas instituições Tá mas
isso pode acontecer às vezes com pouca
antecedência Então se a gente descobrir
uma um ponto que vai precisar ser
necessário um ajuste no motor hoje e tem
um Marco amanhã então pode ser que o
informa saia com pouco tempo de
antecedência não é alo que a gente pode
prever porque depende realmente dos
feedbacks que serão recebidos então
ponto de atenção aqui sempre bom ficar
de olho ali dentro nos informas E aí o
que que a gente tem de cronograma então
a gente já teve a versão Beta
eh versão 2.0 Beta disponibilizada no
dia 2 eh o motor ele tava
disponibilizado já na versão anterior
das especificações
eh e aí a gente tem no dia
23/08 o Marco a o Marco a ele já foi
detalhado no informa 613 Então as
instituições vão ter que passar em
quatro testes que vão validar a etapa
inicial do vínculo de conta e não vai
ter nenhuma requisição pro o servidor
fidal ali nesses quatro testes iniciais
depois no dia 13/09 a gente vai ter
Marco de sucesso de 60% dos Testes então
aqui já não tem mais essa segmentação
dos quatro testes em específicos Então
vai ser 60% dos Testes no total e no dia
11/10 a gente tem o 100% de sucesso
depois a gente tem a etapa
de consolidar todos os feedbacks que
foram recebidos durante os Marcos
ajustar versão das especificações versão
final do motor eh divulgar isso para as
instituições e as instituições têm que
submeter os pedidos de certificação
entre o dia 30/10 até o dia 11/11 eh
abre o ticket no service da tem uma
automação que que faz esse processamento
eh e depois desse vai gerar o link de
certificação funcional para publicar no
diretório até o dia 13/11 e aí a gente
tem o piloto come no dia 14 então é
esperado que todo mundo faça sua
publicação no dia 13 pro piloto começar
dia 14 tá então não é durante o período
de piloto eu vou fazendo a minha
publicação tá então tem todo mundo no
diretório com tudo completinho
integrações feitas piloto até dia 27/2 e
dia 28/2 a gente Abre pro restante das
instituições eu tinha visto aqui também
vou aproveitar
uma pergunta sobre que não são
obrigatórias detentoras que não são
obrigatórias também podem entrar e podem
seguir seguir o fluxo aqui dentro desse
cronograma ou se tiver interesse em
entrar posteriormente também não vai ter
nenhuma
barreira então do lado do cronograma É
isso aí agora vou passar a palavra pro
Wendel para falar aqui sobre as
perguntas frequentes que a gente
recebeu
obrigado obrigado Fabi me apresentar eu
sou Wendel trabalho aqui na estrutura
como team Líder relacionado à frente de
pagamentos turma vou disponibilizar aqui
para vocês no chat eh uma fac que a
gente criou aqui eh através das
perguntas relacionadas aqui no
desenvolvimento da jsr e elas foram
utilizadas pra gente poder construir
esse material tá eh já de antemão já
trago aqui para vocês alguns pontos que
devido ao volume de perguntas que foram
eh tragas aqui dentro do chat no final
aqui da da fac eu vou vou pincelar
algumas dessas perguntas para que a
gente consiga trazer aqui algumas dessas
informações para vocês e aquelas que eu
não trouxera aqui dentro a gente
pretende atualizar a FAC e deixar essas
informações Claras ali para vocês como
participante né então a gente tem aqui
uma relação de perguntas essas essa fac
ela foi construída eh eh com duas
categorias ali né uma categoria uma
subcategoria onde a gente tenta
segmentar O que é o fluxo eh e o que que
é operação aqui dentro né dentro das
diversas perguntas que foram
eh tragas aqui pra gente então a
primeira pergunta ali é a revogação de
um vínculo implica no cancelamento de
pagamentos agendados onde um
consentimento foi autorizado a partir
desse vínculo a a resposta até então é o
vínculo foi utilizado para autorizar o
consentimento e o consentimento permitiu
a realização dos pagamentos como o
vínculo e o consentimento são entidades
separadas a rev a revogação do vínculo
não deve implicar no cancelamento dos
pagamentos agendados a partir do
consentimento autorizado tá Wendel quer
abrir e compartilhar o link compartilhar
a tela com o link pode ser deixa eu
compartilhar aqui Fabi boa
boa só um minuto
estão vendo aqui a minha
tela perfeito ainda sim boa
Eh pergunta dois aqui turma Existe algum
tratamento específico a ser dado alguns
dos diferentes motivos de rejeição
exemplo fraude revogação feita pelo
cliente a princípio não está previsto
nenhum tratamento específico para
rejeição dos solicitantes provenientes
da jornada sem redirecionamentos os
motivos de rejeição de pagamento e
consentimento devem ser aplicados
conforme previsto na na versão corrente
da AP os motivos de rejeição dos
vínculos devem seguir os que foram
apresentados aqui dentro do desse
workshop tá ali pelo pela fala do
Zé como que funciona a múltiplas alçada
para solicitações de pagamento via
jornada sem sem
redirecionamento o vínculo ele é
utilizado para aprovação do
consentimento se o consentimento em si
possuir múltiplas alçadas
eh a aprovação via jorn ela representará
apenas o primeiro aprovador sendo
necessário recolher as demais aprovações
conforme os processos internos de cada
uma dessas detentoras tá
eh Existe algum prazo máximo para
inspiração do vínculo dispositivo a
princípio não a gente aqui e aguarda
regulamentação
eh com as definições aqui do do do
regulador pra gente poder estipular um
prazo para tal
eh trata
é possível autorizar aqui um
consentimento da AP de pagamentos
automático via jornada sem
redirecionamento atualmente não API de
jornada ela hoje está só habilitada para
pagamentos na sua família ali da da
família v4 né então que seri os
pagamentos imediatos agendados
agendamento single e agendamento
recorrente quando a gente fala de eh
pagamentos automático
não é necessário aqui disponibilizar eh
ao cliente um ambiente de gestão de
vínculo dispositivo tanto na detentora
quanto na iniciadora já que ambas devem
possibilitar a revogação desse vínculo
hoje a gente tem essa informação Sim ela
está até descrita ali dentro do guia de
usuário entre
eh quer dizer aqui que ambas as partes
tanto a detentora quanto a iniciadora
elas precisam prover esse esse ambiente
para facilitar a interação do cliente
ali
dentro em que momento a detentora tem a
visão de qual plataforma usu está
utilizando
então isso aqui ela tá relacionada ali
né No momento do vínculo do dispositivo
a plataforma ela é enviada dentro do
endp post enr enrollment de F
registration options durante o pagamento
é registrado no post enrollment
enrollment sign option sign options e
ambos os end Point da famlia r o
processo Pode ser observado através do
diagrama de sequência disponibilizado lá
no na na nossa área do
desenvolvedor eu posso rejeitar aqui uma
tentativa de vínculo de maneira síncrona
sim é possível então se se o é possível
fazer essa rejeição eh a qualquer
momento ali da na na parte da
especificação a gente só tem que se
atentar que sempre eh tem que ser
coerente entre
as razões dos códigos então pro código
422 ali que é uma validação assíncrona é
recomendado o uso cautelar do motivo de
conta inválido uma vez que pode ser
alterada pelo usuário durante o processo
de autorização e aí nesse caso a gente
recomenda o uso para casos mais extremos
como o ISPB não pertence à instituição
por
exemplo como que funciona múltiplas
alçadas para o vínculo de conta a
múltiplas as múltiplas a alada se aplica
ao pagamento em si e não ao processo do
vínculo dispositivo realizado pelo
operador da conta então por conta disso
não há o status de partly accepted no
objeto enrollment aqui da nossa
api durante a coleta de sinais de risco
é possível retornar algum erro síncrono
no post enrollment ID Risk signos Sim
hoje é possível
eh e a gente recomenda ali que o que o
processamento dos sinais de riscos
ocorra de forma assíncrona favorecendo o
cumprimento dos requisitos não
funcionais desempenhados no endp tá eh
aqui a gente se vocês podem perceber a
gente mudou aqui a subcategoria para
Sinais de risco tá essas são algumas das
perguntas eh que a gente entendeu ali
que seriam eh importantes estar dentro
da Fac Com base nas perguntas dos
participantes A detentora de conta pode
negar algum pagamento caso não tenha
recebido todos todos ou um sinal de
risco opcional ela pode aptar mas tudo
isso vai depender vai depender do
apetite a risco da detentora Ali quando
ela faz ali as suas validações
tá quais certificações são necessárias
para a detentora participar da jornada
sem redirecionamento eu acho que esse
tema aqui ele foi muito bem passado aqui
dentro da do nosso workshop mas a gente
reforçou essas informações aqui dentro
da fac para dar uma visibilidade maior
pros participantes sobre a sua
necessidade aqui de certificação então o
que que seria certificação funcional da
jsr né então tem a certificação
funcional da pi de pagamentos via Open
via Open finance tem a certificação de
segurança Open id e providers tem a
certificação fidol server via fidol
Alliance como foi comentado E aí tem
aquela aqueles dois pontos ali que
também foram bem estressados ali pelo
Paulo se instituição já utiliza um
servidor fidal certificado não é
necessário obter uma outra certificação
Mas se a instituição não possui ou
utiliza um um um um um servidor F do
certificado a instituição deve obter
conforme os passos escritos no link aqui
que são todas as orientações ali da
fidon Alliance né quais certificações
são necessárias para para iniciadora que
deseja participar da jornada sem
redirecionamento aqui a gente fala da
certificação já existente que rel
paring as as detentores de contas são
obrigadas a implementar a jornada sem
redirecionamento sim e aí a gente
reforça através dos normativos aqui né
hoje já tem um normativo do Banco
Central com essa com essa informação
dada ali todas as datas
obrigatórias Existe algum prazo máximo
que pode ser aplicado para o vínculo da
conta dentro do campo data expiration
date time no fluxo da jornada sem sem
Red
questionamento não né A princípio não o
campo data expiration date time consiste
na data de expiração do vínculo da conta
de fato e não é alterado em cada cada
transição de status definido na máquina
dos estatus do vínculo da conta essa foi
uma outra pergunta muito forte sobre
esse campo específico que a gente pegou
ali dentro da das nossas eh dos
questionamentos feitos ali pelos
participantes aqui turma a gente tá
entrando num uma nova categoria A gente
não criou uma subcategoria que tá
relacionada à parte de Limites Tá com
relação aos limites definidos para o
vínculo do dispositivo é permitido o
ajuste para um valor menor ou maior E aí
uma resposta aqui bem
eh simples aqui embora não exista isso
dentro do do do nosso manual ali do
material do do guia do de o x não é
vedada a implementação por parte das
detentoras de conta
fazer isso né existe a liberdade aqui da
implementação desse fluxo de maneira não
obrigatória As instituições podem
optar implementar isso da melhor forma
possível existe um limite de vínculo de
dispositivos ativos para o mesmo
CPF instituição iniciadora e conta de
débito não existe aqui né nenhum limite
eh eh não existe limites disponíveis que
podem ser vinculados entre a itp o
cliente e a detentora
em qual momento o itp informa ao
detentor dos limites e prazo de
inspiração do vínculo Então essa
informação aqui ela não é enviada pela
itp para detentora de conta os limites e
os prazos devem ser definidos pelo
usuário Em momento de autorização do
vínculo
onde Opa Alguém falou alguma coisa boa
eh onde o iniciador consegue consultar
os limites estabelecidos pelo cliente
eh no retorno do da consulta do vínculo
aqui no get enrollment enrollment ID pós
pós autorização do consentimento estarão
presentes os campos Day limit e
transaction limit que são preenchidos
com os valores definidos pelo usuário
durante a autorização então esses dois
Campos é que trazem ali a segurança do
usuário sobre o que pode ser
transacionado a cada transação e no
dia como que funciona conv entre os
limites do arranjo né no caso aqui o
arranjo pix a princípio e dos
dispositivos eh dos dispositivos
vinculados né ambos os limites eles
precisam ser respeitados ou seja para
uma transação ser permitida deverá eh
ser respeitado tanto o limite do arranjo
pxs definido entre o cliente e a
detentora essa configuração fica no no
âmbito da detentora quanto do limite do
vínculo definido durante a autorização
do vínculo que é essa outra informação
fica dentro do fluxo aqui da da jornada
eh entre o cliente e a detentora no
momento de validação e erros
relacionados a limites devem ser
consultados na documentação da versão
vigente da nossa ap Então hoje a
princípio a gente tem essas informações
detalhadas ali dentro da nossa
documentação haverá algum valor máximo
de limites para os vínculos durante o
período do piloto outra pergunta que foi
muito bem explorada e foi até palta as
nossas documentações hoje tanto da parte
de na jcr quanto da parte de
certificação elas estão passando por
atualizações e a princípio não
considerando que o público inicial do
piloto deve ser de usuários selecionados
pelas próprias
instituições E ali a gente diz aqui a
respeito aos Bet testers né Eh e elas
têm ali um
eh e e as instituições Elas têm um
máximo de cenários que podem ser
tratados E aí e eh a estrutura optou por
não definir um teto nesse caso então a
gente ressalta aqui que todos os
vínculos
realizados Obrigatoriamente terá um
limite Apenas não estamos limitando
quando pode ser esse pode ser definido
detalhes sobre essa definição dos
limites podem ser encontrados no guia de
experiência do
usuário eu tenho mais três perguntas
aqui do chat e eu vou pincelar mais
algumas perguntas aqui do nosso do chat
também tá Existe algum procedimento para
manter atualizada a informação dos
status do vínculo já que eles podem ser
revogados tanto na detentora quanto na
iniciadora E aí a gente tem aqui os
procedimentos passíveis que podem ser
realizados de manter essa informação
atualizada são o pulling ou webhook E aí
só uma ratificação eu cheguei a
conversar ali com o Christian da Rider
Ele tinha comentado sobre eh a falta de
de existência de o de o Web Hook na na
na versão da api ali de de vínculo de
conta e a princípio o chistian ele só se
confundiu e não era o Web Hook em sim o
pulling porque essa informação do Web
Hook ela já está presente na nossa
documentação desde a versão
1.2 Só essa ratificação aqui para ficar
claro
turma que que o campo dispositivo
autorizado o que que é esse campo
dispositivo autorizado presente na tela
de autorização de vínculo
esse campo ele permite que o cliente
Defina um nome amigável que ele quer
utilizar para aquele vínculo do seu
dispositivo isso permite que ele consiga
se Recordar mais facilmente sobre do que
se trata aquela autorização eh em um
momento futuro para aluma questão de
para para ele conseguir
relembrar Existe alguma implementação de
referência que pode ser utilizada no
desenvolvimento Sim a gente tem aqui o
próprio motor né né que que utiliza o
mock Bank Como já foi comentado aqui
existem outras implementações open
source que foram disponibilizadas e e
tiveram aqui participantes que que
disponibilizaram isso pro ecossistema
mas a princípio a gente Traz essa
informação aqui que o o o motor ele
utiliza mokb podem ser
tratadas dito isso turma eu vou pincelar
aqui algumas perguntas que foram feitas
no no no chat E aí eu abro aqui pro pro
pro pros pros participantes aqui
responderem né Quais são os sinais Eh aí
a primeira pergunta quais os sinais
serão eh quais sinais serão encaminhados
para detentora no momento do
[Música]
vínculo perfeito acho que posso
responder aqui
eh bom a gente tem na especificação ali
eh colocado claramente né então tem dois
momentos de envio de sinal de risco e
tem exatamente na especificação ali uma
uma listinha n então recomendo aí a
consulta depois aqui desse workshop para
verificar realmente essas apis ele tem
bastante detalhamento técnico tá então
isso tá de fato colocado ali boa
Obrigado Nick Então vou continuar aqui
contigo eh como que vai funcionar aqui o
piloto da jsr qualquer itp pode
participar
é desde que eh Garanta ali os requisitos
regulatórios né então tem alguns
requisitos colocados em regulação né um
deles por exemplo é o 90 dias antes do
da operação eh comunicar ali o o banco
central enfim tem outros requisitos ali
mapeados na própria regulação
eh sim na prática qualquer itp pode
participar do piloto deixe cumprindo
todos esses requisitos regulatórios sem
problemas bo Nick posso complementar
essa daqui por fav Acho que chegou a
última pergunta aqui sobre os prazos 14
de novembro é para as detentoras que são
iniciadas 99% ali tipo essas
obrigatórias E essas também tem que
cumprir a data do Gol live em 26 28 de
28 de Fevereiro paraas outras detentoras
eh não não vi essa data de 26 de janeiro
tá eh essa as demais detentoras elas vão
ser opcionais e entram quando eh se for
antes de 14 de novembro Elas têm que ter
oato ato bilateral se for entre 14 de
novembro e 28 de Fevereiro precisa
seguir a regra do go Live eh se for
depois disso
Eh aí já entra
noar aberto ou tem essa data de 28 de 26
de janeiro
pessoal é a data da regulação é
fevereiro né Tá na regulação tem a data
de Janeiro de
2026 né No outro ano PR as demais Ah
[Música]
sim perfeito Obrigada
Cris
Obrigado Janeiro 2 de janeiro de 2026
para ser mais
preciso obrigado
Carlos só para ajudar tá indicada aqui
no artigo 6 a parágrafo inciso do da
resolução
416 perfeito turma muito obrigado outra
pergunta aqui que eu tô
pincelando existe risco mapeado de
manipulação de credenciais fidos através
de instrumentos de aplicativos e
dispositivo Rot ou j breake
eck
é na verdade sim a tecnologia fidol ela
ela tem é uma garantia em hardware né
Então aí já entrando um pouco no detalhe
como funciona realmente internamente el
Você tem uma garantia no próprio chip
que ele não tem um método do tirar a
chave privada Então ela nunca sai né
Isso faz parte inclusive da homologação
do fabricante de chip junto a f wance
então Eh por mais que você tenha um gel
Break nesse dispositivo você não
consegue dumpar essa chave né ela
continua ali dentro do dispositivo ela
mora ali você não consegue clonar né
então é até muito seguro no sentido de
que eh inclusive o usuário fique imune a
Fishing né você não consegue fazer com
que os usuário eh passe a chave fidal
dele para você né Isso fica realmente no
próprio dispositivo Então nesse sentido
não não não há esse tipo de problema e a
gente tem inclusive um sinal de risco né
que se você tem um um um celular aí com
gel Break ele vai mandar um sinal de
risco aumenta o risco ali da operação
porque pode ter um sei lá um aplicativo
que não é do do itp instalado no seu no
seu celular né E tem mais né de risco
inclusive de integridade de aplicativo
ali né Então realmente isso foi bem
discutido amplamente discutido ali na
Squad e por isso desses
sinais
perfeito outra pergunta aqui eh a a
certificação do fidal é obrigatório para
quem atua somente com itp
é a certificação fidal Ela tá
relacionada a quem atua como detentor
então aqui a gente tem o f server né e
isso é um uma implementação que
pessoalmente eu acho que é altamente
recomendável não tentar Reinventar a
roda ali né a gente tem ali no site da
fidal alance se você buscar em quem está
certificado na parte fidal server você
vê claramente ali que tem dezenas
realmente de instituições certificadas
que provem esse tipo de serviço né então
autamente recomendável utilizar um
certificado pensando em detentor
pensando em iniciador o que inici tá
utilizando é o dispositivo fidal né
então é o próprio celular é o próprio
chave USB no desktop então na prática
ele tá consumindo um dispositivo que já
existe api no próprio sistema
operacional por isso então que a o itp
não precisa tirar uma certificação
porque ele não tá recriando o hardware
né ele tá utilizando o hardware
distribuindo a solução via um hardware
específico perfeito e aí a gente tá
chegando aqui próximo do do no final vou
trazer mais uma pergunta
eh qual que é o fluxo aqui no caso de
múltiplas alçadas do PJ com conta
conjunta para PF
é multipla alçada aqui ele é utilizado
para aprovação do pagamento né Então
realmente para movimentar o o saldo Eh
Ou seja você faz o vínculo dispositivo
Então você PJ é um operador o vínculo
dispositivo tá no seu operador então ele
tá realmente lincado ao que o seu
operador pode ou não fazer e uma vez que
você lança um pagamento que depende de
múltipla aprovação aí é o fluxo de
múltipla aprovação já implementado na
Instituição então eh o o ponto sobre
parcel accepted né que a gente tem uma
um status específico para isso ele mora
Realmente na hora de movimentar o saldo
então multiplo salda funciona
perfeitamente aqui e no caso j a gente
tá atendendo sim desde o dia zero né a
gente já fez a api pensando
nisso perfeito eh acho que assim como
perguntas aqui que eu consegui pincelar
dado tempo aqui do do nosso workshop
acho que a gente pode encerrar a essa
questão das perguntas aqui tá turma e as
perguntas que elas não foram respondidas
eu sugiro e peço encarecidamente que
vocês enviem elas através do Service D
que elas vão ser eh populadas a gente
vai responder isso para vocês e ao mesmo
tempo nos ajudará aqui com o
enriquecimento da nossa fac para dúvidas
futuras aqui dos demais
participantes eh Wendel oi maravilha eh
aqui que tá falando é Otávio na caixa
eh eu não sei se esse é o fórum adequado
mas assim eh
a gente perdeu o acesso ao portal e eu
já tô há quase um mês tentando fazer a
restauração do meu acesso e da da minha
técnica aqui cara quem é que pode ajudar
a gente a resolver porque quando a gente
faz a solicitação de uma troca de 100 a
gente não recebe a
mensagem do comense Octávio do Open lá
do portal do Open hum eu acho que se
você entrar numa aba anônima você
resolve eu já vio acontecia antes com
outros participantes acho que quem tem
out conta do confluence dá algum
problema se você abrir o link numa AB
anônima do seu navegador você consegue
acessar não precisa de
usuário mas eu vocês tiverem com algum
problema no acesso e se vocês tiverem se
não tiver um ticket no service desk o
caminho é solicitar por lá se já tiver o
ticket manda o número aqui no chat que
eu vou dar uma investigada também então
tá Fabian eu vou procurar aqui porque já
foi
aberto tá eh eu vou localizar aqui e vou
tentar passar para vocês
aqui Maravilha eh só reforçando aqui
obrigado tá o fluxo é esse mesmo tá
Otávio que isso mas sempre que possível
eu acho que até aims de registro eh
enviem dúvidas questionamentos ou
orientações via o service des Essa é a
ferramenta é o caminho que a gente como
estrutura pode auxiliar vocês aqui nas
tratativas de qualquer demanda tá tá
ótimo
obrigado Fabi bola contigo tá aqui tá
com duas mãozinhas levantadas não sei se
vocês conseguiram mandar Vocês conseguem
mandar aqui no chat também ou a gente
tem 4 minutos se quiser essas duas mãos
levantadas a gente vê qual é a dúvida
aqui a gente ver se CONSEG resp T
travado para mim me desculpe é o Yan
falando você você v aqui no chat ou quer
falar aqui então para mim para mim tá
travado Eu até gostaria de de mandar até
para ficar mas respeitar todo mundo né
mas é que tá você não pode enviar porque
não é membro do chat Hum tá por
isso quer falar aqui então deixa eu
perguntar vou perguntar rapidinho eh foi
falado muito sobre o fluxo do jcr ali
com com dispositivo móvel com com
celular enfim pra web também vai ser
possível né Acho que o nick até comentou
rapidinho agora no no final aí com com
token né com token ou um qualquer
notebook que tenha realmente o o o assim
se você usa o Windows 11 com certeza
você tem porque isso é pré-requisito
para instalar o Windows 11 né você ter o
o hardware de segurança e macos também
enfim e isso funciona na web né é o que
você usa como multifactor na verdade
para fazer o que o pessoal chama de
pesquis né Vocês já devem ter ouvido
falar isso justo e o conteúdo o vídeo
vai ser disponí
iiz vai a gente vai colocar no canal do
YouTube do Open finance então todos os
workshops a gente cadastra lá eh a gente
vai compilar esse material com o
restante das dúvidas também a gente
divulga o link por informa
tá beleza obrigado
Giovana desculpem eu tava com essa
dúvida também mas eu não consegui
colocar no no chat o maté Johan já já
perguntou a outra tem a ver com o pix
NFC então a gente viu que a jornada sem
redirecionamento e que vai viabilizar
esse produto né então eu só queria
entender um pouco melhor de como que
essa jornada tá sendo desenhada acho que
para mim não ficou tão
claro é isso acaba saindo um pouco do
escopo aqui eh de hoje mas eh só
colocando né a gente tem na verdade a
ideia de ter isso padronizado a gente
não tem isso padronizado ainda né a
gente já tem iniciativas de mercado para
para isso mas a gente precisa de uma
forma de transportar O que é eh o o o qu
code né Acho que o string do CR code o
meio de pagamento ali específico para
pxs e isso chegar via NFC na no
aplicativo ali mas de de tal forma que a
gente consiga garantir que isso funcione
de uma forma segura que funcione com
todos os eh todas as instituições então
assim a gente tem é isso como parte aqui
do nosso backlog mas isso tá fora do
escopo hoje desse lançamento que a gente
tá colocando que a gente tá lançando a
base que vai viabilizar um monte de
coisa Essa é uma das coisas ou seja o
pessoal que tá conseguindo fazer vai de
combinações de integrações específicas
entre
eh as entidades As
instituições é isso é realmente o que tá
acontecendo hoje de mercado né a gente
espera ter uma padronização mas por
enquanto não temos
Mas é isso pessoal acho que a gente
conseguiu cobrir bastante coisa aqui
hoje a ideia realmente a gente conseguir
trazer tudo isso para paraa fac né Acho
que tem outras pessoas vão vir aqui com
as mesmas questões a gente construiu
essa fac aqui na Squad né com com
bastante insumo que o próprio
ecossistema trouxe pra gente então é bem
interess interessante realmente ouvir
todas essas questões esses
questionamentos pra gente enriquecer os
materiais né então eh não deixem de
registrar essas dúvidas fiquem à vontade
de enviar via service desk a gente ali
na squide tá realmente eh à disposição
aqui do ecossistema para fazer isso aqui
eh ficar bem claro e
funcionar perfeito eh queria agradecer
todos os o pessoal que ajudou aqui na na
apresentação de hoje a participação de
de todo mundo também esse foi o workshop
com mais participantes que a gente já
teve no ecossistema então a gente chegou
a ter 550 pessoas online Então realmente
assunto quente obrigada a todo mundo que
conseguiu separar um tempinho e a gente
vai divulgando os materiais para vocês e
qualquer dúvida abre um ticket al no
service desk que a gente vai respondendo
vocês tá bom Obrigada pessoal boa tarde
bom de semana valeu gente Parabéns
pessoal valeu