Testing instructions for stakeholders

The instructions were last updated on 7 March 2023. The change concerns the testing start notification and the start package: only the master user can submit the testing start notification and receive the testing start package.

1 Purpose and objectives

These instructions are for operators participating in the Positive credit register’s stakeholder testing. They apply to the first stage of the register rollout, i.e. the reporting and requesting of information on consumer credits and loans comparable to them. The participants of the stakeholder testing include organisations that report information on loan contracts to the Positive credit register, organisations that use the loan data, credit information companies, and authorities that use the registered data. The focus in the stakeholder testing is on technical APIs. The content of the instructions may still change.

The purpose is that the stakeholders would test the functionality of the Positive credit register's APIs. The stakeholders can make use of the testing environment in their own development and testing. Advance testing enables smooth introduction of the register to all parties. On account of the testing, the register is expected to operate more smoothly while in production, and fewer errors are to be expected.

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 its own APIs and for ensuring their conformity to law.

2 APIs and services to be tested

The focus of stakeholder testing is on technical APIs used to report and request data.

Reporting data:

• APIs for reporting data on loan contracts (REST)
  • New loan
  • Changes to loan contract information
  • Delayed amounts
  • Payment transactions
  • End of loan contract
• Batch status inquiry (REST)
• Checking of reported loan data (REST)

Requesting data, lenders:

• API for requesting a credit register extract (REST)
  • A request for a credit register extract

Requesting data, authorities:

• Data requesting service (REST)
  • a new request, a list of requests or terminating a request
• Batch distribution (SFTP)
  • Comprehensive picture of credit stock
    • All loans
    • New and ended loan contracts
  • Loan report flow
    • Reports on loan contracts
  • Targeted sampling
    • Borrower’s loans
    • Lender’s loans
    • Targeted reports on loan contracts
  • Requests for credit register extracts
    • Lender’s requests for credit register extracts
    • Requests for credit register extracts relating to a certain borrower
    • All requests for credit register extracts
  • Data flow of incomes payment reports
    • Incomes payment reports
  • Data flow of reports on credit bans
    • Reports on credit bans

Data requests, credit information companies:

• Data requesting service (REST)
  • a new request, a list of requests or terminating a request
• Batch distribution (SFTP)
  • Data flow of reports on credit bans
    • Reports on credit bans

2.1 Limitations

The present stakeholder testing does not include

• testing of the Positive credit register’s e-services for private individuals and organisations
• testing of sending information on the lenders’ existing credit stock

3 Schedule

Sign-up

Sign-up for stakeholder testing: 1 March–30 April 2023 and 1 August–31 August 2023.

If the testing stakeholder is a data notifier or both a data notifier and a data user, the sign-up period is 1 March–30 April 2023.

If the testing stakeholder is only a data user (for example, authorities and credit information companies), the sign-up period is 1 August–31 August 2023.

Testing

Stakeholder testing takes place in two stages, and each stakeholder participates in one or both, depending on its role:

• testing of reporting data on loan contracts 2 May–31 Oct. 2023
• testing of requesting information 1 Sept. 2023–31 Jan. 2024

The schedules were set so as to ensure that we can take the stakeholders’ observations into account and make any corrections needed before rollout to production. After the above testing periods, the testing environment will still be accessible to stakeholders and they can test the latest API version there.

Stakeholder events and testing meetings will be held before and during the testing so as to allow stakeholders to discuss issues arising during the testing with the project and with other stakeholders.

Figure 1. Schedule.

3.1 Early testing opportunity for authorities

As an exception to these schedules, authorities using the register’s data can test APIs as of 2 May 2023. In early testing, authorities can call APIs in the testing environment. At this stage, however, there is no test database in the testing environment so it is not yet possible to test the actual requesting of data. The requesting of data can be tested according to the original schedule as of 1 September 2023.

If the testing stakeholder is an authority using data and wants to participate in limited early testing before the actual testing of data requests begins, it can sign up between 1 March and 30 April 2023.

• Calling APIs is possible as of 2 May 2023.
• Actual testing of data requests 1 September 2023–31 January 2024.

4 Enter portal

The Enter portal is available for communication. It is the primary channel for communication between the stakeholders and the project to establish a positive credit register in matters related to testing.

One person from the testing organisation registers for the portal as the organisation’s master user. After the registration, the Master User can add persons participating in the testing as users of the portal. It is also advisable to add as users all individuals participating in the testing and dealing with the project in situations such as troubleshooting.

Through the portal, the users can send questions about testing, their testing observations, suspected errors, etc. to the project. Responses will be sent to the portal, and the person who sent the question will receive a message to their email address. The master user can follow the status of their organisation's tickets and thereby see the overall picture of the organisation's testing observations, for example. Basic users can view only their own tickets.

The portal also contains other information related to testing, such as links to testing instructions. In addition, the portal can be used to communicate about topical issues related to the testing environment, such as observations or corrections of errors.

The Enter portal will be introduced for stakeholders participating in the testing on 1 March 2023. Read the instructions on the Enter portal.

5 Progress of testing

The testing starts with sign-up. Stakeholders test the technical APIs and report any errors and other observations to the project during the scheduled testing phase.

The different stages of testing are discussed in greater detail later in these instructions.

Figure 2. Stages of testing.

6 Sign-up for testing

You must sign up for stakeholder testing by completing the sign-up form (start notification) available in the Enter portal. The testing start notification is filled in by the master user. The stakeholder accepts the terms and conditions of testing when signing up. Before sign-up, the organisation's Master User must add at least the testing contact person and technical contact person to the portal.

When signing up, the stakeholder

• accepts the terms and conditions of stakeholder testing
• estimates the date when the organisation will start 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.

The project will process the testing start notification within two weeks. After this, the master user who filled in the testing start notification will receive artificial personal identity codes and an artificial Business ID for use in testing. The information related to the testing certificate will be delivered to the technical contact person assigned to testing. If the stakeholder signs up to test both the reporting of data and the requesting of data, the project will first send information for the testing of reporting data and, before 1 September 2023, the corresponding information for the testing of requesting data or credit register extracts.

If the information submitted in connection with signing up changes in the course of testing (for example, the testing contact person or technical contact person changes), the stakeholder must report this in the Enter portal as soon as possible. For more detailed instructions, see the instructions on the use of the Enter portal.

Sign-up for stakeholders that are both data notifiers and data users

• Sign-up 1 March–30 April 2023.
  • Testing of reporting data on loan contracts 2 May–31 October 2023
  • Testing of requesting credit register extracts 1 September 2023–31 January 2024

Sign-up for stakeholders that are only data notifiers

• Sign-up 1 March–30 April 2023
  • Testing 2 May–31 October 2023

Sign-up for stakeholders that are only data users

• Sign-up 1 August–31 August 2023
  • Testing 1 September 2023–31 January 2024

7 Testing certificate

Each stakeholder needs its own testing certificate for testing the API. There are separate certificates for data notifiers and data users, i.e. if the stakeholder intends to test both the reporting and the requesting of data, it needs two different types of certificates.

After signing up for testing, the stakeholder receives a testing certificate and an artificial Business ID for use in the testing. To retrieve the testing certificate, the stakeholder needs identifiers, which will be delivered to the stakeholder's technical contact person by secure email after the sign-up. 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. In other words, the certificate must be retrieved before the actual testing period.

However, if the stakeholder fails to retrieve the certificate within 14 days, it can request a new certificate by filling in the contact form for testing in the Enter portal.

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

Read the instructions on the testing certificate

7.1 Other situations

Requesting additional certificates

If stakeholders need more testing certificates, they can request additional certificates by filling in and sending the contact form for testing in the Enter portal.

Request to deactivate a certificate

If the stakeholder wants the testing certificate to be deactivated, it can request deactivation by filling in and sending the contact form for testing in the Enter portal. The serial number of the certificate must be stated on the form.

Certificate’s period of validity

The testing certificate is valid for two years.

8 Testing on behalf of another party

A stakeholder can authorise another party to perform testing on its behalf. This is possible, for example, when the stakeholder has outsourced the technical reporting or the requesting of data to another operator. In that case, the stakeholder required to submit reports or using the data can itself sign up for testing, or the operator performing testing can sign up on behalf of the stakeholder.

Before signing up, the organisation must check who in the testing organisation acts as the technical contact person and retrieves the certificate. In connection with signing up, the details of the testing organisation’s technical contact person are given. The technical contact person is sent the information related to the certificate and retrieves the certificate.

The Enter portal can also be used when the stakeholder has outsourced testing and another operator is performing the testing on behalf of the stakeholder. The persons performing the testing can be added to the portal for purposes of communication. These individuals can also use the portal to process the observation forms.

9 Suomi.fi data exchange layer

Instructions related to the Suomi.fi data exchange layer will be published at a later date.

10 Testing

The purpose of testing is to ensure that

• the APIs provided for stakeholders work correctly
• 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
• credit register extracts can be requested and generated successfully
• data is shown correctly in the credit register extracts
• data requests sent by authorities and credit information companies are successful.

Each stakeholder tests the APIs they intend to use during 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.

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

10.1 Testing environment

Stakeholders can test the Positive credit register in the stakeholder testing environment. The stakeholder testing environment is available 24/7, with the exception of scheduled service breaks or error situations, which will be responded to during office hours.

The stakeholder testing environment is available for testing the reporting of data as of 2 May 2023 and for testing the requesting of data as of 1 September 2023. New versions and replacement releases will be made available in the stakeholder testing environment during the testing. When a new version is released, the stakeholders will be notified with a delivery report on new functionalities, corrections made and defects known.

The stakeholder testing environment is common to all the testing stakeholders, so joint testing between different stakeholders is also possible.

10.2 Deviating processing rules of the testing environment

Some of the settings (configurations) and processing rules used in the stakeholder testing environment deviate from those used in production. Testing is possible only with such artificial customer IDs that are saved in the register's stakeholder testing environment. Testing with other customer IDs is not possible because no matching information is available in the register.

There are no processing rules related to dates in the stakeholder testing environment that would differ from the production environment.

10.3 Test data

Testing is performed with artificial test customer data, which the stakeholder’s master user receives after signing up. The test customer data contains personal identity codes. In addition, artificial Business IDs are provided, which the stakeholder can use as reassignees when testing the transfer of credit.

For purposes of testing the requesting of credit register extracts, the project creates a range of income and benefit information, loan information, credit bans, and disputes of information for some test customer IDs.

Some of the test customer IDs are assigned specifically to the stakeholder, while others are in shared use. After signing up for testing, the stakeholder receives a list of the test customer IDs and their properties.

All data delivered to the testing environment is available for 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.

When stakeholders submit data linked to an artificial personal identity code during testing to the testing environment, they must ensure that the data is artificial or anonymised in accordance with the requirements of the separate anonymisation instructions. The stakeholders are responsible for seeing that the test data they provide is artificial or anonymised. The anonymisation instructions will be published at a later date.

10.4 Stakeholder’s own test customer data

The stakeholder can add a moderate amount of its own test customer data to the stakeholder testing environment. In this case, the stakeholder is responsible for seeing that the data does not contain any production data. The project does not check or anonymise data submitted by stakeholders. If the stakeholder wishes to submit its own test customer data, it must contact the project by filling in the contact form in the Enter portal.

If the test data is generated by using production data, the data must be anonymised in such a manner that it cannot be re-engineered. All personal data must be de-identified in such a way that the customer cannot be identified. The anonymisation instructions will be published at a later date.

Read more about legislation governing test data:

• Article 25 of the EU General Data Protection Regulation (gdprinfo.eu)
• Article 32 of the EU General Data Protection Regulation (gdprinfo.eu)

11 Testing observations and reporting

Stakeholders report on their observations through the Enter portal.

If the tester suspects an error, they can use the Enter portal to check whether the error has already been reported. If the error has not been reported previously, you can fill in the observation form. 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. The observation form contains fields for different types of information, so the form itself tells you what information you must give.

Errors are classified according to the table below (Table 1). The tester assigns an appropriate class to the error when reporting the observation. If necessary, the error class can be changed. The final classification is made by the people processing the error report.

Error class	Description
1 Critical	An error that prevents the testing from continuing. There is no acceptable way of circumventing the problem.
2 High	An error that prevents the operation of at least one system component. However, there is an acceptable way of circumventing the problem.
3 Medium	An error that causes the system to generate an incorrect, incomplete or inconsistent result.
4 Low	A minor or cosmetic error, acceptable methods of circumvention exist.

Table 1. Error class descriptions.

12 Communication and support during testing

Information about stakeholder testing is available on the register's website and in the Enter portal. During the testing, stakeholder events about testing will also be held.

During the testing, the project to establish a positive credit register will keep the stakeholders informed of the following topics, for example:

• API descriptions and their updates
• disruptions in the testing environment
• new versions of the testing environment
• additional fixes installed in the testing environment in addition to the scheduled version updates
• any downtime of the testing environment
• delivery reports
• upcoming stakeholder events
• other topics and news to be communicated.

The Enter portal is the primary channel for communication between the stakeholder and the project during the testing. The stakeholder sends the project questions and observations related to testing through the Enter portal and receives the project's answers in the portal.

When signing up for testing, the stakeholder must submit the contact information of the testing contact person. If necessary, the project may notify the contact person by email about testing-related situations.

13 Key terms

Anonymisation
Removal or irrevocable alteration of identification information in such a way that the parties cannot be identified.

Enter portal
The primary means of communication between the testing organisation and the project in matters related to testing. Instructions, bulletins and topical information related to stakeholder testing are published in the Enter portal. Stakeholders can also send their questions and testing observations through the portal.

Project
The project to establish a positive credit register answers for the development of the register. The project supports stakeholders in the stakeholder testing.

API
An access point according to certain definitions, used for sending data between an outside party and the register. The Positive credit register has API services for reporting data, requesting credit register extracts, and requesting and receiving data batches. In the definition of the API, the data transmission method (protocol) and the content and format of the data to be transmitted are specified.

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

Technical contact person
A person to whom information for retrieving a certificate is sent. The person is specified by the testing organisation in a testing start notification.

Testing start notification
A testing start notification is submitted electronically through the Enter portal. In the notification, the stakeholder reports the information needed to start testing and the services to be tested to the Positive credit register, and accepts the terms and conditions of the testing environment.

Testing contact person
The testing organisation’s primary contact person in matters related to the testing of the Positive credit register. There may be one testing contact person. The project will contact the testing contact person, if needed, in matters related to testing.

Testing environment
The stakeholder testing environment for testing the Positive credit register.

Test customer
Artificial companies or individuals in the stakeholder testing environment with artificial customer IDs.

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

Data users
Operators using the Positive credit register’s data and having a statutory right to obtain data from the register to perform their duties. Data users include lenders, credit information companies, and authorities using the registered data and supervising the operation of the register.

Data notifiers
Operators with a statutory obligation to send information to the Positive credit register. Notifiers include financial, payment and credit institutions, and Kela.

Certificate
An electronic identifier issued by the Incomes Register Unit to identify the user.

A test certificate is for the stakeholder testing environment. An access right to and a certificate for the API that will be used when the Positive credit register is rolled out to production at the beginning of 2024 must be requested separately before the rollout.

More terminology in the Positive credit register’s glossary (suomi.fi).