Trois modèles d’adresse coexistent actuellement :

1. L’adresse entièrement structurée

Chaque composant de l’adresse est renseigné dans un champ dédié.

Par exemple :

• Street Name : Rue Villeneuve

• Building Number : 82

• Post Code : 92110

• Town Name : Clichy

• Country : FR

Cette approche permet aux systèmes d’identifier immédiatement la nature de chaque information.

Elle représente le modèle cible privilégié lorsque les données nécessaires sont disponibles.

2. L’adresse hybride

Le format hybride permet de combiner des éléments structurés avec des lignes d’adresse conservées en texte libre.

Deux informations doivent notamment être renseignées dans leurs champs structurés :

• Town Name 

• Country

Les autres informations peuvent, selon les règles applicables, être renseignées dans les champs structurés disponibles ou conservées dans des Address Lines (AdrLine).

Ce modèle facilite la transition pour les organisations dont les référentiels ne permettent pas encore de décomposer entièrement toutes les adresses.

3. L’adresse entièrement non structurée

Dans ce modèle, l’adresse est principalement transmise sous forme de texte libre.

Par exemple :

AdrLine : 82 Rue Villeneuve
AdrLine : 92110 Clichy, France

C’est ce modèle que la communauté Swift prévoit de supprimer à terme pour les messages concernés.

Il est important de distinguer deux notions : la présence d’une adresse et la manière dont cette adresse est structurée.

Les nouvelles exigences ne signifient pas qu’une adresse devient automatiquement obligatoire dans tous les paiements. En revanche, lorsqu’une adresse est requise et transmise dans un flux soumis à ces règles, elle devra respecter le format attendu.

• Retour d’échange : certaines PA ont pu rejeter des factures lorsque le destinataire n’était pas encore prêt ou lorsque l’adressage / l’interopérabilité n’était pas opérationnel. Ce comportement ne doit pas être assimilé automatiquement à une non-conformité de la facture.
• Des écarts d’implémentation peuvent exister entre plateformes. Les contrôles réglementaires s’appuient sur les spécifications et normes applicables ; une plateforme peut toutefois avoir ajouté ses propres contrôles techniques.
• Les plateformes agréées ont passé des tests techniques et d’interopérabilité mais cela n’exclut pas des incidents opérationnels lors des premiers échanges.