Adresses structurées dans les ordres de paiement

Q: Exigences pour SWIFT MT101

Champ 59 (option F) L'option F doit être utilisée dans le champ 59. Au minimum, « nom », « ville » et « pays » doivent être transmis. En outre, à partir de la sous-zone 2 (nom et adresse), chaque ligne, si elle est disponible, doit commencer par l'un des numéros suivants et chaque numéro doit être suivi d'une barre oblique «/»: Exemple pour le champ 59 (option F) :59F:/CHYY00231231nnnnnn02Y 1/ELISABETH EXEMPLE 2/BAHNHOFSTRASSE 6 3/CH/EXEMPLEVILLE Pour les ordres débités sur un compte auprès d'une banque tierce (multibanking), le champ 50 doit être formaté de la même manière. De plus amples informations sont disponibles dans le guide de formatage MT101 .

Afin de répondre aux exigences des autorités réglementaires mondiales en matière de surveillance et de prévention plus transparentes du blanchiment d’argent, la place financière suisse a décidé qu’une indication structurée des données d’adresse était nécessaire pour les transactions de paiement. Sont concernés tous les champs d’adresse des parties impliquées (débiteur, créancier et établissements financiers) d’un ordre de paiement, tant au niveau national qu’international, via SIC, SWIFT et SEPA.

Les clients qui créent des ordres de paiement via leur propre logiciel de comptabilité (pain.001, pain.008 SDD ou MT101) et les transmettent à �鶹�� doivent s’assurer que leur logiciel a été mis à jour conformément aux nouvelles exigences du marché afin que les ordres contiennent des données d’adresse structurées au plus tard le 14 novembre 2026.

À compter du 14 novembre 2026, si les ordres de paiement ne sont pas structurés comme attendu, �鶹�� ne pourra plus les traiter.

Veuillez tenir compte des informations suivantes pour l’établissement de QR-factures via le logiciel.

�鶹�� prend en charge trois options différentes pour structurer les données d’adresse dans les fichiers de paiement pain.001 et pain.008 SDD conformément aux nouvelles exigences.��Les exigences pour SWIFT MT101 peuvent être consultées ci-dessous.

Option I : exigence minimale
Transmettre le « nom », la « ville » et le « pays » dans des champs séparés (structurés).
�鶹�� soutient cette option dès maintenant.
Option I en détail
Option II : adresses entièrement structurées
Outre les exigences minimales « nom », « ville » et « pays », d’autres champs de données d’adresse structurés sont transmis, tels que le nom de rue, le numéro de maison ou le numéro postal d'acheminement.
Nous recommandons de transmettre des adresses entièrement structurées afin d’éviter les refus de paiement en cas de paiements transfrontaliers
�鶹�� soutient cette option dès maintenant
Option II en détail
Option III : modèle hybride
Outre les exigences minimales « nom », « ville » et « pays », des données d’adresse supplémentaires peuvent être transmises de manière non structurée.
Cette option sera prise en charge à partir du 22 novembre 2025 avec la nouvelle version ISO 20022 (2019).
Option III en détail

Glissement 1-3

�鶹�� recommande de procéder à une mise à jour dès que l'occasion se présente, mais au plus tard le14 novembre 2026. À partir de cette date, les fichiers de paiement ne pourront plus être transmis qu’avec l’une des variantes structurées décrites ci-dessus.��Lors de la mise en œuvre de la structuration de vos données d'adresses, vous recevrez le soutien de votre service informatique ou de votre partenaire logiciel.

Calendrier de mise en œuvre des addresses structurées dans les ordres de paiement

Option I : exigence minimale

Afin de satisfaire aux exigences minimales en matière d’adresses structurées et de continuer à garantir un traitement sans problème de vos ordres de paiement, il faut transmettre au moins le « nom », la « ville » et le « pays » de manière structurée dans des champs séparés. Cette option peut être mise en œuvre immédiatement.

Debtor / Creditor Information

Structure XML de l’exigence minimale

<Nm>Elisabeth Exemple</Nm>
<PstlAdr>
�� <TwnNm>Exempleville</TwnNm>
�� <Ctry>CH</Ctry>
</PstlAdr>

Option II : adresses entièrement structurées – notre recommandation

Dans le cas des paiements transfrontaliers, des refus de paiement peuvent parfois survenir, indépendamment des exigences réglementaires et spécifiques à chaque pays, si les données d’adresse de la banque destinataire transmises ne suffisent pas. Pour éviter cette situation, nous recommandons l’utilisation d’adresses entièrement structurées. À cette fin, d’autres champs de données d’adresse structurés doivent être transmis, tels que le nom de la rue, le numéro de maison et le numéro postal d’acheminement. Cette option peut être mise en œuvre immédiatement. Tous les champs de données d’adresse structurés prévus par les �鶹�� Implementation Guidelines peuvent être utilisés.

L’exemple suivant correspond à une recommandation d’�鶹�� :

Debtor / Creditor Information

Option II : adresses entièrement structurées – notre recommandation

Structure XML de la recommandation

<Nm>Elisabeth Exemple</Nm>
<PstlAdr>
�� <StrtNm>Bahnhofstrasse</StrtNm>
�� <BldgNb>6</BldgNb>
�� <PstCd>9999</PstCd>
�� <TwnNm>Exempleville</TwnNm>
�� <Ctry>CH</Ctry>
</PstlAdr>

Option III : modèle hybride

Le modèle hybride correspond à l’option « exigence minimale », mais il est possible de transmettre sous une forme combinée des données d’adresse supplémentaires avec deux champs de données d’adresse non structurés <AdrLine>.��Cette option sera prise en charge à partir du 22 novembre 2025 avec la nouvelle version ISO 20022 (2019).

Debtor / Creditor Information

Structure XML de l’adresse hybride

<Nm>Elisabeth Exemple</Nm>
<PstlAdr>
�� <TwnNm>Exempleville</TwnNm>
�� <Ctry>CH</Ctry>
�� <AdrLine>Bahnhofstrasse 6</AdrLine>
�� <AdrLine>9999</AdrLine>
</PstlAdr>

Exigences pour SWIFT MT101

Champ 59 (option F)

L'option F doit être utilisée dans le champ 59.��Au minimum, « nom », « ville » et « pays » doivent être transmis. En outre, à partir de la sous-zone 2 (nom et adresse), chaque ligne, si elle est disponible, doit commencer par l'un des numéros suivants et chaque numéro doit être suivi d'une barre oblique «/»:

��

Nombre	Contenu	Instruction
1	Nom du client bénéficiaire	Le numéro suivi d'une barre oblique « / » doit être suivi du nom du client bénéficiaire.
2	Adresse	Le numéro suivi d'une barre oblique « / » doit être suivi d'une ligne d'adresse (la ligne d'adresse peut être utilisée pour indiquer, par exemple, le nom et le numéro de la rue, le nom du bâtiment ou le numéro de la boîte postale).
3	Pays et ville	Le numéro suivi d'une barre oblique « / » doit être suivi du code ISO du pays.Celui-ci est à son tour suivi d'une barre oblique « / », puis la ville doit être spécifiée.

Exemple pour le champ 59 (option F)

:59F:/CHYY00231231nnnnnn02Y
1/ELISABETH EXEMPLE
2/BAHNHOFSTRASSE 6
3/CH/EXEMPLEVILLE

Pour les ordres débités sur un compte auprès d'une banque tierce (multibanking), le champ 50 doit être formaté de la même manière.

De plus amples informations sont disponibles dans le guide de formatage MT101 (PDF, 335 KB) .

Le 21 novembre 2025, de nouvelles règles s’appliquent en matière de QR-factures: à partir de cette date, seules des adresses structurées (type d’adresse «S») pourront être utilisées dans les codes QR suisses. Cela signifie que votre propre adresse (émetteur de la facture) ainsi que celle des débiteurs (destinataires de la facture) doivent être structurées en éléments distincts.

Les QR-factures créées avec le ��contiennent déjà des adresses structurées comme l’exigent les nouvelles règles.

Si vous générez encore des QR-factures contenant des données d’adresses non structurées (type d’adresse «K») via un autre logiciel, nous vous conseillons de les modifier d’ici au 21 novembre 2025 au plus tard. Après cette date, il ne faudra plus utiliser de QR-factures contenant des adresses non structurées pour la facturation. En effet, elles ne pourront être payées que pendant très peu de temps encore.��Si vous n'êtes pas sûr que vos QR-factures utilisent déjà des adresses structurées, vous pouvez vérifier dans le , sous le point «Outils pour les émetteurs de factures», si le type d'adresse utilisé est structuré (type d'adresse «S»).

N’oubliez pas que les QR-factures émises longtemps à l’avance (par exemple pour le�� paiement d’acomptes de leasing ou de loyers) sont potentiellement réglées via un ordre permanent ou via des modèles de paiement. Planifiez assez de temps pour modifier ce type de factures. Le cas échéant, il peut être nécessaire de rééditer ces QR-factures et de les transmettre suffisamment à l’avance aux débiteurs.

Pour la mise en œuvre technique, consultez les «Implementation Guidelines pour QR-facture» de SIX (www.six-group.com). Pour la structuration de vos données d’adresse, vous pouvez vous faire aider par votre service informatique ou votre partenaire logiciel externe.��

Option I : exigence minimale

Option II : adresses entièrement structurées

Option III : modèle hybride

Aide

Produits

Domaines d'activité

À notre propos