Entendendo as R-Transactions SEPA: Guia Técnico para Engenheiros de Pagamentos

---

"O pagamento foi devolvido." No SEPA, essa frase pode significar quatro coisas diferentes. Cada uma tem um gatilho diferente, um prazo PSD2 diferente, um ciclo de vida de settlement diferente e um tratamento diferente no ledger. A maioria das implementações as trata como um único evento de "reversão" com um código de razão anexado. Isso leva a gestão incorreta de períodos de retenção, prazos PSD2 perdidos e discrepâncias de reconciliação que aparecem semanas depois do fato.

As R-transactions SEPA não são um conceito. São quatro.

Quatro Tipos, Não Um

A distinção não é acadêmica. Determina o que o sistema deve fazer com o dinheiro, quando deve fazê-lo e como o lançamento do ledger se parece.

Um Reject é silencioso da perspectiva do beneficiário. O pagamento nunca foi liquidado. O banco do devedor o rejeitou pré-settlement (IBAN incorreto, conta encerrada, conta bloqueada). O sistema do beneficiário pode nem precisar saber, a menos que estivesse rastreando o pagamento recebido esperado.

Um Return é uma reversão dentro do período de retenção. O dinheiro foi liquidado (creditado na conta do beneficiário no sistema de clearing), mas durante o período de retenção o banco do devedor envia um return. O ledger do beneficiário deve reverter o crédito. Os fundos passam de SETTLED_PENDING de volta ao devedor.

Um Refund ocorre após o período de retenção ter expirado e os fundos estão SETTLED_AVAILABLE. O beneficiário tem o dinheiro. O devedor disputa, dentro de 8 semanas para SEPA Core Direct Debit (PSD2 Art. 76), sem direito de disputa para B2B. Um refund não é uma reversão do lançamento original. É um novo débito separado contra o beneficiário. O lançamento original permanece no ledger, inalterado e imutável.

Um Reversal é iniciado pelo originador (não o banco do devedor) via uma solicitação de cancelamento camt.056. Isso tipicamente ocorre quando o originador descobre um duplicado ou um erro após o settlement. Na contabilidade alemã, isso é uma Stornobuchung, um lançamento de correção que referencia o original via uma foreign key correction_of. O lançamento original permanece. O lançamento de correção carrega o mesmo valor com sinal oposto.

Períodos de Retenção e Ciclo de Vida de Settlement

Entre o settlement e a disponibilidade, os fundos passam por um período de retenção. A duração depende do esquema:

"Dias úteis" não são "dias corridos." TARGET2 tem seu próprio calendário de feriados: fins de semana, Ano Novo, Sexta-feira Santa, Segunda de Páscoa, 1 de maio, Natal, 26 de dezembro. Feriados nacionais alemães que não são feriados TARGET2 não contam. Feriados nacionais espanhóis que não são feriados TARGET2 não contam. O cálculo de dias úteis deve usar o calendário TARGET2, não um calendário nacional.

Durante o período de retenção, os fundos estão em estado SETTLED_PENDING. O saldo do beneficiário mostra o crédito, mas os fundos não estão disponíveis para saque ou transferência posterior. Após o período de retenção expirar, os fundos passam para SETTLED_AVAILABLE. Returns não são mais possíveis (mas Refunds sim, para Core DD).

Os Códigos de Razão ISO Dirigem a Lógica

pacs.004 (Payment Return) carrega um campo ReasonCode da enumeração ExternalStatusReason1Code. Isso não é texto livre. É um conjunto fechado definido por ISO 20022 e restringido pelos rulebooks do EPC.

O código de razão determina o tipo de R-transaction. O tipo determina a ação de settlement. A ação determina o prazo PSD2. A cadeia é determinística.

A função de classificação:

classify(reason_code, within_holding_period) → tipo R-transaction

  if pre_settlement(reason_code):     → REJECT
  if within_holding_period:           → RETURN
  if originator_initiated(reason_code): → REVERSAL
  else:                               → REFUND

Quando esta classificação é implementada diretamente sobre o código de razão ISO, sem tabela de mapeamento intermediária, o tratamento é determinístico. Um novo código de razão em uma versão futura do rulebook EPC requer adicionar uma variante de enum. O compilador identifica cada handler que não o cobre.

Arquitetura de Implementação

Três responsabilidades, três serviços. Cada um é dono de uma preocupação.

Serviço de classificação: recebe pacs.004 recebidas, extrai o código de razão, classifica em Reject/Return/Refund/Reversal baseado no código e no estado do período de retenção da transferência original.

Serviço de settlement: baseado no tipo classificado, executa a operação de ledger correta:

• Reject: sem ação de ledger (a transferência original nunca foi liquidada).
• Return: anular o settlement pendente. Transição de SETTLED_PENDING para RETURNED.
• Refund: criar nova transferência de débito contra o beneficiário. O lançamento original não é tocado.
• Reversal: criar lançamento de correção (Stornobuchung) com referência correction_of à transferência original.

Serviço de auditoria: registra cada R-transaction com: tipo, código de razão, referência de transferência original, prazo PSD2 e ID de evento DORA.

A Stornobuchung (Lançamento de Correção)

O direito comercial alemão (HGB §239) requer que correções a lançamentos do ledger sejam registradas como novos lançamentos. Nunca como modificações do original. Nunca como exclusões.

Um Reversal não é DELETE FROM transfers WHERE id = original_id. É:

INSERT INTO transfers (
  debit_account_id,   -- conta de crédito original (direção invertida)
  credit_account_id,  -- conta de débito original (direção invertida)
  amount,             -- mesmo valor que o original
  correction_of,      -- FK → transferência original
  code,               -- código de reversão
  ...
)

O lançamento original permanece no ledger. Imutável. O lançamento de correção o referencia. Um auditor vê ambos: a contabilização original e sua correção, vinculados por foreign key. O saldo do ledger reflete o efeito líquido. A trilha de auditoria mostra o histórico completo.

O Que Dá Errado na Prática

Três erros comuns de implementação:

1. Tratar todas as R-transactions como reversões. Um refund não é uma reversão. Uma reversão reverte o lançamento original (contabilização de correção). Um refund é uma nova reclamação que cria um novo débito. Confundi-los leva a lançamentos de ledger incorretos e cálculos de saldo incorretos.

2. Usar dias corridos para períodos de retenção. Os períodos de retenção SEPA são contados em dias úteis TARGET2. Um pagamento liquidado na quarta antes de um feriado TARGET2 na quinta: o período de retenção não conta a quinta. Usar dias corridos significa liberar fundos cedo demais (risco regulatório) ou tarde demais (custo de liquidez).

3. Ignorar a distinção B2B vs. Core. SEPA Débito Direto B2B tem um período de retenção de 2 dias e sem direito de reembolso (o devedor não tem reclamação sob Art. 76). SEPA Core tem um período de retenção de 5 dias e uma janela de reembolso de 8 semanas. Se o sistema aplica regras Core a transações B2B, retém fundos demais. Se aplica regras B2B a transações Core, retém de menos, e está exposto a returns que não pode cobrir.

---

Leia mais: Payments, Orquestração de Pagamentos | Connectivity, Financial Rails

---

Fontes:

• European Payments Council: EPC016-06 (SEPA Core Direct Debit Rulebook, v2024.1)
• European Payments Council: EPC222-07 (SEPA B2B Direct Debit Rulebook)
• PSD2, Diretiva 2015/2366, Art. 71 (Transações não autorizadas), Art. 76 (Direitos de reembolso para débitos diretos)
• HGB §239, Código Comercial alemão, requisitos para correção de lançamentos contábeis
• Calendário TARGET2 do BCE (https://www.ecb.europa.eu/paym/target/target2/profuse/calendar/html/index.en.html)
• ISO 20022 ExternalStatusReason1Code, enumeração de códigos de razão pacs.004.001.11