TRIBHUVAN UNIVERSITY INSTITUTE OF ENGINEERING PULCHOWK CAMPUS

A MINOR PROJECT REPORT ON CIB SYSTEM

SUBMITTED BY LEKHNATH KHANAL RAMESH KUMAR KARN SANJAYA PANDEY SHUBHASHISH MISHRA

SUBMITTED TO DEPARTMENT OF ELECTRONICS AND COMPUTER ENGINEERING PULCHOWK CAMPUS

8TH NOV, 2011

ACKNOWLEDGEMENT
This project is carried out as per requirement of minor project in our sixth semester. It would have impossible to proceed and to achieve the design of our project without the help of technical staffs, teachers and friends. We should like to express our gratitude to Dr. Surendra Shrestha for suggesting the project title and "Karja Suchana Kendra Limited" for providing such opportunity to work in a real project. We are very grateful to our teachers Aman Shakya and Manoj Ghimire who helped a lot in the development of this project. We also express our gratitude to all the friends who helped a lot to learn about the development tools and programming languages.

Members of Project Lekhnath Khanal(065/BCT/506) Ramesh Karn(065/BCT/532) Sanjaya Pandey(065/BCT/539) Shubhashish Mishra(065/BCT/540)

ABSTRACT
We present a report on the Project titled CREDIT IFORMATION BUREAU (CIB) SYSTEM. The system we developed is modeled as per the requirement of the organization Credit Information Bureau. Credit Information Bureau is private organization established as an initiative taken by Nepal Rasta Bank to minimize increasing fraud case in loan lending. CIB is a data organizing body which keeps the record of the debtor information supplied by all banks and financial institution of Nepal. The mechanism for providing loan for customer is main challenging job for any banking organization. Our project ensures economic stability and facility to manage bank indebtedness. Our system provides detail information about customers loan background of all financial institutes of Nepal if existed. The system we have developed can be divided into two parts, one meant for CIB itself which acts as server side & the other as an interface to banks meant for querying the existing debtor which acts as client side. We have used two object oriented programming languages for accomplishing our project. Of which the server side was developed using JAVA whereas the client side was developed using PHP.

TABLE OF CONTENT
Contents Page number

1. Introduction 2. Objectives 3. Literature review 4. Methodology 5. Output 6. Scope of the project 7. Limitations and Further Enhancements 8. Conclusion References

1 3 4 6 14 19 20 21
22

1.INTRODUCTION
1.1Background
Increasing numbers of Banks and financial sectors has impact to increase in number of fraud cases regarding loans day by day. Reviewing the present and past status of banks, we come to conclusion that nearly 30% of loans seems to be unrecoverable. Its all because of lack of information about debtor before providing loan. So, the system which we are going to develop is to provide credit information that is centralized, comprehensive and reliable. As our system is online based system, it provides instantaneous detail information resulting fast and reliable loaning facility. Providing loan has been always a risky business for many banks and financial institution. Although for sake of safety Banks & Financial Institution usually keeps collateral worth more than they provide. But risk may arise any condition, even if collateral is kept. Also there may arise a case where the same debtor may apply for the loan using the same collateral from other Banks & Financial Institution. Reviewing the history of Banking & Financial Institution, at the starting of financial transaction, we see that there exists no communication regarding loan rendering information among the banks and financial institution. This created a condition of more frauds. So to reduce this risky situation an organization was created as an initiative to reduce loan frauds by Nepal Rastra Bank and other Banks & Financial Institution which was named as KARJA SUCHANA KENDRA LIMITED.

1.2 KSKL An Introduction

KARJA SUCHAHA KENDRA LIMITED also know as CREDIT INFORMATION BUREAU (CIB) is data organizing institution which keeps the record of the debtors information who has taken loans. The data regarding the loan taker is provided by the bank which allotted it. The information about the debtor i.e. loan taker includes debtors personal info, amount loaned, collateral (mortgage), guarantor etc. CIB is responsible to make record of these debtor info and provides these information when required at some cost. The main work done by CIB is to make record of these data in a way that the debtor is not redundant. Organizing data in a way that it is not redundant is a very tedious work because there has been some situation where many same named debtors are encountered, so these data are manipulated and recorded in such a way that it removes ambiguity. Similarly, another work that has to be done by CIB is to make efficient search of the debtor info. The debtor info recorded has to be retrieved when required. So, this recorded info must be retrieved with ease without ambiguity. One cannot spend whole day searching for a single record. Similarly CIB also perform the work of black listing the debtor which fail to pay the loan amount. So when a customer apply for loan, the bank look out for their status whether they had been black listed or not. Based on these information the bank decided whether the loan can be allotted or not and ensures economic stability and indebtedness.

Thus in order to make record of debtor irredundant & unambiguous, CIB uses three Generation Identity i.e. record a debtor with debtors name, his/her father & grandfather name with the issue place & date of the citizenship card to specify a debtor identity number. At the beginning of its operation, the entire task was done manually. But later as the no of loan transaction and Banks & Financial Institution increased, it became tedious and difficult to maintain it. So finally the system was software implemented. So the system we are developing is based on the existing system of CIB which provided Banking & Financial institution with the loan background of the customer if existed. This information helps the Bank & Financial Institution to take decision whether to give the customer loan or not. It provides credit information that is centralized, comprehensive and reliable.

1.3 Our System

Unlike the system that existed in CIB, our developed system is bit different. Our system does the same thing as the existing system but the working mechanism is different. In existing system where the working of blacklisting and key generation is done manually, these works are done automatically by the system. In the existing CIB system when the client bank send the request to black list a debtor the administrator has to change the status of debtor himself/herself. While in our system the client bank sends a file containing the debtor info to be blacklisted, it automatically updates the status of debtor to blacklisted. Similarly the key generation which was manually calculated in present CIB system is generated automatically in our system.

2.OBJECTIVE
The objectives of our project are as follows: To develop a system that provides a way to allocate risk free loan for the banks To implement the current trend of Server-Client model. To learn to work in group To implement the knowledge gained by carrying out a small project

3LITERATURE REVIEW
3.1GUI Swing and AWT classes of the JFC (Java Foundation Classes) have been used to complete the GUI portion of the server application .We basically used the drag and drop features of Netbeans to implement the GUI building process. Swing-based user interface elements are somewhat slower to appear on the user's screen than the peer-based components used by the AWT. But in any reasonably modern machine, the speed difference shouldn't be a problem. On the other hand, the reasons to choose Swing are overwhelming: Swing has a rich and convenient set of user interface elements. Swing has few dependencies on the underlying platform; it is therefore less prone to platformspecific bugs. Swing gives a consistent user experience across platforms. This entire means Swing has the potential of fulfilling the promise of Sun's "Write Once, Run Anywhere" slogan. Jframe, Jpanel, Jlabel, Jbutton, are some of the swing component used in this application. Also Java look and feel has been used to modify the default look of the java application. 3.2Exception handling Suppose an error occurs while a Java program is running. The error might be caused by a file containing wrong information, a flaky network connection, or use of an invalid array index or an attempt to use an object reference that hasn't yet been assigned to an object. The mission of exception handling is to transfer control from where the error occurred to an error handler that can deal with the situation. To handle exceptional situations in your program, you must take into account the errors and problems that may occur. there may be different types of error as User input errors, Device errors, Physical limitations, Code errors etc. Exceptions have their own syntax and are part of a special inheritance hierarchy. In the Java programming language, an exception object is always an instance of a class derived from Throwable. If an exception occurs that is not caught anywhere, the program will terminate and print a message to the console, giving the type of the exception and a stack trace. To catch an exception, you set up a try/catch block. The simplest form of the try block is as follows: try { code more code more code } catch (ExceptionType e) { handler for this type } Multiple exceptions can be caught by using a Try block and multiple catch blocks to handle each type differently. The separate catch clause for each type can be as :

try { code that might throw exceptions } catch (MalformedURLException e1) { emergency action for malformed URLs } catch (UnknownHostException e2) { emergency action for unknown hosts } catch (IOException e3) { emergency action for all other I/O problems }

4.METHODOLOGY
The project has been developed in the client-server model.

4.1Server:
The server is major and essential part of our CIB system, which performs all the operation request or updates by client banks. It also performs the essential operation needed for database management and all client banks authority control. All the operations like bank or branch registration are also controlled. It continuously monitor all the activities performed by the client bank in correlation with our system and notification is shown in our desktop application, for this we use Timer, Timer Task classes for continuous monitor the change occurring in database.

Fig1:- GUI Layout of Server application

Server is Java application. The administrator of CIB controls the operations performed by server application. Admin can register new banks and their branches along with providing certain privilege on searching our database.

Some Specific features of the server application are listed below: 1. Bank Registration For new bank registration, we need unique bank name so when admin fill up the registration form, server application makes the unique Bank_ID if and only if bank name is unique otherwise generates error message. The Bank_ID contaions total three character in which first character is the starting letter of the bank name , and other two letter are denotes the order of the bank having same starting letter. For example if we registers two banks having names like Rastriya banijya bank and Raj shree bank , then their Bank_ID will be r01 and r02 respectively. 2. Branch Bank Registration Branch bank registration is another task for admin, for this the admin selects name of main bank and then automatic Branch_ID is generated. Branch name , location and phone number is inserted, then unique Branch_ID is generated. Which contains five characters, three character by using main Bank_ID and remaining two for represent number of branch of same main bank. For example if we register two branch having branch name pulchowk and jawalakhel branches of Rastriya banijya bank, then their Branch_ID will be r0101 and r0102 respectively. 3. View Bank In view bank tab, we can search the bank details like name, name, location and phone number. In the bank name field, we can search all information of bank and it branch by entering full bank name or 2-3 matching substring of full name. For example, by entering ras on bank name we can get name of those banks whose name contains substring ras.

4. View Debtors In view debtor tab, we can search debtor details like name, address, loan information , payment information and his status(blacklisted_status is true or false). This all information can be gather only by using debtor_id.

5. Notification The notification is important part of server. Database update information like update, blacklisted and also search notification is shown in the left side of the GUI called notification. If any bank sends the data of any new debtor, then notification table is updated and message is shown in to the notification text field with date of file submitted. And same process of showing message is happened when existing debtors payment is submitted. When any debtor is blacklisted as request send by any bank, then notification is shown as blacklisted debtor_id and time of blacklisted. Blacklisted notification gets high priority.

Key features: 1. ID Generation : In present context, maintaining records of numerous banking customers is a tedious job because there may exist many customers with same name and cast. Similarly, we have to come to know that the same citizenship numbers is distributed to multiple people. To remove this ambiguity, we have generalized the method of generation of Debtor ID uniquely. For uniquely identifying the debtor, we generate the debtor_id using debtor information. Debtor_id is a string of length 13, where first 2 character from debtor zone( 01,02,.,14 ), 2 character form district (1,2,3,.,75),1 character to represent male/female , 1 character from starting name of debtor and remaining 7 character for represent the debtor having same starting name in same district and same sex(address of debtor is according to citizenship-issued date). Hence, created id can uniquely identify the debtor. For Example: debtor_id of Steve Jobs whose home lies in 02 zone (janakpur) and 34 district(mahottari) then debtor_id becomes 0234M0000011. For uniquely identifying bank, we generate bank_id using bank information. Bank_id is a string of length 4, where character is from first name of bank and reaming three for represent bank starting first name from same alphabet. For Example: bank_id of Standard Chartered Bank is "S003. For identifying branch-bank, we generate branch_id using main bank_id and serial number of the branches of main bank. Branch_id is string of length 6, where first 4 character for main bank_id and remaining 2 string are for serial number of this main bank. For Example: Branch_id of Baneshwor branch of Standard Chartered bank is s00355.

For loan, we generate loan_id using branch_id and loan number on this branch. Loan_id is a string of length 12, in which first 6 character for represent branch_id and remaining 6 character for loan serial number of this branch. 2. Updating database As the client bank sends information of their new debtor and old debtor (i.e. the installment payment information), also request to blacklisted the debtor. The server take action to database is updated according to the file found on the server uploaded by client banks. To read the data from the file, we make some standard file sent from client and so use same standard to read the file. For this purpose, client sent the file filled with data in previously specified order with , as the delimiter to separate the different field values, Then used the StringTokenizer class to with help to read the data from the file with ignoring the delimiter after this we can use these values for further process. Once the file is read and database is updated then file is deleted. Here file name is created according as the name of main bank who is updating the database which makes us easy to identify of which clients file is this, so all bank have their fix file name( i.e. its bank_ID ) hence the maximum numbers of file at the server at a time will be equals to the total number of client bank. For blacklisting, the file uploaded by client with the detail of debtor, then we found the debtor according as the data provided by the client bank. Since the blacklisting is most sensitive work so data must be sufficient and correct to identify the correct debtor otherwise the blacklisting process will be terminated. When we found the debtor then we update the debtors blacklist_status field to 1 (which means debtor is blacklisted).

3. Timer & TimerTask As we mentioned above the main different between the old and new CIB system is old CIB systems most of the client interface is done manually but in new system most of the process is done automatically which makes the system more fast and reliable than the manual interface. For this automaticity the server need to monitor the files and request sent by the client in regular interval of time. For TimerTask is used to define the tasks which is to be scheduled, and then the Timer class is used to schedule the TimerTask. In this system we used two timer classes one for handling the client requests which comes through the file and another timer used to notification which is explained in next topic. For file handling we schedule the timer for 24hr as we assume that one every bank send their information files once in a day.

4. Notification As we know all requests is performed automatically so the admin of the CIB is unknown from the database changes happening in the system, so its important to display the notification of all the database change happened in the system for this we used the timer which is scheduled to 1sec and show the notification for all the new update happens in the system.

4.2 Client:
The client is a web application written in PHP. This is the main part of CIB system regarding to the client banks. Whatever the client bank wants to do like submitting the report of new/old customers, searching the customers information and requesting for the bad debtors to be blacklist etc are all done by filling up the respective form. After the form is filled correctly and submitted, we create a text file in the server. The file are created as per requirement for the each client bank. We create separate files for new report, old report and for the blacklist request. Why a text file? Because different financial institutions have their own file formatting rules and techniques, one may send us in one data format and another may send in another. The main problem in current CIB System is incompatible data format. A very simple example may be taken of the date format. One may set date as DD-MM-YYYY, another may set as MM-DDYYYY, and another may set as March 21 1988. While saving the data to the database,

We felt more comfortable to create a separate text file for each client banks because of the following main reason: 1. Concurrent access by the client banks: If we don't create a separate file, many banks may access the single file at the same time. A file already opened is inaccessible to other until the process stop accessing the file. Because many banks need to access a single file, there is maximum chance of losing the data. Report submission: A. Report of a new debtor: When a bank decides to give loan to a customer, all the information are taken from the client by compulsorily filling the new debtor report form. All the personal, family, guarantor including the loan detail and the collateral detail are taken.

B. Report of a existing debtor: Only necessary information sufficient to specify the debtor uniquely is taken. Necessary information sufficient to make a debtor key will be asked. C. Blacklisting Request: It's not always sure that all the debtors pay their loan due to this or that reason. The loan providing bank feels to list the debtor as a black debtor. A form with including all the information about the debtor is filled and further reason to blacklist is asked. D. A new customer search: Whenever a new customer arrives for a loan, the Client needs to know about the customer whenever the debtor is a true person or not, is already blacklisted debtor or not, how he/she is paying the loan...etc we offer two type of searching facilities. One is general search and another is full search. In general search, only name, address, gender and the blacklist status are given to the client. In full search, the client can know about all the loan payment history of the debtor. For full searching we create a text file dynamically and allowed to download to the client. We let them to download a text file because the client may wish to keep the record in as a hard copy. The text file will be made available only once. The content of the file will be maintained by the CIB Administration. As the policy changes by time, they may alter the fields to access. Actually what we do is we execute the query generated and stored in the database. For general search also we did the same thing. The searching mechanism: To search a customer efficiently, we ask basic information about the customer which gives the unique information. To reach up to the customer, we have made a base key. A base key we define here is the key without which we can't search anything about the customer. In another word, while searching a customer, the searching person doesn't do mistake up to the lowest level. If a client search to a debtor, his/her zone name, district name, gender and the starting letter of customer name are expected to be submitted with zero errors. Thus generated base key will search the customer with lowest correctness. For better correctness, the searcher must supply the remaining field correctly. To search a customer we ask altogether 10 fields. The base key constitutes zone_id, district_id, gender and the first letter of the customer name. This key will list all the debtors from corresponding region having the starting letter as supplied. Further fettering is done by matching the citizenship number first name, last name, city name, street name and finally the house number. If all the fields supplied matches, the result will be hundred percent matched. We have made 7 levels of searching. First we search the customer with all the 10 fields for exact matching result. if there founds a result in first search the result will be exact. The correctness decreases according to the searching levels.

1. Base key: zone+district+gender+First_name[0] 2. Searching_key:base_key+citizenship_number+first_name+last_name+city_name +street+house_number To make the clients more confident about the customers, we tell them how much correct the searched data are. To do so we calculate the search levels. The following relations make the thing clear about the searching levels.

level6: Data searched with base_key+citizenship_number+first_name+last_name+city_name+street+house_number level5: Data searched with base_key+citizenship_number+first_name+last_name+city_name+street level4: Data searched with base_key+citizenship_number+first_name+last_name+city_name level3: Data searched with base_key+citizenship_number+last_name level2: Data searched with base_key+citizenship_number level1: Data searched with base_key level0: Data searched with unmatched base_key unmatched

Percentage calculated: 7th level=>100% 6th level=>85.71% 5th level=>71.43% 4th level=>57.14% 3rd level=>42.86% 2nd level=>28.57% 1st level=>14.28% 0th level=>0% Main aim of showing this percentage level is to tell them how much correct the searched data are. And hence it helps to know about the debtor.

General Search: We show the normal details of the matched customer in general search. The normal search will show the basic information of the customer. To know detail about the debtor found, the client needs to ask our system. Detail Search: By conforming the customer a valid one, banks need to know about the loan payment history. To download all payment detail of the customer, bank needs to instruct the system to provide the detail history. If the client instructs to the system, system makes a dynamic text file and provides the link to download. Thus created file will be available only once.

5. OUTPUT (SNAPSHOTS)
5.1 Server Side

Fig Add a Bank

Fig: View Bank

Fig: Add a Bank Branch

Fig: View Debtor

Fig: Edit Debtor Information

5.2Client Side

Fig: Black Listed Debtor Form

Fig: New Debtor Report Form

Fig: Existing Debtor Report Form

Fig: Search Customer

Fig: Search Result

6. SCOPE OF PROJECT
CIB system developed by us can be used to store the information of the debtor who has taken loan from any bank and financial institution. Thus CIB system can be used for following purpose Reserve bank can use it for monitoring purpose. Client Bank can use it for investing detailed information of loan taker before allocating loan. Can be used to trace fraud loan cases. To provide a medium for communication between client banks.

7.LIMITATION AND FURTHER ENHANCEMEENT

Like everything in this world seem ought not to be perfect, our project do have some limitation and some further enhancement can be carried out to make it perfect.

7.1Limitation:
These are certain limitation that our project has probably due to time constraint and lack of knowledge on some topic Our system dont support loan type having more than one debtor Currently our system only support record with loan type Personal Loan

7.2Enhancements:
These are some enhancement that can be carried out to our project Expanding the system for different loan type i.e. House loan, Corporate Loan etc Enhancing security by implementing Virtual Private Network(VPN) at client side so that it is not accessible for other except clients only.

8.CONCLUSION
The project has helped us, the project members, to learn about real-time project and has encouraged us to explore the new horizons.. In course of our project development we faced different hindrances. These difficulties were solved with the help of mentors, seniors, colleagues and different other resources. Besides it has also made us appreciate the notion of working in team thus consolidating our engineering studies. Due to short duration of the allocated time for the completion of the entire project is very limited. Despite this the project objectives have been achieved with development of CIB System. As well as we have learnt the importance of the Project Management while doing any sort of project.

REFERENCE
Books
Herbert Schildt, The Complete Reference Java 2, Tata McGraw-Hill Publishing Company, 2009 W. Jason Gilmore, Beginning PHP and MySQL From Novice to Professional, Apress,2008

Website
Java Official site www.sun.java.com