Pagamentos10 min de leitura

ISO 20022 e a Nova Interseção do Dinheiro: O Que a Convergência TradFi-DeFi Significa para a Orquestração de Pagamentos

A convergência TradFi-DeFi se rompe na camada de settlement, não na camada de dados. As transferências de crédito SEPA se liquidam por meio de compensação líquida diferida com finalidade T+1 confirmada por um mecanismo de compensação e settlement. As transações on-chain se liquidam por meio de settlement bruto atômico com finalidade determinada pela profundidade de confirmação de bloco. Não são apenas velocidades diferentes. São pressupostos diferentes sobre finalidade, reversibilidade e recuperação que uma camada de orquestração de pagamentos deve resolver explicitamente antes de poder lidar com qualquer modelo corretamente.

A ISO 20022 fornece uma linguagem de dados comum para ambos os mundos. A estrutura de mensagem que transporta uma transferência de crédito SEPA pacs.008 pode, com extensões, transportar uma instrução de transferência on-chain. A taxonomia BankTransactionCode classifica tipos de pagamento tradicionais; o padrão está sendo estendido para cobrir movimentações de ativos tokenizados. O formato de dados é um problema resolvido. O modelo de orquestração não é.

Dois Modelos de Settlement, Dois Pressupostos de Finalidade

A compensação líquida diferida funciona acumulando obrigações compensatórias entre participantes ao longo do dia e compensando-as em janelas de compensação definidas. Um pacs.008 enviado às 09:00 pode não liquidar até o ciclo de compensação das 14:00. Durante essa janela, o pagamento é uma reivindicação, não uma transferência liquidada. A reivindicação pode ser rejeitada (reconhecimento negativo pacs.002), cancelada (solicitação de cancelamento camt.056) ou devolvida após o settlement (pacs.004 transação R). A finalidade é irrevogável somente após o fechamento da janela de compensação.

A camada de orquestração deve rastrear este ciclo de vida. Um pagamento que foi enviado mas não liquidado está em um estado intermediário conhecido: ENVIADO_A_COMPENSACAO. Um pagamento que foi liquidado é LIQUIDADO. Um pagamento que foi devolvido é DEVOLVIDO. O ledger deve tratar esses estados de forma distinta: não marcar o débito como final até que o settlement seja confirmado, porque a janela de transações R ainda está aberta.

O settlement on-chain é atômico e final ao confirmar-se. Quando uma transação é incluída em um bloco confirmado em uma cadeia determinística, está liquidada. Não há intermediário. Não há janela de compensação. Não há mecanismo para revertê-la por meio de um processo estruturado de transações R. Somente o originador pode iniciar uma nova transação compensatória, que aparece no ledger como uma entrada separada, não como uma reversão da original.

O pressuposto de finalidade é diferente em tipo, não em grau. A finalidade de settlement TradFi é um constructo legal: o acordo de compensação, as regras do esquema de pagamento e a regulamentação aplicável (PSD2 Art. 80-81 sobre finalidade de settlement) definem quando um pagamento é irrevogável. A finalidade de settlement on-chain é um constructo matemático: é a probabilidade de que o bloco que contém a transação seja reorganizado fora da cadeia canônica. Para fins práticos, a finalidade é alcançada após um número definido de confirmações de bloco, mas esse número varia de acordo com a cadeia, o tempo de bloco e o apetite de risco da instituição.

Onde a Camada de Orquestração Deve Adaptar-se

Uma camada de orquestração de pagamentos projetada exclusivamente para SEPA tem cinco pressupostos integrados: settlement é por lotes, a finalidade vem de uma rede de compensação, as transações R são o mecanismo de reversão, os prazos são medidos em horas, e a identificação da contraparte é via IBAN. Cada pressuposto se rompe para o settlement on-chain.

Lotes vs. atomicidade. O envio por lotes de SEPA requer recolher transferências, construir uma mensagem em massa pacs.008 e submetê-la dentro da janela de compensação. O envio on-chain requer assinar uma transação e transmiti-la. A camada de orquestração deve distinguir entre esses modelos de envio por tipo de instrumento. Um único framework de orquestração que trate todos os envios de pagamento como envios por lotes baseados em fila introduzirá latência desnecessária para transferências on-chain e gestão incorreta do ciclo de vida para transferências SEPA.

Confirmação de finalidade. Para SEPA, a confirmação de finalidade chega como uma notificação de crédito camt.054 ou um reconhecimento positivo pacs.002 da rede de compensação. Para transferências on-chain, a confirmação de finalidade requer monitorar a cadeia até alcançar a profundidade de bloco alvo. A camada de orquestração deve consultar ou se inscrever no estado da cadeia, um mecanismo que não tem análogo no processamento de SEPA. O modelo de timeout também é diferente: SEPA tem janelas de compensação definidas e mensagens de rejeição explícitas. Uma transação on-chain que não se confirma em um tempo razoável não é rejeitada; continua pendente, potencialmente presa no mempool, e requer intervenção manual ou retransmissão com taxas mais altas.

Mecanismo de reversão. Quando um pagamento SEPA deve ser revertido após o settlement, o mecanismo padrão é pacs.004 (Devolução de Pagamento) ou camt.056 (Solicitação de Cancelamento), ambos resultando em uma transação R estruturada com um código de motivo definido, um prazo definido e um tratamento de ledger definido (entrada de correção segundo HGB §239). Para transferências on-chain, a reversão é uma nova transação: débito do destinatário, crédito do remetente, referência à transação original nos metadados. A reversão não é padronizada, não é classificada automaticamente e não está sujeita a um prazo definido pelo esquema. A camada de orquestração deve lidar com ambos os modelos de reversão com lógica de registro diferente.

Identificação da contraparte. SEPA utiliza IBAN como identificador de conta principal. As transferências on-chain utilizam um endereço criptográfico (hash de chave pública). Uma camada de orquestração que processe ambos deve resolver o modelo de endereço: um endereço blockchain é um identificador de conta de primeira classe armazenado no ledger, ou é uma propriedade do registro CDD de um cliente? A resposta afeta a deduplicação de clientes, o monitoramento de transações e o screening de sanções, todos os quais operam sobre o modelo IBAN e devem ser adaptados para a identificação baseada em endereços.

ISO 20022 como Ponte

A extensibilidade da ISO 20022 a torna a ponte de dados natural entre modelos de settlement. Os tipos de mensagem pacs (pacs.008 para transferências de crédito, pacs.004 para devoluções) já são usados para SEPA. As mesmas estruturas de mensagem, com códigos de instrumento local que identificam o modelo de settlement, podem transportar instruções de transferência on-chain.

A taxonomia BankTransactionCode fornece um framework de classificação. PMNT/RCDT/ESCT identifica uma transferência de crédito SEPA recebida. Um novo código, PMNT/RCDT/TKNZ (transferência de crédito recebida tokenizada) ou equivalente, em desenvolvimento nos grupos de trabalho de extensão da ISO 20022, identificaria uma transferência on-chain recebida usando a mesma estrutura Domínio/Família/Subfamília. O motor AML, o motor de reconciliação e a canalização de relatórios que já consomem BankTransactionCodes podem processar transferências tokenizadas sem um caminho de código separado, uma vez que o conjunto de códigos seja estendido.

Os 27,5 bilhões de dólares em ativos reais tokenizados on-chain no T1 2026, com um aumento de 30% em três meses, representam um volume que nenhuma instituição pode processar manualmente através de workflows separados. A pressão de integrar transferências de token em canalizações de pagamento padrão já está presente. O padrão de dados está pronto. O modelo de orquestração precisa acompanhar.

Semântica de Exactly-Once Através de Modelos de Settlement

A execução exatamente uma vez é mais difícil de garantir quando o pagamento cruza modelos de settlement. Um pagamento híbrido (iniciar on-chain, confirmar off-chain, liquidar o líquido em fiat) cria um workflow de múltiplas etapas onde cada etapa tem um modelo diferente de idempotência e reversão.

Considere: um cliente inicia uma transferência on-chain de EUR 50.000 do seu depósito em euro tokenizado para a conta tokenizada de uma contraparte. A instituição receptora deseja settlement fiat. O workflow:

Débito da conta tokenizada do cliente (on-chain, atômico, irreversível uma vez confirmado)
Enviar uma transferência de crédito fiat para a instituição da contraparte (SEPA, por lotes, reversível via transação R)
Receber confirmação de settlement da rede de compensação
Acreditar a conta fiat da contraparte

Se a etapa 2 falha após a etapa 1 fazer commit, a compensação não é uma reversão da etapa 1. É um novo crédito on-chain para devolver os fundos. Se a etapa 3 falha após a etapa 2 ser enviada, a camada de orquestração deve esperar a confirmação de settlement ou uma transação R, então acreditar ou debitar em consequência. O modelo de compensação requer rastrear o estado de settlement de ambas as pernas de forma independente.

Um motor de execução durável registra cada etapa antes da execução. Se o motor falha entre a etapa 1 e a etapa 2, reproduz o journal ao reiniciar e retoma na etapa 2. Se a etapa 2 produz uma transação R (o pagamento SEPA é devolvido), o motor executa o handler de compensação: um novo crédito on-chain ao originador, registrado como uma entrada de correção no ledger. A sequência completa, ambas as pernas, o erro e a compensação, existe em um journal com uma ID de correlação.

Compromissos

A orquestração de pagamentos de modelo dual introduz uma complexidade operacional que os sistemas puramente focados em SEPA evitam.

Multiplicação de modos de falha. Cada modelo de settlement tem seus próprios modos de falha. Um sistema que lida com ambos deve lidar com ambos os conjuntos: transações R de SEPA, interrupções de redes de compensação e falhas de envio por lotes de um lado; congestão de mempool, risco de reorganização, problemas de conectividade de nós e falhas de resolução de endereços do outro. A equipe de operações deve ser treinada e equipada para ambos.

Assimetria de latência. O settlement on-chain para alguns instrumentos leva segundos. O settlement SEPA leva horas. Um sistema que apresenta ambos como "pagamento" deve tornar explícita a diferença de latência aos clientes e aos sistemas posteriores que dependem da confirmação de settlement. Tratar o settlement on-chain como um análogo SEPA rápido, usando o mesmo tempo de settlement esperado em sistemas posteriores, produzirá relatórios incorretos e cálculos de capital incorretos.

Classificação regulatória. A classificação legal de uma transferência on-chain difere de uma transferência SEPA de maneiras que afetam o tratamento regulatório aplicável. Sob MiCAR, as transferências de EMTs carregam obrigações AML específicas. Sob PSD2, as transferências fiat carregam obrigações diferentes. Um pagamento que cruza modelos (fiat dentro, token fora, ou token dentro, fiat fora) deve ser classificado corretamente para cada perna de forma independente. A canalização de compliance deve lidar com a classificação regulatória composta, não uma única categoria por transação.

Fernel Context

A orquestração de pagamentos da Fernel utiliza modelos de mensagens nativos ISO 20022 para tipos de pagamento SEPA, com BankTransactionCodes armazenados nativamente em vez de traduzidos para códigos proprietários. O motor de execução durável registra cada passo do workflow de pagamento, incluindo os estados do ciclo de vida de settlement ENVIADO_A_COMPENSACAO, LIQUIDADO_PENDENTE e LIQUIDADO_DISPONIVEL, antes da execução. Estender o mesmo modelo de orquestração para cobrir o settlement on-chain requer adicionar um novo adaptador de settlement (monitoramento de cadeia, resolução de endereços, rastreamento de confirmações) sem modificar o motor de workflow ou o ledger. O modelo de journal é agnóstico ao modelo de settlement por design: cada passo leva seu próprio registro de entrada/saída independentemente de se a operação subjacente é um envio SEPA ou uma transmissão de cadeia.

Fontes:

Money20/20 Europe 2026, The New Intersection of Money: Where TradFi and DeFi Converge, coautoria de Scarlett Sieber et al.
Cambridge Centre for Alternative Finance, Tokenized RWA T1 2026: 27,5 bilhões de dólares on-chain, +30% em 3 meses
ISO 20022 pacs.008.001.11 (Credit Transfer), pacs.004.001.11 (Payment Return): especificações de estrutura de mensagens
ISO 20022 BankTransactionCode External Code Sets, taxonomia Domínio/Família/Subfamília
PSD2, Diretiva 2015/2366, Art. 80-81 (Finalidade de settlement e irrevogabilidade)
MiCAR, Regulamento (UE) 2023/1114, Art. 83 (Obrigações AML para instrumentos de transferência tokenizados)
EPC SCT Inst Rulebook (v2024.1): modelo de settlement e tempos de SEPA Instant Credit Transfer