Antes de abrir o ticket de reexecução ou contestação, é importante realizar as seguintes verificações e ações:

1. Acesse o ticket e baixe os logs/evidências disponíveis.

2. Analise a ocorrência para identificar a origem da falha.

3. Verifique se o problema está relacionado à aplicação, integração ou processamento sob responsabilidade da sua equipe.

4. Avalie se houve interferência externa, erro operacional ou inconsistência na execução.

5. Após a análise, utilize a matriz de decisão abaixo para definir a ação adequada.

Conforme citado acima, solicite a reexecução quando a falha estiver relacionada à implementação, integração ou ambiente da instituição. Antes da solicitação, o problema deve ser corrigido e validado internamente.

Importante: O SLA do ticket de notificação permanece pausado até a conclusão da reexecução.

Exemplos de situações que podem exigir reexecução:

• Erro de implementação/integração: Necessária reexecução devido a falha na integração entre sistemas durante a implantação.

• Processamento fora do esperado: Necessária reexecução devido a inconsistência identificada: ex. quando a API espera que a resposta seja 201 e obtém o retorno 400. (para conferir quais Clients não devem ser deletados, consulte a página de especificações de APIs)

• Status de pagamento fora do esperado: “ACSC (1° Etapa), SCHD, PDNG, ACPD, ACCP, CANC e RCVD” ..

• Deleção acidental de client vinculado aos Software Statements. (para conferir quais Clients não devem ser deletados, consulte a página Deleção de Client).

A correção foi aplicada pela instituição e validada internamente, e o ambiente encontra-se pronto para uma nova validação. Dessa forma, prosseguir com a abertura do ticket de reexecução.

Open

Para o preenchimento do formulário de reexecução, siga as orientações abaixo:

• Instituição Requerente: Identificação da instituição

• Título: Solicitação de Reexecução - Ticket FVP #123

• Número do ticket gerado pela FVP: #123 ( obs: Utilize o número do ticket da FVP relacionado à desconformidade que está sendo contestada ou seja ticket da notificação original)

• Descrição da solicitação: Ref. Ticket #123. A instituição corrigiu a inconsistência identificada e realizou validações internas com sucesso. O ambiente está pronto para nova validação. Solicito a reexecução do módulo de teste.

Open

Após a abertura do ticket de reexecução, o SLA do ticket de notificação original será pausado, permanecendo no status "Aguardando Reexecução/Contestação" até a conclusão da nova execução pelo fornecedor de testes. O resultado dessa nova execução determinará o próximo passo do processo

• Teste imediato/curta duração:

• Teste de longa duração:

Nos ciclos da FVP Manual – Testes Restritos, alguns cenários são classificados como Testes de Longa Duração. Quando uma falha é identificada, um ticket é encaminhado à instituição com as evidências da execução. Nesses casos, o encerramento do ticket depende da obtenção de uma reexecução bem-sucedida realizada pelo fornecedor de testes em suas etapas.

Aqui estão exemplos de módulo de teste de longa duração: credit-portability_api_accepted_settlement; payments_api_automatic-pix-scheduling; automatic-payments_api_automatic-pix-scheduling; automatic-payments_api_automatic-pix-scheduling-retry; automatic-payments_api_automatic-pix-verification;

Em casos de problemas em testes de longa duração, verifique se houve a exclusão inadvertida de clients vinculados aos Software Statements. Se confirmado, o client correspondente também deverá ser excluído na ferramenta FVP. Para mais informações, consulte a página Deleção de Clients.

A contestação deve ser utilizada quando a instituição identificar indícios de que a falha não foi causada por sua implementação e desejar uma revisão do resultado.

As solicitações passam por uma análise especializada para validação das evidências apresentadas.

Erro Técnico
Quando houver indícios de falha na ferramenta de validação ou comportamento da suíte de testes, o chamado será direcionado para a fila N2 – Conformance Suite para investigação técnica.

Erro Operacional
Quando houver indícios de falha ocorrida durante a execução dos testes ou no processo de notificação, o chamado será direcionado para a fila N3 (Fornecedores de Testes), categorizado como Erro Operacional.

• Falso negativo: o teste indica falha, mas as evidências demonstram que o comportamento da instituição ocorreu conforme esperado, não era para ter falhado.

• Inconsistências na ferramenta de certificação: Fornecer uma resposta correta, conforme solicitado pela documentação oficial, mas a ferramenta indicar que ela está incorreta.

• Erro operacional na execução ou no processo de notificação: execução incorreta do cenário, configuração inadequada do teste ou comunicação equivocada do resultado

• Utilização de dados incorretos no cenário de validação: uso de informações inválidas ou divergentes do cenário previsto, comprometendo o resultado da validação.

Atenção: É fundamental selecionar a categoria correta ao abrir o chamado no Service Desk. Isso garante o direcionamento adequado da solicitação e evita encerramentos indevidos ou atrasos no atendimento. Caso tenha alguma dúvida sobre os erros tecnicos e operacionais, ou queira ver mais exemplos, consulte a nossa página de Link: Erros comuns

Antes de registrar a solicitação, recomenda-se que a instituição realize as seguintes verificações:

• Analise as evidências recebidas junto à notificação da desconformidade;

• Valide os logs, payloads e respostas envolvidos na execução do cenário;

• Reproduza internamente o cenário reportado para confirmar o comportamento observado; exceto testes de longa duração.

• Compare o comportamento obtido internamente com o comportamento reportado pelo fornecedor de testes; exceto testes de longa duração.

• Reúna evidências que sustentem tecnicamente a contestação, como logs, capturas de tela, Payloads ou referências da especificação aplicável.

Feita a análise e confirmada a divergência identificada, prosseguir com a abertura do ticket de contestação.

Open

Para o preenchimento do formulário de reexecução, siga as orientações abaixo:

• Instituição Requerente: Identificação da instituição

• Título: Solicitação de Reexecução - Ticket FVP #123

• Número do ticket para contestação: #123 ( obs: Utilize o Número do ticket para contestação relacionado ao ticket da notificação original)

• Motivo da Contestação:

• Erro Operacional: “Selecione esta opção quando a contestação estiver relacionada à execução do teste ou ao processo de abertura do ticket de notificação.”

Exemplo de descrição:

A execução está com parâmetros diferentes dos previstos para a validação. As evidências anexadas demonstram divergência entre os dados utilizados no teste e os dados esperados para o cenário.

• Erro Técnico: “Selecione esta opção quando houver indícios de comportamento incorreto da ferramenta ou dos mecanismos de validação.”

Exemplo de descrição:

A instituição reproduziu o cenário internamente e obteve resultado aderente à especificação. As evidências anexadas indicam possível falso negativo durante a validação.

• Descrição da solicitação: “Evidências do ticket #123 mostram AS ID incorreto; logs internos comprovam processamento correto."

• Anexos: Evidências Comprovatórias: Logs internos da aplicação; Prints de reprodução; Payloads/respostas API; Comparativo: "Teste reportou X, mas sistema retornou Y";

“A qualidade das evidências determina o sucesso. Estrutura analisa com base nisso, sem provas técnicas, contestação é rejeitada”.

Open

Após a abertura do ticket de contestação, a solicitação é direcionada para a fila da Estrutura do Open Finance, responsável pela análise técnica do caso.

Essa etapa tem como objetivo avaliar a procedência da contestação de forma imparcial, com base nas evidências apresentadas e nos resultados obtidos durante a validação.

Importante: acompanhe o status do ticket durante a análise. Caso a contestação seja considerada improcedente, o SLA do ticket original será retomado.

A decisão é comunicada no ticket de contestação:

Importante:

Se a contestação estiver vinculada a um ticket original e for necessário seguir com nova validação, será aberto um ticket de reexecução como "nova execução" associado ao ticket original e encaminhá-lo para a fila do fornecedor de testes. O ticket de contestação, nesse caso, é encerrado.

Considerações Críticas

• Classificação adequada: a categorização como erro técnico ou operacional influencia diretamente a equipe responsável, a priorização e o tempo de atendimento.

• Qualidade das evidências: evidências claras e consistentes aceleram a análise e reduzem retrabalho.

• Escopo de aplicação: o processo de contestação aplica-se exclusivamente aos Testes Restritos. Para Testes Abertos, a correção deve ser tratada internamente pela instituição.

Caso a instituição:

• Tenha dúvidas sobre qual fluxo utilizar;

• Necessite orientação antes de abrir uma Reexecução ou Contestação;

• Identifique um comportamento não previsto na documentação;

• Deseje esclarecer questões relacionadas ao processo de certificação;

Deve abrir uma Solicitação de Informação pelos canais oficiais de atendimento: Solicitação de Serviço → Solicitação de Informações → Conformidade → Ferramenta de Validação em Produção.

Para mais informações, consulte a nossa página Dúvidas comuns.

As informações contidas neste documento estão fundamentadas na Instrução Normativa BCB nº 588, de 31 de janeiro de 2025, publicada pelo Banco Central do Brasil, e refletem as orientações vigentes relacionadas aos serviços e processos da Estrutura de Governança do Open Finance.

Open

Open