# Orientação de implementação: STA, SISBAJUD, CCS, CADOC e SIMBA/AMES do BACEN
Documento canônico para um time em outro projeto implementar do zero e acertar na PRIMEIRA transmissão ao BACEN.
Data: 2026-07-23. Fonte da verdade: código VIVO da Monetarie (já smoke-testado contra o BACEN de produção) e relatórios versionados. Cada afirmação carrega a referência de arquivo:linha ou o relatório de onde saiu. Não há inferência: onde o comportamento foi provado contra o BACEN vivo, está marcado com a data e o código de rejeição.
Instituição de referência (troque pelos seus dados):
- ISPB: `46026562` (8 dígitos, identifica você no SFN)
- CNPJ: `46.026.562/0001-05`
- COMPE: `526`
- ISPB do BACEN (destinatário fixo dos arquivos): `00038166`
Regra operacional que atravessa tudo: STA, CCS e SISBAJUD só operam de verdade contra o BACEN em PRODUÇÃO. O ambiente de homologação da Monetarie nunca teve credencial Sisbacen/STA, então a validação funcional de recepção/aceite desses sistemas é sempre feita em PRD. CADOC e SIMBA/AMES têm partes validáveis localmente (geração de arquivo), mas o envio real também é PRD.
---
## 1. Visão geral
### 1.1. O que é cada peça
- **STA (Sistema de Transferência de Arquivos)**: é o TRANSPORTE. Um WebService REST do BACEN por onde você envia e recebe ARQUIVOS. A STA não sabe nada de negócio: ela apenas move bytes, emite um número de PROTOCOLO por arquivo enviado, e lista/entrega os arquivos que o BACEN produziu para você. Todos os demais sistemas (CCS, SISBAJUD via arquivo, CADOC, SIMBA/AMES) trafegam POR CIMA da STA. Na Monetarie a STA vive numa cabine própria (serviço `sta_connector`) que o Core chama por HTTP/NATS.
- **CCS (Cadastro de Clientes do SFN)**: um cadastro regulatório de vínculos cliente x instituição. Você gera um arquivo XML diário (ACCS001) com as inclusões/alterações/exclusões de clientes e envia pela STA. O BACEN responde com ACCS002 (aceite ou rejeição do arquivo), ACCS003 (validação linha a linha) e ACCS009 (ocorrências). Circular BCB 3.347/2007, Res. BCB 53/2020, Res. BCB 179.
- **SISBAJUD (Sistema de Busca de Ativos do Poder Judiciário)**: recebe ORDENS JUDICIAIS de bloqueio/desbloqueio/transferência/cancelamento (arquivo remessa 5301, também chamado AJUD301) e você responde com o resultado da execução (arquivo 5302, AJUD302). Tudo trafega pela STA. Layout v05 (spec v1.11), Reg. CNJ Art. 22, Portaria CNJ SEP 3/2024.
- **CADOC (Catálogo de Documentos)**: família de documentos regulatórios periódicos (4111 saldos diários, 6209 pagamentos de varejo, 1201/APIX001 informações Pix, e vários outros). Cada um tem periodicidade, prazo e leiaute próprios; todos entregues pela STA.
- **SIMBA / AMES**: SIMBA é o Sistema de Investigação de Movimentações Bancárias (quebra de sigilo sob ordem judicial, MPF/CNJ). AMES é o canal de demandas do BACEN que, quando cabível, é respondido com um caso SIMBA. Carta Circular 3454, LC 105/2001, Res. CNJ 332/2020.
### 1.2. Como se relacionam (diagrama textual)
```
+---------------------------------+
| BACEN |
| (RSFN / STA WebService REST) |
+----------------+----------------+
| HTTP Basic Auth (Sisbacen)
| sta[-h].bcb.gov.br/staws
upload/download | protocolo por arquivo
|
+----------------v----------------+
| Cabine STA (sta_connector) | TRANSPORTE
| request_protocol -> upload |
| list_available -> download |
| file.received (NATS) ao Core |
+----------------+----------------+
| NATS monetarie.sta.*
| + HTTP /api/v1/files
+---------------------+---------------------+
| | |
+---------v-------+ +---------v--------+ +---------v---------+
| CCS (ACCS001) | | SISBAJUD (5301/ | | CADOC (4111/6209/ |
| gera XML, lê | | 5302), judicial | | 1201-APIX) e |
| ACCS002/003/009 | | block/unblock TB | | SIMBA/AMES |
+-----------------+ +------------------+ +-------------------+
\_______________ Core banking (Monetarie) _______________/
gera o CONTEÚDO; a STA só transmite
```
Ponto-chave de arquitetura: o CONTEÚDO (o XML do ACCS001, o 5302 do SISBAJUD, o ZIP do 6209/SIMBA) é gerado no core de negócio. A STA recebe esse conteúdo pronto, obtém o protocolo, sobe os bytes, e entrega de volta o que o BACEN produzir. Quem interpreta a resposta (ACCS002, validação AJUD303, etc.) é o core, não a STA.
---
## 2. STA (transporte)
Arquivo de referência: `sta/backend/lib/sta_connector/sta/client.ex`. Manual de referência: Manual STA Web Services v1.5 (julho/2022). A implementação da Monetarie é REST com HTTP Basic Auth, não SOAP. Existe um módulo SOAP (`sta/backend/lib/sta_connector/sta/soap.ex`) que descreve operações ListAvailableFiles/RequestProtocol/etc, mas o WebService REAL do BACEN hoje é REST; a implementação viva usa o cliente REST.
### 2.1. Endpoints e autenticação
- Homologação: `https://sta-h.bcb.gov.br/staws` (`client.ex:64`)
- Produção: `https://sta.bcb.gov.br/staws` (`client.ex:65`)
- Autenticação: **HTTP Basic Auth** (RFC 7617) com usuário/senha do OPERADOR Sisbacen habilitado no STA (`build_basic_auth_header/1`, `client.ex:1227`). Cada sistema exige que o operador tenha a permissão Sisbacen correspondente (ex.: CCS exige "SCERTQRC"/permissão CCS; SISBAJUD exige perfil judicial; etc). Sem a permissão certa, o BACEN devolve 403 no protocolo/upload daquele tipo de arquivo.
- Limites de taxa do BACEN embutidos no cliente: **120 consultas por minuto** e **10 uploads/downloads simultâneos** por instituição (`client.ex:60-61`, `check_rate_limit/1` linha 914). Respeite isso ou o BACEN devolve 429.
- Timeout padrão 30s, retry com backoff exponencial + jitter.
### 2.2. Fluxo de ENVIO (duas etapas obrigatórias)
Todo upload é feito em DOIS round-trips (Manual §5.1 + §5.2), nunca um só:
1. **Requisitar protocolo**: `POST /arquivos` com corpo XML `application/xml` (`request_protocol`, `client.ex:1256-1304`). O corpo (Manual §5.1.1) é:
```xml
{tipo do documento, ex. ACCS001, 5301, 4111}
{SHA-256 do CONTEÚDO, hex minúsculo}
{byte_size do conteúdo}
{nome do arquivo}
...
...
```
O BACEN devolve o número do PROTOCOLO. **Erros históricos que o BACEN rejeita 100% das vezes** (não repita): (a) enviar o `Hash` do NOME do arquivo em vez do conteúdo, e `Tamanho=0` (`client.ex:1278`); (b) inventar um bloco `BACEN` que não existe no schema. O `` do Manual §5.1.2 usa `` com `` obrigatório e ``/`` opcionais; se você não tem destinatário específico, OMITA o bloco inteiro (é opcional).
2. **Enviar o conteúdo**: `PUT /arquivos/{protocolo}/conteudo` com os bytes no corpo (`upload_file`, `client.ex:482-540`). Content-Type `application/octet-stream` (o Manual só proíbe `multipart/form-data`; é opcional). **Erro histórico**: hardcodar `"0"` como protocolo no path fazia o BACEN devolver 404 em todo upload (`client.ex:494`). Use sempre o protocolo real da etapa 1.
Para arquivos grandes há envio em partes (Manual §5.6, `Content-Range: bytes {ini}-{fim}/{total}`) com reconciliação via `GET /arquivos/{protocolo}/posicaoupload` (Manual §5.3.1, campo `` que pode ter buracos, não é offset único). Isso vive em `sta/backend/lib/sta_connector/sta/operations.ex`.
### 2.3. Fluxo de RECEBIMENTO
- **Listar disponíveis**: `GET /arquivos/disponiveis?dataHoraInicio=...&sistemas=...` (Manual §8.1, `client.ex:1241-1254`). `sistemas` é uma lista separada por ponto e vírgula, e só aceita os FILTROS LEGADOS de sistema: `CCS CIR CMP STR SPI CAM LDL DICT JUD` (`systems.ex:11`). Atenção viva: o STA-H rejeitou `PSBA001` no filtro `sistemas`; arquivos SISBAJUD são consultados com `JUD`, não com o código de upload (`systems.ex:151-159`).
- **Baixar conteúdo**: `GET /arquivos/{protocolo}/conteudo` (Manual §6.1). A resposta traz o header custom `X-Content-Hash: SHA-256 ` (não é padrão HTTP, é do BACEN, para validar integridade; `client.ex:542-575`). Verifique o hash.
- **Confirmar recebimento / mudar situação**: `PUT /arquivos/situacao` com Content-Type `application/xml` OBRIGATÓRIO (Manual §7.1). Corpo com `` separados por ponto e vírgula e `REC|A_REC` (`client.ex:1322-1335`). `REC` = recebido/confirmado; `A_REC` = a receber.
- **Consultar protocolo**: `GET /arquivos?tipoConsulta=PROT&nivelDetalhe=RES|BAS|COMPL&protocolos=...` (Manual §8.2). Consulta avançada §8.3.
- **Retomada de download** (Manual §6.2/§6.4): `Range: bytes={ini}-{fim}` com AMBOS os limites explícitos (o Manual não prevê `bytes=N-` aberto), `If-Match` com o ETag.
- Troca de senha do operador §9.1, dias para expirar §9.2.
### 2.4. Estados do arquivo de saída e autoridade da resposta
Máquina de estados do arquivo na cabine (`sta/backend/lib/sta_connector/outbound.ex`): `pending -> uploading -> uploaded -> completed | failed | cancelled | expired`.
Regra de ouro que custou dias de produção para acertar: **o sucesso do UPLOAD NÃO é a aceitação do BACEN**. Subir os bytes com sucesso só significa que os bytes chegaram. Quem ACEITA ou RECUSA o arquivo é o BACEN, e ele responde DEPOIS, num arquivo de retorno próprio (ACCS002 no CCS, AJUD303/304 no SISBAJUD). Modele o sucesso do upload como estado NÃO-terminal (`uploaded`), guarde o protocolo, e só transicione para confirmado/rejeitado quando o arquivo de retorno do BACEN chegar (`core/backend/lib/monetarie/use_cases/ccs/sta_submission.ex:245-304`, docstring `map_sta_to_ccs_status`). Confirmar no upload foi um defeito real: em 2026-07-15 os 4 ACCS001 viraram "confirmado" em milissegundos e o BACEN, ~50s depois, devolveu ACCS002 rejeitando TODOS.
### 2.5. Gotchas do transporte (todos vividos)
- **Upload duplicado = protocolo duplicado no BACEN**. Se dois workers pegarem o mesmo arquivo "pending", cada um pede um protocolo e o BACEN recebe o arquivo DUAS vezes. Prova em PROD 2026-07-15: o segundo upload do mesmo ACCS001 gerou protocolo duplicado (433426387 e 433426411). Solução: claim atômico `UPDATE ... WHERE status='pending'` (`outbound.ex:397-412`, `claim_pending/1`).
- **Retry NUNCA pode re-pedir protocolo se os bytes já subiram**. Um arquivo órfão em `uploading` deve voltar a `pending` PRESERVANDO o `protocol_number` (o worker retoma pelo protocolo já persistido). Re-pedir protocolo é o vetor de duplicado (`outbound.ex:427-446`, `requeue_stale_uploading/1`).
- **403 nunca deve re-pedir protocolo cegamente**: mapeie 403 pós-upload para estado terminal, não para retry.
- **Segredo do bearer/basic com `\n` interno**: valores base64 vindos do Secrets Manager podem vir com quebra de linha (line-wrap). Header HTTP não aceita newline (`:invalid_header_value`). Normalize com `String.replace(~r/\s/, "")` antes de usar (relatado no STA v1 auth, `sta/backend/lib/sta_connector_web/plugs/service_auth.ex`).
- **Proteção do /api/v1 da cabine**: o escopo `/api/v1/*` da cabine STA serve o CONTEÚDO REAL dos arquivos (PII judicial). Ele precisa ser fail-closed (auth de máquina m2m + auth de browser), nunca "aberto porque está na rede interna" (`service_auth.ex:1-45`).
---
## 3. CCS (Cadastro de Clientes do SFN)
Arquivo de referência: `core/backend/lib/monetarie/use_cases/cadoc/ccs.ex` (geração) e `core/backend/lib/monetarie/use_cases/ccs/sta_submission.ex` (ciclo de vida). Manual do CCS v1.2.5, XSD ACCS001 v4.11.
### 3.1. Estrutura do ACCS001 (o arquivo que você envia)
```xml
46026562
00038166
ACCS001
202607200001
46026562
I
N
F
00035012137
2026-07-01
2026-07-31
1
2026-07-20
```
Referência do builder: `ccs.ex:1091-1190`. Campos:
- `TpOpCCS`: `I` (inclusão de vínculo), `A` (alteração, também usado para encerrar relacionamento via `DtFim`), `E` (exclusão de registro errado). Correção de campo não-alterável = par `E` + `I` na ordem (primeiro exclui, depois re-inclui, `ccs.ex:257-284`).
- `QualifdrOpCCS`: default `N`.
- `TpPessoa`: `F` (CPF, 11 dígitos) ou `J` (CNPJ, 14 dígitos). Valide o dígito verificador (mod-11) ANTES de gerar, senão o arquivo queima um NumRemessaArq no BACEN (`ccs.ex:788-792`).
- Arquivo diário é OBRIGATÓRIO mesmo sem movimento: quando não há delta, gere com `QtdOpCCS=0` e sem o bloco `Repet_ACCS001_Pessoa` (XSD v4.11 permite `minOccurs=0`, `ccs.ex:1134-1149`).
### 3.2. Encoding: UTF-16BE sem BOM (o defeito nº 1)
O CCS exige os arquivos em **UTF-16BE (Unicode 16 bits big-endian) SEM BOM**. Prova por escrito do BACEN, dentro do próprio ACCS002 de rejeição: "Os arquivos enviados ao CCS devem obrigatoriamente estarem codificados em formato Unicode de 16 bits big endian (UTF-16BE)".
Como acertar (`sta_submission.ex:155-181`):
- Persista o XML canônico em UTF-8 no banco (a coluna é `text` e o Postgres recusa os bytes `0x00` do UTF-16BE, erro 22021).
- Transcodifique para UTF-16BE só NA FRONTEIRA de envio: `xml |> drop_encoding_decl() |> :unicode.characters_to_binary(:utf8, {:utf16, :big})`.
- NÃO emita `encoding="UTF-8"` na declaração XML. Uma declaração `encoding=` passa a MENTIR depois da transcodificação e o BACEN aborta no prólogo do mesmo jeito. O gerador não deve emitir `encoding=`; para arquivos legados que têm a declaração antiga, remova-a com regex antes de transcodificar (`drop_encoding_decl`, `sta_submission.ex:179-181`).
Enviar UTF-8 fazia o BACEN rejeitar TODO ACCS001 com ACCS002 SitArq=R / ErroCCS=`ECCS0001` ("Documento XML mal formado ... Content is not allowed in prolog", Linha 1 Coluna 1). Provado em PROD 2026-07-15.
Na RECEPÇÃO é o espelho: o BACEN entrega os arquivos CCS COMPACTADOS (ZIP `PK\x03\x04` ou GZIP `0x1F 0x8B`) e em UTF-16BE. Descompacte, depois transcodifique UTF-16BE (com ou sem BOM; sem BOM o XML começa em `<<0x00, 0x3C>>`) para UTF-8, depois alinhe a declaração `encoding=` para UTF-8 antes de parsear (`core/backend/lib/monetarie/use_cases/ccs/sta_inbound.ex:304-372`).
### 3.3. Numeração: NumRemessaArq = UltNumRemessaArq + 1 (o defeito nº 2)
O BACEN mantém um contador POR PARTICIPANTE, `UltNumRemessaArq`, que avança SOMENTE quando ele ACEITA um arquivo. O `NumRemessaArq` do seu próximo envio DEVE ser exatamente `UltNumRemessaArq + 1`. O formato é `AAAAMMDDXXXX` (8 dígitos de data + 4 de sequência).
Provado vivo em PROD 2026-07-16 (`ccs.ex:619-628`): o BACEN recusou `202607160001` (== Ult) e `202607120001` (< Ult) com `ECCS0003` ("O numero informado ... foi 202607160001. O numero correto seria 202607160002") e ACEITOU `202607160002` (SitArq=A, protocolo 433477214, a primeira aceitação da história do sistema).
Implementação (`next_num_remessa`, `ccs.ex:587-653`): o próximo número é o MAIOR entre (a) o sequencial por-dia + 1 e (b) `Ult + 1` extraído do último ACCS002 legível. O `Ult` também é lido dos ACCS002 ÓRFÃOS (o BACEN às vezes emite um ACCS002 sem match, na abertura do dia; ignorá-lo levava a `ECCS0003`). Detalhes importantes:
- O `Ult` NÃO é eco do seu número: é o contador do BACEN.
- Numa REJEIÇÃO, o `Ult` aponta para o último ACEITO, não para o rejeitado.
- Re-envio de uma remessa REJEITADA preserva o `NumRemessaArq` original (não gera número novo); a geração de um arquivo NOVO no mesmo dia usa `MAX(seq do dia) + 1` (`ccs.ex:556-585`).
### 3.4. Grade horária, dia de movimento e retroativo
- **Grade horária do CCS**: `20:00 da véspera` até `08:00 BRT`. Fora da grade = rejeição `ECCS0300`. Fato por escrito do BACEN nos ACCS002 (handoff 2026-07-16). O job diário roda 01:00 BRT (dentro da grade).
- **Dia de movimento**: o `NumRemessaArq` e o `DtMovto` seguem o DIA DE MOVIMENTO, não o dia-calendário. Em fim de semana ou feriado o BACEN desloca o dia de movimento para o PRÓXIMO dia útil. `movement_day = next_business_day(date)` (`ccs.ex:155-162`). Provado em PROD 18-19/07/2026: envios de sábado/domingo receberam `ECCS0003` com "o numero correto seria 202607200001" e `DtMovto=2026-07-20`. Consolide o delta do fim de semana no arquivo do próximo dia útil.
- **Retroativo NÃO é aceito**: enviar movimento de 12/07 no dia 16/07 = `ECCS0003`. O cadastro é cumulativo, então um backlog perdido não precisa ser "recuperado" retroativamente (handoff 2026-07-16 §2).
- Arquivo ilegível: o BACEN responde com `NumRemessaArq=999999999999` (sentinela).
### 3.5. Autoridade do ACCS002 e correlação
O ACCS002 é o VEREDITO do arquivo (`SitArq=A` aceito, `SitArq=R` rejeitado + `ErroCCS`). Só ele move o arquivo para `confirmed`/`rejected` (`sta_submission.ex:580-660`). Correlação:
- O ACCS002 carrega `UltNumRemessaArq` como chave de correlação. Num ACEITE, `Ult == o número do arquivo aceito` (match exato funciona).
- Numa REJEIÇÃO, `Ult` aponta para o último ACEITO, então o match exato acha um arquivo já terminal e o veredito NÃO é dele. Discrimine por CONTEÚDO: match exato terminal com o MESMO XML = redelivery idempotente; XML DIFERENTE = veredito novo, use o fallback do único arquivo aguardando. Provado em PROD 2026-07-16: a rejeição `ECCS0300` do `202607160003` veio com `Ult=202607160002` e era descartada como "idempotente" do 0002 (`sta_submission.ex:591-660`).
- ACCS002 ÓRFÃO (sem arquivo local correspondente) é persistido para alimentar a numeração (`sta_inbound.ex:373-389`).
ACCS003 = validação linha a linha que o BACEN gera após o fechamento da grade; ACCS009 = relatório de ocorrências (texto, sujeito a multa). Ambos são complementares, não mudam o status do ACCS001 (`sta_submission.ex:438-495`).
### 3.6. Exemplo real de aceite
`202607200001`, `SitArq=A`, protocolo `434876738`, com ACCS003 (0 rejeitos) e ACCS009 aplicados (relatório auditoria STA prod 2026-07-20). O primeiro aceite da história foi `202607160002`, protocolo `433477214`.
### 3.7. Códigos de erro ECCS (os que você vai encontrar)
- `ECCS0001`: encoding/XML mal formado (você mandou UTF-8 em vez de UTF-16BE).
- `ECCS0003`: número de remessa inconsistente (o BACEN diz o número correto no comentário do XML).
- `ECCS0300`: fora da grade horária (20:00 a 08:00 BRT).
Existe um dicionário completo de 48 códigos ECCS em `core/backend/lib/monetarie/use_cases/ccs/error_dictionary.ex`.
---
## 4. SISBAJUD
Arquivos de referência: parser em `core/backend/lib/monetarie/use_cases/regulatory/sisbajud/parser.ex`; motor de execução em `core/backend/lib/monetarie/use_cases/judicial/processor.ex`. Layout v05 (spec v1.11), Reg. CNJ Art. 22, Portaria CNJ SEP 3/2024.
### 4.1. Leiaute da remessa 5301 (AJUD301)
Texto POSICIONAL (largura fixa), encoding **ISO 8859-1 (Latin-1)**, uma linha por registro (`parser.ex:1-15`). Tipos de registro:
- `00` = header
- `01` = footer
- `03` = bloqueio OU cancelamento de bloqueio de valores
- `05` = desbloqueio de valores
- `07` = transferência de valores
- `08` = notificação de recebimento de transferência
Header (tipo 00, `parser.ex:44-52`): `tipo_registro`(1-2), `tipo_arquivo`(3-6), `cnpj_instituicao_responsavel`(7-14), `data_movimento`(15-22), `versao_layout`(23-24).
Footer (tipo 01, `parser.ex:55-60`): `tipo_registro`(1-2), `quantidade_registros`(3-12).
Registro 03 / BLOQUEIO (`parser.ex:82-106`), posições principais:
- `protocolo`(3-16), `sequencial_bloqueio`(17-21), `reiteracao_bloqueio`(22-23)
- `juiz_solicitante`(24-138), `data_hora_protocolizacao`(139-158)
- `cpf_cnpj_reu`(159-172), `indicador_cpf_cnpj_reu`(173: F=CPF, J=CNPJ, R=CNPJ raiz)
- `numero_processo_judicial`(174-203), `vara_juizo`(204-208)
- `agencia_bloqueio`(209-214), `conta_bloqueio`(215-229)
- `valor_bloqueio`(230-248), `indicador_bloqueio_conta_salario`(249)
- `ordem_cancelada`(250: `S` = este 03 é um CANCELAMENTO, não um bloqueio novo)
- `nome_autor_exequente`(251-365), `tipo_natureza_acao`(366-367)
- `cnpj_instituicao_bloqueio`(368-375), `conta_instituicao_unica_bloqueio`(376)
Registro 05 / DESBLOQUEIO (`parser.ex:108-122`): referencia um bloqueio ESPECÍFICO por `(protocolo, sequencial_bloqueio, reiteracao_bloqueio)`, mais `sequencial_desbloqueio`/`reiteracao_desbloqueio`, `valor_desbloqueio`(166-184). Libera só aquele bloqueio, não todos os blocos do CPF (`processor.ex:135-167`).
Registro 07 / TRANSFERÊNCIA (`parser.ex:124-147`): `sequencial_transferencia`/`reiteracao_transferencia`, `cnpj_instituicao_destinataria`(166-173), `nome_favorecido`, `cpf_cnpj_favorecido`, `valor_transferencia`(311-329), `id_transferencia` (no registro 08).
Registro 08 / NOTIFICAÇÃO (`parser.ex:149-167`): você é a instituição DESTINO de uma transferência judicial; deve dar o ack.
### 4.2. Identidade única por TIPO de ordem
Ordens diferentes que compartilham `(protocolo, sequencial_bloqueio, reiteracao_bloqueio)` NÃO podem colidir no índice único. Se o índice não incluir o `order_type`, o UNBLOCK/CANCEL/TRANSFER colide com o próprio BLOCK e a ingestão morre. Use índices parciais por tipo (migration `20260709220000`), e trate colisão com ordem terminal como reapresentação (re-emite a resposta original). Handoff 2026-07-09 (identidade por tipo).
### 4.3. Resposta 5302 (AJUD302) e códigos
Você responde o resultado da execução com códigos de resposta (`processor.ex`):
- `00` = resposta negativa / réu não é cliente (quando não achou nenhuma conta, `processor.ex:86-95`)
- `01` = cumprida / executada
- `02` = sem saldo (réu É cliente mas não tem saldo, status `no_balance`, `processor.ex:99-108`)
- `03` = parcial (bloqueou menos que o solicitado)
- `11` = valor diferente do solicitado (transferência)
- `47` = registro inválido
- `99` = falha de sistema
Regra importante do CANCELAMENTO (Reg. CNJ Art. 22 §5º / §4.10): cancelamento SEMPRE responde `01` ao BACEN, mesmo que o bloqueio anterior já tenha sido liberado/liquidado/nunca encontrado (`processor.ex:1034-1112`). Marcadores internos de falha existem para reconciliação, mas o código na resposta é sempre `01`.
### 4.4. Unidade de valor: CENTAVOS na ordem, subcentavos no ledger (o defeito 100x)
A ordem judicial vem em CENTAVOS (2 casas). O ledger da Monetarie (TigerBeetle) trabalha em SUBCENTAVOS (base_units = BRL x 10.000). Misturar sem converter congelava 100x menos (uma ordem de R$ 50,00 congelava R$ 0,50 e reportava "executado" ao BACEN). Decisão de design: guardar os valores judiciais internamente em CENTAVOS (a unidade da ordem, do wire 5302, da contabilidade COSIF) e converter para subcentavos SÓ na fronteira do ledger (`block_amount_cents/2`, `processor.ex:48-59`; `MoneyUnit.to_cents`/`from_cents`). Handoff 2026-07-09 (unidade 100x). Documente a exceção: `judicial_blocks`/`judicial_orders.blocked_amount`/`requested_amount` estão em CENTAVOS, não base_units.
Pré-condição de deploy: se você mudar a unidade em um sistema com blocos já ativos, reconcilie o `blocked_amount` gravado contra o hold real no ledger ANTES, senão o release novo paga 100x o excedente (dinheiro saindo do banco).
### 4.5. Fuso: DATA_HORA_PROTOCOLIZACAO em BRT
O `DATA_HORA_PROTOCOLIZACAO` do fio é hora de BRASÍLIA (BRT = UTC-3 fixo, sem horário de verão desde 2019). Converta BRT para UTC na fonte, ao parsear (handoff SISBAJUD). Não trate como UTC.
### 4.6. Ingestão automática via STA (ZIP + Latin-1)
O caminho vivo é: a cabine STA recebe o arquivo `file.received` pelo NATS, embute o conteúdo em base64 (arquivos JUD, teto 600KB), e um worker Oban durável (`SisbajudStaIngestWorker`, dedup por `source_hash` = sha256 do conteúdo decodificado) ingere. Pontos que custaram um P0 em produção:
- **As remessas AJUD301 chegam ZIPADAS** (`PK\x03\x04`, bytes 3-6 do cabeçalho ZIP). Se o classificador espera o TIPO_ARQUIVO texto (`5301`) na posição 3-6 e recebe o ZIP cru, ele classifica como `unknown` e DESCARTA a ordem. Resultado real (auditoria STA prod 2026-07-20): em produção NUNCA houve ordem ingerida (`judicial_orders = 0`), com ordens de bloqueio de 3+ dias sem resposta e risco de descumprimento do prazo legal de 24h. Corrija detectando `PK\x03\x04` na ingestão e descompactando/iterando as entradas, cobrindo também o caminho das validações e do AJUD305.
- Latin-1 para UTF-8 por campo na ingestão (idempotente por conteúdo descompactado).
- Envio do 5302 tem uma flag `SISBAJUD_AUTO_SEND_ENABLED` (default OFF, decisão do dono 14/07): a ingestão sempre congela o valor e gera o 5302, mas o ENVIO ao BACEN é manual (botão do operador) até a flag ser ligada.
### 4.7. Varas (AJUD305) e outros arquivos
- Códigos de arquivo SISBAJUD aceitos (`systems.ex:98-125`): `AJUD301/302/308/309` e `5301..5341`.
- `AJUD305` = referência de varas/juízos. Sincroniza o catálogo de varas (não gera 5302). O AJUD305 real do BACEN traz ~12.715 varas, o que estoura o teto de 65.535 parâmetros do Postgres; sincronize em LOTES.
- `AJUD303`/`AJUD304` = validações do BACEN sobre a resposta que você enviou.
- `AJUD308` = requisição de informações; `5308` também é aceito.
---
## 5. CADOC (documentos regulatórios periódicos)
Orquestrador de prazos: `core/backend/lib/monetarie/use_cases/cadoc/orchestrator.ex:48-65`. Cada documento tem periodicidade e prazo (`deadline_days`). Todos entregam pela STA com `IdentificadorDocumento` = o código do documento (ex.: `4111`, `6209`, `APIX001`) ou o P-code `PCAD####`.
### 5.1. Tabela de prazos (do código vivo)
| Doc | Periodicidade | Prazo | Descrição |
|---|---|---|---|
| 4010 | mensal | D+10 úteis | Balancete COSIF Mensal |
| 4016 | semestral | D+60 corridos | Balanço Semestral |
| 4111 | diário | D+3 úteis | Saldos Diários COSIF |
| 3040 | mensal | D+10 úteis | SCR Dados de Crédito |
| 3044 | evento | 0 | SCR Eventos de Crédito |
| 2060 | mensal | D+10 úteis | Estatística Bancária Mensal |
| 2061 | trimestral | D+15 úteis | Demonstração de Limites Operacionais |
| 5300 | mensal | D+22 | Relacionamentos de Cooperativa |
| 5500 | mensal | D+10 úteis | Demonstração de Resultado |
| 9010 | trimestral | D+60 corridos | IFData Trimestral |
| 9011 | anual | D+60 | Demonstrações Financeiras Anuais |
| 9800/9805 | mensal | D+60 | SVR (valores a receber / devolvidos) |
| 6209 | trimestral | D+30 | Pagamentos de Varejo e Canais |
| CCS | evento | 0 | Cadastro de Clientes do SFN |
### 5.2. CADOC 4111 (Saldos Diários COSIF)
`core/backend/lib/monetarie/use_cases/cadoc/generator_4111.ex`. IN BCB 354/2023. Envio DIÁRIO, prazo D+3 dias ÚTEIS. Mesma estrutura XML do 4010 (`//`), mas com o snapshot de saldo de UMA data específica. O `dataBase` usa data completa `AAAA-MM-DD`. Deve BATER com o CADOC 4010 no último dia de cada mês.
### 5.3. CADOC 6209 (Pagamentos de Varejo)
`core/backend/lib/monetarie/use_cases/cadoc/generator_6209.ex`. IN BCB 335/2022, manual Decem v2.0.7. TRIMESTRAL. É um ZIP com nome OBRIGATÓRIO `BACEN.ZIP` contendo, na raiz, exatamente 8 arquivos TXT posicionais ISO 8859-1: `CONGLOME`, `USUREMOT`, `ESTATCRT`, `ESTATATM`, `TRANSOPA`, `OPEINTRA`, `CONTATOS`, `DATABASE`. Data-base = AAAAMM do último mês do trimestre; data-limite = último dia útil do mês subsequente ao fim do trimestre civil.
### 5.4. CADOC 1201 / APIX001 (informações Pix) e a taxonomia oficial
`core/backend/lib/monetarie/use_cases/regulatory/cadoc1201/generator.ex`. Código STA `APIX001`, XSD v2.6. Instrução de preenchimento oficial: `APIX001_2-6.xlsx` do BACEN (relatório 2026-07-19).
A taxonomia do grupo Transacoes é onde quase todo mundo erra. O grupo cobre SOMENTE liquidação FORA do SPI. Transações que cursaram pelo SPI NÃO entram em NENHUM balde (o BACEN as recebe do próprio SPI). Baldes (`generator.ex:1-33`):
- Código 5: transações liquidadas pelo Liquidante referentes a participantes indiretos, sem cursar pelo SPI. Só o Liquidante informa. Se você não é Liquidante, este balde é ZERO (o XSD ainda exige as 12 linhas, com zeros válidos).
- Código 6: transações liquidadas pelo próprio participante que não cursaram pelo SPI, entre seus próprios clientes.
- Código 7: rejeitadas por suspeita de fraude pelo PSP do pagador.
- Códigos 1 a 4: descontinuados.
- `QtdConsultas` (grupo ConsultasDict): consultas resolvidas na CÓPIA LOCAL do DICT SEM consultar o DICT. NÃO é o total de consultas ao DICT.
`TipoEnvio`: `I` (inicial) ou `S` (retificação). O ciclo de snapshot tem guard de versão de agregação (`aggregation_version`) para nunca entregar um snapshot gerado com taxonomia antiga.
Lição registrada (relatório 2026-07-19): a tese de que o legado "subnotificou" caiu quando a instrução oficial provou que o balde 5 nunca foi "via SPI". Com a taxonomia oficial, o arquivo do legado estava CERTO ao centavo. Não retifique sem prova de divergência real na fonte.
---
## 6. SIMBA / AMES
### 6.1. SIMBA (quebra de sigilo bancário sob ordem judicial)
`core/backend/lib/monetarie/use_cases/regulatory/simba/simba.ex`. Carta Circular BCB 3454, LC 105/2001, Res. CNJ 332/2020. Atende ordem judicial (MPF/CNJ) de quebra de sigilo.
Gera 5 arquivos TSV empacotados num ZIP: `AGENCIAS`, `CONTAS`, `TITULARES`, `EXTRATO`, `ORIGEM_DESTINO` (`simba.ex:6-9`). O ZIP é transmitido via SIMBA Transmissor (canal próprio) ou, quando o BACEN demanda por AMES, entregue pela STA.
Segurança do dado (obrigatório):
- CPF/CNPJ do investigado é persistido com criptografia AES-256-GCM DETERMINÍSTICA, com chave `:cloak_simba_key` ISOLADA das outras chaves (Res. CNJ 332/2020 §VI). Um blind index HMAC-SHA256 keyed permite busca por igualdade (`simba.ex:11-17`). LGPD Art. 46, Res. CMN 4.658/2018.
- Retenção: casos são purgados após `period_end + retention_years` (default 5 anos). O worker `SimbaRetentionWorker` roda diariamente 03:00 UTC e NULLifica `cpf_cnpj`, `cpf_cnpj_hash`, `notes` e o `content` do arquivo, preservando a trilha de auditoria (accountability LGPD Art. 37, `simba.ex:19-27`).
Pré-condição CRÍTICA: sem o secret `:cloak_simba_key` configurado, a geração falha fail-closed com RuntimeError. Confira o secret (`monetarie/{env}/simba/cloak_key`) ANTES de qualquer geração (relatório AMES-SIMBA 2026-07-19). O ambiente dev precisa de uma chave fixa própria (só dev), senão gerar caso SIMBA localmente sempre falha.
### 6.2. AMES (canal de demandas do BACEN, elo para SIMBA)
`core/backend/lib/monetarie/use_cases/regulatory/ames.ex`. Fluxo: registrar a solicitação do BACEN, anexar a resposta (arquivo simples OU um caso SIMBA), enviar via STA, acompanhar o aceite.
Via de envio (sonda G1, 2026-07-18): o AMES envia pela via HTTP `POST /api/v1/files` da cabine STA (o mesmo caminho do CCS, com aceite BACEN provado em PRD), NÃO pela via NATS. O `system_id` é o `sta_file_code` da solicitação (varia por demanda) e o NOME do arquivo é SEMPRE prefixado pelo código (`AMES\d{3}`), porque a cabine deriva o tipo pelo regex do nome (`ames.ex:1-22`, `attach_simba_response/3` linhas 103-116).
Defeitos reais achados quando o elo AMES para SIMBA foi exercitado pela primeira vez (relatório 2026-07-19, todos corrigidos):
- Casar o shape do gerador (`{:ok, file, validation}`, tupla de 3), não `{:ok, %{file: file}}`.
- Datas vêm do fio como STRING ISO; o gerador exige `%Date{}`. Normalize e recuse período inválido (422 legível).
- Documento sem acervo (investigado sem contas na instituição) deve recusar `documento_sem_acervo` ANTES de gerar caso vazio (fail-closed).
- A adoção de um segundo caso AMES no mesmo dia com a mesma janela colide no índice único; trate como changeset legível (422), não MatchError 500.
---
## 7. Vocabulário canônico consolidado
Use EXATAMENTE estes termos, códigos, encodings, unidades e fusos.
| Item | Valor canônico | Onde/prova |
|---|---|---|
| STA host homolog | `https://sta-h.bcb.gov.br/staws` | `client.ex:64` |
| STA host prod | `https://sta.bcb.gov.br/staws` | `client.ex:65` |
| STA auth | HTTP Basic (operador Sisbacen) | `client.ex:1227` |
| STA limites | 120 consultas/min, 10 simultâneas | `client.ex:60-61` |
| STA envio | 2 etapas: POST /arquivos (protocolo) + PUT /arquivos/{prot}/conteudo | `client.ex:1256-1304` |
| STA hash do protocolo | SHA-256 do CONTEÚDO, hex minúsculo | `client.ex:1288` |
| STA download integridade | header `X-Content-Hash: SHA-256 ` | `client.ex:542-575` |
| STA confirmar | PUT /arquivos/situacao, Situacao REC/A_REC | `client.ex:1322-1335` |
| STA filtro de sistema | `CCS CIR CMP STR SPI CAM LDL DICT JUD` (SISBAJUD = `JUD`) | `systems.ex:11,151-159` |
| STA estados de saída | pending/uploading/uploaded/completed/failed/cancelled/expired | `outbound.ex` |
| ISPB destinatário BACEN | `00038166` | `ccs.ex:29` |
| CCS arquivo de envio | ACCS001 (XML) | `ccs.ex:1091-1190` |
| CCS encoding do fio | UTF-16BE SEM BOM, sem `encoding=` na declaração | `sta_submission.ex:155-181` |
| CCS numeração | `NumRemessaArq = UltNumRemessaArq + 1`, formato AAAAMMDDXXXX | `ccs.ex:619-628` |
| CCS grade horária | 20:00 véspera a 08:00 BRT | handoff 2026-07-16 |
| CCS dia de movimento | próximo dia útil (fim de semana desloca) | `ccs.ex:155-162` |
| CCS veredito | ACCS002 (SitArq A/R + ErroCCS); NUNCA o sucesso do upload | `sta_submission.ex:245-304` |
| CCS erros | ECCS0001 (encoding), ECCS0003 (numeração), ECCS0300 (grade) | handoff 2026-07-16 |
| CCS TpOpCCS | I / A / E | `ccs.ex:1182` |
| CCS TpPessoa | F (CPF 11) / J (CNPJ 14) | `ccs.ex:1184` |
| SISBAJUD remessa | 5301 / AJUD301, texto posicional, ISO 8859-1, layout v05 | `parser.ex:1-15` |
| SISBAJUD resposta | 5302 / AJUD302 | processor |
| SISBAJUD registros | 00 header, 01 footer, 03 bloqueio/cancel, 05 desbloqueio, 07 transferência, 08 notificação | `parser.ex:8-15` |
| SISBAJUD códigos resposta | 00, 01, 02, 03, 11, 47, 99 | `processor.ex` |
| SISBAJUD unidade | ordem em CENTAVOS, ledger em subcentavos (converter só na fronteira) | `processor.ex:48-59` |
| SISBAJUD fuso | DATA_HORA_PROTOCOLIZACAO em BRT | handoff 2026-07-09 |
| SISBAJUD ingestão | AJUD301 chega ZIPADO (PK\x03\x04) + Latin-1 | auditoria 2026-07-20 |
| SISBAJUD varas | AJUD305, sincronizar em LOTES (~12.715 varas) | ingest worker |
| CADOC 4111 | Saldos Diários, D+3 úteis, XML igual ao 4010 | `orchestrator.ex:50` |
| CADOC 6209 | trimestral, ZIP `BACEN.ZIP`, 8 TXT ISO 8859-1 | `generator_6209.ex` |
| CADOC 1201 / APIX001 | Pix, XSD 2.6, TipoEnvio I/S, balde 6 = fora-SPI clientes próprios | `generator.ex:1-33` |
| SIMBA | 5 TSV (AGENCIAS/CONTAS/TITULARES/EXTRATO/ORIGEM_DESTINO) em ZIP | `simba.ex:6-9` |
| SIMBA segredo | `:cloak_simba_key` isolada; fail-closed sem ela | `simba.ex:11-17` |
| AMES envio | STA HTTP, nome prefixado `AMES\d{3}` | `ames.ex:1-22` |
| BRT | UTC-3 fixo (sem horário de verão) | `schedule_config.ex:43-44` |
---
## 8. Checklist de "acertar na primeira transmissão"
Os erros que a Monetarie cometeu e corrigiu. Não repita.
### STA (transporte)
1. NÃO faça upload em uma etapa. São duas: pedir protocolo, depois enviar conteúdo.
2. NO pedido de protocolo, o `Hash` é do CONTEÚDO (SHA-256 hex minúsculo) e `Tamanho` é o `byte_size` real. Hash do nome do arquivo + Tamanho 0 = rejeição 100%.
3. NÃO invente `BACEN`. Omita o bloco `` (é opcional).
4. NO PUT do conteúdo, use o protocolo REAL no path. Hardcodar "0" = 404 sempre.
5. Trate o sucesso do UPLOAD como NÃO-terminal. Só o arquivo de retorno do BACEN (ACCS002, AJUD303) confirma/rejeita.
6. Claim atômico do arquivo pending; retry NUNCA re-pede protocolo se os bytes já subiram (isso duplica o arquivo no BACEN).
7. Normalize segredos base64 (remova `\n`) antes de usar em header HTTP.
### CCS
8. Envie UTF-16BE SEM BOM. UTF-8 = `ECCS0001` em todo arquivo. Não emita `encoding=` na declaração.
9. `NumRemessaArq = UltNumRemessaArq + 1` (contador do BACEN, avança só em aceite). Contador por-dia sozinho colide = `ECCS0003`.
10. Numere e date pelo DIA DE MOVIMENTO (próximo dia útil em fim de semana), não pelo dia-calendário.
11. Respeite a grade 20:00 a 08:00 BRT, senão `ECCS0300`. Não envie retroativo.
12. Na recepção, DESCOMPACTE (ZIP/GZIP) e transcodifique UTF-16BE para UTF-8 antes de parsear.
13. Correlacione o ACCS002 por conteúdo, não só por `UltNumRemessaArq` (que numa rejeição aponta para o último ACEITO).
### SISBAJUD
14. Parseie o 5301 como texto POSICIONAL ISO 8859-1, por posições fixas do layout v05.
15. Converta a unidade: ordem em CENTAVOS, ledger em subcentavos. O bug 100x reportava "executado" congelando 100x menos.
16. Índice único por `(protocolo, seq, reiteracao, order_type)`, senão UNBLOCK/CANCEL colidem com o BLOCK e a ingestão morre.
17. `DATA_HORA_PROTOCOLIZACAO` é BRT, converta para UTC na fonte.
18. DETECTE o ZIP (`PK\x03\x04`) na ingestão do AJUD301 e descompacte. Sem isso, TODA ordem cai em "unknown" e é descartada (P0 real: 0 ordens em produção por dias).
19. Cancelamento sempre responde `01` ao BACEN (Reg. §4.10).
### CADOC / APIX
20. 6209 é `BACEN.ZIP` (nome exato) com 8 TXT ISO 8859-1 na raiz.
21. APIX001: balde 5 é privativo do Liquidante (zeros se você não é); via-SPI não entra em NENHUM balde; `QtdConsultas` é resolvida na cópia LOCAL do DICT, não o total de consultas ao DICT.
### SIMBA / AMES
22. `:cloak_simba_key` isolada e configurada, senão a geração falha fail-closed.
23. AMES envia por HTTP com o nome prefixado `AMES\d{3}` (a cabine deriva o tipo pelo nome).
24. Recuse documento sem acervo e período inválido ANTES de gerar (fail-closed, sem arquivo órfão).
---
## 9. Evidências de produção disponíveis (sem PII/segredos)
O que existe para validar, e onde. Atenção: validação funcional de recepção/aceite de STA/CCS/SISBAJUD é sempre PRODUÇÃO (homologação nunca teve credencial Sisbacen/STA).
- **CCS, primeiro aceite real**: ACCS002 `SitArq=A`, remessa `202607160002`, protocolo `433477214` (handoff `docs/handoff/2026-07-16-ccs-aceite-bacen-utf16be-handoff.md`). Segundo aceite `202607200001`, protocolo `434876738`, com ACCS003 (0 rejeitos) e ACCS009 (relatório `docs/reports/2026-07-20-auditoria-sta-prod-sisbajud-ccs.md`). Rejeições reais ECCS0003 de 17/18/19-07 documentadas no mesmo relatório. Os ACCS002 CRUS ficam legíveis no stream NATS `MONETARIE_STA` (retenção 7 dias): o BACEN escreve o motivo da rejeição em comentário DENTRO do próprio XML.
- **SISBAJUD, resposta entregue ao CNJ**: RESP protocolo `433721199`, transmitido, recebido no BACEN e baixado pelo CNJ (`ejuez.s-sisbajud`) em 16/07 15:30 (auditoria STA prod 2026-07-20, Achado 2). O painel STA do BACEN (acesso legado) mostra o ciclo completo do protocolo. O P0 do ZIP não-descompactado (0 ordens em produção) está no Achado 1 do mesmo relatório.
- **APIX001**: batimento célula a célula do arquivo com a semântica oficial em `docs/reports/2026-07-19-apix-abril-batimento-semantica-oficial.md`. A instrução oficial `APIX001_2-6.xlsx` é baixável do BACEN (URL no relatório). XSD `core/backend/priv/schemas/APIX001_2-6.xsd`, validável com `xmllint`.
- **AMES/SIMBA**: validação viva local (5 TSV, ZIP, download com content-disposition `AMES001_...zip`) em `docs/reports/2026-07-19-ames-simba-validacao.md`. Screenshots em `docs/reports/screenshots/2026-07-19-ames-simba/`.
- **CADOC 6209 vs manual**: `docs/reports/2026-07-08-auditoria-cadoc-6209-vs-manual-bacen.md`; handoff de rebuild `docs/handoff/2026-07-08-cadoc-6209-rebuild-leiaute-oficial.md`.
- **SISBAJUD unidade 100x e identidade por tipo**: handoffs `docs/handoff/2026-07-09-sisbajud-fix-unidade-bloqueio-100x.md` e `docs/handoff/2026-07-09-sisbajud-fix-identidade-ordens-por-tipo.md`.
- **CCS dedup de envio e autoridade do ACCS002**: `docs/handoff/2026-07-15-ccs-sta-envio-duplicado-accs002-handoff.md`.
O que EXIGE acesso a produção (não reproduzível em homologação):
- Envio real de qualquer arquivo (CCS, SISBAJUD, CADOC) ao BACEN e a leitura do veredito (ACCS002, AJUD303, ACADOC). Homologação da Monetarie nunca teve credencial Sisbacen/STA.
- A validação funcional de bloqueio/desbloqueio SISBAJUD ponta a ponta (só ocorre em PRD, com ordens judiciais reais).
- O aceite CADOC 4111/6209/APIX (o BACEN só processa em PRD).
XSDs e leiautes de referência versionados: `core/backend/priv/schemas/` (APIX001 2-6), `core/backend/priv/xsd/ccs/ACCS001.xsd`, e os leiautes SISBAJUD/CADOC citados nos handoffs. Não versione dados reais com PII (CPF/CNPJ, conteúdo de arquivos judiciais).
---
## 10. Ponteiros rápidos de código (para copiar o padrão)
- STA cliente REST: `sta/backend/lib/sta_connector/sta/client.ex`
- STA operações (chunk/resume/reconcile): `sta/backend/lib/sta_connector/sta/operations.ex`
- STA sistemas/IdentificadorDocumento: `sta/backend/lib/sta_connector/sta/systems.ex`
- STA estados de saída + claim/dedup: `sta/backend/lib/sta_connector/outbound.ex`
- STA auth m2m do /api/v1: `sta/backend/lib/sta_connector_web/plugs/service_auth.ex`
- CCS geração ACCS001 + numeração + movimento: `core/backend/lib/monetarie/use_cases/cadoc/ccs.ex`
- CCS ciclo de vida (envio, ACCS002/003/009, encoding UTF-16BE): `core/backend/lib/monetarie/use_cases/ccs/sta_submission.ex`
- CCS recepção (descompacta + transcodifica): `core/backend/lib/monetarie/use_cases/ccs/sta_inbound.ex`
- CCS grade horária/cron: `core/backend/lib/monetarie/use_cases/ccs/schedule_config.ex`
- SISBAJUD parser do 5301: `core/backend/lib/monetarie/use_cases/regulatory/sisbajud/parser.ex`
- SISBAJUD motor de execução (block/unblock/transfer/cancel): `core/backend/lib/monetarie/use_cases/judicial/processor.ex`
- SISBAJUD ingestão durável (ZIP/Latin-1): `core/backend/lib/monetarie/workers/regulatory/sisbajud_sta_ingest_worker.ex`
- CADOC prazos/orquestração: `core/backend/lib/monetarie/use_cases/cadoc/orchestrator.ex`
- CADOC 4111: `core/backend/lib/monetarie/use_cases/cadoc/generator_4111.ex`
- CADOC 6209: `core/backend/lib/monetarie/use_cases/cadoc/generator_6209.ex`
- CADOC 1201 / APIX001: `core/backend/lib/monetarie/use_cases/regulatory/cadoc1201/generator.ex`
- SIMBA: `core/backend/lib/monetarie/use_cases/regulatory/simba/simba.ex`
- AMES: `core/backend/lib/monetarie/use_cases/regulatory/ames.ex`