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. Page 1 of 60
Transcript
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
Page 1 of 48
CORE BANKING
decentralized model to a centralized data center
architecture
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.
Page 2 of 48
CORE BANKING
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 be developed. SRS should accurately and completely represent the system requirements.
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.
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 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?
Page 5 of 48
CORE BANKING
Let’s start by looking at how the Model, the View, and the Controller interact with one another:
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
Page 6 of 48
CORE BANKING
DESIGN PATTERN
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.
ForcesPortability 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 sssssockets. The 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
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
Page 8 of 48
CORE BANKING
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 MigrationA 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 ObjectsBecause 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.
Scope of The Development Project
Page 9 of 48
CORE BANKING
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.
The managers and non-manager staff (cashier) user
interface helps the respective actors in transacting
Page 11 of 48
CORE BANKING
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:-
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.
Page 12 of 48
CORE BANKING
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:
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.
Page 13 of 48
CORE BANKING
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
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.
Page 14 of 48
CORE BANKING
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:-
A directives are translation time instructions to jsp
engine .Jsp directives describe the overall structure of
jsp.
A jsp contain 3 directives
Page 15 of 48
CORE BANKING
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.
Users of the system
Admin
Page 16 of 48
CORE BANKING
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
Page 17 of 48
CORE BANKING
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
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.
Page 18 of 48
Staff 1.1 Accept UserName, Password
Administrator
Cuostomer
CORE BANKING
Low Level Data Flow Diagram:
Page 19 of 48
1.2Verify Details
Login
Validation Data
1.1Accept UserName, Password
casheir
CORE BANKING
Page 20 of 48
1.2Verify Details
Login
Validation Data
Process Data Store
Create account
Deposit/withdraw/transfer
Send Message View Messages
Generate statement
View customerdetails/viewb
alance
1.1
Staff
1.2Verify DetailsLogin
Validation Data
CORE BANKING
Page 21 of 48
Process
Accept/reject account
View customer
viewbranch
View account
type
Send Message
View MessageView empdetails
1.1 Accept UserName, Password
customer
1.2Verify Details
CORE BANKING
Page 22 of 48
Login
Validation Data
ProcessData Store
View accountdetails
Change account details
View balance Send Messages View Messages
CORE BANKING
Page 23 of 48
Corporate_Details
Register_Of_Employee
Joining_Datee
Emp_ Id
Dept_no
Sal
Category
BranchAddr
E-mail
Phone
Messages
To_Addr
Subject
From_Addr
Date_Of_Gen
Message
Registers
View & Send
CORE BANKING
1) Actor: Admin
The Admin module consists of the following services:1) Login2) Create new Account types3) Adding new Branch 4) Registering a new Employee5) View Employees information6) Change profile7) Change Employee designation8) Change branch details9) Change Account Type details10) Send message11) View message12) Block/Remove Employees13) View account type Details14) View branch details15) 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:
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
Page 27 of 48
CORE BANKING
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.
Add new Employees:
Page 28 of 48
CORE BANKING
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.
Send messages:
Page 29 of 48
CORE BANKING
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
View Account Type Details:
Page 30 of 48
CORE BANKING
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.
2) Actor --Cashier
The Cahier module consists of the following services:
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.
Create Customer Account:
Page 32 of 48
CORE BANKING
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.
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.
Page 33 of 48
CORE BANKING
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.
View Balance:
Cashier is provided with a service of viewing the customer’s account balance whenever required. Here he
Page 34 of 48
CORE BANKING
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.
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
Page 35 of 48
CORE BANKING
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.
3) Actor: Manager
Page 38 of 48
CORE BANKING
The Manager module consists of the following services:
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.
Closing an account:-
Page 43 of 48
CORE BANKING
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.
4) Actor: Customer
The Customer module consists of the following services:
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.
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.
Page 45 of 48
CORE BANKING
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 .
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.
Page 46 of 48
CORE BANKING
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.
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
Page 47 of 48
CORE BANKING
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.
