Portabilidade de Crédito - Workshop Open Finance Brasil (26/05/2025)

Pessoal, boa tarde a todos. Quero em
nome da Associação Open Finance eh
agradecer a presença de todos vocês.
Acho que a gente já pode iniciar a nossa
agenda.
Eh, pessoal, acho que hoje é uma data
bastante importante. A gente lança aqui,
né, através desse workshop, eh, o a o
serviço de portabilidade de crédito.
Então, o objetivo da nossa agenda hoje é
apresentar esse serviço para todos os
participantes, apresentar também o
detalhamento técnico da especificação,
falar um pouco de Uex e descrever um
pouco todo esse processo de
certificação, né, para que a gente
consiga garantir que todo mundo faça a
implementação de forma mais adequada
para termos um bom go live lá em
outubro.
Meu nome é Eduardo, trabalho aqui na
BTO, vou conduzir a nossa agenda hoje.
Antes de iniciar, queria me passar
alguns recados gerais. Então, a nossa
agenda, ela vai ser
gravada. A gente deve disponibilizar
tanto o vídeo desse workshop quanto o
material que a gente vai apresentar e
também as dúvidas de vocês eh ao final,
né, dessa agenda. Então, a gente vai
compartilhar com todos.
Eh, então falando um pouco mais de como
vai funcionar, eu vou, como já comentei,
eu vou conduzir, eu sou o Eduardo, a
gente tá aqui com o nosso time de
especialistas, então a Mayara, que é a
nossa líder de portabilidade de crédito
da associação, Gilvan, que é nosso API
expert, Camila, que é nossa líder de X e
também o Bruno que é o nosso PO dos
serviços de
portabilidade. a gente separou essa
agenda em alguns momentos, então a gente
começa com a apresentação desse serviço,
né? Então como que vai funcionar a
portabilidade na fila do Open Pharmacy.
Em seguida, a gente entra um pouco mais
no detalhe da especificação da PI de
portabilidade. Eh, a gente vai passar
também pela jornada de experiência do do
usuário, né? Então, pelos requisitos que
vocês vão precisar implementar em termos
de NUEX, vamos falar também um pouco
sobre os testes funcionais desse período
de certificação e no final a gente
conversa um pouquinho mais sobre o que
vai ser esperado de vocês instituições
durante esse período de certificação.
Então, sem mais delongas, Ma, palavra é
sua.
Bom, Edu, obrigada. Eh, primeiro aqui,
em nome do grupo de produtos, eu quero
agradecer a participação de todos aqui
nesse workshop e aproveitar também para
agradecer ao diretor de portabilidade de
crédito por todas as contribuições que a
gente recebe em cada agenda, eh, ao
Banco Central por todas as orientações e
diretrizes pra gente conseguir
estruturar um bom serviço de
portabilidade de crédito aqui no âmbito
do OpenF. E é o time do secretariado,
que sempre nos apoia na na organização
das agendas. Eh, mas seguindo aqui, vou
vou iniciar falando um pouco sobre a
linha do tempo de portabilidade de
crédito aqui no trilho do Open Finance,
destacando aí a etapa que estamos no
momento, né? Então, olhando pra linha do
tempo, em um tom mais forte, a gente tem
aqui o produto crédito pessoal clean,
que é o CPC, e um tom mais claro temos
aí o produto consignado federal, tá? Eh,
no mês de agosto de 2024 ocorreu a
apresentação do escopo de da
portabilidade de crédito no antigo
conselho deliberativo e também teve a
criação do grupo de trabalho, né, do GT
de portabilidade de crédito.
Então, de agosto 24 a abril 25, foi o
período ali dedicado pra gente realizar
tanto a validação como o detalhamento do
escopo que foi fornecido pelo Banco
Central. Teve a construção do documento
de requisitos do produto, que é o PRD,
né? E com base no PRD foi construído o
guia de UEX e também a especificação
técnica ainda nesse primeiro momento com
ênfase no produto
CPC. Eh, a primeira entrega tanto do
guia quanto da especificação ocorreu no
dia
4/04. E aí seguindo pra fase de
certificação e implementação, que é a
fase que a gente se encontra no momento,
né, que foi iniciada ali a partir do dia
7/04.
eh, e vai até o dia 3/10. Então, durante
esse período, serão disponibilizadas
quatro versões intermediárias da
especificação da IPI de portabilidade de
crédito. E já foram publicadas aí tanto
a versão da beta 1, como também a versão
da beta 2. E em 18/06 será
disponibilizada a versão beta 3 e 21/07,
de acordo com o cronograma, né, de
implementação de portabilidade, será
publicada a versão RC1, tá?
A versão estável da da API, ela tá
prevista para ser publicada no dia
26/08. Eh, e cada versão intermediária
publicada, ela vem aí acompanhada da
disponibilização do motor de
certificação, mas o Bruno, logo mais ele
vai trazer aí um detalhamento sobre o
motor e sobre o os marcos de
certificação, tá bom?
Então, seguindo, a gente tem a adequação
das ferramentas da estrutura, que nada
mais é que um adequação pra gente
conseguir fazer o monitoramento do
serviço de portabilidade de crédito no
âmbito do Openfes, tá? Eh, logo após tem
o o piloto e o Golive. Aqui um ponto de
de atenção é que as datas compartilhadas
aqui são datas que
foram eh sinalizadas no escopo do Banco
Central compartilhado em agosto de 24.
Então, qualquer mudança em relação a
essas datas, a gente atualiza o material
e compartilha aqui com toda a estrutura,
tá bom?
Eh, aqui na cor azul clara, como eu
havia falado anteriormente, é referente
o produto consignato federal. E o que eu
posso compartilhar sobre esse produto no
momento é que já foi iniciada ali a as
discussões referente a ele, tá? Então, é
previsto da gente falar de abril até
outubro desse ano sobre esse produto e
logo ali no início de outubro
disponibilizando a primeira versão
referente à especificação referente ao
produto consignado federal. E aí do pode
seguindo, por favor.
Eh, a gente trouxe aqui um breve resumo,
né, do que é portabilidade de crédito,
por surgiu, qual problema a
portabilidade de crédito no âmbito do
OpenF ele visa resolver. Então,
começando aqui, o que é a portabilidade?
A portabilidade de crédito permite a
transferência de operações de crédito
entre instituições para obtenção de
melhores condições. Atualmente, a
solicitação pode ser feito via
registradora e sua implementação no
âmbito do PFINE se busca agilizar e
simplificar esse processo. Por que que
surgiu, né? Então, o processo de
solicitação de portabilidade de crédito,
ele pode ser demorado e complexo, que
desestimula a utilização do serviço por
parte dos clientes. Além disso, o
desconhecimento do público em relação à
portabilidade de crédito limita o
potencial de utilização desse serviço.
Então, o problema que a gente busca
solucionar implementando o serviço de
portabilidade de crédito aqui no âmbito
do OpenF é justamente viabilizar um
serviço de portabilidade que seja ágil,
que seja fácil, tornando o processo mais
competitivo, transparente e trazendo
alguns benefícios para os clientes.
Então, quais seriam esses benefícios,
né, que é o aumento da competitividade
entre as instituições, redução no tempo
de solicitação e simplificação do
processo. Então, quando eu passar com
vocês o fluxogramo, diagrama de
sequência, esses benefícios vão ficar
mais claros de de de evidenciar de fato,
tá? Para para tangibilizar.
Eh, seguindo, a gente trouxe também um
detalhamento de quem deve oferecer a
portabilidade de crédito. Então, esse
detalhamento, ele foi extraído na
íntegra do escopo fornecido pelo
regulador. E aqui faz menção, né, que
participação somente das instituições
financeiras no papel de instituição
credor original e ou instituição
proponente, tá? Obrigatoriedade
vinculada à participação no
compartilhamento de dados. Então aqui
instituições eh do S1 S2, instituições
com mais de 5 milhões de clientes e
obrigatoriedade apenas no papel de
instituição credora original. Como
instituição proponente é sempre
voluntário. Instituições do S3 a S5 são
voluntárias com reciprocidade. Ou seja,
se atuar como proponente, deve atuar
como credora original também.
Eh, instituição financeira que
participar do compartilhamento de dados
no OpenFance deve participar da
portabilidade como instituição credora
original e vice-versa.
E conforme atualizações recentes na
regulamentação do Openfice, a
participação voluntária no
compartilhamento de dados e
consequentemente na portabilidade
implica a participação de todas as
instituições do conglomerado. Então
essas informações são informações, como
eu havia mencionado, foram extraídas na
íntegra do escopo do Banco Central e
também estão detalhadas no documento de
requisitos do produto no PRD. publicado
na área do do desenvolvedor, tá bom? Eh,
seguindo, temos o macrofluxo, que
evidencia aqui como vai funcionar o
serviço de portabilidade de crédito aqui
no âmbito do Openfes. Então, de forma
bem resumida, eh, o fluxo deixa de ter o
pilar da registradora, né, intermediando
o processo entre as instituições e as
instituições elas passam a se comunicar
diretamente. Eh, um outro ponto
importante é a redução do prazo nas
etapas do fluxo. Então, de acordo com a
com a resolução 5057, que é a resolução
vigente referente ao serviço de
portabilidade de crédito, o processo
atual ele leva por volta ali de 9 dias
úteis para ser concluído. E o processo
aqui no âmbito do Open Finance, ele deve
ser concluído em até 5 dias úteis.
Eh, a redução dessa desse tempo, né, ele
pode ser observado ali na etapa de
contraproposta, que passa de 5 dias para
3 dias, e na etapa também de confirmação
do recebimento do recurso referente à
liquidação do contrato original e da
efetivação da portabilidade de crédito
propriamente dita que passa de 4 dias
para 2 dias. Então, olhando aqui pro
fluxograma, eh, aqui o número um é o é o
cliente, né, celebrando o contrato de
crédito ali, o contrato de empréstimo de
ICPC com a instituição Credora Original.
Depois esse cliente ele solicita a
portabilidade de crédito à instituição
proponente. A instituição
proponente ela envia a solicitação com
as condições da proposta via API, né,
paraa credora original. A credora
original tem o time ali de até três dias
úteis para fazer a oferta da
contraproposta.
E aí em até três dias úteis também
informa a instituição proponente se a
operação foi retida ou não, né? Caso da
operação não se retido, não ser retida,
a instituição proponente precisa
liquidar a operação no mesmo dia em que
em que recebeu os dados ali da IF
credora. E aí, como o step 7 aqui, em
até dois dias úteis, confirma o
recebimento da TED, envia documentação
atestando a efetivação da portabilidade.
Então aqui toda a comunicação, como eu
falei, vai ser via API. Eh, o processo
de liquidação, ele vai ocorrer através
de uma STR exclusiva, uma STR específica
pro âmbito do Openf. STR vai ser chamada
de 0052, que a gente vai tá detalhando
ela um pouco mais à frente. Eh, e aí,
como eu havia mencionado também, antes
instituição tinha um prazo para
confirmar o recebimento e depois um
outro prazo para atestar, para efetivar
a portabilidade de crédito. E isso tudo
vai precisar ocorrer no prazo de dois
dias úteis.
Eh, Mai, acho que temos um levantado
aqui. Eu queria só comentar, pessoal,
que a ideia é que o final dessa
apresentação a gente vai ter um momento
específico para dúvidas. Vocês podem
também escrevendo aqui no chat, a nossa
equipe vai tentando responder, tá? Mas
idealmente a gente vai guardar ali as
dúvidas pro final da apresentação.
Eh, boa, Edu. Obrigada.
Eh, então, seguindo, a gente tem aqui o
diagrama de sequência para detalhar como
será o funcionamento aqui da
portabilidade. Então, temos quatro
pilares, o pilar do cliente, o pilar da
instituição proponente, pilar da
instituição criadora original e aqui o
pilar da estrutura do Openfice. Então,
iniciando, o cliente ele verifica se tem
a disponibilidade de portabilidade ali
junto da instituição proponente. Então
aqui esse início do fluxo pode ser ali o
cliente, tendo interesse em portar o
crédito buscando a instituição
proponente ou a instituição proponente,
caso já tenha ali os dados desse cliente
na sua base de informações, acionar esse
cliente ofertando ali a portabilidade de
crédito, tá? Eh, mas aqui nesse fluxo a
gente trouxe uma ilustração do cliente
indo até a instituição proponente para
verificar ali a disponibilidade para
realizar o pedido da portabilidade de
crédito. Então, fomos separandoos por
bloco aqui esse diagrama de sequência. O
primeiro bloco, que é um pré-requisito
para fazer a solicitação da
portabilidade de crédito no âmbito do
Openfes é a questão da do consentimento,
tá? Então, um pedido de portabilidade,
ele só é realizado se esse cliente
estiver com um consentimento ativo.
Então, caso esse cliente esteja ali na
primeira relação com ele, a a a primeira
eh interação com a instituição
proponente ainda não forneceu, né, a o
consentimento, é necessário que ele faça
isso antes mesmo de iniciar o pedido de
portabilidade de crédito. Então aqui a
instituição proponente, considerando que
esse cliente já tem um consentimento
ativo, ela consulta as permissimento
fornecido pelo cliente com a instituição
credora original. A instituição credora,
ela retorna com os dados a respeito
desse consentimento pelo cliente e aí a
gente entra na etapa de consulta de
contratos. Eh, no serviço de
portabilidade de crédito, além da IPI de
portabilidade, também vai ser necessário
utilizar a IPI de empréstimo, tá? Da
fase dois. Então aqui tem a etapa do
contrato de empréstimo, onde a
instituição proponente ela solicita o
número de contratos vinculados aquele
cliente à instituição credor original. A
instituição credora original, ela
retorna com os contratos realizados pelo
cliente. A proponente, ela solicita o
detalhamento desses contratos através de
três ends da API de empréstimo. E a
credora, ela retorna aqui com o
detalhamento dos contratos solicitados.
Eh, nesse nesse meio tempo, a
instituição proponente, ela faz uma
análise de risco, né, daquele CPF,
entende ali eh o potencial daquele CPF,
passa aquele CPF pelo política de
crédito de cada instituição. E aí a
gente inicia a etapa de de gestão de
simultaneade. Aí, sobe um um
pouquinho.
Boa. O que que quer dizer a etapa de
gestão de
simultaneidade? Eh, um ponto importante
para compartilhar com vocês é que,
apesar de termos o fluxo de serviço de
portabilidade de crédito no âmbito do
Openfice, o fluxo via registradora, ele
ainda vai continuar ativo, tá? Então, os
fluxos vão andar de forma paralela.
Então, gestão de simultaneidade é a
etapa em que a instituição credora
original, eh, ela vai precisar informar
se já existe um pedido de portabilidade
feito previamente para um contrato em
questão, tá? Então, é justamente o que
tá descrito aqui nesse nesse bloco na
cor lilás, que a IF Credora, ela é
responsável por identificar se existe ou
não um pedido prévio de portabilidade de
crédito em andamento, porque a
instituição credora tem tanto a
visibilidade dos pedidos feitos via no
trilho via registradora, como também no
trilho via OpenF. Então, eh, seguindo
aqui, a instituição proponente confirma
se um contrato de portabilidade está
elegível paraa
solicitação e a instituição criadora,
ela retorna com os dados a respeito da
elegibilidade do contrato paraa
solicitação da portabilidade. Então, eh,
trazendo um exemplo aqui, caso um
cliente já tenha solicitado a
portabilidade de crédito via fluxo
atual, via registradora, ao tentar
solicitar a portabilidade para esse
mesmo contrato, a instituição credora
vai estar sinalizando para proponente
que já tem o pedido de portabilidade de
crédito em andamento, logo, né, não vai
poder ser feito um novo pedido para
aquele
contrato. Então,
seguindo, a instituição proponente, ela
retorna para o cliente com os contratos
elegíveis para ser portado. O cliente
ele seleciona qual contrato ele deseja
seguir ali com pedido de portabilidade
de crédito. A instituição proponente,
ela retorna com uma proposta para para
esse cliente seguir com o pedido de
portabilidade.
Aqui tem um ponto importante, né, que
tem algumas regras que a instituição
proponente vai precisar cumprir, que é a
regra do prazo remanescente, né, que o
novo contrato ele não pode ter um prazo
superior ao prazo remanescente do
contrato original.
O, a outra regra é a do saldo devedor,
que o saldo devedor do novo contrato não
pode ser superior que o saldo devedor do
contrato original e também a
periodicidade, né? Não pode haver uma
mudança de periodicidade ali nessa nessa
proposta ofertada para portabilidade de
crédito. Então, se esse cliente no
contrato original ele realiza o
pagamento de forma mensal, aqui nessa
proposta ofertada pela instituição
proponente precisa continuar com esse
mesmo formato, tá bom?
E aí, superado isso, a gente entra na
etapa de assinatura do contrato, que é
quando a instituição proponente
disponibiliza o contrato paraa
assinatura, o cliente confirma e dá o
aceite da portabilidade de crédito. Essa
confirmação e aceite, ela ocorre através
de assinatura digital, né? Então, o
mecanismo de autenticação que vai
viabilizar essa assinatura digital é o
mecanismo já utilizado por cada
instituição. Então, se a sua instituição
utiliza um SMS em token, por exemplo,
para seguir com uma formalização, para
seguir com uma assinatura digital na
adesão de algum produto, vai ser esse
mesmo formato que deve ser utilizado
aqui para viabilizar a assinatura do
pedido de portabilidade de crédito.
É, seguindo, a gente entra aqui no bloco
de solicitação de portabilidade de
crédito em que começa a contar contar o
pararazo de 3 dias úteis para iniciar a
etapa ali da contraproposta, tá? Então,
a instituição proponente, ela notifica a
instituição credora que existe um pedido
de portabilidade de crédito em andamento
para um contrato XPTO e aí a instituição
credora retorna confirmando o
recebimento da portabilidade de crédito.
E aí a gente entra na etapa de análise e
envio da contraproposta.
E aí aqui na etapa de análise envio da
contraproposta, eh o ponto importante é
que no processo atual essa essa etapa
ela pode levar até 5 dias úteis. No
fluxo via Openfice, essa etapa ela deve
ser em até três dias úteis.
Então a aqui seguindo a instituição
credora, ela faz análise do pedido de
portabilidade de crédito e avalia se tem
interesse em tentar reter aquela
operação. Havendo interesse em reter a
operação, a instituição credora, ela vai
est notificando o cliente para fazer ali
o envio da contraproposta. esse envio da
contraproposta, essa notificação, né, ao
cliente, né, para fazer o envio, ela
pode ser feita de acordo com a
estratégia de cada instituição. Então, a
instituição pode enviar um e-mail, a
instituição pode enviar um push no
aplicativo, pode enviar um SMS, pode
seguir da forma que a instituição acha
melhor. Porém, o ponto chave aqui, o
ponto importante que é independente da
maneira que esse cliente ele é acionado
para ser notificado sobre ali uma
contraproposta sobre o interesse da
instituição credora em reter aquela
operação, eh, a instituição criedora
obrigatoriamente ela precisa registrar
essa conta proposta no seu canal
digital, tá bom? Por quê? Porque o
cliente ele obrigatoriamente ele precisa
dar o aceite a essa contraproposta caso
ele tenha interesse através do canal
digital da instituição credora. E aí tem
alguns pontos importantes, né, que esse
aceite da contraproposta, caso o cliente
tenha interesse, ele precisa ocorrer até
às 9 horas da manhã do terceiro dia útil
do pedido de portabilidade de crédito.
Por quê? Porque às 10 horas da manhã do
terceiro dia útil, a instituição credora
precisa informar a instituição
proponente se a operação foi retida ou
não. E caso a operação não tenha sido
retida, para que a instituição
proponente tenha tempo
hábil, tá? Eh, então é o que tá descrito
aqui nesse bloco em lilás, essa questão
dos horários. E um outro ponto
importante que é a ausência de resposta
do cliente em relação à contraproposta
caracteriza o não aceite da
contraproposta, ou seja, o fluxo de
portabilidade de crédito, ele vai ser
sequenciado.
É, e aí passando da etapa da
contraproposta, a gente entra na etapa
de informar a respeito da não retenção
do cliente,
que como eu havia falado, né, cliente
tem até às 9 horas para aceitar a
contraproposta, a credora tem até às 10
da manhã do terceiro dia para notificar
a
proponente sobre essa não retenção. E aí
a instituição eh credora informa a
proponente que pode prosseguir com a
portabilidade de crédito. E a partir
dessa informação, né, aqui também no nos
blocos na cor cinza tem o o estado da
máquina de estado que cada que o pedido
de portabilidade de crédito ele precisa
estar para viabilizar com que esse
processo
aconteça. E aí informando a respeito da
não retenção do cliente, a gente entra
na etapa de atualização do saldo devedor
e dados bancários, que a instituição
proponente, ela consulta novamente o
saldo devedor atualizado para seguir com
a liquidação da operação. A instituição
credora, ela retorna o saldo
atualizado, a instituição proponente
consulta os dados bancários e a creda,
ela retorna com os dados bancários para
viabilizar a liquidação. E aí a gente
entra aqui na etapa para informar a
respeito da liquidação
efetuada. Eh, no dia em que a
instituição proponente ela recebe ali os
dados, né, a informação que a operação
não foi retida, recebe o saldo devedor
atualizado, recebe os dados bancários,
ela precisa realizar ali a liquidação da
do contrato original através da STR0052.
E aí, após isso ser feito, ela informa a
instituição credora que a TED foi
realizada, tá bom? E aí, seguindo paraa
etapa de validar e quitar o contrato de
empréstimo, a instituição credora, ela
tem o prazo de dois dias úteis para
fazer análise a respeito do pagamento
recebido pela quitação do contrato e aí
seguir com a confirmação do recebimento
e fornecer aí o que a gente chamou aqui
como recibo deitação, mas não é bem um
recibo, é uma atualização na máquina de
estados do serviço de portabilidade de
crédito informando que que a
portabilidade de daquele cliente,
daquele contrato em questão foi
concluída com sucesso. E aí por último,
a gente tem aqui o o bloco de reporte, a
estrutura a respeito da portabilidade de
crédito e eh efetuada, que tá muito
conectada ali com a questão de
monitoramento, né, para viabilizar o
monitoramento do serviço eh aqui no
trilho do do
OpenFice. E aí, fechando o tópico de
como vai ser o funcionamento da
portabilidade de crédito, aqui no nome
do Topen Finance, a gente destacou
algumas informações importantes, né,
para facilitar aqui o entendimento do
grupo. E essas informações elas foram
separadas por jornada, né? Então, a
gente tem aqui a jornada de solicitação,
a jornada de efetivação, de liquidação e
a jornada de consulta e
cancelamento. No pilar aqui de
solicitação, as informações que a gente
trouxe importante é que é necessário ter
um consentimento ativo para realizar o
pedido de portabilidade. Então, caso
esse cliente já tenha fornecido ali a o
consentimento para a instituição, vai
ocorrer uma validação se esse
consentimento está válido, se ou se esse
consentimento está prestes a inspirar.
Caso esteja prestes a inspirar, vai ser
solicitado ao cliente que faça a
renovação, tá bom? porque como eu havia
informado, é uma premissa para fazer o
pedido de
portabilidade. Eh, o segundo ponto, só
será permitido um pedido de
portabilidade por contrato, que tá
conectado ali com a gestão de
simultaneidade, que é a credora
sinalizar se já ocorreu, se tem um
pedido de portabilidade em andamento
para aquele contrato em questão. O
terceiro ponto aqui é o pedido de
portabilidade. ele deve ser formalizado
digitalmente conforme o mecanismo
adotado por cada instituição. Então esse
ponto tá conectado ali com a minha fala
que vai ser utilizado mesmo mecanismo de
autenticação que a instituição já opera
hoje, né? CMS Token, Face ID, e-mail,
enfim.
Eh, o último ponto é que o novo contrato
deve ter o prazo e o saldo devedor igual
ou inferior ao informações do contrato
original e a periodicidade deve ser a
mesma, tá? Seguindo aqui pro pilar da
efetivação, a contraproposta, ela pode
ser ofertada por qualquer canal, mas o
aceite deve ocorrer exclusivamente no
canal digital da instituição credora.
Eh, olhando pro pro pilar da liquidação,
a gente tem a transferência de recurso
deverá ocorrer através da
STR0052, que é uma STR exclusiva para o
Open Fence, eh a devolução de recursos
pagos, né, caso seja identificada ali
alguma inconsistência por parte da
instituição credora em relação ao
pagamento realizado pela instituição
proponente. Esse estorno, essa
devolução, ela deve ocorrer através da
STR00, utilizando o motivo 85.
E aqui por último, como terceiro ponto
da da do pilar da liquidação, que a
máquina de estado, ela deve ser
atualizada para viabilizar a efetivação
do pedido de portabilidade. E por último
aqui em consulta e cancelamento, vai ser
disponibilizado pro cliente a área de
gestão, tanto no canal digital da
instituição criedora como no canal
digital da instituição proponente. E
essa área de gestão, ela vai viabilizar
que o cliente ele consulte o pedido de
portabilidade de crédito, como também
ele pode cancelar esse pedido de
portabilidade de crédito. Esse
cancelamento pode ocorrer até antes da
liquidação, antes da instituição
proponente realizar ali a transferência
paraa instituição credora em relação a
esse contrato, tá? Um um ponto
importante aqui que a gente colocou como
ponto de atenção é que foram previstas
notificações que devem ser
compartilhadas com o cliente durante a a
solicitação da portabilidade.
É, essa comunicação com com o cliente,
ela pode ocorrer por meio de texto
definido ali na própria jornada ou por
meio de push, SMS, enfim, essa
comunicação, ela vai se ser contemplada
no fluxo e deve ocorrer de acordo com a
estratégia de negócio adotada por cada
instituição, tá bom? Eh, então aqui sem
mais delongas eu passo a palavra pro
Gilvan, para ele trazer aí uma
explicação técnica sobre a máquina de
estado e o detalhamento também da
especificação da IPI de portabilidade.
Vai lá, Gil.
OK. Obrigado, M. Ah, boa tarde, pessoal.
Então, eh, falando um pouco sobre a
nossa máquina de estado para, eh, a
portabilidade de crédito aqui no âmbito
do OpenFance, nós imaginamos essa, eh, o
fluxo em que deve seguir o pedido de
portabilidade de crédito, né, aonde eh
logo após a assinatura de
contrato ah ali do usuário, é enviado
esse pedido de portabilidade pra
instituição credora, né, uma vez que a
instituição
creda, recebeu o pedido de
portabilidade, o status do pedido de
portabilidade fica como received, né? E
esse estado ele pode ser alterado para
pending, significa que ele está num
período de contraproposta, né, no D+1,
ou ele pode ter sido cancelado pelo
usuário ali nesse nesse meio tempo antes
de virar a chave para o pending, para o
período de contraproposta.
Então o pending significa que nós
estamos no período de contraproposta,
né? Aonde, como a Mai comentou, eh, a
instituição credora, ela tem três dias
úteis para tentar reter aquele cliente.
É um direito dela, tentar reter aquele
cliente, ela pode exercer ou não o seu
direito, né? E caso ela
eh decida ofertar uma contraproposta,
essa contraproposta, como a mãe
comentou, pode ser feito por qualquer
canal, mas ele deve ser aceito pelo
cliente no canal digital da instituição
credora. E caso aconteça essa situação,
o estado de pending, ele deve ser eh
transicionado para rejected, né? que
significa que a instituição eh conseguiu
reter aquele pedido de portabilidade.
Neste meio tempo, também o usuário pode
cancelar o pedido de portabilidade, né?
Uma coisa é o usuário aceitar uma
contraproposta e outra coisa é o usuário
cancelar o pedido de contraproposta,
cancelar o pedido de portabilidade, né?
Então, cancelar o pedido de
portabilidade significa que o usuário
ele tá desistindo daquele pedido e o
aceitar uma contraproposta, ele tá
firmando um novo contrato com aquele com
aquela outra com a instituição criedora
original, né? Eh, caso o usuário ele não
decida cancelar e nem decida por aceitar
aquela contraproposta, passados os três
dias, né, ou eh caso o usuário já tenha
confirmado que ele não quer continuar
com a instituição criadora original, ela
deve avisar a
instituição ah proponente que não reteve
o seu estado, o seu cliente apenas
mudando o estado na máquina de estado.
estado pro acceptment in progress, né?
Então, quando ah nós estivermos nesse
estado de ac stellment em progress,
significa que eh a estamos na etapa de
liquidação e que a instituição
proponente ela deve fazer a liquidação
naquele mesmo dia, tá? Ah, novamente,
ela pode rejeitar o pedido de
portabilidade de crédito, é a
instituição credora, a instituição
proponente, né? Ah, quando a atualização
do saldo venha com um valor
substancialmente maior do que o que era
previsto, ou por alguma política de
crédito, ela pode cancelar, né? O
usuário antes da liquidação, ele ainda
pode cancelar, né? Mas no momento em que
fizer a liquidação, não é mais possível
fazer o cancelamento. Essa liquidação se
dará através de uma STR, tá? Então os
horários para liquidação são os horários
eh onde é possível realizar a minha STR.
Ah, uma vez que eu ah, realizei o
pagamento, né, eu preciso notificar a
instituição credora que eu fui realizado
um pagamento e qual STR, identificando
qual que eh foi feito aquele pagamento,
né, os valores, a data e hora e o
transac ID que está relacionado com o
retorno da STR.
Ah, uma vez que ela notifica através de
um end point para isso, a instituição
criedora ela muda o estado para
stellment completed. Significa aqui que
tem dois dias úteis pra instituição
criedora para avaliar se aquele crédito
que foi efetuado realmente consegue
liquidar aquela operação e dar o recibo
de equitação, né? Então ele pode eh
acontecer um estado de paymento, caso
tem encontrado alguma inconsistência, a
instituição proponente ela pode
verificar esse estado e através desse
estado reconhecer o que precisa ser
feito, fazer as atualizações e e
continuar com o
fluxo. caso ela não tenha tempo hábil
dentro desses dois dias onde ela entrou
no completed eh e não efetuou as devidas
correções, ele vai para rejected. E caso
eh a instituição credora
reconheça o pagamento
daquela daquele contrato, a liquidação
daquele contrato, ela dá a o recibo de
equitação, como a mãe comentou, através
do próprio pint de consulta, né, mudando
o status para portability completed e
preenchendo ali alguns alguns campos a
nossa a nossa consulta do pedido de
portabilidade com as informações que
foram enviadas eh de quitação. Então,
quando que foi feita essa quitação, o
valor que foi quitado e qual foi a
transaction ID, qual foi a STR utilizada
para quitar aquele aquele
contrato.
Perfeito. Aqui nós temos então o nosso
detalhamento. a MAI trouxe para nós um
fluxo de sequência, né, onde mostrava
ali toda eh a complexidade do produto de
portabilidade de crédito, né? E nós
destacamos aqui algumas etapas, né? Ah,
então a etapa de gestão de
simultaneidade, como a MAI
comentou, é uma etapa onde a instituição
credora, que é responsável, ela vai
informar se um contrato ele está
disponível para fazer o pedido de
portabilidade ou ele não está disponível
para fazer o pedido de portabilidade,
né? Eh, esse end point ele se
caracteriza pel esse end point que está
mostrado aqui na figura abaixo, né, que
é o credit operation, contact,
portability, eligibility, né? Então aqui
ele vai informar se o aquele contrato
ele está eh elegível para fazer um
pedido de portabilidade. Essa é a nossa
gestão de simultaneidade, né? O que que
nós temos aqui para esse end point, né?
Nós temos duas configurações distintas.
Nós temos uma configuração aonde ele diz
através do campo is eligible a se o
pedido de portabilidade ele pode ser
feito do âmbito do Open
Filito no âmbito do Open
Filtabilidade pelo âmbito do Openfiles,
né? Um dos motivos de não poder fazer a
razão, eh, não fazer a portabilidade
dentro do OpenF, é porque o contrato de
empréstimo não é do tipo CPC, que é o
nosso primeiro produto que nós estaremos
disponibilizados, disponibilizando.
Depois disso, nós temos mais uma outra
validação para entender se, ok, esse
contrato ele é elegível, né, para fazer
a portabilidade, mas ele está disponível
para fazer a portabilidade, sim ou não?
E daí nós temos um outro campo status,
onde nós temos o Enum se tá disponível
ou se tá em andamento aquele pedido de
portabilidade, né? E com base nessas
informações, a instituição proponente
consegue montar a sua tela para mostrar
quais são os contratos elegíveis, quais
são os contratos disponíveis, eh quais
são as propostas disponíveis pro seu
cliente.
Perfeito. Ahã. Nós temos uma outra etapa
muito importante, né? Logo após a
assinatura de contrato, né? Como a Mai
comentou, essa assinatura de contrato se
dá para meio digital através do mesmo
mecanismo utilizado pela instituição,
né? Ah, onde pode ser eh um Face ID, um
SMS token, enfim, qualquer eh
dispositivo necessário, mas o usuário
precisa assinar
eletronicamente. Uma vez que ele
realizou essa assinatura, a instituição
proponente ela envia esse pedido de
portabilidade para a a instituição
credora, né, através desse end point
portabilities, né, aonde eh ao receber o
pedido de portabilidade, o status,
conforme a nossa máquina de estado, nós
tínhamos lá na nossa máquina de estados,
ele vai para received, né, que eu recebi
aquele pedido de portabilidade e Dentro
desse pedido de potabilidade, existe
algumas validações, né, como a MAI
comentou ali, existe algumas regras, eh,
que a instituição proponente deve ter e
ele faz esse tipo de validações. Caso
ele, encontre algum tipo de
inconsistência, ele deve retornar com
422. por exemplo, o contrato já está em
andamento, não posso ser feita a
contabilidade. Ah, o limite, o prazo é
maior do que o prazo eh ofertado. Eu não
posso ter eh eu posso ter mudança, mas
eu não posso aumentar o meu prazo, né? A
minha frequência eh tá diferente, minha
periodicidade tá diferente, a frequência
em que eu realizo o meu pagamento é
diferente, eu pago mensal, agora vou
pagar quinzenalmente, isso não pode
acontecer. né? Então existe ali algumas
regrinhas e é feita essas validações,
ele retorna um erro específico, conforme
nós detalhamos na nossa especificação no
web. OK? Próximo
slide para a consulta do pedido de
portabilidade, eh nós temos aqui várias
etapas, né? Nós temos tanto a etapa de
contraproposta, a etapa de
eh informar ou não a retenção do
cliente, como que eu informo que eu não
retive o cliente, né? Como que eu
informo que eu já realizei o pagamento?
Como que eu informo que eu já liquidei e
aqui tá o meu recibo de pagamento?
Então, através do end point de consulta
do pedido de portabilidade, né? através
do end pointg
portabilities id, né, aonde eu monitoro
qual é o estado da minha máquina de
status através do campo status, né? E eu
tenho, dependendo de qual seja o estado
em que se encontre, eu posso ter um
motivo para aquele estado, né? Ele está
muito vinculado ao motivo daquele estado
para quando nós temos um estado de
exceção, né? Então, um canceled, um
ejected para entender o por que foi
cancelado, por eh rejeitado aquele
pedido de portabilidade. Nós temos ali o
pay inconsistências encontradas pela
instituição criedora. Então, por
exemplo, se um determinado usuário ele
aceitou uma contraproposta dentro do
canal digital da instituição criedora, a
instituição criedora basta eh mudar o
status para o rejected, como foi
mencionado lá. E a instituição
proponente através de consulta end point
portabilities portability, ela entende
que aquele pedido de portabilidade foi
cancelado. Ela vai verificar ali o
status ruí qual foi o motivo de
cancelamento, qual foi o motivo da
rejeição daquele pedido de
portabilidade, ela vai entender que a
instituição credora ela reteve aquele
cliente. A próxima
slide, né? Uma outra etapa muito
importante é a etapa de atualização do
saldo devedor e dos dados bancários, né?
Então, foi mencionado lá que eh em um
primeiro momento lá no desero, nós
fazemos uma consulta para entender qual
que é o saldo de quitação, eu realizo
uma proposta para aquele usuário e no
doo realizar a quitação daquele
contrato, né? aonde a quitação desse
contrato, se eu preciso consultar
novamente aquelas APIs de empréstimo
para
entender se eh a
instituição ah qual é o novo estado, né,
qual é o novo valor de equitação e
preciso consultar os dados bancários
para fazer o pagamento via STR, né?
Então, para consultar os dados
bancários, nós temos esse get a
tendeira, aonde, basicamente nós temos
ali as informações eh a respeito dos
dados bancários, de como que deve ser
feito esse pagamento, em qual conta
bancária, se a instituição financeira
ela tem uma conta reserva, se ela não
tem uma conta reserva, se ela utiliza um
agente financeiro para fazer esse
pagamento, enfim, vai ter todos os
detalhes.
eh, de como ela deve efetuar essa
liquidação através do account
de OK? O próximo slide, né, comunicação
a respeito da liquidação efetuada, né?
Então, eh, nós mencionamos ali
anteriormente que após realizar o
pagamento, eu preciso efetuar eh, uma
notificação pra instituição credora para
informar a ela que eh eu já fiz o
pagamento com algumas informações a
respeito desse pagamento para facilitar
o batimento da instituição criedora.
Então nós temos esse end point post
portabilities portability
id/payment, aonde eh nesse endp a
instituição proponente ela comunica a
instituição credor a respeito da
liquidação da portabilidade de crédito,
informando qual foi o valor, qual foi o
montante que ela realizou o pagamento, a
data e a hora que ela realizou o
pagamento e o transact ID. E esse
transacid eh se traduz pelo número de
retorno da STR, justamente para
facilitar e ali o batimento da
instituição credora
eh na quitação de um determinado
contrato. E o último slide diz respeito
ao cancelamento do pedido de
porabilidade de crédito, né, onde o
usuário ele pode cancelar a qualquer
momento, tanto no canal digital da
instituição criedora como no canal
digital da instituição
proponente, ah,
através,
eh, do app ali da instituição, né, e
essa
comunicação do lado
da instituição proponente
dará através
deste endp portability portability id/
cancel, né? aonde caso o usuário entre
em contato com a instituição
credora, com a instituição proponente,
ele pode simplesmente eh realizar o
cancelamento do pedido de portabilidade.
A instituição proponente daí informará
para a instituição criedora a respeito
da decisão do cliente que ele tá
desistindo daquele pedido de
portabilidade, por exemplo, né? a
instituição proponente também poderá
utilizar esse pedido para cancelar
aquele pedido de portabilidade caso ela
eh entre em alguma política de crédito
dela, enfim, por alguma questão interna,
ela desista daquela proposta. Então ela
pode também realizar o recancelamento
aqui. E nos próximos slides nós iremos
verificar a respeito eh do guia, né, de
o X e como deve ser essa implementação.
E a Camila pode dar o suporte nesse
nessa apresentação.
Obrigada, Gvan. Boa tarde, pessoal. Eh,
bom, para dar um contexto agora para
vocês, então, a gente fez a primeira
publicação, né, do produto de
portabilidade de crédito com foco em
CPC, eh, no dia 4 de abril desse ano,
tá? Eh, a gente identificou várias
melhorias para fazer, né, que ficaram
pendentes e nós começamos a fazer as
suas revisões agora e a nossa
expectativa é dessa publicação da sua
nova versão pro dia 18 do de junho, que
vai ser agora mês que vem, né? temos
agora poucos dias ah para fazer essa
entrega. E além disso, a gente ainda vai
fazer mais uma revisão final, né? Eh, já
pensando também como que a estrutura do
guia vai ficar pro paraa aquisição desse
novo produto de consignado federal eh no
Gol Live ali em
outubro. Eh, aí a gente já quer também
pensar, já estamos pensando, opa, pode
voltar um Edu, por favor.
Boa. E nós, a gente também já tá
pensando que essa versão final para pro
CPC especificamente, tá? Eh, já vai tá
contemplando o RC1 da API de
portabilidade, tá? Eh, uma das maiores
mudanças que vocês vão ver nesse próxima
versão do guia para esse produto é a
além dessa revisão, né, é a nova
estrutura da arquitetura da informação e
também layout que vai impactar o guia
como um todo. Agora sim, pode passar.
Pessoal, eu poderia passar aqui todos os
requisitos que a gente tem no guia, mas
a Mayara e o Juvan já falaram grande
parte deles. Pouquíssimos aqui, eh, não
foram mencionados. Então, pra gente não
ficar exaustivo aqui, né, falar
novamente, repetir, eu vou trazer uma
visão eh mais da jornada do cliente para
vocês, então, da jornada do usuário,
então o que que acontece nessa jornada.
E essa visão, ela já tá contemplando
essa nova arquitetura que a gente
pensou. Tá? Eh, então, durante eh a
experiência do produto de portabilidade
de crédito, o usuário ele passa por
essas cinco etapas aqui, eh, descoberta,
consulta, solicitação, oferta e
efetivação. Eh, cada etapa dessa tem uma
série de cenários que contemplam
requisitos eh e recomendações que vão
ser implementadas ali pelas
instituições, tá?
Então, brevemente aqui a primeira etapa
que é a de descoberta, o usuário ele
acessa o Penface, ele descobre que a
funcionalidade de portabilidade está
disponível.
Depois ele faz essa consulta de todos os
seus contratos empréstimos elegíveis
dentro dos critérios que já foram
mencionados aqui. Eh, ele faz essa
solicitação através da escolha de um
contrato e aí de fato ele começa a
jornada de eh pedido de portabilidade,
né, dessa intenção de portabilidade. A
partir daí, a gente tem o cenário em que
ele recebe uma proposta proponente para
fazer o aceite, a recusa ou nenhuma das
dos opções, porque o usuário não é
obrigado nem aceitar nem recusar. Caso o
usuário ele aceite essa proposta, eh, a
credor então tem a oportunidade, como já
mencionado também, de fazer uma
contraproposta para tentar reter esse
cliente, que também é o momento onde ele
recebe eh essas condições ali eh de
retenção.
Em qualquer um desses dois cenários,
seja o cliente ter escolhido seguir com
a proponente ou ele ter sido retido pela
credoura, a gente passa para essa etapa
de efetivação que não acontece de fato
uma ação do usuário, é muito mais uma
comunicação, né, uma notificação de que
essa portabilidade ela foi eh concluída
ali e a operação foi liquidada. E a
gente tem ainda além dessas cinco
etapas, a gente tem o momento da área de
gestão, que é onde o usuário tem a
possibilidade de fazer diversas coisas,
né, que é desde consultar o histórico,
eh, de todas as propostas, né, que ele
já solicitou até eh contratos de
portabilidade de crédito que ele tem ali
e vigentes, né? E aqui a gente também tá
falando de fazer a gestão de fato, então
de cancelar propostas, cancelar
intenções, né? Cancelar propostas e
também cancelar portabilidade de
créditos eh que ele
solicitou. Pode
passar, e aqui para mostrar para vocês
como que vai ficar uma carinha. Essa não
é um print da tela do produto de
portabilidade, tá? porque a gente ainda
tá trabalhando em cima dele. Mas para
vocês terem uma ideia de como que vai
ficar eh no guia agora em 18/06, a gente
vai ter uma sinalização padronizada, um
novo layout, como vocês já conseguem ver
aqui, uma nova arquitetura da
informação, como eu já mencionei, e
também uma clareza do protagonista.
Então vocês vão ver qual que é o produto
que tá sendo falado, qual que é a
jornada que tá sendo eh mencionada eh
naquele naquela página, naquele momento
eh do guia. Vocês vão ter uma
visibilidade também de qual etapa dessa
jornada a gente tá falando, eh qual que
é o cenário que tá sendo eh colocado
aqui pros requisitos e recomendações. E
a gente vai sempre se analisar qual que
é de fato o protagonista. é a
instituição transmissora, é a
instituição detentora de conta, é a
instituição proponente, é acredora.
Então, a gente vai deixar isso sempre
bem visível para dizer: "Olha, esses
requisitos, as nossas recomendações,
eles estão especificamente falando eh de
deste protagonista aqui, que no caso,
por exemplo, do da portabilidade de
crédito, vai ser a proponente e a
credora, tá? Pode passar, Edu.
E agora eu vou passar a palavra pro
Bruno. Muito obrigada,
pessoal. A parte de 10,
BR. Bem baixo.
Acho que tá baixo.
Alô, tão me ouvindo agora?
Agora boa. Então vou começar de novo.
Boa tarde a todos. Prazer. Eu me chamo
Bruno, sou aqui do time de portabilidade
de crédito e hoje a gente vai falar
sobre um assunto importantíssimo aqui
pra nossa estrutura, que é referente à
parte de teste de
certificação, começando pela pelo
conceito, né, que é um processo
obrigatório que valida se se as APIs e
os requisitos de segurança das
instituições financeiras estão em
conformidade com os padrões técnicos e
regulatórios do Open Fic Brasil. Aqui um
ponto importantíssimo é que todas as
instituições que desejam participar do
Open Fines, elas precisam ter sido
certificadas tanto nos testes funcionais
quanto nos testes de segurança. Então
esse é um ponto que a gente gostaria
muito de dar ênfase, que é uma
obrigação, certo? E esse processo nos
traz uma série de benefícios, começando
pela segurança, uma maior segurança em
toda a estrutura, aderência às normas, a
proteção dos dados e a integridade do
sistema. Passando para as boas práticas,
nós temos estudo detalhado das ines,
execução antecipada de testes e a parte
de documentação, que a gente pode citar
aqui a parte do PRD, que é o documento
de requisito de produtos, que aqui nós
da DTO está eh criamos essa documentação
para especificar o produto inicialmente
crédito pessoal clean. E tem a parte de
alinhamento contínuo entre DTO e
GT. Pode passar, Edu, por favor.
Falando sobre as
rotinas, nós seguimos uma série de
processos para construção dos nossos
produtos, começando pela especificação,
que é um processo de construção de
funcionalidades, requisitos e
características do produto. Ou seja, a
gente tem semanalmente uma reunião entre
DTO e grupo de trabalho, onde a gente
cria as especificações, que nada mais é
do que a criação de todas as
funcionalidades, tudo que o produto
precisa para ser criado. Temos a etapa
das versões, que são as etapas que
detalham a evolução da construção de um
produto. E temos o motor de
certificação, que é a ferramenta que
permite a execução de testes de
conformidade funcional.
Essa ferramenta é importante falar que
ela é elaborada por uma parceira nossa
chamada Radian, que disponibiliza um
ambiente de teste paraa certificação das
instituições financeiras pro Open
Finance. Então, todos os testes que as
instituições precisam realizar estarão
dentro dessa ferramenta, contido nessas
ferramentas. E temos os marcos, que são
as etapas de validações dos testes. Aqui
do lado direito, a gente trouxe, como a
MAI também já citou, as quatro versões
intermediárias que a gente tem, tá?
Então são as versões onde a gente tá ali
criando as funcionalidades, os
requisitos, tá? Então, para beta 1, a
gente teve a primeira entrega que foi no
dia 4/04. Paraa beta 2, a gente acabou
de entregar as especificações agora no
dia 9/05. E quando a gente faz a relação
com a parte de versões no motor de
certificação, a gente pode perceber que
aqui a beta 2, que tá grifado aqui no
slide, a gente acabou de entregar agora
no dia 23/05, né, na última sexta-feira.
Então, todos os testes que nós
elaboramos para a certificação estão
contidas aqui na beta 2. E também é
importante falar sobre os marcos de
certificação. Nós temos três marcos que
o primeiro de 40% que ele está
contemplado aqui na beta 2, ou seja, de
um total de testes que foram realizados,
40% dos testes precisam ser entregues
agora para a beta 2, que tem a data
limite ali do 3/06.
Perfeito. E aí a gente vai ter também os
marcos de 70% que aí já vai se
relacionar a beta 3 e tem o marco de
100% que é somente no dia
12/08. Pode passar, por
favor. Entrando um pouquinho mais agora
no detalhamento dos testes, a gente
trouxe aqui toda a jornada que a gente
criou dos testes relacionado ao produto
de portabilidade de crédito do serviço
crédito pessoal clean. E a gente trouxe
aqui nove jornadas, né, onde os clientes
precisam, vão passar para realizar todos
os testes. Começando pela pelo
mapeamento dos dados, onde tem dois
testes que contemplam a parte de criação
da portabilidade, a ausência dos campos
obrigatórios. Quando a gente já para
para analisar a parte de gestão de
simultaneidade, a gente tem um teste
mapeado onde vai contemplar a etapa de
validação da disponibilidade da
elegibilidade do contrato. Com relação à
regra de limitação, são dois testes onde
contempla a parte de verificação da
aderência do prazo do contrato a maior e
a menor. Partindo paraa confirmação do
recebimento, temos dois testes, onde
contemplam a parte de validação da
transação por estado da liquidação e a
confirmação da finalização da
portabilidade após o pagamento. Sobre a
contraproposta, são dois testes onde
contempla a parte de validação da
comunicação da rejeição e do aceite da
contraproposta da credora por parte do
cliente. Já com relação à desistência do
pedido de portabilidade, é um teste onde
contempla a etapa de validação do status
da proposta ao ser rejeitada com status
cancellid.
Com relação ao motivo de recusa, a gente
tem um teste que contempla a etapa de
validação do status da proposta ao ser
rejeitada, ou seja, reject, já com
relação ao consentimento, são dois
testes e vai contemplar a parte de
simulação de pedido de portabilidade com
consentimento inspirado e inválido. E
por último, a gente tem aqui os testes
de segurança que vão contemplar a etapa
de validação da presença de campo
obrigatório, que é o XFap Interaction
ID. Também a gente tem aqui uma
observação para esses testes. Se vocês
observarem, são 15 testes no total. E
quando a gente faz associação pro 40%
dos testes para o marco de 40, para o
marco de 40%, é um total de seis testes.
Então, desses 15 testes, seis as
instituições precisam realizar e passar
em seis testes, tá? E temos uma
observação onde os testes que fazem
menção a STR exclusiva de portabilidade
de crédito não será contemplado para o
marco de 40%. Ou
seja, para o marco de 40%, as casas
precisarão passar em seis dos 15 testes
disponíveis, excluindo três testes que
mencionam a STR exclusiva de
portabilidade de
crédito.
Perfeito, Edu tá contigo. Obrigado,
Bruno. Pessoal, acho que para finalizar
aqui, queria sintetizar, né, o que que é
esperado das instituições nesse período.
Eh, acho que começando relembrando aqui
a questão de obrigatoriedade, que a M já
comentou no início. Então, a
implementação da API de portabilidade,
ela é obrigatória para as instituições
transmissoras que vão ofertar ali os
produtos de crédito pessoal clean e
também ou produto de crédito consignado
federal. Paraas receptoras, essa
implementação ela é opcional, tá? Então,
eh, em termos de obrigatoriedade, a
gente tem essas regras que já foram
também divulgadas ali pelo Banco
Central.
Acho que em relação a a todo esse
período de certificação que o Bruno
comentou, né, acho que aqui a gente tem
um ponto muito importante que a gente
precisa também do apoio contínuo das
instituições, né? Porque conceitualmente
o período de certificação ele é também
um ciclo de maturidade tanto da API
quanto do motor de conformidade, né?
Então o que que isso significa? Isso
significa que a gente depende dos
feedbacks das instituições para poder
aprimorar tanto a especificação da API
quanto também o motor de conformidade,
né? Então, é muito importante que vocês
iniciem o quanto antes do
desenvolvimento da API, que vocês abram
os tickets pra gente indicando eventuais
problemas na especificação ou mesmo no
motor de conformidade e e que a gente
consiga fazer todo esse processo ali em
tempo da, né, do go Live ali em outubro,
tá? Importante ressaltar que problemas
relativos à especificação, eles devem
ser reportados paraa estrutura ali pelo
service desk. Quando a gente tiver algum
problema no motor de conformidade, o
canal mais ideal é o GitLB, né? O GitLab
é uma plataforma mais aberta, né? A
gente tem um modelo ali de fórum, então
a gente pede pras instituições que assim
que identificarem qualquer problema no
motor abram uma ISU no GID. lá vocês vão
poder também acompanhar eh o a resolução
dessa ISO,
tá? A gente tem também aqui a questão
dos marcos, né? Então, o Bruno colocou
muito bem, não vou nem me repetir, mas o
intuito aqui eh é realmente a gente
acompanhar o desenvolvimento pelas
instituições, a gente garantir aqui a
maturidade da API também do motor e a
gente ter sucesso ali no Goive, tá? E a
gente tem uma uma ferramenta onde vocês
podem consultar também a o sucesso nos
testes, que é o nosso painel de
certificação, que é um dashboard ali no
Power BI. Então, eh vocês podem
solicitar acesso paraa estrutura e as
próprias instituições podem acompanhar
eh o o sucesso que vocês têm no teste,
que é a mesma visão que a gente vai ter
e que a gente utiliza inclusive para
fazer as notificações ali após os
marcos, tá?
eh a certificação e a publicação da PI,
ela vai ser, né, de forma regular. Então
aqui a gente tá falando de um novo
serviço, né, de uma nova API. A gente
tá, então a gente tá falando de um
processo de certificação que vai ocorrer
ali via eh abertura de ticket no
CERCDESC, da mesma forma que a gente faz
para qualquer outra major, tá? E o prazo
que vocês vão ter, tanto para submeter o
pedido de certificação quanto para
publicar eh a nova PI no diretório é
entre o dia 11 de setembro e 3 de
outubro, tá? Então essa é a data que
vocês têm que ter em mente para fazer a
publicação ali na API da API no
diretório de
participantes. E após esse período, a
gente vai ter piloto, produção. Então
acho que piloto é uma política
relativamente recente aqui do
ecossistema. cujo intuito é basicamente
a gente fazer alguns testes de
introdução antes de disponibilizar,
nesse caso, o serviço para o público por
geral. Eh, a gente aqui da DTO ainda tá
debatendo com o Banco Central como vai
funcionar esse piloto de portabilidade.
Então, é importante que vocês saibam que
haverá um período específico para o
piloto, mas o detalhamento de como vai
ser esse piloto, como que ele vai
funcionar, a gente vai falar depois, tá?
Então, haverá certamente um uma segunda
agenda nossa com vocês para falar
especificamente sobre o piloto quando eh
esse momento
chegar. E aí aqui acho que o pessoal
também vi no chat algumas dúvidas em
relação ao
cronograma. O cronograma que a gente tem
aprovado hoje é esse que tá aqui. Então,
queria só reforçar também algumas datas
importantes para vocês terem em mente.
Eh, a primeira delas é o marco de 40%,
que o Bruno falou muito bem. ele vai
acontecer ali no dia 3 de junho. Então,
tá chegando. Eh, esse marco, a gente,
vocês vão ter que ter sucesso em seis
testes. A gente não vai contabilizar
sucesso nesses três testes aqui que vão
utilizar ISTR, tá? Então, é o payment
core, o invalid payment e o patch
Unhappy. Eh, então tem que ter sucesso
em seis testes, excluindo esses seis que
estão aqui nessa tela. E essa
informação, ela também já foi
compartilhada de informe para vocês,
tá? Uma outra data que é importante que
vocês tenham em mente é o processamento
dos pedidos de certificação e publicação
no diritório. Então, eh essa publicação
ela tem que acontecer até o dia 3 de
outubro, como eu falei. E todo um
cronograma de implementação do serviço
de portabilidade, ele vai envolver
também o versionamento da PI
empréstimos, tá? Então ela vai ser
versionada pra gente incluir aqui
informações que vão ser utilizadas nesse
fluxo. A gente vai ter a liberação do
motor ali também em junho, no dia 6 de
junho. Então a gente já disponibiliza o
motor de empréstimos e a gente tá
prevendo aqui dois marcos inicialmente.
Um deles acontecendo no dia 24 de junho,
no segundo acontecendo no dia 19 de
agosto e a gente tem o go live aqui da P
empréstimos no dia 2 de setembro, tá?
Então, é importante vocês considerarem
que, eh, além do desenvolvimento da API
de Portabilidade, vocês vão precisar
também, né, version a API de
empréstimos, tá? E novamente, acho que
ali pros novos entrantes, eh, na fase de
compartilhamento de dados que entram a
partir de julho, tão dispensados dos
marcos de certificação, mas não estão
dispensados das demais datas, tá? Então,
eh, tanto a certificação, a publicação
do diretório, piloto, eh, vão seguir as
datas que já tão aprováveis nesse
cronograma. E aí, por fim, fica aqui até
respondendo a dúvida ali da Carol em
relação à quantidade de testes. A gente
teve a inclusão de novos testes na
sexta-feira, pode me corrigir, Maara,
que foi quando a gente disponibilizou
ali o motor beta 2, tá, Carol? Então, é
importante vocês considerarem a última
versão do motor para passar nesse marco,
tá? a gente não teve aqui alguma
alteração relevante, então a gente
também vai considerar os sucessos nos
testes já da beta um, mas o total a
gente vai considerar eh eh com base no
beta2.
E aí aqui, pessoal, acho que a gente tem
alguns links úteis para vocês. A gente
vai de novo, compartilhar esse material
com todo mundo, mas é importante que
vocês saibam onde consultar algumas
informações. Então aqui a gente destaca
alguns links importantes. Primeiro deles
é a página de portabilidade de crédito,
onde vão ter, né, tudo, tudo que a Mayar
ou Givan, compartilharam com vocês, vai
tá muito bem descrito lá na página do
portal, junto com os requisitos do
produto, né, que a gente pela primeira
vez, né, Maio, a gente tá eh a gente
disponibilizou isso para ecossistema.
Então, o intuito aqui é tornar eh o
entendimento desse serviço mais
palatável para vocês. As especificações
técnicas também estão no portal. máquina
de estados, a mesma coisa. Eh, o
processo da certificação, ela também tá
ali no no portal e o cenário de teste,
eles vão estar ali no Git. Eh, e aí
vocês podem consultar Carol, inclusive a
versão beta 2 no motor, onde vão tá os
15 testes que a gente mencionou, tá?
Isso já é para tá atualizado lá no Git
Level.
Eh, pessoal, eu acho que em Minas Gerais
é isso. Eh, eu queria abrir aqui eh esse
momento agora para dúvidas de vocês. Eu
sei que bastante gente tá mandando
dúvida aqui no chat. A gente vai tentar
responder. O que não der para responder
aqui no chat agora, a gente vai
responder offline e compartilhar com
vocês. Mas se alguém quiser também
aproveitar esses minutos finais aqui
para fazer alguma pergunta, fica à
vontade, pessoal.
E muito obrigado.
Manda aí, Nelson.
Boa
tarde. Eh, bom, primeiro eu queria
agradecer vocês aí a toda a explicação,
todos os todo o time aí, né?
comprometimento que vocês têm aí com as
casas
aqui. Sou do
Santander. Eh, eu ainda continuo com um
pouquinho de dúvida. Eu eu tenho a
dúvida do seguinte, a quando eu tô
pedindo, quando a recomendação é
que a proponente faça o pedido de saldo
devedor via PI de
empréstimos em Dzeron, ele mostra lá pro
pro cliente na jornada de
portabilidade, eh, uma nova proposta
baseado em seus riscos e tudo mais, faz
uma nova proposta.
Esse cliente, ele provavelmente
descobrindo que tem a possibilidade de
fazer uma portabilidade pelo pelo pelo
banco X, ele vai procurar fazer a mesma
jornada no banco Y, até mesmo para
tentar ver se o Banco Y tem uma proposta
melhor que o banco X nessa
portabilidade. E aí entendo que o que
vier primeiro para a credora é o que tá
valendo. E aí a minha pergunta é eh
nesse caso, eu informei como credora que
o cliente tem um
determinado saldo devedor. três dias
depois, quando eu não tive, eu como
credora não tive sucesso em reter esse
cliente, eh, eu vou passar os dados da
conta e a gente tem e há uma
orientação, né, para que a proponente
faça novamente a consulta na PI de
empréstimos para buscar o valor do saldo
devedor atualizado. Mas lá no comecinho
da jornada, quando o cliente deu o
accept ou ele fez a assinatura dizendo,
ó, eu quero sim fazer essa
portabilidade, ele fez uma pactuação de
um determinado valor, que era aquele
saldo devedor, e agora o saldo devedor é
outro.
Eh, isso juridicamente assim, a gente tá
respaldado que isso isso pode acontecer
e o cliente vai precisar aceitar essa
diferença. E assim, como que a
proponente, como que a gente como creda,
se assegura que a
proponente veio até nós e fez essa
consulta novamente para buscar o saldo
devedor corretamente?
Boa. Obrigada pela dúvida, Nelson. Eh,
durante toda a etapa de validação do
escopo, essa foi uma dúvida muito
latente no GT de portabilidade de
crédito por conta da dessa possível
oscilação que pode ocorrer ali no saldo
devedor. E aí já tem uma negociação que
foi pactuada, assinada ali pelo cliente
e depois isso pode mudar. Eh, então o
que que foi conversado e foi
documentado, tá? que caso esse esse
saldo devedor ele tem uma oscilação
superior a
15%, a instituição proponente ela pode
ali solicitar o cancelamento do pedido
de portabilidade, porque toda a condição
operacional foi arquitetada, foi
estruturada com base na na nas
desinformações recebidas inicialmente
através ali da consulta do do contrato
de empréstimo do cliente, tá? Então, já
existe um motivo de cancelamento mapeado
que pode ser utilizado pela instituição
proponente, eh, olhando pela ótica do
cliente, tá? Durante a jornada, eu até
trouxe na minha fala que foram mapeados
algumas notificações que precisam
ocorrer pro cliente durante ali o fluxo
do pedido de portabilidade de crédito. E
uma dessas notificações é dar
visibilidade pro cliente que pode ser
que aquele saldo ele tenha ali uma
variação, ele tem uma oscilação,
justamente considerando, contemplando
essa possível atualização de saldo que
precisa ser feita ali quando a
instituição proponente, antes de
realizar a liquidação da operação, volta
com a instituição credora para confirmar
os dados, tá? Então tem o a gente tem aí
tanto a parte negocial que tá descrita
no documento de requisitos do produto
PRD, como também na parte técnica, na
especificação técnica, que menciona que
existe essa necessidade de uma nova
consulta ser realizada ali pela
instituição eh proponente acredora.
Ficou,
ficou claro, Nelson?
OK. Sim. Obrigado. Por nada.
Olá, pessoal. Boa tarde. Eh, é possível
voltar no slide eh 1.3 do fluxograma da
portabilidade?
Ele mostra a jornada
completa aí. Boa. Eh, no ponto cinco
ali, em até três dias úteis, informa
retenção do cliente ou informação só do
devedor para dados eh para TED VAP
padronizado. Eu fiquei com uma dúvida.
Eh, a credora, ela vai literalmente
chamar a proponente através de um end
point, por exemplo, vai fazer um post em
um end point da proponente ou ela vai
atualizar a resposta do get dela para
pra conta proponente fazer esse get e
ter o o resultado
atualizado. Eu não entendi isso
aqui. a instituição credora, ela
simplesmente atualiza o status da
máquina de de estados dela, né, daquele
pedido de portabilidade. Então, aquele
pedido de portabilidade, ele vai tá lá
eh com status pending, né, que significa
que tá em período de contraproposta, ela
não reteve aquele cliente, ela vai mudar
o status para accepted stment in
progress. Isso significa que eh ela não
reteve aquele cliente e a instituição
proponente tá lá dentro da nossa
documentação, dentro eh de informações
gerais lá na página do Conflex,
informações
gerais ah no end point de get com
eh portability portability id, né? Na
consulta do pedido de portabilidade, nós
temos descrito que é recomendado eh
consultas a esse end point a cada 2
horas, justamente para entender se houve
alguma mudança de status. E assim as
duas instituições ficam sabendo que
houve eh uma atualização e a proponente
ela consegue eh seguir os próximos
fluxos, próximos passos daquela
portabilidade.
Perfeito. Muito
obrigado, família. Oi, boa tarde,
pessoal. Eu fiquei só com uma dúvida
aqui eh sobre cancelamento aqui do
cliente, né? Eu entendi ali no fluxo que
ele pode tanto cancelar a portabilidade
quanto aceitar a contraproposta. Aí a
minha dúvida é se ele aceitar a
contraproposta, a gente cancela
automaticamente o pedido ali de
portabilidade? Tem que fazer duas ações,
é aceitar a contraproposta e pedir o
cancelamento do pedido.
Aqui na realidade são todos estatus
distintos, né? um de cancelamento, que é
o cancelamento do usuário, significa que
o usuário ele desistiu daquele pedido de
portabilidade. Eh, e o outro é o aceitar
a contraproposta. O aceitar a
contraproposta significa que o usuário
ele eh deixou as condições operacionais
daquele contrato e passou a ter uma nova
condição operacional. mesmo que essa
nova condição operacional seja o mesmo,
ele firmou uma nova assinatura com a
instituição criedora. Então, existe essa
distinção, por isso existe dois estados
eh distintos. Ah, com relação ao
cancelamento, ele pode ser feito eh a
qualquer momento pro usuário, desde que
seja antes da liquidação. É a única
regra que nós temos eh prevista é antes
da liquidação.
Perfeito. Mas assim, pro usuário, a
partir do Entendi que tem essa
distinção, mas a partir do momento que
eu vou lá e aceito uma contraproposta,
ele precisa ter uma uma outra ação de
falar que ele quer o cancelamento
também. É porque eu sei que a gente tem
aquela não, né? Táal não pro usuário é
vai ser transparente, tá? Então ele
aceitando a
contraproposta, a instituição credora
que precisa fazer a atualização na
máquina de estados. Então pro cliente
ele aceitou a contraproposta, ele
continua com a relação com um vínculo
com a instituição credora e aí nos
bastidores, tecnicamente falando, a
instituição que vai tá agindo e não o
cliente. Ah, tá bom. Wit, obrigado.
Nada,
Jardel. Oi. Eh, tudo bom? Minha dúvida é
do no guia de UEX, né? Tem duas coisas
ali que tão recomendadas. Uma é o de
colocar o cancelamento INEP para usuário
na na credora. E aí a colega, a Camila
também falou sobre eh o enví de
notificações ali pela credora em si, que
isso pode ficar duplicado ali com o
proponente. Aí minhas dúvidas é se é uma
recomendação ou uma obrigatoriedade,
porque na essa eh na regulamentação GT
de propriedade não a gente chegar a
discutir isso. E a outra é como vai
ser eh eh homologado isso, porque na nas
homologações não tem, né, esse processo,
é tudo só no backend, assim, então se
tem algum momento que isso também é
homologado,
tá? Ah, eh, pode mãe. Eu, eu só queria
pegar aqui a segunda parte da fala do
jard, que é sobre a definição do do dos
do processo para fazer o solicitar o
cancelamento. E daí eu já te passo, Câ,
para você falar do guia, tá bom?
Eh, sobre o pedido de cancelamento,
Jardel, tava
previsto ali no escopo inicial do Banco
Central e também foi refletido no
documento do PRD que o cancelamento ele
deve ser viabilizado pro cliente tanto
no canal digital da instituição
proponente como no canal digital da
instituição credora. Então, quando a
gente fala sobre esse ponto, eu me
refiro à área de gestão, em que o
cliente ele pode tanto consultar o
pedido de portabilidade, tá? Como
solicitar o cancelamento em ambas as
instituições e não somente na
instituição proponente. Então isso tá no
escopo do Banco Central e também está no
documento de requisitos do produto. Aí
agora eu passo aqui paraa Camila para
falar um pouquinho sobre o guia.
Bom, obrigada. Jardel, tu pode repetir a
tua dúvida, por gentileza?
O a as
as a a essas partes que são na no front
end, né? O cancelamento ou mesmo envio
de notificação ali que estão no guia de
UX, como elas vão ser homologadas,
porque os nos marcos eles são sempre de
back end, né?
como que a gente vai homologar essas
experiências na em tela ali do
usuário, tá? Vamos lá. Eh, quando a
gente fala notificação aqui, a gente tá
falando de post notification, né? Então,
eh, sempre que houver uma mudança de
status no que diz respeito à
movimentação daquele daquele contrato,
daquela portabilidade por parte da
credora, a criedora responsável por
fazer essa notificação ao usuário.
Quando acontece pelo lado da proponente,
a proponente fica também responsável. a
gente tá falando de notificações em
tela, né, que tem ali o temporizador e
claro, isso é determinado eh com base na
no design cist da própria eh
instituição, como que ela se comunica,
né? Eh, mas também pode ser colocado em
tela pro usuário para ficar fixo, porque
como por exemplo quando o usuário faz um
pedido de ele manda uma intenção, né, de
portabilidade, depois que ele vê ali uma
oferta e ele pede para fazer a
portabilidade, inicia ali o o processo.
Eh, a gente tem hoje no guia um exemplo
de tela disso, né, de que o usuário, seu
pedido foi recebido, ele tá sendo
analisado para poder seguir paraas
próximas etapas ali, né? No caso, para
ou caso a criedora não tenha interesse
em reter o cliente, passa já pro
processo de fazer a a efetivação e
liquidação. Caso a criedora tenha eh
interesse em reter o cliente, ela faz a
contraproposta. Consegui responder tua
dúvida?
Parte dela aí, só queria entender como
tem os marcos ali de 40, 60, 100%, eles
são sempre marcos de back end, né?
quando que vai ser eh validado essas
experiências que não são de back end.
Eu vou confirmar aqui com o time e eu
retorno para ti a sua dúvida. Pode ser?
Claro.
Eh, aí aqui até ajudando a Camila, eh, o
cronograma de portabilidade que foi
aprovado, que foi deliberado, ele
contempla ali a linha de teste de
usabilidade de de UEX, mas com data em
definição ainda. Eh, então não sei se o
GT de já fecharam essas datas, mas esse
esse ponto observado aqui trazido pelo
Jardel foi algo mapeado, mas que de fato
quando a proposta ali o cronograma foi
deliberado, ainda não tinha uma data
definida.
É, a gente ainda não discutiu datas para
fazer esse monitoramento, tá? Tá OK. Tá
bom. Então pra gente vai ser importante
porque nossa organização aqui pro
desenvolvimento é uma uma parte que que
é custosa aqui. Obrigado. Com certeza,
Jardel. Pode ficar tranquilo que a gente
vai notificar todo o eh todas as
instituições participantes, tá? Com
antecedência.
Perfeito. Obrigado. Car
GL.
Olá, boa tarde. Aqui tenho algumas
perguntas mais gerais. A a primeira é
inicialmente na apresentação falaram que
para instituições de S3 a S5 a
participação era opcional com com
reciprocidade. No final da apresentação
falava que é obrigatório para qualquer
empresa
oferecendo empréstimo clean. Não
sei basicamente qual qual é a situação
real para instituições S3 e S5.
D36 C5.
Aqui, Edu, eu acho que vale voltar um um
slide onde a gente traz aqui o
detalhamento. Exato. Eh, e aí, Gonzales,
caso eu não consiga responder na
totalidade a sua dúvida, tá bom? a gente
pode depois sugiro que você pode abrir
um ticket ou a gente até mesmo marcar
uma agenda bilateral. Mas de forma bem
resumida aqui, eh, a gente trouxe o
detalhamento aqui na íntegra, né, dos
requisitos de quem deve participar do
serviço de portabilidade aqui no âmbito
do OpenF. E quando o Edu trouxe na fala
dele que instituições que t empréstimo
acoplado, instituições que ofertam, eh é
só um plus, é uma informação acessória
ao que tá descrito aqui, tá? Então, na
sua dúvida sobre instituição S3 S5, é
como tá mencionado nesse nesse slide,
que são voluntárias com reciprocidade,
ou seja, se a instituição quiser atuar
como proponente ali ofertando, né, a
possibilidade de migrar ali, fazer a
portabilidade de crédito,
obrigatoriamente ela também deve atuar
como criedora original. Então, a fala do
Edu não foi eliminando algum ponto
daqui, sim um complemento as informações
trazidas nesse slide
1.2. Perfeito. Muito obrigado. E, e, e,
e se posso perguntar outra coisa, quando
falam que a periidade tem que ser igual,
no caso da da proposta,
isso isso fala se se tem um empréstimo
de seis parcelas, a oferta tem que ser
de um empréstimo de seis parcelas. Isso
fala do empréstimo original ou das
parcelas restantes que o usuário tem que
pagar, tá? Eh, eu vou trazer um um
exemplo na minha fala, tá bom? Então, o
cliente tem ali um contrato de
empréstimo que originalmente esse
contrato tinha 15 parcelas, ele já pagou
cinco. Então, o prazo remanescente desse
contrato, desse contrato original são de
10 parcelas, tá? Logo, esse novo
contrato que vai ser ofertado pela
instituição proponente, ele deve ser um
contrato de 10 parcelas ou menos, nunca
superior, tá? Então ele não poderia
estar ofertando para esse cliente um
contrato com 15 parcelas, que foi o o
prazo originalmente contratado pel
aquele cliente, porque esse cliente ele
já pagou ali cinco, então o prazo
remanescente são de 10 parcelas. Eh, a
sua outra dúvida sobre a periodicidade,
periodicidade que a gente se refere aqui
é a forma em que o pagamento é
realizado. Então, esse esse cliente ele
tem vencimentos ocorrendo de forma
mensal. Então, todo, um exemplo, todo
dia 10 ele paga uma parcela com valor
XPTO. Eh, na oferta da instituição
proponente, esse pagamento não pode se
transformar em quinzenal, esse pagamento
não pode se transformar em trimestral,
tem que eh manter ali a periodicidade
contratada originalmente por esse
cliente.
Perfeito. Muito obrigado. Nada,
meu.
Boa tarde, pessoal. aqui é em relação,
só para ver se eu entendi direito,
Juvan, em relação ao questionamento que
a Janaína trouxe no chat, que também é
um questionamento aqui da nossa casa,
sobre a possibilidade de incluir, né, o
campo de portability ID, eh, no account
data, será discutida, então, numa outra
oportunidade em GT. É isso. Os detalhes,
exato. O que tinha sido mapeado, o que
nós temos hoje dentro da nossa API é um
único account dele. Então, só tem uma
única conta para realizar a aquitação de
qualquer contrato de empréstimo, né,
qualquer portabilidade via Open Files.
Ah, quando nós começamos as discussões a
respeito do Consignado Federal, trouxe a
necessidade de ter eh diferentes tipos
de contas para diferentes produtos e não
para diferentes pedidos de
portabilidade. Não para eh pro meu
contrato de empréstimo eu pago nessa
conta, pro contrato de empréstimo de uma
outra pessoa é uma outra conta. Essa é
uma outra necessidade. É o que trouxe é
que para produtos do tipo CPC eu devo
pagar nessa conta. Produtos do tipo
consignado CIAP eu pago por essa outra
conta aqui. Ah, caso isso vai ser
discutido no futuro, né?
Ah, caso tenha necessidade de incluir
também o portability ID, não tem
problema nenhum, mas é recomendado daí
conversar com a sua cadeira para mostrar
a necessidade do por que você precisa
precisa ter uma conta por usuário e não
uma conta por produto.
Perfeito. É, mas aí também sendo
possível a discussão tanto pro produto
em tela, né, o CPC, quanto
posteriormente para o consignado.
Tá certo. Vou levantar, levar aqui a
questão à cadeira para depois levarmos
de forma única. Obrigada.
Perfetto.
Salve. Infção caiu. Era uma dúvida de
teste aqui, mas eu já tirei já. Tá. Ah,
perfeito. Eh, Lucas,
sou eu, Lucas.
Boa tarde, pessoal. Uma dúvida geral,
assim, a gente tava dando uma olhada no
guia aqui
do de boas práticas, recomendações ali
de Uex e aí surgiu a dúvida que dentro
daquele guia tem alguns requisitos, mas
não tá claro pra gente o, pelo menos
para mim, né, não tá claro o qual é o
objetivo do guia, é falar como deve ser
feita a tela ou que deve conter na
experiência.
Oi, Breno, boa tarde. Eh, como o que
deve conter, tá? Sempre que que você
encontrar, desculpa, era Breno tava
falando, agora fiquei confusa. Lucas,
Lucas, desculpa, desculpa. Pode ir,
Lucas. Eh, sempre o que deve conter, tá?
Quais são as informações que precisam
ser apresentadas no fronte pro usuário.
Então, inclusive, nós estamos fazendo
uma oxigenação do guia para remover tudo
que é indicativo de como deve ser feito,
ou seja, se tem que utilizar cores,
botões, links, né? Então, todos os o que
o que fala sobre componentes, a gente tá
removendo para que a instituição, como
uma orientação geral pro guia, utilize o
melhor formato eh do seu design system,
do seu posicionamento, de como ela se
comunica com o cliente, seja através de
palavras, através de, enfim, vários
formatos aqui que a gente tem de
comunicação com o cliente, eh, da melhor
forma que ela entender ali, né, para
passar a mensagem pro cliente final.
Boa, Camila. E aí, aproveitando, a gente
tá falando aqui também de a decisão de
tá no primeiro nível de tela ou no
detalhe a essas informações que são eh
são requisitos também tá na na mão ali
da instituição, certo?
Eh, a gente tem uma estrutura nova que
vai ficar bem mais claro isso, tá? Eh,
agora para 18/06 a gente vai trazer de
de forma mais, vamos dizer assim,
exemplificada como essas informações
devem aparecer pro usuário, se é detalhe
ou se é de fato em primeira mão ali, tá?
Tá. Então, mas aí nesse caso é uma
determinação, não uma recomendação.
Isso. Isso. Uma determinação. Fica bem
claro. Hoje não tá tão fácil de
verificar, mas agora nessa próxima
versão vai ficar muito mais fácil de
vocês conseguirem identificar o que que
é requisito, que de fato precisa ser
implementado e o que é opcional. Aqui no
caso são recomendações eh com base em
experiência de fato, né, para uma melhor
experiência do do usuário eh pra jornada
do dentro do produto, tá certo?
Obrigado, gente. Nada,
gente, boa tarde. Eh, eu queria tirar
uma dúvida aqui, pode ser até básica,
acho que é uma das primeiras reuniões
que eu participo aqui. Em relação a essa
essa questão de três dias úteis que
vocês colocaram aí na apresentação,
vocês referem isso apenas ao CP ou
qualquer tipo de produto de crédito? Eu
não sei se se já falaram isso em algum
outro momento.
Oi, Breno. Eh, nesse primeiro momento a
gente tá falando se referindo ao produto
CPC. Iniciamos as discussões sobre o
produto consignado federal, mas ainda
não chegamos na discussão da etapa da
contraproposta, tá? Mas de forma
resumida, a gente entende que que irá
contemplar também o o produto consignado
federal, porque não existe um escopo
adicional, um escopo fornecido ali pelo
Banco Central extra para o Consignado
Federal. Então a gente continua
utilizando como base o que foi
compartilhado ali em agosto de 2024 e
nesse escopo menciona que a etapa da
contraproposta deve ser deve ocorrer ali
em até três dias úteis, tá? Mas aí vem
uma dúvida em relação ao vou falar do
consignado, tá? Posso até estar fugindo
um pouco da da se eu já tenho um pedido
em andamento que tá vencendo naquele
meio, naquele naquele período, tá? É só
uma preocupação. Acho que vale para as
discussões quando a gente for falar do
do consignado, até porque além do Open
Fness, eu ainda vou continuar com a
modalidade de de na central de
transferência de crédito que é regida
pela núclea, sabe? Aí eu não sei se vai
haver alguma integração ou coisa do tipo
que tá vendo essa conversa, mas a
preocupação é você ter dois pedidos de
portabilidade do mesmo do mesmo contrato
regindo na mesmo sentido. Então eu
informo os dois, de dois pagamentos, o
meu medo é gerar essa duplicidade, tá?
Mas obrigado pela dúvida aí.
Não, por nada. Sobre esse ponto, eh,
Breno, a gente tem ali a gestão de
simultaneidade que a gente comentou
aqui, que é justamente para viabilizar
que tem ali um uma validação prévia
antes que o pedido de portabilidade de
crédito ele seja realizado. Ou seja, se
já existia um pedido prévio para aquele
contrato XPTO, esse cliente ele não vai
conseguir fazer uma nova solicitação,
logo não vai haver duplicidade ali no
momento da liquidação, no momento da
contraproposta, porque só vai existir um
pedido de portabilidade para aquele
contrato.
Beleza? Mas não vai ter nenhuma
integração com o núclear, nada de
conversa com isso, né? Vai ser tudo
apartado, né?
100% uma nova criação, né? Tudo, todo,
todo o serviço de portabilidade de
crédito, ele vai ocorrer via API de
portabilidade de crédito no AMPO do
OpenF. Então, a conversa com a núclea,
eh, é mesmo para dar visibilidade sobre
o processo e não uma integração com o
fluxo atual feito por eles. Beleza?
Obrigado, viu? Por nada,
Luía.
Oi. Eh, boa tarde. Eu fiquei um pouco
confusa em relação a quais datas os
novos entrantes precisam cumprir, quais
eles não precisam em relação à
certificação, publicação das APIs, etc.
Os entrantes a partir de julho,
né? Opa, Luía, essas instituições elas
foram dispensadas apenas dos marcos
intermediários de certificação, tá?
Então, período de submissão e a
publicação do diretório, ele se mantém
conforme o cronograma que já foi
aprovado, tá? Então, apenas os marcos
intermediários de certificação que foram
dispensados. Demais datas se vat,
tá bom? Obrigada.
Eh, passar pro Mateus. Mas pessoal,
antes disso, eu queria pedir que quem
ainda tiver dúvida que levante a mão
agora pra gente, a gente já tá se
encaminhando pro final, então só pra
gente ter um corte aqui, tá? Mas fala
aí, Mateus.
Opa, boa tarde, pessoal. Eh, só queria
tirar uma dúvida rápida, eh, novamente
falando sobre obrigatoriedade na
participação, eh, que eu fiquei um pouco
confuso. É, no sentido ali a gente tem
um um tópico falando sobre S3 e S5, né,
que são voluntárias com reciprocidade,
mas logo no tópico abaixo, eh, a gente
tem uma citação que todas as as
instituições que participam, né, do
compartilhamento de dados, elas
consequentemente precisam participar da
portabilidade de crédito. Aí eu só
queria entender se eh um requisito ele
complementam o outro ou se a gente pode
levar cada um de forma isolada.
Um requisito complementa o outro, tá?
Ah, tá. Eu desculpa, eu não eu não vi
quem quem fez a pergunta aqui. Mateus.
Oi, Mateus. É, um um requisito
complementa o outro.
Perfeito. Então, se eu sou uma S3
ã e participo da da fase de
compartilhamento de dados,
consequentemente eu sou obrigado a a
implementar a PID de portabilidade de
crédito, certo? Isso. E ali também fala
sobre a participação das instituições do
conglomerado. Uhum. Então, caso a sua
instituição aí tenha demais
instituições, essas instituições também
vão precisar participar, tá bom?
Perfeito. Muito obrigado. Nada,
Fernando. Não, Gustavo, desculpa.
Olá, boa tarde. Acho que a minha
pergunta também vai para Mayara. Também
é um pouco essa dúvida sobre
obrigatoriedade de participação na
portabilidade de crédito. Daí, Mayara,
ã, por exemplo, se a gente for uma S3 ou
S4 com mais de 5 milhões de clientes,
uma informação também complementa a
outra. mais ou menos na mesma dúvida
anterior, ficou confuso para mim também
essa parte.
É, é como como eu falei pro pro Mateus,
ô ô Gustavo, uma informação complementa
a outra. Então, no seu caso aí do seu
exemplo, a instituição S4 com mais de 5
milhões de clientes, precisa participar?
Sim, precisa, porque aí ela se conecta
com o segundo bullet ali da
obrigatoriedade vinculada à participação
do compartilhamento de dados, que são
instituições com mais de 5 milhões de
clientes. Eh, aqui eu eu percebi que tá
gerando uma certa dúvida. Então, no
documento de requisitos do produto que
tá publicado na área do desenvolvedor, a
gente vai criar uma sessão específica de
quem deve oferecer, tentando trazer
essas informações de forma mais didática
para que não gere aí uma interpretação
ambígua, que não o time aqui não fique
com dúvidas, tá bom? Mas respondendo a
sua pergunta de forma simplificada, uma
informação complementa a outra. Então,
por exemplo, maior, se um se uma S4 não
compartilhar dados e não tiver nenhum
daqueles itens ali da primeira opção, o
cliente não tem direito a pedir a
portabilidade de crédito. Por
exemplo, S4, ela não, desculpa, você
pode ir não, por exemplo, uma S4
pequena, né, com menos de 5 milhões de
clientes, ela não faz compartilhamento
de dados. Nesse caso, o cliente não
teria direito de pedir portabilidade de
crédito. Ela não, se ela não quiser
participar do dele. Exato. Nessa
situação, nesse contexto que você trouxe
no seu exemplo, ela ela é não tem uma
obrigação obrigatória e sim voluntária.
Então, querendo ali fazer parte, ter
implementado o serviço de portabilidade
de crédito, ela consegue eh entregar
esse serviço pro seu cliente, mas não tá
como obrigatório, tá? E só bem rápido
para terminar, quando a gente tem sessão
de contrato pro FIDIC, isso exime a
instituição de responsabilidade ou não?
O FIDIC ele é
apenas como é que funciona essa parte?
Eh, sobre esse tópico, Gustavo, eu vou
te pedir a gentileza de abrir um ticket
aqui para a estrutura para para que seja
possível da gente analisar internamente,
seja com o GT ou seja com o Banco
Central. E daí a gente te traz um um
retorno, uma resposta mais completa e
assertiva. Tá bom. Tá bem. Obrigado,
Maer. Nada.
Agora sim, Fernando.
Boa tarde. Eu fiquei com uma dúvida no
fluxo de cancelamento. Quando o cliente
faz o cancelamento pela plataforma da da
IF
originadora, a IF originadora, ela só
precisa alterar o status dela, dizendo
que a operação foi cancelada e fica a
cargo da IF proponente buscar essa
informação. ou a
IF originadora
precisa informar, chamando a API, que a
operação foi cancelada, porque ela
precisaria informar a IF proponente de
alguma forma.
Toda a
comunicação eh da IF cred a IF
proponente é através de mudança de
status, tá? Eh, então ela simplesmente
ela muda o estado e a instituição
proponente ela deve consultar a PI eh,
para identificar qual é o status. Ah,
quando há um cancelamento, ela também
deve preencher, então, em algumas
situações de exceção, né, aquilo que eu
havia comentado, ela também deve
preencher qual foi o motivo, né? Então
vai est lá o estado cancelado e o motivo
daquele estado está na no cancelado,
então muito provavelmente é retenção do
não, desculpe, é cancelamento do
usuário, né, que a gente tá comentando
de um cancelamento do usuário, né? Ah,
mas para qualquer outra situação,
eh toda a comunicação da IF credora
paraa IF proponente se dá através da
mudança de estado daquele pedido de
portabilidade, certo? Então, paraa
retenção é a mesma situação, só muda a
situação e coloca o motivo da retenção.
Exato. Mesma situação. Obrigado,
Felipe.
Oi, pessoal. Boa tarde. Eh, acho que
minha dúvida vai pro pro Gilvan também.
É uma dúvida um pouquinho mais técnica.
Acho que é simples. Ela é sobre o end
point de criação de
portabilidade. Eh, eu entendo que a
proponente ela vai checar o end point de
elegibilidade antes de começar com o
processo. Só que a gente pode ou ter uma
falha no processo em que a proponente
não checou, algum problema de
concorrência que faz com que seja
necessário a gente checar simultaneidade
também na criação da
portabilidade. Nesse caso, a minha
dúvida é se a gente tem que eh retornar
um erro HTTP, caso haja simultaneidade,
ou se a gente cria a entidade de
portabilidade, coloca ela num status de
Jack.
O que está previsto é a ao invés de
retornar um 202, né? Então eu aceitei,
reconheci aquele pedido de
portabilidade, eu retorno um
422 e com o código de portabilidade em
andamento, né? Com a mensagem de
portabilidade em andamento.
Perfeito. Obrigado.
Opa, boa tarde, pessoal. Eu o tema do
não sei quem vai ser o direcionado, mas
sobre a
retenção, quando eu faço a retenção aqui
e daí não necessariamente eu crio um
outro contrato ou mudo a taxa no mesmo
contrato, como que isso é validado,
vamos dizer assim, por vocês? Tem alguma
forma que eu tenho que informar que eu
fiz essa retenção, o motivo e e assim,
como que vocês garantem que realmente eu
fiz essa ação, né?
A retenção, ela deve ter uma assinatura
de contrato, né? Mesmo que seja o mesmo
contrato. Ah, mas eu preciso atualizar
aquele contrato. E como que a gente vai
saber, como que vai ser monitorado eh
essa essa retenção? Então, dentro do
motivo de recusa, nós temos ali o status
rejector. Então, aquele eh aquele pedido
de portabilidade, ele vai pro estado
rejected. O motivo de recusa vai tá lá
retenção do usuário. E para caso de
portabilidade, com motivo de recurso à
retenção do usuário, é obrigatório
preencher um outro objeto que seria a
assinatura digital no canal da
proponente, né? Então ali você tem a
comprovação de que o cliente de fato ele
assinou aquele aquele novo contrato,
mesmo que seja o mesmo contrato.
Ah, tá bom. Obrigado, viu, Gilvan? Por
esse motivo que é importante ter o
registro da contraproposta no canal
digital da instituição credora e o
aceite da contraproposta só pode ocorrer
exclusivamente através do canal digital,
justamente para que a gente consiga
fazer esse monitoramento.
Obrigado, Maara. Por nada.
Bom, pessoal, acho
que sem outras dúvidas aqui a gente pode
encerrar a nossa agenda. Queria só
reforçar que a gente deve, né,
disponibilizar tanto essa gravação hoje
quanto o material que foi apresentado
também, tá? E a FAC aqui com as dúvidas
que surgiram no chat. Tudo isso vai ser
compartilhado com vocês. Então,
novamente, quero agradecer a
participação de todo mundo. Se tiverem
outras dúvidas, pessoal, vocês podem
abrir um ticket no service desk, uma ISO
ali no víde, como a gente já comentou, e
a gente vai acompanhando aí essa
implementação. Muito obrigado a todos.
Boa tarde, pessoal. Obrigada pessoal
pela
participação. Parabéns.
Boa tarde. Obrigado, viu, gente?