Pour pouvoir utiliser la plateforme, il est nécessaire que le service web soit connecté au système de gestion des institutions.

L’échange englobe toutes les données qui figurent sur le décompte de sortie des personnes assurées du 2e pilier (prescription LPP). Il s’agit notamment des données de base (nom, prénom, date de naissance, sexe, n° AVS et adresse) ainsi que des données administratives (part LPP, versements anticipés EPL, solde à l’âge de 50 ans, solde au mariage, informations sur les mises en gage et les versements anticipés, etc.) de la personne

BVG Exchange a été développé par la Fondation institution supplétive LPP. Elle est ainsi responsable de l’ensemble de l’infrastructure, de sa maintenance et de son développement.

Non, le code source n’est pas open source. Une implémentation de référence qui utilise le service web de BVG Exchange et constitue une connexion possible (Command Line Client) est accessible au public.

Voir les conditions d’utilisation, point 7.7 (« Sécurité et protection des données ») : les données transmises par une utilisatrice à des fins de transfert de la prestation de libre passage sont conservées au plus pendant six mois sur la plateforme. Elles sont ensuite effacées, même si elles n’ont pas encore été téléchargées par l’institution de prévoyance ou de libre passage destinataire. Les données collectées seront effacées au bout de 30 jours. 

Les copies de sauvegarde (back-ups), qui sont conservées à part et utilisées exclusivement à des fins de restauration de BVG Exchange (Disaster Recovery), seront effacées trois mois après leur création.
 

Dans la mesure où les données ne sont pas conformes au schéma, la réception sera rejetée directement par la plateforme BVG Exchange. Les données qui ne sont pas complètement transmises sont conservées sur la plateforme au plus pendant six mois. Elles sont ensuite effacées.
Les données entièrement transmises seront effacées au bout de 30 jours.

Pour BVG Exchange, deux comptes sont créés par défaut – l’un pour l’environnement de test et l’autre, pour l’environnement productif.

Environnement de test exchange-test.aeis.ch :
0000_demo ne peut être utilisé que pour l’utilisation du client de démonstration inclus (Command Line Client).
java -jar BVGExchangeClient-x.x.x.jar -demo -u 0000_demo -p password
0000_demo permet d’envoyer (submit) et de recevoir (receive) pour la DEMO_IP contenue dans les demo XMLs fournies.

Environnement productif exchange.aeis.ch :
0000_ws est le compte pour envoyer et recevoir les documents des institutions de prévoyance.
java -jar BVGExchangeClient-x.x.x.jar -run -u 0000_ws -p password

Une InaccessessibleWSDLException indique que le service web n’est pas accessible. Cela peut être dû aux raisons suivantes :

• Le service web n’est temporairement pas joignable. – Ce problème devrait être réglé dans les plus brefs délais.
• Le client local ne peut pas se connecter au service web. De nombreux réseaux d’entreprise empêchent l’accès aux services web inconnus. – Veuillez demander à votre administrateur de vérifier la connexion de réseau.

Le client BVG Exchange prend en charge proxyHost et proxyPort en tant qu’options de Command Line. 

Seuls les comptes de démonstration « xy_demo » sont autorisés à remettre des documents pour cette institution. Convertissez l’EXPÉDITEUR/UID dans XML en celui de votre institution ou utilisez le compte de démonstration fourni pour remettre le document.

Les autorisations sont accordées explicitement pour envoyer et recevoir des documents. Cette erreur signifie que l’utilisateur « xy » a essayé de recevoir un document sans posséder les autorisations nécessaires pour cette institution. Dans l’environnement de test BVG Exchange, un utilisateur a le droit d’envoyer et de recevoir des données pour son institution. 

Dans l’environnement productif, seuls les utilisateurs auxquels l’institution correspondante a accordé le droit de recevoir des documents sont autorisés.

Veuillez tenir compte de cette différence lorsque vous passez de l’environnement de test à l’environnement productif.

Il n’existe pas de Release Cycles prédéfinis. Les releases sont effectuées en fonction des besoins (modification de loi, ordonnances, etc.). Les releases sont annoncées à l’avance et sont généralement rétrocompatibles.

Des rétrocompatibilités existent en ce qui concerne les spécifications de schémas pour les fournitures des données. 

Actuellement, l’interface est rétrocompatible jusqu’au schéma 1.0 inclus.

Un environnement séparé est disponible pour les tests des partenaires. Nous ne pouvons pas estimer le temps que prennent les tests du côté des partenaires.

En interne, nous estimons le test à environ trois journées de travail pour une modification de schéma.

Sur demande, l’environnement de test peut être proposé avec plusieurs accès pour un partenaire afin que celui-ci puisse tester un cycle complet.

Aucun Load Testing spécifique n’a été effectué. Même si toutes les transmissions au sein du 2e pilier étaient traitées par BVG Exchange, la quantité de données est à coup sûr dans les limites de la capacité de l’infrastructure sous-jacente. 

Les partenaires déterminent les fonctionnalités de BVG Exchange qu’ils souhaitent utiliser (p. ex. seulement recevoir ou seulement envoyer). De la même manière, les partenaires décident quelles institutions participantes peuvent recevoir des données électroniques et lesquelles ne le peuvent pas.

Les éventuelles extensions des services offerts sont toujours proposées sous forme d’Opt-in.

Il existe un environnement de test avec des logins spécifiques, qui est disponible pour tous les partenaires. L’environnement de test est en principe toujours disponible, mais nous ne pouvons pas le garantir. 

Outre l’Application Programming Interface (API), qui permet un test automatisé de l’envoi et de la réception, les partenaires disposent également d’une interface utilisateur qui leur fournit un aperçu des données envoyées.

Il n’existe aucune possibilité de paramétrage empêchant la création d’un avis groupé. L’institution est libre de décider si elle transmet un nouveau fichier à BVG Exchange Transfer pour chaque personne assurée ou si elle les résume dans un seul avis. 

Depuis le schéma 1.6, BVG Exchange peut déclencher un avis séparé pour une personne assurée en appelant la méthode API « ExchangeWS#getPdf ». Les deux derniers paramètres permettent de déterminer pour quelle personne assurée l’avis doit être créé (il suffit de cocher l’une des deux options). Vous trouverez de plus amples informations dans la documentation Java sous le lien suivant : https://exchange.aeis.ch/exchange-server/doc/apidocs/index.html 

Nous utilisons cette méthode dans notre système pour archiver l’annonce de sortie pour chaque personne assurée en cas d’avis groupé. Cela signifie que nous recevons d’abord l’avis groupé, puis demandons, dans BVG Exchange, l’annonce de sortie pour chaque personne assurée au moyen du numéro d’assurance sociale.

l’interface peut être consultée à l’adresse suivante : https://exchange.aeis.ch/service/doc/apidocs/index.html 

La communication se fait exclusivement via HTTPS ; le port est 443.
Les points de terminaison pour l’interface sont

• Environnement productif : https://exchange.aeis.ch/exchange-server/ExchangeService_1_0?wsdl
• Environnement de test : https://exchange-test.aeis.ch/exchange-server/ExchangeService_1_0?wsdl

Non. Le PDF est avant tout créé pour la personne qui le reçoit, directement dans sa langue. Si aucune langue de correspondance n’est définie pour le destinataire dans XML, le document est créé dans sa langue préférée.

Si le destinataire le souhaite, il est possible de modifier la langue en mettant par exemple la balise « UEBERTRAGUNG.EMPFAENGER.KORRESPONDENZ_SPRACHE » sur « FR » dans XML.

La dernière étape d’un transfert de données est la confirmation de la réception des données par l’institution de prévoyance destinataire. Cela signifie que si le transfert a été techniquement réussi, elle doit le confirmer à BVG Exchange. Ce n’est qu’ensuite que le statut est mis sur « Done ».

Certains éditeurs de logiciels n’ont toutefois pas implémenté cette dernière confirmation et le statut reste donc « PENDING_RECEIPT ». Nous sommes en contact avec les éditeurs de logiciels pour que cette dernière étape soit également implémentée. C’est important, par exemple pour pouvoir télécharger à nouveau les données transmises en cas de problèmes techniques.

Pour l’institution de prévoyance émettrice, le statut ne joue aucun rôle, la communication avec l’institution de prévoyance destinataire a eu lieu via BVG Exchange même si elle n’est pas marquée comme telle. Le statut n’indique donc pas une erreur de transmission.

En principe, les deux canaux d’échange peuvent être utilisés, mais une seule variante est possible par prestation de libre passage. Lorsqu’une PLP est transmise à la fois par voie électronique et par voie postale, cela entraîne un surcroît de travail évitable et des sources d’erreurs potentielles.

Le portail permet d’annuler le transfert.

Veuillez contacter directement l’expéditeur. 

Non, le fait d’avoir trouvé une correspondance ne signifie pas que l’avoir de prévoyance doit être transféré à la nouvelle institution de prévoyance. Parallèlement à la saisie dans BVG Exchange Match, il est toujours possible de demander directement à la personne assurée où elle souhaite transférer l’avoir. Il s’agit donc uniquement d’une possibilité supplémentaire de trouver l’institution de prévoyance appropriée pour le transfert.

Une entrée peut être annoncée dès que la date d’entrée est connue. Il est important de savoir que de l’argent peut être potentiellement transféré par une autre institution dès que l’entrée a été annoncée. Il peut être judicieux d’accorder un délai à la personne assurée afin qu’elle puisse décider d’envoyer les données à BVG Exchange Match ou non. 

Une sortie peut être annoncée dès que la date de sortie de la personne assurée est connue. Il peut être judicieux d’accorder un délai à la personne assurée afin qu’elle puisse décider d’envoyer les données à BVG Exchange Match ou non. 

Non, le nombre de correspondances possibles dépend du nombre d’institutions de prévoyance participantes et de la qualité de leurs données. Plus les institutions de prévoyance décident de gérer les entrées et les sorties dans BVG Exchange Match, plus les chances d’obtenir une correspondance sont élevées.

Non, étant donné que les correspondances dépendent des données transmises par les institutions de prévoyance, il peut également y avoir des correspondances dites « fausses positives ». C’est par exemple le cas lorsqu’une institution de prévoyance n’annule pas l’entrée d’une personne assurée alors que celle-ci est déjà sortie.

Voir les conditions d’utilisation, point 7.6 (« Sécurité et protection des données ») : lors de l’utilisation de BVG Exchange Match, les données personnelles (numéro d’assurance sociale et date de naissance) sont traitées de manière pseudonymisée. Pour ce faire, l’utilisatrice transmet une valeur de hachage générée à partir du numéro d’assurance sociale et de la date de naissance. BVG Exchange Match vérifie s’il existe une correspondance en comparant les valeurs de hachage des avis d’entrée et de sortie. BVG Exchange Match propose à l’utilisatrice de générer la valeur de hachage. Les données personnelles traitées à cet effet ne sont pas sauvegardées.

L’utilisatrice peut révoquer elle-même les avis d’entrée et de sortie qu’elle déclare via Match (valeurs de hachage). En cas de révocation, les valeurs de hachage sont supprimées automatiquement. En l’absence de révocation de la part de l’utilisatrice, les valeurs de hachage ne sont supprimées que lorsque l’utilisatrice ne participe plus à BVG Exchange.