Testing instructions for stakeholders

The instructions were last updated on 23 January 2025. The instructions have been updated with guidance for stage 2 stakeholder testing as regards schedules, sign-up and stakeholder testing environments, for example.

Key terms

Anonymisation Removal or irrevocable alteration of identification information in such a way that the parties cannot be identified. Instructions for the anonymisation of test data.

Stakeholders The Positive credit register’s stakeholders include all users, such as parties required to submit reports, users of credit register extracts, credit information companies, authorities and individuals.

Test customer Artificial company or individual in the stakeholder testing environment with an artificial customer ID.

Test data Data batch used by the tester in the testing environment, containing data on artificial test customers.

Certificate An electronic identifier used to identify the user. A test certificate is for the stakeholder testing environment. An access right to and a certificate for the Positive credit register's production API must be requested separately before the rollout.

Stage 1 stakeholder testing environment A testing environment with the functions of stage 1. In this environment, stakeholders can test the currently used technical solution of the register.

Stage 2 stakeholder testing environment A testing environment with the functions of stage 2. In this environment, stakeholders can test a technical solution corresponding to the API descriptions of stage 2. The functions of stage 1 are also included where applicable.

1 Purpose and objectives

These instructions are for operators participating in the Positive credit register’s stakeholder testing. The stakeholder testing participants include

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

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

Prepare for the testing carefully.

Study technical documentation, such as API descriptions

In addition to technical instructions, also read other key instructions for lenders on how to report and request data.

Note that the API descriptions and instructions for stage 1 and those for stage 2 are different.

The testing allows stakeholders to make sure they are technically capable of reporting and requesting data. When testing the APIs, the stakeholders can also ensure that their own systems and processes work in the appropriate manner. Each stakeholder is responsible for building their own APIs and ensuring their conformity to law.

The data used in testing 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 sent as test data under any circumstances: the test data must always be anonymised.

This applies both to stakeholder testing of stage 1 and to stakeholder testing of new functions introduced in stage 2 of the register. In addition to these instructions, authorities participating in stakeholder testing will also be given other necessary instructions in cooperation meetings, for example.

1.1 Stakeholder testing of stage 1 of the register

At the moment, consumer credits and loans comparable to them are reported to the register. Stage 1 operators can perform stakeholder testing to test the stage 1 version of the register, for example to gain support for their own system development.

The implementation of stage 1 of the register is subject to changes. Stakeholders will be notified of the changes in good time, and the changes can be tested before their introduction.

1.2 Stakeholder testing of stage 2 of the register

In stage 2 of the register, starting 1 December 2025, lenders start reporting loans granted to private individuals other than consumers, such as business loans granted to private individuals. Changes related to this can be tested in stage 2 stakeholder testing.

The stage 2 testing participants include

• lenders that were not involved in stage 1 but will be in stage 2 of the register
• all stage 1 operators
  • lenders whose reporting obligation expands to credits reportable in stage 2
  • lenders whose reporting obligation does not expand
    • must make sure they can still request and receive credit register extracts, because new content will be added to them
    • must make sure they can still report data after the changes made in stage 2
• authorities using the Positive credit register.

2 How the testing progresses

The contents of stage 2 of the register will be made available for testing before the rollout as follows:

• Lenders can test the reporting of data and the requesting of credit register extracts as of 3 March 2025.
• Authorities can test the requesting of data as of 5 May 2025.

It is important to perform testing in good time before the actual rollout. In this way, it is possible to ensure that any errors and problems are resolved before the rollout so that the rollout runs smoothly. The rollout of stage 2 of the register takes place on 1 December 2025.

Stakeholder testing regarding stage 1 is ongoing and continues uninterrupted.

2.1 Checklist for testing

The checklist describes the different stages of testing in brief. The different stages of testing are discussed in greater detail later in these instructions.

Study the key instructions before you start testing

• API descriptions, general instructions for application developers, and other technical documentation
• Instructions on reporting data to the Positive credit register
  • Reporting data to the Positive credit register (stage 1)
  • Reporting data to the Positive credit register as of 1 December 2025 (stage 2)
• Instructions on sharing information from the Positive credit register
  • Sharing information from the Positive credit register (stage 1)
  • Sharing information from the Positive credit register (instructions for stage 2 will be released in February–March)
• Instructions for the anonymisation of test data
• Instructions on the testing certificate.

Signing up for testing, and identifiers needed in testing

• A representative of the stakeholder organisation fills in the testing start notification.
• An artificial Business ID and other information needed to start testing are provided for the stakeholder, unless the stakeholder has performed testing previously and already received them.
• The stakeholder’s technical contact person receives the information needed to retrieve a testing certificate, unless the certificate has been retrieved in connection with previously performed stakeholder testing.

Certificate retrieval

• The technical contact person retrieves the certificate, unless is has been retrived in connection with previously performed stakeholder testing. Further information about the testing certificate can be found in the instructions on the testing certificate.

When you start testing

• Addresses of testing APIs (link)
• Make sure you use the correct API address. Different testing environments have different addresses.
• Start testing as early as possible. Use stakeholder testing to support your own implementation.
• The test data must be artificial or anonymised.
• If you encounter problems in APIs or suspect an error, fill in the observation form for testing.

Keep yourself up-to-date

• Participate in stakeholder events.
  • Sign-up for stakeholder cooperation by filling in the sign-up form and receive invitations to stakeholder events.
• Subscribe to the system information bulletin and keep an eye on delivery reports, which contain information about any errors or changes.
• Subscribe to our newsletter.

3 Sign-up for testing

Sign up for testing by filling in the stakeholder testing start notification.

After you have signed up for stakeholder testing, you can perform testing until further notice. In other words, you can use the testing environment to perform continuous regression testing or to test any new functions. In some cases, you may need to sign up for testing again, for example to test stage 2 of the register.

When signing up, the stakeholder

• accepts the terms and conditions of stakeholder testing
• can register 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.

The start notification will be processed within two weeks. 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 IDs and Business IDs for use in stakeholder testing.

The person assigned as the technical contact person for testing receives an email with information on the testing certificate associated with the artificial lender’s Business ID. In addition, the stakeholder's testing contact person will receive an email with a login link to the e-service of the Tax Administration's certificate service.

If the stakeholder participated in testing in stage 1 of the register, they will continue to use the previously granted artificial Business ID and the testing certificate associated with the Business ID in question to test stage 2 of the register. If the stakeholder wants a new artificial lender’s Business ID for stage 2 testing, they can request it in the Additional information field of the start notification.

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, for example. Before the rollout of the register, stakeholders sign up to the register as data notifiers and apply for data permissions.

3.1 Testing on behalf of another party

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 of the reporting or requesting of data to another operator. In that case, the stakeholder that is required to submit reports or uses the data can sign up for testing, or the operator performing testing can sign up on behalf of the stakeholder.

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 sign-up, details of the testing organisation’s technical contact person must be given.

4 Testing certificate

Each stakeholder needs its own testing certificate for testing the API. If the stakeholder intends to test both the reporting and the requesting of data, it needs two different types of certificates, because data notifiers and data users have different certificates.

The testing certificate is used only in the stakeholder testing environment during stakeholder testing. A different certificate is needed for production use.

A stakeholder that has participated in testing and retrieved a testing certificate in stage 1 of the register can use the same testing certificate in stage 2 stakeholder testing.

The contact person for stakeholder testing will receive an email with a login link to the e-service of the Tax Administration's certificate service. In the service, you can retrieve certificates and request additional certificates. You log in to the service using Suomi.fi identification. Read the instructions on the certificate service (vero.fi).

The technical contact person receives a secure email message containing the identifiers needed for retrieving the certificate. The message is sent within two weeks after the testing start notification has been submitted. To open the secure email, the technical contact person receives a PIN code by text message. The certificate must be retrieved within 14 days from the receipt of the messages.

However, if the stakeholder fails to retrieve the certificate within 14 days, it can

• log in to the certificate service and order a new testing certificate, or
• submit a contact form for testing and request a new certificate.

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.

5 Testing

The purpose of testing is to ensure that

• the data generated by the stakeholder’s information system complies with the requirements, and the stakeholder can report the data to the Positive credit register and check its accuracy in the register
• the stakeholder receives correct processing responses to its reports and is able to use them
• the stakeholder’s own processes and systems are able to handle various situations, such as errors, in the desired manner
• credit register extracts can be requested and generated, and they contain correct data
• data requests sent by authorities and credit information companies are successful
• data requested from the register can be used in the stakeholder’s own systems.

Stakeholders test all the APIs that they will use in production. In testing, it is advisable to proceed from simple basic cases to more complex test cases, testing all the stages and situations of different processes.

All requesters of credit register extracts must take into account that the content of credit register extracts will change in the second stage of the register. It is important to make sure the stakeholder will be able to receive credit register extracts even after the content changes.

Stakeholders must create relevant test cases for different situations of reporting and requesting data, taking account of changes and errors, as well as their own processes.

We have made demo videos regarding lenders' APIs to support testing. Watch the videos on YouTube.

Reporting of data

• Start with basic cases.
• Test with all your credit products.
• Test the entire lifecycle, and test different situations.
• Use the API for checking loan data to make sure the loan data is correct.
• Test error situations.

Requesting of data

• Test to make sure you can request and receive credit register extracts.
• Check that the information in the extract is correct.

Regression testing

• Make sure that the things you tested earlier still work.

5.1 Stakeholder testing environments

Stakeholders can test the Positive credit register’s APIs in two different stakeholder testing environments. 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.

The stakeholder testing environments have their own API addresses.

The same test customer IDs and testing certificates work in both stakeholder testing environments. In addition, the income data is the same in both testing environments.

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

Stage 1 stakeholder testing environment

The stage 1 stakeholder testing environment of the Positive credit register has a technical implementation and settings corresponding to the API descriptions of stage 1. If a change or correction is made to the implementation, it will usually be first released to the stakeholder testing environment. The stakeholders will then have an opportunity to test upcoming changes in advance.

Stage 2 stakeholder testing environment

For testing stage 2 of the register, a stakeholder testing environment with an implementation corresponding to the API descriptions of stage 2 is provided.

5.2 APIs to be tested, and their addresses

The focus of stakeholder testing is on technical APIs used to report and request data. This chapter lists the APIs and services to be tested by lenders, as well as the addresses of the APIs.

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

	Stage 2 stakeholder testing environment	Stage 1 stakeholder testing environment
Reporting data on loan contracts, lenders
New loans	https://api-testi2.positiivinenluottotietorekisteri.fi/AddLoans	https://api-testi.positiivinenluottotietorekisteri.fi/AddLoans
Changes to loans	https://api-testi2.positiivinenluottotietorekisteri.fi/UpdateLoans	https://api-testi.positiivinenluottotietorekisteri.fi/UpdateLoans
Payment transactions	https://api-testi2.positiivinenluottotietorekisteri.fi/Repayments	https://api-testi.positiivinenluottotietorekisteri.fi/Repayments
Delayed amounts	https://api-testi2.positiivinenluottotietorekisteri.fi/DelayedRepayments	https://api-testi.positiivinenluottotietorekisteri.fi/DelayedRepayments
End of loan contract	https://api-testi2.positiivinenluottotietorekisteri.fi/TerminateLoans	https://api-testi.positiivinenluottotietorekisteri.fi/TerminateLoans
Requests for status information of submitted data	https://api-testi2.positiivinenluottotietorekisteri.fi/GetBatchStatus	https://api-testi.positiivinenluottotietorekisteri.fi/GetBatchStatus
Checking loan contract data	https://api-testi2.positiivinenluottotietorekisteri.fi/GetLoan	https://api-testi.positiivinenluottotietorekisteri.fi/GetLoan
Requesting data, lenders
API for requesting a credit register extract	https://api-testi2.positiivinenluottotietorekisteri.fi/GetCreditRegisterExtract	https://api-testi.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 this address returns the same message as all other APIs during a service break.

5.3 Version releases in the testing period

New versions will be released to the stakeholder testing environment in accordance with the release schedule, and a delivery report will be drafted on the content of each new version. The release of a new version causes a service break in the testing environment. The dates and times of the breaks and the published delivery reports are available on the Version releases and delivery reports page.

Service breaks occur simultaneously in both testing environments. The changes made to each environment will be specified in the delivery report, and any known defects will be described.
Subscribers to the system information bulletin will receive information on service breaks in the stakeholder testing environment by email. Subscribe to the system information bulletin to your email.

5.4 Test data

Artificial test customer IDs are used in testing. The person who filled in the stakeholder testing start notification will receive the IDs after signing up. The end part of the artificial personal ID starts with 9, and no personal IDs of other types may be used in the testing environment.

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.

Only test IDs that stakeholders receive from the Positive credit register may be used in testing. During stage 1 testing, stakeholders could ask their own customer IDs, meeting certain criteria, to be imported into the testing environment. Those IDs can still be used. However, no new stakeholders’ own artificial IDs will be imported into the database.

5.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, a range of 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).

5.4.2 Test data for a testing organisation’s own use to 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. Stakeholders reporting consumer credits receive artificial personal IDs, and those reporting other than consumer credits receive artificial personal IDs and artificial Business IDs for businesses.After signing up for testing, the stakeholder receives a list of the test customer IDs.

Test data submitted to the testing environment cannot be removed except by reporting the loans as ended, and you should take this into account in your testing plans.

Test data that is provided for a stakeholder’s own use may also be sent to other testers, for example when authorities test the requesting of data.

5.4.3 Artificial and anonymised test data

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 of the instructions on the anonymisation of test data. The stakeholders are responsible for seeing that the test data they provide is artificial or anonymised. See the instructions on the anonymisation of test data for more information.

If a stakeholder has submitted production data to the stakeholder testing environment by mistake or suspects that this may have happened, it should immediately inform us by filling in the contact form for stakeholder testing. Specify when the data has been reported, what kind of data we 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 and remedy the matter. The stakeholder should submit a notification of an information security breach to the Data Protection Ombudsman if needed.

6 Testing observations and reporting

Stakeholders report on their observations and on suspected errors with the observation form for stakeholders.

If the tester suspects an error, they can check the delivery report to see whether the error has already been reported. Also make sure you have been testing the correct version of the implementation, i.e. used the correct API address.

You can fill in the observation form if the error has not been reported in the delivery report, it is not caused by a planned 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 submitted or the response message.

7 Support and communication during testing

Participate in stakeholder events. Stakeholder testing is also discussed in the events. The Current issues section (linkki) on the front page of the register’s website gives information on the date and content of the next scheduled stakeholder event.You can also sign up for our stakeholder mailing list to receive (link to webropol) Teams links to the Positive credit register’s stakeholder events.