SWIFT

Transferências SWIFT e Comunicação com Mensagens MT e MX

A SWIFT (Society for Worldwide Interbank Financial Telecommunication) é uma rede de mensagens segura que permite às instituições financeiras, como os bancos, enviar e receber mensagens normalizadas sobre transações financeiras, como instruções de pagamento e confirmações. A SWIFT não detém contas nem transfere fundos; limita-se a disponibilizar uma plataforma segura e fiável para a troca de informação.

As transferências SWIFT normais utilizam uma série de tipos de mensagem normalizados, designados por mensagens MT (Message Type). Estas mensagens têm formatos e campos predefinidos, o que permite às instituições financeiras compreender e processar facilmente a informação que contêm.

As mensagens MX (ISO 20022) constituem uma norma mais recente de mensagens financeiras, baseada em XML (eXtensible Markup Language). Proporcionam um formato mais rico e mais estruturado, permitindo uma troca de dados mais completa e um processamento direto melhorado. As mensagens MX estão a substituir progressivamente as mensagens MT na rede SWIFT, com o objetivo de assegurar uma melhor interoperabilidade e capacidade de tratamento de dados.

Embora as transferências SWIFT tradicionais tenham constituído a espinha dorsal dos pagamentos internacionais durante décadas, apresentam algumas limitações, designadamente transparência limitada, tempos de processamento mais lentos e dados não estruturados.

Swift 103+ STP (Straight Through Processing)

O Swift 103+ STP era o formato MT legado otimizado para o Processamento Direto (STP, Straight Through Processing); desde o fim do período de coexistência, o seu papel é assumido pela orientação de utilização STP da mensagem pacs.008. O STP permite que todo o processo de pagamento, desde a iniciação até à liquidação final, seja realizado por via eletrónica, sem necessidade de intervenção manual.

Características adicionais:

1. Formato Normalizado: Exige o cumprimento rigoroso de um formato normalizado, reduzindo erros e atrasos.
2. Processamento Automatizado: As transações são processadas automaticamente, o que assegura um tratamento mais rápido e eficiente.
3. Redução da Intervenção Manual: A necessidade de introdução e verificação manuais é minimizada, reduzindo o risco de erros e atrasos.
4. Liquidação Mais Rápida: As operações são liquidadas mais rapidamente do que pelos métodos tradicionais.

Considerações relativas ao STP:

1. Introdução rigorosa de dados: Os dados devem ser introduzidos com rigor, a fim de evitar atrasos ou rejeições.
2. Conformidade com os Requisitos de Formato: Os bancos devem assegurar que os requisitos de formato do 103+ STP são rigorosamente cumpridos.
3. Software e sistemas: Os bancos têm de dispor de software e sistemas adequados para tratar eficazmente o STP

É essencial distinguir entre mensagens e liquidação. A SWIFT transmite mensagens financeiras estruturadas entre instituições, mas não movimenta fundos nem detém saldos. Uma confirmação SWIFT, incluindo uma mensagem pacs.008, só é válida quando corresponde a uma transação efetiva, processada e reconciliada nos sistemas bancários das instituições participantes.

Qualquer documento SWIFT isolado, captura de ecrã ou mensagem apresentada sem verificação institucional não deve ser tratado como prova de liquidação concluída.

Transferências SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

Lançada em 2017, a SWIFT gpi é uma iniciativa concebida para colmatar as limitações das transferências SWIFT tradicionais, melhorando a rapidez, a transparência e a rastreabilidade dos pagamentos transfronteiriços. A SWIFT gpi recorre aos formatos de mensagem MT e MX existentes para melhorar os serviços de pagamento. Entre as principais características da SWIFT gpi contam-se:

• Pagamentos mais rápidos: o gpi simplifica processos e estabelece acordos de nível de serviço (SLA) mais rigorosos entre bancos, o que resulta em tempos de execução mais reduzidos, frequentemente de minutos ou segundos.
• Rastreio de pagamentos: O gpi Tracker permite o acompanhamento das transações em tempo real, melhorando a transparência e reduzindo as investigações manuais.
• Transparência das comissões: Os bancos podem fornecer previamente aos clientes informação sobre as comissões das transações, permitindo uma melhor tomada de decisão.
• Dados mais ricos: o gpi suporta uma troca de informação mais detalhada e estruturada, facilitando uma melhor reconciliação e o cumprimento das obrigações regulamentares.

O SWIFT gpi responde às limitações das transferências SWIFT tradicionais, melhorando os pagamentos transfronteiras com rastreio de ponta a ponta, processamento mais rápido e dados mais completos.

Parâmetros Principais para Participantes Não Aderentes ao SWIFT gpi

Quando um participante não aderente ao SWIFT gpi (por exemplo, um banco ou uma instituição financeira não diretamente inscritos no gpi) envia uma instrução de pagamento a um banco participante no gpi, este pode convertê-la nos formatos de mensagem SWIFT exigidos (pacs.008 para transferências a crédito de clientes, pacs.009 COV para transferências de cobertura e pacs.009 para transferências a crédito entre instituições financeiras). Esta conversão permite o processamento e o acompanhamento na rede gpi, desde que a instrução contenha dados suficientes para preencher os campos obrigatórios e cumprir as regras do gpi, como a rastreabilidade de ponta a ponta.

Os participantes não gpi fornecem normalmente estes parâmetros através de esquemas de pagamento nacionais, APIs ou formatos legados, cabendo ao banco gpi acrescentar os elementos específicos do gpi (por exemplo, gerar um UETR caso não seja fornecido, embora a sua transmissão seja facultativa para as entidades não gpi). Os requisitos exatos podem variar consoante a jurisdição, a moeda e os acordos bilaterais, mas os parâmetros essenciais decorrem das orientações CBPR+ (Cross-Border Payments and Reporting Plus) e das normas ISO 20022. Desde o termo da coexistência, em 22 de novembro de 2025, as instruções de pagamento transfronteiriço são trocadas em formato ISO 20022; as referências a campos MT legados que se seguem são indicadas apenas a título orientativo.
1. Identificação das Partes (Dados do Ordenante e do Beneficiário)
Estes elementos identificam o originador e o beneficiário, assegurando a conformidade com a Recomendação 16 do FATF relativa aos requisitos da regra de viagem.

• Devedor/Cliente ordenante: nome completo, morada estruturada (rua, localidade, código postal, país) e identificação da conta (por exemplo, IBAN ou número de conta). Nas anteriores mensagens MT 103/MT 202 COV, corresponde ao campo 50a; nas mensagens pacs.008/pacs.009, aos elementos <Dbtr> e <DbtrAcct>.
• Credor/Cliente Beneficiário: Nome completo, morada estruturada e identificação da conta. Corresponde ao Campo 59a do anterior MT 103/MT 202 COV; <Cdtr> e <CdtrAcct> em pacs.008/pacs.009.
• Devedor/Credor Final (se aplicável): Caso sejam diferentes das partes principais, inclua os respetivos dados para maior transparência (facultativo, mas recomendado para o acompanhamento gpi). Corresponde a <UltmtDbtr>/<UltmtCdtr> em pacs.008/pacs.009.

Porque é exigido: Permite um encaminhamento rigoroso e verificações regulamentares; dados incompletos podem originar rejeições ou atrasos.

2. Informação sobre Agentes e Encaminhamento
Especifica as instituições financeiras envolvidas na cadeia.

• Banco do Ordenante (Debtor Agent): BIC (Bank Identifier Code) ou outro identificador do banco emissor. Corresponde ao campo 52a da antiga MT 103; <DbtrAgt> em pacs.008/pacs.009.
• Banco do Credor: BIC do banco recetor. Corresponde ao Campo 57a das antigas MT 103/MT 202 COV; <CdtrAgt> em pacs.008/pacs.009.
• Agentes Intermediários (se conhecidos): BIC de quaisquer correspondentes (até 3 níveis). Corresponde ao campo 56a da anterior MT; <IntrmyAgt1-3> em pacs.008/pacs.009.
• Agentes Instrutores/Instruídos: BIC do remetente/destinatário imediato na cadeia. Facultativo, mas útil nos métodos em série ou de cobertura.
• Agentes Ordenantes Anteriores (se aplicável): Em cadeias com vários intervenientes, até 3 agentes anteriores.

Motivo da exigência: Garante o correto encaminhamento através de intermediários; utilizar o BICFI em vez de nomes, para maior precisão em pacs.009 COV.

3. Detalhes da Transação
Elementos financeiros essenciais para a liquidação.

• Montante e Moeda: Montante de liquidação interbancária e código de moeda ISO 4217 (por exemplo, USD, EUR). Corresponde ao Campo 32A das anteriores MT 103/MT 202 COV; <IntrBkSttlmAmt> nas pacs.008/pacs.009.
• Montante Ordenado (se diferente): Montante original antes de deduções.
• Data de Liquidação Interbancária: Data-valor da liquidação. Corresponde a parte do Campo 32A nas MT; <IntrBkSttlmDt> nas pacs.008/pacs.009.
• Método de Liquidação: Indicar se por RTGS (CLRG), cobertura (COVE) ou agente (INDA/INGA). Sem equivalente MT direto, mas implícito.

Motivo da obrigatoriedade: Define a transferência de valor; obrigatório em todos os formatos.

4. Identificadores de Referência e de Rastreio
Para efeitos de rastreabilidade, em especial no gpi.

• Identificação de Ponta a Ponta: Uma referência que liga toda a cadeia (por exemplo, o identificador da fatura ou da transação). <EndToEndId> em pacs.008/pacs.009.
• Identificação da Instrução: referência do remetente (limitada a 16 carateres no MT). Corresponde ao campo 20 do antigo MT; <InstrId> em pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): Um UUID para o rastreio de ponta a ponta. Obrigatório nas mensagens pacs.008/pacs.009 e, nas anteriores MT103/MT202, no campo 121; se um canal de origem não o fornecer, o primeiro banco Swift da cadeia gera-o.
• Identificação da Transação: Referência interna adicional.

Porque é exigido: Permite o acompanhamento e a associação gpi (por exemplo, de pacs.008 a pacs.009 COV); o UETR é fundamental para as confirmações universais.

5. Informação sobre a Finalidade e o Serviço
Classifica o tipo de pagamento.

• Códigos de Finalidade e de Categoria de Finalidade: códigos ISO (por exemplo, SALA para salário) que indicam a natureza da transação. Exigidos em determinados corredores; <Purp> e <CtgyPurp> na pacs.008.
• Código de Nível de Serviço: Identifica o serviço gpi (por exemplo, G001 para uma transferência de crédito de cliente gpi); os bancos que não aderem ao gpi não devem incluir códigos específicos do gpi, salvo acordo em contrário. Corresponde ao Campo 23E nas MT; <SvcLvl> nas pacs.008/pacs.009.
• Código de Instrumento Local: Para esquemas específicos (por exemplo, transferências intragrupo).

Razão da exigência: Assegura a conformidade regulamentar e a prioridade de processamento; cada vez mais obrigatória após a migração para a norma ISO.

6. Remessa e Instruções Adicionais

• Informação de Remessa: Não estruturada (até 140 carateres) ou estruturada (por exemplo, dados da fatura). Corresponde ao campo 70 do anterior MT 103; <RmtInf> em pacs.008/pacs.009.
• Instruções para Agentes: Por exemplo, /REC/ para o destinatário, /ACC/ para a conta, ou instruções telefónicas (PHOB). Corresponde ao Campo 72 da antiga mensagem MT; <InstrForNxtAgt>/<InstrForCdtrAgt> nas mensagens pacs.008/pacs.009.
• Indicadores de Hora de Liquidação: Horas solicitadas (por exemplo, CLSTm para a hora CLS).

Razão da exigência: Fornece contexto e instruções de tratamento; essencial para os métodos de cobertura em pacs.009 COV.

7. Dados Regulamentares e de Conformidade

• Reporte Regulamentar: Códigos ou elementos (por exemplo, número de identificação fiscal, indicador de reporte como CRED/DEB). Corresponde ao Campo 77B nas MT; <RgltryRptg> nas pacs.008/pacs.009.
• Códigos de Motivo de Devolução (se aplicável a devoluções): Por exemplo, AC04 para conta encerrada, em pacs.004 associado às mensagens originais.

Motivo da exigência: Cumpre as obrigações de AML/KYC e de reporte; obrigatório em corredores regulados.

Como boa prática, os participantes não aderentes ao gpi devem estruturar os dados de modo a evitar truncagens durante as conversões de MT para MX e consultar o banco membro do gpi quanto a necessidades específicas. Se o pagamento envolver métodos de cobertura, os dados do cliente subjacente devem ser coincidentes nas várias mensagens (por exemplo, de pacs.008 para pacs.009 COV).

Mensagens de Pagamento no SWIFT gpi

No âmbito do SWIFT gpi (Global Payments Innovation), as mensagens de pagamento originais (por exemplo, pacs.008 para transferências de clientes ou pacs.009 COV para transferências de cobertura) são consideradas imutáveis após o envio. Os bancos recetores não podem alterar diretamente o conteúdo dessas mensagens, uma vez que as mensagens SWIFT foram concebidas para preservar a integridade e a auditabilidade ao longo de toda a cadeia de pagamento. Quaisquer alterações, correções ou cancelamentos são, em vez disso, tratados através de mensagens de seguimento autónomas, de atualizações de estado através do gpi Tracker ou de serviços específicos como o gSRP (gpi Stop and Recall Payment). Deste modo, assegura-se a rastreabilidade de ponta a ponta através da Referência Única de Transação de Ponta a Ponta (UETR).

Os bancos recetores (tipicamente na qualidade de agente do credor ou intermediário) podem, contudo, responder a pedidos de alteração do remetente ou iniciar ações que resultem, efetivamente, em modificações do resultado do pagamento (por exemplo, devoluções ou retenções). Podem igualmente solicitar esclarecimentos ou alterações ao remetente em condições específicas. Estes processos são regidos pelos regulamentos da SWIFT, pelas orientações de prática de mercado (por exemplo, do Payments Market Practice Group – PMPG) e pelos requisitos regulamentares, dando prioridade à automatização, à transparência e à prevenção da fraude.

Condições em que os Bancos Recetores Podem Solicitar ou Facilitar Alterações
Os bancos recetores podem solicitar alterações (por exemplo, correções de dados) ou adotar medidas que impliquem a necessidade de alteração quando o pagamento original não possa ser processado conforme instruído. Tal é, em regra, efetuado através de mensagens de pedido de informação (por exemplo, MT 195/199) ou de respostas a pedidos iniciados pelo banco remetente. As principais condições incluem:

• Erros nos Dados de Pagamento: Se existirem inexatidões, como uma conta de beneficiário incorreta (por exemplo, conta encerrada – código AC04), uma moeda errada (código CURR), um encaminhamento incorreto do agente (código AGNT) ou problemas técnicos (código TECH), o banco recetor pode reter o pagamento e solicitar ao ordenante que forneça dados corrigidos ou emita um novo pagamento. Evita-se assim a rejeição definitiva, permitindo a resolução da situação.
• Impossibilidade de Creditar o Pagamento: Nos termos do código CUTA (Cancel Upon Unable to Apply), se o pagamento não puder ser creditado devido a divergências (por exemplo, entre o nome e a conta) ou à insuficiência de dados, o banco recetor pode solicitar ao banco remetente o cancelamento do pagamento ou os dados necessários à sua alteração, a fim de regularizar a situação.
• Suspeita de Fraude ou Operações Não Autorizadas: Em caso de fraude (código FRAD), o banco recetor pode detetar autonomamente irregularidades e iniciar a devolução dos fundos sem pedido prévio do ordenante. Pode igualmente responder aos pedidos de devolução (recall) do ordenante, imobilizando os fundos e solicitando uma garantia de indemnização (código INDM) caso os fundos já tenham sido creditados, a fim de mitigar o risco antes da devolução.
• Pagamentos Duplicados ou Indevidos: Códigos como DUPL (pagamento duplicado) ou UPAY (pagamento indevido) permitem ao banco destinatário assinalar e solicitar o cancelamento da transação, caso esta seja errónea ou injustificada.
• Questões Regulamentares ou de Conformidade: Se o pagamento violar leis locais, sanções ou requisitos AML (código LEGL), o banco recetor pode rejeitá-lo ou retê-lo e solicitar ao ordenante documentação adicional ou alterações.
• Decisões do Cliente ou do Beneficiário: Se o beneficiário recusar o pagamento (código CUST ou NOAS – sem resposta do beneficiário), o banco recetor pode devolvê-lo e notificar o banco remetente, podendo solicitar a confirmação de alterações.
• Resoluções Pendentes: Nos casos pendentes (código PDCR), como a aguardar autorização de débito (RQDA) ou resposta do agente seguinte (PTNA), o banco recetor pode reter o pagamento e solicitar instruções adicionais ou alterações para prosseguir.

Em todos os casos, os pedidos devem ser estruturados para processamento automatizado (por exemplo, incluindo o UETR, referências originais como os campos 20/32A/50/59 e códigos específicos no campo 79 das mensagens), de modo a permitir o processamento direto (straight-through processing). Podem ser exigidos acordos de indemnização bilaterais se os fundos forem creditados, não estando o banco recetor obrigado a aceitar os pedidos, mas devendo dar prioridade aos urgentes (por exemplo, relacionados com fraude).

Processos Envolvidos

• Resposta a Pedidos de Revogação Iniciados pelo Banco Remetente: O banco remetente (banco do devedor) inicia tipicamente um pedido de revogação através de MT 192/292 (ou equivalentes ISO 20022, como camt.056) por meio do serviço gSRP, enviado em série ou diretamente ao banco recetor. O banco recetor deve acusar a receção de imediato e responder com MT 196/296 (ou MT 199/299, se estruturada), utilizando códigos como CNCL (cancelado), RJCR (rejeitado com motivo) ou PDCR (pendente). Se aceite, os fundos são devolvidos através de pacs.004 (Devolução de Pagamento).
• Ações Independentes dos Bancos Recetores: Se for detetada fraude internamente, o banco recetor pode devolver os fundos através de pacs.004 com informação estruturada, notificando através do Tracker para atualização do estado em tempo real.
• Pedidos de Alteração/Esclarecimento: Os bancos recetores utilizam mensagens de consulta (por exemplo, MT 195/295) para solicitar alterações, como informações adicionais. Esta situação é comum em pagamentos retidos.
• Integração com o Tracker: Todas as ações atualizam o gpi Tracker em tempo real, acessível através de APIs ou de interface gráfica, assegurando visibilidade a todas as partes. Os membros gpi devem cumprir os regulamentos obrigatórios aplicáveis a gCCT (Customer Credit Transfer), gCOV (Cover) e gSRP.
• Limitações e Fatores de Êxito: As alterações não são garantidas; o êxito depende da fase do pagamento (mais fácil antes do crédito), da cooperação do beneficiário e da jurisdição. Se o crédito já tiver sido efetuado, a devolução requer o consentimento do beneficiário ou uma indemnização. A regulamentação prevalece sempre sobre as orientações.

Estas práticas aplicam-se sobretudo aos membros da gpi, mas os bancos que não pertencem à gpi podem participar através de gateways. Para obter as informações mais atualizadas, consulte os regulamentos oficiais da SWIFT, uma vez que os processos evoluem (por exemplo, com a migração para a ISO 20022).

Separação entre Mensagens e Liquidação no SWIFT gpi

O SWIFT gpi trata essencialmente de instruções de pagamento e do seu seguimento através de mensagens (por exemplo, formatos ISO 20022 como pacs.008 para transferências de clientes, pacs.009 para transferências financeiras, ou as mensagens legadas MT103/MT202), mas o movimento efetivo de fundos ocorre separadamente, ao nível da liquidação. A liquidação processa-se, em regra, através de relações de banca correspondente (contas nostro/vostro), de compensação bilateral ou de Mecanismos de Compensação e Liquidação (CSM), como os sistemas de liquidação por bruto em tempo real (RTGS) (por exemplo, o T2, anteriormente TARGET2, na Europa, o Fedwire nos EUA ou o CHAPS no Reino Unido). O gpi Tracker proporciona visibilidade em tempo real sobre o estado das mensagens, mas a transferência de fundos depende desses sistemas subjacentes.

O período de coexistência para as instruções de pagamento transfronteiriças terminou em 22 de novembro de 2025: as instruções de pagamento como MT103 e MT202 foram substituídas por mensagens ISO 20022 (MX), como pacs.008 e pacs.009, ao passo que as restantes categorias MT serão descontinuadas em datas posteriores. O texto seguinte explica como ocorrem as devoluções e as libertações de retenções ao nível da conta, da compensação e da liquidação.

Como o Dinheiro É Devolvido ao Nível da Conta/Compensação/Liquidação
As devoluções são iniciadas após um pedido de revogação (recall) bem-sucedido (através do gSRP – serviço gpi Stop and Recall Payment) ou após deteção independente (por exemplo, fraude, erros). O gSRP utiliza a mensagem camt.056 (Pedido de Cancelamento de Pagamento) enviada pelo banco remetente, respondida com camt.029 (Resolução de Investigação). Uma vez aceite, a devolução dos fundos é executada através de uma nova instrução de pagamento que inverte o fluxo, debitando a conta do banco recetor e creditando de volta ao longo da cadeia. Não se trata de uma alteração da mensagem original, mas de uma transação distinta.

Principais Métodos de Liquidação e Processos de Devolução
Os métodos de liquidação determinam a forma como as devoluções ocorrem:

• CLRG (Compensação através de Infraestrutura de Mercado): Liquidação através de um RTGS ou de um CSM (por exemplo, por intermédio de um banco central). As devoluções utilizam pacs.004 para instruir a infraestrutura de mercado a debitar a conta do agente recetor e a creditar a do agente anterior, frequentemente em tempo real ou no próprio dia.
• INGA (Instructing Agent Settles First): O ordenante liquida os fundos antes de enviar a mensagem. As devoluções através de pacs.004 debitam a conta do agente instruído após a liquidação.
• INDA (Instructed Agent Settles on Receipt): O recetor liquida na receção da mensagem. Se não liquidar, rejeita através de pacs.002 (sem movimento de fundos); se tiver liquidado, devolve através de pacs.004.
• COVE (Método de Cobertura): Utilizado em pagamentos de valor elevado com transferência de cobertura (pacs.009 COV). As devoluções seguem a cadeia inversa: pacs.004 do agente do beneficiário de volta aos intermediários, debitando e creditando as contas dos correspondentes em conformidade.

Processo de Devolução Passo a Passo ao Nível da Liquidação

1. Iniciação e Aceitação: O ordenante solicita a devolução (por exemplo, através de camt.056 com UETR). O recetor responde (camt.029) e aceita se os fundos estiverem disponíveis/ainda não tiverem sido creditados ao beneficiário (mais fácil antes do crédito). Se já tiverem sido creditados, poderá ser necessário o consentimento do beneficiário ou uma garantia de indemnização.

2. Instrução de devolução de fundos: o destinatário emite uma mensagem pacs.004 (Payment Return) ou, no formato legado, MT 103/MT 202 com códigos de devolução (por exemplo, RETN). Esta mensagem inclui:

• Referências originais (UETR, End-to-End ID, Instruction ID).
• Inversão de papéis: o credor original passa a devedor; o agente do devedor original passa a credor.
• Dados de liquidação: Montante/Data de Liquidação Interbancária Original, Taxa de Câmbio (se envolver operação cambial), Encargos (se deduzidos).
• Código do motivo de devolução (por exemplo, AC04 para conta encerrada, FRAD para fraude).
• Campo Settlement Account (se constar da mensagem original) para indicar a conta a creditar.

3. Execução da Liquidação:

• A mensagem pacs.004 desencadeia o débito na conta nostro/vostro do banco recetor (detida junto do agente anterior ou da MI).
• Os fundos são creditados de volta, salto a salto, ao longo da cadeia, utilizando o mesmo método de liquidação (por exemplo, transferência RTGS no CLRG).
• Em caso de devolução parcial, indicar «PART» em Informação Adicional com o montante proporcional.
• O Tracker atualiza o estado (por exemplo, «Devolvido») em tempo real, visível através de API ou GUI.

4. Crédito Final: A conta do ordenante original é creditada, frequentemente com dedução de comissões. Se a operação for realizada através de um CSM, a liquidação é atómica; em configurações bilaterais, pode envolver a compensação de saldos no final do dia.

5. Notificações Posteriores à Devolução: Utilizar camt.053/054 (Extrato de Conta/Notificação de Débito-Crédito) para confirmar a atualização dos registos contabilísticos. Não há nova mensagem pacs.004 para «devolver uma devolução»: utilizar, em alternativa, pedidos de informação.
As devoluções são automatizadas sempre que possível, mas pode ser necessária intervenção manual por razões de conformidade ou se os fundos estiverem bloqueados. A recuperação não é garantida; depende, acima de tudo, da rapidez com que o pedido de anulação é enviado e de os fundos já terem ou não sido creditados. Se a operação não estiver liquidada (por exemplo, rejeitada antes da liquidação), não há movimento de fundos: utilizar, em alternativa, pacs.002.

Como os Pagamentos Retidos São Libertados (Autorizados) ao Nível da Conta, da Compensação e da Liquidação

As retenções ocorrem quando um pagamento não pode ser processado de imediato (por exemplo, devido a erros, verificações de conformidade ou a aguardar esclarecimentos), ficando num estado «pendente», sem liquidação. Nenhum fundo é debitado ou creditado até à resolução. O gpi Tracker apresenta estados como «On Hold» ou «Pending» (por exemplo, o código PDCR), e a resolução recorre a mensagens de inquérito (MT 195/199 ou camt.029).

Condições que Conduzem a Bloqueios

• Divergências (por exemplo, discrepância entre conta e nome – código CUTA).
• Verificações regulamentares (por exemplo, sanções – código LEGL).
• A aguardar a resposta do beneficiário (código NOAS) ou a autorização de débito (RQDA).
• Horário de inatividade ou processamento em lote no banco do beneficiário.

Processo de Libertação ao Nível da Liquidação
1. Notificação de Retenção: O recetor envia uma pacs.002 (atualização de estado) ou uma MT 199 com código de pendência, retendo os fundos numa conta de suspenso/escrow caso a liquidação seja parcial (por exemplo, nos métodos de cobertura).
2. Resolução: O remetente fornece as alterações/esclarecimentos (por exemplo, através de uma resposta MT 195 ou de uma camt.029). Se a situação ficar resolvida, o recetor dá “luz verde” processando a instrução original.
3. Execução da Liquidação:

• A mensagem original pacs.008/pacs.009 é libertada da retenção.
• Os fundos são liquidados através do método especificado: débito na conta do ordenante, crédito na conta do destinatário (por exemplo, através de RTGS em CLRG) e, por fim, crédito na conta do beneficiário.
• A etapa do beneficiário (do banco recetor ao cliente final) é frequentemente aquela em que ocorrem atrasos, em especial em mercados com controlos de capitais ou infraestruturas limitadas.
• O Tracker é atualizado para «Creditado» ou «Concluído», com a mensagem pacs.002 (Payment Status Report) a confirmar.

4. Se não for libertado: Se a situação não ficar resolvida (por exemplo, após o termo do prazo), devolver através de pacs.004, conforme acima, ou rejeitar com pacs.002 (sem liquidação).

As regras do gpi exigem o crédito no próprio dia, sempre que possível; a Swift divulgou em 2018 que quase 50% dos pagamentos gpi foram creditados em 30 minutos e quase 100% em 24 horas. Fatores como controlos de capitais ou o horário de inatividade dos bancos podem prolongar as retenções, mas o gpi privilegia a automatização para as minimizar.

SwiftNet Instant

SwiftNet Instant. Trata-se de uma plataforma de mensagens em tempo real, de baixa latência, disponível 24 horas por dia, 7 dias por semana, que suporta a troca segura de fluxos de pagamentos instantâneos entre os Mecanismos de Compensação e Liquidação (CSM) e os respetivos participantes.

Os clientes podem ligar-se ao SwiftNet Instant através da sua infraestrutura de conectividade e segurança Swift existente, incluindo caixas VPN, linhas dedicadas e módulos de segurança de hardware. A integração com o ambiente informático do banco é efetuada através do Alliance Gateway Instant (AGI).

Todas as partes ao longo da cadeia de pagamentos instantâneos podem utilizar o AGI e o serviço de mensagens SwiftNet Instant. As aplicações incluem a iniciação de pagamentos a partir de um serviço de sobreposição, as comunicações de membros indiretos com um membro patrocinador, ou a receção, por uma empresa, de uma confirmação de pagamento.

O SWIFT Instant liga-se aos sistemas nacionais de pagamento instantâneo para permitir o processamento de transações em tempo real, tanto a nível nacional como internacional, utilizando a norma ISO 20022. Estes sistemas representam esforços contínuos de modernização e simplificação dos processos de pagamento no setor financeiro.

Débito Direto SWIFT

O débito direto no sistema SWIFT é um método de pagamento que permite a empresas e particulares cobrar fundos de contas bancárias de devedores em várias moedas e em diferentes países. Ao contrário do débito direto SEPA, concebido especificamente para a zona SEPA e limitado a transações denominadas em euros, o débito direto no SWIFT tem âmbito global e suporta uma vasta gama de moedas.

O processo de iniciar uma operação de débito direto no sistema SWIFT envolve normalmente as seguintes etapas:

1. Acordo entre credor e devedor: o credor e o devedor devem ter um acordo prévio, que inclua os termos e condições das operações de débito direto. Este acordo pode também envolver a constituição de um mandato ou autorização, permitindo ao credor cobrar pagamentos na conta bancária do devedor.
2. Troca de mensagens: O banco do credor inicia o débito direto enviando uma mensagem SWIFT ao banco do devedor – em ISO 20022, uma mensagem pacs.003 (débito direto de cliente) ou pacs.010 (débito direto entre instituições financeiras), anteriormente MT 104 ou MT 204. Esta mensagem contém os dados da transação, como o montante, a moeda, os dados da conta do devedor e quaisquer outras informações necessárias.
3. Verificação e autorização: O banco do devedor verifica os dados da transação, confirma a disponibilidade de fundos na conta do devedor e confirma a autorização da transação. Se tudo estiver em ordem, o banco do devedor procede ao débito dos fundos na conta do devedor.
4. Transferência de fundos: os fundos são liquidados entre o banco do devedor e o banco do credor através de contas correspondentes ou de um sistema de compensação e liquidação.
5. Confirmação: Após a receção dos fundos, o banco do credor envia ao credor uma confirmação, notificando-o do êxito da operação de débito direto.

Os pré-requisitos para dar início a uma operação de débito direto no sistema SWIFT são os seguintes:

1. Contas bancárias: Tanto o credor como o devedor devem ser titulares de contas bancárias em instituições financeiras que integrem a rede SWIFT.
2. Acordo e autorização: Tem de existir previamente um acordo e uma autorização (mandato) entre o credor e o devedor para permitir operações de débito direto.
3. Formatos de mensagem SWIFT: O credor e o respetivo banco devem utilizar os formatos de mensagem adequados: pain.008 para iniciar um débito direto, pacs.003 ou pacs.010 entre bancos.
4. Comissões bancárias: O credor e o devedor devem ter em atenção quaisquer comissões associadas às operações de débito direto no sistema SWIFT, as quais podem variar consoante os bancos e os países envolvidos.

RMA nas Mensagens Interbancárias SWIFT

Na banca e nas finanças, é essencial que a comunicação entre bancos seja segura e eficiente. É aqui que a SWIFT (Society for Worldwide Interbank Financial Telecommunication) desempenha um papel determinante, veiculando a maioria das mensagens interbancárias internacionais. Um componente fundamental para garantir a segurança e a seletividade destas comunicações é a Relationship Management Application (RMA).

O que é a RMA?

A Relationship Management Application (RMA) é uma aplicação de software da SWIFT que permite às instituições financeiras definir quais as contrapartes autorizadas a enviar-lhes mensagens SWIFT e assegura que a comunicação na rede SWIFT fica restringida a utilizadores autenticados. A RMA constitui uma camada de segurança fundamental na gestão da comunicação interbancária, uma vez que filtra mensagens não autorizadas e reduz o risco de fraude.

A Importância do RMA

Para os bancos que operam no domínio das finanças internacionais, como o IFB, a ferramenta RMA é indispensável. Reforça não só os protocolos de segurança, como também garante a conformidade com a regulamentação bancária global. Ao gerirem quais as instituições autorizadas a enviar-lhes mensagens, os bancos podem evitar pedidos de informação e instruções financeiras não autorizados, protegendo os seus interesses e os dos seus clientes.

Como Funciona o RMA

O processo RMA compreende várias etapas essenciais:

1. Estabelecimento de Relações RMA: Antes de dois bancos poderem começar a trocar informação através da SWIFT, têm de acordar mutuamente o estabelecimento de um RMA. Este acordo é semelhante a um aperto de mão digital, que traduz confiança e consentimento para comunicar.
2. Troca de chaves: cada banco envia uma autorização RMA através da aplicação RMA, que a contraparte aceita. O RMA substituiu a anterior troca bilateral de chaves (BKE); as próprias mensagens são autenticadas através da SWIFTNet PKI (infraestrutura de chave pública).
3. Configuração das definições RMA: Cada banco utiliza a ferramenta RMA para configurar permissões e especificar os tipos de mensagens aceites do outro banco. Esta configuração pode ser definida de forma ampla ou ajustada com precisão, de modo a incluir tipos de mensagens e subclasses específicos.
4. Ativação e Monitorização: Uma vez configuradas e ativadas as definições RMA, os bancos podem monitorizar as mensagens recebidas quanto à conformidade com as permissões estabelecidas. O RMA disponibiliza igualmente ferramentas para modificar ou revogar permissões, caso as necessidades de negócio ou preocupações de segurança o exijam.

Aplicações Práticas

Para o IFB, que se especializa em investimento e gestão de património para particulares de elevado património líquido e entidades empresariais, o RMA proporciona várias vantagens:

• Segurança Reforçada: Ao controlar o tráfego de mensagens, o IFB pode proteger as transações e a informação sensível dos clientes contra acessos não autorizados.
• Eficiência operacional: A simplificação das comunicações com entidades de confiança assegura um processamento mais rápido das mensagens legítimas, melhorando os tempos de resposta e a satisfação dos clientes.
• Conformidade Regulamentar: A RMA contribui para o cumprimento da regulamentação bancária internacional, que impõe um controlo rigoroso da troca de informações para prevenir crimes financeiros como o branqueamento de capitais e a fraude.

RMA e MT799. Os bancos podem utilizar uma MT799 para solicitar ou coordenar uma relação RMA, desde que o canal o permita. A própria autorização RMA é concedida no sistema RMA; uma MT799, por si só, não ativa qualquer permissão. Quando falta a autorização RMA necessária para a MT799, esta não pode ser contornada enviando diretamente uma MT799. A configuração é, nesse caso, acordada através da funcionalidade de comunicação RMA do Relationship Management Portal da Swift, concebida para a coordenação com as contrapartes antes da troca de autorizações, ou através de outro canal permitido. «RMA por MT799» pode, por conseguinte, designar a correspondência bancária que a acompanha; a autorização técnica RMA constitui uma etapa distinta.

Em síntese

Para o IFB, a implementação eficaz do RMA não é apenas um requisito técnico, mas um ativo estratégico nas suas operações globais. Reforça o compromisso do Banco com a segurança e a conformidade regulamentar, ao mesmo tempo que aumenta a eficiência das suas redes de comunicação. À medida que o panorama das finanças internacionais continua a evoluir, instrumentos como o RMA permanecem essenciais no arsenal dos bancos empenhados em manter os mais elevados padrões de integridade operacional e de serviço ao cliente.

Os RMA constituem a espinha dorsal de uma comunicação interbancária segura e seletiva, assegurando que todas as mensagens trocadas através da rede SWIFT respeitam os mais elevados padrões de segurança e são plenamente autenticadas. Para bancos como o IFB, compreender e gerir os RMA é essencial para salvaguardar as suas operações e criar confiança junto dos seus parceiros globais.

Instruções Financeiras Swift Digital Blockchain

Em setembro de 2025, a Swift anunciou que, juntamente com mais de 30 instituições financeiras, tinha iniciado a conceção e o desenvolvimento de um registo digital partilhado. Em 9 de julho de 2026, a Swift declarou o registo pronto para utilização inicial, com 17 bancos a preparar-se para testar transações reais de depósitos tokenizados: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB e Wells Fargo. A primeira aplicação terá como foco a possibilidade de instruções transfronteiriças em tempo real, 24 horas por dia, 7 dias por semana, entre bancos – um aperfeiçoamento determinante para o tecido do processamento de transações internacionais.

O primeiro protótipo conceptual foi construído com a Consensys. O registo foi concebido como um livro-razão seguro, imutável e em tempo real das instruções financeiras entre instituições. Registará, sequenciará e validará mensagens de transações, aplicando, através de contratos inteligentes, as regras operacionais e de conformidade. A interoperabilidade é um princípio central: o registo ligar-se-á às infraestruturas existentes e emergentes, preservando a resiliência, a confiança e o cumprimento regulamentar que caracterizam a Swift.

Como explicou Javier Pérez-Tasso, Diretor Executivo da Swift:
«A combinação de um registo partilhado com as mensagens, as API e a ISO 20022 já existentes da Swift cria uma construção ainda mais poderosa – que permite incorporar, desde o início, os requisitos de risco, controlo e conformidade nos fluxos de transações, ao mesmo tempo que possibilita instruções interbancárias transfronteiras em tempo real, 24 horas por dia, 7 dias por semana, com a mesma confiança, segurança, resiliência, escalabilidade e excelência operacional pelas quais a Swift é reconhecida. Tudo em linha com a abordagem que sempre adotámos de inovação responsável.»

Extensão da Infraestrutura

O livro-razão partilhado complementa as infraestruturas existentes da Swift; não as substitui. Foi concebido para alargar a orquestração e a interoperabilidade, garantindo que as instituições financeiras possam trocar instruções com maior rapidez, maior previsibilidade e verdadeira escala global.

Na Sibos, Pérez-Tasso sublinhou esta abordagem em duas vias:
“As infraestruturas financeiras têm de manter um foco incansável nos fundamentos da excelência operacional, da conformidade regulamentar e da governação. E, ao mesmo tempo, têm de se preparar para o futuro. Na Swift, a nossa abordagem consiste em inovar em duas vias paralelas.”

Colaboração em Todo o Setor

Instituições financeiras de 16 países participaram desde o início na definição da conceção, da governação e do percurso de desenvolvimento do registo partilhado. Este esforço coletivo traduz um reconhecimento comum: o avanço da infraestrutura global para instruções interbancárias exige escala e colaboração.

Perspetivas Futuras

O livro-razão partilhado constitui uma progressão natural das anteriores experiências da Swift com ativos digitais e faz parte de um compromisso mais amplo com a interoperabilidade entre redes públicas e privadas. Isto permitirá que o valor tokenizado regulado e os instrumentos tradicionais circulem sem dificuldade entre sistemas.

Pérez-Tasso resumiu a visão:
«Esta é uma plataforma poderosa para o futuro. E pode ser ainda mais transformadora no futuro.»

Perguntas Frequentes

O que é o registo partilhado da Swift baseado em blockchain?
Uma infraestrutura blockchain que proporciona um registo partilhado, em tempo real, das instruções financeiras entre instituições, permitindo um processamento transfronteiriço contínuo e em conformidade.

A quem se destina?
Bancos e instituições financeiras que têm de disponibilizar instruções de transação mais rápidas e transparentes, preparando-se simultaneamente para o futuro digital.

Quais são os benefícios?

• Visibilidade em tempo real e sequenciação das instruções
• Conformidade automatizada através de contratos inteligentes
• Interoperabilidade entre redes tradicionais e digitais
• Tratamento seguro de fluxos regulamentados de valor tokenizado

Como se integra na plataforma da Swift?
Alarga a infraestrutura de confiança da Swift, incorporando capacidades de instrução digital e preservando a resiliência, a segurança e a conformidade.

Qual é o primeiro caso de utilização?
Instruções de transações interbancárias transfronteiriças em tempo real, 24 horas por dia, 7 dias por semana.

Quem está envolvido?
Mais de 30 instituições financeiras de 16 países contribuíram para a conceção; 17 bancos estão a testar as primeiras transações reais em regime-piloto.

Quando estará disponível?
A Swift declarou o livro-razão pronto para utilização inicial em 9 de julho de 2026. Os bancos-piloto realizam as primeiras transações em ambiente real numa fase de entrada em produção controlada; a liquidação final continua a ser efetuada através dos sistemas existentes. A funcionalidade e a disponibilidade serão ampliadas posteriormente.

Caso pretenda saber mais sobre a forma de transferir fundos através do sistema de banca correspondente, queira contactar o nosso Diretor de Banca Correspondente, M. Amri Elarisse