Skip to main content
O canal de troca de arquivos do BACEN entrega toda ordem judicial ao Lerian SISBAJUD como um arquivo de remessa. As ordens entram na integração como arquivos de remessa, não como payloads de ordem via API. A integração recebe o arquivo, o converte em ordens canônicas e cumpre cada ordem no ledger do Midaz. Em seguida, ela retorna arquivos de resultado ao BACEN. Esta página cobre os três tipos de ordem que a maioria das instituições encontra primeiro: bloqueio, desbloqueio e bloqueio permanente. A integração também cumpre ordens de transferência judicial, bloqueio cautelar de conta, anulação, cancelamento, liquidação de garantia, solicitações de informação e ordens de quebra de sigilo.

Entrada de ordens por arquivo


O BACEN entrega um arquivo de remessa. O serviço aceita 5301, 5303 e 5308 em produção, e 5311, 5313 e 5318 em homologação. Cada código identifica um fluxo de arquivo e um parser distintos. Depois que um objeto de remessa foi entregue, POST /remittance-files/notifications recebe e converte esse objeto já entregue de forma síncrona. O Lerian SISBAJUD gera o hash do texto plano, faz a criptografia por envelope, armazena o texto cifrado e normaliza o arquivo em ordens judiciais canônicas. O fluxo de remessa de bloqueio (5301 em produção e 5311 em homologação) usa um formato de largura fixa. Cada registro tem 684 caracteres e usa a codificação ISO-8859-1. As posições iniciais definem o tipo de cada registro. Um header e um trailer marcam os limites do arquivo. O corpo carrega os registros de ordem (bloqueio e reiteração, desbloqueio e interrupção de bloqueio permanente, entre outros). Um indicador de bloqueio permanente por ordem marca cada registro de bloqueio:

Execução do bloqueio


Para uma ordem de bloqueio, o Lerian SISBAJUD descriptografa o CPF/CNPJ criptografado apenas para consultar o CRM e nunca o registra em log. Ele não resolve contas apenas pelo token. Em seguida, resolve as contas do réu e executa o bloqueio solicitado por meio do Midaz. Uma execução pode criar retenções de bloqueio por conta. Toda transação de ledger que o Midaz aceita deve estar balanceada. Esse invariante se aplica por transação de ledger aceita. Ele não torna uma ordem judicial inteira, ou uma perna específica de bloqueio ou desbloqueio, uma única transação de partidas dobradas. Cada conta produz um resultado: o valor bloqueado em relação ao valor ordenado. Esse resultado alimenta tanto o arquivo de resposta ao BACEN quanto a trilha de auditoria à prova de violação.

Bloqueio permanente


Uma ordem permanente (indicador P ou D) não para após a primeira tentativa. Ela permanece em monitoramento e tenta bloquear novamente até o seu prazo. Isso captura fundos que chegam depois da primeira tentativa. As novas tentativas são orientadas por eventos, não agendadas. Um evento de mudança de saldo no ledger desperta cada nova tentativa. Quando o saldo de uma conta monitorada aumenta, a integração bloqueia o valor ainda pendente. O monitoramento tem um limite. Uma ordem permanente é executada até o teto de reiteração de 60 dias do CNJ ou até o seu próprio prazo, o que for aplicável. Em seguida, a integração varre e encerra a ordem expirada.

Desbloqueio


Uma ordem de desbloqueio libera fundos anteriormente retidos, conforme a ordem. Ela pode liberar valores em várias retenções de bloqueio por conta. Toda transação de ledger aceita deve estar balanceada. Uma ordem de desbloqueio não é necessariamente uma única transação de ledger. A integração relata o resultado no arquivo de retorno.

Arquivos de resposta e retorno


O Lerian SISBAJUD gera e transmite arquivos de resultado de volta ao BACEN pelo mesmo canal de troca de arquivos:
  • Um resultado de validação sintática (tipo de arquivo 5303 em produção, 5313 em homologação) que informa se a remessa passou na validação estrutural.
  • Arquivos de resultado de cumprimento que carregam os resultados de bloqueios e desbloqueios por ordem e por conta.
O próprio transporte de troca de arquivos é a integração de propriedade do cliente descrita pelo Lerian STA. O Lerian SISBAJUD é um de seus produtos de origem downstream. Ele consome os arquivos judiciais de entrada que o STA entrega.