Technical issues
General technical questions
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.
Technical questions about BVG Exchange Transfer
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.
For specifications and connecting to the service, see How does BVG Exchange Transfer work? And for general information, see BVG Exchange Transfer.
For legal provisions, see also the general Terms and Conditions of Use of BVG Exchange.
Technical questions about BVG Exchange Match
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.
For specifications and connecting to the service, see How does BVG Exchange Match work? And for general information, see BVG Exchange Match.
For legal provisions, see also the general Terms and Conditions of Use of BVG Exchange.
Technical questions about BVG Exchange Payment Validation
All payment details are validated and documented by one of the following variants:
- The payment details belong to an occupational benefits institution that has not yet been entered: A validation form is sent to the associated bank, which confirms by signature that these payment details correspond to those of the occupational benefits institution.
- The payment details belong to an occupational benefits institution that is already known: A validation form is sent to the occupational benefits institution, which confirms by signature that these payment details correspond to the occupational benefits institution.
- The payment details belong to an occupational benefits institution which has its own payment details for each affiliation: The payment details can be found on an official document from this occupational benefits institution.
The collected documents are stored in the system for documentation purposes.
An occupational benefits institution can have several active payment details for a variety of reasons. If you do not know which ones to use, please contact the relevant occupational benefits institution.
For specifications and connecting to the service, see How does BVG Exchange Payment Validation work? And for general information, see BVG Exchange Payment Validation.
For legal provisions, see also the general Terms and Conditions of Use of BVG Exchange.
Legal issues
BVG Exchange is an in-house product of the Substitute Occupational Benefit Institution. The platform is thus the property of the foundation.
To authenticate the SOAP web service, the user name and password are transmitted to the application server in the request body. The application server checks via the Identity and Access Management system whether the user is valid and has assigned the necessary authorisations for the action to be performed. A user can only deliver or receive documents for their institution that have been delivered to their institution. In addition, there are super-users (only Substitute Occupational Benefit Institution IT) who can request documents from all institutions within the scope of the Terms and Conditions of Use.
The active IT infrastructure for web hosting is operated in a computing centre in Zurich. The computing centre is ISO 27001 certified. Access to the servers of the Substitute Occupational Benefit Institution is restrictive, monitored and logged.
See point 7.4 of the Terms and Conditions of Use, Data security and data protection: With the exception of Liechtenstein, there is no cross-border data processing. Cross-border data processing with Liechtenstein takes place exclusively in the context of the contractual use of BVG Exchange by Liechtenstein occupational benefits institutions.
There is no geo-filter for accessing the BVG Exchange web service. This means that the web service can also be accessed from abroad. Data processing by BVG Exchange takes place in Switzerland
Pursuant to Art. 1 para. 2 VBO, the insured person is obliged to inform the occupational benefits institution prior to departure to which new occupational benefits institution or vested benefits institution the termination payment is to be transferred. If it fails to meet this obligation, the occupational benefits institution will also be unable to meet its obligations, namely to transfer the termination payment either to the new occupational benefits institution (see Art. 3 para. 1 VBA) or to a vested benefits institution (see 4 para. 1 VBA). Furthermore, the occupational benefits institution may demand the termination payment from the previous pension fund relationship as well as the actuarial capital from a form of pension protection for the account of the insured person (Art. 11 para. 2 VBA).
Pursuant to Art. 85a BVG/LPP, occupational benefits institutions are authorised to process or have processed the personal data, including particularly sensitive personal data, that they require in order to fulfil the tasks assigned to them under the Vested Benefits Act.
Personal data must be processed in order for an occupational benefits institution to be able to fulfil the tasks assigned by law and described above. In this respect, data processing via BVG Exchange has a corresponding legal basis.
The confidentiality of data processing is governed in detail in point 10 of the General Terms and Conditions of Use.
Yes, in accordance with Art. 19 of the Swiss Federal Act on Data Protection (FADP), the occupational benefits institution must inform the insured person that they should ask the BVG Match Service for a notification of admission if they fail to comply with their notification obligation (see Art. 1 para. 2 VBO). The occupational benefits institution may include this information in the termination form, for example.
Further answers are available in the general Terms and Conditions of Use of BVG Exchange.