BAT 1st Delivery Stoplichtbeheer Increment 2 - Mid September 2007

Planned changes

1) Update of CSD directly from the Probe results file (no conversion anymore) through a read routine for
the results file and a program that updates the data in CSD

2) Addition of client groups 01**, 02** and 03** for clients of which the subcode FI ends on either 3
(KEM credits) or 6 (SME Transition portfolio credits)

3) For all clients within Stoplichtbeheer (KEM, SME Transition and Zakelijk Maatwerk portfolios),
‘pandlijsten’ will only be requested when a client has both ‘verpanding debiteuren’ and a ‘borrowing
base’

4) Removal of the exclusion of clients that belong to the ‘zakelijk medische’ client groups (1114 / 1124)
for all portfolios within Stoplichtbeheer (KEM, SME Transition and Zakelijk Maatwerk)

5) Removal of the exclusion of clients on the basis of GRV for all portfolios within Stoplichtbeheer
(KEM, SME Transition and Zakelijk Maatwerk)

What should be tested for the planned changes as part of BAT?

General remark: it has to be taken into account that the content of the SLB portfolio will be expanded by
the changes 2, 4 and 5. In BAT all the test cases will be combined so that only one whole cycle of CSD
updating and SLB batch runs will have to be executed

Sub 1) Update of CSD

• In FAT it will be verified that for all tables within the CSD the loaded data in the new situation
matches to the loaded data in the existing (production) situation. The verification will have to be
on correctness, completeness and actuality for all clients within client group 11**. For this, the
business will verify the results from Infosys FAT testing. A condition for business approval will
be that Infosys will show that there is a 100% data match between the old and the new
situation based on testing with a full production file (regular production data as input for CSD,
not a spot-check). Eventual differences must be explained (caused by for instance the portfolio
expansion)

Full production run for FAT has not taken place. FAT Report should be updated accordingly after the
run.

• In BAT a whole cycle of SLB batch runs will be executed, based on the production like CSD
data that was loaded into the CSD with the new program.

In order to check this, Infosys has been asked to match the CSD - production data (obtained
from production) of August (used for September run) with data generated in AT environment.

a) Infosys will obtain the data for the month of August in CSD.
b) Run the queries related to client group 11 on the data, save the result in a set of flat files.
c) Delete the data from the AT –CSD and then repopulate the data with New Program (RF014)
# 15-10-2008 2

d) Run the same queries as in Step (b) and save the result in another set of flat files.
e) Take the difference of two sets of data.
A successful test with full production data will be called when the difference between the two sets is
Zero (=100% data match).

• It will be verified that all Stoplicht functionality for clients within client group 11** still works as it
did before the changes and that the client data in CSD matches the client data within SLB.

In order to verify this, Infosys has been asked match the SLB - production data (obtained from
production) of September run with data generated in AT environment.

a) Infosys will obtain the data for the month of September in SLB.
b) Run the queries related to client group 11 on the data, save the result in a set of flat files.
c) Delete the data from the AT –SLB and then repopulate the data with KZ BATCH
d) Run the same queries as in Step (b) and save the result in another set of flat files.
e) Take the difference of two sets of data.

Business will spot-check client group 11** clients from all portfolios monitored by SLB, i.e. KEM,
SME Transition and Zakelijk Maatwerk. Tested functionality for these specific clients will be:
o determining treatment method;
o manually setting a deviating treatment method;
o manually changing the review date;
o signaling/making/approving limited analyses including negative developments;
o signaling/approving Basel II reviews;
o putting forward the review date;
o verification of lists for limited analyses / Basel II reviews / full reviews (via
‘beheeroverzicht kredieten’);
o ‘annual figures’ decisioning and approving;
o changed ‘pandlijst’ decisioning (see also change #3);
o client information (i.e. showing CRG / treatment method history);

In order to check the functionalities (bulleted list), Infosys must provide business users with userids to
login into the online application of KZ and perform the Tests.
There must be separates user ids for credit specialists (at least 2 of the same BO) and fiatteurs.

Sub 2) Addition of client groups 01**, 02** and 03** for clients with subcode FI ending on either 3 or 6

• In FAT it will be tested by Infosys that (only) clients within client groups 01**, 02** and 03** of
which the subcode FI ends on (only) 3 or 6 are taken up in Stoplichtbeheer (besides currently
already selected clients from client group 11**). The results will be checked by business.

(Piyush to discuss with Piet)

• In BAT a whole cycle of SLB batch runs will be executed, based on the production like CSD
data that was loaded into the CSD with the new programs. It will be verified that all Stoplicht
functionality for clients within the newly added client groups 01**, 02** and 03** of which the
subcode FI ends on either 3 or 6 will work as it does/did for existing clients monitored by SLB
(from client group 11**) and that the client data in CSD matches the client data within SLB. This
will be done through a spot-check of client group 01**, 02** and 03** clients from both the KEM
# 15-10-2008 3

(FI subcode ends on 3) and SME Transition (FI subcode ends on 6) portfolios. Tested
functionality for these specific clients will be:
o determining treatment method;
o manually setting a deviating treatment method;
o manually changing the review date;
o signaling/making/approving limited analyses including negative developments;
o signaling/approving Basel II reviews;
o putting forward the review date;
o verification of lists for limited analyses / Basel II reviews / full reviews (via
‘beheeroverzicht kredieten’);
o ‘annual figures’ decisioning and approving;
o changed ‘pandlijst’ decisioning (see also change #3);
o client information (i.e. showing CRG / treatment method history);

Sub 3) ‘Pandlijsten’ will only be requested for all clients monitored by SLB when they have ‘verpanding
debiteuren’ AND ‘borrowing base’

• In FAT Infosys will test all changed functionality. The results will be checked by business.

• In BAT it will be verified within SLB and through the ‘beheeroverzicht pandlijsten’ that only
‘pandlijsten’ are requested (indicator ‘pandlijst insturen’ = 3 or 1) for clients that have BOTH
‘verpanding debiteuren’ AND ‘borrowing base’. This will be done through a spot-check of clients
from all portfolios (KEM, SME Transition and Zakelijk Maatwerk) monitored by SLB and for all
combinations of control by Office/Stoplicht, in conformity with the new matrix for ‘pandlijst’
decisioning
(Piet and Tim)

• In BAT it will be verified within SLB and through the ‘beheeroverzicht pandlijsten’ that no
‘pandlijsten’ are requested (indicator pandlijst insturen = 4 or 2) for clients that don’t have a
borrowing base. This will be done through a spot-check of clients from all portfolios (KEM, SME
Transition and Zakelijk Maatwerk) monitored by SLB and for all combinations of control by
Office/Stoplicht, according to the new matrix for ‘pandlijst’ decisioning

Sub 4) Removal exclusion for Zakelijk Medisch

The change will be made by the Functional Maintenance Officer by removing the current exclusions
from the control card just before the adapted SLB start-of-month production batch run starts, which at
that time includes the planned changes as described in items 1, 2 and 3. The control card
administration is a tested functionality (it is part of the existing application). The removal of the
exclusions will therefore not have to be tested separately for this change (neither in FAT nor in BAT). It
will be checked by the Functional Maintenance Officer that the control card may be left empty and that
the program reading the control card will run normally when it encounters an empty control card. If not,
the control card will be filled with one record consisting of three spaces.

Sub 5) Removal exclusion based on GRV

This change has already been implemented into production by removing the current exclusions from the
control card. It did/does not have to be tested, as the control card administration is a tested functionality
(it is part of the existing application). It was verified by the Functional Maintenance Officer that the
# 15-10-2008 4

control card couldn’t be left empty as the program reading the control card expects at least one value.
For this reason the control card has now been filled with one record consisting of three spaces