# Conta Escrow Monetarie — Brainstorm de Validação e Implementação (2026-07-08)

> Construído sobre `docs/research/2026-06-28-escrow-legal-research.md` (pesquisa jurídico-regulatória, 729 linhas) e `docs/plans/2026-06-28-conta-escrow-implementacao.md` (guia de implementação, 8 PRs).
> Objetivo do dono: validar e implementar a conta escrow deixando **tudo 100% batido** (o próximo passo é subir para produção).

## 0. O que muda em relação aos docs de 28/06: já existe dado real de escrow

Os docs de 28/06 tratavam o escrow como produto greenfield. **Não é mais.** A re-migração do Core (2026-07-08, backup `monbank_backup_2026-07-08.sql`, reconciliada ao centavo) trouxe **fundos vinculados/escrow REAIS do legado**:

| conta | nome | modalidade (relatório oficial) | bloqueado |
|---|---|---|---|
| 0000005063 | KAY CASS GLOBAL LTDA | **CTA ESCROW VINCULADA / DEP VISTA PJ** | R$ 373.446,51 |
| 0000003710 | LIDER TRATORES LTDA | CONTA DE PAGAMENTO PJ | R$ 136.570,65 |
| 0000007511 | RJ RICK ELETRONICOS | CONTA DE PAGAMENTO PJ (Bloqueada) | R$ 12.854,93 |
| 0000004415 | CARGOPAY INSTITUIÇÃO DE PAGAMENTO | CONTA DE PAGAMENTO PJ | R$ 210,00 |
| 0000005705 | CATAN COMERCIO DE CARNES | CONTA DE PAGAMENTO PJ | R$ 92,12 |
| | | **TOTAL** | **R$ 523.174,21** |

Consequência para o brainstorm: o produto escrow não nasce vazio, ele precisa **adotar** esses R$ 523 mil de recursos já vinculados, e o "100% batido" exige que esses valores parem de aparecer como saldo livre de conta de pagamento e passem a ser **DEPÓSITOS VINCULADOS (COSIF 4.1.1.85.00-1)**, indisponíveis. Hoje, após a re-migração, os R$ 523 mil estão dentro do saldo total (R$ 719.303,44) classificados como conta de pagamento 4.9.8 — contabilmente e no display ainda não segregados. Esse é o gap imediato.

## 1. Veredito regulatório (validado, converge com a pesquisa)

- A Monetarie é **SCD** (Res. CMN 5.050/2022, rol taxativo). **Não** pode ser agente escrow fiduciário clássico, **não** presta garantia (Comunicado BCB 41.321/2024), **não** capta depósito à vista, **não** pode ser conta-bolsão (Res. CMN 5.261/2025 + BCB 518/2025).
- Caminho defensável default: **modelagem A — Moeda Eletrônica** (conta de pagamento com movimentação condicionada), com **B — acessória a crédito** como vínculo opcional. C/D plugáveis por `provider`/`origin`.
- Contábil: **COSIF 4.1.1.85.00-1 DEPÓSITOS VINCULADOS** (Circular BCB 2.535/1995), segregado; ledger TigerBeetle dedicado **1_004** (já existe no código, `Ledgers.operational_escrow/0`).
- Anti-bolsão: **toda conta escrow exige `escrow_agreement` com `purpose`** vinculado a negócio jurídico.
- Pré-condição de go-live: parecer jurídico + (idealmente) consulta ao BCB sobre a modelagem; PLD/FT + AIR do produto; contrato tripartite padrão. Flag `ESCROW_ENABLED=false` até o checklist (§1.3 do guia).

## 2. Como fica "100% batido" — o desenho de reconciliação

O TigerBeetle é a fonte do saldo; o COSIF espelha por partida dobrada. Para os fundos vinculados:

- **Saldo postado** (`credits_posted − debits_posted`) permanece = saldo total da conta (mantém a reconciliação atual R$ 719.303,44 intacta).
- **Bloqueio** = hold **pending** no TB (`debits_pending`): reduz o disponível de gasto (BalanceGuard/BalanceCheck/TransactionPipeline subtraem `debits_pending`) sem mexer no postado. **Não** usar transferência posted para pool (isso reduziria o postado e quebraria a reconciliação — decisão técnica confirmada por análise do código).
- **Display** hoje é um bug: o endpoint de saldo (`v2/account_controller.ex`) crava `blocked: 0` e `available = balance`. Corrigir para `available = postado − pending` e `blocked = pending` (melhora geral, vale para qualquer conta com hold, não só escrow).
- **COSIF**: a parcela vinculada sai de 4.9.8 (conta de pagamento) e entra em **4.1.1.85.00-1 (DEPÓSITOS VINCULADOS)**. Balancete continua fechando (A = P + Resultado); só reclassifica dentro do passivo.

Invariante do guia (§10.2): Σ depósitos = Σ liberações + Σ devoluções + saldo vinculado atual, reconciliando TB ↔ COSIF.

## 3. Plano faseado (Fase 0 imediata + produto completo)

### Fase 0 — Reconciliar os fundos migrados AGORA (pré-produção, sem o domínio contratual completo)
Objetivo: os R$ 523 mil param de aparecer como saldo livre e viram vinculado/indisponível, batido no COSIF, sem depender de todo o produto escrow.
1. Seed COSIF `4.1.1.85.00-1` (DEPÓSITOS VINCULADOS) no plano de contas.
2. No ETL (`Remigrate`), para cada conta com `blocked_amount > 0`: criar **hold pending** no TB (débito conta cliente, crédito contrapartida no ledger do cliente) de `blocked_amount` subcentavos, marcado como `reserva_vinculada_legado`; e reclassificar essa parcela no COSIF para `4.1.1.85.00-1` (em vez de 4.9.8).
3. Corrigir o endpoint de saldo para exibir `available = saldo − bloqueado` e `blocked` real.
4. Registrar em metadata da conta/membro: modalidade legada (ESCROW VINCULADA / DEP VISTA / pagamento), situação, e a referência do bloqueio.
5. Reconciliar: saldo postado total inalterado (R$ 719.303,44); `debits_pending` por conta = blocked_amount; COSIF vinculado = R$ 523.174,21; disponível exibido = R$ 719.303,44 − 523.174,21.

### Fases 1–8 — Produto Escrow contratual (do guia 28/06)
PR1 Contabilidade (COSIF + categorias) · PR2 Domínio (`escrow_agreements/parties/conditions/releases` + state machine) · PR3 Execução financeira (TB 1_004 + COSIF, Σ fecha) · PR4 KYC dual + PLD/FT gating · PR5 APIs cliente+admin (maker-checker) · PR6 Painel admin · PR7 Eventos NATS + cabines PIX/SPB para saídas · PR8 Go-live gating (`ESCROW_ENABLED` + checklist §1.3).

Ligação Fase 0 → produto: as 5 contas vinculadas legadas viram, num backfill posterior, `escrow_agreement` cada uma (com `purpose` = "vínculo legado a formalizar"), adotando o hold já existente — sem re-movimentar dinheiro.

## 4. Decisões a validar (dono)
1. **Modelagem regulatória default**: A (Moeda Eletrônica) — confirmar, e status da autorização de ME junto ao BCB (pré-condição de go-live).
2. **Fase 0 agora** (reclassificar os R$ 523 mil como vinculado + hold + display) antes de subir para produção — ou levar como está (saldo total) e formalizar escrow só depois? Recomendo Fase 0 para o "100% batido" contábil.
3. **`kind` de conta escrow**: criar `escrow (5)` em `AccountType` (fora do `partner_account_types`, só via fluxo de agreement).
4. **Escopo para produção imediata**: Fase 0 + PR1/PR2/PR3 (contábil + domínio + execução) com `ESCROW_ENABLED=false`, e o resto (KYC dual, APIs, painel) em ondas seguintes?

## 5. Itens operacionais ligados (produção)
- **2 TEDs órfãs em PRD**: chegaram antes do restore do legado, não acharam conta destino. Depois que o restore de produção subir (as contas passam a existir), **validar cada TED** (E2E/valor/beneficiário) e **creditar** na conta correta, com lançamento contábil e extrato — idempotente, sem duplicar. Precondição: restore de produção concluído e conciliado.
- **Acesso PRD ruim agora** (coreadmin carregando em branco): diagnosticar à parte (deploy/roteamento/UI do admin em prod) — não bloqueia o desenho do escrow, mas bloqueia a operação/validação das TEDs.

## 6. Referências
- `docs/research/2026-06-28-escrow-legal-research.md` — pesquisa jurídico-regulatória completa.
- `docs/plans/2026-06-28-conta-escrow-implementacao.md` — guia técnico (8 PRs, schema, COSIF).
- `docs/plans/2026-07-08-etl-core-monbank-de-para-matriz.md` — a re-migração que trouxe os fundos vinculados legados.