The web service must be connected to the administration system of the institutions to use the platform.

The exchange includes all data on the termination statements of insured persons in the second pillar (mandatory BVG). In particular, this includes the person’s master data (surname, first name, date of birth, gender, OASI no. and address) and administrative values (BVG/LPP share, withdrawals for home ownership, balance at age 50, balance on marriage, information on pledges and withdrawals, etc.).

BVG Exchange was developed by the Substitute Occupational Benefit Institution. It is therefore responsible for the entire infrastructure as well as its maintenance and further development.

No, the source code is not open source. A reference implementation that uses the BVG Exchange web service and has a possible connection is publicly accessible (Command Line Client).

See point 7.7 of the Terms and Conditions of Use, Data security and data protection: The data transmitted by a user for transferring a vested benefit is stored on the platform for a maximum of six months and then deleted, even if it has not yet been accessed by the recipient occupational benefits institution or vested benefits institution. Collected data is deleted after 30 days. 

Back-ups that are stored separately and used solely for the purpose of BVG Exchange restoration (disaster recovery) are deleted three months after creation.

If data is not compatible with the schema, the BVG Exchange Platform will not accept direct receipt. Data that has not been transmitted in full is stored on the platform for a maximum of six months and then deleted.

Fully transmitted data is deleted after 30 days.

Two accounts are standard for BVG Exchange – one for the test and one for the productive environment.

Test environment exchange-test.aeis.ch:
0000_demo is only for use by the designated Demo Client (Command Line Client).
java -jar BVGExchangeClient-x.x.x.jar -demo -u 0000_demo -p password
0000_demo is authorised for sending (submit) and receiving (receipt) of the DEMO_OBI, which is included in the delivered demo XMLs.

Productive environment exchange.aeis.ch:
0000_ws is the account for sending and receiving documents from occupational benefits institutions.
java -jar BVGExchangeClient-x.x.x.jar -run -u 0000_ws -p password

An InaccessessibleWSDLException indicates that the web service is unavailable. This may be due to the following reasons:

• The web service is temporarily unavailable. – This problem should be rectified as soon as possible.
• The local client is unable to connect to the web service. Many company networks prevent access to unknown web services. – Please have your administrator check the connection of your network.

The BVG Exchange Client supports proxyHost and proxyPort as Command Line options. 

Only «xy_demo» demo accounts are authorised to submit documents for this institution. Change the SENDER/UID in XML to the correct value for your institution or use the demo account provided to submit the document.

Authorisations are granted explicitly for sending and receiving documents. This error means that user «xy» has tried to receive a document without having the necessary authorisations for this institution. In the BVG Exchange test environment, users have the right to both send and receive data for their institution. 

Only users who have been explicitly granted the right of receipt for the institution in question are permitted in the productive environment.

Please note this difference when switching from the test environment to the productive environment.

There are no predefined release cycles. Releases are carried out as required (legislative changes, ordinances, etc.). Releases are announced at an early stage and are generally downwardly compatible.

There are downward compatibilities with regard to the schematic specifications for the data deliveries. 

The interface is currently downwardly compatible up to and including Schema 1.0.

There is a dedicated environment for testing by partners. We are unable to estimate the amount of testing required.

In-house we calculate a testing duration of about three working days for a schema change.
If desired, the test environment can be offered with several access points for a partner so that they can test a complete run.

There was no specific load testing. The data volume is guaranteed to be within the capacity of the underlying infrastructure – even if all transmissions within the second pillar were processed via BVG Exchange. ​​​​​​

The partners decide which BVG Exchange functionalities they want to use (e.g. only receive; only send). The partners also decide which affiliated institutions may and may not be provided with electronic data.

Any extensions to the available services are always offered as an opt-in.

There is a test environment with individual logins, which is available to all partners. The test environment is always available as a rule, but there is no guarantee. 

In addition to the Application Programming Interface (API), which enables automated testing of send and receipt, partners also have access to a user interface that provides details of data sent.
 

There is no configuration option to prevent group messages from being created. It is up to the institution whether it sends a new file to BVG Exchange Transfer for each insured person or summarises this in a message. 

Since Schema 1.6, a separate BVG Exchange message can be triggered for an insured person via the API method «ExchangeWS#getPdf». The last two parameters can be used to determine for which insured person the report should be generated (only one of the two options has to be set). Details can be found in the Java doc under the following link: https://exchange.aeis.ch/exchange-server/doc/apidocs/index.html 

We use this method in our system to archive the notice of termination for each insured person in the event of a group message. This means we first receive the group message and request the notice of termination for each insured person via the BVG Exchange social insurance number.

The Command Line Client connects to the BVG Exchange SOAP interface. The documentation for the interface is available via the following link: https://exchange.aeis.ch/service/doc/apidocs/index.html 

Communication is exclusively via HTTPS; the port is 443.
Endpoints for the interface are

• Productive environment: https://exchange.aeis.ch/exchange-server/ExchangeService_1_0?wsdl 
• Test environment: https://exchange-test.aeis.ch/exchange-server/ExchangeService_1_0?wsdl

No. The PDF is created primarily for the recipient – directly in their language. If no correspondence language is defined for the recipient in XML, the document is created in their preferred language.

However, the language can be overridden at the request of the recipient, for example by setting the tag «UEBERTRAGUNG.EMPFAENGER.KORRESPONDENZ_SPRACHE» to «FR» in XML.  

The final step of a data transfer is that the receiving occupational benefits institution confirms receipt of the data. This means that if the transfer was technically successful, the occupational benefits institution should provide confirmation thereof to BVG Exchange. Only then is the status set to «Done». 

However, there are some software manufacturers that have not implemented this final confirmation and therefore the status remains at «PENDING_RECEIPT». We are in contact with the software manufacturers to ensure that this final step is also implemented. This is important so the transmitted data can be retrieved in the event of technical problems, for example. 

The status is irrelevant for the sending occupational benefits institution; communication with the receiving occupational benefits institution via BVG Exchange has taken place, even if it is not marked as such. In other words, the status does not represent a transmission error.

Both channels can be used in principle – but only one variant per vested benefit. If a vested benefit is transmitted both electronically and by post, this leads to avoidable additional work and potential sources of error.

It is possible to reverse the transfer on the portal.

Please contact the sender directly. 

No, an identified match does not mean that the pension assets have to be transferred to the new occupational benefits institution. At the same time as the entry in BVG Exchange Match, the insured person can still be asked directly where they would like the credit to be transferred. This is simply another way of finding the correct occupational benefits institution for the transfer.

A new employee can be reported as soon as the entry date is known. It is important that any money due is transferred from another institution as soon as the new employee has been reported. It may make sense to adhere to a period granted to the insured person so they can decide whether the data should be sent to BVG Exchange Match. 

A departure can be reported as soon as the departure date of the insured person is known. It may make sense to comply with a deadline notified to the insured person so they can decide whether the data should be sent to BVG Exchange Match.

No, the number of possible matches is determined by the number of affiliated occupational benefits institutions and their data quality. The more occupational benefits institutions decide to manage new and departing employees in BVG Exchange Match, the greater the chance of getting a match.

No, as the matches depend on the data submitted by the occupational benefits institutions, so-called «false positives» may also occur. This happens, for example, if an occupational benefits institution does not delete the admission of an insured person even though the insured person has actually already left the institution.

See point 7.6 of the Terms and Conditions of Use, Data security and data protection: When using BVG Exchange Match, personal data (social insurance number and date of birth) are processed in anonymised form. For this purpose, the user submits a
hash value based on the social insurance number and date of birth. BVG Exchange Match checks a match by comparing the hash values of the notices of admission and termination. The creation of the hash value is offered to the user via BVG Exchange Match, whereby the personal data processed for this purpose is not stored.

The user may also revoke their notices of admission and termination (hash values) notified via Match. Revocation automatically results in deletion of the hash values. If the user does not revoke their consent, the hash values will only be deleted if the user is no longer connected to BVG Exchange.