Piloto Jornada Otimizada (JO) - Workshop Open Finance Brasil

Olá,
boa tarde, pessoal.
>> Boa tarde.
>> Boa tarde.
Boa tarde, pessoal.
Ja. Pega que eu vou ter que entrar.
Boa tarde, pessoal.
Só mais alguns minutinhos aqui, só para
mais algumas pessoas entrarem. A gente
já inicia o nosso workshop.
Boa tarde,
Boa tarde.
Boa tarde,
>> então. Ja.
Boa tarde, pessoal. Já vou dar início
aqui ao nosso workshop relacionado ao
piloto da jornada otimizada. Então,
antes de mais nada, sejam todos muito
bem-vindos.
Apenas compartilhando alguns pontos
iniciais. Nesse work, o nosso objetivo é
falar um pouco sobre como é funcionar o
piloto da jornada otimizada, utilizar
esse canal para tirar dúvidas das
instituições, eh compartilhar
informações importantes e ser mais um
bate-papo para deixar todos na mesma
página com relação a esse piloto.
Antes de de também iniciarmos outras
informações importantes, então esse
workshop aqui ele tá sendo gravado.
Então como de costume, a gente também
vai disponibilizar a gravação desse
workshop no canal do YouTube do Open
Finance Brasil. Então a gente pede
também para todo mundo que, por favor,
quem tiver dúvidas, a gente vai
responder todas as dúvidas pelo chat
aqui do do workshop e no final do
workshop, se alguém ainda tiver alguma
dúvida, a gente tem um tempinho ali
reservado para tirar essas dúvidas com
vocês. Então, só reforçando dúvidas, por
favor, aqui via o chat desse workshop.
Então, também nos apresentando aqui, a
gente tá dividindo esse workshop eh
entre a gente aqui de sucesso
participante, o pessoal do grupo de
produtos, dados do cliente, o Zé também
de arquiteturas integração, pessoal de
experiência de usuário também a Helena e
a Paloma da nossa equipe de sucesso do
participante. Então, já dando início à
nossa pauta, a gente separou essa agenda
em seis partes. A primeira delas, vamos
falar um pouco sobre como vai funcionar
a jornada otimizada em si, falar sobre
os conceitos relacionados mais ao
produto da jornada otimizada. Vamos
entrar também detalh sobre como vai
funcionar a jornada do ponto de vista do
usuário. Em seguida, a gente vai falar
sobre conceitos de piloto. Então, o que
que é exatamente um piloto? Como
funciona as restrições de usuários de um
desse piloto de jornada otimizada. Vamos
passar também aqui sobre o que que a
gente espera de cumprimento de critérios
para as instituições. Então, o que que
elas vão ter, as instituições vão ter
que cumprir tanto a nível de detentoras,
transmissoras de dados, quanto a nível
das ETPs, passar um pouco sobre o nosso
cronograma de responsabilidade e que nem
a que nem a gente comentou, no final
também vão ter um espaço aqui para tirar
eventuais dúvidas ainda pendentes.
Então, agora sim, já dando início à
nossa primeira pauta, passo a palavra
aqui para Bruna. Fique à vontade.
>> Obrigada, Iago. Bom, boa tarde a todos.
Eu sou a Bruna aqui, PM, do time de
dados do cliente. Eu vou trazer um
pouquinho do contexto do produto de
jornada otimizada. E aqui a gente vai
começar pela linha do tempo, né? Então,
jornada otimizada começou a ser
discutida em junho de 2025, onde as
publicações ocorreram entre agosto e
novembro, junto com a disponibilização
dos guias de UEX. Na sequência, nós
tivemos a disponibilização do motor e
marco de certificação paraa jornada
otimizada Mais com sentimento, ocorrendo
entre
ocorrendo entre novembro e dezembro,
depois jo
entre novembro e janeiro, jo mais
pagamentos automatizados ali no início
de novembro e final de janeiro. A
adequação, né, das ferramentas da
estrutura começou em outubro e finalizou
no final de janeiro. A disponibilização
em produção ocorreu no dia 6 de
fevereiro e agora a gente vai entrar no
período de piloto a partir da semana que
vem, de 22 de abril a eh 20 a 22 de
junho, sendo Go Live 22 de junho. Iago,
você puder passar.
Agora a gente vai falar um pouquinho do
que que é, né, a jornada otimizada, o
que de fato ela resolve, né? Então a
jornada otimizada ela une dois fluxos,
né, da jornada do usuário. O
compartilhamento de dados, nesse caso,
saldo disponível e limites operacionais
e pagamentos, sendo para transferências
inteligentes ou jornadas sem
redirecionamento. Essa autorização com a
jornada otimizada, ela vai ocorrer a
partir de uma experiência única. E vale
ressaltar que os consentimentos eles
permanecerão segregados, será utilizado
as APIs existentes, conforme os fluxos
técnicos atuais e a experiência do
usuário ocorrerá de uma maneira única. E
o que que a gente quer trazer aqui com o
Jo, né? Qual que é o nosso objetivo? Eh,
a gente tem um objetivo de trazer mais
informações e segurança pros usuários no
fluxo de pagamento, simplificando a
jornada do cliente, visto que a
autorização de acesso a dados e
contratação desses serviços vai ocorrer
de uma maneira única. Com isso, a gente
entende que jo resolve alguns problemas,
né? Hoje os consentimentos de dados e
serviços são separados, crendo uma certa
fricção dentro dessa jornada, o que traz
mais complexidade e até uma certa
limitação de uso pelo próprio
ecossistema. Com a jornada otimizada, a
gente tem oportunidade de realizar um
aumento na conversão de pagamentos e
reduzir erros por falta de saldo
insuficiente. Tá?
Pode passar aqui, ô Igo, só trazendo
mais contexto em relação, né, eh, ao que
o usuário ter a possibilidade, né, de
compartilhar seu saldo e limites a
partir de dois produtos de iniciação de
pagamentos. JSR, que é conhecida dentro
do mercado como o Pix por aproximação,
onde o usuário faz um vínculo de conta a
um aparelho e a partir dali todo o
pagamento é realizado sem
redirecionamento e para transferências
inteligentes, onde existe, né, o
cadastro de uma regra, um gatilho,
depois a gente tem, né, a execução dessa
regra e no final a ação de fato de
execução automática do pagamento, tá?
Com isso, eu vou passar agora a palavra
pro José para trazer um pouco mais de
questões técnicas sobre aqui a jornada
otimizada.
Obrigada.
>> Boa tarde, pessoal.
Eh, eu vou assumir aqui, vou falar um
pouco sobre a parte técnica da JO. Iago,
você pode passar pro próximo. Acho que é
o Iago que tá apresentando. Isso.
Perfeito. Eh, como a Bruna bem
mencionou, né, o objetivo da Jar de uma
experiência unificada pro usuário poder
autorizar
tanto um consentimento de transferência
inteligente, um vínculo de conta ou um
consentimento de dado eh perdão,
consentimento de transferência
inteligente ou vínculo de contas e o
consentimento de dados, né, associado a
um ou a outro, tá? em uma jornada
unificada.
Eh, para isso, a gente precisou criar um
conceito de consentimento primário e
consentimento secundário, né? Eh,
considerando que o consentimento de
pagamentos, ele de fato manifesta uma
vontade do cliente em realizar uma
transação eh recorrente, tanto o
consentimento de pagamentos quanto o
vínculo de dispositivo.
Entendeu-se que aquele seria o
consentimento primário nessa jornada,
tá? E o consentimento de dados é o
consentimento secundário.
Ali a gente tem a lista de escopos que
são necessários para cada um dos
produtos, porque vocês vão observar mais
ali na frente aonde que a mágica
acontece, tá? Que é a chamada do barra
par. Então, por isso que a gente, por
isso que eu preferi colocar essa lista
de escopos aqui já para dar uma uma
sensação de como que vai funcionar ali
na frente para cada um dos produtos, tá?
Eh,
aqui a gente, obrigado aqui a gente já
tem a um fluxo técnico bem simples de
como que funcionaria isso, né? Primeiro
a gente tem a autenticação sistêmica a
partir de tokens de tipo client
credential, né, com grand type client c
predentials. Compose desses tokens em
mãos a ITP, primeiro precisar ITP, o
receptor aqui no caso, primeiro
precisaria criar um consentimento de
dados,
mencionando a de dentro do consentimento
de dados. Opa, ficou meio escuro aqui,
né, pessoal? Um minuto aí, já vou
voltar.
eh, onde ela precisaria colocar ali no
consentimento de dados a indicação que
esse consentimento será linkcado logo
mais, tá? Então, ela vai criar um
consentimento com e mandar ali a flags
linked como true. Depois ela vai
precisar criar um consentimento de
transferência inteligente ou um vínculo
de conta. É que ela vai associar esse
consentimento de dados a esse
consentimento de transferência ou ao
vínculo, tá? Eh, e essa associação é
feita com base no preenchimento de um
campo dentro de um novo objeto que é o
Link ID, né? Nós temos dois campos
dentro desse objeto, tanto na no
consentimento quanto no vinculo. Um é
uma flag dizendo seria linkcado com algo
ou não. E o outro é o link da flag, é o
o
identificador do consentimento de dados
correspondente, tá? O link ID ali, ele
recebe o valor do consentimento de dados
obtido na chamada anterior ali no passo
dois.
em posse de ambos esses identificadores,
né, tanto do consentimento de dados
quanto do consentimento de pagamentos
ali ou de ou do vínculo de conta, ele
vai fazer uma chamada no barrapá e essa
chamada vai precisar possuir ali no no
campo dedicado aos scopes os scopes
necessários para para ambos os
consentimentos ou pro consentimento e
pro vínculo, tá? Então, é por isso que a
gente tinha naquele slide anterior uma
configuração diferente de escopo para
cada produto, né? Porque cada produto
vai precisar ser enviado um conjunto de
escopos específicos na chamada do
barrapá, porque é ali que a detentora
vai fazer o matching, né, entre o
consentimento de dados e o de pagamento
para poder devolver um redirecti único
pro usuário poder autorizar os dois numa
jornada única, tá?
que é justamente o que acontece ali no
passo cinco, né, que é a aprovação.
Então, o usuário foi redirecionado, já
tá ali em ambiente do detentor, ele vai
selecionar uma conta e aprovar o
consentimento, tá? Eh, seleção da conta
aqui é a conta de débito, né? se não for
informada pelo ITP, mesmo que seja, o
usuário também pode alterá-la lá no
ambiente do detector.
Eh, em posse dessa autorização, né, eh,
volta ali para pra ITP o autorization
code. Ela pode usar esse autorization
code para emitir para emitir access
token, que vai ter os escopos
combinados, tá? Então todos aqueles
escopos que foram enviados ali no
barrapar, eles vão ter que ser esse
excess token vai ter que dar acesso, tá?
Para transações que utilizam-se daqueles
escopos. E em posse desse excess token,
ela vai poder fazer as chamadas ali do
passo 7, passo oito e do passo tá? E
sobre os critérios de renovação desse
access token, vou falar dele mais ali na
frente, tá?
Pode passar.
Aqui é o ponto que eu mencionei, né?
Como vocês podem observar ali na imagem,
a gente tem tanto um consentimento de
dados quanto temos dois consentimentos,
né? No exemplo ali é um consentimento
que seria o consentimento de dados e o
outro que seria o consentimento de
pagamento. Eh, tá? Não, não, não tá o
mais correto ali. O ideal seria que
fosse um constant e um recuent, tá? Mas
para critérios de exemplo, eu entendo
que é suficiente, são, só questão de
nomenclatura, tá? Então, basicamente o o
que a gente tem aqui é
o par como um orquestrador, né, dessa
dessa relação entre esses dois
consentimentos, tá? Então é ali que a
detentora vai poder identificar que
aquela aquele pedido de autorização que
chegou via depoite de par é um pedido de
autorização para redirecionar o usuário
para uma jornada otimizada dentro da
própria instituição, tá?
Pode passar. Iar
aqui é um pouco sobre os cenários de
aprovação e como que vai ser o trabalho
com Access token, né?
Eh, se o usuário ali no ambiente do
detentor, ele vai ter um a Débora vai
entrar mais no detalhe ali de como que
vai ser a interface a a usabilidade do
usuário, a experiência de usabilidade,
mas basicamente
durante o processo de autorização
daqueles recursos, ele vai ter em tela
que ele tá autorizando um consentimento
de pagamentos e ele vai ter a
possibilidade de marcar uma caixinha ali
para poder compartilhar também dados eh
de conta e limite com essa dados de
saldo e MIT com essa junto dessa mesma
autorização, né, ali em um em uma em um
movimento único. Então, se ele clicar
ali em rejeitar ou ele abandonar a
jornada sem ter clicado em autorizar em
nenhum momento, eh, ele significa que
ele tá rejeitando os dois
consentimentos, tá? Então, ambos os
consentimentos precisariam ser
rejeitados.
Se ele desmarca essa caixinha que eu
mencionei de dados, mas mesmo assim
clica em autorizar, então o
consentimento de pagamento ali ou
vínculo de dispositivo devem ser
autorizados, enquanto que o
consentimento de dados deve ser
rejeitado, tá? E se ele mantém ali a
caixinha marcada dizendo que ele quer
compartilhar os dados também, então
ambos os consentimentos, quando ele
clicar em autorizar, devem ser
autorizados, salvo situações que impeçam
essa autorização.
É, como pré-requisitos para poder
ofertar esse produto, a gente tem que os
os ASS das detentoras precisam ter as
rows, dados e contas habilitados e as
ITPs que querem ofertar esse produto
paraos seus clientes precisam ter no seu
software statement os papéis, dados e
pacto habilitados, tá?
O excess token ele é vinculado ao
consentimento aprovado. Então, se ambos
os consentimentos forem aprovados, você
vai ter o escopo completo, tá? Se apenas
serviço for aprovado, o escopo de dados
deve ser removido do Exstoping, tá? E
não deve poder acessar informações de
dados, uma vez que esse consentimento de
dados foi desmarcado ali pelo usuário
durante a jornada, tá?
E a renovação ela se aplica, né, o
refresh token desse access token, ele se
aplica se ao menos um consentimento
tiver válido. Mas esse um consentimento
válido é apenas o de pagamento, porque a
gente não tem um o de pagamento ou o
vínculo do dispositivo, que a gente não
tem um cenário aqui aonde o apenas o
consentimento de dados fica ativo, tá?
Então, se ao menos um consentimento
válido, aqui seria ou consentimento de
pagamentos ou o consentimento de
transferência inteligente.
Eh, se apenas um deles estiverem ativo,
se renova, claro, renova-se com o escopo
de dados removido, conforme tá
mencionado ali no de cima, mas renova-se
ainda esse esse ex stokken a partir de
um refresh, tá?
Eh, e as permissões que precisam ser e
as permissões que podem ser utilizadas
ali pelos ITPs na hora de criar esse
consentimento de dados são account
reads, account balances read, account
overdraft limits read e resources read.
O detentor, quando ele receber uma
requisição de criação de consentimento
ali da fase dois, eh, e tiver com aquele
campo anterior ali, eu acho que é
slinked, se eu não me engano, lá no
consentimento de fase dois, eh,
preenchido como true, esse é o único
conjunto de permissões que ele pode
solicitar, tá? caso tenha uma uma
permissão a mais nesse consentimento com
aqueles linked como o true, o detentor
deve rejeitar com 422 informando que o
conjunto de permissões está inválido,
tá? para aquele para aquele
consentimento em específico.
Pode passar aí, Iago.
Aqui é um pouco sobre a questão da
revogação, né, como eu mencionei antes.
Então aqui a gente tem a questão do
consentimento de dados ser secundário e
e ser secundário e o consentimento de de
serviço ali, né, que a gente tá aqui
englobando tanto transferência
inteligente quanto JSR,
ele ser o primário, né? Eu acho que o
ponto mais importante desse slide aqui,
sem para eu não precisar me repetir, é a
questão da extensão da validade, tá? A
gente tem agora na última versão da JSR,
da jornada sem redirecionamento, que tá
em piloto agora, a possibilidade do
prazo de validade do vínculo ser
estendido, tá?
Eh, quando um vínculo de dispositivo tem
o prazo estendido, o e ele tá associado
a um consentimento de dados do cliente,
a extensão do prazo de de validade desse
vínculo também estende o prazo de
validade do consentimento de dados, tá?
Enquanto que para transferência
inteligente a gente não tem essa
possibilidade de mover o consentimento
para a data, né, de validade desse
consentimento de dados. Porém, a o de
transferência inteligente tem uma
particularidade que ele pode ser
consumido, né? Significa o quê? Quando a
gente tem ali uma configuração de limite
global máxima que pode ser trafegada
dentro desse consentimento. E ao atingir
esse valor, exatamente o valor que tá
configurado pelo usuário,
esse consentimento é consumido, tá? E o
consumo desse consentimento eh
impossibilita a geração de refresh,
porque o o token, né, a emissão de novos
access tokens está condicionada ao
estado do consentimento e ele só emite
para estados autorizados, tá? Então não
seria mais possível utilizar esse
consentimento. Logo, o consentimento de
dados também não seria possível mais ser
utilizado, tá? uma vez que o
consentimento primário, que seria o de
transferências inteligentes,
foi consumido, tá?
Eh, bom, é isso. Eh, caso tenha alguma
dúvida, vocês podem ir colocando aqui no
chat que eu vou estar atento para
respondê-las.
Eh, e acho que agora eu passo a palavra
para Débora. Certo.
>> Boa tarde, pessoal. Débora aqui do time
experiência. Vou apresentar para vocês,
então, eh, tangibilizar nessa parte
técnica em experiência do usuário.
Então, primeiro a gente vai começar com
as transferências inteligentes.
Lembrando que as jornadas são muito
similares, né, mas a gente vai passar
aqui pelas duas. Então, eh, o usuário
começa ali na ITP, né, a sua jornada de
pagamento e ele é oferecido a
oportunidade de compartilhar os seus
dados de saldo e limite. É importante
relembrar que essa escolha ela é
opcional. né? Então, o usuário ele não
pode ser obrigado a escolher. ele tem
que poder continuar essa jornada de
pagamento sem necessariamente escolher
compartilhar o seu saldo limite. Uma vez
que ele fez essa seleção, né, por
exemplo, eh marcando aqui a caixinha de
compartilhamento,
ele prossegue pela jornada, configura
ali os parâmetros da autorização de
transferências inteligentes. E aí a ITP
precisa informar para ele eh que esses
dados de saldo limite estão sendo
compartilhados, bem como o escopo de
cada um desses dados. Então, todas as
informações que serão compartilhadas,
né, junto ali com seu saldo e limite.
Então, ele vai clicar em continuar
e vai ser direcionado paraa detentora.
Pode seguir, por favor, Iago.
Uma vez que ele chega na detentora, ele
não consegue editar nenhuma informação,
mas a detentora precisa informar que
esses dados também estão sendo
compartilhados, né? Então, mesmas
informações, quais são esses dados e o
escopo de cada um desses dados. Uma vez
que o usuário confirma, ele volta para
ITP. Pode seguir, por favor.
Isso. E aí na ITP, né, na efetivação da
autorização, mais uma vez a ITP informa
pro usuário que esses saldo limites
estão sendo compartilhados. aqui não
precisa repetir qual é o escopo, né?
somente a informação. E aí é importante
também a ITP avisar o usuário que esse
consentimento de dados ele pode ser
cancelado a qualquer momento. Eh, e aí a
gente vai paraa área de gestão. Então,
na área de gestão das duas instituições,
o usuário precisa ver ali uma lista com
todas as autorizações de pagamento que
ele deu, com destaque eh para aquelas
paraas quais ele compartilhou seus dados
de saldo limite. Então, aqui no nosso
exemplo de tela, a gente tem uma tag,
né? Então, saldo limite compartilhados,
mas aí cada instituição pode utilizar eh
a forma de destaque que entender seja
que seja melhor. Pode seguir, por favor.
Bom, uma vez que o usuário eh clica
nessa nessas autorizações para ver os
detalhes, ele precisa ver novamente essa
informação de que os saldo limite estão
sendo compartilhados e mais uma vez
precisa ver o escopo desses dados.
Então, tanto na ITP quanto na detentora,
ele vai ter essas informações nos
detalhes. Seguindo.
Bom, se o usuário eh optar por cancelar
a autorização de pagamento, ele precisa
ser informado ali no momento do
cancelamento que o compartilhamento de
saldo limite também será cancelado, né?
Seguindo a regra que o José já
mencionou.
Eh, pode seguir.
E aí na área de gestão da das
autorizações de pagamento, ele visualiza
que a autorização de pagamento foi
cancelada. E na área de gestão de dados,
ele também visualiza que o consentimento
de dados atrelado também foi cancelado.
Pode seguir, por favor.
Caso ele decida cancelar somente o
compartilhamento de saldo limite, ele
precisa ser informado de que a
autorização de pagamento se mantém
ativa. Tô lembrando que o
compartilhamento de saldo limite é
secundário e o seu cancelamento não
cancela o
cancelar o autorização de pagamento.
Pode seguir, por favor, Iago.
E aí, se ele cancela o compartilhamento
de saldo limite na área de gestão de
dados, ele vê esses dados eh cancelados,
né, o compartilhamento cancelado, mas a
autorização de pagamento se mantém ativa
sem agora aquela tag, né, aquele
destaque de compartilhamento de saldo
limite. Eh, e essa é a parte de
transferências inteligentes. Agora a
gente segue paraa vinculação de conta.
Pode seguir, então a jornada de
vinculação de conta, ela é muito similar
a de transferências inteligentes, né?
Então, supondo que o usuário eh foi ele
na área de gestão do vínculo de conta ou
ele fez essa vinculação através de uma
jornada de pagamento, né, uma vez que
ele seleciona que ele quer vincular a
conta, a ITP pode dar para ele a
possibilidade de compartilhar os seus
dados de saldo limite, informando ali no
momento da solicitação quais são esses
dados que serão compartilhados, bem como
o escopo. Lembrando que ele não é
obrigado a compartilhar esses dados
nessa jornada. Uma vez que ele seleciona
e que quer compartilhar, ele é
direcionado pra detentora escolhida.
Pode seguir, por favor.
Na detentora, mais uma vez ele precisa
ser informado desse compartilhamento de
saldo limite, bem como o escopo desses
dados. Pode seguir
isso. E aí ele volta paraa ITP. na ITP,
ele tem ali a efetivação, né, o sucesso
da criação do vínculo e também ele deve
ser informado de que esses eh esse
consentimento ele pode ser cancelado a
qualquer momento.
Pode seguir
na área de gestão, mais uma vez nas duas
instituições, ele precisa ver a lista,
né, dos vínculos de conta com destaque
para aqueles pros quais ele decidiu
compartilhar o saldo limite, né, através
ali de uma tag ou de qualquer outro tipo
de componente que as instituições
entendam. ser melhores. Pode seguir.
Eh, uma vez que ele clicar no detalhe
desse vínculo, mais uma vez ele vai ver
ali essas informações de que seus saldo
e limites estão sendo compartilhados,
bem como o escopo de cada um desses
dados.
Seguindo
eh o que o Zé falou, né, sobre uma
particularidade aqui da jornada de
vinculação de conta, é que o usuário ele
pode alterar o prazo do vínculo. Então,
qualquer que seja a alteração que ele
faça, né, seja uma extensão, seja uma
diminuição do prazo, essa alteração
também altera o consentimento de dados.
Então, uma vez que ele fizer essa
alteração, ele precisa ser informado de
que esse novo prazo também vai valer pro
compartilhamento de saldo e limite.
Pode seguir.
Eh, caso ele deseje cancelar o vínculo,
ele precisa ser informado de que o saldo
limite também vão ser cancelados.
pode seguir.
E aí na área de gestão, eh, tanto de
pagamento, de vínculo quanto de dados,
ele vê que os dois consentimentos foram
cancelados, né, nas duas instituições.
Pode seguir. Se ele decidir cancelar
somente o compartilhamento de saldo
limite, ele é informado de que o vínculo
de conta se mantém ativo. Caso ele
decida por cancelar o compartilhamento
de saldo limite, pode seguir.
Ele visualiza na área de gestão que o
compartilhamento de saldo limite foi
cancelado e na área de gestão do vínculo
de conta que o vínculo se mantém ativo
sem a tag, né, ou o destaque ali de que
o compartilhamento de saldo limite eh
está ativado, né, para esse vínculo de
conta.
E é isso, pessoal, da jornada eh
otimizada, né, para esses dois produtos.
Eh, a experiência do usuário aqui.
Qualquer dúvida podem mandar aí no chat
que a gente responde. Muito obrigada.
>> Obrigado. Eu, Débora. Então, pra próxima
etapa agora falando um pouco mais sobre
os conceitos de piloto. Passava passar a
palavra aqui para Helena. Então, fica à
vontade.
>> Obrigada. Bom pessoal, boa tarde. Sou
Helena aqui do time do Participante. Vou
falar um pouquinho sobre piloto.
Ah, bom, quanto ao conceito do piloto,
ele é basicamente a nossa fase de testes
em ambiente real antes do Go Live. É o
momento da gente validar na prática se
os produtos, as APIs e as integrações
entre as instituições, elas estão
funcionando como deveriam.
Quanto ao objetivo do piloto, o foco
principal é garantir o funcionamento,
né? a interoperabilidade em ambiente
produtivo.
A a ideia é a gente se antecipar para
poder identificar qualquer problema
antes do lançamento oficial.
E para isso a gente
faz a criação de agendas, tanto
bilaterais quanto multilaterais, para
que a gente consiga corrigir qualquer
problema que ocorra durante o processo,
seja na seja entre as estruturas ou
entre as próprias instituições.
Eh, falando sobre as responsabilidades,
ah, as instituições detentoras e
transmissoras, elas precisam estar com a
funcionalidade plena desde o dia zero do
piloto, que vai ser no dia 22/04.
Se os critérios eles não forem atingidos
durante o processo, a gente entra com a
estratégia de salas de guerras, né, que
as warhross, para poder apresentar e
acompanhar de perto os planos de ações.
Quanto as ITPs, ah, a gente tem um
ponto, a gente tem um ponto importante,
quem já estiver com a jornada disponível
até dia 30/04, não participa do piloto,
vai direto pro público geral após o go
live.
Já para quem for participar como ITV
voluntária, o acesso ele é restrito aos
usuários autorizados pros testes e as
instituições que não atingiram os
critérios de sucesso, a gente também
monta as warhross para poder garantir os
os ajustes.
Outro ponto importante é que essa
participação ela pode ser gradual, isso
permite que o ecossistema consiga
evoluir com autoridade. Com isso, a
gente garante que quando o produto
chegar no público final, ele esteja
estável e com uma jornada fluida.
Eh, quanto à parte de de restrição de
usuários, a Paulão vai conseguir
explicar um pouquinho melhor para vocês.
Pessoal, boa tarde.
Eh, se estiver com um pouco de ruído é
porque eu moro em apartamento e está
tendo obra exatamente do lado do meu eh
apartamento.
Mas falando um pouco sobre restrição de
usuários para vocês, tá? Eh, será
necessário fazer um passo a passo ali do
início do piloto e
falando sobre as detempleoras, tá? O que
que será necessário ser feito? Então,
para as detempleiras, será necessário
fazer a configuração
de restrição desse recurso através da
pleg de homolocação JO na API de
Constants, na versão 3.3.1,
eh, lá no diretório no metadados. Esse é
o primeiro passo que as detentoras
precisam fazer. O segundo passo é
indicar quais serão os vivuários que vão
ter acesso a esse produto em produção
através do formulário que já está
disponível nas gerais do piloto. Isso é
para as detentoras. Para as ITPs é
necessário que ela construa um fluxo
onde vai consumir essas informações, tá?
tanto da flag de homologação JO, quanto
da dos usuários que estão, né, nesse
formulário. Então, é importante para
garantir que os usuários eh para que
todo esse processo de restrição desses
usuários, tanto esses dois passos da
detentora quanto eh essa esse consumo
dessas informações do lado das ITPs.
Claro, quem já participa de JSR,
ã, já está habituado porque a restrição
de usuários em JO será idêntica à
restrição de usuários que aconteceu em
JSR, tá? Qualquer dúvida que vocês
tiverem podem colocar aqui no chat que a
gente vai respondendo vocês quanto a
isso.
>> Boa. Obrigado, Pauloma. Então, então já
dando sequência aqui, agora que a gente
já deu um pouco mais de contexto sobre o
que que vai ser a, o que que é a jornada
otimizada em si, sobre objetivo de
piloto e funcionamento da restrição de
usuários, já entrar um pouco mais no
detalhe sobre os critérios do piloto da
jornada otimizada em si. Então, antes de
entrar no detalhe dos critérios em si,
acho importante destacar também que no
dia de ontem, no dia 16, a gente teve
duas instruções normativas divulgadas
pelo Banco Central. Então, a gente
recomenda a leitura delas
para todos. Vou pegar todos os links
úteis que a gente compartilhar aqui no
final, mas eu vou colocar aqui no chat.
Então, são muitas informações, mas
muitas informações relevantes aqui.
Então, dentre desses links que eu
coloquei aqui no chat, estão as duas
instruções normativas, a IN725 e e a
IN724. Então, tem N725 que rege a
relação que rege os o conceito de testes
em produção para a jornada otimizada. E
aqui nessa tela a gente vai dar um
resumo para vocês o que que vai ser
cobrado durante esse período, nos dois
próximos meses. Então no primeiro
momento, eu acho que muito similar a
todos os pilotos anteriores, a gente vai
cobrar uma taxa paramente de 95% para as
instituições. Então como a gente não tem
uma API específica para a jornada
otimizada, a gente vai avaliar as APIs
de relacionadas a pagamentos, APIs
relacionados a consentimentos também. A
gente também cobre que todos os
additional infos sejam enviados, porque
eles são extremamente necessários pra
gente conseguir de fato contabilizar os
critérios de engajamento que a gente vai
falar já já. Então, como por exemplo,
person type, o payment type, os o os
campos de journey relacionados a jornada
otimizada, como o journeys link, journey
linked, então a gente realmente precisa
desses adicionos pra gente conseguir
contabilizar os critérios de
engajamento. Então, um terceiro ponto
aqui relacionado também integração com
as ferramentas eh com relação a ticket
de qualidade. Então, a gente também vai
garantir que todos os tickets de
qualidade não esteja nenhum, na verdade,
aberto durante pontos de controle. o que
que são exatamente esses pontos de
controle. Então é o conceito que a gente
tá introduzindo, o conceito novo que a
gente tá introduzindo nesse piloto de
jornada otimizada, mas não mais são do
que datas intermediárias ao longo do
piloto, em que vamos fazer um um
consolidado de todas as pendências que
já foram notificadas das instituições e
consolidar isso em um único ticket.
Então, esses pontos de controle nada
mais são do que garantir que tudo que já
aconteceu de pendência seja corrigido e
nada esteja em aberto durante essas
datas. Então a ideia é apenas não
esperar o final do período do piloto pra
gente conseguir consolidar essas
pendências e notificar as instituições,
mas garantir que nessas etapas
intermediária, nesses pontos de
controles, as instituições estejam
adequadas sem nenhum ticket também
aberto. H com relação a ticket tickets
bilaterais, então não só nesse ponto de
controle, a gente vai ver os tickets de
qualidade abertos pela PC, mas também
vamos ver os tickets bilaterais abertos
pelas ITPs, as detentoras e vice-versa.
Então aqui a gente tá falando um pouco
sobre detentores e transmissoras, mas
até o momento os critérios deles são os
mesmos também para as ITPs. Então nesse
momento de pontos de controle também não
pode ter nenhum ticket bilateral em
aberto, senão senão o novo ticket também
vai ser aberto e com relação com esses
consolidadas essas pendências. Agora
falando sobre os critérios de
engajamento,
a gente vai cobrar para todas as
instituições, né, esse critério de
engajamento que envolve separação entre
consentimentos criados via jornada
otimizado e pagamentos liquidados também
via jornada otimizado. Entrando na parte
de criação de consentimento e vínculos,
a gente vai cobrar de todas as
detentoras sem consentimentos
transferências transferências
inteligentes criados com jornada
otimizada, sendo pelo menos 20 PJ quando
aplicável. tem que ter pelo menos também
um consentimento criado com 50% das ITPs
participantes do piloto. Isso
relacionado a transferências
inteligentes. Quando a gente fala de
vínculo dispositivo, a gente vai também
cobrar
esses 100 vínculos dispositivos criados
com a jornada otimizada, sendo pelo
menos 20 PJ. E também um vínculo criado
com pelo menos 50% das ITPs
participantes do piloto. A gente vai
falar um pouco melhor mais para frente,
mas aqui o objetivo não é só chegar no
final do piloto com tudo, com todo esse
critério com com predos. a gente também
vai ter esses marcos intermediários que
vamos garantir que uma porcentagem desse
desse critério de engajamento sejam
atingidos. Então, no marco de 30%, por
exemplo, a gente vai cobrar que pelo
menos 30 consentimentos de
transferências inteligentes sejam
criados, 30 vínculos dispositivos também
sejam criados. Quando a gente passar o
cronograma, já já a gente eh vai ficar
mais claro. Então, quando a gente entra
aqui com relação ao critério de
liquidação de pagamentos, a gente vai
cobrar 40 pagamentos de transferência
inteligente, transferências inteligentes
liquidados, utilizando com sentimentos
feitos via uma jornada otimizada, sendo
pelo menos 10 PJ, e um pagamento
liquidado com menos 50% das ITPs
participantes do piloto. Quando a gente
fala de vínculo dispositivo, a gente
também vai cobrar 40 pagamentos
liquidados, utilizando um vínculo
dispositivo criado com uma jornada
otimizada, com pelo menos 20 pagamentos
imediatos e pelo menos também 10
pagamentos PJ quando aplicado. Também um
pagamento liquidado com pelo menos 50%
das ITPs participantes do piloto. Então,
eh, esse critério de engajamento são
critérios que sempre
eh precisam de um pouco mais de atenção
das instituições, então precisam de um
pouco mais de esforço. Então a gente vai
também acompanhar eles de perto, apoiar
apoiar vocês a entender como cumprir
esse critérios do acompanhamento. Vamos
falar mais para frente como que a gente
vai fazer acompanhamento de perto com
vocês, mas já deixando também
compartilhado que eh são critérios que
vamos acompanhando parcialmente com
marcos intermediários ao longo de todo o
período do piloto.
com agora já passando pro próximo
critério específico para as detentoras e
transmissoras, a gente tem como de
costume também os testes relacionados à
FVP manual. Temos ao todo oito testes,
todos de curta duração. Temos para
transferência inteligente cinco testes
de curta duração. Para vínculo
dispositivos mais cinco testes de curta
duração. E temos mais três outros testes
de curta duração que se aplicam tanto
para as instituições que ofertam vínculo
dispositivo quanto transferência
inteligente. Então, por exemplo, sem
minha detentora eu oferto oferto a
jornada otimizada apenas com vínculo
dispositivo. material todo, oito testes,
105 específicos de JSR e três de outros
cenários. Essa é minha instituição
oferta, tanto transferência inteligente
quanto JSR. E eu teria ao todo 13 testes
de curta duração para ter sucesso nos
marcos que no cronograma. Então, hum
falando também agora sobre as validações
da das jornadas de experiência, a gente
vai fazer a validação com as
instituições do grupo de controle. São
instituições de 16 conglomerados que que
também estão divulgados na IN725, que
vão fazer essas validações de um teste
de jornada para transferência
inteligente e um teste de jornada de
vínculo dispositivo, criando
consentimentos com jornada otimizado.
Esse são os resumos, um resumo dos
critérios que vamos cobrar para
detentoras e transmissoras. Quando a
gente fala aqui para as ITPs, então a
base pode estender que é exatamente a
mesma, mas tem algumas diferenças aqui,
principalmente quando a gente fala de
critério de engajamento, mas só dar uma
passada rápida, pareamento, vamos cobrar
95% também de pareamento envio de
agonfos também vamos cobrar envio desses
campos. Ponto de controle vamos ter
também paraa qualidade das chamadas e
também ticketes bilaterais. Agora,
entrando mais detalhe nos critérios de
engajamento, quando a gente fala de
criação de consentimentos, a gente vai
cobrar para as ITPs ao menos um
consentimento criado com todas as 16
detentoras do grupo de controle, que são
aquelas que estão também divulgadas na
IN725, que a gente colocou aqui no chat.
Quando a gente fala de vínculo
dispositivo, a mesma coisa, um vínculo
dispositivo criado com todas as seis
entitoras do grupo de controle. Então
agora falando de engajamento paraa
liquidação de pagamentos, bem similar,
um pagamento com as 16 detentoras do
grupo de controle e vínculo dispositivo,
um pagamento liquidado utilizando o
vínculo dispositivo com jornal otimizada
com a 16 detentoras do grupo de
controle. Então agora falando sobre as
validações que vão fazer de jornada com
as iniciadoras, a gente vai fazer para
cada um dos produtos ofertados, seja
transferência inteligente, seja vínculo
dispositivo, dois cenários de validação.
Paraa transferência inteligente vai
fazer uma validação de um cenário que a
gente cria e cancela um consentimento de
pagamento e um segundo teste que a gente
cria e cancela um consentimento de dados
para garantir o consentimento primário
ele continuativo, que é o consentimento
de pagamentos. No caso, para vínculo
dispositivo, a gente fazer a criação e
edição de cancelamento de vínculo. Essa
edição vai acontecer do lado da
detentora, mas garantir que ele vai ser
refletido na área de gestão também da
iniciadora. E um segundo teste que para
vínculo do dispositivo que a gente vai
fazer a criação e um cancelamento de
consentimento de dados novamente para
garantir aquele comportamento de
consentimento primário e secundário para
garantir que o vínculo dispositivo
depois da revogação de consentimento de
dados ele continua ativo. Então eh em
resumo são esses critérios que a gente
vai cobrar das ITPs ao longo dos dois
próximos meses nesse período de piloto.
Agora falando sobre qual vai ser o
cronograma dessas validações que vamos
fazer. Quando a gente olha, eh, já está
desatalizado aqui. A gente o nosso
workshop estava por isso pelo dia 10,
mas estamos fazendo agora no dia 17. Mas
o próximo ponto relevante aqui é as
novos entrantes de JSR. Então, a gente
já tinha divulgado também que as
instituições que eram novas em trân JSR,
eles estavam dispensados os marcos
intermediários do motor de teste
relacionados a JSO, a JO com JSR. Mas o
prazo limite seria até o início do
piloto. Então a data limite para atingir
esse critério atingiu o sucesso em 100%
dos testes do motor é até o dia 20 do
abril de abril. Então, no dia 22 de
abril, que é a próxima quarta-feira, aí
sim vai se iniciar o piloto. Então,
quais as datas que as instituições têm
que ficar atentas? Então, para FVP, a
gente também vai seguir o padrão dos
outros pilotos. As instituições em que o
fornecedor ele tem conta aberta vai ser
executado pelo próprio fornecedor e as
instituições em que o fornecedor não tem
conta aberta, responsabilidade de
execução é das próprias instituições.
Então a gente também vai ter o nosso
painel de acompanhamento do do piloto
para saber quem tem as contas abertas
pelo fornecedor, não acompanhando
sucesso nos testes da FVP. E as datas
para cumprimento desses critérios estão
aqui. Então o teste interoperabilidade,
que é um único teste para transferência
inteligente e um único teste para para
JSR. A data limite para obtenção de
sucesso é dia 30 de abril. Então, as
instituições em que o nosso fornecedor
tem conta aberta vão fazer execuções,
notificação em caso de falha até essa
data e a as instituições em que o
fornecedor não tem conta aberta tem que
garantir o sucesso nesse teste, nesses
testes de interoperabilidade até o dia
30 de abril. Igualmente, o mesmo se
aplica pros outros paraas outras datas.
Então, garantia de jornada, teste de
garantia de erro.
Então, todas essas informações que a
gente tá falando aqui agora, acho que
vale comentar que a gente vai divulgar
hoje via informe a todas as informações
relacionadas ao piloto de jornada
otimizada. Fizemos a nossa página de
diretrizes gerais do piloto de jornada
otimizada. Estamos compartilhando via
informe, tudo que a gente tá comentando
aqui também para ter essas informações
mais explícitas para vocês. Então, eh,
quando a gente fala agora das validações
de jornada, essas são validações
exclusivas feitas pelo fornecedor.
Então, pode esperar que vão fazer essas
validações no primeiro aumento pelas
ITPs,
validações feitas pelo fornecedor, no
caso, nessas datas. e as outros testes
com as detentoras, a gente vai ter até o
dia 15 de maio. Uma data importante para
para as validações das jornadas. Então,
se minha instituição ela teve uma falha
fal em alguma validação de jornada,
recebi um ticket, o prazo limite para
pedir execução desses testes de jornada
é o até o dia 5 de junho. Então o
fornecedor tem o SLA também para cumprir
essa validação. Então a gente pede que
todos pedir retestes sejam feitos até o
dia 5 de junho. Depois disso, a gente
não consegue garantir que o resultado
desse reteste ele vai sair antes do Gol
Live, que seria 226. Então, vamos
aceitar pedido de reteste. Depois disso,
a gente só não garante que vamos ter
esse resultado antes do Go Live. Então,
eh, indo pros marcos intermediários,
quando a gente fala de engajamento,
igual eu mencionei, a gente vai ter
esses marcos intermediários de, eh,
tanto para criação de consentimentos
quanto para o número de pagamentos
liquidados. Então, um marco de 30% no
dia 8 de maio, marco de 50% no dia 22 e
um marco de 80% nesse
no dia 5 de junho. A ideia aqui é
exatamente garantir que a gente consiga
ter essa antecedência dessas criações,
desses consentimentos e pagamentos em
datas intermediárias e não esperar até o
final do piloto para atingir esses
critérios. Então, em caso de uma
instituição, por exemplo, não conseguir
ter 30, não conseguir ter 30
consentimentos de transferências
inteligentes criadas como jornada
otimizada, a sua instituição vai ser
notificada via service desc por não
atingimento desse marco intermediário.
E acho que comentando novamente desse
novo conceito que a gente tá
introduzindo nesse piloto, que são os
pontos de controle, que nada mais são da
gente, a gente faz a consolidação de
todas as pendências anteriores, seja da
FBP ou X, critério de engajamento, a
gente faz abertura de um ticket
consolidador, como também a gente vai
fazer uma validação se não tem uma
instituição não tem tickets de qualidade
pela PCM em aberto ou também tickets
bilaterais. Então, sempre na próxima
semana, depois desses pontos de controle
que a gente faz o levantamento, depends
das instituições, são as semanas que a
gente vai fazer os rooms, são agendas
individuais que a gente faz com as
instituições com essas pendências.
Então, nessas agendas, a gente pede, a
gente entende as instituições que que
elas estão com dificuldade, pede um
plano de de adequação para entender eh
como que ela como que vocês vão se
corrigir para corrigir os critérios
pendentes. E a ideia é através desses
rooms ajudar vocês, entendermos o que
que está tendo de mais dificuldade pra
gente conseguir chegar no Gol Live no
dia 22/06 com mínimo de pendências
possíveis e com as jornadas e
funcionalidades mais fluidas.
Então, a gente já vai abrir paraas
dúvidas já n mais alguns pontos
importantes. Eh, então, de novo, ponto
de atenção aqui a gente comentou, mas
vale dar um destaque maior. A gente
precisa de fato que as instituições
envie estejam bem integradas com a PCM,
principalmente quando a gente fala do
envio de additional infus. Então, a
gente precisa que seja enviado esses
additional infus, senão a gente não vai
conseguir contabilizar esses critérios
de engajamento como como por exemplo
journeys link. Journal LinkedI pra gente
conseguir identificar que um
consentimento ele foi criado via jornada
otimizada. um person type pra gente
conseguir saber se foi um consentimento
criado com um usuário de pessoa natural
ou pessoa jurídica, payment reference
pra gente conseguir saber qual tipo de
pagamento criado, enfim, as additional
infos são super relevantes pra gente
conseguir identificar a a as chamadas
reportadas pelas instituições. Eh, o
segundo ponto de atenção é que quando a
gente fala tanto de FVP quanto dos
produtos disponibilizados pelas ITPs, a
gente tá falando aqui de funcionamento
real em produção. Então são pagamentos
reais, são valores reais vinculadas suas
contas reais em produção. Então é sempre
recomendado o uso de valores baixos para
fazer esses testes em ambiente
produtivo.
Quando a gente fala aqui também com
alguns pontos de atenção adicionais que
também foram divulgados na IN725, a
gente consegue destacar destacar que as
ITPs que não atuam como transmissora de
dados com vão conseguir participar desse
período de teste em produção do pilot de
jornada otimizada, mas abertura paraa
base de de usuários, base de clientes,
ela está condicionada a sua
regularização como transmissora de dados
também. Então as informações foram
divulgadas ontem na IN725, então a gente
recomenda fortemente essa leitura para
para melhor entendimento. Então o
segundo ponto de atenção também foi
divulgado na IN725 é com relação ao SLA
dos tickets da FP que eles estão com SLA
de dois dias úteis. Então essas
informações estão todas divulgadas
também já na IN de ONA.
Então, já para finalizar, antes de
passar as dúvidas para vocês, como por
padrão a gente tem uma vamos fazer
acompanhamento bem de perto com todas
instituições participantes da jornada
otimizada, então a gente já tem uma
página centralizada com as informações
do pilô jornada otimizada, a gente
colocou o link aqui nesse chat, a gente
também vai divulgar as informações paraa
página dessa da página de diretrizes
gerais do piloto. Hoje via informe.
Também estamos divulgando as agendas
semanais de acompanhamento que vão
acontecer todas as sexta-feiras. a
partir da próxima semana, dia 24, e as
agendas vão correr das 2 às 3 horas até
um mês depois do final do piloto. Então
vamos continuar acompanhando asas
instituições até que toda mesas que
tenham pendências depois do go live a
gente continue acompanhando e dando
suporte para elas. E por último aqui
também temos como padrão o nosso grupo
de WhatsApp. Então, todos que se
interessarem para interações pontuais,
interações bilaterais com as
instituições ou até interações nossas
com a associação, a gente colocou o link
pro grupo WhatsApp aqui no chat também,
mas para facilitar tem um QR code aqui
para vocês já entrarem direto nesse
grupo. Então, falamos muita coisa aqui,
muita informação. Acho que agora sim vi
que teve muitas dúvidas aqui aqui no
chat. O pessoal tá respondendo tudo que
eu a queria liberar o espaço para tirar
dúvidas que ainda estão pendentes de
vocês se vocês tiverem.
>> Francisco, pois não.
>> Oi, Igo, boa tarde. Não ficou claro para
mim me ajuda aqui a a entender as
instituições que não estão listadas ali
no grupo controle, as detentoras, como
como que fica? Elas estão dentro do
escopo do piloto? não estão. Mesmo lendo
a norma, isso não ficou bem claro para
mim. Eu queria entender porque a minha
instituição ela não consta nessa lista.
>> Certo? Perfeito. Tá. Então aqui
isso aqui é o backup, que são as
instituições ali que estão listadas no
no anexo 2 ali da IN725.
Então, a única diferença dessas
instituições é que eles vão ter aqueles
acompanhamentos de engajamento direto
com as ITPs. Então, as ITPs precisam
ter, por exemplo, um pagamento liquidado
com essas com essas detentoras
transmissoras de dados. As instituições
que não estão aqui, elas têm que cumprir
os outros requisitos normalmente. Então,
tem que também ter sucesso nos testes da
EVP, tem que também ter o pareamento,
tem que ter os critérios de engajamento
cumpridos. A única diferença é que essas
instituições aqui a gente vai fazer as
validações de jornada com essas
instituições. A gente não vai testar
todas as jornadas de todas as
instituições com o nosso fornecedor. E
também as ITPs, elas precisam ter esses
critérios de engajamento com essas
detentoras do grupo de controle. Ah, as
outras as outras detentoras precisam
cumprir normalmente todos os outros
critérios. A única diferença é que as
ITPs têm que ter esse engajamento com
essas instituições ao grupo de controle.
Entendi. É o controle para as ITPs.
Então, tranquilo.
>> Perfeito. Tanto para as ITPs quanto pra
gente aqui para fazer as validações
justiça. O resumo é esse,
Ana Cristina. Pois não.
>> Olá, boa tarde. Eh, a minha dúvida é
sobre esse item de engajamento. No caso
de um conglomerado que ele tem
instituições de bas, né? Esse critério
tem que ser cumprido por cada marca. Ou
seja, se eu tiver 100 marcas aqui no meu
BAS, a 100 tem que bater esse essa
volumetria de pagamentos ou vai ser uma
marca específica do conglomerado para
representar o conglomerado inteiro,
>> tá? Eh, não, aqui esse volume a gente
valida a nível de organização, até
porque os reportes que são feitos para
PCM são a nível de organização, então a
gente contabiliza organizações de uma
forma geral. Obrigada.
>> Por nada,
Michele.
>> Michele, você está mutada?
>> Oi.
>> Agora sim.
>> Tô me ouvindo? Ah, tá.
Eh, sobre a restrição de usuários, eh, a
gente já tem essa planilha ali que a
gente vai preencher?
>> Eh, já foi liberado isso?
>> Sim, temos, sim. Exatamente a mesma
planilha que foi utilizada ali para pro
piloto JSR. Então, na página que a gente
compartilhou aqui no chat e também vamos
divulgar VMA, lá tem as instruções de
como que faz para preencher essas
informações. Então, eh, vai te levar ao
mesmo formulário, mas
>> tá, então vai ser divulgado ainda, ainda
não não foi enviado.
>> Exato. Vai sair hoje vir, mas a gente já
colocou o link aqui no chat para
facilitar,
>> tá? Só mais uma dúvida ali. Pra gente
incluir o metadado lá no diretório, a
gente já tem que estar em eh publicado
em prod ou pode fazer isso antes? Como
que
vai ser essa esse calendário ali, esse
processo?
>> Certo. Certo. É, esse metad incluído até
o início do piloto, que vai ser dia 2204
em produção. Então, se a sua instituição
ainda não tem a V3.3.1,
ela já foi notificada, já tem que estar
nessa versão vigente. E se aí está nessa
versão vigente, vocês já podem ir lá no
próprio diretório em produção e
atualizar esse metadado para homologação
joisem fazer um teste no diretório em
sandbox também, essa esse metadado
também tá habilitado lá, mas a gente
precisa que esse metadado esteja nessa
API, nessa versão, no diretório até até
o início do piloto,
>> então até o dia 22, né?
>> Exato. É super simples, é só ir no
diretório adicionar o metad lá para para
essa PI. É, é semelhante ali ao da JSR,
né, que
>> tá, tá bom. OK. Obrigada.
>> Por nada,
>> pois não, Gabriel.
>> Boa tarde, Igo. Tudo bem?
Tudo certo?
>> Deixa eu te perguntar duas coisas, meu
querido. A primeira coisa é sobre eu tô
no grupo ali e controle das 16
instituições. Então, assim como o JSR, é
o FVP vai ser feito pelo parceiro,
certo?
Só
>> isso. Exato. Aqui é todas as
instituições que estão no grupo de
controle vão ser feitos ali o teste DP
pela pelo fornecedor.
>> Acho que vale ponto de atenção que tem
instituições que estão fora do grupo de
controle e também vão ser feito pelo
fornecedor. Então não é uma relação de
só quem está lá que vai ser executado
pelo fornecedor, mas todas que estão lá
vão ser executad pelo fornecedor. Sim.
>> Tá bom. E uma outra dúvida é em relação
ao ao
teste de UX. ele, o prazo final dele é
15 de maio ou é o início dele 15 de
maio.
>> Eh, acho que a gente comentou aqui, mas
vale destacar também, eh, a partir do
início do piloto, todas as jornadas já
tem que estar disponíveis em funcionais,
em um funcionamento pleno. Então, quando
a gente fala daqui de ter a jornada
disponível aqui, é, a gente espera que
já esteja 100% disponível e funcionar a
partir do primeiro dia do piloto. Quando
a gente fala dessa data limite de 5 de
junho, eh, em caso de falhas que a gente
pegar nessas validações de jornada, a
data limite para pedir um novo reteste,
pra gente conseguir dar um retorno antes
do Goho.
Então, vamos abrir os tickets nessas
datas aqui. E a data limite para pedir
reteste paraa jornada de justiça é dia 5
de junho. Mas de novo só reforçando, a
gente espera todas as jornadas têm que
estar disponíveis e funcionais em
produção a partir do início do piloto.
>> Não, eu entendia Gonçal. É, é, era mais
em relação ao 15 de maio mesmo, tá? Se o
15 de maio é o início dos testes ou o
final dos testes, só para eu saber
quando que final dos testes, tá bom?
Exato. Perfeito.
>> Tá, então, a partir do dia 8 de maio,
teoricamente, começa e os testes das
detentoras porque acabam das ITPs,
correto?
>> É, eles podem começar antes aqui,
depende da volumetria, da
>> da vazão dos testes, a gente pode
começar começar. Esse dia 15 é a data
limite final. Boa,
Rui. Pois não.
>> Opa, boa tarde. Ô, Igor, eu fiquei com
uma dúvida. Eh, são só os novos
entrantes que tm que colocar flag?
>> Não, são todos. Todas as detentoras de
de conta e transmissoras de dados.
>> Ah, tá. Tá certo. Obrigado.
>> Por nada. Aqui acho que a única
diferença que a gente comentou ali dos
novos entrando JSR é que eles foram
dispensados marcos intermediários do
motor de J com JSR e esse prazo ele
tinha sido divulgado como sendo até o
início do piloto, ou seja, pode estender
dia 20 de abril, que é a próxima
segunda-feira, que piloto já começa no
dia 22,
>> certo? Essa informação do metadado, ela
tava em algum informa, tu lembra?
>> Ela vai sair hoje também.
>> Ah, vai sair hoje, tá? Obrigado. Por
nada.
Eh, vai estar no boa tarde. Não sei se
vai estar no informe, mas eu não achei
aonde aonde pôs esse esse metadado ou
ele não está na disponível na lista. Se
é na organização, acho que ele ainda não
tá disponível, né?
O metadado ele é a nível da API. Então,
se você for, opa, um minutinho aqui,
per aqui ele tá a nível da API, você
consegue na sua API de con 3.3.1
>> incluir esse metadado de homologação J.
a partir desse metadado que tantas ITPs
vão conseguir saber se a instituição
ainda tá em período de testes em
produção ou pra gente identificar também
quem já cumpriu todos os critérios ao
final do piloto ou não.
Pessoal, acho que quanto, não sei se
alguém ainda vai ter mais algumas
dúvidas, mas acho que só reforçando aqui
esse ponto de atenção que a gente
comentou, eh, a gente reforço novamente
a leitura da IN725, que saiu ontem
relacionado pelo ação normativa 16/04.
Então, a eh esse aqui que a gente tá
comentando é um resumo das informações,
mas a gente recomenda a todos a leitura
da instrução instrução normativa. Também
saiu ontem N724 que relacionada aos
dados de aos dados e serviços. Também
foi incluída uma nova sessão relacionada
à jornada otimizada. E aqui também
reforçando novamente que eh a partir da
próxima sexta-feira, dia 24, das 2 às 3
horas, vamos ter nossa agenda semanal de
acompanhamento com as instituições. A
ideia é a gente acompanhando os testes e
tirando dúvida das instituições,
reforçando as datas, responsabilidades
para ter essa proximidade entre a
associação e e as instituições.
Então esse novamente esse workshop ele
tá sendo gravado. Vamos pegar a
gravação, vamos colocar no YouTube do
Open Finance Brasil e também tem as
dúvidas aqui no chat. A gente também vai
consolidar todas elas e também pegar as
respostas e vamos divulgar também junto
com essa gravação do workshop.
Hã,
se
opa, já tá quase encerrando. Diga aí,
Maurício.
>> Eh, eu só uma dúvida, eh,
como uma ITP que a gente ainda tá
começando a ver as coisas do Jo, eh,
provavelmente a gente não vai
poder entrar nesse começo. Daí, eh, o
que que a gente precisaria? Eu não não
ficou muito claro o que que a gente
deveria fazer caso a gente só fosse
terminar a nossa jornada depois do dia
30.
>> Uhum.
>> Eh, a gente
eh teria que dar algum flag no no
service desk antes de começar a fazer
nossos testes
ou o quê?
Boa. Perfeito. Eh, aqui a data dia
30/04, a data limite para as ITPs
demonstrar interesse e participação no
jornal otimizada para serem incluídas
nesses testes de período de piloto. Ou
seja, se a sua instituição compartilhar
esse interesse de uma jornada disponível
e funcional até o dia 30/04, a gente
inclui as ETPs aqui no período de
piloto. Se é uma ETP, ainda tem
interesse de participar da jornada
otimizada, mas aí está disponível só
depois do dia 30. O fluxo é exatamente o
mesmo. Abre um ticket nessa categoria do
service, compartilha qual que é o
produto que você quer ofertar de jornada
otimizada. A única diferença é que a ITP
vai entrar no fluxo de onboarding. Que o
que isso quer dizer? Que a
disponibilização dessa funcionalidade
para para o pú público aberto vai
acontecer só depois do Go Live. Então as
ITPs que participarem do piloto,
incumprindo todos os critérios, vão
conseguir disponibilizar a
funcionalidade em aberto no Gol Live.
Mas a instituição demonstrar interesse
depois dessa data vai entrar no fluxo de
onboarding, a gente vai fazer as mesmas
validações. A diferença é que a a
disponibilização da jornada vai
acontecer só depois do go live. essa
diferença. Então, poderiam, podem sim,
na verdade, demonstrar interesse. A
única diferença vai ser na no período de
validação e disponibilização da jornada
do público aberto.
>> Ah, entendi. Então, então se eu se até o
dia 30 a gente conseguir terminar, eh,
ainda durante o piloto, a gente poderia
fechar tudo e poder já começar a
disponibilizar para nossos clientes.
>> É exato. uma data limite para ter a
funcionalidade disponibilizada e
demonstrado, compartilhado com a gente é
dia 30/04,
>> mas exatamente.
>> Obrigado.
>> Por nada,
Paulo. Pois não.
>> Ah, boa tarde, pessoal. Eh, Iago, a
minha dúvida, eh, são, na verdade, duas,
eh, é o seguinte, a gente passou tão
recente pelo piloto de JSR e durante o
piloto de JSR eu vi uma lista eh sobre
as rotas disponibilizadas para ITPs e
também houve exemplificações do uso do
fluxo para a jornada de JSR. A gente vai
ter a mesma coisa aqui para a jornada
otimizada, né?
>> Certo. Eh, responder a primeira
pergunta, podemos fazer sim. Tá, tá,
Paulo. A gente ainda tá pegando a
formalização das ITPs via Service Desk,
mas a gente pode fazer fazer da mesma
forma assim, se você entende que que
isso vai ajudar.
>> Ah, eu acho que a última imagino que até
>> perfeito.
>> As outras casas aí vão gostar porque foi
o que houve no piloto anterior.
Obrigado.
>> Perfeito,
>> pessoal. Então, acho que novamente eh
vamos divulgar as informações hoje,
todas as informações que a gente passou
aqui no workshop via informe. Vamos
compartilhar a página das diretrizes
gerais do piloto de jornada otimizada,
assim como também as instruções para
demonstração de interesse das ITPs
participantes, as instruções para a
utilização do metadado de homologação de
JO na API. E só reforçando também que na
partir da sexta-feira que vem já temos a
o início da nossa agenda semanal de
acompanhamento com as instituições
relacionadas ao pilô de jornada
otimizada. Acho que de resto, né,
agradecer a participação aqui de todos e
continua, continuamos à disposição.
É isso. Então, uma boa tarde, boa
sexta-feira, um bom fim de semana.
>> Obrigado pessoal. Obrigado, Iago. Boa
tarde.
>> Obrigado, Iago. Boa tarde, pessoal.
Obrigado, gente.
>> Boa tarde, pessoal.