IG2-Simulator
PAYMENT SYSTEMS
The main purpose of IG2-simulator is to help the bank to test the standard communication between the bank's host system and GIRO's IG2 Centre.
On the one hand why this is needed is that preparation of various applications for IG2 is continuous, while the verification and testing of these systems are possible only on certain restricted dates defined by GIRO. On the other hand some certain cases (for example, payment returns and acknowledgements to recalls) can be tested only if the bank pre-arranged that a partner bank also takes part in testing.
The application is able to simulate these test cases, and so the bank can execute these test cases in its own system.
On the one hand why this is needed is that preparation of various applications for IG2 is continuous, while the verification and testing of these systems are possible only on certain restricted dates defined by GIRO. On the other hand some certain cases (for example, payment returns and acknowledgements to recalls) can be tested only if the bank pre-arranged that a partner bank also takes part in testing.
The application is able to simulate these test cases, and so the bank can execute these test cases in its own system.
Services of IG2-simulator
Reception and checking of outgoing messages
IG2-simulator is able to receive XML files containing standard IG2 bulks (credit transfers, recalls, payment returns, ACKs and NAKs to recalls) and simulate how the IG2 Centre processes and check them.
Similar to IG2 Centre, IG2-simulator also sends back a validation message (PSR), which can be imported to the bank's host system.In order to make the testing of the import of the validation messages easier, in IG2-simulator it is possible to assign an error code to a (valid) transaction. This way we can force the system to create PSR message which is then imported to the host system.
Generation of IG2 messages to be received by the bank
With the help of IG2-simulator we can create such messages that IG2 Centre would create and send to us (settled credit files). This is implemented in a very simple way: we can "reverse" the payment we sent to the application. This simulates that case when the partner bank sends a transaction to our bank. This way you can create credit payments as well payment returns, recalls and answers to recall. IG2-simulator creates standard settled credit files (SCF) including homogeneous batches.
This function helps the bank to verify if the host system got prepared for SCF's created by IG2 Centre.
This function helps the bank to verify if the host system got prepared for SCF's created by IG2 Centre.
Management of clearing sessions and creation of reports
IG2-simulator handles the business day and its sessions the same way as IG2 Centre. This means that the settlement of a transaction is always done in one single session. In order to test the case when a transaction is rolled over to the next session, we can set a bulk (more precisely, a transaction) to "uncovered".
When we close a session, the application first creates a pre-notification report then prepares an end-of-session report (EOS) containing the summarized result of the validation and settlement done in this session. If we have a transaction to be recalled, the system creates a cancellation payment status report (CPSR). Those transactions that we set to uncovered will be rolled over to the next session. Finally the system also generates two additional reports, SSR for the (sent and) settled transactions while SRR for the (sent and) rolled over transactions.
When we close a session, the application first creates a pre-notification report then prepares an end-of-session report (EOS) containing the summarized result of the validation and settlement done in this session. If we have a transaction to be recalled, the system creates a cancellation payment status report (CPSR). Those transactions that we set to uncovered will be rolled over to the next session. Finally the system also generates two additional reports, SSR for the (sent and) settled transactions while SRR for the (sent and) rolled over transactions.
When we close a business day, the uncovered transactions are all cancelled, that is the system generates a standard CPSR message on them. On closing a business day, an end-of-day report (EOD) is also created.
This function is to verify if our host system handles the end-of-session and end-of-day reports properly.
This function is to verify if our host system handles the end-of-session and end-of-day reports properly.