Oracle Flexcube Implemention

Implementation
Oracle FLEXCUBE Universal Banking

Release 11.3.0
[May] [2011]
Oracle Part Number E51536-01
Implementation
Table of Contents
1. ABOUT THIS MANUAL ............................................................................................................................... 1-1
1.1 INTRODUCTION ........................................................................................................................................... 1-1
1.2 ORGANIZATION .......................................................................................................................................... 1-2
1.2.1 Abbreviations and Jargon ................................................................................................................. 1-3
1.2.2 Glossary of Icons ............................................................................................................................... 1-4
2. THE HOMEWORK ........................................................................................................................................ 2-1
2.1 INTRODUCTION ........................................................................................................................................... 2-1
2.2 STRUCTURE OF IMPLEMENTATION TEAMS .................................................................................................. 2-1
2.3 THE PROJECT PLAN .................................................................................................................................... 2-2
2.4 METHODOLOGY FOR STATUS REPORTS ...................................................................................................... 2-2
2.4.2 Support Status Report........................................................................................................................ 2-4
2.5 COMPONENTS OF THE PROJECT PLAN ......................................................................................................... 2-5
2.5.1 Management Summary of the Project................................................................................................ 2-5
2.5.2 Project Plan for the bank................................................................................................................... 2-6
2.5.3 Implementation Team ........................................................................................................................ 2-7
2.5.4 Project Monitoring ............................................................................................................................ 2-7
2.5.5 Hardware Planning ........................................................................................................................... 2-7
2.5.6 Hardware/Software Installation ........................................................................................................ 2-8
2.5.7 Client Workstation Requirements ...................................................................................................... 2-9
2.5.8 User Documentation........................................................................................................................ 2-10
2.5.9 Oracle FLEXCUBE User Training.................................................................................................. 2-10
2.5.10 Security Management System and Controls .................................................................................... 2-11
2.5.11 Branch Database Design................................................................................................................. 2-11
2.5.12 Static Data Input.............................................................................................................................. 2-11
2.5.13 Oracle FLEXCUBE System Trial Run............................................................................................. 2-12
2.5.14 Contingency Plan ............................................................................................................................ 2-12
2.5.15 Stationery......................................................................................................................................... 2-13
2.5.16 Job stream formulation.................................................................................................................... 2-13
2.5.17 Pre-conversion trial run .................................................................................................................. 2-13
2.5.18 Financial conversion ....................................................................................................................... 2-14
2.5.19 Parallel Run..................................................................................................................................... 2-14
2.5.20 Index ................................................................................................................................................ 2-15
3. AUDIT REQUIREMENTS ............................................................................................................................ 3-1
3.1 INTRODUCTION ........................................................................................................................................... 3-1
3.2 CONTROLS .................................................................................................................................................. 3-1
3.2.1 Controls during Software Installation ............................................................................................... 3-1
3.2.2 Controls during database set-up ....................................................................................................... 3-1
3.2.3 Controls during System Trial Run ..................................................................................................... 3-2
3.2.4 Controls while making a change to the code..................................................................................... 3-2
3.3 PROJECT DOCUMENTATION ........................................................................................................................ 3-3
3.3.1 Management Documentation............................................................................................................. 3-3
3.3.2 System Documentation....................................................................................................................... 3-3
3.3.3 Software Installation.......................................................................................................................... 3-3
4. DATABASE DESIGN ..................................................................................................................................... 4-1
4.1 INTRODUCTION ........................................................................................................................................... 4-1
4.1.1 The designers..................................................................................................................................... 4-1
4.1.2 The design process............................................................................................................................. 4-1
4.1.3 Review of Products ............................................................................................................................ 4-2
4.1.4 Review of Account and Ledger structure........................................................................................... 4-2
4.1.5 Outlining Basic Core Parameters...................................................................................................... 4-2
4.1.6 Gathering Customer Data ................................................................................................................. 4-3
4.1.7 Outlining Product Level Parameters................................................................................................. 4-3
4.1.8 Review of Advice, Reports and MIS Requirements............................................................................ 4-4
4.1.9 User Profiles Including Access Rights, Transaction and Authorization Limits ................................ 4-4
4.1.10 System Performance Parameters....................................................................................................... 4-4
4.1.11 Other Activities .................................................................................................................................. 4-4
4.1.12 Review of the Design ......................................................................................................................... 4-5
5. DATA INPUT .................................................................................................................................................. 5-1
5.1 INTRODUCTION ........................................................................................................................................... 5-1
5.2 APPROACH.................................................................................................................................................. 5-1
5.3 METHODOLOGY .......................................................................................................................................... 5-1
5.4 CORE PARAMETERS AND TABLES INPUT SEQUENCE ................................................................................... 5-2
5.4.1 Core Parameters (Miscellaneous) Maintenance ............................................................................... 5-3
5.4.2 Bank/ Branch Parameters................................................................................................................ 5-11
5.4.3 Accounting Period Maintenance (Bank/ Branch Parameter).......................................................... 5-13
5.4.4 Holiday Maintenance....................................................................................................................... 5-13
5.4.5 System Date Maintenance (Bank/Branch Parameter)..................................................................... 5-13
5.4.6 Customer Maintenance.................................................................................................................... 5-14
5.4.7 Other Bank/Branch Parameters ...................................................................................................... 5-14
5.4.8 Revaluation...................................................................................................................................... 5-15
5.4.9 Limits ............................................................................................................................................... 5-15
5.4.10 Customer Accounts .......................................................................................................................... 5-16
5.4.11 Front-end Module Product Set-up................................................................................................... 5-16
6. DATABASE CALLBACK.............................................................................................................................. 6-1
6.1 INTRODUCTION ........................................................................................................................................... 6-1
6.1.1 Suggested List of Reports for Callback.............................................................................................. 6-1
7. SYSTEM TRIAL RUN ................................................................................................................................... 7-1
7.1 INTRODUCTION ........................................................................................................................................... 7-1
7.2 THE LOGISTICS ........................................................................................................................................... 7-1
7.2.1 The database for trial run.................................................................................................................. 7-1
7.2.2 The approach..................................................................................................................................... 7-1
7.2.3 Components of the trial run............................................................................................................... 7-2
7.2.4 Components of the Test Plan ............................................................................................................. 7-2
7.2.5 Handling Errors ................................................................................................................................ 7-2
7.2.6 The Schedule...................................................................................................................................... 7-3
7.2.7 Phase One.......................................................................................................................................... 7-3
7.2.8 Phase Two.......................................................................................................................................... 7-4
7.2.9 Phase Three ....................................................................................................................................... 7-4
8. FINANCIAL CONVERSION ........................................................................................................................ 8-1
8.1 INTRODUCTION ........................................................................................................................................... 8-1
8.2 THE PLAYERS.............................................................................................................................................. 8-1
8.3 SCOPE ......................................................................................................................................................... 8-1
8.4 PLANNING .................................................................................................................................................. 8-2
8.4.1 How to do........................................................................................................................................... 8-2
8.4.2 When to do ......................................................................................................................................... 8-2
8.4.3 Methodology ...................................................................................................................................... 8-2
8.4.4 Conversion Sequence......................................................................................................................... 8-3
8.4.5 Pre-conversion Checklist................................................................................................................... 8-3
8.4.6 Standard Instructions for Conversion ............................................................................................... 8-4
8.5 CONVERSION PROCEDURE .......................................................................................................................... 8-4
8.6 SAMPLE CONVERSION ACCOUNTING ENTRIES ............................................................................................ 8-5
9. PARALLEL RUN............................................................................................................................................ 9-1
9.1 INTRODUCTION ........................................................................................................................................... 9-1
9.2 CALLBACKS ................................................................................................................................................ 9-1
9.2.1 Training ............................................................................................................................................. 9-2
9.2.2 Dummy Conversion/Parallel ............................................................................................................. 9-2
9.2.3 Summary ............................................................................................................................................ 9-3
10. CONTINGENCY PLAN........................................................................................................................... 10-1
10.1 INTRODUCTION ......................................................................................................................................... 10-1
10.2 OVERVIEW................................................................................................................................................ 10-1
10.3 OPERATION RISK ASSESSMENT ................................................................................................................ 10-1
10.3.1 Brief Description of Location and Operations ................................................................................ 10-2
10.3.2 Major Causes of the Operational Risks........................................................................................... 10-2
10.4 CONTINGENCY PLANNING ........................................................................................................................ 10-3
10.5 SOFTWARE ERRORS OUTSIDE NORMAL WORKING HOURS ........................................................................ 10-4
10.5.1 Contingency Plan Distribution List ................................................................................................. 10-4
10.5.2 People who can Authorize Emergency Measures............................................................................ 10-5
10.5.3 Contact Points in Case of Hardware and Software Problems ........................................................ 10-5
10.6 POTENTIAL FOR EXPOSURE AND CONTAINMENT MEASURES .................................................................... 10-5
10.6.1 Hardware Failure............................................................................................................................ 10-5
10.6.2 Containment Measures .................................................................................................................... 10-6
10.6.3 Disk Drive Failure........................................................................................................................... 10-9
10.6.4 Remote Branch Communications/Modem Failure ........................................................................ 10-10
10.6.5 Software Failure ............................................................................................................................ 10-10
10.6.6 Utilities Failure ............................................................................................................................. 10-11
11. POST IMPLEMENTATION REVIEW .................................................................................................. 11-1
11.1 INTRODUCTION ......................................................................................................................................... 11-1
11.2 OVERVIEW................................................................................................................................................ 11-1
11.3 POST IMPLEMENTATION REVIEW GUIDELINES .......................................................................................... 11-2
11.3.1 System Environment......................................................................................................................... 11-2
11.3.2 System Administration Issues .......................................................................................................... 11-5
12. IMPLEMENTATION SIGN-OFF ........................................................................................................... 12-1
12.1 THE SIGN-OFF PROCEDURE ...................................................................................................................... 12-1
1. About this Manual
1.1 Introduction
The objective of this manual is to provide an understanding to the Oracle FLEXCUBE
implementation team at Oracle Financial Services (formerly i-flex) and the site, of the various
steps, components, tasks and requirements to implement Oracle FLEXCUBE.
This manual highlights the most common implementation activities to be performed. Further,
detailed background information on the objectives and the requirements for each major
implementation task is also provided in the manual.
This manual applies to Oracle FLEXCUBE implementations in all business units. Some of the
activities may be carried out in parallel and will commence well in advance of the actual Oracle
FLEXCUBE installation. Because of this, each branch will have a designated project manager
from Oracle Financial Services (formerly i-flex), who will coordinate all activities.
It is important to establish what an Oracle FLEXCUBE implementation involves. This can be

broadly divided into three phases, as follows:
 Pre-implementation
 Implementation
 Parallel Run
Pre-Implementation phase consists of all activities that have to be carried out before the project
team from Oracle Financial Services (formerly i-flex) arrives at the site. These activities typically
include recommending the hardware configuration needed for Oracle FLEXCUBE, preparation of
the project plan and identifying the project team from Oracle Financial Services (formerly i-flex).
On the client side, the activities could include installing and setting-up the hardware, network,
system software and ensuring the availability of other facilities requested by Oracle Financial
Services (formerly i-flex).
Implementation phase consists of installing Oracle FLEXCUBE software, user training, data
base design and financial conversion leading up to the start of parallel run. Our project manager
is responsible for installing Oracle FLEXCUBE software and conducting user training. The project
manager will also provide all necessary help to the branch users for other activities in this phase
and coordinate with the branch officer responsible for this phase to ensure success.
Parallel Run will involve running existing system along with Oracle FLEXCUBE and
reconciliation of the output until dropping off the old system and going live on Oracle FLEXCUBE.
The Oracle FLEXCUBE Implementation team, under the auspices of the Project Manager will
assist the branch in completing each phase of the implementation task.
1-1
1.2 Organization
This manual covers all the necessary stages involved with implementing Oracle FLEXCUBE in
any banking or financial services organization. The manual is organized as follows:
The Homework
The Project Plan section describes all the major activities such as who is responsible and
start/completion dates. It is to be used by the Project Manager from Oracle Financial Services
(formerly i-flex) and Senior Branch Manager as a Navigation Chart in determining quickly where
we are, what has been done, what remains to be done. The plan is updated weekly or twice a
month and distributed to Branch Management, Oracle Financial Services (formerly i-flex)
Management and Audit Division.
Audit Requirements
The Audit Requirements section describes the necessary procedures to be used during the
implementation of Oracle FLEXCUBE.
Software Installation
The Software Installation section describes the recommended software organizations,

environments and access controls on various directories to be used.
Database Design
The database set-up section describes the essential information gathering process for designing
the Database. Database design for the purpose of this section mainly involves identifying the
Bank/Branch level and core parameters, designing chart of account, crystallizing front end
products and product level parameters, Limits and MIS requirements.
Data Input
The Database Input section describes suggested methodology translation of the Database set-up
plan in chapter 5 into the Oracle FLEXCUBE Table. The activity primarily involves static database
(non-financial) input.
Database Callback
The Database Callback section describes the tables and fields that have to be verified after the
initial Database design and input is completed. Based upon the review further changes maybe
required and the callback performed on an ongoing basis, until the database is correctly setup.
System Trial Run
The System Trial Run section describes how the branch staff should conduct a trial run of the
system to ensure that Oracle FLEXCUBE software and hardware is functioning properly and in a
controlled manner.
1-2
Financial Conversion
The Conversion section describes how the conversion process (loading of financials into Oracle
FLEXCUBE for the first time) will take place for branches that are currently manual or migrating
from an existing automated system including MicroBanker to Oracle FLEXCUBE.
Parallel Run
The Parallel Run section explains how the postings on Oracle FLEXCUBE and the existing
system (manual or otherwise) will be conducted, the callbacks and reconciliation to be performed.
Contingency Plan
The Contingency Plan section describes the procedures to be followed in case of disruption of
business due to abnormal or emergency situations.
Post- Implementation Review
The post- implementation review section describes the criteria to be used in a post-
implementation review, which will be conducted by QAG team from Oracle Financial Services
(formerly i-flex). The thrust of this review is to ensure that the implementation process, as defined
in the Implementation Manual has been followed, audit/control issues have been adhered, and
how the next implementation can be improved. Relevant feedback from this review will be
incorporated into the implementation manual.
Implementation Sign-Off
The Implementation Sign-Off section describes the list of activities to be completed before getting
sign-off from the branch.
1.2.1 Abbreviations and Jargon
The following abbreviations and jargon have been used in the manual:
DBA Database Administrator
GL General Ledger
OS Operating System
POIROT Problem Incident Recording and Tracking System
RDBMS Relational Database Management System
BC Bills & Collections
FC Oracle FLEXCUBE
FT Funds Transfer
FX Foreign Exchange
1-3
IC Interest & Charges
LC Letters of Credit
LD Loans & Deposits
MM Money Market
RE Reconciliation
SE Securities
SI Standing Instructions
SV Signature Verification
SFR Software Fix Report
SPC Single Point of Contact
Front Refers to FX, MM, FT, LD, LC, BC, SE and SI

end modules
1.2.2 Glossary of Icons
This User Manual may refer to all or some of the following icons:
Icons Functio
n
New
Copy
Save
Delete
Unlock
Print
Close
Re-open
Reverse
Template
1-4
Icons Functio
n
Roll-over
Hold
Authoriz
e
Liquidate
Exit
Sign-off
Help
Add row
Delete
row
Option
List
Confirm
Enter
Query
Execute
Query
Refer the Procedures User Manual for further details about the icons.
1-5
2. The Homework
2.1 Introduction
There are a number of things you have to do in those order has been signed and my papers are
being processed days. This chapter outlines these activities.
Coming first in the list of a number of things are the following:
 Structure of the implementation teams
 The project plan
 Methodology for status reports
PS: Add informing people back home about your address and telephone number at the project
site, and the contact person at Oracle Financial Services (formerly i-flex).
2.2 Structure of Implementation Teams

The Implementation Team from will comprise one or more members, of which one member will
be identified as the Project Manager. Reporting relationships between the members of the
implementation team and the head of implementation should be clearly understood.
At its end, the bank will identify a Project Manager, who will be a single point of contact between
the team from Oracle Financial Services (formerly i-flex) and the bank. A thorough knowledge of
the team structure helps establish and sustain the communication links amongst the
implementation members.
A typical structure of the Implementation Team is illustrated below:
2-1
2.3 The Project Plan
A tentative project schedule should be drawn up, listing the major activities and the proposed
time frames. It will help you define the goals of the project and give you a fair idea of the work
involved. When all the details of the project are known, this schedule can be enriched to generate
a comprehensive project plan. This plan will include time frames, resource requirements and
utilization of resources.
The project managers of the implementation project, both from Oracle Financial Services and the
bank should draw up the project plan. It should be modified (if necessary) and updated
periodically. Communication about the project plan, its progress and modifications should be
copied to the following people. Who should be directly involved in project planning at their
respective levels:
 Senior Operations Manager of the bank
 Project Manager from Oracle Financial Services (formerly i-flex)
 Project Manager from the bank
 Financial Controller of the bank
 Head of Information Technology Division
 Head of the Internal Control Unit
The project plan should clearly identify duties, responsibilities and the tentative dates for start and
completion of various activities. The progress should be monitored at regular intervals.
2.4 Methodology for Status Reports

A formal and regular reporting process should be established at the very beginning of the project
and continued till it ends. This ensures that progress is monitored regularly and problems are
highlighted appropriately; thus not giving scope to any conflicts in the future.
Status Reports are of two types. Current Status Report should be sent to the Head of
Implementation every fortnight from the day you begin the project. Another type of report is the
Support Status Report generated every fortnight after the bank is live on Oracle FLEXCUBE. This
report should be addressed to the Single Point of Contact with the bank and copied to the
Implementation Head and Head of Global Support at Bangalore.
The Current Status Report should give the following information:
 Work completed during the fortnight.
 Work scheduled for the next fortnight.
 Problems encountered during the fortnight.
 Billing details.
2-2
The following is a sample Current Status Report:
2.4.1.1.1.1.1.1.1 Current Status Report
1. The Project: Implementation of Oracle FLEXCUBE at First Commercial Bank at Melbourne,

Australia (FCB)
2. The People:
Customer Ms. Annabel Smith (IT Head)
Mr. Jim Hacker (Systems Manager)
Oracle Financial Services Sylvia John
Ramkrishnan S
3. Reporting Period: 15/03/98 to 31/03/98
4. The Schedule
Activity Plan Actual Responsibility Remarks
Start End Start End
S/w Installation 15/03 17/03 20/03 Oracle Financial Given below

19/03 Services
User Training 22/03 23/03 In Oracle Financial Given below

25/04 progress Services
Database Set- 24/03 24/03 In Oracle Financial Given below

up 30/04 progress Services
Remarks: Software installation was delayed because hardware was not available. User training was
delayed because a few key users were on leave. Database set-up has begun.
5. Action Items:
Activity Plan Actual Responsibility Remark

s
Start End Start End
Code Structures 08/04 FCB
General Ledger 08/04 FCB
2-3
Activity Plan Actual Responsibility Remark
s
Start End Start End
List of 08/04 FCB

Customers
6. Achievements during the period:
Software installation completed.
User training for Data Entry module completed.
7. Outstanding Issues:
None
8. Plan for the next fortnight:
User training for Foreign Exchange and Money Markets. Database set-up for Branch Parameters,
Customers, General Ledger.
9. Billing details:
Professional working days: 10 working days + 1 Saturday
Milestone achieved for billing: S/w installation
Expenses to be billed to client: Airfare and incidental expenses to Melbourne.
2.4.2 Support Status Report
The Support Status Report should be generated after the branch has cut-over to live. This report
is a summary of the problems solved during the fortnight. The number of problems raised, solved
and outstanding should be listed first, followed by a brief description of the problems and
solutions provided. For outstanding problems, the proposed course of action should be stated.
The following is a sample Support Status Report:
2.4.2.1.1.1.1.1.1 Support Status Report
Reporting Period: 16/02 to 30/03
1. The Statistics
2-4
Category Queries Problems
Brought forward from last report. 05 09
Received in this period. 02 00
Solved/Answered. 05 04
Not a problem. 00 00
Referred back to the bank for more 00 00

information.
Outstanding. 02 05
2. Description of queries answered
Query on Accounting Role Mapping Explained.
3. Description of problems solved
Minor UI error on Journal Entry input form (Till No 001).
4. Outstanding Problems
Another Minor UI Error on SV form (being Fixed).
5. Information awaited from Site
Problems faced in implementing the solution for changing term deposit contracts.
2.5 Components of the Project Plan

An implementation project can be divided into various phases. The format for the plans for these
phases is given in this section.
2.5.1 Management Summary of the Project
This master plan identifies the dates, responsibilities and status of the various phases of
implementation. This plan is a good reference for the management at the bank and Oracle
Financial Services for monitoring the project. This plan should be in the following format:
2-5
Activity Who PS PE AS AE Statu
s
Project plan preparation.
Hardware installation.
Communication drivers installation.
Oracle installation.
Oracle FLEXCUBE installation.
User training.
Data Center Staff training.
Database design.
Database set-up / Static

conversion.
System trial run.
Financial conversion.
Parallel run.
2.5.2 Project Plan for the bank
Objective
To prepare the project plan for the implementation of Oracle FLEXCUBE at the site

s
Discuss strategy with Oracle

Financial Services .
Prepare draft plan.
Finalize plan.
Finalize contracts, agreements, etc.
Milestones
2-6
2.5.3 Implementation Team
Objective
To select a team of personnel from the bank, who will be responsible for the implementation of
Oracle FLEXCUBE.

s
Evaluate activities and personnel needed.
Select the Project Manager for the branch.
Select the implementation team for the

branch.
Define responsibilities.
Milestones
2.5.4 Project Monitoring
Objective
To monitor the project by holding meetings and reviews

s
Form the Automation Committee for the

branch.
Conduct weekly meetings.
Send fortnightly status reports.
Milestones
2.5.5 Hardware Planning
Objective
To plan, organize and complete all the preparatory work for setting- up the hardware required for
the implementation of Oracle FLEXCUBE.
Activity Who PS P AS AE Stat

E us
Oracle Financial Services to recommend hardware

configuration.
Decide on hardware Configuration.
2-7
Activity Who PS P AS AE Stat
E us
Decide-Import Hardware or to buy locally.
Budget approval.
Order Hardware.
Clear hardware from customs or acquire it.
Finalize support.
Milestones
2.5.6 Hardware/Software Installation
Objective
To install hardware/software at the site for operation of Oracle FLEXCUBE

s
Install recommended hardware.
Test hardware and workstations.
Install UNIX .
Install Oracle on server.
Install Oracle on client.
Install SQLNET.
Install DEV2000/Forms/JDeveloper/PL-SQL
Developer/Reports Runtime etc.
Install Third party software - Business Objects/

BIP/OBIEE/BPEL/Control Software.
Installing JRE/MSXML and required software on

client machine for accessing Oracle FLEXCUBE
Application. Get the versions supported from DBA
team.
Install third party hardware – Scanners.
2-8
2.5.7 Client Workstation Requirements
The following software needs to be installed on Internet Explorer.
 IE Version – 6.0 and above
 MSXML Parser – 4.0

 Please look for msxml4.dll under C:\Windows\System32 directory. Ensure that the
option to hide system files is not chosen. If the dll is not there, install MSXML Parser
4.0.
 JDK Version – 1.5.0_03 and above
 To check the version installed on your machine, go to command prompt and execute
‘java –version’.
 If the version is 1.5.0_03 or above, it is fine.
 Otherwise, get JDK 1.5.0_03 or above installed on your machine.
 JRE Version – 1.5.0_03 and above
To check and activate the installed version on your workstation, do the following:
1. Open Internet Explorer
2. Go to Tools Menu  Click Internet Options
3. Go to Advanced Tab  Scroll down and you should see Java (Sun), under which option Use
Java 2 v 1.5.0_03 for applet.
4. Check this option.
5. If either the option is not available or the version no is lesser than 1.5.0_03, install JRE
1.5.0_03 or above on the system.
6. After installation, go to Control Panel.
7. Double click on Java Plug-in
8. Go to advanced tab and select the appropriate JRE version.
9. Go to browser tab and select Internet Explorer and apply the settings
10. Restart the Internet explorer and you should see the changed settings.
The following intranet settings are required for running FCJ
11. Open Internet Explorer
12. Go to Tools Menu  Click Internet Options
13. In General tab, click on ‘Settings…’. Choose the option for ‘Check for newer versions of the
stored pages’ as ‘Every visit to the page’
2-9
14. Go to Security Tab Click on Local Intranet  Click Custom Level button
15. Set Enable for all the options that you can see.
16. Set Low Safety for safety options.
17. If the operating system in Windows XP, there will be an option ‘Use Pop-blocker’, this should
be disabled.
Get the versions supported by the Database Administration team.
2.5.8 User Documentation
Objective
To provide user documentation to the bank before the implementation of Oracle FLEXCUBE
actually begins.

s
Obtain user
documentation.
Milestones
2.5.9 Oracle FLEXCUBE User Training
Objective
To provide the personnel at site with relevant training in hardware, software and system usage

s
Identify training needs.
Train Data Center staff on UNIX/Oracle?
Train users on Oracle FLEXCUBE

application.
Obtain feedback on training.
Milestones
2-10
2.5.10 Security Management System and Controls
Objective
To evaluate and choose the access structure for all functions of Oracle FLEXCUBE. Appoint a
member of the Internal Control Unit as a Systems Administrator, to maintain a protected
environment for Oracle FLEXCUBE.

s
Define security levels according to

functions.
Implement control procedure.
Milestones
2.5.11 Branch Database Design
Objective
To choose a database structure in the system that will provide maximum advantage and
flexibility.

s
Prepare database training

plan.
Conduct database training.
Design database.
Milestones
2.5.12 Static Data Input
Objective
To input the static data necessary for the branch, based on the database design. This is an
activity that has to be carried out before the financial conversion.

s
Complete database input forms.
Maintain database based on input

forms.
Check database against source
2-11
s
documents.
Milestones
2.5.13 Oracle FLEXCUBE System Trial Run
Objective
To conduct a system trial run to ensure that it meets the requirements of the branch and to
familiarize users with Oracle FLEXCUBE functions.

s
Prepare system trial run

plan.
Prepare input data.
Conduct system trial run.
Branch sign-off.
Milestones
2.5.14 Contingency Plan
Objective
To assess the risks and formulate a plan to minimize downtime in the event of a fault in the
hardware or software or network

s
Complete risk analysis.
Prepare contingency plan.
Review contingency plan.
Audit sign-off for contingency

plan.
Milestones
2-12
2.5.15 Stationery
Objective
To evaluate the stationery requirements for source documents, manager checks, demand drafts,
customer account statements and advices.

s
Determine
requirements.
Order stationery.
Acquire stationery.
Milestones
2.5.16 Job stream formulation
Objective
To define the necessary job streams, start-of-day, end-of-day and end-of-month procedure.
Activity Who PS PE AS AE Status
Evaluate work flows.
Document job streams.
Define End of Day and End of Month

procedures.
Milestones
2.5.17 Pre-conversion trial run
Objective
To conduct a final system trial run on the Oracle FLEXCUBE software, UNIX software, Oracle
and network, hardware before the actual financial conversion. This will ensure that the
performance will be satisfactory.

s
Prepare trial run plan.
Prepare trial run input data.
Conduct trial run.
2-13
s
Branch sign-off for financial

conversion.
Milestones
2.5.18 Financial conversion
Objective
To convert the existing financial data to the Oracle FLEXCUBE system

s
Define conversion
strategy.
Select conversion date.
Financial conversion.
Milestones
2.5.19 Parallel Run
Objective
To prepare a full parallel run plan. This involves running the old system in parallel with Oracle
FLEXCUBE.

s
Prepare draft work flows and

procedure.
Finalize parallel plan.
Parallel start.
Obtain audit approval to end parallel.
Start live operation.
Milestones
2-14
2.5.20 Index
Who The person responsible for completion of the

task
PS Planned Start
PE Planned End
AS Actual Start
AE Actual End
Status Status of event
2-15
3. Audit Requirements
3.1 Introduction
This chapter outlines the audit requirements to be met by the implementation team. They can be
broadly categorized into two types; controls and documentation of processes.
3.2 Controls
Controls for system security fall into several categories:
 Controls during software installation
 Controls during data base set-up
 Controls during system trial run
 Controls while making a change to the code
3.2.1 Controls during Software Installation
The following is the list of processes to be followed before the software is installed on the main
machine (the machine on which the bank will carry on its daily operations):
 The plan for the installation should be distributed to all the concerned people at the bank.
This plan should explain how the software will be put into operation. The progress and
changes in the plan should be notified regularly to all these people.
 The procedure for logging errors should be established. It should state the steps involved
for recording and tracking errors.
 A hand-off note of the system should be given to the data center operations.
 The procedure for handling contingencies should be documented. The concerned staff
should be aware of the reports that have to be used, if the system is not available due to
hardware or software problems.
 Training for the Data Center operators, users and the System Administrator should be
completed.
 All sign-offs should be completed.
3.2.2 Controls during database set-up
The database set-up should take place in a well-controlled environment. The characteristics of
this controlled environment are as follows:
3-1
 If the data is to be uploaded automatically, a written approval should be obtained from
the Manager - Operations. This approval should be obtained on the basis of the
Database Design document and Conversion Plan Document prepared for this purpose.
These documents should form the references for post-upload checks. Spread Sheet and
Code translation tables used for upload also have to be verified and approved. The
automated upload can be of two types. The input can be automated while the
authorization is manual or both input and authorization are automated. In either case, a
Maintenance Control List or List of Data uploaded should be taken immediately after the
upload, which has to be signed-off by the Manager-Operations.
 The data should be input only after the concerned person authorizes the Software Data
Input forms. Ideally, it should be prepared by the maker, checked by a checker, entered
by the input clerk and the data input authorized by an authorizer.
 The entire database set-up should be signed-off by the bank s Internal Control Unit
before the financial conversion begins.
3.2.3 Controls during System Trial Run
A trial run has to be conducted by the users before the operations go live. The objective of the
trial run is to ensure that requirements of the customer are met. The test plan for the trial run
should be prepared by the users themselves. The implementation team should only assist them.
The system trial run should be conducted in a controlled test environment. The software and test
data files should be protected from random development changes during the trial run.
The documentation of the System Trial Run should consist of the following:
 The test plan for the Trial Run
 The data used for the Trial Run
 The results of the Trial Run
 Any variations and problems
 Any corrective actions taken
The System Trial Run should be signed-off by the internal auditors of the bank. The basis for this
sign-off is the documentation of the Trial Run.
3.2.4 Controls while making a change to the code
Any problem that needs a software fix should be recorded through the POIROT.
When a program is to be modified at the site, two extra environments should be maintained, as
follows:
Development Environment where the programs should be modified, unit tested and system
tested by a member of the implementation team.
3-2
Acceptance Environment where trial runs of modified programs should be conducted. The trial
run should be completed before the program is copied on to the main environment where the live
operations are going on.
A separate schema with skeletal data can be maintained for this purpose.
Please note that no changes should be made directly onto the main environment.
Access controls to the Development and Acceptance environments should be limited to the
members of the implementation team from Oracle Financial Services.
The fix that has been put in has to be recorded in the POIROT.
3.3 Project Documentation

There are two kinds of project documentation:
 Management Documentation
 System Documentation
3.3.1 Management Documentation

 A project plan, which defines the scope of the project, objectives, budgets, task
scheduling, time frames and deliverables, should be prepared.
 A progress report of the project should be documented and circulated every fortnight.
 The minutes of the management review and discussion should be documented.
3.3.2 System Documentation

 Updated system documentation should be maintained. This should include:
 Enhancement specifications and approval
 Software inventory lists
 Training Manuals
 Operations Manual
 User Manuals
 Implementation Manual
 The test plan for System Trial Run
3.3.3 Software Installation
The details of installing Oracle FLEXCUBE are discussed in the ‘Oracle FLEXCUBE Release and
Installation’ document.
3-3
4. Database Design
4.1 Introduction
Oracle FLEXCUBE offers very high degree of flexibility to the users in respect of basic
parameters around which the bank operates or wishes to operate. This is one of the most critical
activities in the implementation project and requires a detailed analysis of the bank s current and
expected operations. The exercise involves not only understanding and translating the existing
process methodologies but also suggesting and exploring the possibilities of better and improved
strategies so as to exploit the full potential of Oracle FLEXCUBE. This activity in fact begins
during the product walk-through stage itself.
4.1.1 The designers
The team doing the database design comprises the following:
 Project Manager from the bank
 Financial Controller of the bank
 Functional heads of the bank
 IT head
 Key operational staff
4.1.2 The design process
The process involves the following major steps:
 Review of products/business offerings of the bank
 Review of Account and Ledger structure
 Review of charges/interest items
 Outlining basic core parameters
 Gathering Customer Data, including credit lines.
 Outlining product level parameters.
 Review of advice, reports and MIS requirements.
 User profiles including access rights, transaction and authorization limits etc.
 System performance parameters.
4-1
4.1.3 Review of Products
The spectrum of products currently offered by the bank and those proposed to be offered by the
bank have to be carefully analyzed. The exercise would involve
 Identifying the nature of the products.
 Listing the basic features of each product.
 Possible regrouping of products based on common features or parameters.
 Restrictions of currency, branch, in the products.
 Differentiation in making available the products among different class of

customers/branches etc.
4.1.4 Review of Account and Ledger structure
The exercise involves designing the Chart of Account. The existing account structure has to be
analyzed and possibly redrawn based on the new requirements as also the keeping in view the
features offered by Oracle FLEXCUBE. The tiered (tree) structure of accounts, the nature and
type of each GL with parent-child relationship has to be established. Currency and branch
restrictions at each GL HEAD level have to be taken into account. The Central Bank and Head
Office reporting requirements have to be analyzed. The nature of account code structure (GL
account mask) has to be established and appropriate code numbers assigned to accounts.
4.1.5 Outlining Basic Core Parameters
Core level parameters and codes are established in this activity. Some of major parameters are:
 Bank/Branch parameters including name, address, GL mask, Customer a/c masks,

restricted passwords and other particulars.
 Currencies - Currencies used by the Bank, Currency codes, Currency pairs, Rate types,
Rate codes, Conversion definition etc.
 Reporting Lines - for Head office and Central Bank reports, establishing links with GL
accounts
 Holidays
 Accounting Periods - within a financial year
 Inter-branch Accounting set-up
 Limits - Lines, sub-lines
 Transaction codes with clearing float days etc
 Messaging Parameters
 Override Parameters
 Product groups
 Product Status codes
4-2
 Account Revaluation set-up
 End of cycle setup, including frequency of processes, sequence of process
 Classes for securities modules usage
4.1.6 Gathering Customer Data

 Establishing broad customer categories and account classes
 Obtaining a list of customers and reclassifying the customers based on the categories
(customers would also include Central Bank, correspondent banks, clearing house,
brokers etc.)
 Deciding on the Customer Identification code structure
 Allocating new CIF to the customers
 Obtaining other static information about the customers
 Maintaining a translation table for old and new CIF numbers if any
 Account statement periodicity
 Broker setup, including brokerage rates etc
4.1.7 Outlining Product Level Parameters
This is critical activity and should be very carefully undertaken. The products defined are
applicable across all branches and are defined only at H.O. Major steps involved are:
 Identifying products within each functional modules (including Account Class in respect
of Current Savings and Nostro Accounts)
 Identifying the basic features of each product for product level parameters, including the
events for each product
 Identifying the accounting entries to be passed and the advices to be generated for each
event
 Interest, commission, charges and fees applicable (ICCF Rules).
 Taxes Applicable (Tax Rules)
 Identifying GL accounts for the products including ICCF and tax components
 Product start date should be given carefully (the value date of the oldest live contract
under the product)
 Mapping accounting Roles to the respective accounts
 Identifying life cycle events and mapping accounting roles
 Product restrictions in respect of branch, currency, customer categories etc
 In the case of Securities module, the parameters have to be identified for three types of
Products – Security product, Portfolio product and Deal product
For more detailed product level parameters set-ups, respective user manuals must be referred to.
4-3
4.1.8 Review of Advice, Reports and MIS Requirements
 Examining various advices required to be generated during the life cycle events of a
product.
 Formats of all advices, including Customer Account statement.
 Customized advice formats for specific customers.
 Media for sending advices to various customers.
 MIS reports, codes including MIS cost codes, MIS classes, pool codes, MIS groups, GL
linkages
 Report set-up, including printer set-up, server and client printing
 Report generation periodicities and circulation
 Report and advice archival
4.1.9 User Profiles Including Access Rights, Transaction and Authorization

Limits
 Defining user profiles or roles
 User transaction limits
 User authorization limits
 Restricted passwords
 User time level
 OS, RDBMS access to Data center personnel, joint access etc
4.1.10 System Performance Parameters

 System parameters to optimize performance, at the OS level
 System parameters to optimize performance, at the RDBMS level
 System parameters to optimize performance, at the network level
 System parameters to optimize performance, at the workstation level
4.1.11 Other Activities

 Changes to existing workflow to take advantage of new system set-up
 Gathering information for customer accounts and nostro accounts
 Creating Translation tables for new and old account numbers
 Identifying vaults and cash tills
 Collecting data of user to product mapping in the operations for assigning user roles to
enable the users to do the work allotted to them
 Identifying Teller type transactions - including charge-bearing transactions
4-4
 Customer settlement accounts
 Branch level parameters for various modules with respect to accruals
 Deciding the source for consolidated financial reporting, in case of a phased

implementation, where some branches would be only on the old system and some would
be on Oracle FLEXCUBE
 Deciding backup procedures including frequencies, media etc
4.1.12 Review of the Design
The Database design should be reviewed and signed-off by everybody involved in the database
design exercise.
4-5
5. Data Input
5.1 Introduction
In this activity, the database is populated with the Parameters, Code set-up and other static
information (non-financial) as finalized in the database design activity.
5.2 Approach
The data input activity involves the following major steps:
 Breaking down the data base design and parameters into field level inputs.
 Working out the sequence of database table population.
 Deciding on the input methodology - manual, automated or mixed.
 Activity plan and time estimation, bunching of parallel activities where ever possible.
 Planning the resource requirement.
5.3 Methodology
Population of data into the database can be carried either manually or can be automated. Large
volume data are best automated. Parameter inputs of specialized and critical nature should be
manually input for better control. If the existing operations of the banks are carried out in multiple
systems (including manual registers, if any), it would be better if the data from these systems are
first collated and translated into a common system, such as spread sheet package.
Automated data population can be carried out using standard conversion tools supplied as a part
of tool-kit along with office automation package such as spreadsheets.
For banks moving from MicroBanker to Oracle FLEXCUBE, standard conversion tools for the
purpose would be used.
The data and field structure to be maintained in the spread sheet for upload should be clearly
worked out. As mentioned earlier, data relating to a common table, from different sources should
be collated and made available in a single spreadsheet. The IT department of the bank should be
made primarily responsible for making available the spread sheets in appropriate formats. Oracle
Financial Services implementation team may offer any assistance, if required.
Code and identifier translation from old values to new values should be carefully checked out.
Appropriate strategy should be evolved if the existing codes are not translated on one-to-one
basis. Such cases should be dealt with separately, if required, manually. A master list of all such
translations should be printed and kept aside for future cross-referencing.
Data which is planned to be input manually should be first filled in an appropriate input form and
verified and signed off by the person responsible.
5-1
Data input and conversion process is likely to be different for each installation. For every
implementation a conversion plan has to be prepared, covering all the activities of the bank,
automation strategies etc.
Before embarking on data input the following should be ensured:
 The conversion team is aware of the strategy and is familiar with input required.
 Responsibility for making available correct input data in spread sheets is fixed.
 Responsibility for checking and maintaining the code translation table and cross-
referencing master lists is spelt out.
 A dummy database or schema is created and the conversion tools are well tested.
 Sample inputs done by the team to become familiar with the forms.
 User ids are created with appropriate rights for the purpose of inputs.
5.4 Core Parameters and Tables input Sequence

Input of static data and parameters in various tables requires a specific sequence to be followed.
This is due the reason that certain tables are dependent on other tables, thus necessitating the
maintenance of those tables first. Inputs to some of the tables can be grouped together. It is not
necessary that all maintenance have to follow a sequence, certain inputs especially maintenance
of various products can be done in parallel, if they are independent of each other.
Sequence of main tables for maintenance and key fields are outlined as follows:
Maintenance Table Depends On
Core Parameter maintenance
Bank maintenance
Branch maintenance
Countries
Transaction codes
System dates maintenance Branch maintenance, Local holiday maintenance
Accounting periods maintenance
Status codes maintenance
Currency definition maintenance
Currency rate type maintenance
Currency pair maintenance Currency definition maintenance
Local holiday maintenance Branch maintenance
5-2
Maintenance Table Depends On
Currency holiday maintenance Currency definition maintenance
Clearing holiday maintenance
Currency denom. Maintenance Currency definition maintenance
Interbranch (IB) maintenance Branch maintenance, IB GLs maintenance
Reporting lines
GL. Reporting lines
Account class maintenance
Customer category maintenance
Customer (CIF) maintenance Branch maintenance, Customer category
Customer accounts Customer (CIF) maintenance, Currency,

maintenance ACCLASS
5.4.1 Core Parameters (Miscellaneous) Maintenance
Apart from maintaining bank and branch parameters, you will also have to maintain a set of
core (miscellaneous) parameters that govern processing in Oracle FLEXCUBE. The following
table describes the contents of the Oracle FLEXCUBE back-end table CSTB_PARAM that
contains all such miscellaneous parameters. Even though the contents of this table have been
described in some detail, it is actually not intended for the users of the bank to alter / add /
remove. Based on the processing requirements of the Bank, the data in this table will have to
be configured by the Oracle Financial Services implementation team during the
implementation process.
Parameter Name Description Typical Values &

Examples
Operating System related

parameters
OPERATING_SYSTEM The OS on which the UNIX / WINNT

Database is installed
WORK_AREA The path on the server Valid Directory

where server debug
output / any other
handoff file of Oracle
FLEXCUBE is written
DIRECTORY_SEPARATOR The character that /

denotes directory
separation
5-3
Examples
ESC_SEQ Specifies the escape (s8S

sequence for printing
SPOOL_OS Used to indicate the WINNT

Operating System and
based on the operating
system path
convention, the report
spool path and path for
moving and purging
the spooled files
TRACE_AREA Parameter for /tmp

specifying the trace file
path if invalid file
handling occurs in
debug file generation
S390 Used for indicating TRUE / FALSE

whether it is ASCII or
EBCDIC installation.
'FALSE' implies ASCII
installation.
X9$ The code denoting the INRCITI

specific bank at which
Oracle FLEXCUBE is
being implemented; the
typical convention is
that the first three
characters represent
the currency and the
next 4 characters
represent the bank.
ORG_NODE Indicates the current Alpsi.world

host name
Display Control parameters
SHOW_ALL_FT If this parameter is set Y/ N

to Y, all the FTs are
shown in the FT
contract online form;
else if it is set to N then
only the FTs having
Booking date as today
are shown.
SHOW_ALL_FX Same as above, but for Y/ N

FX online screen
5-4
Examples
SHOW_ALL_LD Same as above, but for Y/ N

LD online screen
SHOW_ALL_MM Same as above, but for Y/ N

MM online screen
SHOW_ALL_BC Same as above, but for Y/ N

BC online screen
SHOW_ALL_LC Same as above, but for Y/ N

LC online screen
SHOW_ALL_SI Same as above, but for Y/ N

SI online screen
LOV_CUSTNAME If this parameter is set Y/N

to Y, the customer
names is also
displayed along with
the CIF id in the
customer option-list
LC_SINGLE_FFT If this flag is set to Y, Y/N

the advice tag OTHER-
FFTS will get
populated. Else, each
individual FFT defined
will be available for
message format
definition and the
consolidated tag will
not get populated
Accounting related parameters
ACCOUNT_STATEMENT Whether the account BOOK_DATED;

statement that is sent VALUE_DATED
to customers
periodically should be
booking dated or value
dated
IC_NADJ_PADJ_TAGS_REQD Whether Amount Tags Y/N

indicating Positive and
Negative Adjustment
(in case of IC
adjustment arising out
of Back Valued
transactions) is
required. If this flag is
set to Y and suitable
5-5
Examples
accounting is set-up,
Positive / Negatives IC
adjustment will be
passed with absolute
amounts with
appropriate sign (Dr /
Cr) rather than passing
negative values in
accounting.
VDBAL_UPDATE Whether Value-dated ONLINE; OFFLINE

balances should get
updated online
CCY_DATE_WISE_CHECK If this parameter is Y, Y/N

then the End of Day
process (while marking
EOTI) will check if the
accounting entries are
balanced currency-
wise and value-date
wise. If the check fails,
a configurable override
will be shown.
IC_ACCR_ON_HOLIDAYS If this parameter is set, Y/N

IC (daily accruals) will
pass one entry each
for each day even
when EOD is run
before a set of holidays
(such as on Friday).
Else IC passes one
entry for the entire
holiday period.
GL / MIS related parameters
GL_REBUILD To enable automatic Y/N

EOD rebuild of GL
balances
GL_PERIOD_CHECK To indicate whether GL ALL; CURRENT

(real and contingent)
balance check should
be done for all periods
or current period
MIS_REBUILD To enable automatic Y/N

EOD MIS rebuild
5-6
Examples
REFINANCE_DAILY This flag must be set to Y/N

Y if MIS daily refinance
functionality is
required. From Version
Oracle FLEXCUBE 4.4
onwards, this flag is
available in Bank
Parameters.
Kondor Plus Interface related
KONDOR+ Whether Kondor Plus Y/N

interface is available at
this installation
KPLUS_BRCODE Branch code of the Valid Branch Code

branch where Kondor
Plus interface is
installed
KPLUS_USERID Oracle FLEXCUBE Valid User ID

User ID of the User
doing Kondor Plus
Upload
KPLUS_FILE_PATH Main Directory Path Valid directory path

where all the Kondor
Plus related files/
directories are located
KPLUS_IN_DIR Directory on Oracle Sub-directory of the

FLEXCUBE server to KPLUS_FILE_PATH
which files from Kondor
will be copied
KPLUS_WIP_DIR File from Kondor will Sub-directory of the

be moved to this KPLUS_FILE_PATH
directory from where
interface will read the
file and populate
upload tables
KPLUS_SUCCESS_DIR File from Kondor will Sub-directory of the

directory if the upload
writing was successful
KPLUS_ERROR_DIR File from Kondor will Sub-directory of the

directory if the upload
writing was
5-7
Examples
unsuccessful
KPLUS_DIR_FILE Name of the file which *.TXT

will be written by
Oracle FLEXCUBE into
each the above
mentioned paths
BROKER_BOOKING_METHOD This specifies whether 1/2

the default brokerage
booking method is in
Advance / Arrears
where K + interface is
installed
BROKER_PAYABLE_CCY This specifies the Valid Currency

default brokerage
payable Currency
where K + interface is
installed
BROKER_LIQ_TXN_CODE This is the transaction Valid transaction code

code that the system
should use to liquidate
the brokerage booked
through K + interface
CUSTOMER_LIMIT_CCY Specifies the Limit Valid Currency

Currency in CIF upload
through Kondor Plus
Other Interface related parameters
ELIXIR_IN_DIR This is the directory in Valid Directory path

which the ELIXIR
(clearing interface) file
will have to put in for
Oracle FLEXCUBE to
read
MUREX_UPLD_DIR
MUREX_TXN_CODE Used to get default txn Valid Oracle

code for DE upload in FLEXCUBE txn code
MUREX interface
KIR_TXN_CODE Used for indicating

transaction code for
DE Uploads in
pc832.fnc (applicable
only when KIR
5-8
Examples
interface is installed).
KIR_UPLOAD_DIR This is the directory in Valid Directory path

which the KIR data file
will have to put in for
Oracle FLEXCUBE to
read (when KIR
interface is installed)
EMSNT Whether EMS NT (for Y/ N

messages) is installed
ATM_INSTALLED Indicates whether ATM Y/N

interface is existing
ATM_DELAY ATM EOD processes

will start after the time
delay specified in this
parameter
MAINT_NETT_REQD This pertains to RBAN Y/N

changes. The
parameter is used for
indicating if unnetted
entries are to be
inserted into
actb_transaction_listin
g (used in acpks.sql)
before accounting
netting takes place.
RBAN_PATH Used in achandof.fnc Valid Directory Path

for specifying the path
for generation of
Transaction Handoff
files.
SSN checking related parameters
SSN_FT_CHK_REQD This parameter must Y/N

be set to Yes for SSN
based (anti money
laundering) checking to
be active. This will
validate the total
amount
(SSN_AMOUNT) of FT
transactions (outgoing
FTs) that can be input
for a given Customer
(identified by his Social
Security Number)
5-9
Examples
within a running period
of days (specified as
SSN_DAYS) in a
specified CCY
(SSN_CCY)
SSN_AMOUNT Refer above Valid Amount
SSN_DAYS Refer above Valid Number (of days)
SSN_CCY Refer above Valid Currency
Regulation CC related parameters
REGCC_AMT1 This is the amount of Valid Amount

Day 1 availability for
Regulation CC
REGCC_AMT2 Additional availability Valid Amount

under Regulation CC
REGCC_CCY Currency of the above Valid Currency

amounts
Signon related parameters
COPYRIGHT_VERSION The year of the Eg: 2001, 2002

Copyright clause to be
displayed on the
Signon Screen
RELEASE The version of Oracle Eg: 4.5; 5.0

FLEXCUBE to be
displayed on the
SIGNON screen
Other parameters
CUST_ACC_UDF This parameter is UD#CUST

applicable if the
customer account
mask in the bank
should contain a User
defined field.
This field should have

the name of the UDF
that is part of the
customer account
mask
5-10
Examples
AUTO_PRINT This parameter should Y/N

indicate whether the
advices generated
during the batch
processing should be
printed automatically or
not
DERIVED_TAG Used to indicate Y/N

whether derived tags
functionality is used or
not
MAINT_HIST_REQD Used for indicating if Y/N

maintenance log
history is required
LC_LIAB_AMT_ACTUAL This Parameter is used Y/N

to indicate if Liability
tolerance(maintained
at product level) is to
be considered for LC
amount validation or
not. Used in BC
Contract Online for
defaulting LC Liability
amount to LC amount
in Bills. If set to 'Y',
tolerance is not
considered for
defaulting .
SGEN_PARAM This flag should be set Y/N

to Y if SGEN feature is
required for FTs
TRANSACTION_LIMIT If this parameter is set, Y/N

then the transaction
level amount limits
checking feature will be
turned on
5.4.2 Bank/ Branch Parameters
Specify the following details.
5-11
5.4.2.1 Bank Parameters
Initial skeletal information relating to Bank and branch, such as Bank Code, Name etc. will have
to be uploaded. Next, the Customer account Mask and GL mask as decided during the database
design discussions should be entered. Preferences such as inter-branch accounting scheme,
rate copy option, and GL on-line update option can be entered.
Following fields are to be entered at a later stage after setting- up currencies, Chart of a/c,
Transaction codes etc.
 Year-end PL account
 Year-end PL transaction code
 Default currencies
5.4.2.2 Branch Parameter
As in the case of Bank Parameters, skeletal Branch Information such as branch name address
etc. will also have to be uploaded.
Following other inputs such as have to be captured after Chart of Accounts, Customer
Maintenance is completed:
 Suspense GLs
 Financial Cycle
 Netting suspense a/c
 Walk-in customer
5.4.2.3 Users for Database inputs
Login as MAIN with password as PASSWORD and create roles, users and assign functions.
Country Maintenance
 Country code
 Country Name
Currency Definition
 Currency code
 Description
The following tables relating to currencies can be maintained later:
 Currency Rate Type
 Currency Pairs
 Currency Rate
5-12
 Denomination
5.4.3 Accounting Period Maintenance (Bank/ Branch Parameter)
Some of the key inputs are:
 Financial Cycle code, description
 Period codes, start date, end date
5.4.4 Holiday Maintenance
Local Holidays
To start with, local holidays, particularly for the current year may be maintained. Holiday table for
other years may be maintained later, prior to product maintenance.
Other holiday tables, Currency holidays and Clearing holidays can be maintained later.
5.4.5 System Date Maintenance (Bank/Branch Parameter)
The empty database will be on a specific date, which has to be updated to a current date, the
next working date has to be suitably updated.
5-13
5.4.6 Customer Maintenance
Customer Category
Customer categories as decided during the database design phase have to be input.
Customers
Customer information can be uploaded at this stage using the agreed upload strategy. Prior to
uploading customers, appropriate translations of existing codes with new CIF numbers,
categorizing customer s etc. should be in place. If MIS categorization of customers is also
uploaded simultaneously, then MIS categories have to be maintained first. Otherwise, a
methodology for updating the customer information with MIS categories later on will have to be
worked out. It may be noted that CIF is at the bank level, common across the branches.
General Ledger
Creation of Chart of Accounts in the database is one of the most critical activities in database
input, therefore has to be handled with extra care. It is advisable to automatically upload the chart
of account from a spreadsheet to avoid input errors. It is better to keep separate spreadsheets for
node GLs and leaf GLs, so that they can be uploaded separately.
Reporting Lines
GL Reporting Lines for both head office and central bank reporting have to be first input before
creating the Chart of Account in the database. Here again the possibility of data upload from a
spreadsheet can be explored.
Chart of Account
The node GLs have to be input before input of leaf GLs. Period/Year end P&L GLs, to which the
account balance will be transferred, have to be input and authorized before creating the INCOME
& EXPENSE GLs.
5.4.7 Other Bank/Branch Parameters
The bank/branch level parameter tables have to be revisited to update suspense GLs, year-end
P&L GLs, Walk-in customer CIF etc.
Transaction codes
Transaction codes for various accounting transactions to be passed in the system. Funds
availability for the transactions to be input.
Override parameters
All the errors will be a part of the database. However, most err Categorizing errors under
overrides, errors, ignore, on-line authorization options.
5-14
Messaging
Allowed operations for message handling
Inter-branch maintenance
Identifying due to, due from GLs for inter branch postings. Inter branch accounting route to be
decided. Accordingly the maintenance to be done.
Product groups
Broad grouping of products offered by bank
Status code
Product status codes to be maintained.
Bank Codes
Bank codes, Bank name - Clearing House members have to be created here.
Till/Vault
Till or Vault id codes for cash / teller transactions.
Journal Entry, MM/LD, BC Parameters
Product related parameters at Bank level
5.4.8 Revaluation
Reval Set-up
Revaluation profit/ loss accounts, rate types applicable for revaluation etc. in respect of accounts
to be revalued
5.4.9 Limits
Limits template
Defining credit lines and sublines
Security & Issuer
Details of security, Issuer of security
Type
Defining collateral types
Other maintenance such as limits (customer level); Collateral, margins etc. can be set up later
after product set-up is completed.
5-15
5.4.10 Customer Accounts
5.4.10.1 Customer Maintenance
Account Class
Broad account categories with user-defined identifier are maintained here. Nature of accounts
falling under the class (Current, Savings, Nostro etc.), GL account linkage, Reporting lines,
Statement and other generic preferences, Branch, Currency and customer restrictions are
specified.
Customer Accounts Maintenance
Opening of customer accounts (current, savings, nostro etc.). Here again, possibility of auto
upload/creation of accounts using a spreadsheet could be explored. While creating the upload
spread sheet, or creating the accounts manually, utmost care is to be taken in allocating account
class, account number and other account level specific preferences. A master list containing the
map or translations of old account number with new numbers should be kept aside duly
approved, for future reference.
Interest & Charges
Interest and charges applicable to various customer accounts and account classes - Calculation
method, formula and other parameters will be based on the database design worked out earlier
as per the requirement of the bank.
End of Cycles
The processes to be run as per design are to be set up for each of the branches.
5.4.11 Front-end Module Product Set-up
This is one of the major milestone activities in database input.
On a broad level, product set-up follows the following steps:
 ICCF Maintenance - ICCF rules, Floating rate set-up, if any
 Tax maintenance - Tax rules and Tax scheme maintenance, where ever applicable
 Brokerage Maintenance - As applicable
 Product Specific standard tables, codes, free format text maintenance
 Messages
For more specific product level set- up, you can refer to the respective User Manuals.
It would be more convenient to first identify and create generic rules for ICCF, Tax etc. which
could be applied across the products or modules.
5-16
6. Database Callback
6.1 Introduction
This activity is primarily aimed at checking up the static table maintenance input against the
original source documents and spreadsheets used for the input. This will be the first level check
leading to detailed check in the next stage of System Trial run. A broad list of reports that can be
used for database call back is included in this section. More specific strategies should be evolved
based on the criticality of the data and the database design. Database call back exercise should
be preferably undertaken by set of staff not involved in the input, internal control department
should also be involved. The called back reports should be authenticated by the concerned
authority from the bank and should be kept aside for future implementation or system audit.
6.1.1 Suggested List of Reports for Callback
The Maintenance changes log report can be used to identify all the maintenance carried out and
can be used for the call back. It is suggested that this report be used to fully check all the
database setup done at the bank. In addition, reports/dumps of the data in various tables can be
printed to check with the source sheets.
Static Maintenance
 Bank Parameters
 Branch Parameters
 Customer CIF report
General Ledger
 Chart of Account
 GL-MIS Linkage Report
 MIS Class Maintenance
 Budget Maintenance
Currency
 Currency Definition
 Currency Pair
 Currency Rate Type
 Ccy Denomination
Reports
Maintenance Changes Log Report
Customer Maintenance
Customer accounts
6-1
Interest & charges
 Interest Calculation Details
 Product Print
 Rule Print
Brokerage
 Brokerage Rules
 Broker Profile
Tax
 Tax Rules
 Tax Schemes
Bills
 Bills Branch Parameter
 Commodity Codes
 Discrepancy codes
 Document Codes
 Free Format Codes
 Instruction Codes
 Product Codes
LC
Product Report
End of Cycle
Process Definition Print
In addition to these reports, adhoc reports should be generated for checking any other
maintenance.
6-2
7. System Trial Run
7.1 Introduction
This forms a part of User Acceptance Tests. The trial run should be carried out by the users, to
establish the functionality of the product vis-à-vis their expectations. Further, the various cross
links and parameters set up during database design and inputs are tested. This is a crucial phase
since the sign-off from the customer depends on the successful completion of the trial run.
Another objective of the trial run is to help the end-users get familiar with the system.
7.2 The Logistics

It is essential that the test plan of the trial run is prepared and executed by the users. The
implementation team from Oracle Financial Services should only assist the users in this exercise.
This assistance should be restricted to providing guidance in formulating the test plan, the
procedure to be followed during the trial run and the documentation that is necessary. All aspects
of the trial run should be documented. This document is the basis for the sign-off from the users
and their auditors. It should contain the following information:
 The test plan for the trial run
 The data used
 The results
 Any deviations in the functionality
 Any corrective actions or workarounds suggested
The number of days over which the trial run should be spread should be decided based on the
number of modules that have to be implemented. The results should be documented daily, along
with any problems and solutions provided.
7.2.1 The database for trial run
The trial run should be conducted on a separate scheme containing the static database as
maintained after the database design and input. In some cases system trial run may be carried
out in the pre-shipped maintained database. However, it is advisable to carry out the test in the
actual database set-up for the bank.
7.2.2 The approach
The test plan for the trial run should be a representative of the real life situation in the bank. All
conditions, those that occur during the course of a normal day and those that are critical but may
happen rarely should also be covered in the test plan. As far as possible multiple features should
be tested using a single transaction so as to keep the number of actual transactions to a
minimum. It is easier to control and review the results when the number of transactions is less.
The trial run plan should ideally contain the detailed test plan, schedule for the trial run and
responsibilities. The following people should be involved in the system trial run:
7-1
 Personnel responsible for the input and authorization of data.
 Staff from the IT department involved in End of Day runs and monitoring hardware
performance.
 Staff from the Credit Department to check the functioning of the Central Liability sub-
system.
 Staff from the Fincon department to verify the General Ledger structure.
 Staff from the security department to check on the system security and controls.
7.2.3 Components of the trial run
The trial run should establish the following:
 The functionality of the product.
 Compatibility with the hardware.
 The functionality of the Operating System (system utilities, recovery of data files,
response time, especially for large volumes, back-up and restoration of data).
7.2.4 Components of the Test Plan
All types of transaction in a specific module should be included. Care should be taken to include
transactions that may occur rarely also, along with samples of transactions that are entered more
often. Volume testing should be a part of the test plan.
The test plan should contain the list of output messages that have to be generated for the
transactions.
The system dates for the trial run should cover End of Day, End of Month, End of Month of
February (29th) for a leap year, End of Year and Beginning of Day processing.
7.2.5 Handling Errors
An Error Control Log (Test Incidence log) should be opened in which all the errors encountered
during the trial run have to be registered. Each error should be allotted a number. The following
details should be recorded for an error:
 The exact condition under which the error occurred
 The nature of the error
 The expected result
 An evidence of the error (in the form of a screen dump, batch entries or something similar
that establishes the occurrence of the error)
The errors should be monitored on a daily basis and solutions provided within the time frame
agreed upon. This time frame should depend on the nature of the problem and its impact on
conversion.
7-2
7.2.6 The Schedule
The System Trial Run has three distinct but concurrent phases. Each phase should emphasize
on testing a certain set of system features. The recommended schedule is described in the
following sub-sections. This schedule can be modified to suit the requirements of a site.
7.2.7 Phase One
Phase One should focus on the features of the hardware, the operating system and the various
controls. Besides these the functionality of Core subsystems should be tested Core should
include the following sub-systems:
 Security Management System
 Bank/ Branch Maintenance
 Limit Tracking/ Central Liability
 Accounting Services
 Journal, Teller entries
 End of Cycle (EOC)
 Management Information System
The features to be tested for the Operating System are as follows:
 Activating and de-activating workstations
 Efficiency of task initiation and operation
 Running system utilities
 Error detection, isolation and correction capabilities
 Ability to continue operations after a software failure
 Data restoration and recovery procedure
 System start-up and closing down
 Backup on tape and other media
For system controls, the features to be tested are:
 Control of access to the different data areas through the operating system
 Control of access through Security maintenance (restricted access)
 Verification of audit trails
The tests for hardware should be to ensure the following:
7-3
 Compatibility of client work-stations
 Functioning of printers
 Functioning of image scanners, if any
All the relevant reports must be checked and findings of End of Day run should be recorded.
7.2.8 Phase Two
Phase Two should include tests to establish the functionality of the all the front-end modules
7.2.9 Phase Three
During Phase Three, transactions in all the sub-systems modules that may occur on a day have
to be input. The End of Day operations should be carried on and reports checked. This exercise
will establish the proper functioning of the system under real-life conditions.
It should be noted that the three phases are only for the purpose of proper focusing. These are
not sequential phases. Depending on the number of resource personnel available, Roles can be
assigned to each person to focus on the critical features of each of the phases.
The list of features that has been prepared for the standard Product Test Plan, is available as
a part of the release. It can be used as a reference while preparing the test plan for the trial run.
7-4
8. Financial Conversion
8.1 Introduction
This phase involves populating the database with financial information, transactions and all the
live contracts from the existing system to the new system.
This phase of the implementation of Oracle FLEXCUBE poses many challenges. If these
challenges are not planned for, it may result in serious difficulties during and after the conversion.
This may then involve a re-conversion, resulting in project delay, loss of time, effort and additional
expenditure.
This chapter focuses on the preparation and activities necessary to convert a branch to Oracle
FLEXCUBE. Every implementation is likely to have specific requirements. Broad guidelines for
the activity are mentioned here.
8.2 The players

The key players in this phase of the implementation are:
 Implementation team from the bank
 Senior Operations Manager
 Independent Control Unit Head
 Financial Controller
8.3 Scope
This chapter discusses the various aspects of the financial conversion for products of a branch
that are covered by the following Oracle FLEXCUBE modules:
 Core
 Money Market
 Foreign Exchange
 Funds Transfer
 Letters of Credit
 Bills and Collections
 Loans and Deposits
 Securities
8-1
8.4 Planning
Financial conversion is often done under enormous time pressure. Input of financial data into the
system calls for meticulous attention to the smallest detail and requires advance planning. The
plan for conversion should cover the activities listed below.
8.4.1 How to do
 The steps involved in conversion may vary depending on the Oracle FLEXCUBE module
through which the products will be handled.
 For certain products, it may be essential to work out in advance, the impact of carrying
over the balances and contracts to the Oracle FLEXCUBE system and plan for any
special action to be taken.
 The financial entries must be made in small batches. This simplifies the investigation and
verification process.
8.4.2 When to do
 Static data set-up is complete and sign-off obtained.
 Best done over year-end, quarter-end or month-end, when application of interest for a
majority of the accounts will be done. However, this is not an essential pre-requisite, if
the existing system is capable of generating mid-term accruals.
 The activity could be done over a week-end so that branch operations are not affected
and staff is available for conversion work.
8.4.3 Methodology
Conversion of financial data can be by automated means or manual. The decision regarding this
should be taken well in advance since the activities will have to be planned accordingly. In case
of automatic conversion the following will have to be decided in advance: -
 Scope of auto-conversion
 Hand-off file layouts
 Table set-up for code mapping or translation
 Tools required for conversion
 Responsibility for hand-off Spread sheet, text files etc
 Resources required for upload program development, if any
 Checking and validating procedures (either matching data automatically through

programs or producing reports in formats that facilitate cross-checking by the branch
staff)
 In case of manual conversion, regular Oracle FLEXCUBE input screens will be used
8-2
8.4.4 Conversion Sequence
The sequence of implementation of Oracle FLEXCUBE should be decided in consultation with

the bank officials. In case of a multi branch scenario, the sequence of implementation at the
various branches is to be decided, alternately, all branches may be converted at the same time, if
this is estimated to be manageable. The set-up, whether centralized, distributed or decentralized,
will also play a major role in deciding the sequence of conversion.
Secondly, the sequence of implementation of various Oracle FLEXCUBE modules in a branch,

should be decided in consultation with the bank officials depending on their priority. In many
situations, some of the modules will be taken up for implementation only after the bank goes live
on critical products.
In case any of the products are to be converted in a later phase, the balances relating to those
products should be kept in a separate General Account (with direct entry option) to be opened for
the purpose, preferably product/ module wise. When the conversion of the products is taken up,
these accounts will be the take-down account, and the balance in the accounts will become zero.
After the financial data have been entered, FX revaluation should be done on both the systems -
existing and Oracle FLEXCUBE.
8.4.5 Pre-conversion Checklist
Before getting to the stage where financial entries are passed into the Oracle FLEXCUBE, the
implementation team should check whether the following have been adequately taken care of:
 Static database set-up for all the products and modules should be completed and sign-off
obtained.
 Estimate resources requirement. The following resources should be planned for :

 Staff required for data input and correction
 Staff required for data checking
 Hardware resources
 Consumables like stationery, printer ribbons, magnetic tapes/cartridge tapes, floppy
diskettes
 Set up a team responsible for conversion related activities
 Decide the responsibilities of the team members
 Ensure that the team members are trained in the relevant areas of their operation
 Ensure proper back up arrangement for team members to meet last-minute

contingencies
 Ensure the appointment of one officer of the branch as the Conversion Controller, who
will verify and approve all the entries passed before authorization
 Ensure that the team members are given access to the relevant Oracle FLEXCUBE
function/ screens for the duration of the conversion. Before going parallel the user
profiles must be reviewed and necessary changes must be effected.
8-3
 Lay down checking and correction procedures. This could be a combination of reports
and on-line checking.
 Establish the different types of data to be input product-wise and currency-wise.
 Ensure that conversion accounts for all relevant currencies and products have been
opened. Allot a transaction code for conversion activity if required.
 Prepare a detailed action plan for the duration of the conversion activity; monitor the
activities as per plan.
 Prepare a procedure to verify the correctness of conversion and for sign-off of the
database. The procedure should define the acceptable limit of conversion errors before
going parallel.
8.4.6 Standard Instructions for Conversion
Some of the precautions that have to be taken during the conversion activities are as follows:
 Exchange rates will not be input, the standard rates will be taken as default and the local
currency equivalent calculated automatically.
 Initially, the conversion accounts will be set up as the standard settlement accounts.
Hence all entries will be offset against the conversion account and no other account will
be used. Standard settlement account for all customers will also be conversion account
(which will be the takedown account). After conversion, the standard settlement accounts
should be modified with the actual accounts, in the settlement instructions.
 Decide the value date to be used for all non-contract input. Only this date should be
used.
 No authorization should be allowed until the Oracle FLEXCUBE conversion controller

has seen the inputs, verified the balances and signed off on the financial conversion
schedule.
 Each department must provide items for conversion as of a particular date for their
products; and must prepare a report of the data as of the agreed date for verification.
Contracts maturing before the date of conversion need not be converted to Oracle
FLEXCUBE.
 In case more than one department is using a product, allocate user reference number
range to each department. Within a department also, if more than one person is going to
do the contracts entry, allocate a sub-range to each of them.
 Provide adequate time for frequent backing-up of the database.
8.5 Conversion Procedure

The conversion of financial data to Oracle FLEXCUBE is performed by passing offsetting entries
to the conversion accounts or customer settlement accounts defaulted as conversion account,
setup specifically for this purpose.
The conversion in the simplest form implies that the various account balances (forming a part of
the Trial Balance) be transferred to the Oracle FLEXCUBE accounts through Journal Entry as
debit or credit entries as the case may be. At the end of this exercise, the balances would have
been transferred and the total debits and credits would match, provided they matched in the
existing system.
8-4
However, such a simplistic situation is not likely to occur in an installation. The primary reasons
for this are:
 Entries cannot be passed to GL s having only indirect entry option.
 While taking on the outstanding contracts the front- end module will pass accounting
entries affecting the takedown accounts even though the current balance in that account
has been arrived at after this event.
 The system will pass entries to accrual and interest paid/received accounts during entry
of outstanding contracts, which may have already been passed resulting in double
counting.
 Similarly, the accrual and interest application on current and savings accounts may result
in differences between the new and existing systems.
In order to circumvent these problems, all offsetting entries to existing balances are posted to a
Conversion Account. All contracts are entered with Customer settlement accounts (take-down
accounts) as the conversion account so that they do not affect the customer account balances.
Similarly, the interest/provision accounts balances are entered by accruing in the Oracle
FLEXCUBE system after entry of balances in all the accounts and passing adjustment entries to
these accounts and the corresponding offset entries to the conversion account.
By following this principle, at the end of the conversion exercise, the conversion account(s) would
have a zero balance. In case this is not so (i.e., the balance is not zero), it will serve as an
indication that some of the account balances have not been transferred correctly. By examining
the entries posted and checking the balances of all other accounts the error can then be traced
and rectified. This rectification process should continue till the balance in the conversion accounts
becomes zero or is brought down to an acceptable limit so that the branch can go parallel.
A generic description of the conversion process has been given here and the actual conversion
process could have other items / aspects which would need to be considered on a case-by-case
basis.
8.6 Sample Conversion Accounting Entries

This section aims to explain the conversion procedure outlined in the previous section by giving
an example of the accounting entries passed in a conversion exercise.
For the purpose of this exercise, we will consider the following accounts and contracts that are
outstanding at the time of conversion. All accounts have been assumed to be in local currency.
For simplicity sake, only a few accounts have been considered.
Cash 100,000
DR
Current account of Mr. 1,000 CR
Savings account of Mr. 500 CR
Accrual account 3,000 CR

(deposits)
8-5
Cash 100,000
DR
Accrual account (loans) 2,000 DR
Interest Paid 3,500 DR
Interest Received 2,500 CR
Outstanding Contracts Details:
Deposit contract 150,000

account CR
Loan contract account 51,500.DR
The entries generated during the conversion activity are shown below. Note that the figures in
parentheses refer to the running balance of the conversion account and after all the entries are
completed, the balance becomes zero.
Deposit contract entry will generate the following entries: -
DR Conversion account* 150,00 150,000

0 DR
CR Deposit account 150,00

0
DR Interest Paid 3,000
CR Accrual account 3,000

(dep.)
Loan contract entry will generate the following entries: -
DR Loan account 51,50

0
CR Conversion account* 51,50 (98,500

0 DR)
DR Accrual account 2,000

(loan)
CR Interest received 2,000
Through Data Entry transfer the following balances will result in the entries shown below: -
DR Conversion 500 (99,000 DR)

account
8-6
DR Conversion 500 (99,000 DR)
account
CR Savings account 500
DR Conversion 1,000 (100,000

account DR)
CR Current account 1,000
DR Cash account 100,00 (Nil Balance)

0
CR Conversion 100,00
account 0
The entries also result in correct balances in all the accounts other than the accrual and interest
paid/received accounts. These balances will be finally adjusted as follows: -
Since the balances in the two accrual accounts generated by the contracts match the accrual
account balances in the existing system, no adjustments will be required.
However, the balances in the interest accounts do not match. This could be due to the reasons
outlined in section 9.4.1, and the following entries will be made through Data Entry to adjust the
balances.
Reverse the balance generated by the contracts entry:
DR Interest received 2,000

account
CR Conversion account 2,000 (2,000

CR)
DR Conversion account 3,000 (1,000

DR)
CR Interest Paid account 3,000
The above entries will make the balances in the respective accrual accounts zero. After this,
input the existing system balances into Oracle FLEXCUBE accounts as follows:
DR. Conversion account 2,500 (3,500

DR)
CR. Interest Received 2,500
DR. Interest Paid 3,500

account
CR. Conversion account 3,500 (Nil)
8-7
After this set of entries, the conversion account is restored to zero balance and the interest
accounts have the correct balances as per the existing system. At this stage, the transfer
financial data to Oracle FLEXCUBE is complete and correct and the system is ready for parallel
run.
Conversion Account will be maintained as the takedown account, during the product set-up.
8-8
9. Parallel Run
9.1 Introduction
Parallel Run is the stage where the existing systems of the bank run concurrently with the new
Oracle FLEXCUBE system. The basic objective of this activity is to ensure stability of the new
system, enable the users to become comfortable with the new processes and to develop
confidence leading to complete switch over. However, the parallel stage places tremendous
pressures on resources, time constraints and co-operation by bank personnel. Therefore, careful
considerations must be made to all activities, to ensure that all tasks and resources are evenly
distributed. It should be ensured that the users understand their responsibilities, and differences
in the operation procedures, on the two systems. Remember the users have to use two systems
simultaneously, and this alone is enough to cause confusion if not properly planned. In fact, even
the movement of paper - tickets, contracts, etc. must be planned.
As in the case of conversion, the day to day verification of account balances, contracts, static
maintenance and transactions must be diligently performed. This must be done by a team
independent of the persons doing the input. The verification of financial equality of the two
systems is the main point behind the parallel run, and any laxity in this area, might lead to
indefinite extensions of the parallel run. For the same reason, if there are any differences, they
must be resolved immediately.
Ideally at least one End of Month should be included in the parallel run. Details on how and when
to conduct call backs, accruals/liquidation, error reporting and correction, as well as training on
dummy conversions are described in this chapter.
The Senior Operations Manager from the bank and the Project Manager from Oracle Financial
Services will co-ordinate and plan the parallel run procedure in line with job functions and bank
staff usage of the system.
The rule should be postings to Oracle FLEXCUBE should precede other systems.
Each department will call back its entries prior to leaving at the end of the day. This callback
should catch the majority of posting errors.
Accounting Journal should be compared with the equivalent reports from the existing system by
each department and a report should be submitted to the Reconcilement Controller at the end of
each day. Data Center should commence End of Day operation only when all departmental
reconcilement are correct.
9.2 Callbacks
The information on the current records on the existing system must be compared to that on
Oracle FLEXCUBE through detailed callbacks. Callbacks should be done by a central callback
team and various user departments. Wherever possible, use of spreadsheets or automated tools
should be made to ease the manual workload.
9-1
Reports are classified as Core and Module specific. Core reports are those which contain key
financial information across bank/branch. Module specific reports are key reports relating to the
front-end modules. In addition to the reports, advices and messages generated should also be
checked and compared.
Some of the critical reports to be checked are:
Core Reports
 Accounting Journal
 Trial Balance
 General Ledger
 Maintenance log report
 Revaluation Report
 Limits utilization/ exposure reports
Module Specific Reports

 Activity Journal
 Exception Report
 Accrual Control Reports
 Customer A/c Statements
Error Recording and Correction
The timely correction of errors is essential for a controlled parallel. Errors should be recorded in a
Parallel Log. The log should contain the following for each day of the parallel run:
 Reconcilement sign-off for each report
 Departmental Reconcilement
 Error Reports and corrective action
It should be the responsibility of the Parallel Controller to maintain this record. The Senior Branch
Operations Manager should review the Parallel Log on a daily basis and initial it.
9.2.1 Training
A series of training sessions should be conducted to explain method for performing call-backs,
completing documentation and error correction before the financial conversion.
9.2.2 Dummy Conversion/Parallel
A Dummy Conversion and Parallel should be conducted for one week prior to the live conversion
to confirm that all participants understand the process.
9-2
9.2.3 Summary
The conversion and parallel involves a significant additional workload on the bank. The bank
should plan to minimize the additional workload on the operations during this period.
9-3
10. Contingency Plan
10.1 Introduction
The managers should determine the operational risks and develop a procedure to ensure that the
business is not disrupted in an emergency situation.
10.2 Overview
The people responsible for developing a contingency plan for the bank are:
 The Contingency Planning Officer-for the overall branch plan
 The Data center manager-for technology contingency, including communications,

hardware, system software and third party software
 The Senior Operations Manager of the bank, who is responsible for Oracle FLEXCUBE
 The members of the Internal Control department
The Contingency plan should address the following issues:
 Operation Risk assessment
 Contingency planning
 Software errors outside of normal working hours
 Contingency plan distribution list
 Persons who can authorize the emergency procedure
 Contact points in the event of hardware and software problems
 Potential exposure and containment measures
 Emergency back-up plan
10.3 Operation Risk Assessment

Oracle FLEXCUBE runs on Client Server Architecture, with ORACLE FORMS on the client side
and ORACLE 7.3 (with or without distribution option) on the Server (UNIX). The Database can
either be centralized in a single server or distributed in more than one server connected through
telecommunication network.
There are some risks involved in the implementation of a new system and the maintenance of an
existing one. Some risks are controllable while others are not. But the degree of non-controllable
risks, such as natural disasters, can be minimized. This chapter deals with risks and their
corresponding protective measures. The risk analysis is geared toward the security of hardware
and software. Tight security and back-up systems are the most important elements. Adequate
training for the personnel who will be dealing with the computer is also very important. The basic
contents of the risk assessment are as follows:
10-1
 Brief Description of Location and Operations.
 Major Causes of the Operational Risks.
10.3.1 Brief Description of Location and Operations
A brief description of the location and the operations of the bank should be indicated in the
assessment.
10.3.2 Major Causes of the Operational Risks
The following type of critical factors, which present operational risks, are to be considered:
 Political or Civil Unrest

 Political or Civil disturbances
 Strikes and Riots
 Insurrection etc
 People Related Risks (Internal)
 Illness or Injury
 Non-adherence to established procedures
 Shortage of training in established procedures
 Unpleasant working conditions
 Deliberate or Negligent acts
The risk involved can be loss of customers, fraud, processing errors, delays which include
information modification, loss of information, data omission, damages to hardware, etc.
 People Related Risks (External)

 Intrusion
 Kidnapping or extortion
 Theft of equipment, etc
 Utility Related Risk
 Electricity
 Communication
 Voltage stabilizer
 Air Conditioning etc
Power loss causes processing errors and delays, and a total memory loss in computers. Irregular
or faulty power lines can alter the data being processed and/or cause permanent damage to the
computer.
10-2
 Neighborhood Hazards
 Proximity to chemical or explosive operations
 Nearby building or floor that constitutes a fire hazard to the operation.
 Potential risk of leakage or burst in the water pipes on the premises.
 High crime areas.
10.4 Contingency Planning

The Data Center is a supporting unit that provides the Data Processing services for the
contingency planning process. These services are in the area of the Data Center
This is considered to be a medium risk area and its disruption implies that the bank, Customer
Service, Trade and Treasury are rendered inoperable with a resultant loss of the bank s
reputation and customers. Potential threats to the Data Center (and consequently to the other
units of Operations) include:
 People related risk, e.g. illness, strike, sabotage
 Natural disasters, e.g. fire, power failure, etc. rendering the premises and facilities
unavailable
 Equipment failure, e.g. failure of Main or Back-up Hardware, peripherals, workstations,

printers, etc.
 Software Failure, e.g. abnormal termination of a program due to a database corruption or

program bug
 Support Line failure, e.g. failure of the link between the Oracle Financial Services
Support team and the bank
The above risk factors should be analyzed and preventive measures should be described in
detail. Some of the recommended preventive measures are:
 Employees should be cross-trained at different jobs so that they can act as a back-up for
each other in case of absence due to illness, etc.
 Regular medical check-ups should be arranged for the employees
 Fire detection and suppression equipment, e.g. smoke detectors, fire extinguishers,
Halon, etc. should be placed at all vulnerable locations
 Main and Back-up Hardware systems, printers and workstations should be serviced and
maintained regularly
 Service contract - The bank should evaluate the need for a maintenance contract and
document for hardware and software
 A private, leased data-line should exist between Oracle Financial Services (formerly i-
flex) and the bank. A dial-up facility should also exist as a back-up to access Oracle
Financial Services (formerly i-flex)
10-3
The contingency plan should be drawn to cover those functions critical to the business of the
bank. The contingency plan should contain personnel lists (organization chart, distribution list,
authorizers of emergency measures, succession list and alternate account managers), action
plans, contact names and addresses and contingency planning documentation.
10.5 Software Errors Outside Normal working Hours

In case of a problem arising outside normal working hours, e.g. during the End of Day, month-
end, year- end runs, etc., the following is the recommended emergency procedure:
 The Systems Manager or the back-up person should be summoned if not already
available on the premises. No action should be taken until the Systems Manager or the
back-up person arrives.
 The Senior Operations Manager of the bank should be informed about the matter.
 If the problem has occurred earlier and if the method of resolution is known, it should be
applied (all occurrences of problems and their resolution should be entered in the Data
Center software logbook). The Systems Manager should ensure that the program overlay
and the statement number are exactly the same as in the logbook.
 The Senior Operations Manager of the Bank and the Internal Control Head may be asked
to come to the bank to allow the Systems Manager to enter in the SUPERVISOR mode
and correct the problem.
 If the Senior Operations Manager of the bank and the Internal Control Head are not
available, the Systems Manager should contact the respective back-ups to gain access
to the supervisor mode. Secret passwords to the supervisor mode are lodged in the main
vault and may be withdrawn and opened if the regular and alternate custodians are
unavailable.
 If the error happens for the first time and the bank has a technical person for Oracle
FLEXCUBE maintenance, the Systems Manager should consult the person, identify the
bug and fix it as per procedure. If this is not possible, Oracle Financial Services should
be contacted for instructions. When the bug is fixed, recovery programs 100 and 101
should be run.
 If the error happens for the first time and the bank has a maintenance and support
agreement with Oracle Financial Services the Systems Manager should report/handle
the problem as per the support procedure in the support Manual. The bank should take
action as per the instructions of Oracle Financial Services .
 In all cases, details of the events (error description, communications with Oracle
Financial Services , etc. should be carefully noted in the Logbook of the Data Center and
reviewed by the Internal Control Unit.
10.5.1 Contingency Plan Distribution List
The recommended contingency plan distribution list is as follows.
 The Senior Management of the branch
 The Manager of the Data Center and the Systems Manager of the bank
 The Audit Division of the bank
 The Senior Operations Manager of the bank
10-4
 The System Administrative Manager
 The Control Head of the bank
 The head of the Liability Management Group
 The Manager of the Off-site Back-up location
The contingency plan distribution list should be finalized by the senior management of the bank.
10.5.2 People who can Authorize Emergency Measures
A list should be prepared, giving the following information about the officers who can authorize
emergency measures:
 Name and function of the officer
 Telephone extension number in the office
 Direct telephone number (if available) in the office
 Residential telephone number
10.5.3 Contact Points in Case of Hardware and Software Problems
The following information for contact points in the event of Hardware and Software Problems
should be listed:
 Name address of the Organization to be contacted
 Contact person, office telephone number and residential telephone numbers
 AX/Telex numbers of the Branch or Organization
 Port Numbers of the Oracle Financial Services Support division
 Dialing codes for the country
10.6 Potential for Exposure and Containment Measures

The Contingency Plan should clearly describe the Safety, Preventive and Containment
measures. It should include guidelines and the procedures to be followed in case of an
emergency related to Oracle FLEXCUBE.
10.6.1 Hardware Failure
Hardware failure can be caused by the following situations:
 Failure of the Main machine
 Failure of the Back-up machine
 Failure of the Main and Back-up machines
 Failure of the Disk Drive
10-5
 Failure of a Terminal
 Failure of the Remote Branch terminal
 Failure of the Remote Branch communication or Modem
 Failure of the Printer
10.6.2 Containment Measures
Main machine failure
When failure of the main machine has an immediate effect on the processing, the following steps
should be taken:
 The Manager of the Data Center should inform the user departments about the situation
and the time required to switch on the back-up system.
 The matter should be reported to the Senior Operations Manager of the bank.
 The Manager of the Data Center should establish the cause of the problem before
switching on the Back-up system.
 The Manager of the Data Center should connect all the workstations and peripherals to
the back-up system and inform all the departments.
 Contact the local dealers for immediate repair.
 Record all information about the problem in the Trouble Report Log, The details to be
included are nature of the problem, time of occurrence and name of the person reporting
the problem. The time of contacting the Customer Engineer and the arrival of the
Customer Engineer should also be recorded.
 After consultation with Customer Engineer determine the time required to get the main
system running. If the repairs are expected to extend beyond 24 hours and the off-site
back-up facility exists, inform the off-site back-up location of a possible need for use of
their system.
 The following reports should be generated at the end of each day, to provide for an
emergency. The reports will be useful if the Back-up machine fails before the Main
machine is repaired.
 Accounting Journal
 Trial Balance
 General Ledger
 Currency Position
 Limits Reports
 Accrual reports
 End of Day Account/GL Balances
Produce the accrual reports to avoid manual calculations. This program should only be run
against a copy of data.
10-6
Back-up machine failure
If the Back-up machine is inoperative, the situation does not affect the normal operations, but it
requires immediate repair to avoid a complete breakdown. The following steps should be carried
out:
 The Senior Operations Manager of the bank should be apprised of the situation. Since
the failure of the back-up machine does not disrupt the normal operations, it is not
necessary to inform the user departments.
 Enter all relevant information about the problem in the Trouble Report Log. The details
should include the nature of the problem, the time of occurrence and the name of the
person who reported the problem. The time of contacting the Customer Engineer and the
arrival of the Customer Engineer should also be recorded.
 After consultation with the Customer Engineer determine the time required to get the
back-up system running. If the repairs are expected to extend beyond 24 hours and if an
off-site back-up facility exists, inform the off-site location of a possible need to use their
system.
 If repairs are expected to take more than one day, the key reports (as outlined above,
under Main Machine Failure), should be generated. The reports will be useful if the Main
Machine fails before the back-up machine is repaired.
Failure of Main and Back-up Machines
The failure of both the Main and the Back-up machines is considered an unlikely event. The
stationery required for manual operations, should be stored off-site. In such a situation the
following steps should be taken:
 The Manager of the Data Center should inform all the user departments of the situation.
 Report to the Senior Operations Manager of the bank.
 Record all relevant information in the Trouble Report Log. The details should include the
nature of the problem, the time of occurrence and the name of the person who reported
it. The time of contacting the Customer Engineer and the arrival of the Customer
Engineer should also be recorded.
 After consultation with the Customer Engineer, determine the time required to get at least
one machine running. If the repairs are expected to extend beyond 8 hours and the off-
site back-up facility exists then inform the off-site back-up location, of a need to use their
system. The necessary equipment should be made available.
 If the Senior Operations Manager of the bank decides to go off-site to continue

processing, the following steps are recommended:
 The Data Center Manager should ensure that all the required material on the
checklist is ready to be taken to the back-up site.
 The heads of all the departments should arrange to collect the input media,
Database maintenance forms and tickets from the users and advise the systems
department of completion.
10-7
 The Data Center Manager should approve of the material checklist before the
materials can be transported to the off-site back-up facility under proper custody. The
Data Center Manager should monitor the whole process and if any problems are
encountered they should be reported to the Senior Branch Operations Manager.
At the back-up site, Oracle FLEXCUBE Database should be restored from the latest back-up
tapes from the on site library (ideally, the backup of post end of previous day). All the daily
transactions should be input if necessary and EOD should be run. Extra copies of reports should
be prepared where necessary. The bank should use the latest daily central liability printouts
(stored off-site) to pay checks over the counter and maintain manual ledger to record all
movements.
In case both the machines break down in the middle of business hours, earlier payments should
be taken into account from daily printouts (last business day central liability report) before further
payments are made.
The Senior Branch Operations Manager should use discretion in determining the specific
operation needs. The process detailed below provides a guideline for manual processing. This
can be followed if the time to get at least one system up is likely to exceed 2 working days.
 The Processing priorities should be as follows:

 Clearing Operations
 Teller transactions
 Trading Exchange/Transactions
 Import/Export Operations
 Funds Transfers
 Deposits
 Credit/Financial Control processing
 The following reports printed and kept off-site will assist in manual operations.
 Limit Reports
 Account Balances Report
 Balance controlling should be centralized with the Referral Clerk or person designated by
the Senior Branch Operations Manager.
 Adequate stationery for departmental proofs, tickets, ledgers and manifolds, should be
maintained to facilitate manual processing.
 Current Account balances should be updated manually.
 For all accounts having movements, a run-up of old balances, debits, credits and new
balances should be taken.
 Accounting entry should be done through departmental proofs and tickets. For this
purpose the trial balance and the Currency Position of the previous day should be used.
Ledgers should be maintained, showing balance B/F, debits and credits movements and
new balance.
10-8
 The Control department should comprehensively recheck all movements through source
documents and tickets. Control should ensure that all source documents and tickets are
microfilmed.
10.6.3 Disk Drive Failure
Main Machine Disk Drive Failure
This does not constitute a critical issue. If the disk fails the processing should be switched on to
the back-up machine as per the recommended procedure described above in Main machine
failure. The main machine equipment should be repaired/replaced immediately.
Back-up Machine Disk Drive failure
Although there is no impact on the operation when the disk drive fails on the back-up machine,
urgent repairs/replacements must be ensured in order to bring the probability of general system
failure back to the desired level.
Both Main and Back-up machines Disk Drive failure
Failure of both Main and Back-up machines Disk Drives constitutes a critical situation and is
considered an unlikely event. Should the situation arise the branch should follow the
recommended procedure described above in situation where both main and back-up machine
failure occurs simultaneously.
If the disk drive on the main machine is physically scratched or damaged by any means, the
latest back-up tape should be loaded on the back-up machine and re-input or re- processing has
to be done.
Terminal Failure
Any malfunctioning terminal can be replaced by the Data Center staff or Hardware Engineer with
an available terminal. The failure of one or more is not critical to Branch operations. The
recommended steps to be followed in case of terminal failure are given below:
 Any malfunction of a terminal should be notified to the Data Center Manager who should
perform first level of trouble shooting.
 The terminal should be repaired or replaced by the local vendors as soon as possible.
Remote Branch Terminal failure
Any malfunctioning remote branch terminal should be repaired or replaced by the Hardware
Engineer with the available terminal at the branch. The failure of one or more terminals is not
critical to remote Branch operations if some remote terminals are in working order. The
recommended steps to be followed in case of failure of all the remote terminals, are given below:
 Any malfunction of terminal should be notified to the Hardware Engineer.
 The terminal should be repaired or replaced by the local vendors as soon as possible.
 The transactions should be transmitted to the main branch by telex/phone or FAX. The
main branch should be responsible for the day s posting after receipt of transactions.
10-9
10.6.4 Remote Branch Communications/Modem Failure
Central Server
If the communications or modem between the main system and remote branch fails, it
automatically cut off the hardware in use in the branch, except in case of a distributed setup,
where there is a server in the remote branch. The recommended steps to be followed, where the
remote branch connects to the main system, in case of communications/modem failure are given
below:
 Contact the local communications expert to check communication line and for modem
check.
 If not fixed, the senior officer in the remote branch should decide to telephone the main
branch depending on the expected down time and the main branch should arrange to
process these inputs.
 For modem failures, back-up modem may be arranged from local vendors.
In case of a distributed set-up, the remote node can still function.
Printer failure
Any malfunctioning printer can be replaced by Data Center staff/Hardware Engineer with
available printer. The failure of one or more printers is not critical to Branch operations. The
printers can be used as back-ups for each other without any adverse effects. The recommended
steps to be followed in case of printer failure are as follows:
 Any malfunction of printer should be notified to the Data Center Manager who should
perform first level of trouble shooting.
 The printer should be repaired or replaced by the local vendors as soon as possible.
10.6.5 Software Failure
Software failure can be caused by the following situations:
 Database/Files Damage
 Oracle FLEXCUBE Software Damage
 Oracle FLEXCUBE Software Bug
The recommended steps to be followed in the above cases are:
 The Data Center Manager should inform all the user departments of the situation and the
expected time for correction.
 Report to the Senior Branch Operations Manager.
 The Data Center Manager should inform the Systems Manager.
10-10
 If the Branch has a maintenance and support agreement with Oracle Financial Services
then the Systems Manager should report/handle the problem as per the support
procedure in the Support Manual. The bank should take action as per Oracle Financial
Services s instructions.
 On the Trouble Report Log, a record should be made of the time the problem occurred,
problem description, for further investigation and action taken.
10.6.6 Utilities Failure
Utilities failures can be caused by the following situations: power supply failure and variation in
Power supply/Temperature/Humidity.
Power supply Failure
The recommended steps to be followed in case of a power supply failure are as follows:
 If advanced warning of power failure is announced Data Center Manager should make
alternative arrangements.
 The Data Center Manager should contact technicians
 Power off all the machines
 Report to Senior Branch Operations Manager
 If power remains off and back-up site arrangement exists then back-up site should be
contacted for possible use of their system.
 If power remains off for more than 8 hours prepare to move to back-up site.
Variation of Power supply/Temperature/Humidity
The recommended steps to be followed in case of a variation in Power

Supply/Temperature/Humidity are as follows:
The Data Center Manager should contact technicians and ensure:
 Power off all the machines.
 Report to Senior Branch Operations Manager.
 If variation in power/temperature/humidity lasts over 2 hours and back-up site

arrangement exists then back-up site should be contacted for possible use of their
system.
 If variation in power/temperature/humidity lasts over 8 hours, prepare to move to back-up

site.
10-11
11. Post Implementation Review
11.1 Introduction
Business entities who have implemented the Oracle FLEXCUBE and have gone live are
recommended to conduct a post implementation review along with Oracle Financial Services
Quality Assurance Group (QAG) team, to ensure that all the components in implementing the
new system have been followed. The review process aims to provide bank management and
Oracle Financial Services a framework to improve future implementation.
11.2 Overview
The post implementation review section describes the guidelines and criteria to be used in a post
implementation review, which will be conducted by a team of bank personnel along with the QAG
team from Oracle Financial Services . The thrust of this review is to ensure that the
implementation process, as defined in the Implementation Manual has been followed,
audit/control issues have been adhered to, and how the next implementation can be improved.
Relevant feedback from this review will be incorporated into the Implementation Manual.
The review will focus on the methodology used in implementing Oracle FLEXCUBE, mapping
actual facts against planned activities and potential risks such as:
 Security and Control
 Database Integrity
 Training
 Conversion
 Parallel Run
 Live Operations
The review process should be conducted by the following personnel from the bank and the QAG
team from Oracle Financial Services (formerly i-flex) :
 Senior Branch Operations Manager
 Processing Department Heads
 Internal Control Unit staff
 Financial Control Staff
 Data Center Supervisor or Data Center Manager
 Credit Department Staff
 QAG team from Oracle Financial Services (formerly i-flex)
11-1
11.3 Post Implementation Review Guidelines
Deviations
For any deviations identified, ensure that the deviations been:
 Approved by the business unit head
 Concurred with the Audit division
11.3.1 System Environment
Main and Back-up systems

 Are both systems in sync?
 Do both systems have proper access controls on all directories?
 Is any system found with Software without licenses?
 Is Anti PC Virus kit installed on both systems?
 Is the branch satisfied with system performance?
 Is there a need for H/W Enhancement to improve system performance?
Project Management
During the implementation, have the following activities taken place:
 Regular Status reporting
 Minutes of management review meeting documented
 Approval and acceptance by business unit head for deliverables
Controls
The following need to be completed and implemented:
 Contingency Plan. Staff at the bank should be aware of contingency procedures, reports
to be used in system is not available for more than a day due to Hardware or Software
problems.
 Data Center Flow charts for daily, monthly and surprise basis verification of controls.
 Input and authorization of database changes and items verified by Internal Control Unit
regularly
 Procedures on Statement Mailing have been finalized and are being followed
 Various Oracle FLEXCUBE Reports are checked regularly and are fully understood by
the users
 Control checks on advices are done regularly
 Software Release Control procedures have been finalized
11-2
 Internal Control Unit s knowledge on controls on implementing new releases and controls
needed is good
 Release Controls procedures have been implemented
 Support procedures have been finalized
 Support trial run has been conducted.
 Support trial run has been signed-off.
 Is Oracle Financial Services able to provide support to branch in case of emergency via
remote access?
 Is branch able to contact Oracle Financial Services via telephone, FAX or modem, to
provide support in case of emergency?
 Authorizer for each area for each product has been identified?
 Control check on Password file is done regularly.
 File retention periods have been finalized and documented.
 People are well trained on PC viruses and prevention, and containment procedures are
in place.
Is Internal Control Unit department aware of maintaining separation of duties on system and
Oracle FLEXCUBE SMS:
 Assigning passwords on the system
 System Ids.
 Review of Protocol list.
 Review of System Security Audit Trail.
 Review of reasons and procedure to go on supervisor mode.
 Getting the checksums of software release and independent review of program on

system.
Database Set-up
During the branch static database set-up check, that the following procedures have been
followed:
 Database Design signed off
 Data Conversion/ input strategy or plan approved and signed off
 Database set-up is done in the proper controlled Environment
 Database set-up sign-off is obtained
Oracle FLEXCUBE Software
During the implementation if the software has been modified either due to a bug or changed
requirements, check that the following procedures have been followed:
11-3
 Test Incident logs and Software Fault Reports are maintained.
 Software modification is done in separate development area.
 The proper software modification procedures have been followed.
 The modification sign-off has been obtained from users.
 Any software modification or enhancement is required due to changed requirement yet

to be completed by Oracle Financial Services (formerly i-flex)
 Follow-up action has been suggested.
System Trial Run

 The branch users need to do the system trial run before actual financial conversion.
 System Trial run plan is to be prepared.
 System Trial run results are to be documented.
 System Trial run sign-off has been obtained.
Stationery
 Tickets, Advices, Drafts, Reports, and Manager Checks have been printed.
 People who are familiar with concerned procedures to use above stationery.
Workflow
 The users are to be aware of operational procedures.
 The users are to be aware of parameter set-up and maintenance.
 Work flow relating to Oracle FLEXCUBE operations is in place.
Audit Issues
 The System Documentation is to be provided to the branch.
 The Project documentation has to be filed.
 The formal Oracle FLEXCUBE System handover note has to be given to the branch
management.
 The formal Oracle FLEXCUBE delivery document has to be given to the branch
management.
 The support procedures are clearly defined.
 Oracle FLEXCUBE system and implementation sign-off has to be obtained from the
branch.
Check that Training has been completed for the following:
 Operations users
 Data Center Operators
 System Administrator
11-4
 Control Department users
11.3.2 System Administration Issues
Oracle FLEXCUBE Environment

 The administrator must be familiar with the complete system hardware structure
 The administrator must know how to move the equipment from one place to another.
 The administrator must be familiar with basic environment settings REGEDIT etc.
System Environment
 The administrator must be familiar with defining system users assigning trustee rights.
 The administrator must understand completely the volume separation and contents of
each of them.
 The administrator must be familiar with the concepts of tablespaces, volumes, instances.
 The administrator must be familiar with the concepts of directories, sub-directories and
file attributes.
Support Environment
 The support procedures are to be clearly defined.
 The administrator must know whom to contact in case of trouble (phone numbers,
names, chat numbers).
 In case the administrator receives an urgent program modification, he must know how to
apply it and what rules to follow.
Releases
 Are all the release procedures well defined and understood by the administrator?
 Does the administrator know the procedure to install the new software release on the
production machine
11-5
12. Implementation Sign-Off
12.1 The Sign-Off procedure
After the Oracle FLEXCUBE system starts functioning smoothly in the branch and all outstanding
issues have been addressed to the satisfaction of the branch staff, the system is ready to go live.
At this stage, it is the responsibility of the Oracle Financial Services implementation team to
prepare a DELIVERY DOCUMENT which addresses various topics that the Data Center
Manager, Internal Control Unit Head and the Senior Branch Operations Officer of the branch
must be aware of, in order to run the system smoothly thereafter.
The Oracle FLEXCUBE Delivery Document is the definitive specification of the complete Oracle
FLEXCUBE system at the specific installation site.
This document will be the reference document that details the initial set-up of the branch Oracle
FLEXCUBE and will be used by the Internal Control Head and the auditors of the branch to check
the integrity of the system at any later date and check whether the system is being operated as
per procedures laid down.
This document will be updated whenever any changes are made to the system. These changes
include all program changes, upgradation to a new version of Oracle FLEXCUBE, any changes in
basic parameters, products, product level parameters and procedure.
The Internal Control department following the instructions in the Control Manual can verify the
system integrity using this document and subsequent release documents.
The contents of Delivery Document cover the entire software area of Oracle FLEXCUBE,
Operating System and Third Party products.
This document contains the following:
A cover sheet specifying the branch at which installation has been carried out, date of installation
and the names of all Oracle Financial Services implementation team members.
The specific hardware and software environments at the time of implementation sign-off giving
details of the version of operating system, third-party software, Oracle FLEXCUBE software.
Mention should also be made of the versions to which the branch can upgrade without having to
cross-check with Oracle Financial Services (formerly i-flex).
A list of all volumes set up on the hard-disk, including their size and a full list of all directories and
sub-directories created on the volumes.
A description of each sub-directory contents, including a statement of whether it contains

programs, data files or a combination of both, which users have access rights to it, the types of
accesses they have to the directories and their contents who is responsible for maintaining its
contents, and who is responsible for checking software integrity.
12-1
For each sub-directory that contains Oracle FLEXCUBE programs, a complete list of all
programs, together with their checksums. This report should give the checksums’ values at the
time of software installation, as well as at the time of going live and highlight the changes that
have been carried out.
For each sub-directory that contains data files, a list of files on the sub-directory, where this is
possible, or else the naming convention of the files is to be given. The contents of the test /trial
database should also be included.
The listings of Configfile log in scripts, REGEDIT. The user profiles under Oracle FLEXCUBE, as
at the time of going live should also be included.
For workstations with hard disks, a list of software on the hard disk that is needed to run the
Oracle FLEXCUBE system (e.g. Anti-virus software) should be listed.
The document must clearly spell out all the static set-up, basic parameter set-up, product level
set-ups done during initial database design and input.
Special operational work-flow, procedures, work-around methodology, if any suggested, should

be documented.
The document must also state all the contractual obligations that have been met like
customization, training, documentation supplied and any other issues like meeting specific
performance criteria etc. If any issues are pending, these must be mentioned along with probable
dates of completion.
Details of Oracle Financial Services maintenance support details including the contact persons,
telephone, telex, GTN and Fax details should be listed. The contact details for third-party
software should also be given so that the branch can contact them directly, if required.
This document must be signed-off by the concerned branch officer (Data Center Manager /
Internal Control Head / Senior Branch Operations Officer) and approved by the audit team of the
branch. Copies of the document must be sent to Oracle Financial Services (formerly i-flex) office
in Bangalore.
12-2
Implementation
[May] [2011]
Version 11.3
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com/ financial_services/
Copyright © [2011] Oracle Financial Services Software Limited. All rights reserved.
No part of this work may be reproduced, stored in a retrieval system, adopted or transmitted in any form or by any means,
electronic, mechanical, photographic, graphic, optic recording or otherwise, translated in any language or computer
language, without the prior written permission of Oracle Financial Services Software Limited.
Due care has been taken to make this document and accompanying software package as accurate as possible. However,
Oracle Financial Services Software Limited makes no representation or warranties with respect to the contents hereof and
shall not be responsible for any loss or damage caused to the user by the direct or indirect use of this document and the
accompanying Software System. Furthermore, Oracle Financial Services Software Limited reserves the right to alter,
modify or otherwise change in any manner the content hereof, without obligation of Oracle Financial Services Software
Limited to notify any person of such revision or changes.
All company and product names are trademarks of the respective companies with which they are associated.

Oracle Flexcube Implemention

Uploaded by

Copyright:

Available Formats

Oracle Flexcube Implemention

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Flexcube Implemention

Uploaded by

Copyright:

Available Formats

Implementation

Oracle FLEXCUBE Universal Banking

It is important to establish what an Oracle FLEXCUBE implementation involves. This can be

The Software Installation section describes the recommended software organizations,

System Trial Run

Post- Implementation Review

1.2.1 Abbreviations and Jargon

DBA Database Administrator

POIROT Problem Incident Recording and Tracking System

RDBMS Relational Database Management System

BC Bills & Collections

LD Loans & Deposits

SFR Software Fix Report

SPC Single Point of Contact

Front Refers to FX, MM, FT, LD, LC, BC, SE and SI

1.2.2 Glossary of Icons

Coming first in the list of a number of things are the following:

 Structure of the implementation teams

 The project plan

 Methodology for status reports

2.2 Structure of Implementation Teams

A typical structure of the Implementation Team is illustrated below:

 Senior Operations Manager of the bank

 Project Manager from Oracle Financial Services (formerly i-flex)

 Project Manager from the bank

 Financial Controller of the bank

 Head of Information Technology Division

 Head of the Internal Control Unit

2.4 Methodology for Status Reports

The Current Status Report should give the following information:

 Work completed during the fortnight.

 Work scheduled for the next fortnight.

 Problems encountered during the fortnight.

2.4.1.1.1.1.1.1.1 Current Status Report

1. The Project: Implementation of Oracle FLEXCUBE at First Commercial Bank at Melbourne,

Customer Ms. Annabel Smith (IT Head)

Mr. Jim Hacker (Systems Manager)

Oracle Financial Services Sylvia John

3. Reporting Period: 15/03/98 to 31/03/98

Activity Plan Actual Responsibility Remarks

Start End Start End

S/w Installation 15/03 17/03 20/03 Oracle Financial Given below

User Training 22/03 23/03 In Oracle Financial Given below

Database Set- 24/03 24/03 In Oracle Financial Given below

Activity Plan Actual Responsibility Remark

Code Structures 08/04 FCB

General Ledger 08/04 FCB

List of 08/04 FCB

6. Achievements during the period:

Software installation completed.

User training for Data Entry module completed.

8. Plan for the next fortnight:

Professional working days: 10 working days + 1 Saturday

Milestone achieved for billing: S/w installation

Expenses to be billed to client: Airfare and incidental expenses to Melbourne.

2.4.2 Support Status Report

The following is a sample Support Status Report:

2.4.2.1.1.1.1.1.1 Support Status Report

Reporting Period: 16/02 to 30/03

Brought forward from last report. 05 09