# Conta Escrow Monetarie — Guia de Orientação para Implementação

> **Documento de orientação técnico-regulatória para implementação do produto Conta Escrow na plataforma Monetarie (SCD).**
> Destinado a execução assistida por agentes de codificação (Claude / Codex).
>
> **Data:** 28 de junho de 2026
> **Instituição:** MONETARIE SOCIEDADE DE CRÉDITO DIRETO S.A. — SCD · CNPJ `46.026.562/0001-05` · ISPB `46026562` · COMPE `526` · SISBACEN `00018`
> **Stack:** Elixir/Phoenix (monorepo), TigerBeetle (ledger), Aurora PostgreSQL, NATS, AWS ECS Fargate (`sa-east-1`, conta `990933657879`)
> **Pesquisa regulatória de base:** `research/escrow_legal_research.md` (729 linhas, com URLs verificáveis)

---

## 0. Como usar este documento

Este guia tem três camadas:

1. **Validação regulatória** (§1–§4): o que pode/não pode ser feito por uma SCD, e como o produto deve ser modelado para ser defensável perante o BCB.
2. **Validação técnica do estado atual** (§5): o que já existe no monorepo e o que falta.
3. **Plano de implementação executável** (§6–§12): tarefas concretas, com referências de arquivo, schema, contabilidade COSIF e critérios de aceite — escritas para serem entregues a Claude/Codex em PRs incrementais.

> ⚠️ **Alerta jurídico transversal:** este é um documento de engenharia com embasamento regulatório. Antes do go-live em produção, as decisões de modelagem regulatória (especialmente §1.2 e §2) **devem ser validadas por parecer jurídico e, idealmente, por consulta formal ao BCB**. O produto vive em zona cinzenta: o escrow não está expressamente no rol taxativo da SCD nem expressamente vedado.

---

## 1. Veredito Regulatório: a Monetarie (SCD) pode ofertar Conta Escrow?

### 1.1 O ponto de partida — restrição do rol taxativo

A Monetarie é uma **SCD** regida pela **Resolução CMN nº 5.050/2022**. O art. 7º define um **rol taxativo** de operações e serviços. A SCD **não capta depósito do público** (art. 10, I) e **não pode prestar garantias** (Comunicado BCB nº 41.321/2024). Portanto:

- ❌ A SCD **não pode** atuar como "agente escrow / depositário fiduciário" clássico (serviço autônomo de custódia de recursos de terceiros), pois isso **não está no rol taxativo**.
- ❌ A SCD **não pode** "garantir" os valores às partes (não é seguro-depósito, não tem FGC).
- ❌ A SCD **não pode** operar a conta escrow como conta-bolsão genérica (vedação reforçada pelas **Res. CMN 5.261/2025** + **Res. BCB 518/2025**, em vigor desde dez/2025).

### 1.2 Os caminhos legítimos (escolher a modelagem ANTES de codar)

A pesquisa identifica **quatro ângulos** pelos quais o produto é defensável. A implementação técnica muda conforme a escolha:

| # | Modelagem | Robustez | Implicação técnica |
|---|---|---|---|
| **A** | **Emissora de Moeda Eletrônica** — conta de pagamento pré-paga com movimentação condicionada | ⭐ Mais robusta | Escrow = conta de pagamento (ME) com flags de bloqueio condicional; lastro na CCME junto ao BCB |
| **B** | **Acessória a operação de crédito** — conta vinculada à dívida/recebíveis da própria SCD | ⭐ Sólida quando há crédito | Escrow vinculado a um `loan`/`receivable` existente; é parte do produto de crédito autorizado |
| **C** | **Banco parceiro (BaaS / white-label)** — SCD opera plataforma+KYC+condições; custódia fica no banco S1/S2 | Requer parecer | Integração externa; o saldo "real" vive no parceiro; Monetarie espelha estado e condições |
| **D** | **Cobrança de terceiros** — escrow acessório ao serviço de cobrança de crédito (art. 7º, §1º, II) | Nicho | Escrow ligado a uma operação de cobrança gerida pela SCD |

> **Recomendação de engenharia:** modelar o domínio de forma que a **modelagem A (Moeda Eletrônica)** seja o caminho default, com a **B (acessória a crédito)** suportada por vínculo opcional a um contrato de crédito. As modelagens C e D entram como `provider`/`origin` plugáveis. Isso evita reescrever o domínio caso a decisão regulatória mude.

### 1.3 Pré-condições regulatórias obrigatórias (checklist de bloqueio)

Antes de habilitar o produto em produção (`ESCROW_ENABLED=true`):

- [ ] Confirmar autorização da Monetarie como **emissora de moeda eletrônica** junto ao BCB (modelagem A) — OU formalizar o vínculo a crédito (B) / contrato com banco parceiro (C).
- [ ] **Política PLD/FT** aprovada e **AIR específica** para o produto escrow (Circular BCB 3.978/2020 + Res. BCB 44/2020).
- [ ] **Contrato de escrow tripartite** padronizado, revisado por jurídico (condições de liberação objetivamente verificáveis).
- [ ] Garantir **vínculo específico** de cada conta escrow a um negócio jurídico documentado (anti-conta-bolsão).
- [ ] Definir tratamento contábil: **COSIF 4.1.1.85.00-1 (DEPÓSITOS VINCULADOS)** ou conta de ME equivalente.

---

## 2. Conceito do Produto (alinhamento de domínio)

**Conta Escrow** = conta de movimentação **condicionada**, acessória a um **negócio jurídico principal**, com **três papéis**:

- **Depositante** — entrega os recursos.
- **Beneficiário** — pode receber, se as condições se implementarem.
- **Agente / Administrador (Monetarie)** — custodia, monitora condições e executa liberações/devoluções. Nunca garante.

**Diferenças que o software precisa refletir** (vs. conta de pagamento comum):

1. Movimentação **não é livre** — depende de condições/instruções.
2. Recursos são **segregados** contábil e logicamente do patrimônio da Monetarie.
3. A conta é **acessória** a um contrato (precisa de vínculo obrigatório a um `escrow_agreement`).
4. Liberações podem ser **parciais** (tranches) e **bidirecionais** (beneficiário ou devolução ao depositante).
5. Tem **dois clientes** sujeitos a KYC (depositante + beneficiário).

---

## 3. Tratamento Contábil e Contrapartida COSIF (crítico)

### 3.1 Conta COSIF de contrapartida

A conta-espelho da SCD é **passiva** (recursos de terceiros). Códigos relevantes:

| Código COSIF | Denominação | Uso no escrow |
|---|---|---|
| **`4.1.1.85.00-1`** | **DEPÓSITOS VINCULADOS** | **Conta principal** — recursos indisponíveis para movimentação livre por convenção (Circular BCB 2.535/1995). |
| `4.9.9.27.00-3` | OBRIGAÇÕES DE PAGAMENTO EM NOME DE TERCEIROS | Alternativa quando há pagamento por conta e ordem de terceiros. |
| `4.9.8.x` | Conta de pagamento do cliente (modelo SCD usado hoje) | Já usado pelo `AccountingBridge` como `cosif_account_code` default. |

> **Decisão de engenharia:** criar (na tabela `cosif_contas` / seed) e mapear a conta **`4.1.1.85.00-1`** como contrapartida de escrow. NÃO reutilizar a conta de pagamento comum (`4.9.8`) — isso descaracterizaria a segregação e a indisponibilidade.

### 3.2 Mecânica de partidas dobradas (a implementar no `AccountingBridge`)

```
DEPÓSITO NA CONTA ESCROW (entrada de recursos):
  DÉBITO:  Disponibilidades (1.1.2.x) ou Conta de pagamento de origem
  CRÉDITO: DEPÓSITOS VINCULADOS (4.1.1.85.00-1)

LIBERAÇÃO AO BENEFICIÁRIO (condição implementada):
  DÉBITO:  DEPÓSITOS VINCULADOS (4.1.1.85.00-1)
  CRÉDITO: Conta do beneficiário / saída PIX/TED (1.1.2.x ou 4.9.8 do beneficiário)

DEVOLUÇÃO AO DEPOSITANTE (condição frustrada):
  DÉBITO:  DEPÓSITOS VINCULADOS (4.1.1.85.00-1)
  CRÉDITO: Conta do depositante / saída PIX/TED

COBRANÇA DE TARIFA DE ADMINISTRAÇÃO (receita da SCD):
  DÉBITO:  Conta do depositante (ou desconto na liberação)
  CRÉDITO: Rendas de serviços (7.1.7.x)
```

> A SCD **não** lança o escrow como "Depósitos à Vista" do seu balanço operacional comum — é **DEPÓSITOS VINCULADOS**, segregado. Os rendimentos de eventual aplicação dos recursos seguem tributação normal (IR/IOF); o IR sobre ganho do negócio principal só incide na disponibilidade efetiva ao beneficiário.

### 3.3 Onde isso encaixa no código existente

O monorepo **já tem** o motor contábil correto:
- `core/backend/lib/monetarie/use_cases/accounts/accounting_bridge.ex` — mapeia `category` → par D/C COSIF automaticamente. **É aqui que entram as novas categorias `escrow_deposit`, `escrow_release`, `escrow_refund`.**
- `core/backend/lib/monetarie/use_cases/cosif/plano_contas.ex` — plano de contas COSIF v2 com hierarquia e lookup por código.
- Contabilidade de partidas dobradas Circular BCB 4.010 documentada em `pix/docs/implementation/pt-BR/administration/accounting.md`.

---

## 4. Segregação, PLD/FT e Compliance (requisitos não-funcionais)

| Requisito | Norma | Implementação |
|---|---|---|
| Segregação dos recursos de terceiros do patrimônio próprio | Res. CMN 5.050/2022 art. 21 §1º / art. 23 (analogia); COSIF | Ledger TigerBeetle dedicado (`@operational_escrow 1_004`) + COSIF `4.1.1.85.00-1` separado |
| KYC do **depositante e beneficiário** | Circular 3.978/2020 | Ambos os papéis passam pelo onboarding/KYC antes da liberação |
| AIR específica do produto | Res. BCB 44/2020 | Flag de risco do produto; reaproveitar `use_cases/compliance` |
| Monitoramento e comunicação ao COAF | Lei 9.613/1998; Circular 3.978/2020 | Operações em espécie ≥ R$ 50 mil → comunicação automática; suspeitas → análise ≤ 45 dias |
| Vínculo específico ao negócio (anti-bolsão) | Res. CMN 5.261/2025; Res. BCB 518/2025 | `escrow_agreement` **obrigatório** por conta; sem agreement não há conta escrow |
| Retenção documental | PLD/FT 5 anos; anti-bolsão 10 anos | Auditoria imutável (`use_cases/audit`) por 10 anos |
| Sigilo bancário | LC 105/2001 | RBAC + criptografia; acesso restrito |

---

## 5. Estado Atual no Monorepo (validação técnica)

### 5.1 O que JÁ existe (reaproveitar)

| Componente | Caminho | Observação |
|---|---|---|
| Ledger escrow no TigerBeetle | `core/backend/lib/monetarie/use_cases/ledgers.ex` → `@operational_escrow 1_004` | Range BRL operacional já reservado. |
| Operações hold/release/collect | `core/backend/lib/monetarie/use_cases/transaction.ex` | `hold_funds/3`, `release_funds/2`, `collect_funds/1` — "escrow-like" sobre settlement pool. **Genérico, não contratual.** |
| Produto PIX Escrow (catálogo) | `core/docs-site/api/accounts.md` → `prod_pix_escrow` | Apenas catalogado como "Escrow for disputed transactions". Não há domínio contratual. |
| Motor contábil COSIF | `core/backend/lib/monetarie/use_cases/accounting_bridge.ex` + `cosif/plano_contas.ex` | Pronto para receber novas categorias de escrow. |
| Tipos de conta | `core/backend/lib/monetarie/use_cases/model/relational/account_type.ex` | `client (3)`, `institutional (0)` etc. **Não há kind de escrow.** |
| Abertura de conta | `core/backend/lib/monetarie/use_cases/accounts/open_account.ex`, `account_kind.ex` | Mapeia `account_type` string → kind. |
| Saldos available/pending/blocked | `core/docs-site/api/accounts.md` | TigerBeetle já expõe `blocked`. Usável para "valor sob condição". |

### 5.2 O que FALTA (gaps a implementar)

1. **Domínio contratual de escrow** — não existe `EscrowAgreement`, `EscrowCondition`, `EscrowParty`, `EscrowRelease`. O `transaction.ex` atual é um pool de liquidação genérico (inclusive com aliases `bet/win/loss` deprecados de um blueprint anterior — **não usar**).
2. **Vínculo obrigatório a negócio jurídico** (anti-bolsão) — inexistente.
3. **Contrapartida COSIF `4.1.1.85.00-1`** — não mapeada no `AccountingBridge` (hoje a conta de cliente cai em `4.9.8`).
4. **Categorias contábeis** `escrow_deposit / escrow_release / escrow_refund / escrow_fee` — ausentes em `@mapped_categories`.
5. **Máquina de estados** do escrow (draft → active → partially_released → released/refunded → closed).
6. **Liberação parcial / tranches** e **liberação bidirecional** (beneficiário vs. devolução).
7. **KYC dual** (depositante + beneficiário) acoplado ao gating de liberação.
8. **Painel de gestão** (admin) e **API de cliente**.
9. **Flag de habilitação** `ESCROW_ENABLED` e gating regulatório.

---

## 6. Arquitetura-Alvo do Produto Escrow

```
┌─────────────────────────────────────────────────────────────┐
│ CONTRATO (negócio jurídico principal)                        │
│  escrow_agreement  ──< escrow_parties (depositante, benef.)  │
│        │             ──< escrow_conditions (verificáveis)     │
│        │             ──< escrow_releases (tranches)           │
│        ▼                                                      │
│  escrow_account (account.kind = escrow, cosif 4.1.1.85.00-1) │
└───────────────┬─────────────────────────────────────────────┘
                │ movimentação condicionada
                ▼
┌─────────────────────────────────────────────────────────────┐
│ TigerBeetle ledger @operational_escrow (1_004)               │
│  saldo: available (livre) / blocked (sob condição)           │
└───────────────┬─────────────────────────────────────────────┘
                │ todo lançamento dispara
                ▼
┌─────────────────────────────────────────────────────────────┐
│ AccountingBridge → COSIF journal entry (partidas dobradas)   │
│  DEPÓSITOS VINCULADOS 4.1.1.85.00-1  ⇄  disponibilidade/CP   │
└─────────────────────────────────────────────────────────────┘
```

**Princípios de design:**
- O **saldo real** é fonte única no TigerBeetle (ledger `1_004`); o Postgres guarda o **domínio contratual** e o espelho de estado.
- **Nenhuma liberação** sem (a) condição implementada/verificada e (b) KYC do beneficiário OK.
- Cada movimentação financeira gera **um e somente um** par contábil COSIF via `AccountingBridge` (idempotente).
- O Core **publica eventos** (NATS); assinaturas BACEN (PIX/SPB de saída) permanecem nas cabines PIX/SPB — **o Core nunca assina** (regra absoluta #13 do `CLAUDE.md`).

---

## 7. Modelo de Dados (migrations Ecto)

> Prefixo de migração seguindo o padrão do repo (timestamp). Tabelas no schema do Core (Aurora). Valores monetários em **centavos** (inteiro), consistente com o resto da plataforma.

### 7.1 `escrow_agreements`
```
id              uuid pk
reference       string unique        # identificador legível (ex.: ESC-2026-000123)
purpose         string               # negócio jurídico principal (anti-bolsão; obrigatório)
purpose_doc_ref string               # referência ao contrato/documento subjacente
modeling        enum                 # :e_money | :credit_linked | :partner_bank | :collection
status          enum                 # :draft :active :partially_released :released :refunded :closed :cancelled
account_id      uuid fk -> accounts  # a escrow_account (kind = escrow)
linked_loan_id  uuid fk null         # modelagem B (acessória a crédito)
provider        string null          # modelagem C (banco parceiro)
total_amount    bigint               # valor total previsto (centavos)
currency        string default "BRL"
opened_at       utc_datetime null
expires_at      utc_datetime null    # prazo de vigência
closed_at       utc_datetime null
metadata        map
inserted_at / updated_at
```

### 7.2 `escrow_parties`
```
id            uuid pk
agreement_id  uuid fk
role          enum                 # :depositor | :beneficiary | :agent
user_id       uuid fk null         # cliente Monetarie, se houver
name, document(cpf/cnpj), email, phone
kyc_status    enum                 # :pending :approved :rejected
kyc_ref       string null          # ligação ao onboarding/compliance
is_pep        boolean
metadata      map
```

### 7.3 `escrow_conditions`
```
id            uuid pk
agreement_id  uuid fk
description   text                 # condição objetivamente verificável
kind          enum                 # :document :date :manual_attestation :external_event
status        enum                 # :pending :met :failed
verified_by   uuid null            # admin que atestou
verified_at   utc_datetime null
evidence_ref  string null
ordering      integer
```

### 7.4 `escrow_releases`
```
id              uuid pk
agreement_id    uuid fk
direction       enum               # :to_beneficiary | :refund_to_depositor
amount          bigint             # centavos (permite tranches parciais)
status          enum               # :requested :approved :executed :failed :cancelled
condition_ids   {array uuid}       # condições que habilitam esta liberação
requested_by    uuid
approved_by     uuid null          # segregação de funções (maker-checker)
tb_transfer_id  string null        # id do transfer no TigerBeetle
cosif_entry_id  uuid null          # journal entry COSIF gerado
executed_at     utc_datetime null
metadata        map
```

### 7.5 `escrow_account` (reuso de `accounts`)
- Adicionar `kind` de escrow (ver §8) e definir `accounts.cosif_account_code = "4.1.1.85.00-1"`.
- Ledger TigerBeetle = `Ledgers.operational_escrow()` (`1_004`).

---

## 8. Mudanças no Código Existente (com referências de arquivo)

### 8.1 Tipos de conta — `account_type.ex`
- Adicionar macro `escrow` (próximo inteiro livre, ex.: `5`) em `Monetarie.UseCases.Model.Relational.AccountType`.
- Atualizar quem itera kinds (ex.: `UserAccounts.count_by_kind/1`, setup/replay TigerBeetle).

### 8.2 Mapeamento de tipo — `account_kind.ex`
- Adicionar entrada `"escrow" => escrow()` no `@mapping`.
- **Não** expor `"escrow"` em `partner_account_types/0` por padrão sem gating (criação de escrow deve passar pelo fluxo de `escrow_agreement`, não pela criação genérica de conta de cliente).

### 8.3 Contrapartida contábil — `accounting_bridge.ex`
- Adicionar constante `@deposito_vinculado_code "4.1.1.85.00.00.001"` (normalizar ao formato canônico interno usado em `cosif_contas`; confirmar o código exato seeded — o display é `4.1.1.85.00-1`).
- Estender `@mapped_categories` com `escrow_deposit`, `escrow_release`, `escrow_refund`, `escrow_fee`.
- Adicionar cláusulas em `resolve_debit_credit/2`:
  - `escrow_deposit` → D: disponibilidade/CP origem · C: `@deposito_vinculado_code`
  - `escrow_release` → D: `@deposito_vinculado_code` · C: conta do beneficiário/saída
  - `escrow_refund`  → D: `@deposito_vinculado_code` · C: conta do depositante/saída
  - `escrow_fee`     → D: CP depositante · C: `@receita_tarifas_code` (já existe `7.1.7.x`)
- Garantir seed da conta `4.1.1.85.00-1` no `cosif_contas` (migração de plano de contas).

### 8.4 Domínio de escrow — novo módulo
- Criar `core/backend/lib/monetarie/use_cases/escrow/` com:
  - `agreements.ex` (CRUD + máquina de estados)
  - `parties.ex` (KYC dual)
  - `conditions.ex` (verificação)
  - `releases.ex` (tranches + maker-checker + execução TigerBeetle + COSIF)
  - `state_machine.ex` (transições válidas)
- **Reusar** `transaction.ex` apenas como camada de execução TigerBeetle (hold/release), mas **encapsular** atrás do domínio contratual. **Remover/ignorar** os aliases deprecados `bet/win/loss`.

### 8.5 Eventos — NATS
- Publicar `escrow.agreement.created`, `escrow.deposit.received`, `escrow.condition.met`, `escrow.release.executed`, `escrow.closed`.
- Liberações que envolvam saída por PIX/TED → publicar evento que a cabine PIX/SPB consome (Core não assina).

---

## 9. APIs

### 9.1 API de Cliente (banking/merchant)
```
POST   /api/v1/escrow/agreements            # cria contrato (rascunho)
GET    /api/v1/escrow/agreements/:id        # detalhe + saldo + condições
GET    /api/v1/escrow/agreements/:id/statement
POST   /api/v1/escrow/agreements/:id/deposit-intent   # gera instrução de depósito (PIX/TED)
GET    /api/v1/escrow/agreements/:id/releases
```

### 9.2 API/Painel Admin (gestão)
```
GET    /api/v1/admin/escrow/agreements            # lista + filtros (status, parte, vigência)
POST   /api/v1/admin/escrow/agreements/:id/activate
PATCH  /api/v1/admin/escrow/conditions/:id        # atestar condição (met/failed) + evidência
POST   /api/v1/admin/escrow/releases              # solicitar liberação (maker)
POST   /api/v1/admin/escrow/releases/:id/approve  # aprovar (checker) → executa TB + COSIF
POST   /api/v1/admin/escrow/agreements/:id/close
```

### 9.3 Painel de Gestão — itens de controle (UI admin)
Saldo atual · Extrato (depósitos/aplicações/liberações/devoluções) · Status de cada condição · Prazo de vigência · Beneficiários por tranche · Instruções de liberação com documentação · Histórico de notificações · Status KYC de cada parte · Alertas PLD/FT · Relatórios (DRE da conta, extrato, condições) · Aplicação dos recursos (se houver).

---

## 10. Regras de Negócio (invariantes a testar)

1. **Anti-bolsão:** não existe `escrow_account` sem `escrow_agreement` com `purpose` preenchido e vínculo a negócio.
2. **Soma sempre fecha:** Σ depósitos = Σ liberações + Σ devoluções + saldo atual (reconciliar TigerBeetle ↔ COSIF).
3. **Liberação gated:** `escrow_release` só vai a `:executed` se (a) condições vinculadas `:met` e (b) KYC do destinatário `:approved`.
4. **Maker-checker:** `requested_by ≠ approved_by` (segregação de funções).
5. **Sem garantia:** a Monetarie nunca cobre déficit; liberação ≤ saldo disponível na conta escrow.
6. **Partida dobrada:** todo movimento gera exatamente um par D/C COSIF (idempotente por `tb_transfer_id`).
7. **Segregação de ledger:** recursos escrow vivem no ledger `1_004`, nunca misturados ao operacional `1_000`.
8. **Core não assina:** saídas BACEN passam pelas cabines PIX/SPB.

---

## 11. Plano de Entrega (PRs incrementais para Claude/Codex)

> Cada PR deve compilar, passar testes e não habilitar o produto em prod até o PR final. Usar `ESCROW_ENABLED=false` por padrão.

| PR | Escopo | Critério de aceite |
|---|---|---|
| **PR1 — Contabilidade** | Seed COSIF `4.1.1.85.00-1`; novas categorias e cláusulas D/C no `accounting_bridge.ex`; testes de mapeamento | Lançamentos escrow geram par D/C correto; balancete fecha |
| **PR2 — Domínio** | Migrations (§7); módulos `escrow/` (agreements, parties, conditions, releases, state_machine); sem API | Máquina de estados validada; invariantes §10.1–§10.4 com testes |
| **PR3 — Execução financeira** | Integração com `transaction.ex`/TigerBeetle no ledger `1_004`; geração de COSIF via `AccountingBridge`; reconciliação | Σ fecha (TB↔COSIF); idempotência por `tb_transfer_id` |
| **PR4 — KYC dual + PLD/FT** | Gating de liberação por KYC; flags de risco; hooks de monitoramento/COAF | Liberação bloqueada sem KYC; alerta ≥ R$ 50 mil |
| **PR5 — APIs** | Endpoints cliente + admin (§9.1, §9.2); RBAC; maker-checker | Contratos de API testados (e2e) |
| **PR6 — Painel admin** | UI de gestão (§9.3) no front admin (`core/apps/admin`) | Telas com screenshot estrito (regra #11 do `CLAUDE.md`) |
| **PR7 — Eventos + cabines** | Publicação NATS; consumo PIX/SPB para saídas | Saída PIX/TED roteada às cabines; Core não assina |
| **PR8 — Go-live gating** | `ESCROW_ENABLED`; checklist regulatório §1.3; documentação operador | Produto só liga com pré-condições §1.3 satisfeitas |

---

## 12. Riscos e Pontos de Atenção

| Risco | Mitigação |
|---|---|
| Escrow caracterizado como **captação de depósito** (vedado à SCD) | Modelar como Moeda Eletrônica (A) ou acessório a crédito (B); parecer jurídico; consulta ao BCB |
| Conta escrow vista como **conta-bolsão** (Res. 5.261/2025) | `purpose` obrigatório + vínculo a negócio + retenção 10 anos |
| SCD tratada como **garantidora** (vedado — Comunicado 41.321/2024) | Contrato deixa explícito: Monetarie é custodiante/administradora, nunca garante |
| Mistura contábil com depósitos comuns | COSIF `4.1.1.85.00-1` segregado + ledger TB `1_004` dedicado |
| Reuso indevido do `transaction.ex` (aliases `bet/win/loss`) | Encapsular atrás do domínio contratual; remover semântica de aposta |
| Saída BACEN assinada pelo Core | Roteamento obrigatório às cabines PIX/SPB (regra #13) |
| Ausência de FGC nas contas de ME/escrow | Comunicar claramente ao cliente; não prometer garantia |

---

## Anexo A — Mapa Regulatório (resumo)

| Norma | Relevância |
|---|---|
| Res. CMN 5.050/2022 (+ 5.159/2024) | Marco da SCD; rol taxativo; vedação de captação |
| Comunicado BCB 41.321/2024 | SCD não presta garantias |
| Res. CMN 4.753/2019 | Abertura/manutenção/encerramento de conta de depósitos |
| Res. CMN 5.261/2025 + Res. BCB 518/2025 | Anti-conta-bolsão (vínculo específico ao negócio) |
| Res. BCB 96/2021 | Contas de pagamento (modelagem A) |
| Circular BCB 2.535/1995 | COSIF DEPÓSITOS VINCULADOS `4.1.1.85.00-1` |
| Res. CMN 4.858/2020 + Res. BCB 92/2021 | Padrão COSIF aplicável à SCD |
| Circular BCB 3.978/2020 + Res. BCB 44/2020 | PLD/FT e AIR |
| Lei 9.613/1998 | Antilavagem; COAF |
| Lei 14.711/2023 + Provimento CNJ 197/2025 | Marco das Garantias; conta notarial (referência de mercado) |
| Lei 10.931/2004 / Lei 4.591/64 | Patrimônio de afetação (caso imobiliário) |
| Lei 13.476/2017 | Garantia guarda-chuva (caso crédito) |
| LC 105/2001 | Sigilo bancário |
| Código Civil arts. 425, 627-652 | Base civil do contrato atípico de depósito |

> Pesquisa completa com URLs verificáveis: `research/escrow_legal_research.md`.

---

## Anexo B — Prompt-base para Claude/Codex

> Cole no início de cada sessão de implementação:

```
Você vai implementar o produto Conta Escrow na plataforma Monetarie (SCD), monorepo Elixir/Phoenix + TigerBeetle + COSIF.
Leia primeiro: docs/plans/2026-06-28-conta-escrow-implementacao.md (este guia) e CLAUDE.md (regras absolutas).
Restrições inegociáveis:
- A Monetarie é SCD: NÃO capta depósito à vista; escrow = DEPÓSITOS VINCULADOS (COSIF 4.1.1.85.00-1), ledger TigerBeetle 1_004.
- Toda conta escrow exige um escrow_agreement com purpose (anti-conta-bolsão).
- Liberação só com condição :met E KYC do destinatário :approved; maker-checker obrigatório.
- O Core NUNCA assina mensagens BACEN; saídas PIX/TED vão para as cabines PIX/SPB via NATS.
- Todo movimento gera 1 par D/C COSIF via AccountingBridge, idempotente por tb_transfer_id.
- Produto fica atrás de ESCROW_ENABLED=false até o checklist regulatório (§1.3) ser satisfeito.
Entregue o PR indicado no plano (§11), com testes e sem habilitar o produto em produção.
```