Batch User Guide produced by CRIF - Janata Bank

3.4 WHY SHOULD I SEND REQUESTS
One of the strenghts of the system is that it does not only report unpaid amounts (which can be
used to assess existing credit risk) nor does it only report granted amounts (which can be used
to access potential credit risk), but also usage and requests, which can be used to assess risk of
over-exposure. By submitted requested credit, the system also insures that if someone goes to
three institutions the same day to ask credit, they don‟t all provide it without knowing the same
credit has been requested elsewhere.
3.5 WHY SHOULD I SEND REFUSED/REJECTED
We saw in 3.4 how credit requests can be used to assess over-exposure risk. By the same token,
once a credit request is refused or rejected, such risk is no longer real. It is good practice,
therefore, to provide the notification of refused/rejected credit to keep the credit history up to
date.
It is understandable, however, that not all institutions are immediately equipped to perform this
notification. Therefore the system is set to automatically archive open requests after one year.
3.6 HOW IS THE INFORMATION CONTRIBUTED
While we have a specific paragraph (please see section 4.2) that details the technical
specifications of how the information is sent, at the very high level please note that each
contributor must send, with each contribution, 2 separate files.
1) A file containing Subject information
2) A file containing Contract information
Each file will be a space delimited .txt file with the structure defined in section 5
3.7 WHAT IS THE SINGLE MOST IMPORTANT THING TO REMEMBER
The key aspect to keep in mind is that each contributing institution must be able to manage
internally a unique identification code that refers explicitly to a single subject as well as a unique
identification code that refers explicitly to a single contract. Neither of these number is the CIB
Borrower Code that existed in the previous system.
CIB Code and FI Contract/Subject code Definition
Every Subject and Contract record contributed (online or batch) to the system needs to be
uniquely identified. This is achieved by assigning an unique code to each record. Codes are
divided into two groups: User and CIB.
FI codes – (FI Subject code or FI Contract code) are those codes contributed by the User.
These codes either generate new entries in the database (if the system does not
recognize the information as already present within the DB) or are linked to already
existing information. FI codes must be always
unique for a given FI.
CIB codes – sometimes also referred as DB
codes - (CIB Subject code or CIB Contract code)
are unique codes at the system level. These
codes are used to group the identical
information contributed by different FIs
9 of 92