CORE BANKING

Project Request And Problem initialization

The first step in System Development Life Cycle (SDLC) is the

identification of need. The user request identifies the need
for change and authorizes the initial investigation. The
objective is to determine whether the request is valid and
feasible. The outcome of the initial investigation is the
presentation of results called project proposal. An
acceptance signature on the project proposal by the
authorized person and its acceptance by the MIS department
makes it a formal agreement to proceed with the detailed
analysis and design of the candidate system.

PROBLEM DEFINITION:

In the early days of banking technology, the

network/backend infrastructure used to be decentralized.
This meant that each branch had its own server(s), banking
applications, database(s), and other such assorted
hardware/software.

Decentralized networks had their own set of problems in

terms of the cost and management fronts. The decentralized
model involves huge capital expenditure and resources
(trained manpower, hardware, etc). In the decentralized
model, there is no coordination or one central control point.
This was an acceptable scenario till multi-channel came into
the picture. With these concepts came the need for a
centralized database. The database had to be updated
instantaneously irrespective of the branch or channel the
customer used. The networks had to be run and managed
with lesser costs.

Although data centers were being used by some of the

banking majors, they were never considered as being

capable of being a central operations hub. Things changed

when banks realized the cost benefits of swapping the

decentralized model to a centralized data center architecture

Page 1 of 48
 CORE BANKING

Advantages of Core Banking System:

 Risk management is another area where core-banking

applications can help.
 These systems take care of the risk monitoring and reporting
requirements. Loyalty programs can also be monitored and
managed using a core banking application.
 Core banking applications help integrate the enterprise to
existing in-house applications to offer a single customer view.
These applications provide automation across multiple
delivery channels.
 These applications also help banks achieve centralized
processing and provide 24-hour customer service.
 Core banking applications help provide complete front and
backend automation of banks.
 It is not just the data center, which contributed to
centralization. The network has also evolved into a unified IP
network.

SRS Document

Software requirement specification (SRS) is a fundamental

document, which forms the foundation of software development
process. SRS constitutes the agreement between clients and
developers regarding the contents of the software that is going to

Page 2 of 48
 CORE BANKING
be developed. SRS should accurately and completely represent the
system requirements.

Hardware and software Requirements

User interface requirements: Dreamweaver MX.

IDE : Eclipse
Database requirements : Oracle8.1 & onwards
Server : Tomcat 5.0
Preferred Technologies : JavaScript, Java( Jdbc
2.0,Servlets2.1, JSP 1.2 )

Corebank’s robust business functionality can be delivered in

COBOL on the mainframe zSeries platform as well as in a
J2EE environment on either UNIX pSeries or mainframe
zSeries. Corebanking is the world’s first platform-independent
core processing solution based on J2EE technology. This
advanced technology infrastructure and world-class business
functionality provide financial institutions a competitive
advantage in an ever-changing global marketplace.

ARCHITECTURAL PATTERN

Page 3 of 48
 CORE BANKING

Architecture Pros Cons

Simple No networking -- can't access
One tier Very high performance remote services
Self-contained Potential for spaghetti code
Clean, modular design
Must design/implement
Less network traffic
protocol
Two tiers Secure algorithms
Must design/implement
Can separate UI from
reliable data storage
business logic
Can separate UI, logic, Need to buy database product
and storage Need to hire DBA
Reliable, replicable data Need to learn new language
Three tiers
Concurrent data access (SQL)
via transactions Object-relational mapping is
Efficient data access difficult
Quite inefficient
Must learn API (CORBA, RMI,
Support multiple etc.)
N tiers applications more easily Expensive products
Common protocol/API More complex; thus, more
potential for bugs
Harder to balance loads

Model-View-Controller

• The Model Layer

The model layer in a Java based web application can be

implemented using any Java-based technology, such as EJB,
Hibernate, or JDO. In our CoreBanking System. the model is
represented as simple JavaBeans containing the data and
business logic in a simple data access object. As far as

Page 4 of 48
 CORE BANKING
possible, the model objects should be developed so that they
have no knowledge of the environment. This allows us to
more easily reuse them across environments and applications.

• The View Layer

The view layer of most Java based web applications is made

up of Java Server pages. To facilitate the development of the
view, Java provides a set of JSP tag libraries. These tag
libraries allow us to easily provide fully internationalized user
interfaces that interact with the model components of a web
application.

The vast majority of dynamic Web front ends are based on

HTML forms, and users of such applications have come to
expect from these applications certain behaviors, such as
form validation. With standard JSP, this is a tedious process
that involves recording the contents of the form and
populating every form element with information from a Java
Bean in case of error. Java facilitates this sort of form
processing and validation using Custom tags. These, in
combination with the JSP tag libraries, make View
development with forms really simple and natural.

• The Controller Layer

Java includes a Servlet that implements the primary functions

of the Controller, which is to map the incoming URL to an
model object. The Servlet provides the following functions:

1. Decide what action is required to service a users request

2. Provide view data to the view
3. Decide which view to show next

A Java developer must provide these actions(models) to

implement the logic of their application.

What is Model-View-Controller?

Let’s start by looking at how the Model, the View, and the Controller
interact with one another:

Page 5 of 48
 CORE BANKING

Figure 1 : Model 2/MVC architecture

As you can see from the above diagram, the user interacts with the
Controller components (usually represented by Servlets) by
submitting requests to them. In turn, the Controller components
instantiate Model components (usually represented by JavaBeans or
other similar technology), and manipulate them according to the
logic of the application. Once the Model is constructed, the
Controller decides which View (usually represented by Java Server
Pages) to show to the user next, and this View interacts with the
Model to show the relevant data to the user.

Using Java Server Pages or Servlets alone is known as Model 1.

Model 2 was not particularly innovative or new; It uses Servlets

to resemble Controller and Java Server Pages for resembling
views .Many people realized that it follows the well-known MVC
pattern that was developed back in the days of Smalltalk. As
such, Java programmers tend to use the terms Model 2 and MVC
interchangeably.

DESIGN PATTERN

DESIGN PATTERN

Page 6 of 48
 CORE BANKING

Data Access Object

Context

Access to data varies depending on the source of the data. Access

to persistent storage, such as to a database, varies greatly
depending on the type of storage (relational databases, object-
oriented databases, flat files, and so forth) and the vendor
implementation

Problem

Applications can use the JDBC API to access data residing in a

relational database management system (RDBMS). The JDBC API
enables standard access and manipulation of data in persistent
storage, such as a relational database. The JDBC API enables J2EE
applications to use SQL statements, which are the standard means
for accessing RDBMS tables. However, even within an RDBMS
environment, the actual syntax and format of the SQL statements
may vary depending on the particular database product.

There is even greater variation with different types of persistent

storage. Access mechanisms, supported APIs, and features vary
between different types of persistent stores such as RDBMS, object-
oriented databases, flat files, and so forth.

Such disparate data sources offer challenges to the application and can
potentially create a direct dependency between application code and data
access code. When business components-entity beans, session beans, and
even presentation components like servlets and helper objects for Java
Server Pages (JSP) pages --need to access a data source, they can use the
appropriate API to achieve connectivity and manipulate the data source.
But including the connectivity and data access code within these
components introduces a tight coupling between the components and the
data source implementation. Such code dependencies in components
make it difficult and tedious to migrate the application from one type of
data source to another. When the data source changes, the components
need to be changed to handle the new type of data source.

Forces
Portability of the components is directly affected when specific
access mechanisms and APIs are included in the components.

Page 7 of 48
 CORE BANKING
Components need to be transparent to the actual persistent store or
data source implementation to provide easy migration to different
vendor products, different storage types, and different data source
types.

Solution

Use a Data Access Object (DAO) to abstract and encapsulate

all access to the data source. The DAO manages the connection with
the data source to obtain and store data.
The DAO implements the access mechanism required to work
with the data source. The data source could be a persistent store
like an RDBMS, an external service like a B2B exchange, a
repository like an LDAP database, or a business service accessed via
CORBA Internet Inter-ORB Protocol (IIOP) or low-level s ockets. The
sssss

business component that relies on the DAO uses the simpler

interface exposed by the DAO for its clients. The DAO completely
hides the data source implementation details from its clients.
Because the interface exposed by the DAO to clients does not
change when the underlying data source implementation changes,
this pattern allows the DAO to adapt to different storage schemes
without affecting its clients or business components. Essentially, the
DAO acts as an adapter between the component and the data
source.

Participants and Responsibilities

• Business Object

The Business Object represents the data client. It is the object

that requires access to the data source to obtain and store
data. A Business Object may be implemented as a session
bean, entity bean, or some other Java object, in addition to a
servlet or helper bean that accesses the data source.

• DataAccessObject

The DataAccessObject is the primary object of this pattern.

The DataAccessObject abstracts the underlying data access
implementation for the Business Object to enable transparent
access to the data source. The Business Object also delegates
data load and store operations to the DataAccessObject.

• Transfer Object

Page 8 of 48
 CORE BANKING
This represents a Transfer Object used as a data carrier. The
DataAccessObject may use a Transfer Object to return data to
the client. The DataAccessObject may also receive the data
from the client in a Transfer Object to update the data in the
data source.

Consequences:
Enables Transparency
Business objects can use the data source without knowing the
specific details of the data source's implementation. Access is
transparent because the implementation details are hidden inside
the DAO.

• Enables Easier Migration

A layer of DAOs makes it easier for an application to migrate to
a different database implementation. The business objects
have no knowledge of the underlying data implementation.
Thus, the migration involves changes only to the DAO layer.
Further, if employing a factory strategy, it is possible to
provide a concrete factory implementation for each underlying
storage implementation. In this case, migrating to a different
storage implementation means providing a new factory
implementation to the application.

• Reduces Code Complexity in Business Objects

Because the DAOs manage all the data access complexities, it
simplifies the code in the business objects and other data
clients that use the DAOs. All implementation-related code
(such as SQL statements) is contained in the DAO and not in
the business object. This improves code readability and
development productivity.

• Centralizes All Data Access into a Separate Layer

Because all data access operations are now delegated to the DAOs,
the separate data access layer can be viewed as the layer that can
isolate the rest of the application from the data access
implementation. This centralization makes the application easier to
maintain and manage.

Page 9 of 48
 CORE BANKING

Scope of The Development Project

The scope is to cover the functionalities of “CoreBanking

Customer & Corporate” with complete front and backend
automation of banks.

Purpose

The generated application is the first version upon the system. The
overall system is planned to be in the formal of distributed
architecture with homogeneous database platform. The purpose of
Core banking applications helps integrate the enterprise to existing
in-house applications to offer a single customer view. These
applications provide automation across multiple delivery channels.

The major objective of the overall system is to keep the following

components intact.

 System consistency  System integrity  Overall security of

data  Data reliability and Accuracy  User friendly name both
at administration and user levels  Considering the fact of
generality and clarity  To cross check that the system
overcomes the hurdles of the version specific standards

Project Synopsis

Page 10 of 48
 CORE BANKING
Technical Descriptions

 Database: The total number of databases that were

identified to build the system is 14. The major parts of
the databases are categorized as administration
components and customer of based components. The
administration components are useful is managing the
actual master data that may be necessary to maintain
the consistency of the system. These databases purely
used for the internal organizational needs and
necessities.

The Administrator, Manager, and Non-Manager Staff

components are designed to handle to transactional
states that arise upon the system whereas customer
makes a visit onto the portal for making his
transactions faster. The Customer components are
scheduled accept parametrical information from the
users as per the system necessity.

 GUI:

In the flexibility of the users the interface has been

developed a graphics concept in mind, associated
through a browsers interface. The GUI’S at the top level
have been categorized as
 Administration users interface
 Customer users interface
The Administration users interface concentrate on the
consistent in that is practically part of organizational

actuaries and which needs proper authentication for

data collation.

Page 11 of 48
 CORE BANKING
The managers and non-manager staff (cashier) user
interface helps the respective actors in transacting with
the actual information as per their necessities with
specific to the required services. The GUI’s restrict the
ordinary users from miss manipulating the systems
data, which can make the existing system non-
operational. The information with specific to their
personal standards and strategies can be changed
through proper privileges.

Server:
For Executing any kind of web application in
computer tomcat Server is required.

Technologies :
1) JDBC
2) SERVLET
3) JSP
4) STRUTS

1) JDBC:-

Page 12 of 48
 CORE BANKING
Any kind of java program can communicate with any
kind of database from a standard manner using JDBC
As java is mostly used in business applications , it
should be able to communicate with database.
Database (DBMS) can understand only SQL & java
knows only method call. To communicate between
them JDBC approach is required.

JDBC architecture involves five elements.

1) Client java application

2) JDBC API
3) Driver Manager
4) Driver
5) Database server

Driver:
It is precreated software developed according to the
JDBC specification . Driver implements JDBC API.

Types of Driver

1) JDBC-ODBC bridge driver

2) Native-API java driver
3) Net protocol all java driver
4) Native protocol all java driver

2)SERVLET:

Page 13 of 48
 CORE BANKING
It is a web technologies & also a web component . A servlet is
a dynamic web resources in a web application. A servlet produces
dynamic web content. A servlet contain JAVA code & HTML code.

A servlet is a container (servlet engine) managed public java

class , that implements javax.servlet interface directly or indirectly.

Javax.sevlet interface has five abstract methods

1) Init()
2) Service()
3) Destroy()
4) getSevletConfig()
5) getServletInfo()

The first 3 methods are known as life cycle method. They

are implicitly called by the servlet engine on the servlet

instance.

Servlet life-cycle :-

1) Instantiation phase

2) Initialization phase

3) Servicing phase

4) Destruction phase

3) JSP

Page 14 of 48
 CORE BANKING

A jsp is also a web component .A jsp is server side piece

of code that extends the functionality of a web server.
A jsp translated into a servlet in the background . A
jsp is serving client request.
Generally , Html inside Java code is nothing but a
servlet ,vice versa is jsp.
A jsp contains 3 things
1) Html
2) java code
3) jsp elements
Jsp elements:
Jsp has given 3 kinds of elements(tag) to place java
code directly or indirectly into jsp.

1) Scripting elements
2) Directives
3) Actions

1) Scripting elements:-
These are the Jsp elements embedded java
code into jsp. There are 3 kinds of scripting element.

1) Declaration
2) Expression
3) Scriptlet

2) Directives:-

Page 15 of 48
 CORE BANKING

A directives are translation time instructions to jsp

engine .Jsp directives describe the overall structure of
jsp.

A jsp contain 3 directives

1) page directives
2) Include directives
3) Taglib directives

3) Actions:-

Action are runtime (request processing time)

instructions to the jsp engine.

In jsp 2 kinds of Actions

1) Custom Actions (tag)

2) Standard Actions (tag)

User’s created tags known as Custom tag , where as precreated

tags are known as standard tags.

Page 16 of 48
 CORE BANKING

Users of the system

 Admin

 Manager

 Cashier

 Customer

 Admin: He is the user who interacts all the modules of the system.

 Manager: Is responsible to create/edit/delete of user accounts, approval of

the documents, report generation.

 Cashier: Is responsible for performing credit/debit transactions.

 Customer : He interacts only with I-Banking module apart from the login

module which is mandatory

Modules:

1) Administrator Module: This module maintains the services

related to system administrator who is authenticated upon the
system. This module fairly maintains the integration between the
modules related to backend database and the functionalities
carried out in the whole organization. This module also binds itself
with the employees and branch details.

2) Manager Module: This module maintains the information related to

the customers who have been signed upon to the system as well
as the internal information of the organization. The module

Page 17 of 48
 CORE BANKING
integrates itself with the other modules like the Administrator
module and Cashier module that are provided by the organization.
This module acts as a major integrator with customer’s
transactions and the requests for approvals that are raised by the
Cashier.

3) Cashier Module: This module manages the information related the

customer accounts that are recorded as and when the operations
are performed. The entire customer account information is
revealed in this module. The module manages itself to have an
integrated relational approach with the customer requests and the
organizational interest calculations that are calculated on a
regular basis. The module takes care of the overall integration
among the systems existence with specific to the general
necessities.

4) Customer Module: This module manages and keeps track of the

transactions of the registered customers. It has interaction to
customer account as well as personal information to keep track of
the consistency of information form time to time as they are
executed.

Administrator

Staff 1.1 Accept UserName,

Cuostomer
Password

Page 18 of 48
1.2Verify
Login Details Validation Data
 CORE BANKING

Low Level Data Flow Diagram:

casheir

1.1Accept UserName,
Password

1.2Verify Details
Validation Data

Page 19 of 48
 CORE BANKING

Login

Data Store
Process

Create Deposit/withdra Send Message View Generate

account w/transfer Messages statement

View
customerdetails/viewb
alance

Staff

1.1

1.2Verify Details Validation Data

Page 20 of 48
Login
 CORE BANKING

Process

Accept/reject View viewbran View Send View Message

account
View
customer ch account empdetails Message
type

customer

1.1 Accept UserName,

Password

1.2Verify Details
Validation Data

Page 21 of 48
 CORE BANKING

Login

Process Data Store

View Change account View balance Send Messages View

accountdetail details Messages
s

Page 22 of 48
 CORE BANKING

Joining_Dat Category
ee
Branch
Emp_ Addr
Id Phon
e
Register_Of_Employee
Dept_n
o Re
gis
E- Sal ter
mail s

Message Corporate_Details
To_Add
r

Subject Vie
w&
Messages Sen
d
From_Add
r

Date_Of_Gen Page 23 of 48
 CORE BANKING

1) Actor: Admin
The Admin module consists of the following services:
1) Login
2) Create new Account types
3) Adding new Branch
4) Registering a new Employee
5) View Employees information
6) Change profile
7) Change Employee designation
8) Change branch details
9) Change Account Type details
10) Send message
11) View message
12) Block/Remove Employees
13) View account type Details
14) View branch details
15) Logout

Login:

Page 24 of 48
 CORE BANKING
In this process, Admin enters his username (i.e. his
empid), password and submitted details are verified at the
server side. If he is authorized, then only he is presented with
his remaining services otherwise his access is denied

Create new Account types:

In this process, Admin is allowed to create a new account

type. If any new recommended account type has come up in
existing system then Admin has a privilege to make an entry
of the account type details into the database, so that a
centralized access will make the users of the application to
observe the change that is introduced into the system.

Page 25 of 48
 CORE BANKING

Adding new branch:

Page 26 of 48
 CORE BANKING

This service of Admin allows him to add a new branch. If any new
branch comes into existence then the relevant information (such as
Branch Id, Branch Name, Location, Address, Pin code and Contact
number) is entered into the system by him.

View Employees:

Using this process, Admin can view employee detail like his
personal profile as well as other details related to organization.

Change profile:

In this process, Admin can edit his own profile like his telephone
number, Email and address.

Change Employee designation:

Page 27 of 48
 CORE BANKING
This service enables Admin to change the cadre of an employee
incase of any change in the designation or department. Here, the
Admin is displayed with a list of employee ids available in the
database and by selection of any particular employee, his details
are displayed so that Admin is allowed to change the designation to
the required status. This change is further updated in the
backend by the use of appropriate operations. The output will be
either successor failure of the transaction

Change branch details:

This process facilitates the Admin to edit branch details incase of

any change that has occurred with the existing system. Branch Id is
taken as the input and on obtaining the respective branch details,
required fields like location, address or phone number are modified.
Hence the details are updated for the later use.

Page 28 of 48
 CORE BANKING

Add new Employees:

This process registers a new employee by entering all the details

like First Name, Last Name, Designation, Date of join, address,
salary and so on. If the record is successfully entered into the
database then the employee id is auto generated by the system in a
specific format (ex. E07101).This empid is unique and each
employee is identified by his empid

Change Account type details:

This process facilitates the Admin to edit account type details incase
of any change that has occurred with the existing system. Acctype
is taken as the input and on obtaining the respective account type
details, required fields like rate of interest, minimum balance and
period are subjected to be modified.
Hence the details are updated for the later use by any part
of the organization.

Page 29 of 48
 CORE BANKING

Send messages:

With this service, Admin is capable to send messages to any

other user based on the requirement that is raised at any
time. This service takes to address, subject and message as
the input from the Admin and after sending the data to the
respective recipient successfully, the acknowledgement is sent
to him.

.
View messages:

This privilege lets the Admin to view the messages that are
in his inbox.

Block/Remove employees:

There might be some situations where an

employee of the organization is subjected to any illegal
activities or it is also possible that an employee quits from
the organization and in such a times his data must be
either omitted from the working employees data or sent to
some other storage unit. This responsibility of maintaining
the information in a secured and reliable manner is taken
care by the admin with the help of this subsystem or
process.

View branch details:

This service helps the Admin to view the branch details based
on requirement. The branch details like branch id, location,
address, phone

Page 30 of 48
 CORE BANKING

• View Account Type Details:

This service helps the Admin to view the account type details
based on
requirement. The account details like minimum balance,
account name,
interest, period of the account type that is requested are
displayed.

• Logout:

Whenever the Admin wants to quit the

application he needs to use this service so that the session
will be invalidated so that no one can access his account thus
restricting others in accessing the Admin’s account.

Page 31 of 48
 CORE BANKING

2) Actor --Cashier

The Cahier module consists of the following services:

1) Login
2) Change profile
3) Create account
4) View account details
5) Deposit
6) Withdrawal
7) View balance
8) Transfer amount Details
9) Generate a/c stmt
10) View messages
11) Send messages
12) Logout

• Login:

In this process, Cashier enters his username (i.e. his empid),

password and submitted details are verified at the server side. If
he is authorized, then only he is presented with his remaining
services otherwise his access is denied.

• Change profile:

In this process, Cashier has a privilege to edit his own profile

like his telephone number, Email and address.

Page 32 of 48
 CORE BANKING

Create Customer Account:

In this process, Cashier enters all the customer details that are
required to create the account such as account details, personal
details, account options, account nominee details and the account
additional information. Incase he gets any request for opening a
new account by the customer then that will also be collected and
the request is forwarded to Manager for approval. After the
approval of account the account number that is auto generated by
the system is used to identify the customer’s account for any
further transactions.

Page 33 of 48
 CORE BANKING
View Account Details:

With this service, the Cashier has the privilege to view the account
details of each customer who has an account and based on these
details other transactions like deposit, withdrawal etc are
processed.

Deposit:

This service is used by the Cashier whenever a customer

credits some amount into any of the account. This amount is
deposited and the transaction is recorded into the concerned
account by the cashier for the later use.

Withdrawal:

In this process, when a customer makes a request

for withdrawing some amount from his account, then Cashier
enters customers account details with account no and issues
cash to the customer based on the availability of the
requested amount in his account.

Page 34 of 48
 CORE BANKING

View Balance:

Cashier is provided with a service of viewing the

customer’s account balance whenever required. Here he
enters the customer’s account number and views balance
amount. This information can also be used to do other kinds
of transaction like withdrawal and Transfer of amount.

Page 35 of 48
 CORE BANKING

• Transfer Amount Details:

This service serves the Cashier when customer

sends a request to process the Transfer of amount from his
account to other. The source and destination account
numbers along with their balances are verified to be correct
inorder to process the request. Also this transaction is
recorded that can be of use in future.

Generate Account Statement:

Account statement is a statement that shows all the

transactions made by the customer in his account. The
Cashier checks customer account details based on his accno
and based on his transactions, generates an account
statement for that respective customer and the respective
period of time.

Page 36 of 48
 CORE BANKING

• Send messages:

With this service, Cashier is capable to send

messages to any other user based on the requirement that is
raised at any time. This service takes to address, subject and
message as the input from the Cashier and after sending the
data to the respective recipient successfully, the
acknowledgement is sent to him.

Page 37 of 48
 CORE BANKING

View messages:

This privilege lets the Cashier to view the messages

that are in his inbox.

Logout:

Whenever the Cashier wants to quit the application

he needs to use this service so that the session will be
invalidated so that no one can access his account thus
restricting others in accessing the Cashier’s account.

Page 38 of 48
 CORE BANKING

3) Actor: Manager
The Manager module consists of the following services:

1) Login
2) Change profile
3) Approve/Reject Account
4) Send Messages
5) View Messages
6) View account type Details
7) View employee Details
8) View branch details
9) View Customer account details
10) Closing an account
11) Logout

• Login:

In this process, Manager enters his username (i.e. his empid),

password and submitted details are verified at the server side. If
he is authorized, then only he is presented with his remaining
services otherwise his access is denied.

• Change profile:

In this process, Admin can edit his own profile like his telephone
number , Email and address.

Approve/Reject Account:

Manager is the only one who has the authority to either accept or
reject the customer’s account based on the organization’s terms
and conditions, since he is a decision maker for whole financial
system.

Page 39 of 48
 CORE BANKING

Page 40 of 48
 CORE BANKING

Send messages:

With this service, Manager is capable to send messages to any

other user based on the requirement that is raised at any time. This
service takes to_address, subject and message as the input from
the Manager and after sending the data to the respective recipient
successfully, the acknowledgement is sent to him.

Page 41 of 48
 CORE BANKING

View messages:

This privilege lets the Manager to view the messages that are in his
inbox.

View Account Type Details:

Similar to Admin’s service, Manager also has the

privilege to view the account type details if required. The
account type details like minimum balance, account name,
interest, period of the account type that is requested are
displayed.

Page 42 of 48
 CORE BANKING

• View Employee Details:

The Manager also has the capability to view the

employee details just as that of Admin. Using this process,
Manager can view employee details like his personal profile as
well as other details related to organization.

• View Branch Details:

This is a common service of both Admin and

Manager, which helps to view the branch details based on
requirement. The branch details like branch id , location,
address, phone number, pin code of the branch name that is
requested are displayed.

Page 43 of 48
 CORE BANKING

Closing an account:-

The Manager has also the capabilities to close the account.

• Logout:

Whenever the Manager wants to quit the

application he needs to use this service so that the session
will be invalidated so that no one can access his account thus
restricting others in accessing the Manager’s account.

Page 44 of 48
 CORE BANKING

4) Actor: Customer
The Customer module consists of the following services:

1) Registration
2) Login
3) View account details
4) Change profile
5) Request to change account type/branch/account options
6) View account statement
7) Transfer amount details
8) Send Messages
9) View Messages
10) Logout

• Registration:

With this service a new customer can create an

account and register into the system. In this customer has to
enter accounts details like actype, date of open , balance ,
jointly also his personal details like accholder , fname ,
lname , date of birth ,marital status ,nationality, address ,
pan no, pin, photo, signature etc. After these details are
entered then customer is given option of choosing the means
he can obtain his details and it can be through internet,
phone, smart card, debit card, telebanking etc. After that
customer has to enter Account Nomination details like
nominees name, address, relation, age, minor, date of birth.
After this is entered accounts additional information has to
be entered like occupation, source of funds, monthly income,
annual turnover , abroad relative name, relationship,other
bank name, other account type. Finally Customer gets
registered in the corebanking system and customer’s account
no(accno) is generated and for every further request
customer makes he has to use this accno as his login and
enter into the corebanking system. So, in this way a new
customer sign’sup into the system and uses the services
provided by the system.

Page 45 of 48
 CORE BANKING

• Login:

In this process, Customer enters his username (i.e.

his empid), password and submitted details are verified at
the server side. If he is authorized, then only he is presented
with his remaining services otherwise his access is denied.

• View Balance:

In this service, customer views his account details

that he entered and account details like number,
acctype,branch can be viewed by customer.

• Change Profile:

In this, Customer can edit his personal profile like

his telephone number, email and address .

Page 46 of 48
 CORE BANKING

• Request to change account type:

In this customer based on his accno makes a

request to cashier to change his account type .Cashier will see for
the request and makes changes to customer account details.

• View Account Statement:

Account statement is a statement that shows all

the transactions made by the customer in his account
statement. Cashier checks customer account details based
on his accno and based on his credit and debit cashier
generates an account statement for that respective
customer. So in this, account statement generated by
cashier is viewed by the Customer.

• Transfer Amount Details:

In this when customer sends a request to
cashier, then cashier is responsible to transfer amount
from one account to other account or from one branch to
other branch.

Page 47 of 48
 CORE BANKING

• Send messages:

With this service, Customer is capable to send

messages to any other user based on the requirement that is
raised at any time. This service takes to address , subject and
message as the input from the Manager and after sending the
data to the respective recipient successfully, the
acknowledgement is sent to him.

• View messages:

This privilege lets the Customer to view the

messages that are in his inbox.

Page 48 of 48