Вы находитесь на странице: 1из 35

AUTOMATED SYSTEM FOR INTIMATION IN LOAN

RECOVERY
MBABT 418 : Business Analysis Lab using OOMD

Submitted by

C.PRIYADHARSSHINI

REGISTER No. : 16381034

MASTER OF BUSINESS ADMINISTRATION


IN

BANKING TECHNOLOGY

DEPARTMENT OF BANKING TECHNOLOGY


SCHOOL OF MANAGEMENT
PONDICHERRY UNIVERSITY, PONDICHERRY - 14
NOVEMBER 2016

BONAFIDE CERTIFICATE

Certified that this Business Analysis using OOMD Laboratory record work titled
AUTOMATED SYSTEM FOR INTIMATION IN LOAN RECOVERY is the bonafide
work of C.PRIYADHARSSHINI who carried out the record work during July to November
2016

HEAD OF THE DEPARTMENT

FACULTY INCHARGE

Submitted for the End Semester Examination and Viva Voce held on _________________

..
Internal Examiner

External Examiner

ABSTRACT
Banks in past were never so serious in their efforts to ensure timely recovery and consequent
reduction of Non-Performing Assets (NPAs) as they are today. This because of the complex,
competitive market conditions that are making banks to undertake this step. It is important to
remember that Interest earned is the income for the corporation, this should payments, the
entire expenses and plough back requirement therefore, recovery of money is one of the major
source of funds for the corporation. In intimating the loan recovery details to the customers it
collects all types of loans. Manual operating of the existing system is having certain drawbacks
like it is difficult for anyone to remember details of each customer. For every time it is needed
to sort the data from unsorted data which is very time consuming. All system is operated
manually so there may be human error or mistakes occurs. There may be loss of data at the
time of sorting. To overcome this, an automized application is created to send a notification of
the EMI balance for various types of loans to the customer which helps to overcome the above
problems. It is very helpful for those banking staffs who are in the charge of loan management,
it provides a very reliable and convenient form for every loan and emi related details. It also
generates a very customer friendly and understandable form for their transaction information
as they receive a notification after a transaction. Reports are daily generated in the system and
maintains separate database.

LIST OF FIGURES
FIG NO

NAME

PAGE NO

4.1

Notifying customers sorted


by date

11

4.2

Notify the defaulted


customers

12

4.3

Class Diagram

14

Activity Diagram for


scenario 1

15

4.4
4.5

Activity diagram for


scenario 2

16

4.6

Sequence Diagram

17

4.7

Component Diagram

18

4.8

Statechart Diagram

19

4.9

Deployment Diagram

20

4.10

Collaboration Diagram

21

II

CHAPTER I
INTRODUCTION
In finance, the term recovery refers to collection of amount due. The normally recovery
depends on the purpose, time and condition, business running process etc. Normally loan
amount will be recovered on instalment basis. The manager can fix instalment period on the
basis of nature of their business.
Recovery is different from one loan to another.

In short term loans recovery is less than 36months.

In medium term loans recovery is from 36 months to 84 months.

In long term loans recovery is normally 84 months or longer.

Interest earned is the income for the corporation, this should payments, the entire expenses and
plough back requirement therefore, recovery of money is one of the major source of funds for
the corporation. The health of the corporation is judged by the extent of recovery that it can
affect. All source of funds carry cost, if the cost of borrowings is higher, it reduces the margin
profit, further the profit are subject to payment of income tax as per applicable laws. The
corporation also is bound by minimum dividend obligation irrespective, whether it makes profit
or not out of the post tax and post dividend income. The memos are retained in the corporation
by way of reserves. Plough back of finds into system is emerging as one of the very important
source funds in the total resource mix, if the corporation has to retain sufficient money for the
business operations; it has to generate more income. More income obviously improving the
recovery. Therefore, systematic follow-up recovery of loan plays a significant role in our
operations. In fact, is not exaggeration of the state that effective recovery of loans is the
backbone of any financial insitutions.
Banks in past were never so serious in their efforts to ensure timely recovery and consequent
reduction of Non Performing Assets (NPAs) as they are today. This because of the complex,
competitive market conditions that are making banks to undertake this step. It is important to
remember that recovery management, be of fresh loans or old loans, is central to NPA
management.
This management process needs to start at the loan initiating stage itself. Effective management
of recovery and NPA comprise two pronged strategy. First relates to arresting of the defaults
1

and creation of NPA thereof and the second is to handling of loan delinquencies. The tenets of
financial sector reforms were revolutionary which created a sense of urgency in the minds of
staff of bank and gave them a message that either they perform or perish. The prudential norm
has forced the bank to look into the asset quality.A debt from a loan, credit line or accounts
receivable that is recovered either in whole or in part after it has been written off or classified
as a bad debt. Because it generally generates a loss when it is written off, a bad debt recovery
usually produces income. In accounting, the bad debt recovery would credit the "allowance for
bad debts" or "baddebt reserve" categories, and reduce the "accounts receivable" category in
the books. Not all bad debt recoveries are "like-kind" recoveries. For example, a collateralized
loan that has been written off may be partially recovered through sale of the collateral. Or, a
bank may receive equity in exchange for writing off a loan, which could later result in recovery
of the loan and, perhaps, some additional profit.
As we all know growing percentage of Non Performing Assets is a big concern for modern as
well as traditional financial institutions. If recovery is been made effective thencertainly it will
reflect positively on reducing percentage of NPAs. So recovery management, beof fresh loans
or old loans, is central to NPA management. Thus qualified recovery personals is a prime need
of the banking industry.

1.1 EXISTING SYSTEM


Manual operating of the existing system is having certain drawbacks like it is difficult for
anyone to remember details of each customer .For every time it is needed to sort the data from
unsorted data which is very time consuming. All system is operated manually so there may be
human error or mistakes occurs. There may be loss of data at the time of sorting. To overcome
this, an automized application is created to send a notification of the EMI balance for various
types of loans to the customer which helps to overcome the above problems.Loss of data and
data redundancy problem is avoided and the database is updated automatically. Loan
transaction information from agency is updated daily and the updated information from branch
is updated to main branch monthly.

1.2 PROPOSED MODEL


In order to reduce human errors and manual work for registering for monthly collection of Loan
Installment a notification is given to the Customer. At the end of the day it is necessary to
update automatically with new Amount. At the end of each month the Branch updates their
data to the head office and the data/information is stored at the Branch with Security. Reports
2

are daily generated in the system and maintains separate database. It is very helpful for those
banking staffs who are in the charge of loan management, it provides a very reliable and
convenient form for every loan and EMI related details. It also generates a very customer
friendly and understandable form for their transaction information as they receive a notification
after a transaction. Loss of data and data redundancy problem is avoided. Database is updated
automatically. Loan transaction information from agency is updated daily and the updated
information from branch is updated to main branch monthly.
1.3 OBJECTIVES AND SCOPE OF THE PROJECT
Today the need of simplicity has driven application software programming to a new level. This
project is a transaction related information storing project which will be used by the staffs of a
bank for handling their customers who have loans. Operator need to use the registration form
to create account for the new customers, and EMI details and the loan detail forms are present
for dealing with the old customers or those who are already registered. This application has a
user friendly interface so that the banking staffs can easily and efficiently use the software and
its features. It also incorporates steps for getting notification for customers regarding the
transaction details on every transaction and next EMI date and remaining amount details that
helps the operators to use the application efficiently.

1.4 ADVANTAGES

The system reduces human efforts and errors.

System works more efficiently than existing system.

Time consumption is less.

Loss of data and data redundancy problem is avoided.

It provides better security than existing system.

CHAPTER II
LITERATURE REVIEW
2.1 AUTHOR: Jean Pierre Fenech1 ,Ying Kai Yap , SalwaShafik
TITLE: Modelling the recovery outcomes for defaulted loans.
This study investigates the determinants affecting the recovery outcome for bank loans when
firms default. We develop survival analysis models, explaining the transition hazards of bank
loan recoveries varying over time within the conditional probability of firms either fully
recovering or not. Both loan and recovery covariates are critical for recovery outcomes. The
log-logistic parametric model describes the best fit. Our results demonstrate the significant
covariates affecting loan recovery rates, highlighting the importance for banks to structure their
loans in the best possible way.

2.2 AUTHOR: Weiping li and Philip mc mahan


TITLE: A case study on loan loss analysis of a community bank
In this paper, a case study on a community bank from the aspect
of the terms structure of the banks historical loan losses and the loan quality rating matrix used
by the bank. The data source is from a small rural community bank located in a midwestern
state of the United States. The basic statistical analysis of the loan losses that is based on the
banks internal loan quality rating system is presented.

2.3AUTHOR:Dr.Umakanth
TITLE: Loan recovery management and its impacts.
In this study an effort is made to study the impact of NPAs on banks performance. In this
study both primary and secondary data are being used to study the problem stated. Primary data
is collected through structured questionnaire which are collected through employees of private
and public banks having minimum five years of work experience and secondary data is
collected though journal. The results indicate that the market share and profits are affected due
to presence of NPAs and securitization act does not empower the banks to reduce the NPAs.

2.4AUTHOR: AniokeChisom N.
TITLE: Loan granting and its recovery problems on commercial banks(a case study of first
bank plc, ojo- alaba branch)

The research was intended to achieve the following objectives: To find out the several problems
facing loan recovery, the effects of loan default on commercial banks and the measures that
will be used in reducing the incidence of loan default. Relevant data were collected from both
primary and secondary sources. Questionnaires were the main primary data collection
instrument employed while data from various relevant publication constituted the sources of
secondary data. Upon the analysis of data, the following conclusions were drawn: That problem
of loan default stemmed from the fact that there is unavailability of security to be disposed by
banks to realize funds. And also customers attitude towards loan payment. On the basis of the
above findings, it was recommended that commercial banks should use some risk control
measures to guide against loan default. Also, before granting loan, they should examine
critically the project statement submitted by the customer or borrower which will help them to
find out the realistic repayment pattern and also help them in knowing if the projects are
realistic based on the customers past performance.

CHAPTER III
SOFTWARE REQUIREMENTS SPECIFICATION
3.1. INTRODUCTION
THE AUTOMATED SYSTEM FOR INTIMATING IN LOAN RECOVERY is a very
efficient process to handle all loan related details in a very accurate and convenient way. It is
very helpful for those banking staffs that are in the charge of loan management, it provides a
very reliable and convenient form for every loan and EMI related details. It also generates a
very customer friendly and understandable form for their transaction information as they
receive a notification after a transaction.

3.1.1 PURPOSE
This project is a transaction related information storing project which will be used by the staffs
of a bank for handling their customers who have loans and also incorporates steps for getting
notification for customers regarding the transaction details on every transaction and next emi
date and remaining amount details.

3.1.2 SCOPE
This application has a user friendly interface so that the banking staffs can easily and efficiently
use the software and its features. It also incorporates steps for getting notification for customers
regarding the transaction details on every transaction and next EMI date and remaining amount
details that helps the operators to use the application efficiently.
3.1.3 Definitions, Acronyms, and Abbreviations.
IEEE Institute of Electrical and Electronics Engineers
OS Operating System
SRS Software Requirements Specification
SQL Server Query Language

3.1.4 REFERENCES
IEEE Recommended Practice for SRS, IEEE Std 1016-1998, IEEE Computer Society, 1998.

3.1.5 OVERVIEW
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the functional and data
requirements of the product. General description of the project is discussed in section 2 of this
document. Section 3 gives the functional requirements, data requirements and constraints. It
also gives the user viewpoint of product. Section 3 also gives the specific requirements of the
product. Section 3 also discusses the external interface requirements and gives detailed
description of functional requirements. Section 4 is for supporting information.

3.2. THE OVERALL DESCRIPTION


In existing system, for every time it is needed to sort the data from unsorted data which is very
time consuming. All system is operated manually so there may be human error or mistakes
occurs. There may be loss of data at the time of sorting. To overcome this an automized
application is created to send a notification of the EMI balance for various types of loans to the
customer which helps to overcome the above problems.

3.2.1 PRODUCT PERSPECTIVE


The software requires a connection to a database server containing the details of the
customer who have applied for loan which in banks. The program will be executed as a
standalone application on a single machine.The user will use both the mouse and keyboard for
input and all information will be outputted to the monitor.

3.2 PRODUCT FUNCTIONS


3.2.1 ADD FUNCTION
This function will be used to add the details of the customers to the database.

3.2.2 VIEW FUNCTION


This function will be used to view the customer (all type of loans) in banks. The
software system provides the emi details and personal details of the customers . It also shows
the updated remaining EMI amount to be paid by the customer after paying every month.

3.4 GENERAL CONSTRAINTS


The program is designed to be executed on a PC running a Windows OS.

3.5 ASSUMPTIONS AND DEPENDENCIES


The program will be executed on a Windows OS platform. Connection to the server
will be available for all times at which the program is to be used.

3.3 SPECIFIC REQUIREMENTS


3.3.1 FUNCTIONAL REQUIREMENTS
USER MANAGEMENT:

Registration:

User can register with basic information like User name, Mobile no, email id etc.

Login:

Admin,Users can login with username and password.

Manage Profile:

Admin,User can manage profile and update information.

CUSTOMER INFORMATION MODULE:

It shows all an information & details of the customer database which includes all the
details like customer name, address, contact no, bank account no, PAN no, email id,
etc.

Only Admin can manage customer record.

LOAN TRANSACTION MODULE:

Loan transaction module includes Loan Type, Customer, Issuing Loan, EMI

Calculation, Receive payments. The System Administrator can able to add, modify loan
type like

Home Loan, Gold Loan, Personal Loan of customer and can modify the interest rate.

One customer can have more than one loan, System generate unique loan no. Admin
can add, modify loan details like loan type, loan amount, tenure, mortgage details,
guarantor details.

EMI Calculation - System have EMI calculator which can provides details of
particular loans, System take input from user like Loan Amount, Interest Rate,
Tenure, Issue Date and give details output like monthly EMI, total interest, total cost.

Receive payment using with this System admin can enter payment information for
particular EMI.

In this system late fine charges can mention if receipt date is greater than the emi date.

System user can find customer by their name to get customer ID.

3.3.2 HARDWARE REQUIREMENTS


Processor

2.4GHz

Hard Disk

40 GB Free Space

RAM

2 GB

3.3.3 SOFTWARE REQUIREMENTS


Operating System

Windows server 2008

Web Server

Apache Tomcat ver. 7.0

Front-End Tools

Java/jdk 1.6.0 (JSP/Servlet)

Back-End Tools

MYSQL Server 5.1

3.4 EXTERNAL INTERFACE REQUIREMENTS


3.4.1 USER INTERFACE
The user will utilize the GUI to input required information. The user will be able to
click on-screen buttons to maneuver around the program. The user will also be able to click on
fields to enter text into the fields. The user will be able to use the tab key to move between
fields. The user can also search for customer details based on their ID number or name. The
defaulted customers can also be sorted out in the fields.

3.5 PERFORMANCE REQUIREMENTS


The program should run at such a speed that the user can move at his/her own pace,
without noticing interruption due to processing.

3.6 DESIGN CONSTRAINTS


The program is designed for and will only operate under the Windows OS.

3.7 ATTRIBUTES
3.7.1 RELIABILITY
The software should not have any reliability issues. The software will be thoroughly
tested and any issues resolved.

3.7.2 AVAILABILITY
The software will execute as a standalone system so as long as the machine is running,
the program will be available. The key to maintaining availability will be by ensuring a
connection to the database server is available. Failure to connect to the database will make data
unavailable.

3.7.3 SECURITY
This software is intended to communicate over an internal network, therefore security
is of little concern. The user will have to enter the username and password so the program can
connect to the database server. The username and password will not be stored because
encryption of such information is outside the scope of the project.

3.7.4 MAINTAINABILITY
The software will be composed of various modules decreasing the complexity of
expansion.

3.7.5 PORTABILITY
As states previously, this software will only run under the Windows OS. The setup file,
setup.info, can be copied to multiple machines so that each program does not have to be setup
separately.

10

CHAPTER IV
DESIGN AND ANALYSIS

4.1USECASE DIAGRAM
4.1.1 SCENARIO 1
NOTIFY CUSTOMERS SORTED BY DATE

Fig 4.1. Notifying customers sorted by date

ACTORS
The actors present in this diagram are
1.Bank
2.Customers

11

USECASES
1

Log In

Registration

Selection of type of loan

Calculate the EMI

Send notification to the customers

Update the EMI details and balance amount

Log out

DESCRIPTION
The usecase diagram is one which shows the flow of sequence in the system. In theabove
system, Bank employee first log into the account and view the details of the EMI amount and
intimate the customers about the loan details.He/she can update the details after each month.

4.1.2 SCENARIO 2
NOTIFY DEFAULTED CUSTOMERS

Fig4.2. Notify the defaulted customers


12

ACTORS
The actors present in this diagram are
1.Bank
2.Customers

USECASES
1. Log In
2. Registration
3. Select the type of loan
4. List the default customers
5. Add comments
6. Notify the individual
7. Log out

DESCRIPTION
The Use case diagram is one which shows the flow of sequence in the system. In the above
system, Bank employee first log into the account and view the details of Customers. List the
customers who have failed to pay their EMI amount and notify them with comments.

4.2CLASS DIAGRAM
CLASSES
1. Member
2. Loan data
3. Recovery
4. Loan customer
5. Report
6. Reminder
7. Notification
8. Comment

13

Fig 4.3 Class Diagram

DESCRIPTION
The class diagram shows the attributes and the operations of the system. The
member consists of membership number, name ,date of birth and other details
of the customer. The functions of this attributes is to create the membership for
new customers, to search the customers by their details and to edit the details.
The loan data consists of loan type and the duration of the loan. The recovery
provides the details regarding the amount paid by the customers and the status
of the loan. The Loan customer must be a member of the company and shows
the custome type. The report has sections of reminder, notification and
comments to be sent to the customer.

14

4.3ACTIVITY DIAGRAM
SCENARIO 1

Fig 4.4 Activity Diagram for scenario 1

DESCRIPTION
The activity diagram shows the flow of control for the system process. Bank employee first log
in the account to register and view the details of the customer. The loan customers are sorted
by their due date at each every month. The notification is sent to the customers sorted out. Then
the user from bank can logout after finishing the process.

15

SCENARIO 2

Fig 4.5. Activity diagram for scenario 2

DESCRIPTION
In scenario 2, the bank employee updated the loan details and list out the defaulted customers
and send notifications with the additional comments.

16

4.4 SEQUENCE DIAGRAM

Fig 4.6 Sequence Diagram

DESCRIPTION
The sequence diagram shows the sequence flow of control over the activities. Here the bank
employee first log in to the account to view the customer details regarding the loan. The bank
employee selects the due date and the system sorts out the customer details according to the
due date. The notifications are sent to the user device.The defaulted customers are listed out
and again comments are added and sent to those customers.

17

4.5COMPONENT DIAGRAM

Fig 4.7 Component Diagram

DESCRIPTION
The component diagram shows the logical component involved in the system. The data base
consists of details regarding the customers like name, address, occupation, annual salary details
and also details about the loan and types of loan and amount of loan sanctioned. The data must
be updated each month after the payment of amount. The bankers system should access the
data from the database and helps to view the details regarding the status of the loan and
customers. The notifications are sent to the user device via message or through email.

18

4.6STATECHART DIAGRAM

Fig 4.8 Statechart diagram

DESCRIPTION
The State Chart Diagram provides the transition between the states. The State Transition occurs
due to the occurrence of events. It consists of only one start state and one or more stop
states.Initially the employee is logged in. After viewing and sending the notification to the
customers the user can log out.

19

4.7DEPLOYMENT DIAGRAM

Fig 4.9 Deployment diagram

DESCRIPTION
The deployment diagram involves the hardware components involved in the system. In this
system, includes number of loan customers and to ensure manage the payment of the EMI
amount . The database is available to view the details of the loan. The user device receives the
notification from the bank.

20

4.8COLLABORATION DIAGRAM

Fig 4.10 Collaboration Diagram

DESCRIPTION
The collaboration diagram shows the interaction between the objects. Each objects defines its
own functionality. The Admin user initially login the account to check the loan details. The
loan details is stored in the database and is updated each month. The customer receives the
notification regarding loan payment and its due date to remind. The defaulted customers is
listed out and intimated later.

21

CHAPTER 5
IMPLEMENTATION AND TESTING

5.1 MODULES USED:

Login

Entering the due date

Loan details

EMI details

Notification

5.2 MODULES DESCRIPTION:


5.2.1 LOGIN
Admin can login the system with his user name and password.

5.2.2 ENTER THE DUE DATE


The due date is entered and the customers under it are sorted out.

5.2.3 LOAN DETAILS


The admin manages loan details such as Loan no, loan type, Loan Amount, loan
tenure, interest rate of the customer.
5.2.4 EMI DETAILS
The admin calculates the EMI amount based on the loan amount and the interest rate. It
manages the EMI details and the interest amount to be paid at every month.

5.2.5 NOTIFICATION
The defaulted customers are notified by adding comments.

22

S.NO

Test case

Input

Expected

Name
1.

Login Test

Test Result

Explanation

Check
username
and
password

Successful

Check
username
and
password

Output
Username
Password

2.

Entering
the due date

Enter the date

Customer
details
according to
the due date

Successful

Request
successful

3.

Loan
details

Enter the
customer ID

Details of
the loan,
interest and
mortgage
details

Successful

Uploaded
successful

4.

EMI details

Enter the loan


amount and
interest rate

Calculating
the EMI
details

Successful

Verified
successful

Notification

Enter the
comments

Sent
successfully
to the
customer

Successful

Verified
successful

23

5.3 SCREENSHOTS
5.3.1 LOGIN

24

5.2.2 ENTER THE DUE DATE

25

5.2.3 LOAN DETAILS

26

5.2.4 EMI DETAILS

5.2.5 NOTIFICATION

27

CHAPTER 6
CONCLUSION
Thus a conscious effort has to be made to create and develop a software package, making use
of available tools, techniques and resources that would generate a proper system. The
automated system for intimating in loan recovery is developed to process to handle all loan
related details in a very accurate and convenient way which helps banking staffs that are in the
charge of loan management, it provides a very reliable and convenient form for every loan and
EMI related details. It also incorporates steps for getting notification for customers regarding
the transaction details on every transaction and next EMI date and remaining amount details
that helps the operators to use the application efficiently.

28

29

Вам также может понравиться