Orientações - [DC] Contas

Obrigatoriedade de informações de contraparte

Com a IN BCB nº 371, a partir de 02/05/23, o envio das informações de identificação de contraparte (CPF ou CNPJ) tornou-se obrigatória para transações de pagamento conforme os tipos de transações da tabela abaixo. 

Legenda: N –Envio não obrigatório; S –Envio obrigatório; R –Em avaliação pelo Banco Central

Abaixo encontramos os casos de exceções à obrigatoriedade de envio da contraparte: ​

• Tipo de transação TED quando se tratar de Transferência entre Reservas (STR0004); ​

• Recebimento de recursos judiciais (STR0051R2);

• Pagamento decorrente de Convênio de Arrecadação na qual a contraparte é um banco correspondente (Neste caso o pagador não necessita enviar a contraparte);

• Transferência para depósito judicial (STR0025);

• Depósito em cheque, e compra e venda de cheque (Neste caso não é necessário envio de contraparte do pagador e recebedor);

• Crédito em conta por motivo de rejeição de Pix, ou seja, uma transação que tem como causa uma tentativa anterior de débito na mesma conta, também realizada via Pix, a qual foi recusada pelo PSP recebedor.

Orientações sobre o transactionId

• As instituições que tiverem transações que ocorreram anteriormente a 13/11/2023 (go-live da v2.1.0) e não possuírem transactionId único, estável e imutável, recomenda-se preenchimento de valor “0000000000” (dummy);

Identificador de transações

O envio do campo transactionId nos endpoints de transações é obrigatório no Open Finance Brasil. O identificador de transação é obrigatório em D0 para todos os tipos de transação. Já a imutabilidade se dá de acordo com a tabela abaixo:

Abaixo a descrição dos possíveis status que uma transação pode ter:​

• TRANSACAO_EFETIVADA - corresponde a data de processamento/efetivação da transação​

• LANCAMENTO_FUTURO - corresponde a data prevista de efetivação da transação​

• TRANSACAO_PROCESSANDO – corresponde a data de lançamento da transação

Para as transações que podem ter seu identificador alterado, conforme regras delimitadas, os comportamento abaixo devem ser seguidos: ​

• O identificador “provisório” compartilhado em D0 deve ser alterado para o identificador definitivo em D+1:​

  • Importante considerar que as instituições financeiras tem diferentes formas de tratar feriados ao processar transações. Umas consideram apenas feriados nacionais e outras consideram feriados regionais. ​

  • Para transações em D+1 com status TRANSACAO_EFETIVADA entende-se que D+1 diz respeito a dias úteis.

• Não devem ser compartilhados ao mesmo tempo o identificador provisório e o identificador definitivo, ou seja, após a alteração do status da transação para TRANSACAO_EFETIVADA, somente a transação com o identificador definitivo deve ser exposta.​

• A data e o valor da transação podem ser alterados na mudança do status para TRANSACAO_EFETIVADA, de acordo com os processos internos existentes nas instituições. Por exemplo: Resgates de investimentos sem liquidez, e Compra e Venda de ações. ​

• A propriedade de identificador de transação único, estável e  imutável passa a vigorar a partir do momento em que o status da transação passa a ser TRANSACAO_EFETIVADA. Entretanto:​

  • Não se deve ter o mesmo identificador entre transações em diferentes status. Por exemplo, não é possível se ter ao mesmo tempo o identificador 123 sendo utilizado para transações no status TRANSACAO_PROCESSANDO e TRANSACAO_EFETIVADA, mesmo que os valores e datas sejam distintos.​

• Especificamente nos casos de transações no status LANÇAMENTO_FUTURO a data do campo transactionDateTime deve ser enviado com as informações de dia/mês/ano prevista para o processamento da transação e os demais campos de precisão da data/hora podem ser enviados como 0 (00:00:00.000).​

• O identificador de transação pode se repetir apenas para transações em status TRANSACAO_PROCESSANDO e LANCAMENTO_FUTURO. Ou seja, uma instituição pode utilizar, por exemplo, o identificador 9999999 para identificar todas as transações que ainda serão confirmadas (status TRANSACAO_PROCESSANDO). 

• Para as transações que não podem ter seu identificador alterado, conforme regras delimitadas, há exceções mapeadas:  ​

  • Existem situações, principalmente para clientes Pessoa Jurídica, nas quais as transações são lançadas de forma individual (múltiplas transações) em D0 e em D+1 são consolidadas em um único lançamento. Também podemos ter o cenário oposto, no qual a transação é lançada de forma consolidada em D0 e em D+1 “abertas” em múltiplos lançamentos individuais. É importante que não haja duplicidade de informações na exposição, ou seja, as transações individuais e a transação consolidada não sejam expostas ao mesmo tempo. ​

    • Por exemplo, para transações de boleto, pix ou folha de pagamento, em D0 são feitos lançamentos individuais com TransactionId individuais, e em D+1 é efetuado lançamento único com um novo transactionID. ​

  • Existem situação de exceção nas quais um lançamento com identificador estável em D0 pode ser eliminado em D+1. ​

    • Por exemplo, para situações de cobrança de tarifa avulsa nas quais existe acordo negocial ou insuficiência de saldo.

QUANTO AO ERRO 422

Na especificação técnica existe a possibilidade de retornar o código HTTP Status Code 422 - accepted. Este código de retorno deve ser utilizado quando algum parâmetro da consulta for enviado semanticamente incorreto, ou seja, desrespeitando uma regra de negócio, para os seguintes endpoints:

• /accounts/{accountId}/transactions;

• /accounts/{accountId}/transactions-current.

Tabela descritiva das possibilidades de interação entre API de Recursos (Resources) e API Contas (Accounts)

*Para os cenários de consentimento revogado ou expirado, conforme determinado na especificação de segurança o access token associado ao mesmo é invalidado impossibilitando a consulta as APIs produtos por parte da Receptora.

Exemplos de casos de uso de contas e o respectivo status a ser informado pela API Resources

• Contas que se encontram em plena utilização e disponível nos canais de atendimento eletrônico devem ter seu status como AVAILABLE.

• Conta cancelada/encerrada nos últimos 12 meses anteriores da data consulta – considerando o consentimento vigente - devem ter seus status como AVAILABLE.

• Conta cancelada/encerrada a mais que 12 meses anteriores da data consulta –considerando o consentimento vigente - devem ter seus status como UNAVAILABLE.

• Conta cancelada/encerrada, em situações nas quais o cliente não mais possua acesso aos canais de atendimento eletrônico da instituição, devem retornar o status UNAVAILABLE.

• Conta que se encontra em bloqueio temporário, onde o cliente não possui acesso aos detalhes por meio dos canais de atendimento eletrônico, devem retornar o status TEMPORARILY_UNAVAILABLE.

• Conta que se encontra em bloqueio definitivo onde o cliente não possui acesso por meio dos canais de atendimento eletrônico, devem retornar o status UNAVAILABLE.

• Contas com bloqueios nas quais o cliente tenha acesso aos detalhes da conta por meio dos canais eletrônicos da instituição devem ter seu status como AVAILABLE.

• Casos de uso que um cliente final efetue um consentimento para Conta para o qual um dos recursos (respeitando a RN001) exija a aprovação de múltiplas alçadas (PENDING_AUTHORISATION) e outro recurso esteja disponível para consulta (AVAILABLE), o comportamento esperado é que cada recurso tenha seu status representado de forma independente, disponibilizando imediatamente os recursos já aprovados.

Conforme a identificação de cenários pelas instituições a lista de exemplos de casos de uso de Contas e o respectivo status a ser informado pela API Resources pode ser complementada.