Virements IP/IP et IPZip

IP à IP (IPIP)

Les transferts IP à IP désignent une étape du processus de transfert de devises ou d'actifs, de passifs et de capitaux propres depuis des comptes de banques correspondantes, ou de données, entre différents établissements ou systèmes financiers, au moyen d'adresses IP (Internet Protocol). Dans le contexte des transactions financières, l'adresse IP est un identifiant numérique unique attribué à chaque appareil connecté à Internet ; elle sert à acheminer l'information entre différents systèmes. Les transferts IP à IP dans le secteur bancaire reposent sur la communication directe entre deux systèmes au moyen de leurs adresses IP respectives afin de réaliser une transaction financière. Des méthodes spécifiques d'authentification et d'autorisation viennent s'y ajouter pour garantir l'intégrité et la sécurité de l'information.

Il importe toutefois de noter que les transferts d'IP à IP ne sont ni courants ni recommandés dans le secteur bancaire, pour diverses raisons, notamment des préoccupations de sécurité, de fiabilité et de conformité. Les points suivants apportent quelques éléments de contexte sur ces préoccupations :

1. Sécurité : les transferts d'IP à IP peuvent être moins sûrs que ceux effectués via des réseaux bancaires établis, tels que SWIFT ou ACH, qui mettent en œuvre plusieurs niveaux de sécurité, de chiffrement et d'authentification. Une communication directe entre deux adresses IP peut exposer des informations sensibles à des menaces, notamment le piratage, l'hameçonnage ou les attaques de l'homme du milieu.
2. Fiabilité : le recours aux transferts d'IP à IP ne garantit pas la fiabilité de l'opération, dès lors qu'il n'existe dans le secteur bancaire aucune norme ni aucun protocole universellement reconnus pour les transferts fondés sur l'IP. Cela peut engendrer des difficultés potentielles en matière de traitement, de suivi et de rapprochement des opérations.
3. Conformité : les banques et les établissements financiers sont soumis à de nombreuses réglementations et exigences, notamment les politiques de lutte contre le blanchiment de capitaux (AML) et de connaissance du client (KYC). Les transferts d'IP à IP peuvent ne pas satisfaire à ces exigences réglementaires, ce qui expose potentiellement les parties concernées à des risques juridiques et financiers.

Plutôt que des transferts d'IP à IP, les banques et établissements financiers privilégient des réseaux établis, tels que SWIFT, RTGS ou ACH/paiements instantanés, ainsi que des normes de messagerie comme ISO 20022, afin de permettre des transferts de fonds sécurisés, fiables et conformes entre établissements.

Principales différences entre les serveurs de communication et les serveurs de grand livre et de comptes dans les banques

Dans la technologie bancaire, les serveurs jouent un rôle déterminant pour assurer le bon fonctionnement des transactions financières et de la tenue des registres. Les banques s'appuient principalement sur deux types de serveurs : les serveurs de communication et les serveurs de grand livre/de comptes. Bien que tous deux soient essentiels, ils répondent à des finalités distinctes et traitent des types de données différents.

Serveurs de communication

Les serveurs de communication constituent l'épine dorsale de l'échange sécurisé de données entre les banques et les établissements financiers. Voici leurs principales fonctions et caractéristiques :

1. Échange sécurisé de données : ces serveurs permettent l'échange sécurisé de données, de sorte que les informations financières sensibles puissent être transmises entre établissements sans être compromises.
2. Protocoles et normes : ils recourent à des protocoles normalisés tels que SWIFT, SEPA ou ACH, etc., pour la communication interbancaire, garantissant l'uniformité et la fiabilité entre les différentes plateformes.
3. Chiffrement et authentification : afin de garantir la sécurité, les serveurs de communication recourent à des méthodes de chiffrement avancées et à des protocoles d'authentification rigoureux, qui protègent les données pendant leur transmission.
4. Traitement des transactions : ils traitent en premier lieu les demandes de transaction, les messages et les instructions, en jouant le rôle d'intermédiaires qui transmettent les informations nécessaires aux transactions.
5. Aucun mouvement de fonds : il importe de relever que ces serveurs ne déplacent pas de fonds et ne mettent pas directement à jour les soldes des comptes ; ils se bornent à faciliter les communications nécessaires à de telles opérations.

Serveurs de grand livre et de comptes

Les serveurs de grand livre et de comptes, quant à eux, sont les dépositaires des registres financiers d'une banque. Voici leurs principales caractéristiques :

1. Tenue des registres financiers : ces serveurs stockent et conservent les registres financiers essentiels de la banque, garantissant l'enregistrement exact de chaque opération.
2. Enregistrement des opérations : ils enregistrent l'ensemble des opérations, y compris les débits et les crédits, et sont chargés de la mise à jour et de la conservation des soldes de compte courants.
3. Gestion du grand livre : les serveurs de grand livre gèrent le grand livre général de la banque ainsi que les comptes individuels des clients, offrant une vue complète de la santé financière.
4. Intégrité des données : garantir la cohérence et l'intégrité des données est essentiel, ces enregistrements étant indispensables à l'exactitude de l'information financière et à la conformité.
5. Mesures de sécurité renforcées : compte tenu de la sensibilité des données, les serveurs de registre mettent généralement en œuvre des mesures de sécurité plus strictes, notamment des couches supplémentaires de chiffrement et des contrôles d'accès rigoureux.

Le serveur de communication initie et facilite les transactions, mais c'est le serveur de grand livre qui, après validation, les enregistre et les reflète en dernier lieu dans les livres de la banque.

Dans les systèmes bancaires contemporains, ces fonctions sont souvent intégrées, les protocoles de communication sécurisés internes à la banque fonctionnant de concert avec les systèmes de gestion des registres comptables. Cette intégration garantit des mises à jour en temps réel et la cohérence de l'ensemble de l'écosystème financier de la banque, ce qui renforce à la fois l'efficacité et la sécurité. De nombreuses banques recourent à une combinaison de serveurs sur site et de serveurs en nuage afin de concilier exigences de sécurité, de conformité et d'évolutivité.

Transfert effectif des actifs, passifs et capitaux propres : Les transferts de titres sont enregistrés par les dépositaires centraux de titres (DCT), qui tiennent le registre juridique de la propriété ; les prêts, immobilisations et autres positions sont transférés par cession ou par conventions de transfert soumises au droit applicable. Ces deux aspects échappent au champ des protocoles de communication. Le transfert d'actifs et de capitaux propres a également une incidence sur les états financiers des banques, en modifiant les soldes du passif, de l'actif et des capitaux propres. Cette information financière destinée aux autorités de contrôle concernées, ainsi que les exigences de conformité qui s'y rattachent, dépasse les capacités de transmission de données des protocoles et nécessite des processus financiers et réglementaires supplémentaires.

En substance, si les protocoles sont essentiels à l'échange sécurisé et efficient d'informations dans les opérations IPIP, le processus complet fait intervenir des systèmes supplémentaires pour le mouvement effectif des devises, des actifs, des passifs et des fonds propres, ainsi que pour leur règlement, leur enregistrement juridique et leur reporting financier, afin que l'ensemble de l'opération soit exécuté conformément aux normes bancaires réglementaires.

Transfert IP ZIP

Transmission sécurisée par fichier d'instructions de paiement institutionnelles

Un virement IP ZIP se comprend avant tout comme une méthode sécurisée, fondée sur des fichiers, de transmission d'instructions de paiement structurées et des données de transaction associées, directement entre des systèmes institutionnels authentifiés, sur un réseau fondé sur le protocole Internet (IP).

La terminologie exige une précision particulière.

Une transmission IP ZIP n'est ni un système de compensation, ni un système de règlement, ni un canal de paiement, ni un mécanisme autonome de transfert de valeur monétaire. L'archive ZIP est un conteneur de transport. La connexion IP est le canal de communication. L'information contenue dans l'archive constitue une instruction, un jeu de données ou un message de transaction.

En conséquence :

IP ZIP transmet des informations et des instructions de paiement. Il n'assure pas, à lui seul, le règlement des fonds.

Sur le plan conceptuel, cette situation est comparable à la distinction applicable à un message ISO 20022 pacs.008 (virement de client entre institutions financières). Un message pacs.008 peut véhiculer une instruction de virement interbancaire hautement structurée, mais le message lui-même ne doit pas être confondu avec le mouvement et le règlement effectifs de monnaie de banque centrale, de monnaie de banque commerciale ou de soldes de comptes de correspondants.

Le même principe s'applique à une transmission IP ZIP.

2. Le fichier ZIP comme conteneur sécurisé de transaction

Le composant ZIP sert principalement de mécanisme de conteneurisation et de conditionnement.

Plutôt que de transmettre séparément chacun des éléments de la transaction, l'établissement donneur d'ordre peut regrouper les fichiers pertinents en un seul lot contrôlé.

Selon la spécification bilatérale convenue, un tel dossier peut comprendre :

• des instructions de paiement structurées ;
• Messages de paiement XML ;
• jeux de données compatibles avec ISO 20022 ;
• objets de transaction JSON ;
• enregistrements de transactions au format CSV ou à format fixe ;
• fichiers de paiement interbancaires propriétaires ;
• informations relatives au débiteur et au créancier ;
• informations relatives au compte du donneur d'ordre et au compte du bénéficiaire ;
• identifiants de transaction ;
• informations relatives à la devise et au montant ;
• dates d'exécution et de valeur demandées ;
• instructions de la banque correspondante ;
• les informations relatives à la banque intermédiaire ;
• informations de remise ;
• les informations d'acheminement du règlement ;
• la documentation de conformité ;
• références KYC ou KYB ;
• informations relatives à l'origine des fonds ;
• manifestes de transaction ;
• signatures numériques ;
• hachages cryptographiques ;
• certificats ;
• les horodatages ;
• les fichiers de rapprochement ; et
• totaux de contrôle.

L'archive peut donc contenir à la fois l'instruction de paiement principale et les informations accessoires nécessaires pour authentifier, valider, traiter et rapprocher cette instruction.

La compression est techniquement accessoire. L'objectif principal est la constitution d'un dossier maîtrisé et sa transmission.

Une archive ZIP ne doit en conséquence jamais être traitée comme la preuve que les fonds qui y sont représentés existent, sont disponibles, sont libres de toute charge ou ont été réglés.

3. Instruction de paiement structurée

Lorsqu'elle est conçue de manière appropriée, l'instruction de paiement contenue dans un paquet IP ZIP peut remplir une fonction analogue à celle de la messagerie financière structurée conventionnelle.

Par exemple, une institution pourrait transmettre une instruction XML contenant des champs correspondant aux informations que l'on trouve ordinairement dans un message ISO 20022 pacs.008, notamment :

• identification du message ;
• date et heure de création ;
• nombre de transactions ;
• les informations de règlement ;
• agent donneur d'ordre ;
• agent mandaté ;
• débiteur ;
• compte du débiteur ;
• agent du débiteur ;
• agent du créancier ;
• créancier ;
• compte du créancier ;
• montant ordonné ;
• devise ;
• partie supportant les frais ;
• identification du paiement ;
• identification de bout en bout ; et
• informations de remise.

La distinction essentielle est que la structure des données ne détermine pas le mécanisme de règlement.

Une instruction de paiement techniquement valide peut être reçue, authentifiée et acceptée par le système destinataire alors que le règlement financier correspondant demeure en suspens.

Ainsi :

Instruction reçue ≠ fonds reçus

Instruction authentifiée ≠ fonds réglés

Fichier importé avec succès ≠ bénéficiaire crédité de fonds définitifs

L'accusé de réception du serveur ≠ la confirmation de règlement

Cette distinction est fondamentale dans le traitement par IFB des méthodologies alternatives de transfert.

4. Protocoles de transmission

Les transmissions de fichiers IP ZIP institutionnels devraient s'effectuer exclusivement au sein d'un environnement de communication contrôlé et authentifié.

Selon l'accord technique bilatéral, la transmission peut recourir à des technologies telles que :

SFTP

Le protocole de transfert de fichiers sécurisé sur SSH assure un transport chiffré, l'authentification du serveur et une authentification contrôlée des utilisateurs.

L'authentification par clé publique devrait en principe être préférée à l'authentification par mot de passe seul pour la connectivité institutionnelle.

FTPS

Le FTP peut être protégé par TLS lorsque l'infrastructure héritée l'exige, sous réserve de la mise en œuvre d'une validation appropriée des certificats, de normes de chiffrement adéquates et de contrôles d'accès.

HTTPS / API REST

Le dossier peut être transmis par un point d'accès HTTPS authentifié ou une architecture d'API reposant sur TLS et sur une authentification applicative appropriée.

TLS mutuel

Pour les connexions institutionnelles exigeant un niveau d'assurance plus élevé, le TLS mutuel (mTLS) permet aux deux extrémités de s'authentifier réciproquement au moyen de certificats numériques.

Cela offre une protection sensiblement plus solide contre les terminaux non autorisés que la seule authentification unilatérale du serveur.

VPN

Un VPN IPSec site à site, ou équivalent, peut établir un tunnel privé chiffré entre les établissements participants avant que la transmission au niveau applicatif n'ait lieu.

Connectivité privée dédiée

Lorsque les volumes de transactions, les exigences de sécurité ou les profils de risque institutionnels le justifient, une connectivité par réseau dédié ou privé peut compléter ou remplacer la transmission par l'Internet public.

Le protocole précis doit être convenu bilatéralement avant l'activation opérationnelle.

5. Authentification des terminaux

L'établissement destinataire doit s'assurer que la transmission émane bien de l'établissement qu'elle prétend représenter.

Les contrôles pertinents peuvent notamment comprendre :

• certificats numériques institutionnels ;
• paires de clés SSH publique/privée ;
• certificats TLS mutuels ;
• identifiants d'API ;
• liste blanche d'adresses IP ;
• authentification VPN ;
• modules de sécurité matériels (HSM) ;
• épinglage de certificats (certificate pinning), le cas échéant ;
• authentification administrative multifacteur ;
• des comptes de service contrôlés ;
• des contrôles d'accès fondés sur les rôles ; et
• séparation des environnements de production et de test.

Une adresse IP ne constitue pas, à elle seule, une preuve suffisante de l'identité d'une institution.

De même, la possession d'un point d'accès, d'une connexion à un serveur, d'un identifiant d'API ou d'un mot de passe de fichier ZIP n'établit pas la propriété des fonds sous-jacents.

6. Chiffrement

La confidentialité devrait en principe être établie à plusieurs niveaux.

Chiffrement du transport

Le canal de communication devrait être chiffré au moyen d'un protocole contemporain correctement configuré, tel que TLS ou SSH.

Cela protège les informations en transit.

Chiffrement de la charge utile

Lorsque cela est requis, le dossier de transaction lui-même peut en outre être chiffré.

Cela assure la protection des informations financières indépendamment du canal de transport et peut réduire sensiblement l'exposition lorsque des fichiers sont stockés temporairement, acheminés par des infrastructures intermédiaires, archivés ou traités de manière asynchrone.

Chiffrement des données au repos

Les fichiers en attente de traitement doivent être protégés au sein d'environnements de stockage contrôlés, assortis de restrictions d'accès appropriées et d'un chiffrement au repos.

Le chiffrement établit toutefois la confidentialité. Il n'établit pas la validité financière de la transaction.

7. Intégrité cryptographique

L'établissement destinataire doit également être en mesure de déterminer si le lot transmis a été modifié après sa création.

Une empreinte cryptographique (hash) peut ainsi être générée pour le dossier ou pour chacun des fichiers qui le composent.

Par exemple :

Lot de transaction d'origine
→ génération d'une empreinte cryptographique
→ transmission du lot
→ calcul indépendant de l'empreinte par le système destinataire
→ comparaison de l'empreinte calculée avec l'empreinte transmise ou signée

Une discordance indique que le paquet reçu n'est pas cryptographiquement identique au paquet initialement authentifié.

Des algorithmes de hachage cryptographique contemporains, tels que les membres des familles SHA-2 ou SHA-3 selon ce qui convient à la mise en œuvre, peuvent être employés pour la vérification de l'intégrité.

8. Signatures numériques

Une signature numérique remplit une fonction sensiblement différente de celle du chiffrement.

Le chiffrement protège la confidentialité.

Le hachage contribue à établir l'intégrité.

Une signature numérique correctement mise en œuvre peut contribuer à établir :

1. authenticité - le paquet a été signé au moyen de la clé privée correspondante ;
2. intégrité - les données signées n'ont pas été modifiées par la suite ; et
3. responsabilité - la signature peut être rattachée à l'identifiant institutionnel concerné, sous réserve de l'infrastructure PKI et du cadre de gouvernance applicables.

L'établissement destinataire doit vérifier la signature au regard du certificat de confiance ou de la clé publique correspondant avant que l'instruction de transaction n'entre dans le circuit de traitement des paiements.

Les clés de signature privées doivent être protégées de manière appropriée, de préférence au moyen d'une infrastructure de gestion de clés institutionnelle et, le cas échéant, de modules de sécurité matériels (HSM).

9. Protection contre le rejeu et la duplication

La transmission de fichiers financiers exige des contrôles empêchant qu'une même instruction valide soit soumise de façon répétée.

Une architecture conçue de manière appropriée devrait donc intégrer des identifiants de transaction uniques et des contrôles adéquats tels que :

• identifiants de message uniques ;
• des identifiants de transaction uniques ;
• les horodatages ;
• numéros de séquence ;
• identifiants de fichiers ;
• détection des messages en double ;
• contrôles d'idempotence ;
• registres de suivi du statut de traitement ; et
• rapprochement avec les instructions précédemment traitées.

L'établissement destinataire doit rejeter, mettre en quarantaine ou examiner les instructions en double conformément à la procédure opérationnelle convenue.

10. Validation des fichiers

La bonne réception d'un fichier doit déclencher une validation, et non un règlement automatique.

Un environnement de traitement sécurisé peut soumettre le colis à plusieurs contrôles successifs :

Étape 1 – Validation du transport

Confirmation que le colis est parvenu par un canal autorisé.

Étape 2 – Authentification des terminaux

Confirmation du système émetteur et de ses références institutionnelles.

Étape 3 – Contrôles anti-logiciels malveillants et de sécurité des fichiers

Examen de l'archive et des fichiers qui la composent avant leur intégration dans l'infrastructure de paiement.

Étape 4 – Vérification cryptographique

Validation des empreintes (hash), des signatures et des certificats.

Étape 5 – Validation structurelle

Confirmation que les fichiers sont conformes au schéma convenu, aux conventions de nommage, à l'encodage des caractères et aux spécifications de données.

Étape 6 – Validation sémantique

Confirmation que les champs de paiement obligatoires sont présents et cohérents entre eux.

Étape 7 – Validation de l'opération

Validation de la devise, du montant, des comptes, des informations d'acheminement, des références de transaction et des instructions de règlement.

Étape 8 – Validation de la conformité

Contrôles en matière d'AML, de sanctions, de KYC/KYB, de surveillance des transactions et autres contrôles applicables.

Étape 9 – Validation du règlement

Confirmation de l'existence d'un mécanisme effectif permettant de régler la valeur financière correspondante.

Ce n'est qu'une fois ces contrôles achevés qu'une instruction doit être exécutée, conformément aux procédures applicables de l'établissement destinataire.

11. L'accusé de réception ne vaut pas règlement

Un environnement IP ZIP peut générer plusieurs accusés de réception techniques.

Par exemple :

ACK – Fichier reçu

Cela établit uniquement que le point de terminaison destinataire a bien obtenu le paquet.

ACK – Fichier authentifié

Cela établit que les contrôles d'authentification ont été menés à bien.

ACK – Fichier validé

Cela établit que le paquet satisfait à la validation structurelle ou technique applicable.

ACK – Instruction acceptée

Cela peut établir que l'instruction de paiement est entrée dans le circuit de traitement de l'établissement destinataire.

Aucun de ces états ne signifie nécessairement :

RÉGLÉ

Le règlement requiert un événement financier distinct.

La distinction est comparable à celle qui prévaut dans la messagerie financière conventionnelle, où la bonne remise et l'acceptation d'un message de paiement doivent être distinguées du règlement définitif de l'obligation monétaire sous-jacente.

12. Règlement de la transaction sous-jacente

Une fois qu'une instruction de paiement IP ZIP a été authentifiée, validée, acceptée et autorisée, la valeur monétaire sous-jacente doit être réglée par l'intermédiaire d'une infrastructure financière appropriée.

Selon les devises, les établissements et les juridictions concernés, le règlement peut s'effectuer par l'intermédiaire de :

• banque correspondante ;
• Comptes nostro/vostro ;
• comptes auprès de banques centrales ;
• Infrastructures de règlement brut en temps réel (RTGS) ;
• systèmes de compensation reconnus ;
• systèmes de paiement nationaux ;
• infrastructures de paiement instantané ;
• banques de règlement correspondantes ; ou
• tout autre dispositif de règlement juridiquement et opérationnellement reconnu.

14. Principe de sécurité

IFB applique une distinction fondamentale à l'ensemble des méthodologies alternatives de transfert :

Une transmission sécurisée prouve que les données peuvent être transmises en toute sécurité. Elle ne prouve pas que des fonds puissent être réglés.

• Le chiffrement ne constitue pas un justificatif de fonds.
• Une signature numérique ne prouve pas l'existence de fonds.
• Un solde affiché sur un serveur ne constitue pas la preuve de l'existence de fonds.
• Un fichier de transactions ne constitue pas un justificatif de fonds.
• Le succès de l'ingestion d'un fichier ne prouve pas l'existence des fonds.
• Un accusé de réception technique ne constitue pas une preuve de règlement.

La question financière déterminante demeure celle de savoir si l'établissement émetteur dispose d'une liquidité vérifiée et d'un circuit de règlement opérationnel capable de délivrer la valeur monétaire correspondante par le biais d'infrastructures bancaires reconnues.

15. Cadre d'acceptation d'IFB

IFB peut envisager des transmissions par IP ZIP uniquement pour les contreparties institutionnelles approuvées et les clients acceptés, à l'issue d'un examen technique, juridique et de conformité satisfaisant.

Avant l'établissement d'une connectivité de production, IFB peut exiger la vérification des éléments suivants :

• l'établissement à l'origine de l'opération ;
• l'habilitation institutionnelle à transmettre la transaction ;
• bénéficiaires effectifs et parties à la transaction ;
• origine et légitimité des fonds ;
• la finalité économique sous-jacente ;
• infrastructure d'émission et de réception ;
• la propriété des points de terminaison ;
• l'architecture IP et réseau ;
• méthodologie d'authentification ;
• certificats et justificatifs cryptographiques ;
• normes de chiffrement ;
• format de fichier et schéma ;
• structure des messages de paiement ;
• méthodologie d'identification des transactions ;
• protocole d'accusé de réception ;
• contrôles anti-doublons et anti-rejeu ;
• traitement des exceptions ;
• procédures de rapprochement ;
• les relations de correspondance bancaire ;
• comptes de règlement ;
• les dispositifs de liquidité ; et
• la voie de règlement ultime.

L'interopérabilité technique ne suffit pas à elle seule.

IFB ne considérera pas la transmission réussie d'un paquet IP ZIP comme une réception de fonds. L'opération n'est financièrement achevée que lorsque la valeur correspondante a été réglée avec succès via l'infrastructure bancaire ou de règlement convenue et que le règlement peut être rapproché de manière indépendante.

Principe fondamental

IP ZIP est la transmission sécurisée d'une instruction. Le règlement est le mouvement de la valeur financière correspondante.

Les deux processus peuvent faire partie du même flux de travail d'une transaction, mais ils ne constituent pas un seul et même événement.

Dans la terminologie bancaire institutionnelle :

Transmission du message → authentification → validation → acceptation → exécution → règlement → rapprochement

Seul l'achèvement du processus de règlement applicable établit que le volet monétaire de la transaction a été exécuté.

La terminologie associée aux méthodes de transfert alternatives ou historiques doit être interprétée dans le contexte de l'infrastructure bancaire. Ces termes peuvent désigner des canaux de communication, des méthodes de traitement internes ou des pratiques historiques, mais ils ne se substituent pas à l'exigence de recourir à des établissements réglementés, à des systèmes de paiement reconnus et à des procédures de règlement formelles.

Tout transfert, quelle que soit sa dénomination, doit en définitive être traité, compensé et rapproché au sein du système financier établi.

Si vous souhaitez en savoir davantage sur la manière de transférer des fonds ou des actifs vers vos comptes auprès de nous, veuillez prendre contact avec Marie Mayer.