Testing instructions for stakeholders

These instructions were last updated on 01 April 2026. References to the first and second stage of the register were deleted, the names of the stakeholder testing environments were updated and clarifications were made. 

1 Purpose and objectives

These instructions are for operators participating in the Positive credit register’s stakeholder testing. The instructions relate to stakeholder testing of the register’s current and future functionalities.

The stakeholder testing participants include

•    organisations reporting loan data to the Positive credit register
•    lenders using credit register extracts
•    credit information companies
•    authorities using the register’s data.

The testing focuses on technical APIs. Data can be reported to the Positive credit register and requested from the register only through APIs, so all data notifiers must prepare for the use of an API solution and perform stakeholder testing before the rollout so as to make sure the APIs work as required.

The testing allows stakeholders to make sure they are technically capable of reporting data to the register and requesting data from the register. The testing environments can be used to perform continuous regression testing, for example, or to test new functionalities. When testing the APIs, the stakeholders can make sure that their own systems and processes work in the appropriate manner. Each stakeholder is responsible for building their own APIs and for making sure they conform to law.

The data used in testing must be artificial or anonymised and it may not be connectable to natural persons or their data. Personal identity codes or other data that can be connected to natural persons may not be used as test data under any circumstances.

There are two stakeholder testing environments available:

ExtTest: A testing environment with the functionalities in production. Here you can test a solution corresponding to the register in production. This testing environment may sometimes contain some of the same functionalities relating to upcoming changes as ExtTest2. The functionalities are specified in delivery reports on stakeholder testing.  
 
The functionalities in production are described in section Production documentation on the Documentation page. 

ExtTest2: A testing environment with future functionalities, where you can test a solution with functionalities to be introduced into the register in future. If a change or correction is made to the implementation, it will usually be first released to this stakeholder testing environment. This testing environment also contains the functionalities in production insofar as the future changes will not affect them. 
 
Future changes will be announced at least 6 months before they are brought into production, and they will be described in section Upcoming changes on the Documentation page.  

Also read other key instructions before you start testing

•    General instructions, Production documentation and Upcoming changes 
•    Reporting data to the Positive credit register
•    Sharing information from the Positive credit register
•    Instructions for the anonymisation of test data
•    Instructions on the testing certificate

2 Signing up for testing

Stakeholders sign up for testing on the stakeholder testing start notification, which is filled in by the organisation’s representative. 

When signing up, the stakeholder

•    accepts the terms and conditions of stakeholder testing
•    specifies both a testing contact person and a technical contact person
•    can sign up to test both the reporting of data and the requesting of data.

When the notification has been processed, the person who filled in the start notification will receive an email with an artificial lender’s Business ID and artificial borrowers’ personal identity codes and Business IDs for use in stakeholder testing.

When a stakeholder signs up for testing, we do not examine whether they are required to submit reports or have the right to use the register’s data. In other words, participation in testing does not guarantee the right to use data at the production stage. Before the rollout of the register, the stakeholder sign up to the register as a data notifier and applies for a data permission.

2.1 Testing on behalf of another

A stakeholder can agree with another party that the other party performs testing on their behalf. This may be necessary, for example, when the stakeholder has outsourced the technical solution to another operator. In that case, the stakeholder with the reporting obligation or using the data can sign up for testing or, alternatively, the operator performing testing can sign up on the stakeholder’s behalf.

The party that signs up for testing must specify either the organisation on whose behalf they will be testing or the party that will be testing on their behalf. This must be stated in the Additional information field of the testing start notification. In connection with signing up, the details of the testing organisation’s technical contact person are given.

3 Testing certificate

In order that the test APIs could be used, the user calling an API must be identified. A testing certificate is an electronic identifier used to identify the user in stakeholder testing environments. A stakeholder is provided with testing certificates connected to the artificial Business ID after signing up for testing. The same testing certificates can be used in both testing environments.

When the stakeholder has signed up for testing, the technical contact person receives a secure email message containing a retrieval ID for retrieving the testing certificate and a text message containing a PIN code for opening the secure email message.

If the stakeholder tests both the reporting and the requesting of data, it needs two different certificates, because data notifiers and data users have different types of certificates.

The certificate must be retrieved within 14 days from the receipt of the messages. If the certificate is not retrieved within 14 days, the stakeholder can request a new certificate in the certificate service or on the contact form for stakeholder testing.

Instructions on additional testing certificates and on the revocation and renewal of certificates are provided in the instructions on the testing certificate. Certificates are valid for 2 years. Stakeholders must renew their certificates themselves in the API of the certificate service.

The stakeholder’s testing contact person and technical contact person will also receive an email with a login link to the e-service of the Tax Administration's certificate service. 

Read the instructions on the testing certificate
Read the instructions on the certificate service

4 Testing

Stakeholders are advised to test all the APIs they use, including those they will use when in production. In testing, it is advisable to proceed from simple basic cases to more complex test cases, testing all the credit products, all the stages of different processes and all the situations. Stakeholders are advised to create test cases that are relevant to them in different situations of reporting and requesting data, also taking account of changes and error situations, for example.

We have made demo videos regarding lenders' APIs to support testing. See the demo videos regarding lenders’ APIs in YouTube.

Testing the reporting of data

The purpose of testing is to ensure that 

•    the data generated by the stakeholder’s information system complies with the requirements and that the stakeholder is able to report the data to the Positive credit register
•    the stakeholder receives correct processing responses to their reports and is able to use them
•    the stakeholder can continue to report correct data if the functionalities change
•    the stakeholder’s own processes and systems are able to handle various situations, such as errors, in the desired manner.

The API for checking loan data allows the user to make sure, at different stages of the testing, that the loan data is correct.

Testing the requesting of credit register extracts

The purpose of testing is to ensure that

•    the stakeholder can request credit register extracts and that the data is shown correctly in the stakeholder’s own systems
•    the stakeholder can continue to receive credit register extracts if the functionalities change
•    data requested from the register can be used in the stakeholder’s own systems
•    the stakeholder’s own processes and systems are able to handle various situations, such as errors, in the desired manner.

Regression testing

The objective of regression testing is to make sure that the changes made have not disrupted a functionality that has been working well. Perform regression testing whenever changes are made to your own systems or to the functionalities of the Positive credit register.

4.1 Stakeholder testing environments

Stakeholders can test the Positive credit register’s APIs in two different stakeholder testing environments. One environment is for testing functionalities in production, and the other is for testing future functionalities. The stakeholder testing environments are available all the time, with the exception of scheduled service breaks or error situations, which will be responded to during office hours on business days.

The stakeholder testing environments are shared by all the testing stakeholders, so data reported in testing may also be returned to other stakeholders when they are testing the requesting of data.

ExtTest - Testing environment (api-testi)

A testing environment with the functionalities in production. Here you can test a solution corresponding to the register in production. This testing environment may sometimes contain some of the same functionalities relating to upcoming changes as ExtTest2. The functionalities are specified in delivery reports on stakeholder testing.

The functionalities in production are described in section Production documentation on the Documentation page. 

ExtTest2 - Testing environment (api-testi2)

A testing environment with future functionalities, where you can test a solution with functionalities to be introduced into the register in future. If a change or correction is made to the implementation, it will usually be first released to this stakeholder testing environment. This testing environment also contains the functionalities in production insofar as the future changes will not affect them.

Future changes will be announced at least 6 months before they are brought into production, and they will be described in section Upcoming changes on the Documentation page.

The two stakeholder testing environments have different API addresses. The same test customer IDs and testing certificates work in both testing environments. Loan data reported to one testing environment is not available in the other testing environment.

4.2 APIs to be tested, and their addresses

The API addresses used in production are different from those used in stakeholder testing. Under no circumstances may test data be submitted to the production environment, nor production data to the testing environment. 

The APIs specified below are used in stakeholder testing. The API address of the environment for testing functionalities in production contains the text “api-testi”. The API address of the environment for testing future functionalities contains the text “api-testi2”.

New loans
•    https://api-testi.positiivinenluottotietorekisteri.fi/AddLoans
•    https://api-testi2.positiivinenluottotietorekisteri.fi/AddLoans

Changes to loans
•    https://api-testi.positiivinenluottotietorekisteri.fi/UpdateLoans
•    https://api-testi2.positiivinenluottotietorekisteri.fi/UpdateLoans

Payment transactions
•    https://api-testi.positiivinenluottotietorekisteri.fi/Repayments
•    https://api-testi2.positiivinenluottotietorekisteri.fi/Repayments

Delayed amounts
•    https://api-testi.positiivinenluottotietorekisteri.fi/DelayedRepayments
•    https://api-testi2.positiivinenluottotietorekisteri.fi/DelayedRepayments

End of loan contract
•    https://api-testi.positiivinenluottotietorekisteri.fi/TerminateLoans
•    https://api-testi2.positiivinenluottotietorekisteri.fi/TerminateLoans

Batch status inquiry
•    https://api-testi.positiivinenluottotietorekisteri.fi/GetBatchStatus
•    https://api-testi2.positiivinenluottotietorekisteri.fi/GetBatchStatus

Checking loan data
•    https://api-testi.positiivinenluottotietorekisteri.fi/GetLoan
•    https://api-testi2.positiivinenluottotietorekisteri.fi/GetLoan

API for requesting credit register extracts
•    https://api-testi.positiivinenluottotietorekisteri.fi/GetCreditRegisterExtract
•    https://api-testi2.positiivinenluottotietorekisteri.fi/GetCreditRegisterExtract

In addition, all organisations participating in testing can test service breaks by sending an API call to https://api-testi.positiivinenluottotietorekisteri.fi/Servicebreak and https://api-testi2.positiivinenluottotietorekisteri.fi/Servicebreak. Calling the above address returns the same message as the APIs do during service breaks.

4.3 Version releases during testing

New versions will be released to the stakeholder testing environments in accordance with the release schedule. A version release causes a service break in testing environments. Service breaks occur simultaneously in both testing environments. 

If necessary, a delivery report regarding the contents of the new version will be released. The delivery report itemises the changes made to the environments or specifies any known defects in the environments.

The dates and times of the breaks and the published delivery reports are available on the Version releases and delivery reports page. 

Subscribers to the system information bulletin will receive advance information on service breaks in the stakeholder testing environment by email. Subscribe to the system information bulletin to your email.

4.4 Test data

Only artificial test customer IDs are used in testing. The stakeholder’s representative who filled in the stakeholder testing start notification will receive the IDs from the Positive credit register after signing up. The end part of the artificial personal IDs starts with 9, and these are the only types of personal IDs that may be used in the testing environments.

Stakeholders can use the same artificial lender’s Business ID and the same testing certificate connected to it in both testing environments. If the stakeholder wants a new artificial lender’s Business ID for testing purposes, it can be requested on the contact form for stakeholder testing.

All data delivered to the testing environment will also be available to other testers using the testing environment. Data submitted to the testing environment when the reporting of data is tested will be utilised when the requesting of data is tested. For example, authorities can request test data submitted by lenders.

4.4.1 Shared test data for testing the requesting of credit register extracts

Shared test customer data is provided for stakeholders to allow them to test especially the requesting of credit register extracts. For some of the shared test customer IDs, diverse income and benefit data, loan data, credit bans and denials of data have been created. The data is needed for purposes of testing the requesting of credit register extracts. 

Test customer IDs for shared use (Excel file).

On one tab of the file, you will find artificial Business IDs that you can use as reassignees when the transfer of loans is tested.

Loans may not be reported for test customers in shared use.

4.4.2 Test data for a testing organisation’s own use when they test the reporting of data

Stakeholders testing the reporting of data will also be provided with artificial customer IDs that are only for their organisation’s use. After signing up for testing, the stakeholder receives a list of these test customer IDs.

Test data submitted to the testing environment cannot be deleted except by reporting the loans as ended or cancelled. Stakeholders should take this into account when planning the testing.

Test data provided for a stakeholder’s own use may also end up for other testers, for example when authorities test the requesting of data.

4.4.3 Artificial test data and anonymisation

When testing stakeholders submit data linked to an artificial personal identity code to the testing environment, they must ensure that the data is artificial or anonymised in accordance with the requirements specified in the instructions on the anonymisation of test data. The stakeholders are responsible for seeing that the test data they provide is artificial or anonymised. Read more in the instructions on the anonymisation of test data.

If a stakeholder has submitted production data or other data contrary to the anonymisation instructions to the stakeholder testing environment by mistake or suspects that this may have happened, they should immediately inform us by filling in the contact form for stakeholder testing. Specify when the data was reported, what kind of data you are talking about, and what efforts (if any) you have made to correct the matter. We may have to close down the testing environment or testing APIs to investigate the matter. The stakeholder should submit a notification of information security breach to the Data Protection Ombudsman if needed.

5 Testing observations and reporting

Stakeholders report on their observations and on suspected errors on the observation form for stakeholder testing.

In a delivery report, you can see whether the error is already known. Also make sure the correct version of the solution, i.e. the correct test API address, has been used in the testing.

You can fill in the observation form if the error is not reported in the delivery report, it is not caused by a communicated service break and the API address is correct. Report the situation in which the error was detected as accurately as possible. You may also add screenshots or other necessary attachments to the form, such as the data batch submitted or the response message.

6 Support and communication during testing

Stakeholder events are held about new features, instructions and current matters, for example. Stakeholder testing is also discussed in the events. Read more about stakeholder events.

The dates and times of scheduled service breaks and the published delivery reports are available on the Version releases and delivery reports page.