SWIFT

Virements SWIFT et communication par messages MT et MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) est un réseau de messagerie sécurisé qui permet aux établissements financiers, tels que les banques, d'envoyer et de recevoir des messages normalisés relatifs à des opérations financières, comme des instructions de paiement et des confirmations. SWIFT ne tient pas de comptes et ne transfère pas de fonds ; il fournit uniquement une plateforme sécurisée et fiable d'échange d'informations.

Les virements SWIFT ordinaires reposent sur une série de types de messages normalisés, dits messages MT (Message Type). Ces messages présentent des formats et des champs prédéfinis, ce qui permet aux établissements financiers de comprendre et de traiter aisément les informations qu'ils contiennent.

Les messages MX (ISO 20022) constituent une norme plus récente de messagerie financière, fondée sur le XML (eXtensible Markup Language). Ils offrent un format plus riche et mieux structuré, permettant un échange de données enrichi et un meilleur traitement de bout en bout. Les messages MX remplacent progressivement les messages MT sur le réseau SWIFT, dans le but d'offrir une meilleure interopérabilité et de meilleures capacités de traitement des données.

Si les virements SWIFT traditionnels constituent depuis des décennies l'épine dorsale des paiements internationaux, ils présentent certaines limites, notamment une transparence restreinte, des délais de traitement plus longs et des données non structurées.

Swift 103+ STP (traitement automatisé de bout en bout)

Swift 103+ STP était le format MT historique optimisé pour le traitement automatisé de bout en bout (Straight Through Processing, STP) ; depuis la fin de la période de coexistence, son rôle est repris par le guide d'utilisation STP du message pacs.008. Le STP permet de conduire l'ensemble du processus de paiement, de l'initiation au règlement définitif, par voie électronique et sans intervention manuelle.

Caractéristiques complémentaires :

1. Format normalisé : il exige le strict respect d'un format normalisé, ce qui réduit les erreurs et les retards.
2. Traitement automatisé : les transactions sont traitées automatiquement, ce qui garantit un traitement plus rapide et plus efficace.
3. Réduction des interventions manuelles : la nécessité de saisie et de vérification manuelles est réduite au minimum, ce qui limite les risques d'erreurs et de retards.
4. Règlement plus rapide : les opérations sont dénouées plus rapidement qu'avec les méthodes traditionnelles.

Points à considérer pour le traitement automatisé (STP) :

1. Saisie exacte des données : les données doivent être saisies avec exactitude afin d'éviter tout retard ou rejet.
2. Conformité aux exigences de format : les banques doivent veiller à ce que les exigences de format de 103+ STP soient strictement respectées.
3. Logiciels et systèmes : les banques doivent disposer de logiciels et de systèmes appropriés pour assurer efficacement le traitement automatisé de bout en bout (STP)

Il est essentiel de distinguer l'échange de messages du règlement. SWIFT transmet des messages financiers structurés entre établissements, mais ne déplace pas lui-même de fonds et ne détient pas de soldes. Une confirmation SWIFT, y compris un message pacs.008, n'est valable que si elle correspond à une transaction effective, traitée et rapprochée dans les systèmes bancaires des établissements participants.

Tout document SWIFT, capture d'écran ou message isolé présenté sans vérification institutionnelle ne doit pas être considéré comme la preuve d'un règlement effectué.

Virements SWIFT gpi.

SWIFT gpi (Global Payments Innovation) :

Lancée en 2017, l'initiative SWIFT gpi vise à remédier aux limites des virements SWIFT traditionnels en améliorant la rapidité, la transparence et la traçabilité des paiements transfrontaliers. SWIFT gpi s'appuie sur les formats de messages MT et MX existants pour améliorer les services de paiement. Ses principales caractéristiques sont les suivantes :

• Paiements plus rapides : gpi simplifie les processus et établit des accords de niveau de service (SLA) plus stricts entre les banques, ce qui réduit les délais de traitement des transactions, souvent à quelques minutes, voire quelques secondes.
• Suivi des paiements : le gpi Tracker permet le suivi des transactions en temps réel, ce qui améliore la transparence et réduit les recherches manuelles.
• Transparence des frais : les banques peuvent communiquer à leurs clients, en amont, les informations relatives aux frais de transaction, ce qui permet de prendre des décisions plus éclairées.
• Données plus riches : gpi prend en charge un échange d'informations plus détaillé et structuré, facilitant un meilleur rapprochement et la conformité réglementaire.

SWIFT gpi répond aux limites des virements SWIFT traditionnels en améliorant les paiements transfrontaliers grâce à un suivi de bout en bout, à un traitement plus rapide et à des données plus riches.

Paramètres clés pour les participants ne relevant pas de SWIFT gpi

Lorsqu'un participant non SWIFT gpi (par exemple une banque ou un établissement financier non directement inscrit à gpi) adresse une instruction de paiement à une banque participante gpi, la banque gpi peut la convertir dans les formats de message SWIFT requis (pacs.008 pour les virements de clientèle, pacs.009 COV pour les virements de couverture et pacs.009 pour les virements entre établissements financiers). Cette conversion permet le traitement et le suivi au sein du réseau gpi, à condition que l'instruction comporte des données suffisantes pour renseigner les champs obligatoires et respecter les règles gpi, telles que la traçabilité de bout en bout.

Les participants non gpi fournissent généralement ces paramètres au moyen de schémas de paiement nationaux, d'API ou de formats hérités, et la banque gpi se charge des ajouts propres à gpi (par exemple la génération d'un UETR s'il n'a pas été fourni, sa transmission étant facultative pour les entités non gpi). Les exigences précises peuvent varier selon la juridiction, la devise et les accords bilatéraux, mais les paramètres essentiels sont issus des lignes directrices CBPR+ (Cross-Border Payments and Reporting Plus) et des normes ISO 20022. Depuis la fin de la période de coexistence le 22 novembre 2025, les instructions de paiement transfrontalier sont échangées au format ISO 20022 ; les références aux champs MT héritées ci-dessous ne sont données qu'à titre indicatif.
1. Identification des parties (informations sur le débiteur et le créancier)
Ces éléments identifient le donneur d'ordre et le bénéficiaire et garantissent le respect de la Recommandation 16 du FATF relative à la règle de voyage.

• Débiteur/Donneur d'ordre : nom complet, adresse structurée (rue, ville, code postal, pays) et identification du compte (p. ex. IBAN ou numéro de compte). Dans les anciens messages MT103/MT202 COV, cela correspond au champ 50a ; pour pacs.008/pacs.009, aux éléments <Dbtr> et <DbtrAcct>.
• Client créancier/bénéficiaire : nom complet, adresse structurée et identification du compte. Correspond au champ 59a de l'ancien MT 103/MT 202 COV ; <Cdtr> et <CdtrAcct> dans pacs.008/pacs.009.
• Débiteur/créancier final (le cas échéant) : s'ils sont distincts des parties principales, indiquez leurs coordonnées afin de renforcer la transparence (facultatif mais recommandé pour le suivi gpi). Correspond à <UltmtDbtr>/<UltmtCdtr> dans pacs.008/pacs.009.

Raison de l'exigence : permet un acheminement précis et des contrôles réglementaires ; des données incomplètes peuvent entraîner des rejets ou des retards.

2. Informations sur les agents et l'acheminement
Précise les établissements financiers intervenant dans la chaîne.

• Banque du donneur d'ordre : BIC (Bank Identifier Code) ou autre identifiant de la banque émettrice. Correspond au champ 52a de l'ancien MT 103 ; <DbtrAgt> dans pacs.008/pacs.009.
• Banque du créancier : BIC de la banque réceptrice. Correspond au champ 57a des anciens MT 103/MT 202 COV ; <CdtrAgt> dans les pacs.008/pacs.009.
• Agents intermédiaires (si connus) : BIC des correspondants éventuels (jusqu'à 3 niveaux). Correspond au champ 56a de l'ancien MT ; <IntrmyAgt1-3> dans pacs.008/pacs.009.
• Agents donneurs d'ordre/agents destinataires de l'ordre : BIC de l'expéditeur et du destinataire immédiats dans la chaîne. Facultatif, mais utile pour les méthodes en série ou de couverture.
• Agents donneurs d'ordre précédents (le cas échéant) : pour les chaînes à plusieurs intermédiaires, jusqu'à 3 agents antérieurs.

Raison de l'exigence : Garantit un acheminement correct par les intermédiaires ; privilégier le BICFI aux dénominations pour plus de précision dans les pacs.009 COV.

3. Détails de la transaction
Éléments financiers essentiels au règlement.

• Montant et devise : montant du règlement interbancaire et code de devise ISO 4217 (par exemple USD, EUR). Correspond au champ 32A des anciens MT 103/MT 202 COV ; <IntrBkSttlmAmt> dans pacs.008/pacs.009.
• Montant ordonné (s'il diffère) : montant initial avant déductions.
• Date de règlement interbancaire : date de valeur du règlement. Correspond à une partie du champ 32A en MT ; <IntrBkSttlmDt> dans pacs.008/pacs.009.
• Méthode de règlement : indiquer s'il s'agit d'un règlement via RTGS (CLRG), par couverture (COVE) ou par agent (INDA/INGA). Pas d'équivalent MT direct, mais implicite.

Raison de l'exigence : Définit le transfert de valeur ; obligatoire pour tous les formats.

4. Références et identifiants de suivi
Pour assurer la traçabilité, en particulier dans gpi.

• Identification de bout en bout : référence reliant l'ensemble de la chaîne (par exemple, identifiant de facture ou de transaction). <EndToEndId> dans pacs.008/pacs.009.
• Identification de l'instruction : référence de l'émetteur (limitée à 16 caractères en MT). Correspond au champ 20 de l'ancien MT ; <InstrId> dans pacs.008/pacs.009.
• Référence unique de transaction de bout en bout (UETR) : un UUID destiné au suivi de bout en bout. Obligatoire dans les messages pacs.008/pacs.009 et, dans les anciens messages MT103/MT202, dans le champ 121 ; si le canal d'initiation ne la fournit pas, la première banque Swift de la chaîne la génère.
• Identification de la transaction : référence interne supplémentaire.

Raison de l'exigence : permet le suivi et le rapprochement gpi (par exemple, pacs.008 avec pacs.009 COV) ; l'UETR est essentiel pour les confirmations universelles.

5. Informations sur l'objet et le service
Classe le type de paiement.

• Codes de finalité et de catégorie de finalité : codes ISO (par exemple SALA pour salaire) indiquant la nature de l'opération. Obligatoires sur certains corridors ; <Purp> et <CtgyPurp> dans pacs.008.
• Code de niveau de service : Identifie le service gpi (par exemple, G001 pour un virement client gpi) ; les banques non gpi ne doivent pas inclure de codes propres à gpi, sauf accord préalable. Correspond au champ 23E en MT ; <SvcLvl> dans pacs.008/pacs.009.
• Code d'instrument local : pour des schémas spécifiques (par exemple, les virements intragroupe).

Raison de l'exigence : garantit la conformité réglementaire et la priorité de traitement ; devient de plus en plus obligatoire depuis la migration vers ISO.

6. Instructions de remise de fonds et instructions complémentaires

• Informations de remise : texte libre (jusqu'à 140 caractères) ou données structurées (par exemple, détails de facture). Correspond au champ 70 de l'ancien MT103 ; balise <RmtInf> dans pacs.008/pacs.009.
• Instructions aux agents : par exemple /REC/ pour le destinataire, /ACC/ pour le compte, ou des instructions téléphoniques (PHOB). Correspond au champ 72 de l'ancien MT ; <InstrForNxtAgt>/<InstrForCdtrAgt> dans pacs.008/pacs.009.
• Indicateurs d'heure de règlement : Heures demandées (par ex. CLSTm pour l'heure CLS).

Raison de l'exigence : Fournit le contexte et les instructions de traitement ; indispensable pour les méthodes de couverture dans pacs.009 COV.

7. Données réglementaires et de conformité

• Déclaration réglementaire : codes ou informations (par exemple, numéro d'identification fiscale, indicateur de déclaration tel que CRED/DEB). Correspond au champ 77B dans le MT ; <RgltryRptg> dans pacs.008/pacs.009.
• Codes de motif de retour (le cas échéant pour les retours) : Par exemple, AC04 pour compte clôturé, dans le message pacs.004 rattaché aux messages d'origine.

Raison de l'exigence : satisfait aux obligations en matière d'AML/KYC et de déclaration ; obligatoire dans les corridors réglementés.

Pour les bonnes pratiques, les participants non gpi doivent structurer les données de manière à éviter toute troncature lors des conversions MT-MX et consulter la banque membre gpi pour leurs besoins spécifiques. Lorsque le paiement recourt à la méthode de couverture, les données du client sous-jacent doivent être identiques dans tous les messages (par exemple, de pacs.008 à pacs.009 COV).

Les messages de paiement dans SWIFT gpi

Dans le cadre de SWIFT gpi (Global Payments Innovation), les messages de paiement d'origine (par ex. pacs.008 pour les virements de clientèle ou pacs.009 COV pour les virements de couverture) sont considérés comme immuables une fois envoyés. Les banques destinataires ne peuvent pas en modifier directement le contenu, car les messages SWIFT sont conçus pour préserver l'intégrité et l'auditabilité tout au long de la chaîne de paiement. Toute modification, correction ou annulation est donc traitée au moyen de messages de suivi distincts, de mises à jour de statut via le gpi Tracker, ou de services dédiés tels que gSRP (gpi Stop and Recall Payment). Cela garantit une traçabilité de bout en bout grâce à la référence unique de transaction de bout en bout (UETR).

Les banques destinataires (agissant généralement en qualité d'agent du créancier ou d'intermédiaire) peuvent toutefois répondre aux demandes de modification émanant de l'émetteur ou engager des actions aboutissant de fait à modifier l'issue du paiement (par exemple, retours ou blocages). Elles peuvent également, dans certaines conditions précises, demander à l'émetteur des précisions ou des modifications. Ces processus sont régis par les règlements de SWIFT, les guides de bonnes pratiques de marché (par exemple ceux du Payments Market Practice Group – PMPG) et les exigences réglementaires, qui privilégient l'automatisation, la transparence et la prévention de la fraude.

Conditions dans lesquelles les banques destinataires peuvent demander ou faciliter des modifications
Les banques destinataires peuvent demander des modifications (par exemple, la correction de certaines données) ou entreprendre des actions impliquant un besoin de modification lorsque le paiement initial ne peut être traité conformément aux instructions. Cela se fait généralement au moyen de messages de demande de renseignements (par exemple MT 195/199) ou de réponses à des demandes émanant de l'émetteur. Les principales conditions sont les suivantes :

• Erreurs dans les détails du paiement : en cas d'inexactitudes telles qu'un compte bénéficiaire incorrect (par exemple un compte clôturé – code AC04), une devise erronée (code CURR), un acheminement erroné via l'agent (code AGNT) ou des problèmes techniques (code TECH), la banque destinataire peut mettre le paiement en attente et demander à l'émetteur de fournir des informations corrigées ou d'envoyer un nouveau paiement. Cela évite un rejet pur et simple tout en permettant une résolution.
• Impossibilité d'imputer le paiement : en vertu du code CUTA (Cancel Upon Unable to Apply), si le paiement ne peut être crédité en raison de discordances (par exemple, écart de nom ou de compte, ou informations insuffisantes), la banque destinataire peut demander à l'émetteur des précisions en vue de l'annulation ou de la modification afin de régulariser la situation.
• Fraude présumée ou opérations non autorisées : en cas de fraude (code FRAD), la banque destinataire peut détecter elle-même les anomalies et engager un retour de fonds sans demande préalable de l'émetteur. Elle peut également répondre aux demandes de rappel de l'émetteur en mettant les fonds en quarantaine et en demandant une garantie d'indemnisation (code INDM) si les fonds ont déjà été crédités, afin d'atténuer le risque avant le retour.
• Paiements en double ou indus : des codes tels que DUPL (paiement en double) ou UPAY (paiement indu) permettent à la banque destinataire de signaler l'opération et d'en demander l'annulation lorsqu'elle est erronée ou injustifiée.
• Problèmes réglementaires ou de conformité : si le paiement enfreint la législation locale, des sanctions ou des exigences AML (code LEGL), la banque destinataire peut le rejeter ou le suspendre et demander à l'émetteur des documents complémentaires ou des modifications.
• Décisions du client ou du bénéficiaire : Si le bénéficiaire refuse le paiement (code CUST ou NOAS – absence de réponse du bénéficiaire), la banque destinataire peut le retourner et en informer l'émetteur, en demandant éventuellement la confirmation des modifications.
• Résolutions en suspens : pour les dossiers en suspens (code PDCR), par exemple dans l'attente d'une autorisation de débit (RQDA) ou d'une réponse de l'agent suivant (PTNA), la banque destinataire peut retenir le paiement et demander des instructions complémentaires ou des modifications pour poursuivre le traitement.

Dans tous les cas, les demandes doivent être structurées pour l'automatisation (par exemple, inclure l'UETR, les références d'origine telles que les champs 20/32A/50/59, et des codes spécifiques dans le champ 79 des messages) afin de permettre le traitement automatisé de bout en bout. Des conventions d'indemnisation peuvent être exigées sur une base bilatérale si les fonds sont crédités ; la banque destinataire n'est pas tenue d'accepter les demandes, mais doit traiter en priorité les demandes urgentes (par exemple, liées à la fraude).

Processus concernés

• Réponse aux rappels initiés par l'émetteur : l'émetteur (banque du débiteur) initie généralement un rappel au moyen d'un MT 192/292 (ou d'équivalents ISO 20022 tels que camt.056) via le service gSRP, transmis en série ou directement à la banque réceptrice. La banque réceptrice doit accuser réception immédiatement et répondre par un MT 196/296 (ou un MT 199/299 s'il est structuré), en utilisant des codes tels que CNCL (annulé), RJCR (rejeté avec motif) ou PDCR (en attente). En cas d'acceptation, les fonds sont restitués au moyen d'un pacs.004 (retour de paiement).
• Actions indépendantes des banques destinataires : Si une fraude est détectée en interne, la banque destinataire peut restituer les fonds au moyen d'un message pacs.004 comportant des informations structurées, en procédant à la notification via le Tracker afin de permettre un suivi de statut en temps réel.
• Demandes de modification ou de précision : les banques réceptrices utilisent des messages de demande (par exemple MT 195/295) pour solliciter des modifications, telles que des informations complémentaires. Cela est courant pour les paiements en attente.
• Intégration du Tracker : toutes les opérations mettent à jour le gpi Tracker en temps réel, accessible par API ou interface graphique, ce qui garantit la visibilité de l'ensemble des parties. Les membres gpi doivent se conformer aux guides de règles obligatoires relatifs à gCCT (Customer Credit Transfer), gCOV (Cover) et gSRP.
• Limites et facteurs de réussite : les modifications ne sont pas garanties ; leur succès dépend du stade du paiement (plus aisé avant l'inscription au crédit), de la coopération du bénéficiaire et de la juridiction. Si les fonds ont été crédités, leur restitution requiert le consentement du bénéficiaire ou une garantie d'indemnisation. La réglementation prévaut toujours sur les lignes directrices.

Ces pratiques s'appliquent principalement aux membres gpi, mais les banques non membres peuvent y participer par l'intermédiaire de passerelles. Pour obtenir les informations les plus récentes, veuillez consulter les règlements officiels de SWIFT, car les processus évoluent (par exemple avec la migration vers ISO 20022).

Séparation de la messagerie et du règlement dans SWIFT gpi

SWIFT gpi gère principalement les instructions de paiement et leur suivi par voie de messagerie (par exemple, des formats ISO 20022 tels que pacs.008 pour les virements de clientèle, pacs.009 pour les transferts entre établissements financiers, ou les messages hérités MT103/MT202), mais le mouvement effectif des fonds s'effectue séparément, au niveau du règlement. Le règlement intervient généralement par le biais de relations de banque correspondante (comptes nostro/vostro), de compensation bilatérale ou de mécanismes de compensation et de règlement (CSM) tels que les systèmes de règlement brut en temps réel (RTGS) (par exemple T2, anciennement TARGET2, en Europe, Fedwire aux États-Unis ou CHAPS au Royaume-Uni). Le gpi Tracker offre une visibilité en temps réel sur le statut des messages, mais le transfert des fonds repose sur ces systèmes sous-jacents.

La période de coexistence pour les instructions de paiement transfrontalières a pris fin le 22 novembre 2025 : les instructions de paiement telles que MT103 et MT202 ont été remplacées par des messages ISO 20022 (MX) tels que pacs.008 et pacs.009, tandis que d'autres catégories de messages MT seront retirées à des dates ultérieures. Ce qui suit explique comment s'opèrent les retours et les levées de blocage au niveau du compte, de la compensation et du règlement.

Restitution des fonds au niveau du compte, de la compensation et du règlement
Les retours sont initiés à la suite d'une demande de rappel aboutie (via gSRP – service gpi Stop and Recall Payment) ou d'une détection indépendante (par exemple, fraude, erreurs). Le gSRP utilise le message camt.056 (demande d'annulation de paiement) émis par la banque expéditrice, auquel il est répondu par un message camt.029 (résolution d'une enquête). Une fois la demande acceptée, la restitution des fonds est exécutée au moyen d'une nouvelle instruction de paiement qui inverse le flux, en débitant le compte de la banque destinataire et en créditant en retour tout au long de la chaîne. Il ne s'agit pas d'une modification du message initial, mais d'une opération distincte.

Principales méthodes de règlement et processus de retour
Les méthodes de règlement déterminent la manière dont les retours s'effectuent :

• CLRG (compensation via une infrastructure de marché) : règlement par l'intermédiaire d'un RTGS ou d'un CSM (par exemple via une banque centrale). Les retours utilisent pacs.004 pour donner instruction à l'infrastructure de marché de débiter le compte de l'agent récepteur et de créditer celui de l'agent précédent, souvent en temps réel ou le jour même.
• INGA (Instructing Agent Settles First) : L'émetteur règle les fonds avant l'envoi du message. Les retours via pacs.004 débitent le compte de l'agent instruit après le règlement.
• INDA (l'agent instruit règle à réception) : le destinataire règle dès réception du message. En l'absence de règlement, rejet via pacs.002 (aucun mouvement de fonds) ; en cas de règlement, restitution via pacs.004.
• COVE (méthode de couverture) : utilisée pour les paiements de montant élevé avec un transfert de couverture (pacs.009 COV). Les retours suivent la chaîne inverse : pacs.004 de la banque du bénéficiaire vers les intermédiaires, avec débit et crédit des comptes de correspondants en conséquence.

Processus de retour pas à pas au niveau du règlement

1. Initiation et acceptation : l'émetteur demande le rappel (par exemple au moyen d'un message camt.056 avec UETR). Le récepteur répond (camt.029) et accepte si les fonds sont disponibles ou pas encore crédités au bénéficiaire (plus aisé avant crédit). Si les fonds ont été crédités, le consentement du bénéficiaire ou une garantie d'indemnisation peut être requis.

2. Instruction de retour de fonds : le destinataire émet un message pacs.004 (Payment Return) ou un MT 103/MT 202 hérité comportant des codes de retour (par ex. RETN). Ce message comprend :

• Références d'origine (UETR, identifiant de bout en bout, identifiant d'instruction).
• Inversion des rôles : le créancier initial devient débiteur ; l'agent du débiteur initial devient créancier.
• Détails du règlement : montant et date de règlement interbancaire d'origine, taux de change (en cas d'opération de change), frais (s'ils sont déduits).
• Code motif de retour (p. ex. AC04 pour compte clôturé, FRAD pour fraude).
• Champ Settlement Account (s'il figure dans le message d'origine) pour préciser le compte à créditer.

3. Exécution du règlement :

• Le message pacs.004 déclenche le débit du compte nostro/vostro de la banque destinataire (détenu auprès de l'agent précédent ou de l'IMF).
• Les fonds sont recrédités de proche en proche le long de la chaîne, selon le même mode de règlement (par exemple, un virement RTGS dans CLRG).
• En cas de retour partiel, indiquer « PART » dans les informations complémentaires, avec le montant calculé au prorata.
• L'outil de suivi met à jour le statut (par exemple « Retourné ») en temps réel, consultable via l'API ou l'interface graphique.

4. Crédit définitif : le compte de l'expéditeur initial est crédité, souvent après déduction de frais. En cas de passage par un CSM, le règlement est atomique ; dans les dispositifs bilatéraux, il peut impliquer une compensation en fin de journée.

5. Notifications postérieures au retour : utiliser les messages camt.053/054 (relevé de compte / avis de débit-crédit) pour confirmer la mise à jour des écritures. Aucun nouveau pacs.004 pour « retourner un retour » : recourir plutôt aux demandes de renseignements.
Les retours sont automatisés dans la mesure du possible, mais une intervention manuelle peut avoir lieu pour des raisons de conformité ou si les fonds sont gelés. Le recouvrement n'est pas garanti ; il dépend avant tout de la rapidité avec laquelle le rappel est envoyé et du fait que les fonds ont déjà été crédités ou non. En l'absence de règlement (par exemple en cas de rejet avant règlement), aucun fonds n'est transféré : utiliser alors pacs.002.

Comment les paiements retenus sont libérés (feu vert) au niveau du compte, de la compensation et du règlement

Une mise en attente intervient lorsqu'un paiement ne peut être traité immédiatement (par exemple en raison d'erreurs, de contrôles de conformité ou dans l'attente d'éclaircissements) et se trouve placé dans un état « en suspens » sans règlement. Aucun fonds n'est débité ni crédité avant résolution. Le gpi Tracker affiche des statuts tels que « On Hold » ou « Pending » (par exemple le code PDCR), et la résolution s'effectue au moyen de messages de demande de renseignements (MT 195/199 ou camt.029).

Conditions donnant lieu à des blocages

• Discordances (par exemple, écart entre compte et nom – code CUTA).
• Contrôles réglementaires (par exemple, sanctions – code LEGL).
• En attente de la réponse du bénéficiaire (code NOAS) ou de l'autorisation de débit (RQDA).
• Heures de fermeture ou traitement par lots auprès de la banque du bénéficiaire.

Processus de libération au niveau du règlement
1. Notification de blocage : La banque destinataire envoie un message pacs.002 (mise à jour de statut) ou MT 199 avec un code d'attente, et conserve les fonds sur un compte d'attente ou un compte séquestre en cas de règlement partiel (par exemple, dans les méthodes de couverture).
2. Résolution : La banque émettrice fournit les modifications ou précisions requises (par exemple, par une réponse MT 195 ou camt.029). Si la situation est résolue, la banque destinataire donne son feu vert en traitant l'instruction initiale.
3. Exécution du règlement :

• Le message pacs.008/pacs.009 d'origine est libéré de sa mise en attente.
• Les fonds sont réglés selon la méthode spécifiée : débit du compte de l'émetteur, crédit du compte du destinataire (par exemple via RTGS dans CLRG), puis crédit final sur le compte du bénéficiaire.
• Le tronçon bénéficiaire (de la banque destinataire au client final) est souvent celui où surviennent les retards, en particulier sur les marchés soumis à des contrôles des capitaux ou dotés d'infrastructures limitées.
• Le suivi passe à « Crédité » ou « Terminé », le message pacs.002 (Payment Status Report) en apportant la confirmation.

4. En l'absence de libération : si la situation n'est pas résolue (par exemple après expiration du délai), retour par pacs.004 comme ci-dessus, ou rejet par pacs.002 (aucun règlement).

Les règles du gpi exigent, dans la mesure du possible, un crédit le jour même ; Swift a indiqué en 2018 que près de 50 % des paiements gpi étaient crédités en moins de 30 minutes et la quasi-totalité en moins de 24 heures. Des facteurs tels que le contrôle des capitaux ou les heures de fermeture des systèmes bancaires peuvent allonger les délais de blocage, mais le gpi privilégie l'automatisation afin de les réduire au minimum.

SwiftNet Instant

SwiftNet Instant. Il s'agit d'une plateforme de messagerie en temps réel, à faible latence, disponible 24 heures sur 24 et 7 jours sur 7, qui prend en charge l'échange sécurisé de flux de paiements instantanés entre les mécanismes de compensation et de règlement (Clearing and Settlement Mechanisms, CSM) et leurs participants.

Les clients peuvent se connecter à SwiftNet Instant via leur infrastructure existante de connectivité et de sécurité Swift, y compris les boîtiers VPN, les lignes louées et les modules de sécurité matériels. L'intégration à l'environnement informatique de la banque s'effectue au moyen d'Alliance Gateway Instant (AGI).

Toutes les parties de la chaîne de paiement instantané peuvent utiliser AGI et la messagerie SwiftNet Instant. Les applications comprennent l'initiation de paiements depuis un service overlay, les communications entre un membre indirect et son membre sponsor, ou la réception par une entreprise d'une confirmation de paiement.

SWIFT Instant se connecte aux systèmes nationaux de paiement instantané afin de permettre le traitement des opérations en temps réel, tant au niveau national qu'international, selon la norme ISO 20022. Ces systèmes illustrent les efforts continus de modernisation et de simplification des processus de paiement dans le secteur financier.

Prélèvement SWIFT

Le prélèvement dans le système SWIFT est un mode de paiement qui permet aux entreprises et aux particuliers d'encaisser des fonds sur les comptes bancaires de débiteurs, dans plusieurs devises et dans différents pays. À la différence du prélèvement SEPA, spécifiquement conçu pour la zone SEPA et limité aux opérations libellées en euros, le prélèvement dans SWIFT a une portée mondiale et prend en charge un large éventail de devises.

Le processus d'initiation d'une opération de prélèvement au sein du système SWIFT comprend généralement les étapes suivantes :

1. Accord entre créancier et débiteur : le créancier et le débiteur doivent avoir conclu au préalable un accord, qui définit les conditions applicables aux opérations de prélèvement. Cet accord peut également prévoir la mise en place d'un mandat ou d'une autorisation permettant au créancier de prélever les paiements sur le compte bancaire du débiteur.
2. Échange de messages : la banque du créancier initie le prélèvement en envoyant un message SWIFT à la banque du débiteur – en ISO 20022, un message pacs.003 (prélèvement de clientèle) ou pacs.010 (prélèvement entre institutions financières), anciennement MT 104 ou MT 204. Ce message contient les détails de l'opération, tels que le montant, la devise, les coordonnées du compte du débiteur et toute autre information nécessaire.
3. Vérification et autorisation : la banque du débiteur vérifie les détails de la transaction, contrôle la disponibilité des fonds sur le compte du débiteur et confirme l'autorisation de la transaction. Si tout est en ordre, la banque du débiteur procède au débit des fonds du compte du débiteur.
4. Transfert de fonds : les fonds sont réglés entre la banque du débiteur et celle du créancier par l'intermédiaire de comptes de correspondants ou d'un système de compensation et de règlement.
5. Confirmation : à réception des fonds, la banque du créancier envoie au créancier un message de confirmation l'informant du succès du prélèvement.

Les conditions préalables à l'initiation d'une opération de prélèvement au sein du système SWIFT sont les suivantes :

1. Comptes bancaires : le créancier comme le débiteur doivent détenir des comptes auprès d'établissements financiers membres du réseau SWIFT.
2. Convention et autorisation : une convention et une autorisation (mandat) préalables entre le créancier et le débiteur doivent exister pour permettre les opérations de prélèvement.
3. Formats de messages SWIFT : le créancier et sa banque doivent utiliser les formats de messages appropriés : pain.008 pour initier un prélèvement, pacs.003 ou pacs.010 entre banques.
4. Frais bancaires : le créancier et le débiteur doivent connaître les frais éventuels associés aux opérations de prélèvement dans le système SWIFT, ces frais pouvant varier selon les banques et les pays concernés.

RMA dans la messagerie interbancaire SWIFT

Dans le secteur bancaire et financier, des communications sécurisées et efficaces entre banques sont essentielles. C'est là que SWIFT (Society for Worldwide Interbank Financial Telecommunication) joue un rôle crucial, en acheminant la majorité des messages interbancaires internationaux. Un élément essentiel garantissant la sécurité et la sélectivité de ces communications est l'application de gestion des relations (Relationship Management Application, RMA).

Qu'est-ce que le RMA ?

La Relationship Management Application (RMA) est une application logicielle SWIFT qui permet aux établissements financiers de définir les contreparties autorisées à leur envoyer des messages SWIFT et garantit que les communications sur le réseau SWIFT sont réservées aux utilisateurs authentifiés. La RMA constitue une couche de sécurité fondamentale dans la gestion des communications interbancaires, car elle filtre les messages non autorisés et réduit le risque de fraude.

L'importance de la RMA

Pour les banques actives dans la finance internationale, telles qu'IFB, l'outil RMA est indispensable. Il renforce non seulement les protocoles de sécurité, mais garantit également la conformité à la réglementation bancaire mondiale. En maîtrisant les établissements autorisés à leur adresser des messages, les banques peuvent prévenir les demandes d'informations et les instructions financières non autorisées, protégeant ainsi leurs intérêts comme ceux de leurs clients.

Fonctionnement du RMA

Le processus RMA comprend plusieurs étapes clés :

1. Établissement de relations RMA : avant que deux banques puissent commencer à échanger des informations via SWIFT, elles doivent convenir mutuellement d'établir une RMA. Cet accord s'apparente à une poignée de main numérique, signifiant la confiance et le consentement à communiquer.
2. Échange de clés : chaque banque envoie une autorisation RMA par l'application RMA, que la contrepartie accepte. Le RMA a remplacé l'ancien échange bilatéral de clés (BKE) ; les messages eux-mêmes sont authentifiés par la PKI (infrastructure à clés publiques) de SWIFTNet.
3. Configuration des paramètres RMA : chaque banque utilise l'outil RMA pour configurer les autorisations et préciser les types de messages acceptés de la part de l'autre banque. Cette configuration peut être définie de manière générale ou affinée pour inclure des types de messages et des sous-catégories spécifiques.
4. Activation et suivi : une fois les paramètres RMA configurés et activés, les banques peuvent surveiller les messages entrants afin de vérifier leur conformité aux autorisations établies. Le RMA fournit également des outils permettant de modifier ou de révoquer des autorisations lorsque les besoins de l'activité ou des préoccupations de sécurité l'exigent.

Applications pratiques

Pour IFB, qui est spécialisée dans la gestion d'investissements et de patrimoine pour des particuliers fortunés et des entités commerciales, la RMA présente plusieurs avantages :

• Sécurité renforcée : en contrôlant le trafic des messages, IFB peut protéger les transactions et les informations sensibles de ses clients contre tout accès non autorisé.
• Efficacité opérationnelle : des communications simplifiées avec des entités de confiance permettent un traitement plus rapide des messages légitimes, ce qui améliore les délais de réponse et la satisfaction de la clientèle.
• Conformité réglementaire : la RMA facilite le respect des réglementations bancaires internationales, qui imposent un contrôle strict des échanges d'informations afin de prévenir les délits financiers tels que le blanchiment de capitaux et la fraude.

RMA et MT799. Les banques peuvent recourir à un MT799 pour demander ou coordonner une relation RMA, pour autant que le canal le permette. L'autorisation RMA elle-même est accordée dans le système RMA ; un MT799 seul n'active aucune autorisation. Lorsque l'autorisation RMA requise pour le MT799 fait défaut, elle ne peut être contournée par l'envoi direct d'un MT799. La mise en place est alors convenue au moyen de la fonction de communication RMA du portail de gestion des relations de Swift, conçue pour la coordination avec les contreparties avant l'échange des autorisations, ou par un autre canal autorisé. « RMA par MT799 » peut donc désigner la correspondance bancaire d'accompagnement ; l'autorisation technique RMA constitue une étape distincte.

En résumé

Pour IFB, la mise en œuvre effective de la RMA n'est pas seulement une exigence technique, mais un atout stratégique dans ses activités mondiales. Elle renforce l'engagement de la banque en matière de sécurité et de conformité réglementaire, tout en améliorant l'efficacité de ses réseaux de communication. À mesure que l'environnement de la finance internationale évolue, des outils tels que la RMA demeurent indispensables aux banques attachées à maintenir les plus hauts niveaux d'intégrité opérationnelle et de service à la clientèle.

Les RMA constituent l'épine dorsale d'une communication interbancaire sécurisée et sélective, garantissant que chaque message échangé via le réseau SWIFT respecte les normes de sécurité les plus élevées et est pleinement authentifié. Pour des banques comme IFB, comprendre et gérer les RMA est essentiel pour protéger leurs opérations et instaurer la confiance avec leurs partenaires internationaux.

Instructions financières Swift Digital Blockchain

En septembre 2025, Swift a annoncé qu'elle avait entamé, avec plus de 30 établissements financiers, la conception et le développement d'un registre numérique partagé. Le 9 juillet 2026, Swift a déclaré le registre prêt pour une première utilisation, 17 banques se préparant à piloter des transactions réelles de dépôts tokenisés : ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB et Wells Fargo. La première application portera sur la mise en place d'instructions transfrontalières interbancaires en temps réel, 24 h/24 et 7 j/7, une amélioration déterminante de l'infrastructure de traitement des transactions internationales.

Le premier prototype conceptuel a été réalisé avec Consensys. Le registre est conçu comme un registre sécurisé, immuable et en temps réel des instructions financières entre institutions. Il enregistrera, séquencera et validera les messages de transaction, tout en appliquant les règles opérationnelles et de conformité au moyen de contrats intelligents. L'interopérabilité en est un principe central : le registre se connectera aux infrastructures existantes comme émergentes, tout en préservant la résilience, la confiance et le respect de la réglementation qui caractérisent Swift.

Comme l'a expliqué Javier Pérez-Tasso, directeur général de Swift :
« L'association d'un registre partagé avec la messagerie, les API et la norme ISO 20022 déjà proposées par Swift constitue un dispositif encore plus puissant : il permet d'intégrer dès l'origine, dans les flux de transactions, les exigences de gestion des risques, de contrôle et de conformité, tout en autorisant des instructions interbancaires transfrontalières en temps réel, 24 h sur 24 et 7 jours sur 7, avec la même confiance, la même sécurité, la même résilience, la même capacité d'évolution et la même excellence opérationnelle qui font la réputation de Swift. Le tout dans le droit fil de l'approche que nous avons toujours adoptée : celle d'une innovation responsable. »

Extension de l'infrastructure

Le registre partagé complète les infrastructures existantes de Swift ; il ne les remplace pas. Il est conçu pour étendre l'orchestration et l'interopérabilité, afin que les établissements financiers puissent échanger des instructions plus rapidement, avec une plus grande prévisibilité et à une échelle véritablement mondiale.

Lors du Sibos, Pérez-Tasso a souligné cette approche à double voie :
« Les infrastructures financières doivent rester résolument concentrées sur les fondamentaux que sont l'excellence opérationnelle, la conformité réglementaire et la gouvernance. Et, dans le même temps, elles doivent se préparer à l'avenir. Chez Swift, notre approche consiste à innover sur deux voies parallèles. »

Collaboration à l'échelle du secteur

Des établissements financiers de 16 pays ont été associés dès l'origine à la définition de la conception, de la gouvernance et de la trajectoire de développement du registre partagé. Cet effort collectif traduit une reconnaissance commune : faire progresser l'infrastructure mondiale des instructions interbancaires exige une échelle suffisante et une collaboration étroite.

Perspectives

Le registre partagé s'inscrit dans le prolongement naturel des précédents essais de Swift sur les actifs numériques et participe d'un engagement plus large en faveur de l'interopérabilité entre réseaux publics et privés. Il permettra à la valeur tokenisée réglementée comme aux instruments traditionnels de circuler sans heurt d'un système à l'autre.

Pérez-Tasso a résumé cette vision :
« Il s'agit d'une plateforme puissante pour l'avenir. Et elle peut devenir encore plus transformatrice à l'avenir. »

FAQ

Qu'est-ce que le registre partagé de Swift fondé sur la blockchain ?
Une infrastructure blockchain fournissant un enregistrement partagé et en temps réel des instructions financières entre établissements, permettant un traitement transfrontalier continu et conforme.

À qui s'adresse-t-il ?
Aux banques et institutions financières qui doivent fournir des instructions de transaction plus rapides et plus transparentes tout en se préparant à l'avenir numérique.

Quels sont les avantages ?

• Visibilité en temps réel et séquencement des instructions
• Conformité automatisée par contrats intelligents
• Interopérabilité entre les réseaux traditionnels et numériques
• Traitement sécurisé de flux de valeur tokenisée réglementés

Comment cela s'intègre-t-il à la plateforme de Swift ?
Ce dispositif étend l'infrastructure de confiance de Swift en intégrant des capacités d'instruction numérique tout en préservant la résilience, la sécurité et la conformité.

Quel est le premier cas d'usage ?
Instructions de transactions interbancaires transfrontalières en temps réel, 24 h/24 et 7 j/7.

Qui est impliqué ?
Plus de 30 établissements financiers de 16 pays ont contribué à la conception ; 17 banques testent les premières transactions en conditions réelles.

Quand sera-t-il disponible ?
Swift a déclaré le registre prêt pour une première utilisation le 9 juillet 2026. Les banques pilotes réalisent les premières transactions en conditions réelles dans le cadre d'une phase de mise en service contrôlée ; le règlement définitif continue de transiter par les systèmes existants. Les fonctionnalités et la disponibilité doivent être étendues par la suite.

Si vous souhaitez en savoir plus sur le transfert de fonds par l'intermédiaire du système de banque correspondante, veuillez contacter notre Responsable de la banque correspondante, M. Amri Elarisse