Safeguarding na Prática: Arquitetura de Contas de Dinheiro Eletrônico para Licenciamento EMI

---

O Artigo 10 da EMD2 requer que instituições de dinheiro eletrônico salvaguardem os fundos recebidos em troca de dinheiro eletrônico. Os fundos devem ser colocados em uma conta segregada em uma instituição de crédito, ou investidos em ativos seguros de baixo risco, até o final do próximo dia útil. Em qualquer momento, a instituição deve poder demonstrar que os fundos dos clientes estão completamente cobertos.

Safeguarding é uma arquitetura de contas, não um requisito de reporting adicionado a infraestrutura existente. O ledger deve estruturalmente prevenir a mistura, combinar fundos de clientes com os próprios fundos da instituição, através de tipos de conta separados, isolamento imposto e visibilidade em tempo real do saldo de safeguarding.

Reguladores não aceitam "reconciliamos mensalmente e sempre fecha." Eles requerem que a arquitetura previna a mistura por construção. A diferença importa durante os exames.

A Arquitetura de Contas

Um ledger compatível com safeguarding distingue quatro categorias de contas:

A equação fundamental:

Soma(saldos e-money de clientes) ≤ Soma(saldos de contas safeguarding) + Soma(saldos float)

Em todo momento. Não no fechamento do mês. Não após a reconciliação. No momento em que o regulador perguntar.

Quando um cliente deposita EUR 100:

DEBIT  safeguarding:eur     100,00    (ativo aumenta, banco recebeu o dinheiro)
CREDIT customer:alice:eur    100,00    (passivo aumenta, devemos a Alice EUR 100)

Ambos os lados do lançamento mantêm a equação. O saldo de safeguarding aumenta pelo mesmo valor que o passivo com o cliente. Se um lado é registrado sem o outro, um bug, um crash no meio da transação, um webhook falho, a partida dobrada rejeita o lançamento incompleto. A equação é mantida pela própria invariante do ledger, não por disciplina de aplicação.

Prevenção de Mistura

A mistura é o pecado capital da regulação de dinheiro eletrônico. Significa: a instituição usou fundos de clientes para seus próprios fins. Mesmo temporariamente. Mesmo por acidente.

Três mecanismos arquitetônicos a previnem:

1. Flags de tipo de conta no ledger.

Cada conta carrega um tipo: customer_emoney, safeguarding, fee_revenue, operating, float. O tipo é definido na criação da conta e é imutável. Não é um rótulo, é uma restrição que afeta quais transferências são permitidas.

2. Regras de transferência impostas pela camada de domínio.

Uma transferência de uma conta safeguarding para uma conta operacional é bloqueada por padrão. O único caminho permitido para fundos se moverem de safeguarding para operacional é através de um workflow explícito de extração de comissões: o cliente é cobrado uma comissão (reduzindo seu saldo de e-money), e o valor da comissão é transferido de safeguarding para operacional. Este workflow é journalizado, auditado e requer autorização explícita na camada de orquestração.

A sequência para uma comissão mensal de EUR 2,00:

Passo 1: DEBIT  customer:alice:eur    2,00    (passivo diminui, Alice deve menos)
         CREDIT platform:fees:eur     2,00    (receita aumenta, comissão ganha)

Passo 2: DEBIT  safeguarding:eur      2,00    (ativo diminui, fundos liberados)
         CREDIT operating:eur         2,00    (patrimônio aumenta, fundos próprios da instituição)

Ambos os passos são parte de um único workflow durável. Se o passo 1 tem sucesso e o passo 2 falha, o motor de workflows retenta o passo 2 a partir do journal. O saldo de safeguarding nunca fica dessincronizado com o saldo do cliente, porque os dois movimentos são acoplados em um único workflow, não dispersos entre processos independentes.

3. Verificação de saldo de safeguarding em tempo real.

O sistema pode gerar um relatório de safeguarding a qualquer momento:

Total e-money de clientes:    EUR 1.247.891,23
Saldo safeguarding:           EUR 1.198.442,00
Float (settlement pendente):  EUR   52.100,00
Cobertura:                    EUR 1.250.542,00
Excedente:                    EUR     2.650,77   (>0 = conforme)

Se o excedente é negativo, a instituição tem safeguarding insuficiente. O sistema levanta um alerta. A equipe de operações tem minutos, não dias, para investigar e corrigir.

Float e Timing de Settlement

Entre a iniciação do pagamento e o settlement, os fundos estão em trânsito. Um cliente recebe um débito direto SEPA: o banco do credor enviou a cobrança, mas o banco do devedor ainda não liquidou. Os fundos são creditados à conta de e-money do cliente (passivo aumenta), mas o correspondente aumento de ativo depende do ciclo de settlement.

Durante esta janela, a equação de safeguarding inclui float:

Saldo do cliente:        EUR 100,00    (cliente vê EUR 100)
Safeguarding:            EUR   0,00    (banco ainda não recebeu os fundos)
Float (SDD pendente):    EUR 100,00    (settlement esperado em D+5)
Cobertura:               EUR 100,00    (float conta para a cobertura)

O modelo de período de retenção rastreia isso com precisão. Fundos em estado SETTLED_PENDING são contados como float, cobertos para fins de safeguarding mas ainda não disponíveis para o cliente. Após o período de retenção expirar e os fundos passarem para SETTLED_AVAILABLE, eles se movem de float para safeguarding (o banco confirma o recebimento).

Se um return ocorre durante o período de retenção (R-transaction), o float é reduzido e o saldo de e-money do cliente é revertido. A equação de safeguarding se reequilibra automaticamente porque ambos os lados se movem juntos.

Requisitos de Reporting

O licenciamento EMI impõe obrigações específicas de reporting. A arquitetura deve produzir estes relatórios a partir do ledger, não de um banco de dados de reporting separado, não de um pipeline ETL, e não de uma planilha.

Os dados para cada relatório vêm da mesma fonte: o ledger imutável de partida dobrada. O e-money pendente de clientes é a soma de todos os saldos de contas customer_emoney (saldo normal crédito). A cobertura de safeguarding é a soma de todos os saldos de contas safeguarding (saldo normal débito) mais saldos float. O relatório é uma consulta, não uma construção.

Esta é a vantagem de construir sobre partida dobrada desde o dia um. O balanço patrimonial é uma propriedade do ledger, não um artefato derivado. A equação de safeguarding é um subconjunto da equação contábil (Ativos = Passivos + Patrimônio). É verificada toda vez que qualquer transferência é registrada, porque cada transferência deve equilibrar.

Erros Comuns de Safeguarding

Três padrões que criam risco de safeguarding:

1. Contas bancárias compartilhadas. A instituição usa uma conta bancária tanto para fundos de clientes quanto para fundos operacionais, confiando na contabilidade interna para rastrear a divisão. Se o banco congela a conta (por qualquer razão, investigação AML, disputa, insolvência do banco), todos os fundos são congelados, incluindo fundos de clientes. EMD2 requer segregação física: uma conta bancária dedicada para safeguarding, separada da conta operacional.

2. Falta de rastreamento de float. Saldos de clientes incluem settlements pendentes (o cliente vê o crédito), mas o saldo de safeguarding não inclui o float correspondente. O relatório de safeguarding mostra um déficit que realmente não existe, ou pior, um excedente que mascara um déficit real porque o float é contado duas vezes.

3. Extração de comissões sem acoplamento de workflow. Comissões são deduzidas de saldos de clientes (reduzindo passivo) mas o movimento correspondente de safeguarding para operacional acontece em um processo separado e assíncrono. Se o processo assíncrono falha ou atrasa, a conta de safeguarding temporariamente mantém mais do que deveria, o que é tecnicamente conforme mas operacionalmente confuso, ou mantém menos do que deveria se o timing é invertido.

Cada um destes é evitável através de arquitetura. Contas bancárias separadas. Tipos de conta float explícitos. Workflows duráveis que acoplam os dois lados de uma extração de comissões. Os padrões não são complexos. Devem ser deliberados.

---

Leia mais: O Ledger | Segurança e Compliance

---

Fontes:

• EMD2, Diretiva 2009/110/CE, Art. 7 (Requisitos de safeguarding), Art. 10 (Proteção de fundos)
• PSD3/EMD3, COM/2023/366 (proposta de fusão de PSD2 e EMD2)
• Ley 21/2011 (Espanha), Art. 8-10 (safeguarding para EMIs espanhóis)
• BaFin: Guia sobre requisitos de safeguarding para instituições de dinheiro eletrônico
• HGB §246, Proibição de compensação (Verrechnungsverbot), ativos de clientes não devem ser compensados contra passivos da instituição