Oracle FLEXCUBE Universal Banking

Oracle FLEXCUBE Universal Banking
Core Services User Guide
Oracle FLEXCUBE Universal Banking
Release 12.87.02.0.0
Part No. E71280-01
February 2016
Core Services User Guide
February 2016
Oracle Financial Services Software Limited
Oracle Park
Off Western Express Highway
Goregaon (East)
Mumbai, Maharashtra 400 063
India
Worldwide Inquiries:
Phone: +91 22 6718 3000
Fax:+91 22 6718 3001
www.oracle.com/financialservices/
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed
on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to
the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure,
modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the
hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other
rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or
intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use
this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup,
redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages
caused by use of this software or hardware in dangerous applications.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and
are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may
not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any part, in
any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors,
please report them to us in writing.
This software or hardware and documentation may provide access to or information on content, products and services from third
parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect
to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or
damages incurred due to your access to or use of third-party content, products, or services.
Contents
1.
Preface ...................................................................................................... 1-1
1.1
1.2
1.3
1.4
1.5
1.6
2.
2.2
2.3
2.4
2.5
Introduction.............................................................................................................. 3-1
Maintaining Ramadan Day ...................................................................................... 3-1
Dealer Maintenance ................................................................................. 4-1
4.1
5.
Defining Bank Level Parameters ............................................................................. 2-1
2.1.1 Maintaining Financial Preferences ............................................................. 2-2
2.1.2 Generating Automatic Balancing Entries.................................................... 2-3
2.1.3 Maintaining General Preferences ............................................................... 2-4
2.1.4 Placing User Restrictions on Data Entry Batches ...................................... 2-7
2.1.5 Specifying UDF Details............................................................................. 2-12
2.1.6 Specifying Account Generation Parameters at Bank Level...................... 2-12
2.1.7 Maintaining Zengin Characters................................................................. 2-25
2.1.8 Defining Bank-wide Preferences .............................................................. 2-27
2.1.9 Maintaining FATCA Preferences .............................................................. 2-35
Maintaining Product Groups .................................................................................. 2-36
Maintaining Mayuru Limit Details........................................................................... 2-36
2.3.1 Viewing Maruyu Limit Details ................................................................... 2-40
Maintaining Deposit Insurance Parameters........................................................... 2-41
Maintaining Customer DIC Details ........................................................................ 2-41
2.5.1 Viewing Customer DIC Details ................................................................. 2-43
2.5.2 GI Interface Definition for DIC Outgoing Hand-off File ............................. 2-44
Ramadan Maintenance ............................................................................ 3-1
3.1
3.2
4.
1-1
1-1
1-1
1-1
1-3
1-3
Bank Parameters ..................................................................................... 2-1
2.1
3.
Introduction..............................................................................................................
Audience..................................................................................................................
Documentation Accessibility....................................................................................
Organization ............................................................................................................
Related Documents .................................................................................................
Glossary of Icons.....................................................................................................
Defining Dealer........................................................................................................ 4-1
Branch Parameters .................................................................................. 5-1
5.1
Creating Branches................................................................................................... 5-1
5.1.1 System Features ........................................................................................ 5-1
5.1.2 Creating Reporting Structure...................................................................... 5-2
5.1.3 Basic Parameters for Branch...................................................................... 5-2
5.1.4 Maintaining General Details for Branch...................................................... 5-4
5.1.5 Maintaining Financial Details for Branch .................................................... 5-8
5.1.6 Maintaining Duplication Check Details ..................................................... 5-13
5.1.7 Maintaining SWIFT Address for Branch ................................................... 5-14
5.1.8 Defining Account Mask............................................................................. 5-14
5.1.9 Maintaining Customer Number Range .................................................... 5-16
5.1.10 Maintaining Global Interdict Functions ..................................................... 5-19
5.1.11 Maintaining Preferences........................................................................... 5-19
5.1.12 Maintaining LCY Message Preference for Branch ................................... 5-26
5.2
5.3
6.
6.4
6.5
6-1
6-1
6-2
6-4
6-5
6-6
Introduction.............................................................................................................. 7-1
7.1.1 Maintaining Dates Change ......................................................................... 7-2
Web Service Maintenance ....................................................................... 8-1
8.1
8.2
9.
Introduction..............................................................................................................
Maintaining Branch Transfer Parameters................................................................
Transferring Customer Account Branch ..................................................................
6.3.1 Viewing Account Branch Transfer Details ..................................................
Transferring Account Class .....................................................................................
Processing Account Branch Transfer ......................................................................
System Dates Maintenance .................................................................... 7-1
7.1
8.
5-27
5-27
5-31
5-31
5-32
5-32
5-34
5-34
5-34
5-35
5-36
Account Branch Transfer ........................................................................ 6-1
6.1
6.2
6.3
7.
5.1.13 Specifying UDF Details.............................................................................
5.1.14 Maintaining Address Codes Details..........................................................
5.1.15 Address Code Summary ..........................................................................
Maintaining Tax Cycle ...........................................................................................
5.2.1 Updating Tax Cycle .................................................................................
5.2.2 Maintaining Tax .......................................................................................
5.2.3 Maintaining Clearing Currencies ..............................................................
5.2.4 Account Statement Handoff......................................................................
5.2.5 Account Statement Generation ................................................................
Maintaining Role to Head Mapping at Branch Level .............................................
5.3.1 Viewing Accounting Role to Head Mapping Details .................................
Introduction..............................................................................................................
Maintaining Web Service.........................................................................................
8.2.1 Mapping of Web Service ............................................................................
8.2.2 Web Service Details ...................................................................................
8.2.3 WebService Maintenance...........................................................................
8-1
8-1
8-2
8-3
8-4
Accounts for Inter-Branch Transactions .............................................. 9-1
9.1
9.2
Defining Accounts for Inter-Branch Transactions ....................................................
9.1.1 System Features ........................................................................................
9.1.2 Specifying Customer Accounts...................................................................
Defining Accounts for Inter-Branch Fund Transactions...........................................
9.2.1 Querying on Netting Batch .........................................................................
9-1
9-2
9-4
9-5
9-6
10. Currency Maintenance .......................................................................... 10-1
10.1 Introduction............................................................................................................ 10-1
10.2 Maintaining Currency Details................................................................................. 10-1
10.2.1 Indicating Rounding Preferences ............................................................. 10-6
10.2.2 Specifying Amount Format Mask.............................................................. 10-7
10.2.3 Specifying Exchange Rate Limits ............................................................. 10-8
10.2.4 Mapping Currency to Country .................................................................. 10-8
10.2.5 Specifying User Defined Fields ................................................................ 10-9
10.2.6 Annexure .................................................................................................. 10-9
10.2.7 Specifying Currency Cut-Off Parameters .............................................. 10-12
10.3 Maintaining Currency Position Details................................................................. 10-14
10.4 Handling Euro...................................................................................................... 10-16
10.5 Maintaining Euro Related Information ................................................................. 10-17
10.5.1 Maintaining Currency Details.................................................................. 10-17
10.5.2 Maintaining Conversion GLs .................................................................. 10-19
10.5.3 Implications of Currency Redenomination .............................................. 10-19
10.5.4 Specifying Preferred ERI Currency for Counterparty .............................
10.5.5 Specifying Settlement Message Details .................................................
10.5.6 Settlements of Foreign Exchange Deals ...............................................
10.5.7 Reports and Advices ..............................................................................
10.5.8 Maintaining Limits Type..........................................................................
10.5.9 Maintaining Transaction Limits ..............................................................
10.6 Maintaining Sequence Generation Format..........................................................
10-21
10-22
10-22
10-22
10-23
10-24
10-26
11. Maintaining Currency Denomination ................................................... 11-1
11.1 Introduction............................................................................................................ 11-1
11.2 Maintaining Currency Denomination Details ......................................................... 11-1
12. Expressing Amounts in Words ............................................................ 12-1
12.1 Introduction............................................................................................................ 12-1
13. Defining Currency Pairs ........................................................................ 13-1
13.1 Introduction............................................................................................................ 13-1
13.2 Maintaining Currency Pair Details ......................................................................... 13-1
13.2.1 System Features ...................................................................................... 13-1
13.2.2 Maintaining Parameters for Currency Pair ............................................... 13-2
13.2.3 Specifying Points Multiplier....................................................................... 13-4
14. Maintaining Exchange Rates ................................................................ 14-1
14.1 Introduction............................................................................................................ 14-1
14.2 Maintaining Currency Rates .................................................................................. 14-1
14.2.1 Authorizing Exchange Rates .................................................................... 14-4
14.2.2 Revising Exchange Rates ........................................................................ 14-4
14.2.3 Viewing Exchange Rates.......................................................................... 14-4
14.2.4 Viewing Currency Batch Rate................................................................... 14-5
14.2.5 Specifying Limits for Cross Currency Transactions .................................. 14-5
14.3 Maintaining Currency Position Threshold Limits ................................................... 14-8
14.3.1 Viewing Currency Position Threshold Limits Summary ............................ 14-9
14.3.2 Viewing Currency Position...................................................................... 14-10
15. Maintaining Currency Spread for Customer ....................................... 15-1
15.1 Maintaining Currency Spread ................................................................................
15.2 Maintaining Customer Spread Details ...................................................................
15.2.1 Computing Buy and Sell Spreads.............................................................
15.2.2 Maintaining Currency Margins for Customer ............................................
15-1
15-2
15-4
15-4
16. Maintaining Company Codes ............................................................... 16-1
16.1 Introduction............................................................................................................ 16-1
17. Period Code Maintenance ..................................................................... 17-1
17.1 Introduction............................................................................................................ 17-1
17.2 Invoking Period Code Maintenance Screen .......................................................... 17-1
17.3 System Functions .................................................................................................. 17-3
18. Status Code Maintenance ..................................................................... 18-1
18.1 Introduction............................................................................................................ 18-1
18.2 Invoking Status Maintenance Screen .................................................................... 18-1
18.2.1 Maintaining Status Codes for Contracts ................................................... 18-2
18.2.2 Maintaining Status Codes for OD Account ............................................... 18-3
18.3 Maintaining Dormancy Parameter Details ............................................................. 18-3
18.4 Maintaining CR\DR Statistics Details ................................................................... 18-5
19. Transaction Code Maintenance ............................................................ 19-1
19.1 Introduction............................................................................................................ 19-1
19.2 Invoking Transaction Code Screen ....................................................................... 19-1
19.2.1 Maintaining Transaction Details .............................................................. 19-2
19.2.2 Maintaining Country Name Details ........................................................... 19-9
20. Account Revaluation Maintenance ...................................................... 20-1
20.1 Introduction............................................................................................................ 20-1
21. Maintaining Branch Holidays ............................................................... 21-1
21.1 Introduction............................................................................................................ 21-1
21.2 Invoking Local Holiday Screen .............................................................................. 21-1
21.2.1 Steps to Define Yearly Holidays ............................................................... 21-2
21.2.2 Defining Holidays...................................................................................... 21-3
21.2.3 Annual Holidays........................................................................................ 21-3
21.2.4 Designating Unexpected Holidays for Branch .......................................... 21-3
22. Maintaining Currency Holidays ............................................................ 22-1
22.1 Introduction............................................................................................................ 22-1
22.2 Invoking Currency Holiday Screen ........................................................................ 22-1
22.2.1 Steps to Define Currency Holidays........................................................... 22-2
22.2.2 Defining Currency Holidays ...................................................................... 22-2
22.3 Uploading Holiday File........................................................................................... 22-2
23. Maintaining Clearing Holidays ............................................................. 23-1
23.1 Introduction............................................................................................................
23.1.1 Steps to Define Clearing House Holidays ................................................
23.1.2 Defining Clearing House Holidays............................................................
23.1.3 Designating Unexpected Holidays for Clearing House.............................
23-1
23-1
23-2
23-2
24. Document Maintenance ........................................................................ 24-1
24.1
24.2
24.3
24.4
24.5
Introduction............................................................................................................
Maintaining Document Type..................................................................................
Viewing Document Type Details............................................................................
Maintaining Document Checklist Details ..............................................................
Viewing Document Type Details............................................................................
24-1
24-1
24-1
24-3
24-4
25. Configuring Overrides ........................................................................... 25-1
25.1 Introduction............................................................................................................
25.1.1 Types of Overrides ...................................................................................
25.2 Specifying Override Type ......................................................................................
25.2.1 Maintaining Override Conversion .............................................................
25.2.2 Maintaining Error Codes...........................................................................
25-1
25-1
25-2
25-3
25-3
26. Maintaining Features ............................................................................. 26-1
26.1 Introduction............................................................................................................ 26-1
26.2 Maintaining Feature ID .......................................................................................... 26-1
26.2.1 Specifying UDF Values............................................................................. 26-3
26.3 Viewing Feature ID Summary................................................................................ 26-4
27. Purging and Archiving Data ................................................................. 27-1
27.1 Purging Data..........................................................................................................
27.2 Module Purging .....................................................................................................
27.3 Maintaining Purge Details.....................................................................................
27.4 Entity Purging ........................................................................................................
27.4.1 Configuring Purge Parameters .................................................................
27.4.2 Viewing Purge Parameter Configuration Details ......................................
27.4.3 Processing Ad-hoc Purge.........................................................................
27.4.4 Parallel Stream Maintenance ...................................................................
27-1
27-1
27-2
27-3
27-4
27-6
27-7
27-9
27.4.5 Inquiring Purge Log ................................................................................
27.5 Archiving Data .....................................................................................................
27.5.1 Archival of CASA and GL Transaction History .......................................
27.5.2 Archival of Closed CASA Accounts ........................................................
27.5.3 Archival of TD accounts..........................................................................
27.5.4 Archival of Liquidated Loans ..................................................................
27.5.5 Archival of ATM/POS/IVR Transaction Logs ..........................................
27.5.6 Archival of Payment (Zengin) Transactions............................................
27.5.7 Archival of Branch Transaction Logs......................................................
27.5.8 Archival of Retail Teller Transaction Logs ..............................................
27.5.9 Archival of Interface Gateway Logs........................................................
27.5.10 Archival of Generic Interface (File/Batch) Upload Logs.........................
27.5.11 Archival of Exchange Rate History ........................................................
27.5.12 Archival of Security Management Logs .................................................
27.5.13 Archival of Audit Logs............................................................................
27-10
27-10
27-11
27-14
27-15
27-16
27-17
27-18
27-19
27-20
27-21
27-22
27-23
27-23
27-24
28. Support 24x7 .......................................................................................... 28-1
28.1 Introduction............................................................................................................ 28-1
28.1.1 Gateway Messaging ................................................................................. 28-1
28.1.2 Web Branch.............................................................................................. 28-1
28.1.3 Batch Processing ..................................................................................... 28-1
28.1.4 Processing Different Categories during EOD ........................................... 28-2
28.2 Supporting 24x7 Transactions............................................................................... 28-7
28.2.1 24x7 Transactions through Channel......................................................... 28-8
28.2.2 24x7 Transactions through Branch or Call Centre ................................... 28-9
28.2.3 EOD handling ......................................................................................... 28-13
28.2.4 Call Centre Handling .............................................................................. 28-15
29. Tanking of Maintenance Records ........................................................ 29-1
29.1 Introduction............................................................................................................ 29-1
29.2 Tanking New and Modified Maintenance Records ................................................ 29-1
29.2.1 Tanking New Records .............................................................................. 29-2
29.2.2 Tanking Modified Records........................................................................ 29-2
29.2.3 Closing a Record ...................................................................................... 29-2
29.2.4 Re-opening a Record ............................................................................... 29-2
29.2.5 Authorizing a Record ................................................................................ 29-2
29.2.6 Deleting a Record .................................................................................... 29-2
29.2.7 Viewing Summary of Records .................................................................. 29-2
29.2.8 Modifying Tanking Preferences ................................................................ 29-2
30. External Deal Maintenance ................................................................... 30-1
30.1 Introduction............................................................................................................ 30-1
31. Annexure B - File Formats .................................................................... 31-1
31.1 Introduction............................................................................................................ 31-1
31.2 Upload File Formats .............................................................................................. 31-1
32. Anti-Money Laundering Reporting ....................................................... 32-1
32.1 Guarding Against Money Laundering ....................................................................
32.1.1 Creating Product Categories in Oracle FLEXCUBE.................................
32.2 Maintaining Limit Codes ........................................................................................
32.3 Maintaining Anti Money Laundering Customer Groups.........................................
32.4 Monitoring AML Accounting...................................................................................
32-1
32-1
32-3
32-4
32-7
33. Developer and Developer Project Maintenance .................................. 33-1
33.1 Introduction............................................................................................................ 33-1
33.2 Maintaining Developer Details............................................................................... 33-1
33.2.1 Viewing Project Details............................................................................. 33-2
33.2.2 Viewing UDF Details................................................................................. 33-3
33.3 Viewing Developer Maintenance Summary........................................................... 33-3
33.4 Maintaining Developer Project Details................................................................... 33-4
33.4.1 Viewing UDF Details................................................................................. 33-5
33.5 Viewing Developer Project Maintenance Summary ............................................. 33-6
34. Project Financing ................................................................................... 34-1
34.1 Introduction............................................................................................................ 34-1
34.2 Processing Finance for Project.............................................................................. 34-1
34.3 Maintaining Project Financing Transaction............................................................ 34-4
34.3.1 Specifying the Project Details................................................................... 34-5
34.3.2 Specifying the Main Details ...................................................................... 34-7
34.3.3 Specifying Milestones Details................................................................... 34-8
34.3.4 Specifying the Venture Details ................................................................. 34-9
34.3.5 Specifying PPC Limits Details ................................................................ 34-11
34.3.6 Specifying Non PPC Limits Details......................................................... 34-13
34.4 Maintaining PPC.................................................................................................. 34-14
34.4.1 Specifying PPC Maintenance Details ..................................................... 34-15
34.4.2 Specifying Joint Venture Details............................................................. 34-16
34.4.3 Maintaining PPC Liquidation .................................................................. 34-17
34.5 Viewing Dashboard Details ................................................................................. 34-18
34.5.1 Viewing PPC Details............................................................................... 34-18
34.5.2 Viewing Limit Details .............................................................................. 34-19
34.5.3 Viewing Commitment Details.................................................................. 34-20
34.5.4 Viewing Loan Details .............................................................................. 34-21
34.6 Querying Dashboard Details ............................................................................... 34-22
34.7 Querying Accounting Entries ............................................................................... 34-22
35. Error and Error Codes for Project Financing ..................................... 35-1
35.1 Error and Error Codes ........................................................................................... 35-1
36. Reports ................................................................................................... 36-1
36.1 Introduction............................................................................................................ 36-1
36.2 List of Deleted Transactions .................................................................................. 36-1
36.2.1 Contents of Report ................................................................................... 36-2
36.3 Accounting Journal ................................................................................................ 36-4
36.3.1 Contents of Report ................................................................................... 36-5
36.4 Cash Flow Report.................................................................................................. 36-6
36.4.1 Contents of Report ................................................................................... 36-7
36.4.2 Cash Flow (Summary) Report .................................................................. 36-8
36.5 Future Dated Account Balance Report.................................................................. 36-9
36.5.1 Contents of the Report ............................................................................. 36-9
36.6 Current Rates Report .......................................................................................... 36-10
36.6.1 Contents of Report ................................................................................. 36-11
36.7 Rate History Report ............................................................................................. 36-12
36.8 Customer Account Opening Confirmation Report ............................................... 36-13
36.8.1 Contents of the Report ........................................................................... 36-14
36.9 Activity Journal Report......................................................................................... 36-15
36.9.1 Contents of Report ................................................................................. 36-16
36.10 Core Exception Report ........................................................................................
36.10.1 Contents of Report ................................................................................
36.11 Uncollected Funds Report ...................................................................................
36.11.1 Contents of Report ................................................................................
36.12 Account Revaluation Report................................................................................
36.12.1 Contents of Report ................................................................................
36.13 Accounts Movement Report ................................................................................
36.13.1 Contents of Report ................................................................................
36.14 Customer Details Report .....................................................................................
36.14.1 Contents of Report ................................................................................
36.15 Customer Accounts Report .................................................................................
36.15.1 Contents of Report ................................................................................
36.16 Document Check List Report...............................................................................
36.16.1 Contents of the Report ..........................................................................
36.17 Memo Revaluation Report...................................................................................
36.17.1 Contents of Report ................................................................................
36.18 Black Listed During Contract Booking Report .....................................................
36.18.1 Contents of the Report ..........................................................................
36.19 Black List Report During File Upload Report.......................................................
36.19.1 Contents of the Report ..........................................................................
36.20 Cheque Book Issued Report ...............................................................................
36.20.1 Contents of the Report ..........................................................................
36.21 Demand Draft Issued Report...............................................................................
36.21.1 Contents of the Report ..........................................................................
36.22 PDC Input Report ................................................................................................
36.22.1 Contents of the Report ..........................................................................
36.23 Temporary Overdraft Report ...............................................................................
36.23.1 Contents of the Report ..........................................................................
36.24 Daily Sales Report...............................................................................................
36.24.1 Contents of the Report ..........................................................................
36.25 Exception Report .................................................................................................
36.25.1 Contents of the Events Log ...................................................................
36-17
36-18
36-19
36-19
36-20
36-20
36-22
36-22
36-23
36-24
36-28
36-29
36-32
36-33
36-34
36-34
36-35
36-36
36-37
36-37
36-38
36-39
36-39
36-40
36-41
36-42
36-43
36-44
36-45
36-46
36-47
36-48
37. Function ID Glossary ............................................................................. 37-1
1. Preface
1.1
Introduction
This manual is designed to help you quickly get acquainted with the Core Services module of
Oracle FLEXCUBE.
You can further obtain information specific to a particular field by placing the cursor on the
relevant field and striking <F1> on the keyboard.
1.2
Audience
This manual is intended for the following User/User Roles:
1.3
Role
Function
Back office clerk
Input functions for contracts
Back office managers/officers
Authorization functions
Product Managers
Product definition and authorization
End of day operators
Processing during end of day/ beginning of
day
Financial Controller/Product Managers
Generation of reports
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
1.4
Organization
The manual is organized in the following manner:
Chapter 1
About this Manual gives a brief introduction of the module, the audience it addresses and the organization of the various chapters. It also
includes the list of related documents to be referred, if any, and the
conventions used in the document
Chapter 2
Bank Parameters explains the maintenance of various basic details
about your bank
Chapter 3
Ramadan Maintenance explains maintenance of Ramadan year.
Chapter 4
Dealer Maintenance explains how you can capture profiles of dealers
involved in buying and selling of foreign exchange
Chapter 5
Branch Parameters explains the process of creating and maintaining
branches of your bank, with all necessary details
1-1
Chapter 6
Account Branch Transfer explains how you can maintain and process
account transfers from one branch of the bank to another.
Chapter 7
System Dates Maintenance explains how you can maintain system
dates for the branches of your bank
Chapter 8
Web Service Maintenance explains the process of WebService Mapping and other details regarding maintenance of external WebService.
Chapter 9
Accounts for Inter-Branch Transactions explains how you can maintain internal accounts for branches involved in inter-branch transactions
Chapter 10
Currency Maintenance explains the process of maintaining currencies
in the system, with all necessary static attributes
Chapter 11
Maintaining Currency Denomination explains the maintenance of
standard currency denominations for each currency
Chapter 12
Expressing Amounts in Words describes the details of maintaining
amounts in words
Chapter 13
Defining Currency Pairs explains the maintenance of static attributes
for currency pairs for which exchange rate quotes are available
Chapter 14
Maintaining Exchange Rates explains the maintenance of exchange
rates used to buy and sell currencies one for another
Chapter 15
Maintaining Currency Spread for a Customer explains the maintenance of currency spread and margin details for a customer
Chapter 16
Maintaining Company Codes explains the maintenance of company
codes predominantly used for cycle based rates.
Chapter 17
Period Code Maintenance explains the maintenance of financial periods into which each financial cycle is to be divided
Chapter 18
Status Code Maintenance explains the maintenance of codes that you
can assign to the different statuses that a contract or a customer
account can attain
Chapter 19
Transaction Code Maintenance explains the maintenance of codes
that you can use to represent different types of transactions
Chapter 20
Account Revaluation Maintenance explains the maintenance of
parameters for account revaluation
Chapter 21
Maintaining Branch Holidays explains the maintenance of the holiday
calendar for the different branches of your bank
Chapter 22
Maintaining Currency Holidays explains the maintenance of the holiday calendar for the different currencies in which your bank transacts
Chapter 23
Maintaining Clearing Holidays explains the maintenance of the holiday
calendar for the different clearing houses with which your bank transacts
Chapter 24
Document Maintenance explains about the type of documents to be
submitted before opening an account and the document checklist to
be maintained.
1-2
1.5
1.6
Chapter 25
Configuring Overrides details on configuring overrides of the system.
Chapter 26
Maintaining Features explains the method of installing features in a
branch to improve the performance of the system during online or
batch processes.
Chapter 27
Purging Data explains the details of purging data.
Chapter 28
Support 24x7 explains about the 24x7 support features in FCUBS.
Chapter 29
Tanking of Maintenance Records explains the process of tanking
maintenance records.
Chapter 30
External Deal Maintenance explains the process of capturing deals
booked in an external system.
Chapter 31
Annexure B – File Formats contains a list of file formats.
Chapter 32
Anti-Money Laundering Reporting explains the process of guarding
against money laundering, a facility provided by Oracle FLEXCUBE
Chapter 33
Developer and Developer Project Maintenance explains how you can
maintain details of the real-estate developer and developer projects.
Chapter 34
Project Financing explains the process of maintaining the project
finance transaction in a bank using the Project Detail and Maintenance screen.
Chapter 35
Error and Error Codes for Project Financing lists all the error messages that you can encounter while working with this module.
Chapter 36
Reports explains the procedure of generating Reports.
Chapter 37
Function ID Glossary has alphabetical listing of Function/Screen ID's
used in the module with page references for quick navigation.
Related Documents

The Procedures User Manual

The Settlements User Manual
Glossary of Icons
This User Manual may refer to all or some of the following icons:
Icons
Function
Exit
Add row
Delete row
Option List
1-3
2. Bank Parameters
2.1
Defining Bank Level Parameters
In the ‘Bank Wide Parameters’ screen, you maintain basic information about your bank such
as its name, head office, account number structure, local currency and so on.
The details that you maintain in this screen will be made applicable to all branches of your
bank. For instance, the account number structure that you define in this screen will be a
common format for customer accounts in all branches of your bank.
Invoke the ‘Bank Parameters’ screen by typing ‘STDBNKPM’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
You can maintain the following details in this screen:
Bank Code
In Oracle FLEXCUBE a bank is identified by a unique four-character code. You can follow
your own convention in devising this code. In all inter-bank transactions this code identifies
your bank.
Name
You can also specify the detailed name of the bank. This name will always be displayed
whenever the bank code is used.
2.1.0.1
Specifying Details of Head Office Branch
After specifying a code to identify your bank, you should specify details of the head office of
your bank.
2-1
Code
From the list of the branches you have already maintained of your bank, designate one as
your Head Office
Description
The description of the branch designated as Head Office is displayed.
2.1.1
Maintaining Financial Preferences
In this screen, you can maintain information regarding default currency for the branch, specify
if balancing entries must be automatically generated in case of mismatches, define routing
mask, clearing bank code etc.
2.1.1.1
Specifying Default Currency Codes
You can indicate currency preferences for your bank. You can specify preferences to indicate
the default currencies for the following purposes:

Local — The currency that you indicate as the local currency will be taken as the local
currency for all branches of your bank and the default currency for all transactions input
into Oracle FLEXCUBE. The income and expense balances of your bank will also be
maintained in this currency

Discount — If the discount rate for a particular currency is not maintained the discount
rate of the specified discount currency will be picked up for discounting profits on
forward foreign exchange contracts

Head Office — The default currency for the Head Office

Reporting — The default currency in which all financial reporting should be done
You will not have an option to modify the default currencies that you specify after the Bank
Parameters record has been stored and authorized.
Auto Generate Currency and Value Date Mismatch Entries
You can specify that balancing entries must be generated automatically by Oracle
FLEXCUBE, in the case of currency or value date mismatches in accounting entries due to
transactions that are not balanced with respect to currency or value dates, for each branch
(single entity) of your bank.
To specify the automatic generation of such balancing entries for currency mismatches, select
the options ‘Auto Generate Currency Mismatch Entries’ and for generation of balancing
entries to correct value date mismatches, select ‘Auto Generate Value Date Mismatch Entries’
in the Bank Wide Parameters screen.
If indicated in the Bank Wide Parameters, balancing entries will be automatically generated
for any event if a mismatch of currency or value date entries (or both) is involved in any
module of Oracle FLEXCUBE, with the exception of manually entered journal entries.
2.1.1.2
Specifying Control Accounts for Auto Balancing Entries (Real and Contingent)
If you specify that such automatic balancing entries must be generated, you can also specify
the control accounts into which the entries must be booked.
There are two sets of accounts that you can maintain in the Bank-Wide Parameters screen,
one for mismatches arising out of entries to real accounts and another for mismatches arising
out of entries to contingent accounts. The relevant Control accounts must therefore be of Real
or Contingent nature (as defined in the GL – Chart of Accounts). Such balancing entries will
be automatically generated if a mismatch of currency or value date entries (or both) is involved
in any module of Oracle FLEXCUBE, except Journal Entry.
2-2
In your Chart of Accounts, you must ensure that the following conditions are not indicated for
the control accounts that you have specified for the currency mismatch and value date
mismatch entries:

Position accounting: Even if position accounting is set to “Yes” for the control account,
the system will not pass any position accounting entries, since position accounting is
done only for the main set of entries and not for the auto-balancing entries.

Account revaluation: Account revaluation must be set for the control accounts since the
effect of revaluing these balances would be offset the effect of revaluing the original
GLs. (the GLs into which the main entries were posted).

Direct posting: If you post a manual entry to one of the Control Accounts and the
Position Entry Flag for the Control Account is set to 'Yes', then the system will do
position accounting for that entry. Hence, for the GLs set-up as Control Accounts, the
“Direct Posting” flag in the Chart of Accounts maintenance must be turned OFF.
Note
Additionally, it is also recommended that these Control Account GL's that you have specified in the Bank Wide Parameters screen for the mismatch entries are not used as part of
Role to Head Mapping in any of the products. If maintained, the system would pass mismatch adjustment entries into the same GLs in which the main entries have been passed.
There is no system-enforced validation of this and this aspect needs to be taken care of
during Product set-up.
2.1.2
Generating Automatic Balancing Entries
In the case of transactions entered in any of the front-end modules of Oracle FLEXCUBE, the
accounting process checks the entries at each business event, and automatically generates
the balancing entries in case of a mismatch in currency or value date entries (or both).
Manually entered journal entries
In the case of manually entered journal entries, a journal batch that has been opened must
be closed before it is authorized. During closure, the accounting process checks to see that
the batch is balanced with respect to currency and value date entries. If a mismatch is
detected, the accounting process raises an override to this effect. Depending upon how the
override is configured, for your bank, the user who has opened the batch could adopt either
of the following courses of action:

If the override is configured to be an error, the system will not allow the user to close the
batch without balancing the mismatches.

If the override is configured to be a warning (either ‘Override’ or ‘Ignore’), the user can
save the batch with the mismatches. No balancing entries are automatically generated
by the system for the mismatch.
Uploaded journal entries
In the case of uploaded journal entries, a journal batch that has mismatched entries is not
rejected, but an override is raised by the accounting process. Depending upon how the
override is configured, for your bank, the accounting process takes either of the following
paths:

If the override is configured to be an error, then the batch is rejected, and must be
uploaded again with the corrected entries.

If the override is configured to be a warning, the accounting process automatically
generates the balancing entries for the currency or value date mismatches, for the
batch, and posts them to the requisite control accounts specified in the Bank
Parameters.
2-3
In each case, the transaction reference for the balancing entries is the same as that of the
original accounting entry, in which the mismatch occurred, and the other details of the
balancing entries are, by default, the corresponding values in the original entries.
The mismatch balancing entries are generated in the following order or preference:

Currency mismatch balancing entries

Value Date mismatch balancing entries
In the case of mismatches in accounting entries due to inter-branch transactions, the interbranch balancing entries are generated before any balancing entries for currency
mismatches, and then, finally, the value date mismatches.
Routing Mask
A mask defines the manner in which a Routing Number is generated for your bank. It is on the
basis of the routing number that Oracle FLEXCUBE processes clearing transactions.
The following is a typical mask format: ‘BBBbbbSSS’, wherein, ‘BBB’ indicates the bank code,
‘bbb’ indicates the branch, and ‘SSS’ indicates the sector to which the branch belongs. On the
basis of the routing number, clearing transactions are routed to the appropriate branch of your
bank.
Clearing Bank Code
Specify the code by which your bank is identified in the Clearing Network you participate in.
This has to the same as that specified for your bank in the Clearing Bank Code Maintenance
screen.
2.1.3
Maintaining General Preferences
In this screen, you can define format masks (for general ledger, CIF), choose if batch numbers
should be auto-generated by the system, specify the details for cheque numbering etc.
2-4
2.1.3.1
Defining Format Masks
A format mask is a structure that you can you can define for various elements that need to be
entered in Oracle FLEXCUBE. You can define format masks for the following elements:

General Ledgers

Customer Identification File codes

Customer account numbers
Once defined, you can modify the structure of a format mask only if no Customer or General
Ledger Account has been opened using the mask. Customer Account mask is defined from
the ‘Account Mask’ Button.
For more details on defining customer account mask, refer the section titled ‘Specifying
Account Generation Parameters at Bank Level’.
CIF Mask
You can maintain a mask for generation of identification numbers (CIF Number) for customers
of your bank. During customer information maintenance, the system will automatically
generate the CIF numbers based on the mask you define here and the customer number
range maintained at the branch level.
A CIF mask consists of a maximum of 9 digits. The CIF mask could have only numbers or
could be alpha numeric or could also have the branch code as a part of it.
For instance, you can maintain the CIF Mask as ‘bbbnnnnnn’ where ‘bbb’ represents a threedigit branch code and ‘nnnnnn’ represents a 6-digit number.
PID Mask
You can maintain a mask for generation of personal identification number (PID) for customers
of your bank. A PID mask can have a maximum of 15 digits with alphanumeric characters.
You can also have the branch code as a part of it. For instance, you can define PID Mask as
follows:

For modulo 11, bbb nnnnnnnnnnn d

For modulo 97, bbb nnnnnnnnnn dd
Where ‘b’ represents a three-digit Branch Code, ‘n’ represents 10/11 digit number, and
‘d’ represent the check digit.
System automatically generates the PID numbers based on the defined mask and the
preference option selected as ‘Auto Generate PID No’ or ‘Re-Generate Unused PID number
in the ‘Preferences’ tab, system.
PID Checksum Algorithm
Select the checksum algorithm to be associated with the selcted PID mask from the dropdown list. The list displays the following values:

Modulo 11

Modulo 97
For more details on the algorithm types, refer to section ‘Checksum Algorithm’ and ‘Specifying
Customer Account Mask’ of this document.
GL Mask
You can indicate a mask for the general ledgers that are maintained for your bank. The mask
that you define here will be enforced whenever a General Ledger is created in the Chart of
Accounts screen.
2-5
A GL mask can consist of a maximum of nine alphanumeric characters. It can be built using
a combination of numbers and letters to indicate for instance, the category of the GL - asset,
liability etc., the GLs hierarchical position and so on.
Each element used to define the mask would represent a single character. To represent an
alphabet of the English language, indicate “a”. To represent a number, indicate “n”. The last
character would be a D or d, which indicates a check digit generated by the system. For a
numeric check digit define it as‘d’; for an alphanumeric check digit define it as ‘D’.
You may use any of the following punctuation in the GL mask:

dash (-)

comma (,)

asterisk (*)

Full Stop (.)

Forward slash (/)
For example, You wish to create a two level GL structure for your bank. You could define the
first two characters of the GL to represent the category asset, liability etc., aa; the next two
characters, nn, to represent the first level GL; and the next three characters, nnn, to represent
the second level GL. A GL based on the given structure would read as AS01001 where AS
represents the GL category - asset; 01 represents the first level GL; 001 represents the
second level GL.
For creating this structure you would define your GL mask as - aannnnn’d/D’.
If you want to define your second level GL with a 4 digit numeric code instead of 3; other
parameters remaining the same your mask would read as aannnnnn ‘d’/ ‘D’.
2.1.3.2
Indicating Year-end Profit & Loss
General Ledger
At the end of any financial year the balances in the income and expense accounts are posted
by Oracle FLEXCUBE into a separate year-end account for the purpose of consolidation of
balances and turnovers. This account is called the Year End profit and loss General Ledger
Account.
You also specify year-end profit and loss GL for each GL account you maintain in the ‘Chart
of Accounts’ screen. The year-end account specified at the bank level is the default year end
profit and loss GL for all GL accounts maintained in the ‘Chart of Accounts - GL’ screen. If you
do not specify the account to which year end balances of a particular GL should be posted, it
will be posted to the bank’s year-end profit and loss account.
You can select a GL code from the option list of all assets, liabilities, income and expense GLs
maintained in the chart of accounts screen.
Transaction Code
Indicate the transaction code that should be used to post the balances in the income and
expense accounts to the year-end GL account.
You can select a transaction code from the list of transaction codes maintained in the
‘Transaction Code Maintenance’ screen.
Spread
Capture the following details.
2-6
Spread Application
Indicate the transaction legs for which the spread should be applicable. Choose the
appropriate option from the following available in the adjoining drop-down list:

Single Leg

Both Legs
Spool File Purge Days
Specify the duration for which spool files should be stored in the spool file directory.
Interpay Lead Days
Specify the inter-pay lead days required for fetching billing records for inter-pay files for
automatic billing of clients..
Auto Batch
Each time you post journal and multi offset entries, you need to open a batch. You can specify
that the batch numbers of the journal entry batches opened in your bank should be generated
automatically by enabling the Auto Batch option.
Consequently, the system automatically generates batch numbers while posting journal and
multi offset entries.
2.1.4
Placing User Restrictions on Data Entry Batches
You can restrict the usage of batches to specific user by placing bank-wide User level batch
restrictions. If you enable this option as a Bank Parameter, you need to allocate the batch
number range for each user through the ‘Batch Restriction Maintenance’ screen.
The restriction on the usage of batch numbers is made applicable on data entry and PC
transactions. The user will be allowed to enter only those batches reserved for the user profile.
As a result, each time a user specifies a batch number; it will be validated against the
‘Allocated Batch Number Range’.
This feature is applicable only when batch generation is manual. Therefore, if you enable this
option, you must ensure that the Auto Generate option has not been enabled. In a scenario
where the User Restriction for Batch Number field is enabled and Auto Batch option has also
been enabled, the system displays an error message as “Not a Valid Batch Number For the
User”.
In case you choose to auto generate batch numbers, the System will not perform the batch
restriction validation.
2-7
You can invoke the ‘Batch Restrictions Maintenance’ screen by typing ‘STDBRRES’ in the
field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Specify the following details in this screen:

The User Profile for which the restrictions are being maintained. A list of all the User
Profiles with access rights to the DE and PC modules is displayed in the option list. You
can select the appropriate.

The branch of your bank for which the restrictions will be made applicable. You can
either choose a specific branch or make the restriction applicable to ‘All’ the branches
of your bank.

The module for which you are maintaining the Allocated Batch Number Range. This can
either be PC or DE.

The batch number range, which is indicated in terms of Start and End numbers. The
range that you specify is allocated to the user. For distinct numbers, the start number
and end number of the range will be the same.
Note
While processing DE and PC transactions, the batch number specified by the user is validated against the allotted range. If the validation fails, an error message is displayed.
These validations are made applicable even during the Batch Upload operations for the
following functions:
1. Journal Online – Single Entry
2. Multi-offset Entry
3. Teller Transaction Input
SSO Enabled
To enable Single Sign On (SSO) for your installation check the SSO Enabled check box. This
enables restricted login from external systems into Oracle FLEXCUBE.
2-8
General Ledger Purge Days
You can specify here the maximum number of working days, the average GL balance
computation for which is to be retained in the System.
2.1.4.1
Specifying Cheque Numbering Details
Scheme
In Oracle FLEXCUBE, cheque numbers can be generated automatically or can be manually
entered. If you indicate manually, you can draw up numbering conventions and assign
numbers to the cheques that are issued.
Cheque Number Mask
Specify the mask of a cheque number to be used by the bank.You can define numeric cheque
mask as a series of N.
While defining an alpha numeric cheque mask, the alphanumeric character should always
precede the numeric characters. For example: AANNNN, A being alpha numeric character
and N being numeric character. Numeric characters should always follow the alpha numeric
characters.
If cheque numbering scheme is 'Automatic' and checksum algorithm is selected, the 'Cheque
mask' can be defined as only numeric. The cheque mask can contain only 'N' or can start with
a 'T' followed by 'N'. If the cheque mask contains a 'T' in the first position, it indicates that the
cheque is of type EURO or COMMERCIAL. If the mask contains only 'N', then the cheque is
only numeric and cannot be EURO / COMMERCIAL. An appropriate error message is
displayed if cheque numbering scheme is 'Automatic' and cheque number mask defined
contains anything other than 'N' or 'T' in the first position.
If the cheque numbering scheme is ‘Automatic’ and checksum algorithm is selected at bank
parameter, the cheque mask cannot be defined as alpha-numeric. The system validates if the
cheque mask is alphanumeric and inventory is enabled at bank parameter. The system
displays an appropriate error message as ‘Alpha-numeric Cheque number is not supported
as Inventory tracking is enabled’.
Checksum Algorithm
If you choose the automatic generation option you can indicate the algorithm based on which
the check digit should be generated. A cheque number consists of three components:

A check digit

A cheque type

A running serial number
You have the option to choose the algorithm to be used to arrive at the check digit. Currently
Oracle FLEXCUBE supports only the Modulo-7 algorithm. Based on this algorithm the check
type and serial number is divided by seven, and the remainder is taken to be the check digit.
If the remainder is zero, then the check digit is set to seven.
The cheque type indicates whether the cheque is a Euro or Commercial cheque. The numeral
1 before a cheque serial indicates a Euro cheque and 2 indicates a Commercial cheque.
2-9
The cheque serial number is generated sequentially starting from 0001. This running serial
number is assigned taking into account the last check number issued for the account.
Cheque Numbers Unique For Branch
For cheque numbers that are automatically generated, you can choose to make cheque
numbers unique across the branches of your bank.
If you indicate that serial numbers need not be unique, you can have the same cheque
number assigned to cheque leaves of different accounts within a branch. In effect cheque
numbers remain unique to an account.
Lodgment Numbers Unique for Branch
You can indicate whether lodgment leaves must have unique numbers in a branch, or must
be unique for individual accounts.
For example, in the Bank Wide Parameters, you have specified that lodgment book numbers
must be unique for the branch. This means that lodgment numbers need to be unique across
all accounts of that branch. For instance, if a book is maintained with the Start Number as 1,
and containing 25 leaves, you cannot start another book in respect of any other account, with
these numbers.
If you have specified that lodgment book numbers must be unique to accounts in the branch,
and a book is maintained with the Start Number as 1, and containing 25 leaves, you cannot
start another book in respect of the same account, with these numbers. However, you can
start a book with the same numbers in respect of another account in the branch.
2.1.4.2
Specifying TRS Details
You can maintain the following details that will be used by the system to raise direct debit for
Tax Relief at Source (TRS) rebate availed by customers on mortgage loans. The direct debit
is raised during the End of Day (EOD) process after the LD batch processes.
Sort Code
Specify the destination bank code for which the bank raises direct debits for TRS claims.
Account Number
The destination account for which the bank raises direct debits for TRS claims.
Payment & Collection Product Category
Specify the Payments and Collections (PC) product category that would be used by the bank
to raise direct debits for TRS claims.
Suspense Account
Specify the account that would be debited with the TRS amount, to credit customer account.
For more details about processing for TRS, refer the Loans module user manual and the
Payments and Collections user manual.
2.1.4.3
Viewing Trade License Details
Expiry Advice Generation Days
If the trade license is set to expire on a particular date, the number displayed here denotes
the number of days before that date when an advice is generated and sent to the customer
informing about the impending expiration.
2.1.4.4
Specifying Mandatory Limit Tracking For Customer Type
You can maintain limit tracking as a mandatory option based on the customer type.
2-10
Corporate
Check this box if it is mandatory to link customer of Corporate type to credit line.
Bank
Check this box if it is mandatory to link customer of Bank type to credit line.
Individual
Check this box if it is mandatory to link customer of Individual type to credit line.
If a contract is saved without selecting the limit line for customers checked for mandatory limit
tracking, then the system displays the error message as “Limit tracking is mandatory for this
customer <Customer CIF>”.
Note
2.1.4.5
–
By default the customer type is selected as ‘Individual’. However you can modify it.
–
At the customer maintenance level, system defaults ‘Track Limits’ option based on
the option set here.
Loan Automatic Prepayment Details
Automatic Prepayment Transaction Code
A provision has been provided to update the transaction code for automatic prepayment.
Select the transaction code from the adjoining option list. For a retail lending product, if the
automatic prepayment feature is enabled, that is, the automatic prepayment check box is
selected in the Retail Lending Product Maintenance screen (CLDPRMNT), then the system
validates whether a transaction code is maintained for automatic prepayment at the bank
level. If not, then an appropriate error message is displayed
2.1.4.6
Specifying Cheque Discounting Details
Cheque Return Count for Drawer Blacklisting
The system displays the number of cheque returns for a drawer. During the cheque return
processing, the system check the number of cheque returns against this maintenance and
marks the drawer as ‘Blacklisted’ drawer.
2.1.4.7
Specifying Passbook Details
Minimum Number of Digits for Passbook
Specify the minimum number of digits for creating passbook number. The system defaults the
minimum value 10. However you can modify it.
2-11
2.1.5
Specifying UDF Details
You can associate values to all the User Defined fields created and attached to the Bank
Parameters Screen. You can view the list of User Defined fields associated by clicking the
‘Fields’ button. The screen appears as shown below:
You can enter the value for the UDFs listed here in the ‘Value’ column.
For more details on how to create user Defined fields, refer chapter ‘Creating custom fields in
Oracle FLEXCUBE’ in the User Defined Fields User Manual under Modularity.
2.1.6
Specifying Account Generation Parameters at Bank Level
Account numbers in your bank are generated in the format of the account mask that you
specify through the ‘Account Parameters’ sub-screen of the Bank-wide Parameters screen.
2-12
Click ‘Account Mask’ button in the Bank-wide Parameters screen. Account Parameters
screen is displayed. The screen appears as shown below:
Note
Since account level parameters are defined at the bank-level, by default these parameters
will be defaulted to all the branches of your bank. However, individual branches of your
bank will be allowed to change these specifications.
2.1.6.1
Specifying Customer Account Mask
Account numbers can either be generated automatically or you can choose to allocate them
manually. In Oracle FLEXCUBE you have the option of maintaining three types of account
masks.
They are as follows:

Alphanumeric – this type of an account mask is a combination of alphabets and
numbers where you can build the mask with components such as the Branch Code, the
Account Class, the Currency Code, a check digit, etc

Numeric - is a numeric type of account mask where the checksum algorithm associated
with the account mask is either Modulo 11, Modulo 11 with weights or Modulo 97.

Pure Numeric – is a numeric type of account mask, which does not have a checksum
algorithm, associated with it. If you are maintaining a pure numeric mask you have to
identify the start and end account number which is to be associated with it.
2-13
Alphanumeric customer account masks
The alphanumeric customer account mask can have a maximum of twenty alphanumeric
characters. It can comprise of one or more of the following elements in combination:

Account Class — Use “ACLASS” to indicate that the account class to which the
account belongs should be part of the mask.

CIF Number — You can incorporate the nine-character CIF code assigned to the
customer into the mask. To do so indicate ‘CIF Number’ in the mask.

Currency — To add the currency of the customer account, use ’CCY’

To indicate an alphabet or number — Each element used to define the mask would
represent a single character. To represent an alphabet of the English language, indicate
“a”. To represent a number, indicate “n”.

Punctuation Marks — When defining the customer account mask you have the option
of separating the elements. To do this, you may use the following punctuation marks:
–
Dash (-)
–
Comma (,)
–
Asterisk (*)
–
Full stop (.)
–
Forward slash (/)
For Check Digit - The last character in the customer account mask should always be a ‘D’ or
‘d’. This indicates the check digit, which is generated by the system. When specified in the
mask, the check digit component is generated using either of the following methods:
–
Modulo 11
–
Modulo 97
–
Modulo 11 without Weights
–
User Defined Algorithm
If you choose Modulo 97, all components of the account mask (for example, the Branch Code,
the Account Class, the CIF ID, etc.) should be numeric. For example, if you enter ‘bbb’ in the
account mask field (indicating that the branch code should be part of the account number),
and choose the Modulo 97 option, ensure that the branch code is a numeric value, such as
‘000’, ‘123’, etc.
Note
The maximum length of twenty characters for the customer account mask is inclusive of
the check digit
All customer accounts that are entered in any branch of your bank will compulsorily have to
conform to the mask.
For example, you want the following elements to be part of the customer account mask:
The currency of the account
The nature of the account (savings, current etc.) and
The Customer Id
Given the above criteria the customer account mask would be:
ACLASSCCYCIFNUMBERn’D’
2-14
This corresponds to:
LLLLL$$$CCCCCCCnD
All customer accounts entered in any branch of your bank would now comprise of these
elements, in the order defined in the mask.
A customer with CIF number 10005 has opened his first USD savings account with your bank,
and the Account class for savings accounts is INDSB. His account number would read:
INDSB-USD-10005-1’D’
Similarly, the second GBP current account of a corporate customer with CIF Number 20005,
would read
CUCOR-GBP-20005-2’D’
'CUCOR' being the account class representing current accounts of corporate customers.
Characters Supported for Various Fields in Account Mask:
Field
Mask character
Max length
supported
Account class code
L
6
Account code
T
4
Currency code
$
3
Currency type
Z
3
Customer number
C
9
Branch code
b
3
Serial Number
S
-
Numeric value(user
to input)
n
-
Alphabet value(user
to input)
a
-
UDF
U
-
Note
You must specify the mask character in the same case as mentioned above.
Field
Case 1
Case 2
Case3
Case4
CIF number
015005624
015005624
015005624
015005624
Currency
code
GBP
GBP
GBP
YUV
Currency
type
O
O
O
YA1
2-15
Field
Case 1
Case 2
Case3
Case4
Account
class
SAVINV
CACIN
123456
SAVINV
Account
code
SA12
SA12
8909
SA12
Branch code
014
015
015
015
Mask maintained
Booked against
Chk sum
Algorithm
Generated
Account Number
LLLLLL$$$CCCC
CCCCSSd
Case 1
Modulo 11
SAVINVGBP15005624019
LLLL$$$TTCCCC
CCCCSSd
Case 1
Modulo 11
SAVIGBPSA15005624028
LLLLLL$$$ZZCCC
CCCnnd
Case 2
Modulo 11
CACINGBPO005624997
nnnnnnnD
Case 1
Modulo 11
09888994
bbbbLLLZZZZCCCCC
nnd
Case 4
Modulo 11
015SAVYA105624
074
LLLLLL$$$CCCC
CCCSSDD
Case 1 / 2
Modulo 97
Error. Will not be
able to generate
the check digit.
The control digits
value must be
numeric for Modulo 97.
LLLLLLTTTTTCCCCCSSD
D
Case 3
Modulo 97
123456890900562
40150
Customer Account Number Containing a UDF Value
While defining a customer account if you include ‘U’ in the account mask, it indicates that the
customer account numbers will have the value of a user-defined field.
The number of U’s will depend on the length of the UDF value that has to be included in the
customer account number. For example, if you want to include 3 characters from a UDF, the
account mask should consist of UUU (in addition to other parameters which you want to
include in the customer account numbers).
Note
–
A user-defined field can be part of the customer account mask only if the customer
account number generation is not automatic.
2-16
–
Since a customer account number in Oracle FLEXCUBE can accommodate only up
to 20 characters you have to ensure that the account mask you have defined does
not exceed this number.
Numeric Account Masks with Modulo 11 and Modulo 97 as Checksum Algorithms
A numeric type of mask can have a maximum of fifteen numeric characters, inclusive of the
checksum algorithm.
If you associate Modulo 11, as the checksum algorithm, a single character D will be appended
to the numeric mask. Let us assume that you have an account mask with five numeric values
– ‘nnnnn’ and associated Modulo 11 as the checksum algorithm. The system automatically
appends ‘D’ to the numeric mask. The generated account numbers will have the following
format – nnnnnD.
If the Account mask is Alphanumeric, and check sum digit is needed as per Modulo 11, then
the check digit- 'd' has to be manually specified in the mask. For example, if you need an
account mask as 'bbbCCCCCCSS', then considering Modulo 11 check sum digit, you need
to input the mask as 'bbbCCCCCCSSd'.
Similarly, if you associate Modulo 97, with an account mask of five numeric values, the system
appends a double-digit value of DD to the mask. The generated accounts will have the
following format – nnnnnDD
Note
As system automatically appends DD in case of Modulo 97, if you input the customer mask
with 'D', system will display the error message as 'Cannot have D denoting Alphanumeric
Characters'.
if you input 'dd' in the mask, then system displays the error message as 'Cannot have dd
denoting Alphanumeric Characters in account mask while using mod11 Checksum algorithm'.
System automatically appends DD always at the end of the Mask.
Contents of
the mask
Check sum
digit
Check digit
character
Modulo 11
Alphanumeric
User to input
d
Check digit
should be
specified
manually in
the mask
Modulo 11
Numeric
Auto append
D
System
appends the
check digit
automatically, however, the
mask characters
should be 'n'
for example,
nnnnD
Algorithm
2-17
Remarks
Contents of
the mask
Check sum
digit
Check digit
character
Modulo 97
Alphanumeric
Auto append
DD
If the values
for the mask
are alphanumeric, then
check digit
will not be
generated
Modulo 97
Numeric
Auto append
DD
-
Algorithm
Remarks
wing format
– nnnnnDD.
Numeric Account Masks with ‘Modulo 11 with Weights’ as Checksum Algorithm
The account mask with ‘Modulo 11 with Weights’ algorithm can have a maximum of 13 digits.
It comprises of the following elements:

Branch Code (3 digits) – Indicates the branch at which the customer account is
maintained.

Account Code (1 digit) – This will indicate the account code of the account class to which
the customer account belongs. During account number generation (in the Customer
Account Maintenance screen), you need to select the account class from the option-list
provided. The system will then convert it to the account code maintained for that account
class. The account code thus becomes a part of the customer account number.

Currency Type (1 digit) – This will represent the currency type of the account currency.
As explained for account code, you will select a 3-digit currency code during account
generation. The system will convert it to the currency type maintained for that currency.
The currency type will then form a part of the account mask.

CIF Number – You can also include the CIF number of the customer as part of the
account mask. The CIF number is automatically generated by the system when you
capture customer details in the Customer Information Maintenance screen. During
customer account maintenance, you can select the CIF number from the option list
provided.
Sequence Number (1 digit) – The sequence number is automatically generated by the system
for a combination of account code + currency type + customer. This means that, for this
combination, you can maintain nine accounts. To maintain the 10th account for the same
combination, the system will use the ‘Dummy Customer No. Range’ maintained at the branch
level’.
Refer the section titled ‘Creating Branches’ of this document for more details on dummy
number range.

Control Number (1 digit) - This is the 13th digit of the account number. This number is
also automatically generated by the system based on the ‘Modulo 11 with Weights’
algorithm.
For the above combination, the customer account mask would be:
‘bbbTZCCCCCCSd’
Where,

bbb – is the branch code

T – indicates the account code
2-18

Z – is the currency type

CCCCCC – is the CIF number of the customer

S – is the sequence number for a combination of account code, currency type and
customer

d – is the control number generated by ‘Modulo 11 with Weights’ algorithm
The following example illustrates the manner in which the system calculates the 13th digit for
a customer account number using the ‘Modulo 11 with Weights’ algorithm.
Assume that the account number of a customer is ‘000-4-1-123456-1’. As per this algorithm,
the value of each position (1 to 12) is multiplied with the weight for each position (the weights
are provided by your bank). Further, the sum of the product obtained is divided by 11. The
remainder of the division will determine the value of the 13th digit.
The position-wise weight and account number and the product (of weight and number) is as
follows:
Position
1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
Weight (W)
2
4
8
5
10
9
7
3
6
2
3
5
Acct. No (N)
0
0
0
1
2
3
4
5
6
4
1
1
Product (W * N)
0
0
0
5
20
27
28
15
36
8
3
5
Sum of the product = 147.
Divide the value 147 by 11 to obtain the remainder
Remainder = (147/11) = 4
As per this algorithm, if the remainder is 10, then the control number will be zero. If it is any
value other than 10, the remainder itself will be taken as the control number.
Therefore, the 13th digit = 4.
The customer account number will now read as ‘000-4-1-123456-1-4’
Numeric Account Masks with User Defined Algorithms as Checksum Algorithm
If the check digit component within a Customer Account Number is to be generated using a
method of your choice you must identify the following:

The User Defined Algorithm for the Customer Account Number – this identifies the
name of the user-defined algorithm for check digit generation of account numbers.

The User Defined Algorithm for Consumer Number – this stores the name of the userdefined algorithm for validating consumer numbers.
While capturing Customer Account numbers, the System checks for your specification for the
checksum algorithm. If you have selected User Defined, the check digit is generated using the
specified user-defined algorithm.

Unused sequence numbers of CASA cannot be tracked for re-use if the sequence
number is generated by user defined algorithm
Since these parameters are maintained for your bank, they are defaulted to the branches of
your bank. You will not be allowed to change these for a specific branch of your bank.
2-19
Note
Unused sequence numbers of CASA can be tracked for re-use only if the customer account mask contains numeric mask.

If the account mask contains any of the following characters, the lost account number
is re-used only if the same customer opens another account with the same branch code,
account class, currency & sequence number combination:

C(Customer number)

b(Branch)

T(Account class)

Z(Currency)

S(Single digit sequence number)

SS(Double digit sequence number)

Unused customer account number is reused in the same day, except in the following
scenarios:


Session termination for the current user
Multiple windows opened for the same Function ID by the current user.
Pure Numeric Masks
A numeric account mask, which does not have a checksum algorithm associated with it, is
called a pure numeric mask. Since it does not have a checksum algorithm associated with it
you will have to specify the start and end account numbers and enable the auto-generated
option.
The start account number forms the basis on which customer accounts numbers are to be
generated. Similarly, you will not be allowed to maintain account numbers beyond the end
account number.
Let us assume, that you are have maintained the following details in the Account Parameters
screen at your bank:
Customer Account Mask
nnnnn
Start Account Number
1
End Account Number
50000
Cust Accunt Auto Generate
Yes
While generating a new account number the system will automatically generate 00001
corresponding to nnnnn. The next account will be – 00002.
Note
'n' is allowed in the account mask, only if auto account number generation is selected at
branch level.
Including Value of a UDF as Part of Customer Account Number
If your bank has not opted for automatic generation of account numbers, you can specify a
structure for customer account numbers. The structure can be a combination of CIF number,
account class, value of a user defined field, currency, branch code, alphabets/numeric and a
check digit which is automatically generated by the system.
2-20
For example, an account mask is CCCCCCCLLbbbUUU$$$ad.
This implies that a customer account number will contain:
CIF Id – represented by C
Account Class represented by L
Branch Code represented by b
Values of a user defined field represented by U
Any user-input alphabet represented by a (enter ‘n’ if you want to include a numeric)
Currency Code represented by $$$
A check digit (which is automatically generated by the system) represented by ‘d’
Note
The number of C’s in the account mask should match with the CIF mask that you have
specified. For instance, if the CIF mask is aaaannn (7characters), the account mask
should consist 7 C’s to include the CIF Id in the customer account number.
The value of a user-defined field can be used to include an additional parameter (for example:
the code of the country to which the customer belongs) in the customer account number.
The steps involved for including the value of a user-defined field in a customer account
number are as follows:
1. Include ‘U’ in the customer account mask to indicate that the customer account number
should contain the value of a UDF
2. Create a new user defined field
3. Link it to the Function Id STDCIF
4. Specify the value of the user defined field at the time of creating a customer
5. Specify the UDF whose value has to be included in the customer account number to the
Oracle FLEXCUBE implementer. The implementer will indicate this at the back end.
Maintaining Ten Digit Masks with Running Sequence Numbers
You can maintain a 10-digit mask of any combination, wherein the last two digits will
necessarily be a running sequence number. This number will be automatically generated by
the system. For instance, if you want to maintain a mask for the customer number and
currency combination followed by the two digit running number, you will have to maintain the
mask as CCCCC$$$SS. Here, CCCCC stands for the customer number, $$$ stands for the
currency of the account and SS stands for the running number. The system will generate the
last two-digit number in a continuous sequence irrespective of the combination that you
specify in the mask.
For example, let us assume that you want the customer account number to be a combination
of the customer number and the account currency followed by the serial number. To achieve
this, you have to specify the mask as CCCCC$$$SS. Based on this mask, for a customer with
CIF ID 40207 with account in USD, the account number will be 40207USD01. If the same
customer has another account in GBP, the next account number would be 40207GBP02. That
is, there will not be any holes in the system generated running number.
2-21
2.1.6.2
Specifying Multicurrency Account
Multicurrency Account Mask
Specify the multi-currency account mask. The system supports 15 characters of PID number
as Multicurrency Account Mask. If lesser number of digits are considered from PID mask, then
the system considers the last set of digits. In case the PID digit is less than the mask defined
then it should be prefixed by '0'.
Multicurrency Checksum Algorithm
Select the checksum algorithm details from the adjoining drop-down list. This list displays the
following values:

Modulo 11

Modulo 97

Modulo 11 with weights

Modulo 10

User Defined
Multicurrency Account Algorithm
Specify the multi-currency account algorithm details.
Start Multicurrency Account Number
Specify the start number for multi-currency accounts.
End Multicurrency Account Number
Specify the end number for multi-currency accounts.
Auto Generate Multicurrency Account
Check this box to generate unique multi-currency accounts automatically.
If this box is unchecked, then you need to specify the account number details for each
currency while creating an account.
The 1st account opened (through account maintenance screens or through Gateway) should
remain in ‘Active’ state. You cannot open accounts in different branch using multi currency
account class for the same customer. The Account Branch number for all the assigned CASA
accounts will be same as that of the 1st account (LCY) created.
The system will check if the 1st account opened under the Multicurrency Account Class is in
LCY (Branch Account Currency).
On initiation of a transaction, the system will automatically create the account and post the
transaction for inactive accounts.
At the time of account creation, system will replicate the following data maintained for the 1st
account/ LCY account to the automatically created account:

Account Description

Account Type

Mode of Operation

Account Open Date

Address

Location

Media

IC special condition
2-22

Instructions

Restrictions MIS

Joint Holders

Linked Entities

Account Status

Statement

Account signatory, only if 'Replicated Customer Signature' is selected during manual
account creation.
In case, if the transaction is reversed, the system will not roll back the account opening/
creation process.
In case if the first account opening (manual) fails due to any reason, for instance, Failure of
Initial funds, the entire process of account opening will be rolled back.
The system will validate that for a customer and currency combination, there should be only
one account under the multicurrency account class. The system will perform this validation at
both account creation and at account authorization level.
The system will validate for the following 'Account Class' level validations during account
creation for assigned CASA account numbers/ Inactive accounts:

Initial Funding

Currency restrictions

Debit Card Request

Cheque Book Request

Restrictions - Defaulted data will be removed automatically for Inactive Accounts since
‘Special Condition’ is ‘NA’, by default
Note
Following data will not be captured for Inactive accounts:
The sub sections such as, Limits, Deposit Instructions, Debit Card Request, Sweep in Setup, Instructions, BIC, Interim Transactions Report, Standing Instructions, Billing Parameters Documents, Restrictions and Cheque Book Request
Intermediary Details in ‘Auxiliary’ tab
The system will maintain Interest/Charge calculation and application, account statement and
passbook separately for each account. Also, all the account activities in the entire life cycle of
an account till the closure date will be maintained separately.

In case if the account class is modified at a later stage, i.e., increase in the number of
allowed currencies, then,
–
For customers with a multicurrency account, the bank should open the accounts in
new currency, if required, provided the customer has LCY account opened in the
multicurrency account class. Newly added accounts should be in active status and
it should be mapped to the existing Multi-currency Account number of the customer
and account class combination. In case if a customer does not have an LCY
account opened, then the system will perform the validation to open an LCY
account
–
In case if new multicurrency accounts are opened, the system will assign the
account number for newly added currency under account class.
2-23

In case if the account class is modified at a later stage, i.e.,decrease in the number of
allowed currencies, then,
–
For customers with a multicurrency account, the assigned accounts will be opened
even if those currency details are removed at account class level. The system will
not validate against currency restriction maintained at account class level.
–
In case if new multicurrency accounts are opened, the system will assign the
account number for newly added currency under account class.
The assigned CASA account numbers will be available for the following screens:

360 Degree Retail Customer View (STDRETVW)

360 Degree Corporate Customer View (STDCUSVW)
The system will display the assigned CASA account number as a part of TD account opening
and redemption for the following screens:

Term Deposit Payout Details

Term Deposit Payout

ICDREDMN
The system will display the assigned CASA account number as a part of Teller transaction for
the following screens:

1401

1006

8207
In case if the transaction is deleted before authorization or reversed after authorization, the
account will remain in active state.
Note
Multicurrency Account Class cannot be closed unless all the accounts under the same is
closed first. Also at any given point of time there can be only one active ‘Multicurrency Account Class’.
The system should not allow an account to be transferred from multicurrency account
class to a non multicurrency account class and vice versa.
Customer Aggregation cannot be initiated from customer who has a multicurrency account
to a customer who also holds a multicurrency account.
2.1.6.3
Specifying Auto Account Creation Parameters
You may wish the system to automatically create current accounts for customers at the time
of loan initiation. These system-created current accounts are for use as settlement accounts.
Here, you need to specify the range of numbers available for such auto created accounts by
mentioning a start and an end number.
If you wish to retain the facility of auto creation of current accounts at loan initiation, you will
have to ensure that the account number mask does not have any user input character.
2-24
2.1.7
Maintaining Zengin Characters
You can maintain Zengin characters by clicking on ‘Zengin Characters’ button in ‘Bank
Parameters’ screen.
You can specify the following details:
Type of Character
Select the type of character from the adjoining drop-down list. This list displays the following
values:

English

Numbers

Katakana

Special Characters
You can select any one type of characters and add multiple allowed characters in the ‘Allowed
Characters’ field.
A character can be entered only once, if the same character is entered twice, then the system
will display the following error message:
Duplicate Value X
For instance, if you have selected ‘Type of Character’ as ‘English’ and if you try to enter the
value ‘A’ twice in the ‘Allowed Character’ field, then the system will display the following error
message:
Duplicate Value A
Also, you can enter multiple characters in the same field. For instance, if you have chosen
‘Type of Character’ as ‘English’, then you can enter ABCE….Z (A to Z) in a single ‘Allow
Character’ field
A type of character can be selected only once, if duplicate value has been selected for the
same then system will display the following error message:
Type of Character Cannot be Duplicate
2-25
Note
When the “Type of Character” is chosen as English, the character entered in the
“Allowed Characters” field will be validated against English capital (A to Z) & English
small (a to z).
When the “Type of Character” is chosen as Numbers, the character entered in the
“Allowed Characters” field will be validated against the numbers (0 to 9).
Ensuring whether the right value that is entered into the right type of character for special
characters and Katakana scripts need to be controlled operationally.
Allowed Characters
Specify the number of Zengin characters allowed.
If an allowed character is deleted at any point in time, then the deleted character will be
restricted for new customer creation and modification of existing customers.
The system performs the following validations against Zengin characters set during customer
creation/modification:
During customer creation or modification in STDCIF/STDCIFAD screens, the values entered
in Full Name, First Name and Middle Name needs to be validated against each character set
maintained at STDBNKPM level. If a character entered in the above mentioned fields is not
maintained in STDBNKPM screen then the system will display the following error message:
Character X is not Allowed
During customer creation or modification in STDCIF/STDCIFAD screens, the values entered
in Full Name’ field in ‘Katakana’ script Name needs to be validated against each character set
maintained at STDBNKPM level. If a character is entered in the ‘Full Name’ field in Katakana
scripts and not maintained in STDBNKPM screen then system will display the following error
message
Character X is not Allowed
During creation or modification of multiple names in Customer Name in STDCIFNM screen to
be validated against the character set maintained at STDBNKPM level.
When an incoming Zengin message has been received, the beneficiary name available in that
message needs to be validated against the following values.

Full Name, Middle Name and Last Name fields in STDCIF.

Full Name field in Katakana scripts in STDCIF.

Multiple Names maintained in Customer Name field in STDCIFNM.
When the RT web service is consumed by the channels and if the value has been provided
the Zengin Transaction and Beneficiary Name fields then the Beneficiary Name will be
validated against the following values.

Full Name, Middle Name and Last Name fields in STDCIF.

Full Name field in Katakana scripts in STDCIF

Multiple Names maintained in Customer Name field in STDCIFNM.
If the Beneficiary name exactly matches with any of the above mentioned values then the
transaction will be processed otherwise it will be rejected.
2-26
2.1.8
Defining Bank-wide Preferences
In the Bank-Wide Preferences screen, you can specify the following:

The route of inter-branch accounting — through HO, through RO or directly between
branches

Exchange rate preferences — to be maintained for the bank as a whole or at each
branch

Preference relating to update of GL balances — on-line or at the End of day

Preference relating to Position Accounting

Interface details
Click the ‘Preferences’ button to invoke the ‘Preferences’ screen.
Interface Details
Specify the following details:
Journal Account
Specify Journal Account of the Interface details
Width
Specify width of the interface.
Emperor’s Coronation Date
Specify the date of coronation of the current emperor.
Inter Branch Scheme
Indicate the following details.
Inter Branch Account Schedule
You can indicate the route through which accounting entries for inter-branch transactions
should be settled. You can select one of the following routes from the option list that is
available:
2-27

Choose ‘Through HO’ to indicate that inter-branch transactions should be settled
through the Head Office

If you specify ‘Through RO’ the accounting entries would be routed through the regional
office. If two branches involved in a transaction do not report to a common regional
office, the accounting entry would be routed through the HO

If you specify ‘Direct’, each branch would have a direct accounting relationship with
every other branch
The receivable and payable accounts between the branches, referred to as ‘due from’ and
‘due to’ accounts, are maintained in the ‘Inter-branch parameters’ screen.
For example, suppose the University Savings Bank has the following set up for its head office
and branches in Headington, Oxford:
Roosevelt Avenue Branch, is the HO with Branch Code 000
Foxlake Drive Branch (Branch Code 001)
Mountainwood Road branch (Branch Code 002)
You have indicated that inter-branch transactions should be routed through the Head Office.
Ms. Tanya Agnihotri has an account in Branch 002. She makes a cash withdrawal from
Branch 001. This being an inter-branch transaction, Branch 001 will have to recover the
money from Branch 002.
In this example the following movement of funds is involved:

At Branch 001, the cash account is credited for the transaction amount and due from
Head Office account debited.

At Branch 000, the due from Branch 002 is debited and the due to Branch 001 is
credited.

At Branch 002, the Customer Account is debited and the due to Head Office account
credited
Inter Branch Entity
Oracle FLEXCUBE allows you to post accounting entries related to inter-branch transactions
to either of the following:

Customer Accounts

General Ledgers

Both
If you select Customer Accounts as an inter-branch entity, you can specify the currency and
the actual customer accounts involved in an inter-branch transaction between two branches
of your bank. If the inter-branch entity is specified as ‘General Ledgers’, you need to specify
the internal accounts that would be involved in a transaction between two different branches
of your bank. If you select ‘Both’ option, it indicates that inter branch accounting entries could
be posted for both GL and Customer accounts.
Fund Inter Branch Scheme
Indicate the following details.
Inter Branch Account Schedule
You can indicate the route through which accounting entries for inter-branch fund transactions
should be settled. You can select one of the following routes from the option list that is
available:
2-28

Choose ‘Normal’ to indicate the inter-branch routing defined for corporate transactions
will be applicable to the inter-branch fund transactions as well.

Choose ‘Through HO’ to indicate inter-branch transactions should be settled through
the Head Office.

If you specify ‘Through RO’ the accounting entries would be routed through the regional
office. If two branches involved in a transaction do not report to a common regional
office, the accounting entry would be routed through the HO.

If you specify ‘Through RO and HO’, the accounting entries would be routed through the
Regional Office of the first branch, then the Head Office. From the Head Office, the
entries would be routed through the Regional Office of the second branch.

If you specify ‘Direct’, each branch would have a direct accounting relationship with
every other branch.
The receivable and payable accounts between the branches, referred to as due from and
due to accounts, are maintained in the ‘Inter-branch parameters’ screen.
Inter Branch entity
Oracle FLEXCUBE allows you to post accounting entries related to inter-branch fund
transactions to a General Ledger that you have specified.
If you choose ‘Normal’ as the inter-branch routing, and you have not selected the option
‘Allow Corporate Access’ in the Branch Parameters screen, the Inter Branch transfer options
you have chosen will be used.
If you have selected the option ‘Allow Corporate Access’ in the Branch Parameters screen
and the branch is a fund branch, the entity will be defaulted as General Ledger. The GL will
be based on the maintenance you have carried out in the Fund Inter Branch Accounts
Maintenance screen, for the fund id. The same is explained in the chapter Accounts for
Inter-branch transactions.
Online GL Updates
The update of GL balances can take place either on-line or during End of Day. For an on-line
update select this checkbox.
Re-generate unused CIF ID
Check this box to indicate that the unused CIF ID needs to be re-generated automatically.
Note
Unused sequence number’s of CIF is tracked for re-use only in the following scenarios:
–
If the user cancels without saving new customer maintenance.
–
If the user deletes a new customer before authorizing it.
–
Unused customer account is regenerated on next day post cancelling or deleting.
Re-generate unused CASA no
Check this box to indicate that the unused CASA number needs to be re-generated
automatically.
Note
Unused sequence number’s of CASA is tracked for re-use only in the following scenarios:
–
If the user cancels without saving a new CASA maintenance.
–
If the user deletes a new CASA before authorizing it.
2-29
–
The sequence numbers marked during delete operation is re-used in ascending order. The sequence numbers marked during cancel operation is reused only from
next working day to prevent concurrency issues.
Auto Generate PID No
Check this box to automatically generate PID No.
Auto- Generate CIF Numbers
This indicates whether or not the CIF should be generated automatically. Check this box to
indicate the CIF number needs to be generated automatically.
Note
Unused sequence number’s of CIF is tracked for re-use only if the CIF is generated automatically.
Re-generate Unused PID No
Check this box to automatically re-generate unused PID numbers.
Re-Generate unused Multi-currency Account No
Check this box to automatically re-generate unused multi-currency account number.
Use Head Office Exchange Rates
Exchange rates are maintained for a currency pair and are used to calculate the equivalent of
one currency against the other. These exchange rates can be maintained in each branch or
at the Head office. You can indicate your preference.
If you check against the option ‘Use Head Office Exchange Rates’ the exchange rates
maintained at the Head Office will be made applicable to all branches of the bank. Leave it
unchecked to indicate that exchange rates should be maintained at each branch.
This value is used to inherit the USE HO EXCHANGE RATE field at branch param level.
Position Accounting Required
You can retrieve the position of a foreign currency, any time, by opting for position accounting
in your bank. When you opt for position accounting, you maintain a Position GL and a Position
Equivalent GL for every foreign currency maintained in your bank. The Position GL reflects
the current position of the currency.
If you opt for position accounting while defining Bank-Wide Parameters, you have to maintain
Position GLs and Position Equivalent GLs for every foreign currency that your bank deals in.
When maintaining GLs for your bank, you can opt to link the different currencies, associated
with the GL to either of the following:

The Position GLs that you have specified for the currency (Your specifications in the
Currency Definition screen will default here)

Position GLs of your choice
Daily MIS Refinancing
As part of setting up the bank level preferences you can indicate whether MIS refinancing
processing is required on a daily basis for the particular branch of your bank.
If you indicate that MIS refinancing should be done on a daily basis, refinance processing will
be done on a daily basis for the following modules:

Loans and Deposits

Money Market
2-30
Note
You can indicate the rate type that is to be used for individual LD, and MM transactions
while processing the contract.
Propagate Floating Rates to Branches
You have to indicate whether the floating rates maintained at the head-office of your bank
should be propagated across all the branches of your bank.
Check the box positioned next to this field to indicate that floating rates need to be propagated
across branches. Consequently, each time you maintain a floating rate for a particular rate
code and currency combination at your bank, a corresponding floating rate record will be
created and sent to all the branches of your bank.
Limits History Required
You can indicate whether date-wise limits history needs to be maintained for the Bank. If you
choose to enable this option, the limits history is maintained at the following levels:

Liability level history for storing liability records

Limit level history for storing Lines records

Line level history for storing Line Utilization records
Conditions for collating Limits History data:

There is no retrospective effect on limits history.
–
Back-valued contracts and account transactions do not result in any adjustment to
the previous records in the history. Such transactions are inserted with the current
EOD date. Similarly any future-dated contracts and account transactions are also
inserted with the current EOD dates.
–
In cases where the main line is changed to a sub line, the utilization is transferred
from the old main line to the new main line and the effect cascades to the ultimate
parent line. But existing records are not changed or updated.
–
Existing data will not reflect the change in the liability number for a customer.

Revaluation has no effect on the limits history data

Limits history is not maintained country-wise
The data is archived during the EOD processing. The history data is not updated for holidays.
Note
If there is no change for a liability/limit/line, data is not archived for that day.
Note
This option can be enabled or disabled at any point of time. Limits history will be recorded
with effect from the day the option is enabled. Disabling the option will however not automatically purge history data.
You have the option of querying Liability history and drilling down to Limits Line history and
further drilling down to Contract-wise Utilization history. Clean risk data is displayed only as
of the date of query and history for the same is not maintained.
2-31
Branch wise Limits
This option indicates whether or not the limits tracking must be done at the branch level. If this
box is checked, you will be allowed to view/change only the lines created from that branch for
a given liability.
To illustrate, if you open any credit line facility in branch BR1, then in the Limit Restriction
screen, the only branch available will be BR1.
Checking this option will also allow you to View details of line utilization at the branch level in
the Limits Query screen.
For a total utilization of a global customer maintained in HO, you would have to generate a
report of the limit utilization for each instance.
Pairwise Positioning Required
You have to select this option to indicate whether pair wise positioning entries need to be
stored/handed off or not. If selected, the system will store position creating pair entries
separately for handoff to other external systems.
When processing accounting entries, the system will check whether you have opted for pair
wise positioning. If you opt for this option, the system will check for the following conditions in
all the accounting entries that are posted:

The set of entries posted are balanced i.e. total LCY debit is equal to total LCY credit

At least one pair of accounting entry is in FCY

Both the currencies are not the same
If the above conditions hold true, the system will store the entries along with the following
information:

Dr. Account: indicates the debit leg’s account GL

Cr. Account: indicates credit leg’s account GL

Event Code: is the event of the transaction

Dr CCY/Bought Currency

Dr. Amount/Bought Amount

Cr. CCY/Sold Currency

Cr. Amount/Sold Amount

Dr Booking Date/Cr Booking Date

Dr Value Date/ Cr Value Date

Dr Transaction Code/Cr Transaction Code

Exchange Rate

Hand Off Flag
Note
While passing pair wise position entries, the main component will be passed with
TRF_AMT tag and the equivalent entry will be passed with the AMT_EQUIV tag.
In case of accruals/revaluation also, if position entries are created, the corresponding entries
will be stored separately for hand off.
2-32
Note
Pair-wise Positioning Required will decide whether position creating pair entries need to
be stored by the accounting processor separately for handing off to other system.
Period for Customer Names (in Days)
Specify the total number of days during which multiple customer names are valid in the
system.
This field will take only positive integer values up to 5 digits. If the Period for customer names
field is not positive, then the system will display an error message.
Note
–
Period for Customer Names (in Days) field can be modified at any time. When
multiple customer names are added in the account level, this value is used in the
default population of ‘Valid Till Date’ field in the STDCIFNT screen.
–
When Period for Customer Names (in Days) field is left blank, then the ‘Valid Till
Date’ field in the STDCIFNT screen will also be blank and the name will remain valid
indefinitely.
Propagate CIF to other Nodes
You need to indicate whether or not the CIF number maintained in HO has to be propagated
to other branches present in different instances. Check this box to indicate the CIF number
has to be propagated to other Nodes/instances.
Propagate Customer Addresses to Nodes
You need to indicate whether or not the customer addresses maintained in HO has to be
propagated to other branches present in different instances. Check this box to indicate the
Customer addresses has to be propagated to other Nodes/instances.
Propagate Bank Instruction Codes Details to Nodes
This indicates whether or not the BIC data maintained in HO has to be propagated to other
branches present in different instances. Check this box to propagate BIC details.
Maintenance of Customer Identification Mask at Branch/Node level
This option gives you the flexibility to define different CIF masks at the Nodes/Bank level. If
you select ‘Bank’ from the option list, then the CIF mask given at Bank level will be applied to
all the branches under it.
Mudarabah Fund Shareholder Balance Type
Specify whether the system should consider the month-end balance or the monthly average
balance of the GL to compute the shareholders’ investment in the linked Mudarabah fund.
Choose from the following options available in the drop-down list:

Monthly Average Balance

Month End Balance
The option specified here will be common to all the shareholder GLs identified under the
Mudarabah fund and once Mudarabah fund shareholder balance type is input and authorized,
it will not be allowed to modify later.
Customer Service Model Effective Month
The system displays the month in YYMM format. The customer service model effective month
will be the application date month.
2-33
Staff Account Restriction Required
Check this option to apply staff account restriction at the bank level.
Auto Account Closure
Check this box to enable Account Auto Closure functionality.
If you select ‘Node’ from the option list, you will need to maintain CIF masks at the Node level
in the ‘Node-wise CIF Mask Maintenance’ screen. This would ensure that the branches
maintained in different nodes/instances have different CIF masks.
Click ‘Nodewise CIF mask Maintenance’ button to access this screen. The screen appears as
shown below:
You can specify the following details here:
Nodes
This indicates the node/instance for which the CIF mask is required. Select a node from the
option list provided.
Customer Identification File Mask
This indicates the CIF mask for the corresponding instance/node. Select a CIF mask from the
option list provided.
Autogenerate Customer Identification File Number
This indicates whether or not the CIF should be generated automatically. Check this box to
indicate the CIF number needs to be generated automatically.
Allow Inventory Tracking
You can use this check box to allow/disallow inventory management and tracking. To use
inventory management module, check this box.
Note
If inventory tracking is allowed then ‘Cheque Numbering Scheme’ should be left blank/null.
For more details on Inventory Tracking, refer the Instruments Inventory Tracking User
Manual.
2-34
2.1.9
Maintaining FATCA Preferences
In this screen, you can maintain the details regarding the banks' own FATCA classification.
You mainly need to maintain the details in the following screen to identify:

If FATCA is applicable to the bank

The banks' own FATCA classification

The banks' IRS issued EIN as well as its issue and expiry date
You can maintain these details by clicking the 'FATCA' tab. The screen appears as shown
below:
FATCA Applicable
Check this box to indicate that the FATCA rules are applicable to the bank.
Banks FATCA Classification
FATCA Classification
Specify the bank's own FATCA classification. The adjoining option list displays the all the
allowed classifications maintained for customer type bank using the 'Customer Type-Wise
FATCA Parameters' screen.
Employer Identification No. (EIN)
Specify the employer identification number (EIN) issued to the bank by IRS.
Note
All the statuses do not require employer identification number (EIN).
2-35
Issue Date/Date of Agreement
Specify the date on which the employer identification number (EIN) was issued by IRS; or the
date on which the bank entered into an agreement with IRS.
Expiry Date/Date of Revalidation
Some classification requires revalidation of employer identification number (EIN) periodically.
Specify the date on which the EIN is to be revalidated.
GIIN
Specify the global Intermediary Identification number issued to the bank by the IRS.
Remarks
Provide any remarks, comments or observations regarding the Bank's FATCA Classification.
2.2
Maintaining Product Groups
For maintaining product groups, you can invoke the ‘Product Group Maintenance’ screen. To
invoke this screen type STDPRGRT' in the field at the top right corner of the Application tool
bar and click on the adjoining arrow button.
Specify the following details in this screen:
Group ID
Specify a group ID for the product group that you are defining.
Description
Enter a brief description of the product group that you are defining.
2.3
Maintaining Mayuru Limit Details
The customers can be categorized to ‘Maruyu Limit’ (Tax free small sum savings) group/
category. The customers belonging to this group are provided tax exemption for deposits up
to a certain limit amount. If the balance in the account goes above the allowed limit then, on
interest liquidation the interest amount will be taxable.
2-36
The Maruyu limit maintained at the customer level is applicable to all the CASA and TD
accounts of the customer. The account limit can be specified by the customer on opening of
account or any time during the life cycle of the account. The sum total of the threshold limits
across all accounts of the customer (CASA and term deposit) should not breach the customer
level limit.
You can maintain the Maruyu Limit per customer using ‘Maruyu Limit Maintenance’ screen.
The limit amount for Maruyu customers should be less than or equal to the bank level limit.
You can invoke this screen by typing 'CSDMLMT' in the field at the top right corner of the
Application tool bar and click on the adjoining arrow button.
You can enter the following details:
Limit Currency
The system displays the currency for which the limit is maintained.
Customer Limit Amount
Specify the amount of customer limit.
Effective Date
Specify the date from which the limit is effective at the bank level. The Maruyu effective date
should not be less than the current system date.
In this screen, you can perform the following operations:

New

Enter Query

Save

Authorize

Copy

Close

Unlock

Print

Delete
The SDEs MARUYU_CUSTOMER and MARUYU_ACCLIMIT are used for tax calculation for
Maruyu Customers.
2-37
The SDE MARUYU_CUSTOMER will return a value as '1' for TD accounts based on the
following conditions:

In the list of records available in the multi grid of 'Maruyu limit’ in STDCUSTD screen,
the SDE will identify the records which are related to current liquidation cycle.

If the ‘Maruyu Status' is Yes or Disqualified for a particular record.
The SDE MARUYU_CUSTOMER will return a value as '1' for CASA accounts based on the
following conditions:

In the list of records available in the multi grid of 'Maruyu limit’ in STDCUSAC screen,
the SDE will identify the records which are related to current liquidation cycle.

If the ‘Maruyu Status' is Yes for a particular record.
The SDE MARUYU_CUSTOMER will return a value as '0' for TD accounts based on the
following conditions:

In the list of records available in the multi grid of 'Maruyu limit’ in STDCUSTD screen,
the SDE will identify the records which are related to current liquidation cycle.

If the 'Maruyu Status' is No for a particular record.
The SDE MARUYU_CUSTOMER will return a value as '0' for CASA accounts based on the
following conditions:

In the list of records available in the multi grid of 'Maruyu limit’ in STDCUSAC screen,
the SDE will identify the records which are related to current liquidation cycle.

If the ‘Maruyu Status' is No or Disqualified for a particular record.
The formula for Maruyu Limit is below:
2-38
CASA
Sl.No
Conditions
Result
Periodicity
Remarks
1
VD_DLY_CR_BAL
_M>0
((VD_DLY_CR_BAL
_M* DAYS *
TERM_RATE) /
(100 *
YEAR))
Daily
Credit Interest Formula
2
MARUYU_C
USTOMER =
0
((VD_DLY_CR_BAL
_M* DAYS *
TERM_RATE) /
(100 *
YEAR))
Daily
Non booked
Formula,
periodicity
should be
maintained
as daily
3
FORMULA2
>0
FORMULA2*(TAX_RATE/100)
Daily
Tax formula,
periodicity
should be
periodic
TD Accounts
Sl.No
Conditions
Result
Periodicity
Remarks
1
DEPOSIT_A
MOUNT>0
((DEPOSIT_
AMOUNT *
DAYS * TERM_RATE) /
(100 *
YEAR))
Daily
Credit Interest Formula
2
MARUYU_C
USTOMER =
0
((DEPOSIT_
AMOUNT *
DAYS * TERM_RATE) /
(100 *
YEAR))
Daily
Non booked
Formula,
periodicity
should be
maintained
as daily
3
FORMULA2
>0
FORMULA2*(TAX_RATE/100)
Daily
Tax formula,
periodicity
should be
periodic
The MARUYU_CUSTOMER SDE will be ‘1’ only if all of the following customer level
conditions are met:

Customer is a Maruyu Customer (based on the check box ’Maruyu Customer’)

The effective date is reached
The SDE MARUYU_ACCLIMIT will pick up the value based on the SDE
MARUYU_CUSTOMER. i.e. only if SDE MARUYU_CUSTOMER is ‘1’ the limit is considered.
On modification of the account limit amount, the SDE MARUYU_ACCLIMIT will consider the
latest value of the limit for every interest liquidation cycle.
2-39
The MARUYU_CUSTOMER SDE will be ‘0’ only if Maruyu Status is ‘No’ or ‘Disqualified for a
particular record.
2.3.1
Viewing Maruyu Limit Details
You can view the maruyu limit details of the customer in ‘Maruyu Limit Summary’ screen. You
can invoke this screen by typing ‘CSSMLMT’ in the field at the top right corner of the
Application tool bar and clicking on the adjoining arrow button.
You can search for the records based on either one or more of the following search
parameters:

Authorization Status

Record Status

Effective Date
Once you have specified the search parameters, click ‘Search’ button. The system will display
the following information:

Authorization Status

Record Status

Effective Date

Customer Limit Amount
2-40
2.4
Maintaining Deposit Insurance Parameters
Oracle FLEXCUBE allows you to activate your deposit insurance in case the bank becomes
bankrupt. When bankruptcy is declared on a bank, the core banking generates the handoff
files, that contains the details of all CASA and deposit accounts and sends to Deposit
Insurance Corporation Japan (DICJ). The DIC system determines the insured and uninsured
amount for each account and this file is sent to FCUBS.The uninsured amount will be
transferred to the ‘Miscellaneous Cr GL' configured in the GL Lines sub screen of Account
Class Maintenance screen.
You can configure transaction code to facilitate transfer of funds from CASA/TD accounts to
this GL (Miscellaneous Cr GL) through Deposit Insurance Parameters Maintenance screen.
You can invoke this screen by typing ‘STDDICP’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Bank Code
The system displays the bank code.
Transaction Code for Uninsured Movement
Specify the transaction code for uninsured movement. Alternatively, you can select the
transaction code from the option list. The list displays all valid transaction codes.
2.5
Maintaining Customer DIC Details
You can maintain the netting preference of a customer based on customer ID, PID and
customer name through ‘Customer DIC Details’ screen.You can invoke this screen by typing
2-41
‘STDCDICD’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
You can maintain the following in this screen:
Customer No
Specify the customer number. Alternatively, you can select the customer number from the
option list. The list displays all valid customer numbers.
PID
The system displays the PID based on the customer number.
Customer Name
The system displays the customer name based on the customer number selected.
Branch Code
The system displays the branch code based on the customer number selected.
Kana Name
Specify the DIC specific Kana name. If Kana name is maintained here then it will be
considered for while reporting to DIC. If it is not maintained then the Kana name maintained
at Customer Maintenance (STDCIF) screen will be considered.
Local Public Name
Specify the local name of the customer.
Industry Category
Specify the industry category. Alternatively you can select the industry category from the
option list. The list displays all valid industry classifications.
Joint Signature Savings Classification
Check this box to indicate preference for joint signature savings classification.
2-42
2.5.1
Viewing Customer DIC Details
You can view the customer DIC details in ‘Customer DIC Summary’ screen. You can invoke
this screen by typing ‘STSCDICD’ in the field at the top right corner of the Application tool bar
and clicking the adjoining arrow button.
In the above screen, you can query on any or all of the following parameters and fetch
records:

Authorization Status

Record Status

Customer No

Customer Name

PID
Select any or all of the above parameters for a query and click ‘Search’ button. Records
meeting the selected criteria are displayed with the following details:

Authorization Status

Record Status

Customer No

Customer Name

PID

Branch Code

Kana Name
2-43
2.5.2

Local Public Name

Industry Category

Joint Signature Savings Classification
GI Interface Definition for DIC Outgoing Hand-off File
Oracle FLEXCUBE allows you to activate your insurance deposit in case the bank becomes
bankrupt. When bankruptcy is declared on a bank, the core banking generates the handoff
files, that contains the details of all CASA and deposit accounts and sends to Deposit
Insurance Corporation Japan (DICJ). The handoff file generation is scheduled to trigger every
week and will replace the files generated in the previous week. The files have to be generated
post EOTI stage of EOD processing after all the interest accruals are completed.
The following interface definition and corresponding data source will be available in the
handoff file generated from FCUBS to external system DICJ (Deposit Insurance Corporation
Japan):
Retail Customer Data
Format ID
Description
STODICNC
GI outgoing file for Nayose (Customer Change) customer
data
File Name to be generated - CSDICRC1.dat
STODICIF
GI outgoing file for customer data
File Name to be generated - CSDICRC2.dat
STODIDEP
GI outgoing file for CASA and Deposit accounts
File Name to be generated - CSDICRC3.dat
STODICOL
GI outgoing file for Collateral accounts
File Name to be generated - CSDICRC4.dat
STODIODA
GI outgoing file for OD accounts
File Name to be generated - CSDICRC8.dat
STODIAPP
GI outgoing file for Appendix data
File Name to be generated - CSDICRC9.dat
The following periodic outgoing file with Nayose CIF Data is generated for the format ID
‘STODICNC’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
Type
Lengt
h
Format
Remarks
Fixed
Value
NAYOSE
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"36"
2-44
3
Financial
institution
code
DERIVED
Bank Code
> Bank
Parameters
C
4
4
Branch
code
DERIVED
1st 3 digits
of PID
C
3
5
CIF (customer)
number
DERIVED
RTL+ last
7 digits of
PID
C
10
6
Non-applicable
class
FIXED
NA
N
1
7
Indiv. / corporate
code
FIXED
1 - Retail
N
1
Name
(kana)
DERIVED
C
48
8
2 - Corporate
If record
available
for PID in
STDCDICD
Kana
name from
same, else
Kana
name of
STDCIF>Additional
Scripts
2-45
"0"
9
Birth date
DERIVED
00000000
if
D
8
a) In case
customer
addition
date is 05/
Nov/2001
and Birth
date is 01/
Jan/1950
b) In case
customer
addition
date is
within(<=)
01/Jan/
1850,
else
Date of
Birth from
STDCIF in
YYYYMMDD format
10
Telephone
number
DERIVED
Phone
number
from CIF Mobile ISD
Code +
Mobile
Number
C
17
11
Dummy
FIXED
NA
C
15
spaces
The following periodic outgoing file with customer data is generated for the format ID
‘STODICIF’.
Sl.
No
Field Name
Field
Type
Derivation
Logic
Data
type
Length
Format
Remarks
Fixed
Value
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"02"
3
Financial
institution
code
DERIV
ED
Bank Code >
Bank Parameters
C
4
4
Branch code
DERIV
ED
1st 3 digits of
PID
C
3
5
CIF (customer) number
DERIV
ED
RTL+ last 7
digits of PID
C
10
2-46
6
CIF caution
code
DERIV
ED
Customer
Memo
C
10
0: If no memo
Based on
customer
memo
1:If 'error or
override' type
of memo
10:if 'information' memo
7
Name (kana)
DERIV
ED
If record available for PID in
STDCDICD
Kana name
from same,
else Kana
name of STDCIF>Additional Scripts
C
48
8
Name (kanji)
DERIV
ED
Kanji name
from CIF
K
90
9
Zip code
DERIV
ED
Address zip
code from CIF
- PIN Code
without
spaces
C
7
10
Address
(kana)
DERIV
ED
Kana address
from CIF Prefecture +
City + Addr1-3
- without
space
C
80
11
Address
(kanji)
DERIV
ED
Kanji address
from CIF Prefecture +
City + Addr1-3
- without
space
K
120
12
(Tax info)
financial system, etc.
classification
FIXED
NA
N
1
13
(Tax info) foreign address
display classification
DERIV
ED
0 - Country in
Address is
Japan
N
1
1 - Other
address
2-47
Double
byte
"0"
14
(Tax info) no
residence/
foreign corporation
classification
DERIV
ED
0-Resident, 1Non-resident
N
1
based on
customer
type (resident)
15
(Tax info)
diplomatic
immunity
classification
FIXED
NA
N
1
"0"
16
(Tax info)
has property
but no residence/ foreign
corporation
classification
FIXED
NA
N
1
"9"
17
(Tax info)
reduced/ tax
exempt classification
FIXED
NA
N
1
"0"
18
(Tax info) tax
reduction
rate (%)
FIXED
NA
N
5
19
Dummy
DERIV
ED
NA
C
14
"0000
0"
"00000”
will be
interpreted as
00.000
The following periodic outgoing file with deposit data is generated for the format ID
‘STODIDEP’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"03"
3
Financial
institution
code
DERIV
ED
Bank Code in
Bank Parameters
C
4
4
Branch
code
DERIV
ED
the first 3
digit of
account no.
C
3
2-48
Format
Remarks
Fixed
Value
5
Deposit
item code
DERIV
ED
product type/
CCY
N
2
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- CASA
with 0% interest or no
Credit interest formula
attached
6
Deposit
item code
branch
number
FIXED
"00"
N
2
7
Account
number
DERIV
ED
Digits 4-12 of
account number
C
12
8
Account
branch
no.
FIXED
NA
N
4
"0000"
9
CIF (customer)
branch
code
FIXED
NA
C
3
all
space
10
CIF (customer)
number
DERIV
ED
"RTL" + the
last 7 digit of
PID
N
10
2-49
"00"
Right pad
with
SPACE
11
Account
caution
code
DERIV
ED
Refers to
ATM flag +
CASA
Account status.
It contains
the values
based on
below calculation.
Decode(MO
D(ATM
Flag,2),0,1,1,
0)+Decode(A
CCOUNT
STATUS,8,0,2,10
,3,100,16,10
00,0)
ACCOUNT
STATUS : If
'Debit Override' = 16,
else 8
ATM FLAG
(Channels
allowed
based on
STDCTLMT)
: Sum of values based on
channels
allowed at
acocunt
where
ATM=1,IVR=
2,POS=4,Inte
rnet Banking=8
Example:
Account
where ATM &
Internet
banking is
allowed and
account in Dr
override status
ATM flag = 9
&
cod_acct_sta
t =16
Account Caution code
=
2-50
0+1000
=1000
C
10
Left pad
ZERO
12
Account
setup
date
DERIV
ED
Account
Open Date
N
8
13
Deposit
date
DERIV
ED
CASA : Last
transaction
date
N
8
N
8
N
8
N
9
2,7
N
9
2,7
C
1
TD : Interest
Start Date
14
Term end
date
DERIV
ED
CASA:
00000000
TD : Maturity
date in
YYYYMMDD
15
16
Immediately prior
to interest settlement
date/ term
end date
DERIV
ED
Interest
rate (%)
DERIV
ED
CASA- sets
last interest
accrual date
TD - Last
Interest Liquidation Date
CASA : Interest rate as
per default
product with
RP variance
TD : Interest
Rate with RP
variance
17
Post-end
of term
rate (%)
DERIV
ED
CASA: If tax
formula is
available,
same as
'Interest
Rate' field
above, else 0
TD: Value
maintained
for
'PMI_RATE'
UDE, else 0
18
General
ledger
principal
balance
mark
DERIV
ED
"-" if account
balance is
'Dr'
blank otherwise
2-51
19
General
ledger
principal
balance
DERIV
ED
CASA : Current Balance
N
17
N
1
N
17
14,3
TD: Deposit
Amount
Note: Round
down to previous integer
for JPY
accounts.
Others retain
currency decimals
20
21
Other
bank bill
return
decision
classification
DERIV
ED
Unpaid
end of
term interest
DERIV
ED
1 - if amount
block is available for
account
0 - otherwise
CASA - all
zero
TD - total
interest
amount till
TD maturity
(excluding
PMI)
2-52
14,3
22
Unpaid
accrued
interests
DERIV
ED
CASA : Interest accrued
from last liquidation date
N
17
14,3
The result
of Yen
interest
(both
CASA and
TD),
TD: Interest
accrued +
PMI , since
last liquidation date
If 123.678
then
123000.
(round
down)
Note: Rounding as per
remarks field
The result
of FCY
savings
interest,
If 123.678
then
123670.
(round
down
below
Subsidiary currency)
The result
of FCY TD
interest,
If 123.678
then
123680.
(round
closer
below
Subsidiary currency)
23
Uncollected
interests
FIXED
24
Passbook capital
balance
symbol
DERIV
ED
'-' (balance is
negative) or
space (positive / not
issued)
2-53
C
12
C
1
12,0
"0"
Balance of
CASA (JPY/
FCY)
N
17
Passbook capital
balance
DERIV
ED
26
Passbook
update
classification
FIXED
1(unprinting
exist),"0"(No
unprinting
exist or not
issued)
N
1
27
Savings
passbook
not issued
classification
DERIV
ED
1(not
issued),"0"(is
sued)
N
1
28
Foreign
currency
type
DERIV
ED
Account Currency Code
for FCY
accounts
C
3
N
1
25
14,3 without
separator
last 3 digits considered as
decimal
0 for other
accounts
for LCY
accounts null
29
Debt classification
DERIV
ED
0 - if collateral is not
created for
deposit
2 - if collateral is created in case
of CASA
if TD, space
30
Collateral
deposit
classification
DERIV
ED
"1" if limit
against
deposit is utilised
N
1
31
401K
classification
FIXED
NA
N
1
"0"
32
Ineligible
deposit
classification
FIXED
NA
N
1
"0"
2-54
33
Third
party
investment trust
classification
FIXED
NA
N
1
"0"
34
(Maruyu)
Tax-free
small-sum
savings
system
classification
FIXED
Maruyu flag
N
1
"0"/"1"
35
(Maruzai)
Tax-free
property
accumulation system
classification
FIXED
NA
N
1
"0"
36
Tax-free
corporation classification
FIXED
NA
N
1
"0"
37
Children's
bank savings classification
FIXED
NA
N
1
"0"
38
Other
than
objective
repayment total
FIXED
NA
C
13
39
Joint signature
savings
classification
DERIV
ED
Set "1" - if
CASA interest rate is 0
OR no Cr
interest formula is
attached
N
1
C
7
13,0
all zero
Set "0" - In
case of the
other code,
sets "0".
40
Discount
rate (%)
FIXED
NA
2-55
all zero
41
General
ledger
principal
amount
FIXED
42
Assumed
interest
payable
coefficient
FIXED
43
Date
immediately
preceding interest
payment
FIXED
44
3
45
Dummy
FIXED
NA
C
11
all zero
C
8
all zero
NA
C
8
all zero
NA
N
1
"3"
NA
C
11
all
space
The following periodic outgoing file with collateral data is generated for the format ID
‘STODICOL’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
C
2
"04"
3
Financial
institution
code
DERIVE
D
Bank Code in
Bank Parameters
C
4
4
Branch
code
DERIVE
D
the first 3 digit
account number for JPY
CASA
C
3
5
Deposit
item code
DERIVE
D
01: JPY CASA
C
2
6
Deposit
item code
branch
number
FIXED
NA
C
2
7
Account
number
DERIVE
D
Digits 4-15 of
JPY CASA
Account Number
C
12
8
Account
branch
no.
FIXED
NA
C
4
2-56
Format
Remarks
Fixed
Value
"00"
"0000"
9
Collateral
deposit
branch
code
DERIVE
D
the first 3 digit
of collateralized TD
account number
C
3
10
Collateral
deposit
deposit
item code
FIXED
NA
C
2
"05"
11
Collateral
deposit
deposit
item code
branch
no.
FIXED
NA
C
2
"00"
12
Collateral
deposit
account
number
DERIVE
D
Digits 4-15
digits of TD
Account Number
C
12
13
Collateral
deposit
account
number
branch
no.
FIXED
NA
C
4
"0000"
14
Dummy
FIXED
NA
C
17
all
space
The following periodic outgoing file with outstanding OD data is generated for the format ID
‘STODIODA’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Financial
institution
code
DERIVED
Bank Code in
Bank Parameters
C
4
2
Branch
code
DERIVED
the first 3 digit
account number for JPY
CASA
C
3
3
Deposit
item code
DERIVED
01: JPY CASA
C
2
4
Deposit
item code
branch
number
FIXED
NA
C
2
2-57
Format
Remarks
Fixed
Value
"00"
5
Account
number
DERIVED
6
Account
branch
no.
DERIVED
7
Negative
balance
mark
DERIVED
8
General
ledger
principal
balance
DERIVED
C
12
C
4
'-' (balance is
negative) or
space (positive)
C
1
Account Balance with
leading zeros
C
17
Digits 4-15 of
JPY CASA
Account Number
last three digits for decimals
without separator
"0000
"
will be
interpreted as
14,3 i.e.
last 3 digits are
decimals
eg:
JPY1,000,000
is shown as
00000001000
000000
The following periodic outgoing file with appendix data is generated for the format ID
‘STODIAPP’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Branch
code
DERIVE
D
the first 3 digit
of PID (the
same as it of
Nayose CIF)
C
3
2
comma
FIXED
NA
C
1
3
CIF(customer)
number
DERIVE
D
"RTL"+the last 7
digit of PID (the
same as it of
Nayose CIF)
C
10
4
comma
FIXED
NA
C
1
","
5
NCIF(cu
stomer)
number
FIXED
NA
C
8
ALL
space
6
comma
FIXED
NA
C
1
","
7
Business
Division
code
DERIVE
D
"RTL"
C
3
2-58
Format
Remarks
Fixed
Value
","
8
comma
FIXED
NA
C
1
","
9
Customer
Group
code
FIXED
NA
C
3
ALL
space
10
comma
FIXED
NA
C
1
","
11
Customer
Type
Code
DERIVE
D
Based on customer tax group
code decription
C
1
A: 'Resident',
D: 'Non Resident'
I: 'Tax Exemption'
12
comma
FIXED
NA
C
1
","
13
industry
type
classification
FIXED
NA
C
5
"0000
0"
14
comma
FIXED
NA
C
1
","
15
Dormancy
Flag(rea
son
code)
DERIVE
D
Account Status
Dormant
C
1
flag 'Yes' then
'1'
else '0'
16
comma
FIXED
NA
C
1
","
17
Birth
date
flag(reason
code)
FIXED
NA
C
1
ALL
space
18
comma
FIXED
NA
C
1
","
19
Dummy
FIXED
NA
C
16
ALL
space
The following incoming file from DIC after bankruptcy is generated for the format ID
‘STIDICIN’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
2-59
Data
type
Length
Format
Remarks
Fixed
Value
1
Deposit
Item
Code
DERIVE
D
product type/
CCY
C
2
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- Other
deposits
2
Drawdown
Number
FIXED
NA
N
2
3
Account
Number
DERIVE
D
Digits 4-15 of
account number
C
12
4
Account
Branch
Number
FIXED
1st 3 digits of
account number
N
4
5
Non
Insure
Classification
DERIVE
D
1 - if total
account balance is uninsured
C
1
"00"
set
account
number
by leftjustified
and set
single
byte
space
"0000"
2- if partial
account balance is uninsured
6
Setteing
Classification
(Spare)
DERIVE
D
NA
C
1
7
Non
Insure
Amount
(Principal)
DERIVE
D
Uninsured
principal to be
transferred to
GL
N
14
8
Non
Insure
Amount
(Interest)
DERIVE
D
Uninsured
interest to be
transferred to
GL
N
12
2-60
"1"
9
(for division
Saving
Account
with
interest)
DERIVE
D
Include this
amount to be
deducted from
CASA and
paid to Uninsured GL
N
12
10
Dummy
FIXED
NA
C
21
The following daily tran reporting on insured portion is generated for the format ID
‘STODICTN’.
Sl.
No
Field
Name
Field
Type
Processing
Logic
Data
type
Length
Format
Remarks
Fixed
Value
HEADER
1
Data Classification
FIXED
NA
N
1
"1"
2
Data Type
FIXED
NA
N
2
"10"
3
Code
Specification
FIXED
NA
N
1
"1"
4
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
C
4
5
Creation
Date
DERIV
ED
Creation date
YYYYMMDD
N
8
6
Creation
Time
DERIV
ED
Creation date
HHMMSS
N
6
7
Value Date
(from)
DERIV
ED
Transaction
value date
From YYYYMMDD
N
8
8
Value Date
(to)
DERIV
ED
Transaction
value date To
YYYYMMDD
N
8
9
Tape Number
DERIV
ED
Unique number
for magnetic
tape
C
10
10
Dummy
DERIV
ED
Set all space
C
152
200
STATEMENT RECORD (BODY)
1
Data Classification
FIXED
NA
N
2-61
1
"3"
2
Data Type
FIXED
NA
N
2
3
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
N
4
4
Branch
Code
DERIV
ED
First 3 digits of
account number
C
3
5
Deposit
Item Code
DERIV
ED
product type/
CCY
C
2
"10"
01 - JPY CASA
05 - JPY TD
17- FCY CASA
18- FCY TD
13- CASA with
0% interest or
no Credit interest formula
attached
6
Drawdown
Number
FIXED
NA
N
2
7
Account
Number
DERIV
ED
Digits 4-15
C
12
8
Account
Sub Number
FIXED
NA
N
4
9
CIF (Customer)
Branch
Code
DERIV
ED
1st 3 digits of
PID
C
3
10
CIF (Customer)
Number
DERIV
ED
RTL+ last 7 digits of PID
C
10
11
Value Date
DERIV
ED
Transaction
value date
YYYYMMDD
N
8
12
Transaction Number
DERIV
ED
Running serial
number to signify nth transaction for account
on tran value
date
N
8
13
Credit
?Debit Date
DERIV
ED
Same as value
date
N
8
2-62
space
"0000"
14
Deposit
Status
Classification
DERIV
ED
CASA :
N
1
N
2
0 - New
account
1 - Credit
2 - Debit
3 - Reversal/
Cancellation
TD:
0 - booking
1 - Reversal of
debits, if any
2 - Other debits
to account
3 - Full redemption
15
Transaction Classification
DERIV
ED
10 : cash
(include checks
issued by other
banks)
14 : account
transfer
(interest of
Saving Account
etc. and middle
interest of Term
Deposit transfer to a designated account)
15 : automatic
renewal
18 : others
19 : correction
16
Transaction Principal Amount
DERIV
ED
Transaction
amount with
leading 0's
C
12
17
Interest
Rate (%)
DERIV
ED
Interest rate
considered in
case of TD
redemption,
else 0
N
9
18
Interest
Rate after
Maturity
(%)
DERIV
ED
If field 14 is TD
booking related
(0), then corresponding interest rate , else 0
N
9
2-63
19
Maturity
Date
DERIV
ED
Maturity date of
TD YYYYMMDD if available, else all 0's
N
8
20
Transaction Interest Amount
DERIV
ED
Interest amount
with leading 0's
in case of TD
redemption
C
11
21
Balance
Sign after
Transaction
DERIV
ED
-'-, if account
balance after
transaction is in
Dr, else space
C
1
22
Balance
after Transaction
DERIV
ED
Current balance
after transaction with leading 0's
N
14
23
Dummy
FIXED
NA
C
66
space
200
END RECORD
1
Data Classification
FIXED
N
1
"8"
2
Data Type
FIXED
N
2
"10"
3
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
C
4
4
New
Transaction Number
DERIV
ED
?total number
of Deposit Status Classification of
?0?(New) in
this MT
N
9
?number set by
right-justified +
remaining "0"
(for example)
1,234 transaction is
?000001234?
2-64
5
Total
Amount of
New Transaction
DERIV
ED
?total principal
amount of all
transaction of
Deposit Status
Classification of
?0?(New) in
this MT
N
14
N
9
N
14
?number set by
right-justified +
remaining "0"
(for example)
12,345,600 Yen
is
?00000012345
600?
6
Credit
Transaction Number
DERIV
ED
?total number
of Deposit Status Classification of
?1?(Credit)
& not Transaction Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
2,345 transaction is
?000002345?
7
Total
Amount of
Credit
Transaction
DERIV
ED
?total principal
amount of all
transaction of
Deposit Status
Classification of
?1?(Credit)
& not Transaction Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
23,456,700 Yen
is
?00000023456
700?
2-65
8
Total Number of
Credit Correction
Transaction
DERIV
ED
?total number
of Deposit Status Classification of
?2?(Debit)
N
9
N
14
N
9
& Transaction
Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
3,456 transaction is
?000003456?
9
Total
Amount of
Credit Correction
Transaction
DERIV
ED
?total principal
amount of all
transaction of
Deposit Status
Classification of
?2?(Debit)
& Transaction
Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
23,456,700 Yen
is
?00000023456
700?
10
Debit
Transaction Number
DERIV
ED
?total number
of Deposit Status Classification of
?2?(Debit)
& not Transaction Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
4,567 transaction is
?000004567?
2-66
11
Total
Amount of
Debit
Transaction
DERIV
ED
?total principal
and interest
amount of all
transaction of
Deposit Status
Classification of
?2?(Debit)
N
14
N
9
& not Transaction Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
45,678,900 Yen
is
?00000045678
900?
12
Total Number of Debit
Correction
Transaction
DERIV
ED
?total number
of Deposit Status Classification of
?1?(Credit)
& Transaction
Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
5,678 transaction is
?000005678?
2-67
13
Total
Amount of
Debit Correction
Transaction
DERIV
ED
?total principal
and interest
amount of all
transaction of
Deposit Status
Classification of
?1?(Credit)
N
14
N
9
N
14
& Transaction
Classification of
?19?(Correction) in this MT
?number set by
right-justified +
remaining "0"
(for example)
56,789,000 Yen
is
?00000056789
000?
14
Cancellation Transaction
Number
DERIV
ED
?total number
of Deposit Status Classification of
?3?(Cancallation) in this MT
?number set by
right-justified +
remaining "0"
(for example)
7,890 transaction is
?000007890?
15
Total
Amount of
Cancellation Transaction
DERIV
ED
?total principal
and interest
amount of all
transaction of
Deposit Status
Classification of
?3?(Cancellation)
?number set by
right-justified +
remaining "0"
(for example)
78,900,000 Yen
is
?00000078900
000?
2-68
16
Number of
Statement
Record
DERIV
ED
?Total Number
of Statement
Record in this
MT
N
9
C
46
?number set by
right-justified +
remaining "0"
(for example)
12,300 records
is ?000012300?
17
Dummy
FIXED
18
Data Classification
FIXED
N
1
"9"
19
Data Type
FIXED
N
2
"10"
20
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
N
4
21
Total Number of
Statement
Record
DERIV
ED
?Total Number
of Statement
Record
C
9
Dummy
FIXED
C
184
22
all space
?number set by
right-justified +
remaining "0"
(for example)
23,456 records
is ?000023456?
all space
The following uninsured balance reporting to third party system is generated for the format ID
‘STODICUN’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
DataClassification
FIXED
NA
N
1
`
2
DataType
FIXED
NA
N
2
"36" (
Fixed
value )
3
CifBranchCode
FIXED
NA
V
3
" " ( All
space )
4
Cif Number
DERIVE
D
RTL+ last 7
digits of PID
V
10
5
BranchCode
DERIVE
D
the first 3
digit of
account no.
V
3
2-69
Format
Remarks
Fixed
Value
6
BankAccountNumber
DERIVE
D
Uninsured
GL to which
amount is
transferred
C
16
7
DepositIte
mCode
DERIVE
D
product
type/CCY
V
2
"4007510
00123456
" ( 16th
byte is
space )
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- Other
deposits
8
DepositIte
mCodeBranchNumber
FIXED
NA
N
2
"0"
9
AccountNumber
DERIVE
D
Account
Number of
Insured Portion;
V
12
"7582593
2D1 " (
11th&12th
byte are
space )
digits 4-13
followed by
2 spaces
10
AccountBranchNumber
FIXED
NA
N
4
11
NonInsuredClassificat
ion
DERIVE
D
1 - if total
account balance is uninsured
C
1
"00"
"0000"
"2"
2- if partial
account balance is uninsured
12
SettingClassification
FIXED
NA
C
1
13
NonInsuredPricipalAmou
nt
DERIVE
D
Uninsured
principal
transferred
to GL
N
14
2-70
"1" (
Fixed
value )
(14, 0)
14
NonInsuredInterestAmo
unt
DERIVE
D
Uninsured
interest
transferred
to GL
N
12
(12, 0)
15
AccountBalanceAmo
unt
DERIVE
D
Account Balance before
split
N
14
(14, 0)
16
ValidFlag
FIXED
NA
C
1
"Y"
17
WithdrawalProcesse
dFlag
FIXED
NA
C
1
"W"
18
GlProcessedFlag
FIXED
NA
C
1
"C"
19
NonInsuredBranchCo
de
FIXED
NA
N
4
20
NonInsuredDepositIte
mCode
DERIVE
D
product
type/CCY
V
2
"05"
"0000"
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- Other
deposits
21
NonInsuredDepositIte
mCodeBranchNumber
FIXED
NA
N
2
"0"
22
NonInsuredAccountNum
ber
DERIVE
D
DIC account
number (as
per mask at
STDDICP)
V
12
"7582593
2D1 "
digits 4-13
followed by
2 spaces
2-71
"00"
23
NonInsuredAccountBra
nchNumber
FIXED
NA
N
4
"0000"
24
DepositDate
DERIVE
D
Account
Open Date
in YYYYMMDD format
D
8
"2012042
7"
25
MaturityDate
DERIVE
D
Maturity
Date in
YYYYMMDD format
for TD
D
8
"2019042
7"
CASA 00000000
26
InterestRate
DERIVE
D
Interest rate
last applied
on account
N
9
(2, 7)
27
InterestRateAfterMaturit
y
FIXED
NA
N
9
(2, 7)
"0" (
Fixed
value )
Corporate Customer Data
Format ID
Description
STODCCNC
GI outgoing file for Nayose (Customer Change) customer
data
File Name to be generated - CSDICRC1.dat
STODCCIF
GI outgoing file for customer data
File Name to be generated - CSDICRC2.dat
STODCDEP
GI outgoing file for CASA and Deposit accounts
File Name to be generated - CSDICRC3.dat
STODCCOL
GI outgoing file for Collateral accounts
File Name to be generated - CSDICRC6.dat
STODCODA
GI outgoing file for Loan accounts
File Name to be generated - LCPAYOFF.dat
STODCAPP
GI outgoing file for Appendix data
File Name to be generated - CSDICRC9.dat
The following periodic outgoing file with Nayose CIF data is generated for the format ID
‘STODCCNC’.
2-72
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
Format
Remarks
Fixed
Value
NAYOSE
1
Data classification
FIXED
NA
N
1
"3" (
Fixed
value )
2
Data type
FIXED
NA
N
2
"01" (
Fixed
value )
3
Financial
institution
code
DERIVED
Bank Code
> Bank
Parameters
C
4
4
Branch
code
DERIVED
First 3 digits
of PID
C
3
5
CIF (customer)
number
DERIVED
"CRP"+ last
7 digits of
PID
C
10
6
Non-applicable
class
FIXED
NA
N
1
7
Indiv. /
corporate
code
FIXED
1 - Retail
N
1
8
Name
(kana)
DERIVED
If record
available for
PID in STDCDICD
Kana name
from same,
else Kana
name of
STDCIF>Additional Scripts
C
48
9
Birth date
DERIVED
Date of
Incorporation from
STDCIF in
YYYYMMDD format
D
8
2 - Corporate
2-73
"0"
10
Telephone
number
DERIVED
Mobile ISD
Code +
Mobile Number : Phone
number from
CIF > Director's tab
C
17
11
Dummy
FIXED
NA
C
15
12
Old Cif
DERIVED
WHEN
A12 =
'00000000'
THEN
C
8
'09180025'
ELSE
A12
If the
length is
more the
first 17
digits
after concantenating the
two fields
to be considered
spaces
This is
based on
migrated
customers in legacy
system.
Table
mapping
from FCR
to V12 to
be
updated
The following periodic outgoing file with customer data is generated for the format ID
‘STODCCIF’.
Sl.
No
Field Name
Field
Type
Derivation
Logic
Data
type
Length
Format
Remarks
Fixed
Value
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"02"
3
Financial
institution
code
DERIVED
Bank Code >
Bank Parameters
C
4
4
Branch code
DERIVED
1st 3 digits of
PID
C
3
5
CIF (customer) number
DERIVED
CRP+ last 7
digits of PID
C
10
2-74
6
CIF caution
code
DERIVED
Customer
Memo
C
10
If 'error or
override' the
set
0000000001
Based on
customer
memo
if 'information'
0000000000
7
Name (kana)
DERIVED
If record
available for
PID in STDCDICD Kana
name from
same, else
Kana name
of STDCIF>Additional Scripts
C
48
8
Name (kanji)
DERIVED
Kanji name
from CIF
C
90
9
Zip code
DERIVED
Address zip
code from
CIF - PIN
Code without spaces
C
7
10
Address
(kana)
DERIVED
Kana
address from
CIF - Prefecture + City +
Addr1-3 without
space
C
80
11
Address
(kanji)
DERIVED
Kanji
address from
CIF - Prefectue + City +
Addr1-3 without
space
C
120
12
(Tax info)
financial system, etc.
classification
FIXED
NA
N
1
13
(Tax info) foreign address
display classification
DERIVED
0 - Country in
Address is
Japan
N
1
1 - Other
address
2-75
State +
City +
Addr1-3 without
space
"0"
14
(Tax info) no
residence/
foreign corporation classification
DERIVED
0-Resident,
1- Non-resident
N
1
15
(Tax info) diplomatic
immunity
classification
FIXED
NA
N
1
"0"
16
(Tax info) has
property but
no residence/ foreign
corporation
classification
FIXED
NA
N
1
"9"
17
(Tax info)
reduced/ tax
exempt classification
FIXED
NA
N
1
"0"
18
(Tax info) tax
reduction
rate (%)
FIXED
NA
N
5
19
Dummy
DERIVED
NA
C
14
based on
customer
type (resident)
"0000
0"
To interpreted as
00.000
The following Periodic outgoing file with deposit data is generated for the format ID
‘STODCDEP’.
Format
Remarks
Fixed
Value
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"03"
3
Financial
institution
code
DERIV
ED
Bank Code in
Bank Parameters
C
4
4
Branch
code
DERIV
ED
1st 3 digits of
account number
C
3
2-76
5
Deposit
item code
DERIV
ED
product type/
CCY
N
2
01 - JPY CASA
05 - JPY TD
17- FCY CASA
18- FCY TD
13- CASA with
0% interest or
no Credit interest formula
attached
6
Deposit
item code
branch
number
FIXED
"00"
N
2
7
Account
number
DERIV
ED
Digits 4-15 of
account number
C
12
8
Account
branch no.
DERIV
ED
TD : 0001
N
4
9
CIF (customer)
branch
code
FIXED
NA
C
3
10
CIF (customer)
number
DERIV
ED
"CRP" + the last
7 digit of PID
(left trim)
N
10
11
Account
caution
code
DERIV
ED
If Account Status is
BT
10
"00"
CASA : 0000
Blocked 0000000010
No Debit 0000000100
Debit Override 0000001000
Else 0000000000
12
Account
setup date
DERIV
ED
Account Open
Date
N
8
13
Deposit
date
DERIV
ED
CASA : Last
transaction date
N
8
TD : Interest
Start Date
2-77
all
space
14
Term end
date
DERIV
ED
CASA:
00000000
N
8
N
8
N
9
2,7
N
9
Last
seven
digits to
be considered
as decimal
TD : Maturity
date in YYYYMMDD
15
16
Immediately prior
to interest
settlement date/
term end
date
DERIV
ED
Interest
rate (%)
DERIV
ED
CASA- sets
last interest
accrual date
TD - Last Interest Liquidation
Date
CASA : Interest
rate as per
default product
with RP variance
TD : Interest
Rate with RP
variance
17
Post-end
of term
rate (%)
DERIV
ED
CASA: If tax
formula is available, same as
'Interest Rate'
field above,
else 0
TD: Value maintained for
'PMI_RATE'
UDE, else 0
18
General
ledger
principal
balance
mark
DERIV
ED
"-" if account
balance is 'Dr'
blank otherwise
2-78
Assuming
PMI_RAT
E will be
the UDE
maintained for
PMI
C
1
19
General
ledger
principal
balance
DERIV
ED
CASA : Current
Balance
N
17
N
1
N
17
14,3
TD: Deposit
Amount
Note: Round
down to previous integer for
JPY accounts.
Others retain
currency decimals
20
21
Other
bank bill
return
decision
classification
DERIV
ED
Unpaid
end of
term interest
DERIV
ED
1 - if amount
block is available for account
0 - otherwise
CASA - all zero
TD - total interest amount till
TD maturity
(excluding PMI)
2-79
14,3
22
Unpaid
accrued
interests
DERIV
ED
CASA : Interest
accrued from
last liquidation
date
N
17
14,3
The result
of Yen
interest
(both
CASA
and TD),
TD: Interest
accrued + PMI ,
since last liquidation date
Note: Rounding as per
remarks field
If
123.678
then
123000.
(round
down)
The result
of FCY
savings
interest,
If
123.678
then
123670.
(round
down
below
Subsidiary currency)
The result
of FCY
TD interest,
If
123.678
then
123680.
(round
closer
below
Subsidiary currency)
23
Uncollected
interests
FIXED
24
Passbook
capital balance symbol
DERIV
ED
'-' (balance is
negative) or
space (positive
/ not issued)
2-80
C
12
C
1
all zeros
25
Passbook
capital balance
DERIV
ED
Balance of
CASA (JPY/
FCY)
N
17
0 for other
accounts
26
Passbook
update
classification
FIXED
1(unprinting
exist),"0"(No
unprinting exist
or not issued)
N
1
27
Savings
passbook
not issued
classification
DERIV
ED
1(not
issued),"0"(issu
ed)
N
1
28
Foreign
currency
type
DERIV
ED
Account Currency Code for
FCY accounts
C
3
N
1
for LCY
accounts - null
29
Debt classification
DERIV
ED
CASA:
0 - if collateral
is not created
for deposit
2 - if collateral
is created
TD: N/A (space)
2-81
14,3
30
Collateral
deposit
classification
DERIV
ED
A.Set '0'
If there are no
records in
STODCOL
whose fields 610 matches to
the value of
fields 4-8 in
deposit file,
B. If there are
any records in
collateral file
whose fields 610 matches to
the value of
fields 4-8 in
deposit file
i) Set '3' (Under
attachment )
AND all 3 conditions below
are satisfied
1) Select
accounts
whose status is
"restricted"
a) for CASA
;
Acct.Status = "Block the
Account"
or "Disallow
debits"
or "Allow debits
with override"
b) for TD ;
Acct.Status = "Block the
Account"
2) search
acct-statuschange-history,
and select the
records where
after-status in
history = acctstatus in
pres2-82
ent acct master.
If more than
one records
N
1
31
401K classification
FIXED
NA
N
1
"0"
32
Ineligible
deposit
classification
FIXED
NA
N
1
"0"
33
Third party
investment trust
classification
FIXED
NA
N
1
"0"
34
(Maruyu)
Tax-free
small-sum
savings
system
classification
FIXED
Maruyu flag
N
1
"0"/"1"
35
(Maruzai)
Tax-free
property
accumulation system
classification
FIXED
NA
N
1
"0"
36
Tax-free
corporation classification
FIXED
NA
N
1
"0"
37
Children's
bank savings classification
FIXED
NA
N
1
"0"
38
Other than
objective
repayment total
FIXED
NA
C
13
all
zeros
39
Joint signature
savings
classification
DERIV
ED
Set "1" - if
CASA interest
rate is 0 OR no
Cr interest formula is
attached
N
1
Set "0" - In
case of the
other code, sets
"0".
2-83
40
Discount
rate (%)
FIXED
NA
C
7
all
zeros
41
General
ledger
principal
amount
FIXED
NA
C
11
all
zeros
42
Assumed
interest
payable
coefficient
FIXED
C
8
all
zeros
43
Date
immediately
preceding
interest
payment
FIXED
NA
C
8
all
zeros
44
3
NA
N
1
"3"
45
Dummy
NA
C
11
FIXED
all space
The following periodic outgoing file with collateral data is generated for the format ID
‘STODCCOL’.
Field Name
Field
Type
Derivation
Logic
Data
type
Length
1
Data classification
FIXED
NA
N
1
"3"
2
Data type
FIXED
NA
N
2
"06"
3
Financial
institution
code
DERIVE
D
Bank Code in
Bank Parameters
C
4
4
CIF (customer)
branch code
DERIVE
D
First 3 digits of
PID
C
3
5
CIF (customer) number
DERIVE
D
"CRP" + the
last 7 digit of
PID (left trim)
N
10
6
Collateral
deposit
branch code
FIXED
1st 3 digits of
account number
C
3
2-84
Format
Remark
s
Fixe
d
Valu
e
Sl.
No
"00"
7
Collateral
deposit
deposit type
code
DERIVE
D
product type/
CCY
C
2
01 - JPY CASA
05 - JPY TD
17- FCY CASA
18- FCY TD
13- Other
deposits
8
Collateral
deposit
deposit type
code subnumber
FIXED
"00"
N
2
9
Collateral
deposit
account
number
DERIVE
D
Digits 4-15 of
ac number (left
trim)
C
12
10
Collateral
deposit
account subnumber
DERIVE
D
TD : 0001
N
4
Dummy
FIXED
NA
C
17
11
"00"
CASA : 0000
all
spac
e
The following periodic outgoing file with outstanding loan data is generated for the format ID
‘STODCODA’.
Sl.
No
Field Name
Field Type
Derivation Logic
Data
type
Length
1
Data classification
FIXED
NA
N
1
2
Data type
FIXED
NA
N
2
3
Financial
institution
code
DERIVED
Bank Code in Bank
Parameters
C
4
4
CIF (customer)
branch code
DERIVED
1st 3 digits of PID
C
3
5
CIF (customer) number
DERIVED
CRP+ last 7 digits of
PID
N
10
2-85
Format
Remarks
6
Outstanding
loan
DERIVED
Customer loan balance across loan
accounts
N
12
7
Accrued
interest on
loan
DERIVED
Accrued interest on
loan
N
12
8
Dummy
FIXED
all space
C
16
First 12
digits of
amount
field
The following periodic outgoing file with appendix data is generated for the format ID
‘STODCAPP’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
Branch
code
DERIV
ED
the first 3 digit
of PID (the
same as it of
Nayose CIF)
C
3
2
comma
FIXED
NA
C
1
3
CIF(customer)
number
DERIV
ED
"CRP"+the
last 7 digit of
PID
C
10
4
comma
FIXED
NA
C
1
","
5
NCIF(cu
stomer)
number
FIXED
NA
C
8
ALL
space
6
comma
FIXED
NA
C
1
","
7
Business
Division
code
DERIV
ED
"CRP"
C
3
8
comma
FIXED
NA
C
1
","
9
Customer
Group
code
FIXED
NA
C
3
ALL
space
10
comma
FIXED
NA
C
1
","
2-86
Format
Remarks
Fixed
Value
","
11
Customer
Type
Code
DERIV
ED
Based on customer tax
group code
decription
C
1
A: 'Resident',
D: 'Non Resident'
I: 'Tax Exemption'
12
comma
FIXED
NA
C
1
","
13
industry
type
classification
FIXED
NA
C
5
"00000
"
14
comma
FIXED
NA
C
1
","
15
Dormancy
Flag(reason
code)
DERIV
ED
Account Status Dormant
C
1
flag 'Yes' then
'1'
else '0'
16
comma
FIXED
NA
C
1
","
17
Birth
date
flag(reason
code)
FIXED
NA
C
1
ALL
space
18
comma
FIXED
NA
C
1
","
19
Dummy
FIXED
NA
C
16
ALL
space
The following incoming file from DIC following bankruptcy is generated for the format ID
‘STIDCCIN’.
S.
No
Field
Name
Field
Type
Processing
Logic
2-87
Data
type
Length
Format
Remarks
Fixed
Value
1
Deposit
Item Code
DERIVE
D
product type/
CCY
C
2
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- Other
deposits
2
Drawdown
Number
FIXED
NA
N
2
3
Account
Number
DERIVE
D
Digits 4-15 of
account number
C
12
4
Account
Branch
Number
FIXED
1st 3 digits of
account number
N
4
5
Non Insure
Classification
DERIVE
D
1 - if total
account balance is uninsured
C
1
Concatenate
fields
'4+3' to
arrive at
account
number
2- if partial
account balance is uninsured
6
Setting
Classification (Spare)
FIXED
NA
C
1
7
Non Insure
Amount
(Principal)
DERIVE
D
Uninsured
principal to be
transferred to
GL
N
14
8
Non Insure
Amount
(Interest)
DERIVE
D
Uninsured
interest to be
transferred to
GL
N
12
9
(for division Saving Account
with interest)
DERIVE
D
Include this
amount to be
deducted from
CASA and
paid to Uninsured GL
N
12
2-88
"1"
10
Dummy
FIXED
NA
C
21
The following daily tran reporting on insured portion is generated for the format ID
‘STODCCTN’.
Sl.N
o
Field
Name
Field
Type
Processing
Logic
Data
type
Length
Format
Remarks
Fixed
Value
HEADER
1
Data
Classification
FIXED
NA
N
1
"1"
2
Data
Type
FIXED
NA
N
2
"10"
3
Code
Specification
FIXED
NA
N
1
"1"
4
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
C
4
5
Creation
Date
DERIV
ED
Creation date
YYYYMMDD
N
8
6
Creation
Time
DERIV
ED
Creation date
HHMMSS
N
6
7
Value
Date
(from)
DERIV
ED
Transaction
value date
From
YYYYMMDD
N
8
8
Value
Date
(to)
DERIV
ED
Transaction
value date To
YYYYMMDD
N
8
9
Tape
Number
DERIV
ED
Unique number for magnetic tape
C
10
10
Dummy
DERIV
ED
Set all space
C
152
200
STATEMENT RECORD (BODY)
1
Data
Classification
FIXED
NA
N
2-89
1
"3"
2
Data
Type
FIXED
NA
N
2
3
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
N
4
4
Branch
Code
DERIV
ED
First 3 digits
of account
number
C
3
DERIV
ED
product type/
CCY
C
2
5
Deposit
Item
Code
"10"
01 - JPY
CASA
05 - JPY TD
17- FCY
CASA
18- FCY TD
13- CASA
with 0% interest or no
Credit interest formula
attached
6
Drawdown
Number
7
Accoun
t Number
8
FIXED
NA
N
2
DERIV
ED
Digits 4-15
C
12
FIXED
NA
N
4
Accoun
t Sub
Number
9
CIF
(Customer)
Branch
Code
DERIV
ED
1st 3 digits of
PID
C
3
10
CIF
(Customer)
Number
DERIV
ED
CRP+ last 7
digits of PID
C
10
2-90
space
"00"
11
Value
Date
DERIV
ED
Transaction
value date
YYYYMMDD
N
8
12
Transaction
Number
DERIV
ED
Running
serial number to signify
nth transaction for
account on
tran value
date
N
8
13
Credit
?Debit
Date
DERIV
ED
Same as
value date
N
8
DERIV
ED
CASA :
N
1
14
Deposit
Status
Classification
0 - New
account
1 - Credit
2 - Debit
3 - Reversal
TD:
0 - booking
1 - Reversal
of debits, if
any
2 - Other
debits to
account
3 - Full
redemption
2-91
15
Transaction
Classification
DERIV
ED
10 : cash
(include
checks
issued by
other banks)
N
2
14 : account
transfer
(interest
of Saving
Account etc.
and middle
interest of
Term Deposit
transfer to a
designated
account)
15 : automatic
renewal
18 : others
19 : correction
16
Transaction
Principal
Amount
DERIV
ED
Transaction
amount with
leading 0's
C
12
17
Interest
Rate
(%)
DERIV
ED
Interest rate
considered in
case of TD
redemption,
else 0
N
9
18
Interest
Rate
after
Maturity (%)
DERIV
ED
If field 14 is
TD booking
related (0),
then corresponding
interest rate ,
else 0
N
9
19
Maturity
Date
DERIV
ED
Maturity date
of TD
YYYYMMDD if available, else all
0's
N
8
20
Transaction
Interest
Amount
DERIV
ED
Interest
amount with
leading 0's in
case of TD
redemption
C
11
2-92
module/
product/
event or
tran code
basis
21
Balance
Sign
after
Transaction
DERIV
ED
-'-, if account
balance after
transaction is
in Dr, else
space
C
1
22
Balance
after
Transaction
DERIV
ED
Current balance after
transaction
with leading
0's
N
14
23
Dummy
FIXED
NA
C
66
space
200
TRAILER
1
Data
Classification
FIXED
N
1
"8"
2
Data
Type
FIXED
N
2
"10"
3
Financial
Institution
Code
DERIV
ED
Bank Code in
Bank Parameters
C
4
4
New
Transaction
Number
DERIV
ED
?total number of
Deposit Status Classification of
?0?(New) in
this MT
N
9
?number set
by right-justified +
remaining "0"
(for example) 1,234
transaction is
?000001234
?
2-93
5
Total
Amount
of New
Transaction
DERIV
ED
?total principal amount of
all transaction of
Deposit Status Classification of
?0?(New) in
this MT
N
14
N
9
?number set
by right-justified +
remaining "0"
(for example)
12,345,600
Yen is
?000000123
45600?
6
Credit
Transaction
Number
DERIV
ED
?total number of
Deposit Status Classification of
?1?(Credit)
& not Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example) 2,345
transaction is
?000002345
?
2-94
7
Total
Amount
of
Credit
Transaction
DERIV
ED
?total principal amount of
all transaction of
Deposit Status Classification of
?1?(Credit)
N
14
N
9
& not Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example)
23,456,700
Yen is
?000000234
56700?
8
Total
Number of
Credit
Correction
Transaction
DERIV
ED
?total number of
Deposit Status Classification of
?2?(Debit)
& Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example) 3,456
transaction is
?000003456
?
2-95
9
Total
Amount
of
Credit
Correction
Transaction
DERIV
ED
?total principal amount of
all transaction of
Deposit Status Classification of
?2?(Debit)
N
14
N
9
& Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example)
23,456,700
Yen is
?000000234
56700?
10
Debit
Transaction
Number
DERIV
ED
?total number of
Deposit Status Classification of
?2?(Debit)
& not Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example) 4,567
transaction is
?000004567
?
2-96
11
Total
Amount
of Debit
Transaction
DERIV
ED
?total principal and interest amount of
all transaction of
Deposit Status Classification of
?2?(Debit)
N
14
N
9
& not Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example)
45,678,900
Yen is
?000000456
78900?
12
Total
Number of
Debit
Correction
Transaction
DERIV
ED
?total number of
Deposit Status Classification of
?1?(Credit)
& Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example) 5,678
transaction is
?000005678
?
2-97
13
Total
Amount
of Debit
Correction
Transaction
DERIV
ED
?total principal and interest amount of
all transaction of
Deposit Status Classification of
?1?(Credit)
N
14
N
9
& Transaction Classification of
?19?(Correction) in this
MT
?number set
by right-justified +
remaining "0"
(for example)
56,789,000
Yen is
?000000567
89000?
14
Cancellation
Transaction
Number
DERIV
ED
?total number of
Deposit Status Classification of
?3?(Cancallation) in this
MT
?number set
by right-justified +
remaining "0"
(for example) 7,890
transaction is
?000007890
?
2-98
15
Total
Amount
of Cancellation
Transaction
DERIV
ED
?total principal and interest amount of
all transaction of
Deposit Status Classification of
?3?(Cancellation)
N
14
N
9
C
46
?number set
by right-justified +
remaining "0"
(for example)
78,900,000
Yen is
?000000789
00000?
16
Number of
Statement
Record
DERIV
ED
?Total Number of Statement Record
in this MT
17
Dummy
FIXED
18
Data
Classification
FIXED
N
1
"9"
19
Data
Type
FIXED
N
2
"10"
20
Financial
Institution
Code
DERIV
ED
N
4
?number set
by right-justified +
remaining "0"
(for example) 12,300
records is
?000012300
?
all space
Bank Code in
Bank Parameters
2-99
21
22
Total
Number of
Statement
Record
DERIV
ED
Dummy
FIXED
Total Number of Statement Record
C
9
C
184
number set
by right-justified +
remaining "0"
(for example) 23,456
records is
?000023456
?
all space
The following uninsured balance reporting to third party system is generated for the format ID
‘STODCCUN’.
Sl.
No
Field
Name
Field
Type
Derivation
Logic
Data
type
Length
1
DataClassification
FIXED
NA
N
1
"3"
2
DataTyp
e
FIXED
NA
N
2
"36" (
Fixed
value )
3
CifBranchCode
FIXED
NA
V
3
" " ( All
space )
4
Cif Number
DERIVE
D
CRP+ last
7 digits of
PID
V
10
5
BranchCode
DERIVE
D
the first 3
digit of
account no.
V
3
6
BankAccountNumber
DERIVE
D
Uninsured
GL to which
amount is
transferred
C
16
2-100
Format
Remarks
"4007510
00123456
" ( 16th
byte is
space )
Fixed
Value
7
DepositIt
emCode
DERIVE
D
product
type/CCY
V
2
01 - JPY
CASA
05 - JPY
TD
17- FCY
CASA
18- FCY
TD
13- Other
deposits
8
DepositIt
emCodeBranchNumber
FIXED
NA
N
2
"0"
9
AccountNumber
DERIVE
D
Account
Number of
Insured
Portion;
V
12
"7582593
2D1 " (
11th&12th
byte are
space )
digits 4-13
followed by
2 spaces
10
AccountBranchNumber
FIXED
NA
N
4
11
NonInsuredClassific
ation
DERIVE
D
1 - if total
account
balance is
uninsured
C
1
"00"
"0000"
"2"
2- if partial
account
balance is
uninsured
12
SettingClassification
FIXED
NA
C
1
13
NonInsuredPricipalA
mount
DERIVE
D
Uninsured
principal
transferred
to GL
N
14
(14, 0)
14
NonInsuredInterestAm
ount
DERIVE
D
Uninsured
interest
transferred
to GL
N
12
(12, 0)
2-101
"1" (
Fixed
value )
15
AccountBalanceAm
ount
DERIVE
D
Account
Balance
before split
N
14
(14, 0)
16
ValidFlag
FIXED
NA
C
1
"Y"
17
WithdrawalProcess
edFlag
FIXED
NA
C
1
"W"
18
GlProcessedFlag
FIXED
NA
C
1
"C"
19
NonInsuredBranchC
ode
FIXED
NA
N
4
20
NonInsuredDepositIt
emCode
DERIVE
D
product
type/CCY
V
2
"05"
"0000"
01 - JPY
CASA
05 - JPY
TD
17- FCY
CASA
18- FCY
TD
13- Other
deposits
21
NonInsuredDepositIt
emCodeBranchNumber
FIXED
NA
N
2
"0"
22
NonInsuredAccountNu
mber
DERIVE
D
DIC
account
number (as
per mask at
STDDICP)
V
12
"7582593
2D1 "
N
4
"00"
digits 4-13
followed by
2 spaces
23
NonInsuredAccountBra
nchNumber
FIXED
NA
2-102
"0000"
24
DepositDate
DERIVE
D
Account
Open Date
in YYYYMMDD format
D
8
"2012042
7"
25
MaturityDate
DERIVE
D
Maturity
Date in
YYYYMMDD format for TD
D
8
"2019042
7"
CASA 00000000
26
InterestRate
DERIVE
D
Interest
rate last
applied on
account
N
9
(2, 7)
27
InterestRateAfterM
aturity
FIXED
NA
N
9
(2, 7)
2-103
"0" (
Fixed
value )
3. Ramadan Maintenance
3.1
Introduction
Zakat is a charge which is applied on the balance in an account if the balance is above a
certain threshold amount. This charge is applicable only to savings accounts and Term
Deposits (TD). It cannot be levied on current accounts.
The minimum threshold amount above which Zakat will be payable is decided every year
before Ramadan. In addition, the percentage to be applied on the capital amount for
calculation of Zakat is also decided.
This charge is levied on the savings accounts and TD accounts at Ramadan. For savings
accounts, Zakat is computed on the balance as on the first day of Ramadan for all active
accounts. The applicable amount is then deducted from the accounts.
In the case of TD accounts, Zakat is computed whenever there is a redemption of the
principal. It is computed on the redeemed principal amount, provided the first day of Ramadan
(for any one year of the TD tenor) falls between the profit start date of the deposit and the
maturity date.
For computation and collection of Zakat you need to capture the first day of Ramadan every
year.
3.2
Maintaining Ramadan Day
You can capture the first day of Ramadan for a given year in the ‘Ramadan Day Maintenance’
screen. This is a bank-level maintenance that needs to be done at your Head Office. To
invoke the ‘Ramadan Day Maintenance’ screen, type ‘CSDRAMDN’ in the field at the top right
corner of the Application tool bar and clicking the adjoining arrow button.
Here you can specify the following details:
3-1
Year
Specify the year for which you are capturing the first day of Ramadan. Note that you cannot
maintain multiple records for the same year.
First Day of Ramadan
Specify the date on which Ramadan starts in the specified year. Note that the date should be
valid as per the Ramadan calendar.
Refer the chapters titled ‘Defining the attributes specific to an Interest or Charge product’ and
‘Daily Processing of Interest and Charges’ in the Interest and Charges User Manual for details
on Zakat computation and application.
3-2
4. Dealer Maintenance
4.1
Defining Dealer
At the time of entering the details of a foreign exchange, money market, or securities deal,
you will be required to enter details of the dealer who has struck the deal.
The dealers at your bank, who are associated with the buying and selling of foreign exchange,
money or securities in the treasury, should each be assigned an identification number (ID
number). The dealer list is maintained for the bank through the ‘Dealer Maintenance ‘screen.
Invoke this screen by typing ‘STDDLRMT’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
The following parameters need to be maintained to define a dealer ID:
Dealer Id
Enter a unique code to identify the dealer. The identification code can have a maximum of six
alphanumeric characters.
The dealer will be identified by this code for all transactions entered in Oracle FLEXCUBE.
You can also retrieve dealer-wise information on the treasury deals entered into by your bank.
Dealer Name
You can also enter a detailed name of the dealer. The name of the dealer will be displayed
whenever the dealer Id is used.
4-1
5. Branch Parameters
5.1
Creating Branches
In the ‘Branch Parameters’ screen you create the various branches of your bank, define their
reporting hierarchy, and maintain parameters such as their names, their address of location,
SWIFT, TELEX, and HOST addresses.
In this screen you can do the following:

Create the Regional Offices and branches of your bank by assigning each a unique
branch code

Maintain the address of location of each of the branches and also their SWIFT, TELEX
and HOST addresses

Specify the Suspense GL for posting all those accounting entries for which no GL has
been specified or the specified GL has been closed

Define preferences, such as - the retention duration, a CIF number for walk-in
customers and the GL for netting FX contracts

Maintain customer number range for generation of CIF numbers for customers of your
bank.
The HO creates the branches at the bank level. All subsequent modifications on the table are
done from the respective branches.
5.1.1
System Features
Oracle FLEXCUBE supports a three level reporting structure.
At the top stands the Head Office followed by the Regional Offices. At the lowest level are the
branches. There can be any number of branches, but the number of regional offices is
restricted to six. The system validates to check that the number of parent branches is not more
than six. If the number of parent branches is more than six, system will give an error and
restrict the number to six.
The branches report to the RO; and the ROs in turn report to the HO. Within this three level
structure you can also have a branch reporting independently to the Head office (as branch,
BR7 in the diagram).
It is also possible to have a two level reporting structure with only the HO and the branches,
where each individual branch reports directly to the HO.
5-1
5.1.2
Creating Reporting Structure
The order in which you create the HO, the ROs and the branches should follow the hierarchy.
Hence, the first branch to be created should be the HO, followed by the ROs, and then the
branches.
The Head Office of your bank is created during installation. You only have to create the
Regional Offices and the various branches. During installation, the system automatically
populates this screen with the branch code and name of your Head Office that you have
specified to the implementer. The ‘Parent branch’ and the Regional Office fields’ also default
to this branch code.
To create an RO, invoke a new screen. Then, enter the code and name of the RO against
‘Branch Code’ and ‘Name’ respectively. You do not need to specify the ‘Regional office’
because the HO Code is the default for the field. (All ROs report to the HO).
Then create all the branches. If a branch reports to an RO, to specify that RO is the branch’s
‘Regional Office’, select the code you want from the option list provided for this field.
But before designating, you should authorize all the RO records you have created; the system
will not allow you to use any unauthorized record.
(Diagrammatic Representation)
5.1.3
Basic Parameters for Branch
In Oracle FLEXCUBE, the Head Office and the Regional Offices are defined as branches.
You can maintain the details of the Head Office, regional offices and branches in the ‘Branch.
5-2
Parameters Maintenance’ screen. Invoke this screen by typing ‘STDBRANC’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
You can specify the following details here:
Branch Code
This is the code you assign to the office or branch. The code acts as an identifier in the system
for the office / branch.
Branch Name
This is the name of the office or branch, the code of which is input. Enter the name using a
max. Of 35 characters, alphanumeric
Branch Available
The system displays the Branch Available status. If the status is ‘Yes’, it indicates that the
branch can accept transactions for the day and if the status is ‘No’ , then it indicates that the
transactions will be accepted but it will be in effect only from the next business day.
Accordingly accounting entries will be passed checking the following, for tanking branch
transactions:

The Branch Available Status

The Branch date and host date i.e. entries will be tanked if branch date is ahead of host
date
When the Branch Available status is ‘NO’ or if branch date is ahead of host date, then the
transactions will be tanked. These transactions will be untanked by the BOD program which
runs post date change i.e. POSTDTCH.
Note
If you want to check whether the transaction is tanked or not, you should login to host and
refer to the corresponding query function.
5-3
Alternate Branch Code
Specify the alternate branch code. Alternate branch code is mandatory if it is used for the PID
mask at bank level or the account number mask at the branch level. The system checks if the
length of alternate branch code is same as the number of ‘r’ maintained in PID mask or
account number mask.
Alternate branch code can be used as a component for CASA account number mask and PID
number. For example, if the account number and PID number will have the mask like
‘rrrTTTSSSSSSSSSd’ and ‘rrrnnnnnnnnnnnnd’ respectively, then the system picks ‘rrr’ as the
alternate branch code while generating account number and PID number.
The branch code and alternate branch code should be in numeric characters.
For more information on ‘Querying the Transactions’ refer Retail Teller, Clearing and Utility
Payment Chapters under Oracle FLEXCUBE host module.
5.1.4
Maintaining General Details for Branch
You can maintain the branch details regarding the local currency, the parent branch, regional
office of the branch, address details including telex, BIC etc.
Local Currency
Specify the currency of operation for your branch and the default currency for all transactions
of your branch. The income and expense balances of your branch will also be maintained in
this currency.
Parent Branch
Parent Branch is to define an alternate reporting line, other than the three level HO-ROBranch structure. The ‘Parent’ for all the branches you create is the HO code (default). To
specify the Parent, other than the HO, select from the options displayed. The name of the
parent branch is displayed alongside.
Regional Office
This is the branch code of the Head Office or Regional Office to which the branch (whose code
is input eg. Branch Code) reports.
For a Head Office or a Regional office, this code should be the Head Office branch code,
which is also the default for this field. For the branches, specify that branch as the RO, to
which the branch reports. Select from the list of options displayed.
Country Code
Specify the code of the country in which the branch operates. Select from the options provided
in the pick list
Customer Identity
Specify the customer’s identity. During maintenance of payments & collections periodic
instructions, system defaults the customer number here.
GL Class
Specify the GL Class. The adjoining option list displays a list of all the valid GL class codes
and their description. You can choose the appropriate one.
Note
You can also select ‘ALL’ as an option. This indicates that all the GL codes are allowed for
this branch.
5-4
5.1.4.1
Specifying ATM Details
Specify the following details
ATM Branch
Specify the ATM branch.
Institution Identification
Your bank may have a branch or multiple branches for different countries. You have to
capture the identification code that uniquely identifies your bank branch in the ATM
transactions interchange environment. Specify a code to identify the institution. This
institution ID will help identify whether a particular transaction has been sent from an external
network or whether it has originated from your bank branch.
Inter Branch Transaction Code
You can specify the Transaction Code through which accounting entries for inter-branch
transactions should be settled.
Customer Transfer
Check this option to indicate that transfer transaction should be permitted through the ATM
5.1.4.2
Specifying Address Details
For each branch of your bank you maintain the following parameters:
Branch Address
Input the address of location of the branch. Each line can have a maximum of 35 characters.
BIC
Input the SWIFT address for a branch using 8 or 11 characters, alphanumeric
Telex
Specify the branch’s TELEX address, using a maximum of 14 characters, alphanumeric
Host Name
Against ‘HOST’ enter the name of the Host server for this branch, in not more than 35
characters, alphanumeric
Time Level
In this field is displayed the system time level status, represented by a number between 0 and
9
In Oracle FLEXCUBE, user access to the system can be controlled by assigning each user
and the system, a time level. Both the system and the users are set to different time levels.
Only those users who have a time level equal to or greater than the system time level can log
into the system.
A control clerk, during the EOC process, does the change in time level status
Fund Branch
Even though the fund and the bank are in the same database, the fund is treated as a different
legal entity and as such the books of the fund are maintained separately from those of the
bank. Funds are created in a separate branch and any transaction initiated in the fund branch
belongs to a fund. Check this box to indicate that the branch you are maintaining if is a fund
branch. Since the fund is a different legal entity, it should not be possible to initiate interbranch accounting entries from the fund branch.
5-5
Any settlement with an external entity is routed through the normal settlements interface. In
order to facilitate this, all the account fields in the system accept only the accounts in the
transaction branch, if the branch happens to be a fund branch.
Allow Corporate Access
Select this option to specify that the fund subscription/redemption operations in the fund
branch can access the accounts of corporate branch.
Note
–
You will not be allowed to change this field once the branch record has been
authorized.
–
This field will be enabled only if the branch is a fund branch.
External Value
Specify the name of the branch as maintained in an external system. This value can be used
to interface with the external system.
EOC Status
Under EOC status one of the following alphabets will be displayed which stand for the
following:
B - Beginning of financial input; indicates system transactions in progress
I -- Indicates that user transactions are in progress
T-- End of user transaction input; indicates system transactions in progress
F -- End of financial input; system transactions also completed
E -- End of Day, Branch awaiting date change
The values are updated by EOC process.
5.1.4.3
Specifying Time Zone Offset
For branches with different time zones, you can define the offset time that is to be displayed
in maker/checker stamp and all the reports generated for the branch.
The offset time is specified in terms of hours and minutes, and the time will be added/
subtracted from the Server Time maintained for the bank.
Hours
Specify the number of hours to be offset from Server Time to arrive at the local branch time
This is the number of hours by which the branch leads or lags behind the Server Time
Minutes
Indicate the additional minutes by which the branch leads or lags behind the Server Time
Note
The reference of time is always the System Time (Server Time)
5-6
Ahead
The system calculates the local time of the Branch by adding/subtracting the Server Time and
the Time Zone Offset time. When you maintain the offset time for the time zone, you need to
specify whether the system should add or subtract the offset time from the Time Zone Offset.
Checking the Ahead box indicates that the offset time is added to the Server Time.
Consequently, if the box is unchecked, the offset time is subtracted from the Server Time.
Additionally, the system validates the cutoff time depending on the time you specify here. The
validation is based on following 3 parameters:
5.1.4.4

Cutoff Time maintained for the currency in Currency Definition Screen

Cutoff Offset Time maintained for the Branch in Branch Parameters Screen

Time Zone Offset maintained for Branch in Branch Parameters Screen
Indicating Cutoff Offset Time
When defining a currency, you can indicate a cut-off time for the currency. If your bank
operates in branches located in different time zones, the cut-off time maintained for the bank
will not be applicable across branches.
Therefore, you can set up an offset time for your branch based on the cut-off time set for the
bank. You can specify an offset time for your branch in the Branch Parameters screen.
Hours & Minutes
The offset time is expressed in hours and minutes. The time you specify here is added or
subtracted from the cut-off time maintained for the bank. This depends on the time difference
between your branch and the Head Office.
5.1.4.5
Indicating Local Payments
Clearing Branch
Select the clearing branch from the adjoining option list.
Transaction Code for Consolidation Across Products
Select the transaction code for consolidation from the adjoining option list.
5-7
5.1.5
Maintaining Financial Details for Branch
You can specify the details regarding suspense GLs, Financial cycle, preference for floating
rate, message generation (103,103+) for the branch in this screen. The screen appears as
shown below:
5.1.5.1
Specifying Suspense GL
The accounting entries generated by different modules of Oracle FLEXCUBE will be passed
into the specified ‘Suspense GL’ account if:

The GL into which the entries are to be passed is not defined, or

If the GL has been closed
Suspense GLs are of two types:
Real Suspense GL (Local and Foreign Currency)
The accounting entries that belong to asset, liability, income or expense GL categories will be
passed to the ‘Real suspense GL’. To indicate the real suspense GL for a branch, click option
list and select a GL code from the option list.
Contingent Suspense GL (Local and Foreign Currency)
The accounting entries that belong to contingent asset or contingent liability GL categories will
be posted to a ‘Contingent Suspense GL’.
To indicate the contingent suspense GL for a branch, click option list and select a GL code
from the option list.
5-8
5.1.5.2
Specifying Euro Redenomination GL
To facilitate the currency conversion process, you have to maintain a common Conversion GL
and a Transaction Code.
The conversion GL that you specify in this screen will be identified as the common suspense
GL for all balance conversions while re-denominating the currency of an account either for
specific customers or for generic conversions.
In addition to the conversion GL you have to indicate a Transaction Code, which identifies
conversion, related entries.
5.1.5.3
Indicating Payment Messages
Generate 103+
The ‘Generate MT 103 + option’ allows you to generate outgoing MT 103 messages in the MT
103 + format. This check box can be enabled only if you have enabled the generation of MT
103 messages as Payment Messages.
Note
The system will generate MT 103 messages as payment messages for transactions in the
branch, and generate them in the MT 103 + format only if you have enabled this option in
the following cases:
–
For the counterparty of the transaction, in the BIC Code Maintenance
–
By choosing the Generate 103+ option for currency in the Currency Definition
–
For the product used by the transaction, in the Product Preferences
The system is also capable of processing incoming MT 103 messages in the MT 103 +
format. During the upload process the system considers an MT 103 payment message to
be of MT 103 + Format based on the presence of the STP code in the 119 field. Field 119
is present in the third block of the message i.e., {3: {119:STP}}.
Branch Code for Clearing
Indicate the code that identifies your branch in the Clearing Network. The code you specify
for your branch should be the same as that defined in the Clearing Bank Code Maintenance
screen.
Clearing Through Branch
If clearing transactions involving your branch are routed through another branch, specify the
Oracle FLEXCUBE branch code of that branch in this field.
On the basis of the Routing Number Mask defined for your bank, and your specifications in
this screen, Oracle FLEXCUBE automatically generates the Routing Number for clearing
transactions involving your branch in the Routing Number field.
Loan Direct Debit Generation Days
Loan DD Generation days specifies the number of days before the schedule payment date,
when a Direct Debit Contract is generated for the schedule due. This is applicable only for
Loan Contracts in the local currency.
In order to facilitate the processing of loan repayments by customers who have their current
or settlement accounts in some other bank of the clearing network you can initiate Direct
Debits to these accounts. When a payment is due on a loan, a direct debit is generated ‘Loan
DD Generation Days’ before the payment date.
5-9
As a result in Oracle FLEXCUBE the following entries will be passed:
Dr
Clearing suspense
Cr
Dummy Settlement Account
During liquidation which is performed on the schedule date the entries passed are as follows:
Dr
Dummy Settlement Account
Cr
Loan Asset GL / Interest Income GL
Refer the ‘Maintaining the attributes specific to PC products’ chapter of the PC manual along
with the Branch Parameters section of the Core Services Manual for details on processing
DDs originating from a Loan.
5.1.5.4
Processing Amount Block
Oracle FLEXCUBE passes the accounting entries for releasing an amount block through the
‘Transaction Code for Amount Block Release’ field. The system will check whether any
amount block of type CASA for a branch is in open status. If an account is in open status, the
system will group the amount blocks into primary account and primary account branch. Then,
the system will remove the amount block from the cover account and debit the blocked
amount of the cover account to the primary account.
Transaction Code for Amount Block Release
Specify the transaction code for the release of amount block. The adjoining option list displays
all valid transaction codes maintained in the system. You can choose the appropriate one.
5.1.5.5
Indicating Financial Cycle
Current Cycle
This is the code for the current financial year as defined by you in the ‘Period Code’ screen.
Current Period
Each financial year is divided into accounting periods called ‘Period Codes’ defined in the
‘Period Code Maintenance’ Screen (for details refer ‘period Code screen’). The current
accounting period of the financial year is displayed in this field.
5.1.5.6
Specifying Referral Cut-off Time
Referral refers to the process of handling customer transactions that force the accounts
involved in such transaction to exceed the overdraft limit. Examples of typical transactions,
which force an account to move into overdraft, are Payment and Collections, Funds
Transfers, Standing Instructions or Clearing transactions. If an account is marked for referral,
the details of transactions resulting in the account moving into Overdraft will be sent to the
referral queue.
Hours & Minutes
In branch parameter, you have to specify the referral cut-off time for accepting / rejecting
transactions in the referral queue.
In case a transaction is rejected from the referral queue after the cut-off time then system
displays the override message as “‘Rejected after cut off time”.
5-10
Note
Transactions are accepted into the Referral Queue even after cut-off time if account goes
into overdraft.
Auto Authorisation
Oracle FLEXCUBE enables you to allow certain users (of your choice, depending on your
requirements at your installation) to automatically authorize transactions.
To indicate applicability of automatic authorization for users of the branch, you must enable
the Auto Authorization option in the Branch Parameters screen. When you do, you can then
allow automatic authorization rights to the appropriate users at the branch.
For more details about automatic authorization, refer the Security Management System and
Procedures user manuals.
Deferred Statement Status
This is a display field. This field indicates whether or not the Branch is ready for Deferred
Statement Generation. ‘Y’ indicates the Branch is ready for deferred statement generation.
For further details on Referrals refer to the Processing Referrals in Oracle FLEXCUBE
chapter of the Core Entities manual.
Install
Select the appropriate value from the drop-down list to indicate whether Oracle FLEXCUBE
installation is complete or incomplete.
Proceed Without Maintaining Floating Rate
Check this option to indicate that floating rates should be propagated across all branches,
Sector code
Specify the Sector Code of your branch, as specified in the Clearing Bank Code Maintenance
screen.
Routing No
On the basis of the Routing Number Mask defined for your bank, and your specifications in
this screen for clearing and sector, Oracle FLEXCUBE automatically generates the Routing
Number for clearing transactions involving your branch in the Routing Number field.
5.1.5.7
Specifying Revaluation/Position Transfer Details
You can transfer the currency positions from the individual branches to the designated branch
during EOD. The system transfers the position from the existing branch to the treasury
branch. When the position is negative in the given GL, then the system will choose the Offset
account as Position asset GL and when the position is positive in the given GL, then the
system will choose the Offset account as Position liability GL. Sequence of the EOD between
the designated branch and all other branches are operationally controlled.
You can maintain the following revaluation/position transfer details:
Transfer Type
Select the transfer type from the drop-down list. Following are the options available in the
drop-down list:

Position

Reval
5-11
Note
–
If the Transfer Type field is left blank then neither the position transfer nor
revaluation transfer to the designated branch will be done.
–
For position transfer, the ‘Inter Branch in Local Currency‘ check box in the Transaction Code maintenance screen, should be checked to avoid creating position due to
IB posting.
Transfer Branch
The system will identify the branch to which the revaluation/position transfer should be done.
During account/GL revaluation process, the system considers this branch and the GL to pass
one leg of the revaluation profit and loss entries. The other leg of the entries will be passed
based on the revaluation profit/loss GL and the account branch. The account branch in this
case is the ‘Revaluation Into’ branch maintained as part of branch parameters maintenance.
Position Asset GL
Specify the GL to which the notional asset needs to be transferred..
Position Liability GL
Specify the GL to which the notional liability needs to be transferred.
Transaction Code
Specify the transaction code used to pass the accounting for position transfer.
While saving, the system will validate the difference between negotiated rate input by the user
and the base rate maintained against the tolerance limit at the product level. If the difference
is not within the tolerance limit, then the system will display an error message.
5.1.5.8
Specifying Suspense Batch Entry Details
Specify the following details:
Suspense Entry Required
Check this box to indicate that automatic suspense entries can be posted for a branch. If a
mismatch occurs between real entries or contingent entries during the batch, then the system
will post the balancing entries and will continue the EOD without interruption, if you check the
‘Suspense Entry Required’ option and specify the Suspense Batch Entry details. You can
correct those entries manually at later stages.
If you leave this box unchecked and if a mismatch occurs in Real or contingent entries then
the EOD is stopped and the error is thrown. You have to correct the entries.
Suspense Transaction Code
Specify the transaction code against which the suspense entries are posted or /reversed.
Suspense Batch Number
Specify the batch number against which the suspense entries are posted or reversed.
Reverse Suspense Entry Days
Specify the days till which the system can sustain the mismatch entries once the batch is run
for the same. You can specify a value within a range of 1 to 9999.
If the ‘Reverse Suspense Entry Days’ is greater than the EOD suspense entry date and if
reversal action is not performed for the suspense entry then the EOD is stopped and system
displays an error message.
5-12
Maximum Real Suspense Amount
Specify the maximum amount that the system can consider to post suspense entry for an
EOD for real entry.
Maximum Cont Suspense Amount
Specify the maximum amount that the system can consider to post suspense entry for an
EOD for contingent entry.
5.1.6
Maintaining Duplication Check Details
You can maintain the number of days for which the duplication check should be done for a
transaction in ‘Duplication Check Details’ tab. A transaction is compared with all previous
transactions entered during the number of days maintained here, for any possible duplication.
The duplicate check is done starting from booking date till the booking date minus the number
of days for duplicate check. This duplication check is carried out based on the combination of
the preferences maintained at the FT/SI product respectively.
Note
Duplicate transaction check is applicable only for FT and SI transactions.
You can specify the following details here:
Module
Specify the module for which you wish to maintain duplicate check days or select the module
from the option list provided.
Duplication Check Required
Check this box to indicate that duplication check is required for the transactions related to the
module selected.
Note
–
However, despite checking this box if the duplication check criteria are not specified
in the following screens the system will not perform duplication checks for all the
respective contracts under this branch.
–
Payments and Collection Product Category Maintenance
–
Funds Transfer Product Preference
5-13
–
Standing Instruction Product Definition
Duplication Days
Specify the number of days for which the duplication checks for transactions need to be
carried out. Calendar days are considered for duplication check.
Note
You need to specify a value here if ‘Duplicate Check Required’ option is selected. You cannot specify a negative value.
5.1.7
Maintaining SWIFT Address for Branch
Click the ‘SWIFT Address’ in the Branch Parameters screen to invoke ‘Additional SWIFT
Address’ screen.
The screen appears as shown below:
You can specify the SWIFT addresses related to the branch in this screen.
5.1.8
Defining Account Mask
Customer Account Masks can be defined at the Branch Level or at the Bank Level
Click the ‘Account Mask’ in the Branch Parameters screen to invoke ‘Account Parameters’
screen.
5-14
The screen is as shown below:
5.1.8.1
Specifying Multicurrency Account
Multicurrency Account Mask
Specify the multi-currency account mask.
Multicurrency Checksum Algorithm
Select the checksum algorithm details from the adjoining drop-down list. This list displays the
following values:

Modulo 11

Modulo 97

Modulo 11 with weights

Modulo 10

User Defined
Multicurrency Account Algorithm
Specify the multi-currency account algorithm details.
Start Multicurrency Account Number
Specify the start number for multi-currency accounts.
End Multicurrency Account Number
Specify the end number for multi-currency accounts.
Auto Generate Multicurrency Account
Check this box to generate unique multi-currency accounts automatically.
5-15
If this box is unchecked, then you need to specify the account number details for each
currency while creating an account.
For further details please refer the Section ‘Specifying the Account generation Parameters at
bank level’ under Bank Parameters.
Fund Subscription
You may wish the system to automatically create deposit accounts for customers at the time
of fund subscription. These system-created deposit accounts are for use as settlement
accounts.
Here, you need to specify the range of numbers available for such auto created accounts by
mentioning a start and an end number.
If you wish to retain the facility of auto creation of current accounts at loan initiation, you will
have to ensure that the account number mask does not have any user input character.
Note
5.1.9
–
The range of numbers specified for the creation of current accounts should not
overlap with the range specified for the creation of deposit (or contra deposit)
account.
–
Fund account number ranges are enabled only in the fund branch.
Maintaining Customer Number Range
You can specify a number range based on which the customers of your bank will be assigned
CIF numbers for identification. Since the number range is maintained at the branch level, you
can specify different number ranges for different branches of your bank.
To maintain the number range, click the ‘CIF Range’ in the Branch Parameters screen. The
‘Customer Number Range’ screen is displayed:
Specify the following in this screen:
Start Customer No.
This number is the basis on which the system generates the CIF numbers for customers of
your branch.
5-16
The CIF number generation is determined by the following details:

The CIF mask maintained in the Bank-Wide Parameters screen. Assume that the mask
is ‘bbbnnnnnn’ (where ‘bbb’ represents a 3-digit branch code and ‘nnnnnn’ is a 6-digit
number).

The start customer no – assume that this number is 100
While generating CIF numbers, the system will automatically assign the number ‘000000100’
to the first customer of your branch, assuming that the branch code is 000. This conforms to
the CIF mask maintained for the bank. The next customer will be ‘000000101’ and so on.
If the option ‘Auto Generate CIF Numbers’ is checked in the ‘Bank Parameter Preferences’
screen and the start CIF is zero or null, the new customer number will be generated for the
branch as per the current running sequence number of the Head Office.
End Customer No
Just as you specify a Start Customer Number, you have to indicate the End Customer Number
also. You will not be allowed to maintain customers beyond this range.
Let us assume that the ‘End Customer No.’ is 99999. As per the mask and the end number,
the last customer CIF number that is generated at your branch will be ‘000099999’.
Start Dummy Customer Number & End Dummy Customer Number
You should also maintain a dummy customer number range in this screen. When maintaining
a dummy range, you should ensure that dummy CIFs and the actual range do not overlap with
one another.
The dummy CIF range will be used for account number generation. As explained earlier, the
account number can be generated based on the following account mask:
‘bbbTZCCCCCCSd’
Where,

bbb – is the branch code

T – indicates the account code

Z – is the currency type

CCCCCC – is the CIF number of the customer

S – is the sequence number for a combination of account code, currency type and
customer

d – is the control number generated by ‘Modulo 11 with Weights’ algorithm (explained
earlier)
To recall, the sequence number that is automatically generated by the system is for an
account code + currency type + customer combination. The sequence number is a single digit
number (from 1 to 9). This means that, for the same combination, you will be allowed to
maintain only nine accounts. To eliminate this limitation and to allow maintenance of more
than nine accounts for the same combination, the dummy customer number range will be
utilized. This is explained with the help of an example.
For example, Assume that you have maintained the following CIF range for your branch:
Start CIF No.
100000
End CIF No.
198999
Start Dummy No.
199000
5-17
End Dummy No.
199999
Ms. Jennifer approaches your bank to open a savings account in your branch (branch code
is ‘000’). Further, the CIF and account number masks maintained for the branch are
‘bbbnnnnnn’ and ‘bbbTZCCCCCCSd’ respectively.
As per the CIF mask, Ms. Jennifer is assigned the CIF number: 000123456. According to the
account number mask, the 6th to 12th digits will be the last six digits of the CIF number, which
is ‘123456’.
The account number of the first savings account, in USD opened for Ms. Jennifer is:
000411234561 (we will consider only 12-digits for this example since the 13th digit is auto
generated by the system based on Modulo 11 with Weights algorithm).
The components of the account number 000-4-1-123456-1 are as follows:

000 – is the branch code

4 – is the account code

1 – is the currency type

123456 – is the CIF number for Ms. Jennifer

1 – is the sequence number for the combination of account code, currency type and
customer i.e. the number ‘4-1-123456’ will be common for the first 9 accounts
maintained for the same combination.
Now, Jennifer decides to open another account for the same combination. In this case, the
sequence number gets incremented to 2 and the account will be assigned the number: 0004-1-123456-2.
This will go on till the 9th account for the same combination. The 9th account number would
be 000-4-1-123456-9.
If the customer decides to maintain the 10th account for the same combination, the sequence
number will restart since it has reached the maximum allowed level. This would result in
duplication of account numbers. To eliminate this, the system will now use the dummy CIF
range to number the accounts.
Therefore, the 10th account number will be: 000-4-1-199000-1. This sequence will continue
for subsequent accounts maintained for the same combination.
Note
You can view all the dummy CIF numbers linked to a customer in the ‘Customer Accounts
– Allocated Dummy CIF’ screen.
PID Range
Start PID Number
Specify the initial characters of the PID number. You can enter a maximum of 11 or 10
numeric characters when modulo 11 or module 97 is selected respectively. The same can be
entered only once, and cannot be modified subsequently.
End PID Number
Specify the last characters of the PID number. You can enter a maximum of 11 or 10 numeric
characters when modulo 11 or module 97 is selected respectively.
5-18
5.1.10
Maintaining Global Interdict Functions
Click ‘GI Functions’ button in the Branch Parameters Maintenance screen to invoke ‘Branch
Global Interdict Functions’ screen. Using this screen, you can integrate with Global Interdict
System for online verification of transactions before authorisation in order to comply with
‘Office of Foreign Assets Control’ (OFAC) regulations in US.
5.1.11
Maintaining Preferences
To specify your preferences, click ‘Preferences’ button from the ‘Branch-Wide Parameters’
screen. The ‘Preferences’ screen is displayed.
In this screen you define the following preferences:

The netting suspense GL into which settlement entries for netted FX Contracts should
be posted

The CIF Number against which all Walk in customers should be identified
5-19

The format in which the IBAN Account Number and the Bank Code should be captured

The duration for which spool files should be stored in the spool file directory

The directory into which the files should be spooled

MIS codes for posting of automatic balancing entries
These details can be maintained by the respective branches. For a branch you maintain the
following, in the ‘Preferences’ screen:
Netting Suspense GL
All settlement accounting entries relating to a netted FX contract, is passed into the specified
‘Netting suspense GL’. The net amount of the settlement is transferred through the Nostro
accounts. For instance, let us take the following two outstanding contracts entered into by
bank A; both settling on January 10, 1998:

Bought from bank B 1 Million USD in exchange for 35 Million INR

Sold to bank B 1/2 million USD in exchange for 18 million INR
The above contracts can be settled in either of the two ways given below, on the settlement
date:

Settle both contracts separately

Net the settlements of the two contracts
If your bank has a netting agreement with the counterparty, the settlement entries are posted
to this ‘Netting suspense GL’ and the net amounts are settled through the nostros.
Walk in Customer
For your branch you can create a walk in customer ID against which you track all those
customers who do not hold a regular account with your bank but have approached the bank
for a transaction, say, for encashment of traveler’s checks or for manager’s checks.
Internal Swap Customer
You need to specify an internal swap customer for processing internal swaps. The names of
all the customers of your bank will be displayed in the option-list provided. This will be a
unique customer meant for processing internal swaps.
Clearing Account
Specify the default GL account to be used for clearing transactions at the branch.
Offset Clearing Account
Specify the default offset GL account to be used for clearing transactions at the branch.
Weekly Holiday 1 & 2
Using this option you can indicate the holiday in a week for your branch. You can select the
day for holiday from dropdown list. If you want to set only one holiday in a week for your
branch, select the day for Weekly Holiday 1 and leave Weekly Holiday 2 Blank. If you want to
opt for two holidays in a week, select the days for Weekly Holiday 1 & Weekly Holiday 2.
Clearing Bank Code
Specify the code by which your bank is identified in the Clearing Network you participate in.
This has to the same as that specified for your bank in the Clearing Bank Code Maintenance
screen.
MIS Group for Currency (Mismatch Entries)
If the posting of automatic balancing entries due to currency and value date mismatches has
been specified for your bank, you can specify the MIS codes or groups to be used for posting
the balancing entries.
5-20
Interdict Validation Required
For your branch you need to indicate whether Interdict Validation is required for all
Customers, Customer Accounts, Funds Transfers, Standing Instructions, Foreign Exchange,
Letter of Credit and DD transaction processed within your branch.
The options available are:

Yes – the details of CIFs and Customer Accounts, captured in the specific branch of
your bank will be sent to the GI system as and when they are captured in Oracle
FLEXCUBE.

No – the details maintained in the specific branch will not be sent to the GI system for
online verification.
Interdict Timeout Interval
If you indicate that the details should be sent to the GI system, you will also have to specify
the interdict timeout interval period. If the response time from the GI system takes longer than
the time that you specify in this field, the transaction will be timed out since the processing
time exceeds the time stipulated in this field.
If you enable this preference, you will have to identify the Code or ID of the function in Oracle
FLEXCUBE for which such a validation should be performed by clicking on the ‘GI’ button in
the Branch Parameters screen.
Status Processing Basis
In the Branch Parameters, you can indicate the basis upon which status processing must be
done at the branch, for customer accounts as well as loan contracts.
Status processing can be done either at an individual contract / account level, or at a Group /
CIF level.
If you opt for Group / CIF -level processing, it is done in two stages:

The worst status among all contracts and accounts under a specific customer group or
CIF is arrived at

All accounts and contracts involving the customer group or CIF are then moved to the
worst status that was arrived at
If you opt for status processing at individual contract / account level, the status of each
contract or account would be assigned according to the status processing parameters that are
operative for the contract or account.
If ‘Status Processing’ is at Individual Contract Level, then you can change the status and
trigger the status change event along with accounting entry posting. However if the ‘Status
Processing’ is at CIF/Group level individual module (LC, CI, MO, CA, IA and BC) batches will
be updating common storage with the derived status of each contract and CIF/Group level
status will be triggered by the common status change batch. The common status change
batch will call the individual module function for status change processing.
For details about loan status processing and provisioning, consult the Loans user manual and
the Core Entities user manual.
Provisioning Frequency
Provision processing depends upon status processing for accounts and contracts. The
provisioning batch process executes after the status processing batch. If status processing
is indicated to be processed at group / CIF level, you can indicate the frequency at which the
provisioning batch is to be executed for your branch. The frequency options available are daily
and monthly.
5-21
For details about loan status processing and provisioning, consult the Loans user manual and
the Core Entities user manual.
(Withdrawable) Uncollected Funds Basis
You can define how the System enforces the allowable amount of uncollected funds (on an
account) that can be withdrawn within a business day.
For each customer account, you designate a limit on the amount of uncollected funds that
can be withdrawn (the Uncollected Funds Limit). You can also indicate whether, for a given
business day, the System should consider the uncollected funds that are allowed to be
withdrawn as:

The funds scheduled to be released on the current date (today), OR,

The total uncollected funds available against the account subject to the Uncollected
Funds Limit
You can specify your preference by choosing any of the following options:

Uncollected Funds : If you select this option, an amount up to or less than the
uncollected funds limit defined for the account, is allowed to be withdrawn, on a given
business day.

Uncollected Funds Available Same Day: If you select this option, the funds allowed to
be withdrawn against uncollected funds on a given business day are the funds
scheduled to be released on the current date (today).
Deferred Statement Generation
Check this option to stop the automatic account statement generation at end of day.
If this option is checked, then the account statement generation will be deferred to whenever
you initiate action for executing Batch Operations for statement generation. You can do this
through the Branch Statement Status Change screen.
Enterprise GL
Check this option if this branch needs to have an enterprise GL hand-off. Once checked the
system will identify the said branch for creating an ASCII hand-off file containing the relevant
accounting entries to be sent to the external enterprise GL.
Minor Age Limit (Yrs)
Specify the minor age limit. This varies from nation to nation. However If user does not
maintain the age limit, the system will automatically defaults it as 18 years during save.
Notification Days
Specify the intimation days to send advice prior to the customer turns major based on DOB.
Cheque Stale Days
Specify the cheque stale days. Here you can identify the number of days for which stale
validation is done.
Limit Expiry Advice Notification Days
Specify the limit expiry advice notification days. The system will send advice to the customer
these many days before the limit expiry date.
The limit expiry advice generated by the system provides information on the limit details.
Multiple lines can be attached to a customer with different expiry dates. Advice sent to the
customer contains the details of the line which is about to expire.
5-22
Use Head Office Exchange Rates
Exchange rates are maintained for a currency pair and are used to calculate the equivalent of
one currency against the other. These exchange rates can be maintained in each branch or
at the Head office. You can indicate your preference.
If you check ‘Use Head Office Exchange Rates’ field, the exchange rates maintained at the
Head Office will be made applicable to the respective branches of the bank.
If this field is not checked then the exchange rates should be maintained at the respective
branch.
5.1.11.1 Specifying Back-Valued Details
For your branch you can specify the maximum period up to which back valued posting can be
processed. This restriction can be made applicable by specifying the following preferences:
Back Value Check Required
It is used to indicate whether all back-valued transactions should be validated against a
specific period.
Back Value Days
If you enable the Back Value Check Required option, you must indicate the number of
calendar days up to which back-valued transactions can be allowed. During transaction
processing you will be allowed to post back-valued transactions up to the specified date in the
past (no check will be done). Further, if the option is checked but you have not maintained the
‘Back Value Days’ (maintained as NULL), the system will interpret it to be ‘Zero’ days allowed
(for back valued transactions).
The restriction for the maximum period up to which back-valued posting can be allowed, will
be made on transactions processed in following modules:

Payment and collections

Data Entry

Retail Teller

Utility Payments

Foreign Exchange

Money Market

Expense Processing

Fund Transfer

Loans and Deposits
While saving transactions pertaining to any of these modules the System validates the Value
Date of the contract to check whether it adheres to the restriction. You will be intimated with
an override if the Value Date is earlier than the specified period. This restriction is made
applicable on all uploads as well.
Refer the Contract Processing chapter of the individual modules for additional information.
5.1.11.2 Indicating Profit and Loss Adjustment
Track Previous Year Profit and Loss Adjustment
You can collect data pertaining to the unrealized income booked for each contract during the
year by triggering the Year-end batch process. But, you will be allowed to trigger the batch
process for splitting the unrealized profit and loss for the previous year and the current year
only if you have specified this (Track PY PnL Adjustment) as a preferred option for your
branch.
5-23
If you set this preference, the data pertaining to the unrealized income is collected at contract
level for the following modules:

Securities - Unrealized Interest, Discount and Premium accrued for the year.

Derivatives - unrealized income

Bills and Collections - unrealized income

Letters of Credit - unrealized income

Money Markets - unrealized income
5.1.11.3 Indicating Revaluation Split Details
Revaluation Split Required
You can choose to break-up revaluation profit/loss into:

Trading P&L – P&L due to revaluation of foreign currency transactions during the day

Revaluation P&L – P&L due to revaluation of opening balances (balances without
current day’s turnover)
If you enable this preference, all GLs which are marked for revaluation split will have their
revaluation profit/loss broken up into trading and revaluation P & L for entries posted from this
branch.
For further details on Split Revaluation refer the GL user manual.
5.1.11.4 Specifying Suspense Product Maintenance
When a branch goes offline, user posts the transactions allowed in offline mode. Once the
branch and host are online, branch starts posting these transactions as force post. If the force
post fails, then the host needs to post these transactions as a suspense product in the branch.
Debit Product
Specify a valid debit product you need to maintain as Suspense Product. The adjoining option
list displays all the valid debit products maintained in the system. You can select the
appropriate one.
Description
The system displays the description based on the selected debit product
Credit Product
Specify a valid credit product you need to maintain as Suspense Product. The adjoining
option list displays all the valid credit products maintained in the system. You can select the
appropriate one.
Description
The system displays the description based on the selected credit product.
5.1.11.5 Specifying International Banking Account Number MASKS
The IBAN or International Bank Account Number is a unique account number that is used to
identify a customer’s account in a financial institution internationally.
International Bank Account Numbers in your bank are generated in the format of the account
mask that you specify in the Branch Parameters screen. Therefore, you have to first define
IBAN masks.
5-24
The IBAN Mask
Since IBANs should be maintained in a particular format you should first define the format in
which the IBAN should be captured. You should also indicate the format in which the bank
code of the bank in which the account resides should be maintained.
The maximum length of an IBAN should be 34 characters. The IBANK Mask should be a
combination of the following parameters:

An ISO Country Code, which has a maximum length of two characters. The identifier
that you can use to indicate the country code is DD. The identifier will be replaced by
the actual country code while defining the account number. For instance, you will
replace DD with PL for Poland, US for the United States and so on.

A Check Digit Number calculated according to an ISO Standard algorithm, using the
Country Code, Bank Code and Account Number combination. Since this is a two-digit
number you can use the identifier CC to specify this algorithm. The system arrives at
and replaces this identifier with the actual check-digit based on the Country Code, Bank
Code and Account Number combination.

The Bank Code of the bank where the IBAN resides. This code is assigned to the
respective Bank by its national bank. There are no individual restrictions on the length
of Bank Code and Account Number. However, the combined length of the Bank Code
and Account Number should not exceed 30 characters. You can use the identifiers a
(for alphabets) and n (for numerals) as the identifiers to capture the length of the bank
code.

The Account Number of the customer account. The bank in which the customer
account resides assigns this number. You can use the identifiers a (for alphabets) and
n (for numerals) as the identifiers to capture the length of the account number.
For example, you maintain an IBAN mask in the following format:
DDCCaaaaaaaaannnnnnaaaaaannnnnnnnn
While capturing the IAB number you have to strictly adhere to the format mentioned above.
USccCHASEBANK000101CBNYLI450000026
In place of the ‘cc’s the system will generate the check digit algorithm based on the Country
Code, Bank Code and Account Number combination.
The Bank Code Mask
After indicating the IBAN mask you have to specify the mask for the Bank Code. The Bank
Code mask is a combination of alphabets and numerals. Therefore you can specify A and N
as the identifiers. Subsequently, while capturing the bank code in the IBAN screen each of
these characters will be replaced with the respective alphabet or numeral. For instance, let us
assume that you have maintained a 15-character mask for the Bank Code:
A
A
A
A
A
A
A
A
A
N
N
N
N
N
N
You will have to capture the corresponding bank code in the same format:
C
H
A
S
E
B
A
N
K
0
0
0
1
0
1
Note
The combined length of the Bank Code and Account Number should not exceed 30 characters.
5-25
5.1.11.6 Indicating Cheque Number Mask
Cheque Number Mask
The system displays the cheque number mask maintained at bank parameter level.
The ‘Cheque Number Mask’ defined at branch parameter level cannot be changed once
maintained and authorized.
If the cheque book is issued to non base branch accounts, the system populates or validates
the cheque numbers based on the cheque mask of the account branch.
5.1.11.7 Indicating ELCM Integration
Check this box to indicate that the branch details will be replicated to ELCM system. System
will select this option by default, but you can unselect it.
System will not allow unselecting this option once it is selected.
LDAP DN Template
The LDAP DN template needs to be maintained here for each branch. This is used in Oracle
FLEXCUBE user maintenance form to populate corresponding LDAP user-id automatically
from the template.
5.1.12
Maintaining LCY Message Preference for Branch
Click the ‘LCY Msg Pref’ button in the Preferences screen to invoke the ‘LCY Message
Preference’ screen.
The screen is as shown below:
Branch
The system displays the branch details.
Description
The system displays the description.
Module
Specify the module details.
5-26
Module Description
Specify the description of the module.
Local Currency Message Type
Select the local currency message type from the drop-down list. Following are the options
available in the drop-down list:
5.1.13

Suppress LCY

Generate LCY Message Thru SWIFT

Generate PC Contract
Specifying UDF Details
You can associate values to all the User Defined fields created and attached to the Branch
Parameters Screen. You can view the list of User Defined fields associated by clicking the
‘Fields’ button.
The screen appears as shown below:
You can enter the value for the UDFs listed here in the ‘Value’ column.
5.1.14
Maintaining Address Codes Details
You can maintain the address code details in the ‘Address Code Maintenance’ screen. This
facility helps to store and retrieve address details based on the address code maintained.
The address codes maintained in this screen can be retrieved in the following customer
account creation or maintenance screens:

Customer Maintenance (STDCIF)

Customer Summary (STSCIF)

Quick Customer Addition (STDCIFAD)

Quick Customer Addition Summary (STSCIFAD)

360 Degree Corporate Customer View (STDCUSVW)

360 Degree Retail Customer View (STDRETVW)

Customer Party Summary (STSCUSSH)

Customer Details in the Customer Tab (Homepage)
5-27

Customer Accounts Maintenance (STDCUSAC)

Deposit Account Booking (STDCUSTD)

Customer Address Maintenance (MSDCUSAD)

Account Address Maintenance (MSDCACAD)

Quick Customer Account Input (STDCASAC)

Central bank blacklist status (STDNCBQY)

Lead Maintenance (STDLEDMT)
You can invoke this screen by typing ‘STDADMNT’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
Specify the following details:
Address Code
Specify the address code which will uniquely define the address and PIN code. During the
closure of an address code, the system will validate whether the address code is not used for
address maintenance for any other customer. If this address is maintained for another
customer, then an appropriate error message with the customer details are displayed.
If an address code is modified, then using the batch STBADMNT the modified record is
applied across all customers and accounts mapped to this address code.
5-28
Mark For Expiry
Select the check box to maintain the address code details for a scheduled period.
Script Code
Specify the script code. Alternatively you can select the script code from the option list. The
list displays all the valid script codes maintained in the system.
Address 1-3
Specify the address details of the customer from fields Address 1 to Address 3.
Note
If there is a character validation defined for the address fields in ‘Script Maintenance for
Language’ screen (i.e. ‘Validate Characters’ option checked in ‘STDSCRPT’ screen) then
the system validates for allowed characters defined for that particular script entered in ‘Address 1’, ‘Address 2’ and ‘Address 3’ fields.
Prefecture
Specify the prefecture associated with the address specified.
PIN Code
Specify the PIN code.
The batch STBADMNT will not save the modified ‘Address Code’ record in ‘Address Code
Maintenance’ screen (STDADMNT). This batch is run as a part of End of Transaction Input
Process (EOTI) at the end of the day (EOD). Also, modified ‘Address Code’ gets reflected for
all the below mentioned screens as a part of STBADMNT batch:

Address Code Maintenance (STDADMNT)

Address Code Summary (STSADMNT)

Customer Maintenance (STDCIF)

Customer Summary (STSCIF)

Quick Customer Addition (STDCIFAD)

Quick Customer Addition Summary (STSCIFAD)

360 Degree Corporate Customer View (STDCUSVW)

360 Degree Retail Customer View (STDRETVW)

Customer Party Summary (STSCUSSH)

Customer Accounts Maintenance (STDCUSAC)

Quick Customer Account Input (STDCASAC)

Deposit Account Booking (STDCUSTD)

Customer Address Maintenance (MSDCUSAD)

Account Address Maintenance (MSDCACAD)

Central Bank Blacklist Status (STDNCBQY)

Lead Maintenance (STDLEDMT)
Address code and it's details gets fetched and displayed in customer tab.
5.1.14.1 Address Code Upload
Address codes are also maintained by using 9 byte or 11 byte format uploads in Generic
Interface.
5-29
11 byte Address Code Upload
New Address Code Addtion
If an address code that is present in the file is not available in the system, then it is identified as a new
record.These records are added in the system and auto authorized ( configured at
GIDPARAM) and would be available at address code maintenance screen (STDADMNT).
Address Code Modification
System checks the ‘Address Code’ and ‘New Address Code’ fields. In case if both are
different then those records can be considered as address code changed records. The
modified record including ‘New Address Code’ value wil be updated in the system and the
mapped fields at address code maintenance (STDADMNT) level would be updated
accordingly. The modified values are also updated at account level.
Address Code Deletion
Address files which are not available as part of the uploaded file are identified as deleted files.

System marks the address code as closed if no customer or accounts are linked to the
address code.
System does not closed mark the address code as closed if it is linked to customers or
accounts. In this case, deletion is handled procedurely by bank. The system displays an error
code, ‘Address code for closure is linked to customer/accounts. Hence address code could not be
closed’
9 byte Address Code Upload
Data Type = 981/986
Data type 981 and 986 are treated as new data entry. System adds the records and these will
be available at address code maintenance screen(STDADMNT).In case a record for the
address code already exists in the system, a error message will be displayed.
Date Type = 982
Data type 982 refers to modified address codes. System updates the changes to the attributes
of a address code record and reflects the same in address code maintenance screen,
customer and account screens.
Data Type = 983
Data type 983 refers to deleted entries. The sytem does the following:

Mark the address code as closed if no customer or accounts are linked to it.

Displays an error if the address code is linked to a customer or account.

Displays an error if the address code does not exist in the system.
Data Type = 984
Data type 984 are marked for expiry. These address codes are set for expiry after a scheduled
period. These address codes are automatically checked for ‘Mark for Expiry’ in the address
code maintenance screen.
Data Type = 985
Data type 985 are address codes marked as expired. System marks these address codes as
closed if they are not linked to any customer of accounts.
System displays an error if the address code is linked to a customer or account and cannot
be closed.
5-30
5.1.15
Address Code Summary
You can view the summary of the address code maintained in the ‘Address Code Summary’
screen. You can invoke this screen by typing ‘STSADMNT’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
Specify the following details:

Authorization Status

Record Status

Address Code
System displays the following:

Authorization Status

Record Status

Address Code
For more details on how to create user Defined fields, refer chapter ‘Creating custom fields in
Oracle FLEXCUBE’ in the User Defined Fields User Manual under Modularity.
5.2
Maintaining Tax Cycle
You can maintain tax cycle at the bank level through the ‘Tax Cycle Maintenance’ screen.
Invoke this screen by typing ‘STDTXCYL’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
5-31
The screen is as shown below:
Tax Cycle
You need to define the tax cycle, which will be uniquely identified in the system
Start and End dates for tax cycle
You need to indicate the start and end date of the tax cycle you are defining, using the
adjoining calendar.
5.2.1
Updating Tax Cycle
The Current Tax Cycle would be updated as and when the tax cycle changes. This would be
done during authorization of date change function on the first day of the new Tax Cycle.
5.2.2
Maintaining Tax
To maintain Tax parameters at the branch level, click the ‘Tax’ button in the Branch
Parameters Details screen.
5-32
The screen appears as shown below:
Tax Cycle
This is the current tax cycle for the branch. This is a display field. Whenever the tax cycle
changes, the field is updated during the date change authorization for that day.
Consolidated Tax Certificate Required
Check this option to indicate Consolidated Tax Certificate is required for all the transactions
done in the Tax Cycle. This option works in conjunction with a similar option in the Customer
Information Maintenance and the Tax Category Maintenance screen.
The Consolidated Tax Certificate would be generated at the frequency specified at the branch
level. Apart from this, the certificate would also be generated at the end of the Tax Cycle. The
consolidated tax certificate would always display all the transactions pertaining to the current
Tax Cycle.
Individual Tax Certificate Required
Check this option to indicate Individual Tax Certificate is required for individual transactions
under the selected tax category. This option works in conjunction with a similar option in the
Customer Information Maintenance and the Tax Category Maintenance screen.
Tax Certificate Frequency
This field is enabled only if the Consolidated Tax Certificate option is checked.
You need to specify the frequency with which the tax certificate should be generated. This
would be a combination of the Tax Certificate Frequency and the Tax Certificate Day. It could
be any of the following:

Monthly - This indicates that the tax certificate would be generated every month. The
day of the month on which the Tax Certificate would be generated is defined in the Tax
Certificate Day field.

Quarterly (Q) – This indicates that the tax certificate is generated once in three months.
The end-month for the first quarter is defined in the Tax Certificate Day field. The
Certificate would be generated on the last working day of the month defined in the Tax
Certificate Day field. Subsequent end-months would be derived by the system.

Half Yearly (H) – This indicates that the Tax Certificate would be generated once in six
months. The end-month for the first half-year period is defined in the Tax Certificate Day
field. The Certificate would be generated on the last working day of the month defined
in the Tax Certificate day field. Subsequent end-months would be derived by the
system.
5-33

Yearly (Y) – This indicates that the tax certificate would be generated once a year. The
month in which the certificate needs to be generated is defined in the Tax Certificate
Day field. The Certificate would be generated on the last working day of the month
defined in the Tax Certificate Day field.
Frequency Value
Select the appropriate month for tax certificate generation, from the adjoining drop-down list.
5.2.3
Maintaining Clearing Currencies
You can maintain a list of currencies in which clearing transactions can be processed under
a branch. In order to achieve this, you need to invoke the ‘Clearing Currency’ screen by
clicking the ‘Branch Currency’ button in the ‘Branch Parameters – Detail View’ screen.
Here you can capture the following details:
Branch Code
The branch code gets defaulted from the ‘Branch Parameters – Detail View’ screen. A brief
description of the branch is displayed alongside.
Currency Code
Specify the currency in which you wish to allow clearing transactions under this branch. You
can specify multiple currencies for a branch. Click on the adjoining option list and select the
appropriate code from the list of currencies maintained in the system.
Currency Description
A description of the chosen currency code is displayed here
5.2.4
Account Statement Handoff
The account statement handoff will consider the movements on accounts based on the
Statement Date and not the Transaction Date. The Statement Status Change will itself run the
Account Statement handoff for the previous working date before marking the Branch
Statement Status as ready.
5.2.5
Account Statement Generation
Accounting entries with Statement Date lying between From Date and To Date populated in
the handoff records will be picked up for Account Statement Generation processing.
5-34
5.3
Maintaining Role to Head Mapping at Branch Level
You can maintain different General Ledgers for different branches for the accounting roles
defined in the system. If you have maintained Role to Head mapping for a product at the
branch level, the system uses these accounting heads instead of the heads maintained at the
product level.
You can maintain Role to Head mapping for a combination of branch, product and status in
‘Branch Level Role to Head Mapping’ screen. You can invoke this screen by typing
‘CSDACRHM’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
You can specify the following details in this screen:
Branch Code
The branch code of the current branch gets defaulted here.
Branch Name
The name of the current branch corresponding to the branch code gets displayed here.
Product Code
Specify the product code for which you wish to maintain role to head mapping or select the
product code from the option list provided.
Status
Specify the status code for which you wish to maintain role to head mapping or select the
status code from the option list provided.
Accounting Role
Select the accounting role to be used for role to head mapping, from the option list provided.
Accounting Head
Select the GL accounting head to be used for role to head mapping, from the option list
provided.
5-35
You can add more rows to accounting role and heads by clicking the ‘plus’ icon provided. You
can also delete a row from this table by selecting the required row and clicking the ‘minus’
icon.
Note
The accounting roles and heads maintained here will override the default role head mapping maintained for the product.
5.3.1
Viewing Accounting Role to Head Mapping Details
You can view the details related to accounting roles and heads for a branch in ‘Branch Level
Role to Head Mapping Summary’ screen. You can invoke this screen by typing ‘CSSACRHM’
in the field at the top right corner of the Application tool bar and clicking the adjoining arrow
button.
The following details get displayed in this screen:

Authorization status

Record status

Branch code

Product code

Status
5-36
6. Account Branch Transfer
6.1
Introduction
You may get request from the customers for change of account branch. Oracle FLEXCUBE
allows you to transfer a customer account from one branch of the bank to another. You can
also transfer the all accounts that belong to an account class to a different branch at once.
This chapter explains the required maintenances and the methods to process account branch
transfer.
6.2
Maintaining Branch Transfer Parameters
In order to facilitate this, you need to maintain the branch transfer parameters using ‘Branch
Transfer Parameters Maintenance’ screen. To invoke this screen, type ‘CSDACTRP’ in the
field at the top right corner of the Application toolbar and click the adjoining arrow button.
Specify the following details:
Transaction Code
Specify a unique transaction code. The system will use this transaction code to post the
accounting entries while processing the account balance transfer from one branch to another.
Note
Ensure that the options ‘Account Activity’, ‘Cheque Mandatory’, ‘IC Transaction Count’, ‘IC
Turnover Inclusion’ and ‘IC Penalty’ are not checked on ‘Transaction Code Maintenance’
screen.
Transfer Bridge GL
Specify the bridge GL to be used while moving the account balance from one branch to
another.
6-1
Process Mode
Specify the mode of processing the account transfer. The drop-down list displays the following
options:
l
Sequential – If you choose this, the system will process the transfer in a sequential order
l
Job – If you choose this, the system will process the transfer as job
Choose the appropriate one.
Number of Parallel Jobs
Specify the number of parallel jobs. This is the maximum number of jobs that may be
submitted for processing at the same time.
Commitment Frequency
Specify the commitment frequency. While processing the transfer batch, the system will
perform commits based on the frequency set here.
6.3
Transferring Customer Account Branch
Using Oracle FLEXCUBE, you can transfer a customer account from one branch of the bank
to another. The account branch transfer is processed using ‘Account Transfer’ screen. To
invoke this screen, type ‘CSDACCTR’ in the field at the top right corner of the Application tool
bar and click the adjoining arrow button.
Specify the following details:
Transfer ID
The system generates a unique transfer ID. This will be used as a unique identifier of the
account transfer.
Current Branch
Specify the current branch of the account. On processing the transfer, the system will move
the account from this branch to the target branch.
6-2
Current Branch Name
The system displays the name of the current branch.
Target Branch
Specify the target branch code. The option list displays all valid branch codes maintained in
the system. Choose the appropriate one.
On processing the transfer, the system will move the account from the current branch to the
branch selected here.
Target Branch Name
Based on the branch code selected, the system displays the name of the target branch.
Transfer Date
Specify the effective date of the account branch transfer. Click the date button to choose a
date from the calendar.
The transfer date must be a date in the future. You cannot process the transfer on the current
date or a past date.
Account Details
You need to specify the following account details:
Account Number
Specify the account number that you need to transfer. The option list displays all valid account
numbers at the selected branch. Choose the appropriate one.
Account Description
Based on the account selected, the system displays the description.
Customer Number
Based on the account selected, the system displays the customer number.
Customer Name
Based on the customer number selected, the system displays the name of the customer.
Once you have captured the details, save the record. The system will process the account
transfer on the transfer date.
6-3
6.3.1
Viewing Account Branch Transfer Details
You can search and view the details of account branch transfer using ‘Branch Transfer Log’
screen. To invoke this screen, type ‘CSDACLOG’ in the field at the top right corner of the
Application toolbar and click the adjoining arrow button.
You can search for the account transfer details based on one or more of the following
parameters:
l
Transfer ID
l
Account number
l
Transfer date
l
Customer number
l
Source/current branch
l
Target branch
l
Status of the transfer record (Success/Error)
l
Account class
Once you have set the search parameters, click search button. The system displays the
account transfers that match the search criteria. Double-click a record to view the details.
Note
The system will not process the account transfer in the following circumstances:
–
The account is a Nostro type account
–
Local currency of the current branch and the target branch are different, in case of
individual account transfer
–
Minor age limit is different for the current branch and target branch
6-4
Note
6.4
–
Staff restriction, account class restriction and branch restriction are applicable while
maintaining details of individual account transfer.
–
You can mark for rerun the accounts with status ‘Error’ by clicking ‘Resubmit’ button. Such accounts are processed during EOD operations on the next day.
Transferring Account Class
You can transfer all accounts that belong to an account class, from one branch to another,
using ‘Account Branch Class Transfer’ screen. To invoke this screen, type ‘CSDACLTR’ at
the top right corner of the Application toolbar and click the adjoining arrow button.
Specify the following details:
Transfer ID
The system generates a unique transfer ID. This will be used as a unique identifier of the
account class transfer.
Current Branch Code
Specify the current branch of the account class. On processing the transfer, the system will
move the accounts that belong to the selected account class from the current branch to the
target branch.
Current Branch Name
The system displays the name of the current branch.
Target Branch Code
Specify the target branch code. The option list displays all valid branch codes maintained in
the system. Choose the appropriate one.
6-5
On processing the transfer, the system will move the accounts that belong to the selected
account class from the current branch to the target branch selected here.
Target Branch Name
Based on the branch code selected, the system displays the name of the target branch.
Transfer Date
Specify the effective date of the account branch transfer. Click the date button to choose a
date from the calendar.
The transfer date must be a date in the future. You cannot process the transfer on the current
date or a past date.
Account Class
Specify the account class that you need to transfer. The option list displays all valid account
classes maintained in the system. Choose the appropriate one.
Account Class Description
Based on the account class selected, the system displays the account description.
Once you have captured the details, save the record. The system will process the account
transfer on the transfer date.
6.5
Processing Account Branch Transfer
During Beginning of Day Operations, the system will check the accounts whose transfer date
is the current system date. These accounts are processed by the account branch transfer
batch (ACDTFRBT), which is triggered as part of BoD operations.
The system verifies the balances of the accounts to be processed. There can be two cases
as follows:
l
Negative balance – If the account balance is negative, then the system will debit the
transfer GL and credit the account to make the balance zero.
l
Positive balance – If the account balance is positive, then the system will debit the
account and credit the transfer GL to make the balance zero.
Further, the system updates the remaining necessary account information. The new branch
code is updated in messages, statements and all branch related information specific to the
account.
Note
The system will not process the account transfer in the following circumstances:
–
The target branch is not allowed for the account class
–
The account has uncollected, unauthorized or tanked balance
–
The account status is ‘Frozen’, ‘Deceased’, ‘No Debit’ or ‘No Credit’
–
The account is a Nostro type account
Once the details are updated, the system transfers the balance back to the account from the
transfer GL.
6-6
Auto deposits linked to the account is handled as follows:
l
Auto deposit maturing on the transfer date – The system does not transfer the auto
deposits that mature on the date of transfer.
l
Auto deposit maturing in the future – The system transfers the auto deposits that mature
on a future date.
In case of a customer portfolio transfer or a bank merger, the accounts will be transferred to
the corresponding branch. For further details on customer portfolio transfer and bank merger,
refer to the sections ‘Transferring Customer Portfolio’ and ‘Merging of Branches’ in chapter
‘Branch Transfer of Loans’ of Retail Lending user manual.
6-7
7. System Dates Maintenance
7.1
Introduction
In the ‘System Dates Maintenance’ screen you maintain the system dates for your branch, for
instance, the business date for your branch, which is the booking, date for all transactions
input in the branch.
The dates screen is maintained at the branch level by the respective branches. Invoke this
screen by typing ‘STDDATES’ in the field at the top right corner of the Application tool bar and
clicking the adjoining arrow button.
In this screen the following fields are maintained for your branch:
You define today’s date, previous working date and next working date, for the first time, during
installation of the system (for details refer to the installation manual).
Suppose Oracle FLEXCUBE is installed on 1 January 1998, in your bank. In the dates screen
you would input the following:
Today’s date: 01-JAN-1998
Previous working date: 31-DEC-1997
Next working date: 02-JAN-1998
After EOD for a branch is run, the system will not allow you to run any other operation in the
branch, till a date change has been invoked.
If you try to run any other application, you will be prompted to invoke a date change first.
l
Simultaneously two different branches can be running on two different system dates.
This may happen when EOD for a branch is delayed for some reason.
7-1
l
7.1.1
Based on ‘today’s date’ (post authorization) the system computes and updates the
‘Current financial cycle’ and the ‘Current period’ in the Branch Parameters screen.
Maintaining Dates Change
For maintaining date change, invoke the ‘System dates maintenance’ screen after EOD for
the day is run. Click ‘Unlock’ in the Action menu or click unlock icon. The system populates
the default dates in the screen.
For instance, on the first working date i.e., 2nd of January, 1998; the system dates will be
updated to:
Today’s date = 02-Jan-1998
Previous working date = 01-Jan-1998
Next working date = 03-Jan-1998
‘Today’s date’ is defaulted from ‘Next working date’ of the old record. ‘Previous working date’
is defaulted from ‘today’s date’ of the old record. The ‘Next working date’ is picked up from the
‘Local branch holiday calendar’ as maintained by you. You can modify ‘today’s date’ and the
‘next working date’ by either clicking unlock icon on the toolbar/selecting ‘unlock’ from the
action menu.’ Previous working date’ cannot be modified.
Today’s date, if modified, should always be greater than the ‘previous working date’ and less
than the ‘next working date’. Similarly, ‘next working date’ if modified should be greater than
‘today’s date’. On modifying the dates, the system will ask you for an override. On
confirmation the change will be effected.
Date change should be immediately authorized because no application of Oracle FLEXCUBE
can be run without date change authorization.
l
If you have input any date modification, you cannot authorize it. A user with a different
login ID should do it.
l
For a branch you can have only one system dates record
l
Any modification in date, (be it an authorized or unauthorized record), can be done any
time after today’s EOD and before BOD for the next day is run. You can modify the ‘next
working date’ any time before running the EOD for the current day.
To authorize, click authorize icon on the toolbar. If any modifications were made, on the
system date, the old and the new values will be displayed. After which an alert box will warn
you that the dates change will be authorized. You will be prompted to confirm. Click
to
confirm. The change will be authorized. If you do not want to authorize the change then click
delete icon, you will be returned to the screen from where you invoked the authorization
function. Click ‘Exit’ button to exit and return to the Application Browser.
7-2
8. Web Service Maintenance
8.1
Introduction
Oracle FLEXCUBE supports a generic functionality to call external web services. The
operations done on the screens have the information of web services. The request processed
during the operations is analyzed and the web service is enabled. This chapter takes you
through the WebService Maintenance, WebService Mapping and other details regarding
WebService.
8.2
Maintaining Web Service
You can maintain Web service through WebService Maintenance screen. You can invoke this
screen by typing ‘CSDEXTWS’ in the field at the top right corner of the Application tool bar
and clicking the adjoining arrow button.
Specify the following here:
WebService Code
The unique code for the web service s defaulted here.
WebService Description
The description of the web service is displayed here.
WebService User
The system displays the user of the web service.
WebService Password
The system displays the password with which the web service is invoked.
WebService Server IP
The system defaults the IP address of the server where web service is installed.
8-1
WebService Server Port
The system displays the port of the server where web service is installed.
WebService Server URI
The system defaults the URI of the server where web service is installed.
8.2.1
Mapping of Web Service
WebService mapping is attached to the transaction screens for which web service call is
required. You can invoke this screen by typing ‘CSCEXWSO’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
WebService Code
Select the unique web service code from the adjoining option list.
Call Sequence Number
The unique sequence number for the web service is displayed here.
Calling Stage
Select the stage at which web service should be called from the drop-down list.
Status
The system defaults the status of the web service.
8-2
8.2.2
Web Service Details
Web Service details is attached to the maintenance screens for which web service call is
required. You can invoke this screen by typing ‘CSCEXWSM’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
WebService Code
Select the unique web service code from the adjoining option list.
Call Sequence Number
The system displays the unique sequence number for the web service.
Calling Stage
Select the stage in which the web service should be called from the drop down list.
Status
Select the status of the web service from the drop down list.
Note
–
When any operation is done in the screen and call to back end is made, the request
built during this process will have the information of web services to be called. The
web service call will be made based on the status of each web service which will be
updated in the backend.
–
The details of an external web service is taken from the maintenance screen based
on the web service code mentioned in the call form. Each web service should be
deployed in the URL mentioned in the maintenance before processing the request.
–
A flag will be set to find whether the request contains the web service information
and the same will be used for parsing the request in the application server. Call to
the web service is based on the request format that particular web service accepts.
The request to the web service should be in that format and it can be written in the
handler class provided.
Sending request to back end involves two cases:
l
If in the request, option to call the web service is pre, then the web service will be called
and the response from the web service will be appended in the request before sending
it to the back end.
8-3
l
8.2.3
If in the request, option to call the web service is post, then the request will sent to back
end first and the response from the back end will be sent to the web service. The
response from the web Service Call will be appended in the request and sent to the
backend again.
WebService Maintenance
Web Service Maintenance is attached to the maintenance screens for which web service call
is required. You can invoke this screen by typing ‘CSDEXWSD’ in the field at the top right
corner of the Application tool bar and clicking the adjoining arrow button.
WebService Code
The system displays the unique code of the web service
Call Sequence Number
The system displays the unique sequence number of the web service
Calling Stage
Select the stage in which the web service should be called.
Status
The system defaults the status of the web service.
Key ID
The system defaults the ID for which the web service is called.
Request
The system displays the request of the web service.
Response
The system displays the response of the web service.
8-4
9. Accounts for Inter-Branch Transactions
9.1
Defining Accounts for Inter-Branch Transactions
A transaction that takes place in a branch of your bank may involve accounts that are
maintained in another branch. For example, a customer has an account in the Head Office
branch and approaches another branch of the bank for a cash withdrawal.
For each combination of branches that may be involved in an inter-branch transaction, you
can define the currency and the respective customer accounts to which the related accounting
entries will be posted.
The accounting entries for such inter-branch transactions can be routed in one of the following
ways:

Directly - where each branch will have a direct accounting relationship with all other
branches

Through a Regional Office -- where two branches involved in a transaction will interact
through a common RO

Through the Head Office -- where the two branches involved in the inter-branch
transaction will interact only through the HO.
This route for all transactions is defined in the ‘Bank parameters’ screen.
In the ‘Inter-branch Parameters Maintenance’ screen you define the internal accounts for
pairs of branches that would be involved in any inter-branch accounting.
Invoke this screen by typing ‘ACDIBMNT’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
9-1
The screen appears as shown below:
In this screen you maintain the following for each combination of branches that may be
involved in an inter-branch transaction:

Branch Code of both the branches that are involved in the transaction

For each of the branches, whether inter-branch entries must be posted in transaction
currency or settlement account currency

Customer accounts of Branch 1

9.1.1
–
Due to Branch 2
–
Due from Branch 2
Customer accounts of Branch 2
–
Due to Branch 1
–
Due from Branch1
System Features
The system generates a set of pairs of branches for which internal accounts should be
maintained. The pairs generated depend upon on two factors:

The reporting structure for the branches as created in the ‘Branch parameters’ screen
and

The route defined for inter-branch transactions in the ‘Bank-wide parameters -Preferences’ screen,
9-2
For example, the following represents the reporting structure of your bank:
If you have defined a direct inter-branch accounting route then you need to maintain an
accounting relationship for each possible combination of

Branch and branch

Branch and RO

RO and HO

Branch and HO
For the above mentioned reporting structure the system will offer the following pairs of branch
combinations to be maintained:
1. BR1- BR2
2. BR1- RO1
3. BR2- RO2
4. RO1- HO
5. RO2- HO
6. BR1 - RO2
7. BR2 - RO1
8. BR1 – HO
9. BR2 – HO
10. RO1 - RO2
If you have defined ‘through RO’ inter-branch accounting route then you need to maintain an
accounting relationship for each possible combination of

Branch and RO/HO

RO and RO
In the branch and RO pair, the RO should be that RO to which this branch reports. For the
above mentioned reporting structure the system will offer the following branch pairs to be
maintained:
1. BR1 - RO1
2. BR2 - RO2
3. RO1 – HO
4. RO2 – HO
5. RO1 - RO2
If you have defined ‘through HO’ inter-branch accounting route then you need to maintain an
accounting relationship for each possible combination of,

Branches and HO
9-3

ROs and HO
For the above mentioned reporting structure the system will offer the following branch pairs
to be maintained:
1. HO - RO1
2. HO - RO2
3. HO - BR1
4. HO - BR2
The system has an in-built auto escalation path for inter-branch accounting transaction which
escalates from Direct to Through RO to Through HO.
For example, in the ‘Bank preferences’ screen you have defined a ‘direct’ inter-branch
accounting relationship. But in the ‘Inter-branch Accounts’ maintenance screen (where all
inter-branch accounts are maintained), you have not maintained an accounting relationship
between two branches -- 000 and 002. Then, in case of an inter-branch accounting
transaction between 000 and 002, the system will first look for a ‘direct relationship’ since that
has not been maintained it will look for a relationship through RO i.e., if the two branches have
a common RO; if that too does not exist then ‘through HO’ the transaction would take place.
9.1.2
Specifying Customer Accounts
System determines the settlement route for inter-branch transactions by considering the
customer accounts that you specify for a particular currency in this screen.
For example, your bank has to processes a transaction in USD involving your branch (Branch
Code 001) and another branch (Branch Code 002). If you maintain the customer accounts for
the branch pair 001-002 and currency USD, system will accordingly determine the settlement
route.
Branch1 and Branch2
To specify a branch pair for which you want to define the customer accounts, you can choose
from a list of maintainable branch pairs displayed by the System. The description of Branch 1
and Branch 2 are displayed below the respective branch codes.
9.1.2.1
Specifying General Ledger Details
Specify the customer accounts which are involved in the inter-branch transaction, in the
respective branches
To maintain customer accounts for the branch pair specified, the following parameters should
be maintained:
Inter Bank Currency
For each branch, you have the option of specifying whether the inter-branch entries must be
posted in the transaction currency or the settlement account currency.
For the booking branch, if the Inter-branch Transaction Currency option specified is
Transaction Currency, inter-branch entries are posted in the transaction currency only if:

The local currency of both branches involved in the transaction is the same

One of the accounts in the entries belongs to the booking branch
Due To Branch 2
This field identifies the customer account maintained in Branch 1 into which the credit
accounting entry is passed.
9-4
To specify the customer account, select the appropriate account from the picklist of all the
customer accounts maintained at Branch 1 .
Due From Branch 2
This field identifies the customer account maintained in Branch 1 into which a debit entry will
be passed.
Due to Branch 1
This identifies the customer account maintained at Branch 2 into which a credit entry will be
passed.
Due From Branch 1
This account identifies the customer account maintained at Branch 2 into which a debit entry
will be passed.
System uses the customer accounts specified in this screen and determines the settlement
route for a transaction between two different branches of your bank.
9.2
Defining Accounts for Inter-Branch Fund Transactions
A fund transaction that takes place in a branch of your bank may involve accounts that are
maintained in another branch.
As mentioned earlier, if you have selected the option ‘Allow Corporate Access’ in the Branch
Parameters screen and the branch is a fund branch, the IB Entity will be defaulted as General
Ledger. The GL that will be used will be based on the maintenance in the Fund Inter Branch
Accounts Maintenance screen, for the fund id.
To invoke this screen, type ‘IADIBMNT’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.I
For a fund id, specify all the details necessary to define the Inter branch GL that will be used.
The option list against the field Fund ID includes all the valid funds maintained in the system.
For an explanation on each of the other fields, refer to the previous section.
9-5
9.2.1
Querying on Netting Batch
You can view all netted and non-netted transactions of the netting process from the ‘Netting
Batch Query’ screen. You can invoke this screen by typing ‘STDNETQY’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
You can query on the basis of one or more of the following parameters:

Netting Group Code

Account Number

Date
On searching, the system displays the following details:

Netting Reference Number

Date

Branch Code

Account

Module

Event

Reference Number

Transaction Code

Amount Tag

Debit/Credit Transaction

Account Currency

Foreign Currency Amount

Local Currency Amount
9-6
10. Currency Maintenance
10.1 Introduction
In the ‘Currency Definition’ screen, you define the attributes of the currencies in which your
bank can deal. For each currency, you can define attributes like, the SWIFT code for the
currency, the country to which the currency belongs, the interest method, the spot days, the
settlement days, etc.
Currencies can be maintained only at the Head Office. The list of currencies will be made
available to all the branches of your bank.
Invoke this screen by typing ‘CYDCDEFE’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
10.2 Maintaining Currency Details
Currency Code
Currencies are identified in Oracle FLEXCUBE by the SWIFT codes assigned to them. The
currency will be identified by this code in all transactions that involve it.
Currency Name
You can enter the detailed name of the currency in not more than thirty-five alphanumeric
characters.
Currency Type
As per your bank’s requirement you can choose to classify currencies into different currency
types. The bank can use its own discretion to decide the basis of classifying currencies into
different currency types. A currency type can consist of a maximum of three characters.
Depending on the customer account mask maintained, the value in the currency type field
would be used during the generation of customer account numbers through the Customer
Accounts Maintenance screen.
10-1
If you have decided to include currency type as part of the customer account number (in the
account number mask), then at the time of creating a new customer account number, you will
need to select the currency of the account number being generated. In the option-list provided
for currency, the currency code is displayed along with the associated currency type say, USD
– 1, GBP – 2 etc. When the account number gets populated, it is the currency type that forms
a part of the customer account number.
ISO Numeric Currency Code
Specify the currency code specified by the International Standardization Organization.
Country
After you have identified the currency, you should indicate the country to which the currency
belongs. You can select a country code from the option list available.
Decimals
You can indicate the number of decimal units up to which the currency can be denominated.
The number of decimals allowed for any amount in the currency can be:
0 - Currency with no decimals
2 - Currency with two decimals
3 - Currency with three decimals
Interest Method
You can indicate the interest rate to be used for transactions that involve this currency. The
interest options available are:

Actual/Actual

30(US)/360

Actual/360

30(Euro)/365

30(US)/365

Actual/365

30(Euro)/Actual

30(US)/Actual

Actual/Actual
Select the interest method that should be used by default whenever the currency is used in
transactions. While processing a transaction that involves this currency, the interest method
defined for the currency is defaulted. You have the option to change it for a specific
transaction.
However, if you do not specify an interest method for a transaction, the method defined for
the currency will be used (For details refer to the Annexure in this User Manual).
Spot Days
The number of spot working days applicable for the currency is specified here. Payment
advises for FX and MM contracts will be generated on a date, which is calculated as the
number of spot working days before the Maturity Date of the contract.
For example, the tenor of an MM contract is as follows:
Value Date - 01/01/99
Maturity Date - 31/01/99
10-2
Contract Currency - USD
Contract Amount - 5000
For USD, the number of Spot Days is specified as: Spot Days - 3
For this contract, the payment advices will be sent on 28/01/96.
Foreign Exchange Netting Days
Oracle FLEXCUBE provides a facility wherein all transactions relating to a customer, meant
to be settled on a particular day and are made before a specific cut off day are collated, netted
and a single payment message is sent instead of individual messages for each payment. This
cut off day can be parameterized and is called ‘Netting Days’. The number of FX netting days
applicable for the specified currency is maintained here.
Note
The system will validate that the FX Netting days are lesser than or equal to the spot days.
Settlement Days
In this screen, you can specify the ‘Settlement Days’ for a currency. Settlement messages for
the components of a contract (in the LC, BC, LD, MM, FX, and FT modules) will be generated
according to the settlement days specified for the currency of the settlement account. The
following example illustrates this.
For example, when maintaining the details of USD in the Currency screen, you specify the
‘Settlement Days’ as ‘2’. This implies that two working days prior to the settlement of a
component through a USD account, a settlement message will be automatically generated if
specified (when you run the Settlement Messages function at the end of day).
The settlement details of a contract are as follows:
Settlement Date: 06 May 1999
Settlement Account Currency: USD
Component: Principal
Settlement Message: Yes
Component Currency: GBP
When you generate the Settlement Messages function, at the end of day, on 04 May 1999, a
settlement message for the Principal component of the contract will be generated.
You can run Settlement Messages function as part of EOD operations from the Application
Browser to automatically generate settlement messages for contracts marked out for
automatic liquidation.
The settlement day specification for a currency will determine the contracts that are picked up
for settlement message generation.
Cut-off Time
The Currency Cut-off time refers to the time by which all transactions involving a currency
should be generated. For a currency, you can indicate the cut-off hour and minute. This time
should be expressed in the local time of the bank.
10-3
The maintenance of a cut-off time for a currency has particular reference to outgoing funds
transfers involving it.
Cut-off days
You can also specify the cut-off days and time for payment transactions involving the
currency.
For example, the value date of a funds transfer transaction (incoming payment) involving
USD, is 3rd June 2001. The number of cut-off days specified for the currency is 2. This means
that the payment must be received on or before 1st June 2001. If the payment is received on
1st June, it must be received before the cut-off time specified for USD.
If the USD cut-off time is 1200 hrs, then, if the payment is received on 1st June 2001, it must
be received before 1200 hrs.
The cut-off time (in hours and minutes) that you maintain to be applicable for payment
transactions involving a currency are applicable to the head office branch of your bank.
If the branches are in time zones other than the head office branch time zone, you must
maintain the offset time applicable for each branch, in the Branch Parameters screen.
Note
Even when cut-off days and cut-off time for a currency have both been specified, the cutoff checks are performed for a funds transfer transaction only if specified as applicable for
the product involved in the transaction.
Position or Position Equivalent GL for a currency
If you have opted for position accounting in your bank, you should indicate the Position GL
and the Position Equivalent GL, when maintaining a foreign currency, in the currency screen
(the Currency Definition screen).
When maintaining the GLs in your bank, you can opt to link the different foreign currencies,
associated with the GL to either of the following:

The Position GLs that you specify here (for the corresponding currency)

Position GLs of your choice
Tolerance Limit
When you are maintaining an ‘In’ Currency, or the Euro, in the Currency Definition screen, you
can define a ‘Tolerance Limit’ for it. The limit is expressed as a percentage.
The implication:
During the transition period, settlement of components in ‘In’ currencies can be made either
in the same currency or in the Euro (EUR) depending on the settlement account(s)
maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.)
In the settlement messages that are generated (MT 100, MT202), the settlement amount
would be reported in the Settlement Account Currency. However, you can opt to additionally
furnish the value of the component in Euro Related Information (ERI) currency. You have to
manually specify the settlement amount value, in the ERI currency, in the Settlement
Message Details screen.
When generating the message towards settlement (MT100, MT202), the system ensures that
the value you specify as the ERI Amount conforms to the Tolerance Limit defined for the ERI
Currency (in the Currency Definition screen). That is, the system computes the ERI equivalent
of the settling amount using the pegged rates, and compares the same against the ERI
10-4
amount input by the user. If the difference is within the tolerance limits defined for the ERI
currency, the user specified amount is used.
If the user specified ERI amount breaches the Tolerance Limit defined for the ERI currency,
the system calculates and reports the ERI Amount on the basis of the exchange rate defined
for the settlement currency vis-à-vis the ERI currency.
For example, in the SWIFT messages (MT 100 and MT 202) that are generated towards
settlement, the value of the component can be reported both in Nostro account currency (in
Field 32A) and in an ERI currency that you specify (in Field 72). In Oracle FLEXCUBE, this
information is captured in the European Related Information (ERI) fields in the Settlement
Message Details screen.
Assume the following scenario:

The settlement account is an EUR account

You have to settle an amount of DEM 10000

You have defined the ERI currency for DEM as DEM

The Tolerance Limit for DEM as 0.05%

The exchange rate: 1 Euro = 1.30 DEM
The settlement amount in Euro would therefore be 7692.36 (rounded to nearest higher cent).
This amount will be reported in Field 32A of the settlement messages. Now, if you want to
furnish the settlement amount in the ERI currency (in this case, DEM) you have to manually
enter the DEM value in the ERI Amount field. You may enter DEM 10000. (EUR 7692.36
actually converts into DEM 10000.068.)
The value that you have entered is well within the Tolerance Limit of 0.05% defined for DEM.
Therefore, this value will be reported in Field 72 of the settlement messages.
Since the Tolerance Limit for DEM is 0.05%, you can specify an ERI Amount between DEM
9995 and DEM 10005 (DEM 10000 * 0.05/100 = DEM 5). If you enter an ERI value exceeding
DEM 10005 or less than DEM 9950, the system recalculates the ERI Amount at the time of
generating the settlement messages. The recalculation will be on the basis of the pegged
rates between the Settlement Currency and the ERI currency.
Note
The system validates the ERI amount only when generating the settlement messages. It
does not validate the ERI amount at the time of input (in the Settlement Message Details
screen).
Index Base Ccy
Specify the currency that should be used to handle index-based securities traded by the
banks, wherein the deals are done in index currency and their settlement is done through the
local currency.
Generate 103+
You can enable the MT 103 + format option only if you would like to generate outgoing MT
103 messages in the MT 103 + format.
If you are enabling this option for a specific currency, ensure to also enable this option:

For your bank branch in the Branch Parameters Maintenance

For the customer of the contract, in the BIC Code Maintenance

For the product used by the contract, in the Product Preferences
10-5
Consequently, while processing transactions in the specified currency for such a customer,
branch and product, for which the MT 103+ option is enabled, the system generates outgoing
payment messages in the MT 103 + format.
Note
Since the system is also capable of processing incoming MT 103 messages in the MT 103
+ format. Therefore, during the upload process for your branch, the system considers an
MT 103 payment message to be of MT 103+ format for those customer, currency and
product combinations, for which the MT 103+ option has been enabled.
CLS currency
To allow customers of your bank to settle their FX deals via the CLS (Continuous Linked
Settlements) Bank, you can identify the currency to be a ‘CLS Currency’. FX deals in the CLS
currency only will be eligible to be routed through the CLS bank.
From the available list of CLS currencies, you can further maintain a list of ‘allowed’ or
‘disallowed’ currencies for a specific customer. Every customer who is a ‘CLS Participant’ will
be allowed to trade in all the available CLS currencies unless specifically mentioned.
Refer the ‘Continuous Linked Settlements’ chapter of the Foreign Exchange User Manual for
details on maintaining currency restrictions and other maintenances required for processing
CLS deals in Oracle FLEXCUBE.
Index Flag
Check this box to derive index rate of the currency in Lending module.
Validate Tag 50F
Check this box to indicate that validations need to be performed for the 50F details captured
for the ordering customer during contract input.
For more details on 50F validations, refer the chapter titled ‘Maintaining Addresses for a
Customer’ in Messaging System user manual.
Note
Customer cover messages are always generated in new format (MT202COV or MT205COV).
For more details on new cover message formats, refer settlements user manual.
10.2.1
Indicating Rounding Preferences
Rule
This refers to the method to be followed for rounding off fractional units of a currency. The
rounding preferences available are:

Truncate — The amount is truncated to the number of decimals specified for the
currency

Round Up — The amount is rounded up based on the number of decimals and the
nearest rounding unit

Round Down —The amount is rounded down based on the number of decimals and the
nearest rounding unit
10-6
For example,
Amount
before
Rounding
Rounding Method
No. of
Decimals
Rounding
Unit
Amount after
Rounding
1234.678
Truncate
2
-
1234.67
1234.678
Round up to the
nearest rounding unit
2
.01
1234.68
1234.678
Round down to the
nearest rounding unit
2
.01
1234.67
Unit
If you have selected Round Up or Round Down in the Rule field, you need to indicate the
nearest unit to which the rounding should take place. The number of units specified here
should not be greater than the number of decimals allowed for the currency.
Example
The decimal points specified for currency ‘A’ is 2. Rounding unit is .05
Amount for transaction is USD 100.326, which will be rounded off depending upon the decimals specified
and the rounding rule and rounding unit.
For Rounding Rule ‘Up’, the amount available for transaction would be USD 100.35. For rounding rule
‘Down’, the transaction amount would have been rounded down to 100.30
If the rounding rule was specified as ‘truncate’ then, the amount would have rounded off to 100.32 (simply,
knock off all decimal points beyond the stated decimals places to be rounded off). Thus whenever you
specify a ‘truncate’ option you need not state the ‘Rounding unit’.
10.2.2
Specifying Amount Format Mask
Specify the format in which amounts in this currency are to be displayed for contracts in this
currency. Two options are available:
999,999,999
9,999, 999, 99
The system defaults to the 999,999,999 format.
Euro Type
When maintaining a currency in the Currency Definition screen, you have to specify the ‘type’
of the currency with relation to transition phase of the European Economic and Monetary
Union (EMU). You can do this in the ‘Euro Type’ field.
Your specifications in this field enable you to handle the first phase of the EMU, which
commenced on 01 January 1999.
For more details on the manner in which Oracle FLEXCUBE handles the Euro, refer the
chapter ‘Handling the Euro’.
By choosing the appropriate option, you can indicate if the currency is:

The Euro

An ‘In’ currency

An ‘Out’ currency
10-7

‘Euro Closed’
National currencies of ‘In’ countries are referred to as ‘In’ currencies. When maintaining other
currencies, you have to choose the ‘Out Ccy’ option under Euro Type.
When the transition period ends, the national currencies of the participating countries would
cease to exist as valid legal tenders. The Euro would be the only legal tender in the
participating countries. Consequently, the Euro changes made to Oracle FLEXCUBE will no
longer be required.
You can turn off the changes at the end of the transition period by:
1. Closing all ‘In’ currencies, and
2. Choosing the ‘Euro Closed’ option (for the Euro)
10.2.3
Specifying Exchange Rate Limits
Click ‘PC’ button in the Currency Definition screen to invoke ‘Limits’ screen.
You can specify the credit limit and the debit limit for the exchange rate in this screen. The
transaction amount of a PC contract must not exceed the limit specified here.
10.2.4
Mapping Currency to Country
Click ‘Currency Country Mapping’ button in the Currency Definition screen to invoke ‘Clearing
Zones Country Codes for Currency’ screen.
10-8
The screen appears as shown below:
You can map a currency code to a country in this screen.
10.2.5
Specifying User Defined Fields
You can associate values to all the User Defined fields created and attached to the Currency
Definition Screen. You can view the list of User Defined fields associated by clicking the
‘Fields’ button.
The screen appears as shown below:
You can enter the value for the UDFs listed here in the ‘Value’ column.
For more details on how to create user Defined fields, refer chapter ‘Creating custom fields in
Oracle FLEXCUBE’ in the User Defined Fields User Manual under Modularity.
10.2.6
Annexure
The treatment for interest calculation varies with each of the interest calculation methods.
Each method is dealt with individually below:
10-9
Actual/Actual Method
10,000x10/100 x (31/365 + 84/366)
In this method, the number of days is calculated as follows:
Dec. -31 days (include from date exclude to date)
Jan -31 days
Feb.-29 days (leap year)
March - 24 days (include from date exclude to date)
Total = 31 + (31+29+24=84) =115
Note
When the interest period crosses from a non-leap year to a leap year (or otherwise), the
basis of actual days has to be treated separately in each year.
Therefore, the denominator for the 31 days in December is 365 as it is a non-leap year and
the denominator for the 84 days in 2000 is 366 as it is a leap year.
Actual /365 Method
10,000x10/100x115/365
In this method, the number of days is calculated as follows:
Dec. -31 days (include from date exclude to date)
Jan -31 days
Feb.-29 days (leap year)
March - 24 days (include from date exclude to date)
Total=31+31+29+24=115
Actual/360 Method
10,000x10/100x115/360
In this method, the number of days is calculated as follows:
Dec. -31 days (include from date exclude to date)
Jan -31 days
Feb.-29 days (leap year)
March - 24 days (include from date exclude to date)
Total=31+31+29+24=115
30 Euro/Actual Method
10,000x10/100 x (30/365+84/366)
In this method, the number of days is calculated as follows:
10-10
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)
Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)
March - 24 days (include from date exclude to date)
Total = 113 days
Note
When the interest period crosses from a non-leap year to a leap year (or otherwise), the
basis of actual days has to be treated separately in each year.
30 Euro/365 Method
10,000x10/100x114/365
In this method, the number of days is calculated as follows:
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)
Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)
March - 24 days (include from date exclude to date)
Total = 113 days
30 Euro/360 Method
10,000x10/100x114/360
In this method, the number of days is calculated as follows:
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)
Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)
March - 24 days (include from date exclude to date)
Total = 113 days
30 US/Actual Method
10,000x10/100 x (30/365+84/366)
In this method, the number of days is calculated as follows:
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual
number of days calculated.)
Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)
10-11
March - 24 days (include from date exclude to date)
Total = 113 days
Note
When the interest period crosses from a non-leap year to a leap year (or otherwise), the
basis of actual days has to be treated separately in each year.
30US/365 Method
10,000x10/100x114/365
In this method, the number of days is calculated as follows:
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual
number of days calculated.)
Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)
March - 24 days (include from date exclude to date)
Total = 113 days
30US/360 Method
10,000x10/100x114/360
In this method, the number of days is calculated as follows:
Dec. - 30 days (include from date exclude to date)
Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual
number of days calculated.)
Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)
March - 24 days (include from date exclude to date)
Total = 113 days
10.2.7
Specifying Currency Cut-Off Parameters
You can choose to restrict the time within which (or before which) funds transfer transactions
involving a specific customer, product, and a currency, must be received for processing. For
a specific customer, product, and a currency, you can specify a certain number of days before
which a transaction involving the combination must be received, as well as a cut-off time
before which transactions must be received. These parameters are known as currency cutoff parameters, and you maintain these parameters in the ‘Value Dated Spread’ maintenance
screen.
Invoke this screen by typing ‘FTDVDSPR’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
10-12
The screen is as shown below:
In this screen, you can maintain the cut-off time, cut-off days and the value spreads to be
applicable for:

Each customer, for a product and currency combination

All customers, for each product and currency combination
These currency cut-off parameters are validated in respect of a funds transfer transaction only
if currency cut-off checks are specified as applicable in the product preferences, for the
product involving the transaction.
For details about how the currency cut-off checks are applied on a funds transfer transaction,
refer the chapter ‘Processing a Funds Transfer Contract’ in the Funds Transfer User Manual.
10-13
10.3 Maintaining Currency Position Details
You can view the currency position through Currency Position Details screen. To invoke this
screen type ‘CYDCCYLS’ in the field at the top right corner and click the adjoining arrow
button in the application toolbar.
In this screen, system calculates and displays the currency positions for different currencies.
You can view the following positions of each currency in a selected branch:

Cash Position - This gives the currency wise cash position based on the transactions
booked across all the modules in Oracle FLEXCUBE. It considers the entries that are
formed under Asset, Liability, Income and Expenses GL heads for which ‘Report as
Accrual’ at GL Maintenance screen is not checked.

Spot Position - This position is derived based on the outstanding deals from various
modules for which the maturity date falls on the spot days as maintained in the
‘Currency Maintenance’ screen.

Forward Position - This position is acquired based on the outstanding deals from various
modules for which the maturity date falls after the spot days maintained in the ‘Currency
Maintenance’ screen.

Open Position - This position is a combination of Cash Position, Spot Position and
Forward Position

Accrual Position - This gives the currency wise position across all the modules in Oracle
FLEXCUBE considering the entries that formed under Asset, Liability, Income and
Expenses GL heads for which 'Report as Accrual' at ‘GL Maintenance’ screen is
checked.

Global Position - This position is a combination of Cash Position, Spot Position, Forward
Position and Accrual Position.
Note
Check ‘Report as Accrual’ field in ‘GL Chart of Accounts Maintenance’ screen to calculate
the accrual entries posted to this GL. This is displayed during the online query of FX positions. Depending on your selection in this field, system will arrive at the cash and accrual
positions.
10-14
Click ‘Spot Position’ to view the details of the deals that have contributed to spot position.
Click ‘Change Position’ to view the details of the deals that have contributed to change
position.
Click ‘Accrual Position’ to view the details of the deals that have contributed to accrual
position.
10-15
Click ‘Forward Position’ to view the details of the deals that have contributed to forward
position.
10.4 Handling Euro
On 1 January 1999, eleven countries that are part of the European Union embarked on the
first phase of economic integration, called the ‘Economic and Monetary Union’ (EMU). In
Oracle FLEXCUBE, the eleven countries participating in the first phase of the EMU are
referred to as ‘In’ countries and the respective national currencies as ‘In’ currencies. All other
countries are referred to as ‘Out’ countries.
The first phase of the EMU, referred to as the ‘transition period’, ushered in a new, single
European currency: the Euro (EUR). During this phase, the National Currency
Denominations of ‘In’ countries would co-exist with the Euro. That is, transactions involving
an ‘In’ currency would, typically, be routed through the Euro during this phase. At the end of
the transition period, in mid 2002, however, the national currencies of the participating
10-16
countries would cease to exist as valid legal tenders. The Euro would be the only legal tender
in ‘In’ countries.
In Oracle FLEXCUBE, you can handle the Euro and the attendant implications for your bank,
by capturing additional currency and settlements related information. This chapter details how
this information is to be captured, and its implications.
10.5 Maintaining Euro Related Information
In Oracle FLEXCUBE, the details that you need to maintain in order to handle the EMU
include:

Maintaining Euro as a valid currency

Indicating if a currency is ‘In’, ‘Out, ‘Euro’, or ‘Euro Closed’

Maintaining Currency Redenomination details

A common conversion GL and a transaction code to identify the redenomination entry

Maintaining a ‘Tolerance Limit’ for a currency (to check against ERI information)

Capturing additional settlement details (Euro related information for the MT 100 and MT
202 SWIFT messages)
You can maintain currency related information in the Currency and the Currency Pair
Definition screens. ‘Settlement’ details can be captured in the Settlement Instruction Details
screen.
10.5.1
Maintaining Currency Details
Your specifications for a currency in the Currency Definition screen determine the manner in
which transactions in the currency are handled in Oracle FLEXCUBE.
Currency Type
When maintaining a currency in the Currency Definition screen, you have to specify the ‘type’
of the currency. You can do this in the ‘Euro Type’ field. Choose the appropriate option from
the following:

The Euro itself

An ‘In’ currency

An ‘Out’ currency

‘Euro Closed’
National currencies of ‘In’ countries are referred to as ‘In’ currencies. When maintaining other
currencies, you have to choose the ‘Out Ccy’ option under Euro Type.
When the transition period ends, the national currencies of the participating countries would
cease to exist as valid legal tenders. The Euro would be the only legal tender in the
participating countries. Consequently, the Euro changes made to Oracle FLEXCUBE will no
longer be required.
You can turn off the changes at the end of the transition period by:

Closing all ‘In’ currencies, and
10-17

Choosing the ‘Euro Closed’ option (for the Euro)
Tolerance Limit
When you are maintaining an ‘In’ Currency, or the Euro, in the Currency Definition screen, you
can define a ‘Tolerance Limit’ for it. The limit is expressed as a percentage.
The Implication:
During the transition period, settlements of components in ‘In’ currencies can be made either
in the same currency or in the Euro (EUR) depending on the settlement account(s)
maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.)
In the settlement messages that are generated (MT 100, MT202), the settlement amount
would be reported in the Settlement Account Currency. However, you can opt to additionally
furnish the value of the component in Euro Related Information (ERI) currency. You have to
manually specify the settlement amount value, in the ERI currency, in the Settlement
Message Details screen.
When generating the message towards settlement (MT100, MT202), the system ensures that
the value you specify as the ERI Amount conforms to the Tolerance Limit defined for the ERI
Currency (in the Currency Definition screen). That is, the system computes the ERI equivalent
of the settling amount using the pegged rates, and compares the same against the ERI
amount input by the user. If the difference is within the tolerance limits defined for the ERI
currency, the user specified amount is used.
If the user specified ERI amount breaches the Tolerance Limit defined for the ERI currency,
the system calculates and reports the ERI Amount on the basis of the exchange rate defined
for the settlement currency vis-à-vis the ERI currency.
The following example illustrates the application of the Tolerance Limit.
Note
The system validates the ERI amount only when generating the settlement messages. It
does not validate the ERI amount at the time of input (in the Settlement Message Details
screen).
10-18
Currency pairs
In the Currency Pair Definition screen, you can specify a ‘Through Currency’. When
maintaining a pair involving an ‘In’ currency (‘In’ – ‘Out’ and ‘In’ – ‘In’), you can only specify
the Euro as the ‘Through Currency’.
Note
You cannot maintain a ‘Through Currency’ for a pair constituted by an ‘In’ currency and the
Euro.
10.5.2
Maintaining Conversion GLs
To facilitate the currency conversion process, two additional parameters need to be
maintained in the ‘Branch Parameters’ screen. You have to maintain a common Conversion
GL and a Transaction Code that identifies redenomination entries.
The screen is as shown below:
10.5.2.1 Indicating Euro Redenomination General Ledger
Conversion GL
The conversion GL that you specify will be identified as the common Suspense GL for all
balance conversions while re-denominating the currency of an account either for specific
customers or for generic conversions.
Transaction Code
In addition to the conversion GL, you have to indicate a Transaction Code, which identifies
conversion related entries.
10.5.3
Implications of Currency Redenomination
In the IC Product Accounting Role Definition screen
For the purpose of currency conversion, an accounting role called ‘Acquired’ is available.
10-19
End of day processes
Maintaining a Conversion GL and Transaction Code simplifies the End of day process.
Basically two important things happen when the End of day processes are run. Firstly interest
is liquidated to the Acquired Interest GL and secondly all balances will be reduced to zero.
When you run the Beginning of day processes the next day the change in the currency
conversion will be in place. In addition balances will get restored.
Change in field values due to conversion
The change in currency re-denomination impacts amount based fields pertaining to Accounts,
Collaterals, Credit Lines and Customer Limits. The change in the value of these fields is
reflected when you run the beginning of day processes.
The amount-based fields, which are affected by the change in currency denomination, will be
updated with the equivalent value in the new currency
Accounts
The following fields will reflect the new values:

Temporary Over Draft limit

Sub-limit

Uncollected Funds limit

Offline limit

Account Currency
These fields can be found in the Customer Accounts Maintenance screen.
Collateral
In the Limits Maintenance Collaterals screen the following fields will be updated:

Collateral Currency

Collateral Value

Limit Contribution

Issuer Exposure Amount
Credit Lines
In the Limits screen of the Limits Maintenance module the following fields will reflect the new
values:

Credit Line Currency

Tenor limits

Tenor utilization

All Related Amounts
Customer Limits
In the Customer Maintenance screen of the Core Services module the following fields will be
updated at BOD.

Limit Currency

Liability Risk Limit

Customer Risk Limit
10-20
Note
Once the conversion process is complete the advices generated for your customer will carry the following information:
–
The Old Value
–
The New Value
–
And the Exchange Rate used for the conversion
As a consequence of currency re-denomination you will not be able to pass entries where
the value date falls before the currency conversion date.
10.5.4
Specifying Preferred ERI Currency for Counterparty
For a counterparty and currency (combination), you can maintain a preferred ERI currency.
You can state this preference in the ‘Settlement Instructions’ screen.
The Implication
During the transition period, settlements of components in ‘In’ currencies can be made either
in the same currency or in the Euro (EUR) depending on the settlement account(s)
maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.)
In the settlement messages that are generated (MT 100, MT202), the settlement amount
would be reported in the Settlement Account Currency. However, you can opt to additionally
furnish the value of the component in Euro Related Information (ERI) currency. You can
maintain this ERI currency (for a counterparty and currency combination) in the ‘Settlement
Instructions Maintenance’ screen.
In the SWIFT messages that are generated towards settlement of a component (involving the
counterparty and the currency), the component value will be expressed in this (ERI) currency,
by default. Invoke this screen by typing ‘ISDINSTN’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen is as shown below:
10-21
10.5.5
Specifying Settlement Message Details
SWIFT messages (MT 100/MT202) generated towards settlement can furnish the value of the
settlement amount in both the settlement account currency, and an ‘ERI’ currency. If you opt
to furnish the ERI value of the amount, you have to enter the following in the ‘Settlement
Details’ screen:

The ERI currency

The ERI Amount
The screen appears as shown below on clicking ‘Settlements’ button in the contract screen:
The system defaults to the ERI currency specified for the customer and currency combination.
You can change the default ERI currency. The ERI amount that you specify will be validated
against the Tolerance Limit specified for the ERI currency.
10.5.6
Settlements of Foreign Exchange Deals
Oracle FLEXCUBE allows cross currency settlements of foreign exchange deals that involve
an ‘In’ currency. You can settle the ‘In’ currency leg in another ‘In’ currency or in ‘Euro’.
10.5.7
Reports and Advices
The following reports furnish the equivalent Euro values of amounts in an ‘In’ currency. The
‘locked in’ exchange rates defined for the Euro against the ‘In’ currency will be used for
currency conversions.
The reports with this feature are the:

Currency Position report

Cash Flow report

FX Maturity report
10-22
Note
These reports will not furnish the ‘In’ currency and equivalent Euro values when you close
the ‘In’ currencies, and choose the ‘Euro Closed’ option (for the Euro) in the Currency Definition screen.
All advices that provide ‘In’ currency details will also provide the equivalent Euro values
Account Statements
Statements provided for accounts in an ‘In’ currency provide the Euro equivalent values of the
following:
10.5.8

The opening balance

The closing balance

Every transaction
Maintaining Limits Type
You can maintain various limit types and their values through the ‘Limits Types Maintenance’
screen. For example, you can define and maintain various Limit types like price codes,
collateral types and price through this screen.
You can invoke this screen by typing ‘LMDTYPES’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen is as shown below:
Type
Specify the limit type for which you want to maintain values
Description
Specify the description for the limit type you are maintaining
10-23
Values
The values for the limit type that you are maintaining can be listed here. To add a value to the
list of values, click on the ‘Add’ icon, and type the value. To remove a value from the list of
values, check the box against that value and click on the ‘Delete’ icon.
Value
Specify the list of supported values. For example, MAIL, COURIER, BRANCH and so on.
Code
Specify the codes for the list of value. For example, CO, ML and so on.
10.5.9
Maintaining Transaction Limits
This section explains in detail about maintaining transaction limits, level of authorisations
required for the transaction amounts and minimum user authorisation limit required for a
transaction.
Oracle FLEXCUBE offers you a facility, whereby, each time a particular transaction
processed in the system exceeds a certain limit; an override will be generated by the system.
You can maintain transactional limits for a module and product combination through the
‘Product Transactional Limits Maintenance’ screen. Invoke this screen by typing
‘CSDPLMNT’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
The screen appears as shown below:
Module Identification
Each module in Oracle FLEXCUBE is identified by a code. First, you have to identify the
module for which the currency-wise transactional limit is to be maintained. A list of all the
modules operational at your bank will be displayed in the option list. You can choose the
appropriate module code.
10-24
Module Description
The description associated with the module will be defaulted in the adjacent field.
Product Code
Each module contains a number of products within it. After you identify the module, indicate
the product within the module for which you would like to maintain a currency-wise
transactional limit. You can select the appropriate product code from the option list.
In the Product Transactional Limits screen, you can maintain the limits for:

A specific module and a specific product

A specific module and all products (select ‘ZALL’ as the Product Code)

All modules (Select ‘AL’ as the Module Code) and all products
Product Description
The description associated with the module will be defaulted in the adjacent field.
Source Code
Specify the source code based on which you need to maintain the product transactional limits.
The adjoining option list displays all valid source codes. The transaction limit amount
maintained for the selected source code is used to validate transaction limit while authorizing
the contract.
If the source code is available in Oracle FLEXCUBE, then the system enables all the fields
available under ‘Product Transaction Limit Details’ multi grid.
If the source code external, then the system enables only ‘Transaction Limit’ available under
‘Product Transaction Limit Details’ multi grid.
Note
You cannot select a source code more than once.
Transaction Limit Currency
The transaction limit currency is the currency in which you would like to maintain the amount
limit.
Customer Type
Select the type of customer for whom you are maintaining the transaction limits from the
adjoining drop-down list. The following are the options available:

Corporate

Individual

Bank

All
10.5.9.1 Specifying Product Transaction Limit Details
Specify the following transaction limit details:
Transaction Limit
Specify a transaction limit. Each time you process a transaction, the system checks the
transaction amount involved in the contract against the limit specified here. If the contract
currency is different from the transaction limit currency, then the system converts the contract
amount using the standard mid rate to the transaction limit currency and check against the
transaction limit amount maintained for the product
10-25
The system displays an appropriate message indicating the levels of authorization if the
transaction amount booked is in excess of the maintained transaction limit.
Level Of Authorization
Specify the number of authorisers to be involved in the authorising a particular transaction
amount.
Note
The level of authorization should be greater than one.
Minimum Authorization Limit
This option is enabled only if the ‘Cumulative’ option is checked. Specify the minimum
authorization limit required for a transaction. The authorization limit cannot be greater than the
transaction limit. This amount is used to validate authorizer limit while authorizing the contract.
Cumulative
Check this option to indicate that multiple authorisers are allowed to authorise a transaction.
The authorisers must have equal or greater than the minimum authorization limit maintained
in this screen. The system displays an appropriate error message if the authoriser tries to
authorise a transaction having transaction amount greater than the minimum authorising limit.
10.5.9.2 Validating Transaction Amount during Contract Processing
While saving a contract, the system will check the transaction amount against the cut-off
amount maintained for the module and product currency involved in the transaction. If both
the transaction currency and the limits currency are same, the comparison will be done
directly. If different currencies are involved, the system will first convert the transaction
amount into the cutoff amount currency using the STANDARD mid rate and then perform the
validations.
To perform the check, the System will look for the limits maintained, in the following order:
3. The System looks for the limits maintained for a specific module and specific product
combination
4.
If the first option is not available, it checks the limits maintained for a specific module +
ZALP (all products) combination
5.
It checks the maintenance for AL (all modules) + ZALP (all products) combination
If the third option is also not available, the system displays an error message
When a transaction exceeds the amount limit, the system displays an override message while
saving the transaction
10.6 Maintaining Sequence Generation Format
Every contract in Oracle FLEXCUBE is identified by a unique Contract Reference Number
that is generated internally by the system. You are not allowed to modify this number. In
addition, a contract is also identified by a unique User Reference Number. By default, the
Contract Reference Number will be taken as the User Reference Number. But you have the
option to change the User Ref Number.
Oracle FLEXCUBE also provides you the facility to generate the user reference number in a
specific format.
10-26
To maintain a specific format, you need to identify the various components that would be part
of the user reference number including details such as the length, order, value etc. of each
component.
You can maintain a unique format through the ‘Sequence Generation Input’ screen. You can
invoke this screen by typing ‘CSDSQGEN’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
You can maintain the following details of the sequence format:
Sequence Code
Each sequence format is identified by a unique sequence code. You can devise a code
comprising a maximum of 20 alphanumeric characters.
Branch Code and Module Code
You can maintain the format for a specific branch and module combination. Select the branch
code and the module code from the option-list. All authorized and active records will be
displayed in the list.
Alternatively, you can maintain a sequence format that will be applicable to all the branches
(ALL) and all the modules (AL) available in your bank.
Reset Frequency
You need to specify the frequency at which the system will drop and recreate the sequence
numbers once again. At the reset frequency that you specify, all sequence numbers of the
sequence format will be dropped and recreated again during the End of Day processing.
The options available are:

None

Daily

Monthly
10-27

Yearly
For example, let us assume that the running number in the sequence format is 4 characters
long (starting from 0001) and the reset frequency is Monthly. Further, let us assume that the
sequence number of the last contract processed on the last day of the month is 0199. At EOD
of the last day of the month, the sequence numbers generated till date will be dropped and
the system will begin regeneration starting from 0001 once again for all subsequent contracts.
Range
You can specify a range of sequential reference numbers. If you specify such a range, then
no additional details need be specified. If you do not specify a range, you can specify
additional details specific to each component of the sequence format.
In addition to the above details, you should also maintain details specific to each component
of the sequence format. The details are as follows:
Component Order
Each component is assigned an order number based on which they would appear in the user
reference number. The component order is automatically generated by the system and is noneditable.
Component
Each component in the sequence format is identified as one of the following:

An Oracle FLEXCUBE Component – If your sequence format uses an Oracle
FLEXCUBE column directly, you can specify it as an Oracle FLEXCUBE Component.
For instance, you may want to include the product group associated with the product
code involved in a contract, as a component in sequence number generation. To
achieve this, you will use the Oracle FLEXCUBE column PRODUCT_GROUP
(available in the table CSTM_PRODUCT) as an Oracle FLEXCUBE Component.

A User Component – You may want the first two characters of your bank’s name to be
part of all the user reference numbers generated at your bank. You can define it as a
user component. In addition, if you want to use the manipulated value of an Oracle
FLEXCUBE Column in the sequence format, you can specify it as a User Component.
For eg, you may want to include ONLY the first four characters of the product group in
the sequence number. In this case, the component would be defined as a User
Component.

A Separator – To separate the various components from one another, you can use the
component known as the separator. Eg: a back slash, a hyphen etc.

A Running Number – Each contract is identified by a unique sequence number. It is
mandatory to maintain a running number as a component in the sequence format. If not
included, you will not be allowed to save the details of the format. A running number is
internally generated by the system.
Component Type
You need to identify the type of each component in the sequence format. A component can
be constant through out or change for every contract processed at your bank. You can
associate a component with one of the following types:

Static – To include any hard coded component in the sequence format, you will specify
the type to be static. For instance, you may want the first two characters of your bank’s
name to be part of all the user reference numbers generated at your bank. The
component type would be static in this case.

Dynamic – You will specify the component to be of the dynamic type if its value is picked
up from the Oracle FLEXCUBE table. Eg: Product Group. A running number would
always be dynamic in nature.
10-28
Use in Sequence Generation
You need to indicate whether the component being defined should be used in sequence
generation or not. Specify ‘YES’ or ‘NO’ as per your choice.
You can also choose to display the reference number in the advices that are generated for a
contract.
Component Length
You can also specify the length of each component in the sequence format. The component
value is dependent on the component length maintained. For instance, if you specify 2 as the
component length, the value should comprise of only two characters.
Component Value
As stated earlier, the component value is dependent on the component length. Based on the
length, you can specify a value comprising of as many characters as specified in the
Component Length field. However, this field is used only if the value of the component is
required to be constant (static type) in all the user reference numbers generated at your bank.
If the component value is changing constantly (Dynamic type) for every contract, the system
will automatically pick up the value from the DB table based on the SQL query that you
maintain for the purpose.
Component Column and Component Table
If your component is of the dynamic type, you will need to mention the name of the Oracle
FLEXCUBE column from where the system will pick up the component value. Further, if you
wish to include a manipulated column value in sequence generation, you will need to include
‘SUBSTR’ as well in the column name. For eg, to include only the first four characters of the
product group associated with the product code involved in a contract, you will specify the
following in the Component Column field:
SUBSTR (PRODUCT_GROUP, 1, 4)
You need to mention the table name also, if the component type is dynamic. The following
table names are available in the option-list provided.

DUAL

STTM_BANK

STTM_BRANCH

CSTM_PRODUCT
For our example, the table name would be CSTM_PRODUCT.
Component Where Clause
The condition or the ‘where clause’ of the SQL code is specified here. In the example
discussed above, the system will pick up the appropriate product group depending on the
product code involved in the contract being processed. You can specify the following where
clause as an extension of the SQL statement specified earlier:
WHERE PRODUCT_CODE = SUBSTR (P_CRN, 4, 4);
Click add icon to define each subsequent component in the format. Use the navigating icons
to move between the various components of a sequence format.
10-29
11. Maintaining Currency Denomination
11.1 Introduction
In the Data Entry module, you can specify a break up of a transaction amount for Teller
transactions by denomination. The system also maintains a break-up of the till balances by
denomination.
11.2 Maintaining Currency Denomination Details
In the ‘Currency Denomination’ screen, you maintain the standard currency denominations for
each currency that your bank deals with. You can invoke this screen by typing ‘CSDDEMAN’
in the field at the top right corner of the Application tool bar and clicking the adjoining arrow
button.
To maintain the denominations of a currency, you need to specify the following:

The code of the currency for which you are defining denominations

A unique code to identify each denomination of the currency. For example, you can
assign D1, D10, D50 for USD 1, 10, 50.

A description of the denomination unit

The denomination type coin or note

The value of the denomination in relation to one unit of the currency. It could be a
fraction for coins
For example, for the currency USD you can maintain the denominations as follows:
CURRENCY
CODE
DENM
CODE
DESCRIPTIO
N
VALU
E
NOTE /
COIN
USD
D100
100 dollars
100.00
NOTE
11-1
USD
D50
50 dollars
50.00
NOTE
USD
D20
20 dollars
20.00
NOTE
USD
D10
10 dollars
10.00
NOTE
USD
D5
5 dollars
5.00
NOTE
USD
D1N
1 dollar Note
1.00
NOTE
USD
D1C
1 dollar Coin
1.00
COIN
USD
C25
25 cents
0.25
COIN
USD
C10
10 cents
0.10
COIN
USD
C5
5 cents
0.05
COIN
USD
C1
1 cent
0.01
COIN
Denomination type Millionaire certificate is used to facilitate MC/LMC (Millionaire Certificate)
transactions. You can have only one denomination with denomination type as ‘Notes’ and the
currency code should be the LCY code of each country..
11.2.0.1 Operations Allowed in the Currency Denomination Screen
Following standard maintenance operations are possible in the ‘Currency Denomination’
screen:

Add

Modify

Delete

Authorize

Close

Re-open

Inquiry

Logs all maintenances in the Audit Trail.
11-2
12. Expressing Amounts in Words
12.1 Introduction
You can describe the amounts printed on account statements, messages, advices, etc., in
words, for the benefit of your customers. To describe ‘amounts’ in a specific language, you
have to maintain the verbal equivalents of numerals in the language. You can maintain verbal
equivalents of numerals in the ‘Amount Text Maintenance’ screen.
You can invoke this screen by typing ‘STDAMTMN’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Amount translation details can be maintained as one time maintenance at the time Oracle
FLEXCUBE is installed at your bank. Once maintained, the amount descriptions printed on
account statements, and other messages, will be described according to your specifications
in this screen.
Language
You can maintain verbal equivalents of numerals in any language that Oracle FLEXCUBE
supports. This means that you can maintain the verbal equivalents of numerals in as many
languages as you generate messages.
12-1
Text
You must describe the following numerals in the Description field (in the language that you
specify in the Language field):

1, 2, 3, upto 10

20, 30, 40, 50, 60, 70, 80, and 90

100

1,000

10,000

100,000

1,000,000

10,000, 000, and so on
In certain languages, One thousand, One million, and so on are expressed, simply, as
‘thousand’, and ‘million’. If you are defining verbal equivalents of amounts in such a language,
do not choose the ‘Prefix One’ option. Statements and messages printed in such a language
will describe amounts such as ‘1000’, simply, as ‘thousand’.
Choose the ‘Prefix One’ option, if you would like amounts such as ‘1000’ described as ‘One
thousand’.
Currencies
In this screen, you can also describe the pre-decimal and the post-decimal units of a currency
in different languages. Enter the verbal equivalent of the ‘pre’ and ‘post’ decimal units of a
currency in the Pre-Decimal and Post-Decimal fields respectively. For example, if you would
like to describe the decimal units of USD, enter:
1. The currency in the Currency field
2. The pre-decimal description as ‘Dollars’
3. The post-decimal description as ‘Cents’
4. Final Text to be attached to the currency.
You can opt to prefix, or suffix, an amount with its currency. If you would like the suffix an
amount with its currency, do not choose the ‘Text Before’ option. If you would like to prefix an
amount with its currency, choose the ‘Text Before’ option.
For example, if you would like to describe USD 1000, as Dollars One Thousand, choose the
‘Text Before’ option.
12-2
13. Defining Currency Pairs
13.1 Introduction
In the foreign exchange markets, the exchange rates for some currency pairs such as the
USD-GBP or USD-JPY are easily obtainable, since these are frequently traded. The
exchange rates of other currencies such as the ZAR-INR (South African Rand - Indian
Rupee), which is not traded very often, is determined through a third currency. This third
currency is usually the US dollar, since the US dollar is quoted in all trading centres.
In the Currency pair definition screen, you define the static attributes of currency pairs for
which a regular market quote is readily available. For other pairs, which do not have a regular
market quote, you need to specify the third currency through which the system should
compute the exchange rate.
13.2 Maintaining Currency Pair Details
The currency pair screen is maintained at the bank level by your Head Office branch using
the ‘Currency Pair Maintenance’ screen.
You can invoke this screen by typing ‘CYDCCYPR’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
13.2.1
System Features
From among the currencies maintained in the currency screen, the system builds all possible
combinations of currencies in pairs. For example, if you have maintained the following
currency codes: USD, YEN. The system will give you a choice of defining parameters for the
following pairs.

USD-INR
13-1

USD-YEN

INR-USD

INR-YEN

YEN-USD

YEN-INR
It is however, not obligatory to define parameters for all these pairs. A currency pair needs to
be maintained only if:

You want to define a direct exchange rate for the pair: for frequently traded currencies
like INR-USD or USD-GBP or USD-JPY for which market quotes are available.

You want to define a through currency for the pair: for those currencies which are not
so well traded, market quotes may not be available. Therefore you can route the
conversion rate for the pair via a ‘through currency’. For example, in the case of GBPNLG, for which a direct exchange rate may not be available, you can define a through
currency say, USD. The exchange rate between GBP-USD and NLG-USD will be
picked up by the system to compute the exchange rate between GBP-NLG.
In the absence of a direct exchange rate, the system will look for a through currency to
compute the rate. If a ‘through currency’ has not been maintained then the default local
currency will be picked up as the through currency to compute the rate for a currency pair.
13.2.2
Maintaining Parameters for Currency Pair
Currency Pair
A currency pair (specified as Currency1 and Currency2, in the Currency Pair screen)
represents the two currencies for which you need to maintain exchange rates.
To specify the pair, choose from the list provided against Currency1. Select the pair for which
you want to maintain parameters.
The pair should be selected according to the quotation method followed by the market, which
could be direct or indirect (for details refer to the field ‘quotation method’). Exchange rates can
be defined for currency1 against currency2 or currency2 against currency1.
The descriptions of the respective currencies are displayed below.
Through Currency
If the exchange rate for a particular currency pair is not to be maintained, specify the ‘Through
Currency’ via which the exchange rate between the currencies should be calculated.
To maintain a through currency for a currency pair, check against the box ‘Through Currency’.
Then choose from the list codes provided against Code, Select the currency code, which you
want to specify as the ‘through currency’. The exchange rate for the currencies involved in the
pair will be calculated using the through currency.
Note
–
While maintaining a pair involving an ‘In’ currency (‘In’ – ‘Out’ and ‘In’ – ‘In’), you can
only specify the Euro as the ‘Through Currency’. Please note that you cannot maintain a ‘Through Currency’ for a pair constituted by an ‘In’ currency and the Euro.
For more details on the manner in which Oracle FLEXCUBE handles the Euro, refer the
chapter ‘Handling the Euro’ in this manual.
13-2
Whenever, you define a through currency for a currency pair, you will not be allowed to specify
the following for the pair:

Number of units

Spread definition
Direct Spread Application Required
Check this box to indicate if direct spread maintenance is to be used to compute the final rate.
You can select this option only if ‘Through Currency’ is selected. This is an alternate method
to compute exchange rates for currency pairs. The system computes only the mid rate using
through currency. The system will pick buy and sell spread from the spread definition and will
apply directly to the computed mid rate to get the final buy and sell rates.
Quotation Method
This is the method to be followed for quoting the exchange rate. There are two methods direct
and indirect.
In the Direct method the exchange rate for the currency pair is quoted as follows:
Buy rate = mid rate - buy spread
Sell rate = mid rate + sell spread
Ccy 1 = Rate x Ccy 2
In the Indirect method the exchange rate for the currency pair is quoted as follows:
Buy rate = mid rate + buy spread
Sell rate = mid rate - sell spread
Ccy 2 = Rate x Ccy 1
Example
The market follows the direct quote convention for the currency pair USD-DEM e.g., 1USD=1.6051DEM.
To maintain this pair, you would specify currency 1 as USD and currency 2 as DEM, and specify “direct” in
this field.
For the USD-GBP pair, which is quoted indirectly (1 GBP = 1, 5021 USD), the USD will be defined as
currency 1 and the GBP as currency 2, with the quotation method “indirect”.
Number of Units
This indicates the number of units of currency to be used for currency conversion
Spread Definition
You need to indicate the method in which the spread for a currency pair needs to be defined.
There are two ways of defining the spread -- in points and in percentage.
The effective spread can be calculated using any of the following two methods:

In points — spread x points multiplier

In percentage — spread/100 x mid rate
The method of spread definition that you specify here applies to two instances:

While maintaining exchange rates for this currency pair

While maintaining Customer Spread for this currency pair
13-3
13.2.3
Specifying Points Multiplier
Points are the smallest unit of measurement in the exchange rate of a currency pair. If you
have opted for a points system of defining spread, you should specify the multiplication factor
for the points to compute effective spread.
Suppose for the currency pair USD-DEM your rates are as follows:
Mid-Rate:1.6045
Buy rate:1.6040
Sell rate:1.6051
The effective buy spread is 0.0005 (1.6045 - 1.6040) and the effective sell spread is 0.0006
(1.6051 - 1.6045).
In the Rates screen, where you define rates and spreads for a currency pair, you can specify
the buy and sell spreads as 5 and 6 instead of as 0.0005 and 0.0006 (i.e., as spread points),
and specify here the points multiplier as 0.0001.
The effective spread, buy and sell rates are then computed as follows:
Effective buy spread = Buy spread x Points multiplier = 5 x 0.0001 = 0.0005
Buy rate= Mid rate - Buy spread = 1.6045 – 0.0005 = 1.6040
13-4
14. Maintaining Exchange Rates
14.1 Introduction
In the Currency Rates screen, you can maintain exchange rates for a currency pair, the rates
at which you buy and sell one currency for another.
A bank determines its buy and sell rate for a currency pair by applying a spread (i.e., its profit
margin) to the mid-rate of the currency pair. Mid rate is the basic rate at which a currency pair
is exchanged.
The spread applied for a currency pair varies with the transaction type, while the mid-rate
usually remains constant. Consequently, different rates are applicable to different transaction
types. For instance dollars in currency are purchased at a certain rate, while USD traveler’s
checks are bought at a different rate. In Oracle FLEXCUBE, you can define a rate type which
you would like to associate with a transaction type e.g., ‘CASH’, ‘TRAVCHKS’, etc., in the
Rates screen.
14.2 Maintaining Currency Rates
In the Currency Rates Maintenance screen, you define the mid-rate, buy and sell spread
applicable to each rate type; the buy and sell exchange rates are computed by the system.
Buy rates and sell rates can either be maintained by individual branches or can be input by
the HO and propagated to all the branches. If in the Bank-wide parameters - Preferences
screen you have specified your preference as ‘Use Head Office Exchange Rates’ then the
header part of currency rates maintained at the bank level by your Head Office will be
propagated to the branches. In the Bank-wide Preferences screen, if you have not specified
‘copy exchange rate to branches’ then the ‘Currency Exchange Rates Input’ screen is
maintained at the branch level by the respective branches.
Modifications of Rates at branch level are allowed even though “Use Head Office Exchange
Rates” is enabled at bank level.
You can invoke this screen by typing ‘CYDRATEE’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
14-1
The screen appears as shown below:
In this screen you maintain the following parameters for each rate type of a currency pair:

Mid rate

Buy spread and Sale spread

Buy rate and Sale rate
Specify the currency pair for which you want to compute the exchange rates. The pair should
be selected keeping in mind the quotation method for exchange rates as followed by the
market. The system offers the choice of maintaining both the currencies as currency1 or
currency 2 -- USD against DEM and DEM against USD.
For the pair specified the following parameters need to be maintained to arrive at the buy and
sell rate of currencies:

Rate Type

Mid Rate

Buy Spread

Sell Spread

Buy Rate

Sell Rate
Rate Type
This is the rate type for which you are maintaining exchange rates for a currency pair. For
different transaction categories your bank would like to maintain different exchange rates. For
example, traveller’s check is purchased at a certain rate whereas a bill of exchange is bought
at a different rate.
In the front-end-modules, where you define products to cater to the various transaction types
of your bank, you can link an appropriate rate type to the product. For instance, you create a
product to cater to outgoing cross currency transfers by SWIFT. For this product, if you define
14-2
the rate type to be STANDARD then for all contracts linked to this product, the Standard Rate
Type would be applied.
Mid Rate
Mid rate is an indicative exchange rate for a currency pair. It is the average of the buy and sell
rate quoted by the market for a currency pair.
For example,
currency 1 = USD
Currency 2 = INR
Buy rate -- 1 USD = 1.7020 INR
Sell rate -- 1 USD = 1.7040 INR
Mid-Rate = 1.7030
Buy Spread
The system displays the buy spread value maintained for the currency pair.
This is the buy spread for a currency pair. It is defined as the profit margin specified over the
mid rate when you buy currency 1 for currency2. The buy spread is defined in two ways -either in points or in percentage. The system computes the effective buy spread for you.
Sell Spread
The system displays the sell spread value maintained for the currency pair.
This is the sell spread for a currency pair. It is defined as the profit margin specified over the
mid rate when you sell currency 1 for currency 2. The sell spread is defined either in points or
in percentage. The system computes the effective sell spread for you.
Buy Rate
The system displays the buy rate value maintained for the currency pair.
Buy rate is the rate of exchange for a currency pair, which is computed by the system based
upon the mid rate, the spread specified, the spread definition and the quotation method
maintained in the ‘Currency definition’ screen.
Sale Rate
The system displays the sale rate value maintained for the currency pair.
Sell rate is the rate of exchange for a currency pair, which is computed by the system based
upon the mid rate, the spread specified, the spread definition and the quotation method
maintained in the ‘Currency definition’ screen.
Rate Date
This is a display field. When you enter the exchange rate for a currency pair, the system will
default the Rate Date as the Application Date. The rate date will always be less than or equal
to the application date.
Rate Sequence
This is a running serial number for the Rate Date. You need to specify the serial number. You
entry will be validated for uniqueness. For example, there could be only one exchange rate
between USD and EUR for 31/07/2003 with Rate Type STANDARD with Rate Serial as 0001.
Thus, this will be a unique rate serial for a currency pair, rate type combination for a given rate
date.
14-3
When you enter the exchange rate for a currency pair, the system will default the Rate Date
as the Application Date and the Rate Serial as the latest available serial for the currency pair
+ 1. The Rate Serial Number will be system generated. However, you can modify it if required.
This number takes into account the Rate Serial Number present in the Currency Rates History
screen too. The Rate Serial Number and the Rate Date will be displayed during authorization
of the Rate in the Currency Authorization screen.
14.2.1
Authorizing Exchange Rates
Authorization of exchange rates is done from the Currency Exchange Rates input screen.
Details like old value, new value for each field (buy rate, mid rate etc) are displayed. Click
authorise icon to authorize the record.
14.2.2
Revising Exchange Rates
For revising the exchange rates for your bank or the branches invoke the ‘Currency
Maintenance’ screen. Click the currency pair whose exchange rate you want to revise and
click unlock icon on the toolbar. Input/modify the new rates for the pair.
14.2.3
Viewing Exchange Rates
You can view the exchange rates in the ‘Currency Exchange Rates View’ screen. You cannot
input any values. You also have the option of specifying whether you want to view authorized
rates or the unauthorized rates for any currency pair.
You can invoke this screen by typing ‘CYSRATES’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
If the branches pick up the exchange rates maintained by the HO, then each time you invoke
the ‘currency view’ screen from a branch it is advisable to update this screen with the latest
rate input, from the HO. To do this, click on ‘Refresh’. Refresh updates the screen with the
last exchange rates input.
14-4
14.2.4
Viewing Currency Batch Rate
You can view the currency batch rates maintained in the system using ‘Currency Batch Rate
Maintenance’ screen. An automated intra-day batch process (CYBCYPOB) extracts the latest
exchange rate and store it as batch rate. The same is considered as freezed exchange rates
for batch operations.
To extract the currency rates for Branches which does not use head office exchange rates,
you need to login into the respective branch where the branch setup and execute the Batch.
For branches which use head office exchange rates, you need to run the batch at Head office
level.
You can invoke this screen by typing ‘CYDBATRT’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
You can query on records based on any one or all of the following criteria:

Branch Code

Currency
Click ‘Execute Query’ button. The system identifies all records satisfying the specified criteria
and displays the following details for each one of them:
14.2.5

Rate Type

Mid Rate

Buy Spread

Sale Spread

Buy Rate

Sale Rate

Rate Date
Specifying Limits for Cross Currency Transactions
Typically, the exchange rates applicable for cross currency funds transfer or teller
transactions is defaulted by the system depending upon the preference indicated in the
product preferences, for the product involving the transaction.
14-5
In your bank, for high-value cross currency transactions, you may want the user to manually
enter the exchange rate involved, rather than let the system automatically pick up a default
rate during transaction input.
You can define such a preference to be applicable to cross currency transactions involving:

A currency pair

A specific product, or all products

A specific module, or all modules

A specific branch, or all branches

A specific rate code
The transaction amount limit, above which the exchange rate must be entered, for a high
value transaction, could be defined in terms of currency pair where the currency of the
transaction is currency1 in the CCY pair defined in the maintenance.
To ensure that users manually enter exchange rates for high-value cross currency
transactions in Oracle FLEXCUBE, you must specify the limit amounts that must be validated
for each transaction in terms of currency pair, product, module, and branch combination. You
can use the ‘Product Limits Maintenance’ screen to specify the limits.
When you have specified these limits, the system automatically validates the amount with
each transaction for the currency pair, product, module and branch combination, and
accordingly, if the limits are exceeded, enforces the manual entry of exchange rates.
In case, the limit between ccy1 and ccy2 is given in ccy2, the system will automatically convert
the transaction amount to an amount in ccy2 using standard mid rate and check against the
limit amount whether or not manual entry of exchange rates is required. You can invoke the
‘Product Limits Maintenance’ screen, by typing ‘CSDPXMNT’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
14-6
Branch Code
You must specify the branch for which the limit amount will be applicable. You can specify that
the limits must be applicable for all branches.
Module Code
You must specify the module for which the limit amount will be applicable. You can indicate
that these limits must be applicable for both the Data Entry (DE) and Funds Transfer (FT)
modules.
Product Code
You must specify the product, transactions involving which the limit amount will be applicable.
You can specify that the limits must be applicable for all products.
Currency 1
You need to specify the currency1 applicable for defining the Transaction Amount limit,
beyond which the system will not default the Auto Exchange Rate.
All valid currencies defined in the Currency Pair Maintenance will appear for selection. This
currency is always the transaction currency of the contract.
Currency2
You need to specify the currency2 applicable for defining the Transaction Amount limit,
beyond which the system will not default the Auto Exchange Rate.
All valid currencies defined in the Currency Pair Maintenance will appear for selection. The
Currency2 should be part of a Currency Pair Maintenance in which the Currency1 defined
here is the first currency. Currency 2 can be specified as ALL.
14.2.5.1 Specifying Limit Details
Rate Code
You need to specify the Rate Type (code) for the Exchange Rate Limit
Limit Currency
You need to specify the currency in which the Limit Amount should be expressed. All valid
currencies defined in the system will be applicable for selection. There will be a validation for
the limit currency as either Currency1 or Currency2.
Limit Amount
You need to specify the maximum amount up to which the system should default the
Exchange Rate or perform the Rate Variance validation.
14.2.5.2 Validating Exchange Rate Limits
The Funds Transfer Contract Input will default the Rate only if the Transaction Amount is less
than the Maximum Amount defined for the Rate Code maintained at the product level for FT.
If the amount is more than the specified amount, then the system will not default the Rate.
Instead, it will force the user to enter the Rate. Once the user enters the Rate, the system will
not add the Customer Spread etc. as this will be final Exchange Rate for the contract.
The Rate Variance validation will also be done only if the amount is less than the maximum
amount defined for the Rate Code maintained at the product level for FT. If the amount is more
than the specified amount, the system will not perform the Rate Variance validation. Instead,
there will be an override to specify that the transaction amount is greater than the maximum
amount for Rate Variance check.
For details about how limits are applied when a transaction is entered, refer the chapter
Processing a Funds Transfer, in the Funds Transfer user manual.
14-7
14.3 Maintaining Currency Position Threshold Limits
You can view the various foreign currency positions of the bank and define the threshold limits
for currencies at different levels using the ‘Currency Position Threshold Limits’ screen. When
the threshold levels are is reached, an automated warning is displayed.
You can invoke the ‘Currency Position Threshold Limits’ screen, by typing ‘CYDCYTHR’ in
the field at the top right corner of the Application tool bar and clicking the adjoining arrow
button.
Maintain the following details:
Branch Code
Specify the branch code for which threshold is to be maintained. Alternatively, you can select
the branch code from the option list. The list displays all valid branch codes maintained at the
bank level.
You can also select ‘ALL’ to select all the branch codes listed.
Branch Name
Based on the branch code selected, system displays the branch name.
GL Class Code
Specify the GL class code for which threshold limits are to be maintained. Alternatively, you
can select the GL class code from the option list. The list displays all valid GL class codes
maintained for the selected branch in ‘GL Class Maintenance’ (STDGLCMT) screen.
GL Class Name
Based on the GL class code selected, system displays the GL Class Name.
Severity
Select the type of severity from the drop-down list. The list displays the following values:

Low

Medium

High
Click ‘+’ the define the threshold limits for different currencies.
14-8
CCY Code
Specify the currency code for which the buy and sell threshold limits are to be maintained.
Alternatively, you can select the currency code from the option list. The list displays all valid
currencies maintained for the selected branch.
Buy Threshold
Specify the limit amount in the currency being maintained to indicate the threshold for net buy
position. If the net balance of the currency is in credit and exceeds this amount, a warning is
be displayed.
Sell Threshold
Specify the limit amount in the currency being maintained to indicate the threshold for net sell
position. If the net balance of the currency is in debit and exceeds this amount, a warning is
displayed.
14.3.1
Viewing Currency Position Threshold Limits Summary
You can view the various currency threshold limits maintained in the system using ‘Currency
Position Threshold Limits’ screen. You can invoke this screen, by typing ‘CYSCYTHR’ in the
field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
You can query on records based on any one or all of the following criteria:

Authorization Status
–
Authorized
–
Unauthorized
–
Rejected

GL Class Code

Severity
–
Low
14-9


–
Medium
–
High
Record Status
–
Open
–
Closed
Branch Code
Click ‘Execute Query’ button. The system identifies all records satisfying the specified criteria
and displays the following details for each one of them:
14.3.2

Authorization Status

Record Status

GL Class Code

Branch Code

Severity
Viewing Currency Position
You can view the various currency positions maintained in the system using the ‘Currency
Position’ screen. An automated Intraday batch process (CYBCYPOB) triggered at the head office
level, extracts and stores the GL balance for various currencies.
Update GL balance and Extract the GL balance for providing
You can invoke this screen, by typing ‘CYDCCYPE’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
You can query on records based on any one or all of the following criteria:

Branch Code

GL Class Code
14-10
Click ‘Search’ button. The system identifies all records satisfying the specified criteria and
displays the latest extracted currency position of real GLs and contingent GLs in different tabs
with the following details:

CCY Code

Buy Threshold Limit

Sell Threshold Limit

Currency Position

Currency Position LCY Eqv

Breach
The Breach column indicates the threshold limit status in the following colour combinations:

Red indicates, Buy/Sell - High or Medium or Low level breach.

Green indicates, Buy/Sell Limit has not been breached.
If the net balance of the currency results in credit, then its a buy breach. Similarly, if the net
balance of the currency results in debit, then its a sell breach.
You can also click ‘Refresh’ to fetch the latest currency position.
14-11
15. Maintaining Currency Spread for Customer
15.1 Maintaining Currency Spread
You can maintain currency pair-wise spreads in the ‘Currency Spread Definition’ screen for
those branches which does not follow the Head Office currency exchange rates. However,
this condition is not applicable if your current branch itself is the head office.
All defined currency pairs including those currency pairs that have a through currency will be
available for spread maintenance.
You can invoke this screen by typing ‘CYDSPRDF’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Specify the following details:
Branch Code
Specify the branch code. Alternatively, you can select the branch code from the option list.
The list displays all valid branch codes maintained at the bank level.
Note
System display only those branch codes for which the ‘Use Head Office Exchange Rates’
option is not selected in ‘Bank Parameters Maintenance’ (STDBNKPM) screen. However,
for Head office Branch, this condition is not applicable and is listed for selection
Currency 1
Specify the currency for which you to maintain spread. Alternatively, you can select the
currency from the option list. The list displays all valid currencies maintained at the bank level.
Currency 2
The system displays the second currency based on the branch code and currency code
selected,
15-1
Spread Definition
The system displays the spread as either points or percentage based on the currency pair
combination maintained at bank parameter level.
Quotation
The system displays the Quotation method values based on the branch code and currency
code selected,
Branch Name
The system displays the branch name based on the branch code and currency code selected,
Currency 1 Name
The system displays the name of the first currency pair based on the currency code selected.
Currency 2 Name
The system displays the name of the second currency pair based on the currency code
selected.
Points Multiplier
The system displays the points multiplier values from the currency pair definition based on the
branch code and currency code selected,
Rate Type
Specify the Rate Type. Alternatively, you can select the rate type from the option list. The list
displays all valid rate type maintained at the bank level.
Buy Spread
This is the buy spread for a currency pair. It can be defined as the profit margin specified over
the mid rate when you buy currency 1 for currency2. You can define the buy spread in two
ways, either in points or in percentage. The system computes the effective buy spread for you.
Sell Spread
This is the sell spread for a currency pair. It can be defined as the profit margin specified over
the mid rate when you sell currency 1 for currency 2. You can define the sell spread either in
points or in percentage. The system computes the effective sell spread for you.
Note
Currency Spread maintained through ‘Currency Spread Definition’ (CYDSPRDF) screen
can be in decimals but has to be in positive integer. You can upload Upload Currency
Spread for new and update records using a macro enabled Microsoft excel file.
15.2 Maintaining Customer Spread Details
For a customer and currency pair, you can maintain tenor-wise spread details in the
‘Customer Spread Maintenance’ screen.
15-2
You can invoke this screen by typing ‘CYDCUSPR’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
In this screen, for a customer and currency pair, you can maintain buy and sell spreads for
different tenors.
You need to maintain customer spreads in each branch. Transactions initiated in a branch will
pick up the spread(s) maintained for that branch.
Note
–
Funds Transfer, Loans and Deposit contracts have tenor = 0 (zero). Therefore, you
need to maintain Customer Spreads for zero tenor also.
–
The tenor is specified in days
15.2.0.1 Specifying Spread Details
When processing an FX deal involving a customer (for whom you have maintained spread
details), the system picks up the customer spread corresponding to the tenor of the deal and
builds it into the exchange rate. If spread details are unavailable for a specific tenor, the
system picks up the spread defined for the nearest lower tenor.
For example, assume for a customer and currency pair you maintain spread details for the
following tenors: ‘3’, ‘5’, and ‘10’ days. When processing a deal with a tenor of ‘4’ days
(involving the customer and the currency pair), the system picks up the spread details defined
for a tenor of three days. This is because spread details for a ‘4’ day tenor is unavailable for
the customer and currency pair.
Note
You can also maintain customer spreads for the wildcard entry – ALL. If spread details for
a specific counterparty (for the currency pair) are unavailable, the System looks for the
customer spread maintained for the wildcard ALL entry. If even that is not available, then
the customer spread defaults to zero.
15-3
15.2.1
Computing Buy and Sell Spreads
Using percentage system -- suppose the bank wants to make a profit of 5% over and above
the mid rate quoted. Suppose the dealing currencies are USD and AUD. 1USD = 1.4166 AUD
for Standard rate type. (Mid rate being 1.4166). Now to arrive at the spread the bank will use
the following formula:
Spread = 5 / 100 x Mid rate (1.4166) = 0.07083
Using the points system -- suppose the point quoted by the bank is 708.3. The points
multiplier in this case would be 0.0001 (depends on the decimal points that the mid rate
extends to. Usually it is 4 decimal places).
Spread = Points (708.3) x Points Multiplier (0.0001)
Now coming to the buy and sale rate computing, there are two ways of computing the buy and
sale rates -- Direct and Indirect. Depending upon the quotation method you have specified in
the Currency pair screen, the system computes the spreads.
In the Direct method, the buy and sell rates are calculated as follows:
Buy Rate = Mid-Rate - Buy Spread
Sell Rate = Mid-Rate + Sell Spread
For cross currency contracts, the rate for the currency pair is:
1 unit of Ccy 1 = Rate * 1 unit of Ccy 2
In the Indirect method, the buy and sell rates are calculated as follows:
Buy Rate = Mid-Rate + Buy Spread
Sell Rate = Mid-Rate - Sell Spread
For cross currency contracts, the rate for the currency pair is:
1 unit of Ccy 2 = Rate * 1 unit of Ccy 2
The method of spread definition – percentage or points – that you have maintained for the
currency pair is displayed on this screen.
15.2.2
Maintaining Currency Margins for Customer
For each customer of your bank you can define buy and sell margins for a specific currency.
This spread is applied to floating interest components that involve the customer and currency
combination.
You can define buy and sell margins for a customer in the Customer Spread Maintenance
screen invoked from the Application Browser. You can invoke this screen by typing
‘CFDCUMRG’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
The margin that you define will be appropriately picked up and applied to arrive at the final
rate that is applied to floating components of contracts that involve the customer - currency
combination.
15-4
The buy and sell margins that you define are for a customer and currency combination. You
can select the customer and currency combination from the option lists available.
For the selected currency – customer combination, you can define amount slabs and specify
a Borrow and Lend margin for each slab. To add a slab to the list click add icon and enter the
slab details. To remove a slab from the list, highlight it and click delete icon.
Whenever you enter a contract in Oracle FLEXCUBE that involves the customer and currency
combination, the appropriate spread is applied to arrive at the floating rate to be charged. The
slab is selected based on the contract amount and depending on the nature of the contract,
the Borrow or Lend spread is applied.
15.2.2.1 Making Margin Applicable to All Customers
For a given currency, you can define borrow and sell margins to be applied to All customers.
At the customer field choose ALL. However, if you have maintained currency margins for a
specific customer and currency combination, it takes precedence over the margin defined for
all customers.
Currency margins can be maintained for customers across branches. In effect, a branch can
maintain margins for a customer belonging to another branch. These margins are propagated
across branches of your bank.
15-5
16. Maintaining Company Codes
16.1 Introduction
A list of company codes can be defined in the Company Maintenance screen.You can invoke
this screen by typing ‘STDCOMMT’ in the field at the top right corner of the Application tool
bar and clicking the adjoining arrow button.
The following details need to be specified in this screen:
Company Code
Specify the company code to uniquely identify the company.
Description
Specify the description of the company code.
Default
Check this box to select the company code as the default company code. This box should be
selected for only one company. If the default flag is selected for more than one company then
an appropriate error message is displayed by the system during the Save operation.
The company codes defined in this screen is subsequently listed in the ‘Company Based
Variance and Charge’ screen and the ‘Customer Maintenance’ screen to define Cycle Based
Interest Rates.
16-1
17. Period Code Maintenance
17.1 Introduction
Banks, like all business houses compute their profits and losses and assess their financial
position at the end of each financial year, which typically extends to 12 months -- from January
to December or from March to April. However, this could be changed, depending upon the
Bank’s policies and regulatory requirements.
For interim reporting needs, the financial year is further divided into accounting periods, the
duration of which is again determined by the bank’s accounting requirements. For example,
your bank’s Board of Directors meets once a month therefore, you would divide the financial
cycle into monthly periods.
The financial year and the accounting periods are referred to in the Oracle FLEXCUBE
system as the ‘Financial Cycle’ and the ‘Financial Periods’ respectively and are maintained at
the bank level by your Head Office branch.
At the end of each financial period and financial cycle you can generate profit and loss
statement and a balance sheet. The system also offers you the flexibility of keeping a financial
period/financial cycle open, allowing you to post adjustments to it and obtain a revised profit
or loss statement/balance sheet. You can maintain these details in the ‘Period Code
Maintenance’ screen.
17.2 Invoking Period Code Maintenance Screen
You can invoke this screen by typing ‘STDPRCDE’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen appears as shown below:
17-1
In this screen you define the following:

The financial cycle of your bank giving the start date and end date of each financial year

The period group - financial periods into which each financial cycle is to be divided
The following are the features of the Period Code screen
Financial Cycle
For each financial cycle you maintain the following parameters:
Cycle
This is a code for the financial cycle. It acts as an identifier for the cycle. For example, while
posting adjustments into a previous financial cycle -- you would identify the year through this
code.
Input the code using a maximum of 9 characters, alphanumeric.
For example, the financial cycle extends from 1st April to 31st March in India. A bank here
could define its code for the year 1996-97 as FY 1996-97.
Description
This describes the financial cycle. Enter description using a maximum of 35 characters,
alphanumeric. Taking the above example, you could enter Financial Year - 1996-97.
Start Date
This is the first day of this Financial Cycle
End Date
This is the last day of this Financial Cycle
Period Group
The financial cycle defined above, can be divided into different accounting periods. To define
individual accounting periods click on the first row under period code. A period called ‘FIN’ is
created by the system. This is an open ended period coinciding with the last day of the
financial cycle (for details refer to the section ‘System Functions’).
You can maintain the following parameters for each accounting period within a financial cycle:
Period Code
This code identifies the accounting period. Enter a code using a maximum of 3 characters,
alphanumeric. For example, if your period length is a quarter you can enter - Q1 for the first
period; Q2 for the second; Q3 for the third and so on. If your period length is a bimonthly you
can enter BM1, BM2. If your period length coincides with a month you can input M1, M2.
Start Date
This is the first day of the corresponding period
End Date
This is the last date of the corresponding period. ‘End date’ of a period should always end on
a month end. Please note:

The period codes could be of varying lengths but no gaps should be left between
periods

The duration of two periods should not overlap

You can modify the period code of the current or a future period; however, a past period
cannot be modified even if it has not been closed

All details maintained in the ‘Period Code Screen’ will automatically apply to any new
branch opened by you in the Branch Parameters Screen
17-2

The current financial cycle code and the current period code are displayed in the
‘Branch Parameters Screen’
Period Code Status
After authorisation, you can view whether a financial period is open or it has been closed.
Each branch can view the status of a period in every other branch. Click the period whose
status you want to view.
Branch
Displays the codes of the different branches of your bank
Status
Displays the corresponding status of the period code highlighted. ‘O’ - indicates open status;
‘C’ - indicates closed status
Note
The current financial cycle code and the current period code are displayed in the ‘Branch
Parameters Screen’
All details maintained in the ‘Period Code Screen’ will automatically apply to any new branch
if incorporated to your bank post maintenance of this screen. The status of all periods in the
new branch will be open.
17.3 System Functions
The system offers you the flexibility of posting transactions into a previous accounting period
which has passed its due end date. For example, lets assume your bank’s financial cycle
extends from 1st January to 31st December; the first period starts on 1-01-96 ends on 31-0396. Even beyond 31-03-96 you can keep the period open to be able to post for example,
expense bills you expect to receive in April. After you have posted all adjustments, you can
close the period.
Even after you have closed the last accounting period of a year, the system offers you the
flexibility of posting adjustments to the financial year.
For each financial year the system generates an open status period called FIN. Its start and
end dates coincide with the last date of the financial cycle. Into this one day period you can
post the accumulated profits and loss for the financial cycle, general reserves, and statutory
reserves for the current year after paying off the dividends. After this one day period is closed
the status of the financial cycle in the made by field ‘status’ is displayed as closed. With this
the financial year stands closed and no adjustments can be posted to it.
Closure of a period/financial cycle can be invoked through the General Ledger/ Core Services
module. The branches of the bank should close this period/financial cycle.
17-3
18. Status Code Maintenance
18.1 Introduction
Loans and bills, which are past their due maturity date of installment re-payment, but remain
unpaid, are defaulted contracts. In the Oracle FLEXCUBE system these defaulted contracts
can be assigned to different statuses, based on the number of days for which the contract is
outstanding.
Each status can be assigned a code. For instance, you can define a status code PDO to
represent ‘past due obligation’, and specify a period of 15 days after which an outstanding
contract should be marked as ‘PDO’. If they are due for more than 60 days, you could assign
a ‘doubtful’ status; ‘sub-standard’ if due for 6 months, and so on. Contracts for which no
installments are due, or which are regularly paid on their due dates are assigned the status
‘Active’ by the system. According to the number of days of default defined for each status, a
loan would be moved from ‘Active’ to PDO status, then to doubtful and finally to sub-standard
status.
Similarly, you can define status codes for current and savings accounts also. Current and
Savings accounts that have not generated any interest over a specific period or have
remained inactive with interest overdue may be identified as ‘NPAs’ (Non-Performing Asset).
In Oracle FLEXCUBE, you can assign these accounts different status codes and define status
criteria based on which the status movement will occur.
Refer the ‘Core Entities’ user manual for details on associating status codes with a customer
account class /account.
These status codes are maintained in the ‘Status Codes Maintenance’ screen.
18.2 Invoking Status Maintenance Screen
You can invoke this screen by typing ‘STDSTSCD’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
18-1
In this screen you can maintain the following to user defined status of a loan or bill/account
status:
l
A unique code for the status
l
A brief description for the status
l
A sequence number for the status
l
The type of status – Indicate whether the status codes are maintained for an ‘Account’
or for a ‘Contract’, or for ‘Both’
The type of status you choose depends on the status processing basis for your branch, which
is defined in the Branch Parameters Preferences maintenance. If status processing basis is
at individual account / contract level, you can choose the applicable status types as ‘Account’
or ‘Contract’. The status codes that have been maintained of type ‘Account’ are available for
association in the Account maintenance and those maintained with type ‘Contract’ can be
associated with contracts.
If status processing basis is at Group / CIF level, you can only maintain status codes of type
‘Both’ (that is, applicable for both accounts and contracts). In such a case, you must associate
the statuses at both the Account maintenance as well as for contracts.
Note
18.2.1
–
It is mandatory to maintain the status code ‘NORM’ (Normal) with the sequence
number as ‘0’, for all the status types. The sequence number must not be repeated
for a status type.
–
The sequence number associated with the status will be used for determining the
hierarchy of statuses, i.e., higher the number, worst the status and this will be
unique for the status codes.
Maintaining Status Codes for Contracts
The following parameters need to be maintained for defining a status code:
Status Code
This is the code, which identifies the status to which the contract belongs.
For example, assign a code using a maximum of 3 characters, alphanumeric. For example, if
your contract has past its due obligation status you can input code PD1. PD representing post
due obligation. The number 1 stands for stage 1 of the post due obligation status
Status Description
This is the description of the status, Enter a description using a maximum of 35 SWIFT
characters.
For example, taking the above example, you can input here - Past Due Obligation 1 for Loan
if you are maintaining status codes for Loans.
Link to
This represents the category of the product - asset or liability to which the contract status is
applicable.
For example, if you are maintaining status codes for loans or any money market placements,
click on ‘assets type of product’. If you are maintaining status codes for deposits, click on
‘liability type of products’.
18-2
Effective days from Maturity
This indicates the number of days after the due date when this status becomes applicable to
the contract. You can specify any number of days from 0-999.
The effective days defined here is defaulted to the product level in the Bills and Loans
modules. You have the option of redefining the number of days at the product level.
18.2.2
Maintaining Status Codes for OD Account
Oracle FLEXCUBE provides a facility to maintain status codes for Charge-off and Write-off
status of the OD account. These status codes are maintained in ‘Status Code Maintenance’
screen and the details of the same are as follows:
Status Code
Description
Status Sequence
Status Type
CROF
Status code for
Charge-off of OD
accounts.
Should be less
than SUSP status
sequence
Account
SUSP/WOFF
Status code for
suspended status
of OD accounts.
Should be greater
than CROF status
sequence
Account
18.3 Maintaining Dormancy Parameter Details
You can maintain the dormant statuses for the customer account in the ‘Dormancy Parameter
Maintenance’ screen. To invoke this screen, type ‘STDSTDOR’ in the field at the top right
corner of the Application tool bar and click the adjoining arrow button.
Transaction Branch
Select the appropriate branch from the list of branches available in the option list. This screen
will be available only for those users who has ‘Multi Branch Operational’ check box enabled
at ‘User Maintenance’ Screen.
While clicking ‘Ok’ button, the system validates the access rights of the selected branch and
function for the user. If you don’t have appropriate rights on the selected branch and function,
the system would raise an error message. If you select a valid branch, the system updates
the same as transaction branch and the transaction would be posted for this branch.
Note
The system performs the action level access rights validation only on ‘Save’ operation.
18-3
After selecting the Transaction Branch, you can enter the remaining details in the ‘Dormancy
Parameter Maintenance’ screen.
You need to specify the following details:
Account Number
Specify the customer account and the TD account for which you are maintaining the dormant
status. The adjoining option list displays all the customer account numbers and the TD
accounts that are maintained in the selected transaction branch. You can choose the
appropriate one.
Account Description
The system displays the account description of the selected account.
Account Branch
Specify the account branch code. The adjoining option list displays all the branch codes that
are maintained in the system. You can choose the appropriate one.
Account Currency
The system will display the currency of the selected account.
No Debit
Check this box to indicate that no debits should be posted to the selected customer account.
This option is not applicable for TD accounts.
No Credit
Check this box to indicate that no credits should be posted to the selected customer
account.This option is not applicable for TD accounts.
Frozen
Check this box to indicate that the customer account is frozen due to some unavoidable
reason. This option is not applicable for TD accounts.
18-4
Dormant
Check this box to indicate that the account is in dormant status which means not used for
along time.
Reverse Movement Parameters
Select the parameters for reverse movement of the dormant account from the drop-down list
and the available options are:
l
Debit
l
Credit
l
Any
l
Manual
Note
For TD accounts only 'Manual' parameter is supported.
Remarks
Specify the remarks, if any.
18.4
Maintaining CR\DR Statistics Details
You can maintain the credit\debit statuses for the customer account in the ‘CrDrStat
Maintenance’ screen. To invoke this screen, type ‘STDSTCDM’ in the field at the top right
corner of the Application tool bar and click the adjoining arrow button.
Transaction Branch
Select the appropriate branch from the list of branches available in the option list. This will be
available only for those users who has ‘Multi Branch Operational’ check box enabled at ‘User
Maintenance’ Screen.
While clicking ‘Ok’ button, the system validates the access rights of the selected branch and
function for the user. If you don’t have appropriate rights on the selected branch and function,
the system would raise an error message. If you select a valid branch, the system updates
the same as transaction branch and the transaction would be posted for this branch.
Note
The system performs the action level access rights validation only on ‘Save’ operation.
18-5
After selecting the Transaction Branch, you can enter the remaining details in the ‘CrDrStat
Maintenance’ screen.
You need to specify the following details:
Branch Code
Specify the branch code. The adjoining option list displays all the branch codes that are
maintained in the system. You can choose the appropriate one.
Customer A\C
Specify the customer account for which you are maintaining the credit\debit status. The
adjoining option list displays all the customer account numbers that are maintained in the
selected transaction branch. You can choose the appropriate one.
No Debit
Check this box to indicate that no debits should be posted to the selected customer account.
No Credit
Check this box to indicate that no credits should be posted to the selected customer account.
Posting Allowed
Check this box to indicate that the account class being created is to be used while creating
IRA monetary accounts. Monetary accounts used for IRA need to be distinguished from the
other accounts in Oracle FLEXCUBE, so that these accounts do not come up for posting in
the other Oracle FLEXCUBE screens.
Remarks
Specify the remarks, if any.
18-6
19. Transaction Code Maintenance
19.1 Introduction
In the ‘Transaction Codes Maintenance’ screen you define transaction codes to representing
various types of transactions, for example, transfer charges, incoming mail transfer, incoming
telex transfer, reserve, incoming clearing transfer etc. All similar transactions can be grouped
under a common transaction code with a description. This description will be printed on the
account statements, reports and advices generated.
For a transaction type you also maintain other related processing details which will be
applicable to all transactions posted under a common code. Details about availability of funds
for liability checking, SWIFT code for the transaction type, preferences regarding charges to
be levied on turnovers, payment to be made through cheques etc.
19.2 Invoking Transaction Code Screen
You can invoke ‘Transaction Code Maintenance’ screen by typing ‘STDTRNCD’ in the field at
the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen you maintain the following for a transaction:

A code representing the transaction type

Description of the transaction type

The interval after which funds should be made available after the transaction
19-1
19.2.1

Preferences regarding charges to be levied or not on number of transaction counts and
total turnover amounts

Preference stating whether a transactions booked under this code should cause an
account marked as ‘dormant’ by the system to be re-instated to ‘active’

Preference whether payment for a transactions posted under this code should be made
through cheque

Preference indicating whether payment for a transaction booked under this code should
be considered for Escrow transfer processing
Maintaining Transaction Details
The following parameters need to be maintained for a transaction type:
Transaction Code
This is the code you assign to a transaction type. This code identifies the type of transaction.
Enter 3 characters, Alphanumeric. For example, for all transfer charges transaction you can
give the code as TCT; for incoming telex transfer you can input - ITT. In case, you want to
assign numeric codes only, then for ease of operation similar transaction types should be
grouped into a range. For example, you can set a range for all Money Market transactions
say, A1-A30; a different range for Bills and Collections B1-B30 and so on.
Description
This is the description of the transaction type
Enter the description using a maximum of 35 characters, alphanumeric. For example, for TCT
code you can enter ‘Transfer Charges Transaction’.
SWIFT Code
This is the SWIFT code to which this transaction code is linked. It is used for posting
transaction details on SWIFT format.
Select from the option list. It will display a list of SWIFT formatted codes representing
transaction types. The following list is displayed:
SWIFT
CODES
TRANSACTION TYPE
BOE
Bill of Exchange
BRF
Brokerage fee
CHG
Charges and other Expenses
CHK
Cheques
CLR
Cash Letter/Cheque Remittance
COL
Collections
COM
Commission
DCR
Documentary Credit (for Principal Amount)
DIV
Dividends - Warrants
EQA
Equivalent Amount
19-2
ECK
Euro checks
FEX
Foreign Exchange
INT
Interest
LBX
Lock Box
LDP
Loan Deposit
MSC
Miscellaneous
RTI
Returned Item
SEC
Securities
STO
Standing Order
TCK
Travelers Cheques
TRF
Transfer
VDA
Value Date Adjustment
The codes COL -Collections, DCR - Documentary Credit and SCC- Securities are used when
entering a principal amount.
MIS Head
Each Transaction Code that is created can be linked to an MIS Head. An MIS Head indicates
the manner in which the type of entry should be considered for profitability reporting purposes.
Availability Information
This states the different time intervals after which funds will be available for withdrawal in case
of all transactions posted under this transaction code.
The system defaults to immediate, which means that funds will be immediately available for
withdrawal (the immediate option on the screen). Example: Teller Transaction. For all
Clearing transactions you have the option to specify as to when will funds be made available
for withdrawal. Click the desired option.
Click ‘On Value Date’ option if you want funds to be available on the date the transaction
became effective. Example: A loan or a deposit
Incase you want to specify the number of days after which funds should be available for
withdrawal, click on the option After Days. Enter the number in the box. It could be any two
digit positive integer from 1 to 99. This option will make funds available for all transactions
posted under this code, on the specified date from the value date. Example: Demand Draft
When you click the option After Days with New Value Date and enter the number of days in
the box; then the original value date of the contract will take a new value date. This new value
date = old value date + the number of days input by the user in the box against the option.
Example: Future dated funds transfer.
The difference between the third and fourth option being that in the latter case the old value
date changes; while in the former the value date does not change.
When you click the option ‘After X Days’ it indicates the availability of the respective funds on
the same day as per the customer value date or with a delay based on value for ‘X’.
19-3
During this extended period, funds will not be available and will be in “Uncollected” status.
Intra-day Release
If you want uncollected funds on a transaction posted using the transaction code, to be
manually released intra-day (that is, within the day), select the Intraday Release option. The
Intraday Funds Batch, when manually executed during the day, picks up those transactions
that are due for release on or before the system date, which have been posted with the
transaction code (with the Intraday Release option enabled), for release of uncollected funds.
The Intraday Release option cannot be enabled if the Availability specified for the transaction
code is Immediate.
You can use the ACUNCOLB (Intraday Funds Release) batch process to perform the intraday release of uncollected funds in respect of transactions posted using a transaction code
for which the Intraday Release option has been enabled.
For details about invoking the batch process, refer the Current and Savings Account user
manual.
Extended Period for Uncollected Balance
If ‘availability days’ is deferred by X days mentioned in transaction code, the system will credit
the funds to customer account as on ‘Customer Value Date’, but the availability of the funds
will be restricted. The uncollected funds will NOT be released on reaching customer value
date. The system will trigger the ‘uncollected release’ on reaching ‘Contract Date + ‘X’ Days
as per transaction code’.
The system will schedule the ‘uncollected release’ as an intra day batch to release the funds
to available balance on the account, say at 2PM every day.
The float extension can be triggered till the movement to ‘available balance’ takes place.
Whenever there is a float extension defined using CGDBFLEX or CGDCFLEX, the
uncollected release execution will get pushed by the extended number of days and
correspondingly the ‘Availability date’ in CGDQUERY screen will also be updated with the
new date
For interest application, the system will consider the value date of credit as the previous local
working day for the clearing house, compared to the ‘Availability Date’.
Overdraft Tracking
Component type for transaction
Select the component type for transaction from the drop-down list. The options available are:

Principal - Select ‘Principal’, if a transaction type is not an interest or charge

Interest - Select ‘Interest’, if a transaction code is used for debiting interest for an
overdraft account.

Charge - Select ‘Charge’, if a transaction code is used for debiting charge for an
overdraft account.
The component type for the transaction code is mandatory for maintaining transaction code
and cannot be modified after the first authorization.
Preferences
This field indicates your preferences regarding transactions booked against this transaction
code. The preferences marked relate to the following:
19-4
Interest and Charges Transaction Count
Every debit or credit entry is passed under a transaction code. If for a transaction code you
have checked ‘I&C transaction count’ then all entries made under that code would be picked
up by the system as chargeable transaction counts which would be used by the I&C system
to compute charges.
Therefore, you should take care not to check for all bank induced transactions like - service
charges, interest payment, calculation, brokerage and charges, etc.
For example, your bank has a policy of limiting savings withdrawals without additional charges
to only 8 in a month. Beyond which all withdrawals would be charged. For the ninth and
onward withdrawals in the month from any account the system will maintain a count for
computing charges. However, care should be taken to exclude all bank-induced transactions
from the count.
Interest and Charges Turnover inclusion
Every debit or credit entry is passed under a transaction code. If for a transaction code you
have checked ‘I&C turnover inclusion’ then the debit turnover/ credit turnover balance under
that code would be picked up by the system as chargeable depending upon the option
specified in the I&C module. Therefore you should take care not to check for all bank induced
transactions like - service charges, interest payment, calculation, brokerage and charges, etc.
Interest and Charges Balance Inclusion
Check this box to indicate that the transactions posted under this code should be considered
for the purpose of computation of Remuneration (Interest). By default this option is checked.
Uncheck this box for such loan transactions or any other transactions for which you wish to
exclude computation of remuneration (interest).
Note
Once the transaction code is authorized, you cannot change your preference.
Consider for Turnover Limit
Check this box to indicate that all transactions posted under this code should be considered
as part of the turnover limit processing.
Consider for Cover Sweeps
Check this box to consider easy saver processing using cover accounts for transaction.
Only if you check this box, the system will consider the debit transactions for sweep from
cover accounts/auto linked TD/linked term deposits.
If a particular transaction should not be included for sweep, then the related transaction codes
should be maintained with 'Consider for Cover Sweeps' as unchecked.
The above field is applicable only for clearing and teller modules. Oracle FLEXCUBE repays
loan from multiple accounts. In Oracle FLEXCUBE, the loan account is the primary account
and all the other accounts linked to it are cover accounts. While paying the settlement if the
primary account has insufficient amount, the system will check the cover accounts for the
remaining amount according to the preference.
Consider for Account activity
If you check the field ‘Consider for A/C activity’ for a transaction code, then any debit or credit
posted under this code would reinstate the status of an account from dormant to active and
accounting activity shall be considered.
19-5
Cheque Mandatory
If for a transaction code you check ‘Cheque Mandatory’ then, for all transactions posted under
this code, transaction will take place through cheque. For example: Incoming Clearing
transfer.
Cheque Mandatory should be checked only for SB cheque withdrawals and Cash Account
Cheque withdrawals.
Available Balance Check Required
Select this option if you want the system to check for the availability of funds before posting a
debit entry to a customer account. The system will check for the available balance in all
customer accounts associated with the Transaction Code for which the option is enabled. If
the available balance check fails i.e. if the system detects insufficient funds in the customer
account, it will display a warning message.
Note
However, the system will check for the available balance only if you have selected the
‘Available Balance Check required’ option for both the transaction code associated with
the accounting entry and the Customer Account Class to which the customer’s account
that is being debited, belongs. The check will not be performed if the option is not selected
in both places.
Interest and Charges Penalty Inclusion
In the transaction code that you use for debit entries to time deposit accounts, you must
indicate the computation of penalties on debit entries due to withdrawals from the account
before the maturity date. You must select the IC Penalty Inclusion check box to indicate this.
Inter Branch in Local Currency
This indicates whether inter branch entries passed with this transaction code should be in
Local currency. If this option is checked, the inter branch transactions would be passed in
local currency. This way, the Treasury would be able to track its profit and the branch’s profit
by passing a single consolidated entry (Position transfer from one branch to the Treasury
branch) at the treasury rate.
Note
–
This option is applicable only if the local currency of the different branches is the
same. This option is applicable only for Fcy1- Fcy1 transactions. For other
transactions, namely, Fcy1-Fcy2, Lcy-Fcy, Fcy-Lcy, IB entries would be based on
IB Parameters Maintenance.
–
For position transfer, the ‘Inter Branch in Local Currency‘ check box in the Transaction Code maintenance screen should be checked to avoid creating position due to
IB posting.
Acumen Transaction Code
You need to check this option in order to eliminate the deals/transactions uploaded from the
Acumen in the Hand-off of transactions affecting FCY Position to Acumen from Oracle
FLEXCUBE.
19-6
Note
This is applicable where Oracle FLEXCUBE interfaces with Acumen. Acumen is an Integrated Turn-key solution for Treasury, Derivatives and Capital Markets Covering Front,
Risk Control, Middle Office from Login SA.
Exempt Advance Interest
Check this box to indicate that all the postings with this transaction code should not be
considered for penalty interest calculation.
Escrow Processing
Check this box to indicate that all the payments related to this transaction code should be
considered for Escrow sweeps. If this box is checked and the credit account (Project account)
is Escrow enabled then the system will automatically compute predefined percentage of
transaction amount and places an amount block on the credit account (Project account).
Note
Escrow processing is possible only if the trust account and escrow account are of the same
currency and are with-in Oracle FLEXCUBE.
Available Balance update through PPC
Check this box to update the available balance on the project through PPC.
Exception to Debit Override Status
Check this box to provide all the transactions under the transaction code an exception to debit
override restriction.
Exception to Credit Override Status
Check this box to provide all the transactions under the transaction code an exception to
credit override restriction.
If a customer account is marked as Debit/Credit Override for all Debit/Credit transactions to
the account, then during the accounting entry posting to the account the system behaves as
follows:


FCUBS UI
–
If a debit/credit transaction to the account is performed through FCUBS user
interface, system will pop-up an override message intimating the user that the
account is in ‘Debit/Credit Override’ status. This validation will be applicable to all
debit/credit transactions to the account and system will not consider the exceptions
maintained at transaction code level. The user has an option to accept the override
and go ahead with the transaction or reject the override and abort the transaction.
–
If the override is accepted, then it will be logged along with transaction details.
–
For all FCUBS transactions, override will be displayed only during posting of the
account entries into account.
–
The system displays an override message on the transaction screen if the
accounting entries for a transaction are posted online.
–
In case of bulk transaction processing in PC/ Clearing transactions, where the
accounting entries are deferred, the transactions will move to a debit exception
queue. From the queue these overrides can be accepted or rejected by the user
FCUBS Automatic Batch Processes
–
If a customer account is marked as debit/credit override, all the transactions in the
account will be restricted by a validation which is configured as ‘Error’.
19-7
–

If ‘Exception to Debit/Credit override’ status is checked at the transaction code level,
then the accounting entries are posted. Else, the system does not allow the
accounting entries to get posted.
Transaction from Interfaces
–
If the customer account is marked as ‘Debit/Credit Override’, all debit/credit
transactions in the account initiated from external interfaces will be stopped and the
system will not consider the exceptions maintained at transaction code level.
–
You can handle the transactions from the external interfaces through the error code
conversion functionality available in the ‘Override Maintenance’ (CSDOVDME)
screen. The error code conversion can be maintained based on channel names and
the new error code can be maintained as ‘Error’ type.
Salary Credit
Select the type of salary credit from the adjoining drop-down list. This list displays the
following values:

Normal Salary

Bulk Salary
By default, the system selects null value.
Note
–
The value ‘Bulk Salary’ can be selected only if the ‘Availability Information’ is
‘Immediate’.
–
This applies when you use the option ‘Bulk Salary’ along with a transaction code.
When a credit is made to an account through salary upload table along with a bulk
salary enabled transaction code, the system blocks the entire credit amount on that
account with effect from the date of upload. This block remains active for the period
maintained in CSTB_PARAM against the parameter ‘BULKSALARY_BLOCK_DAYS’. The number of days for expiry is mentioned terms of calendar days. The
system does not allow manual operations on the amount block for these accounts.
Statement Day Basis
You need to specify when the transaction associated with the selected Transaction Code
should appear in the account statement. The available options are:

Current Working Day

Previous Working Day
19.2.1.1 Accounting Entry Processing to Calculate Statement Date
The accounting entry processing will be enhanced to calculate the Statement Date based on
the Transaction Code Maintenance and the Statement Status at the Branch level. The
following illustration explains the calculation of Statement Date.
Assume two Transaction Codes TXN1 and TXN2 have been defined with Statement Date
Basis as Current Working Day and Previous Working day respectively. The Statement Date
would be derived as follows:
For a transaction C1 posted on say 25th Jan, 2004 with TXN1, the Statement Date would be
derived as 25th Jan, 2004 irrespective of the Branch Statement Status.
For a transaction C2 posted on 25th Jan, 2004 with TXN2, the Statement Date would be
derived as the Previous Working Day of 25th Jan, 2004 if the Branch Statement Status is set
to ‘N’ specifying that the Branch is not yet ready for periodic statements processing.
19-8
For a transaction C3 posted on 25th Jan, 2004 with TXN2, the Statement Date would be
derived as 25th Jan, 2004 if the Branch Statement Status is set to ‘Y’ specifying that the
Branch is ready for periodic statements processing.
The Statement Date would be stored as part of the archived data also
The Statement Date would be recomputed during the reversal entry in the same logic
19.2.1.2 Monitoring Anti Money Laundering
Anti Money Laundering Required
Check this box to indicate that AML monitoring is required for all accounting entries linked to
the particular transaction code. Leave it unchecked to indicate otherwise.
Product Category
If you indicate that AML tracking is required for all transactions linked to the particular
transaction code you have to identify the product category for which AML tracking is
necessary.
Note
If the transaction code linked to the transaction type has ‘intra day release’ as ‘Yes’, then
‘uncollected release’ can be scheduled as an intra day batch to release the funds to the
available balance on the account.
19.2.2
Maintaining Country Name Details
You can define country name through the ‘Country Code Maintenance’ screen. You can
invoke this screen by typing ‘STDCNMNT’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
Here, you can capture the following details
19-9
Country Code
You can capture a unique three-character code to identify the country. For example: you can
maintain USA as the country code for United States of America.
Alternate country code
You can also associate an alternate country code. This is for information purposes only and
will not be printed on any customer correspondence.
For example you can have US as the alternate code for USA
Country Name
After you define an alphanumeric code to identify the country for which you would like to
assign a name, you have to specify the name of the Country.
Overall Limit
This is the maximum credit exposure that a bank is willing to take for a country. That is, the
sum of all utilization's under this country liability cannot exceed the amount specified here.
Blacklisted
Further, in the ‘Country Name Maintenance’ screen you can black list a country for further
usage. You are not allowed to deal in countries that are blacklisted.
You can only deal with countries that are not blacklisted
IBAN Mandatory for Payment Messages
If this is checked, it indicates that for every payment message an IBAN is mandatory. This is
automatically checked if you have checked the ‘EU Member’ box.
If this option is unchecked for a country, the system will not process the outgoing payments
wherein the ordering customer or the beneficiary customer belongs to that country.
EU Member
This indicates whether the country is recognized by Swift as a part of the Intra European
countries.
If you check this flag the instructed amount field should be mandatory in the generated 103,
103+ and 102 messages. The instructed amount field is mandatory in the incoming
messages.
Clearing Code in BIC+
Check this box to indicate that the National ID in the BIC plus file is the clearing code. During
upload of clearing codes from BIC plus file, the records that belong to countries against which
this box is checked will be selected.
Generate 205
Check this box to indicate that the cover message 205COV or 205 need to be generated for
transactions involving this country. If you do not select this option, RTGS, 202 or 202COV
message will be generated.
For more details on 202COV and 205COV cover message formats, refer settlements user
manual.
Default Clearing Network
Once the National ID from BIC plus directory is uploaded into clearing codes, the network will
be populated as the default clearing network for that country. This is mandatory when clearing
code in BIC+ is chosen as ‘Y’.
19-10
International Dialling Code
Specify the international dialing code associated with the country.
19-11
20. Account Revaluation Maintenance
20.1 Introduction
Account revaluation is a process by which the LCY equivalent of balances in the FCY
accounts is marked to market.
In all foreign currency accounts, the FCY current balance is displayed along with the LCY
equivalent of the current balance. The LCY equivalent current balance is the aggregate of the
LCY equivalent of the various transactions that have been posted to the account.
In the ‘Chart of Accounts - GL Details’ screen you specify whether a GL should be revalued
or not.
In the ‘Account Revaluation Maintenance’ screen, you specify parameters for account
revaluation such as rate type, the GL to which the profit or loss from revaluation should be
posted, etc. You can invoke this screen by typing ‘RVDSETUP’ in the field at the top right
corner of the Application tool bar and clicking the adjoining arrow button.
In this screen you can maintain the following parameters to define the revaluation parameters
for a GL account:
l
The general ledger accounts to which the profit or loss on revaluation is to be posted
l
The account to which the revaluation profit is to be debited or loss credited
l
The rate type to be used to revalue the GL
l
The transaction code for posting the revaluation entries
20-1
l
The rate type to be used for accounting entry-based revaluation of profit and loss GLs
l
The transaction code that would be used to post revaluation entries due to accounting
entry-based revaluation of profit and loss GLs
General Ledger Code
This is the code of the GL account for which you are specifying revaluation parameters.
Transaction Code
This is the transaction code under which the accounting entries would be posted to the
defined revalued GL account
Rate type
This is the rate type to be used for revaluation of this GL
Profit General Ledger
If the result of revaluation is a profit, the profit amount is credited to this profit GL. If, for a GL,
you have opted for revaluation split, then Revaluation Profit (as opposed to Trading Profit) is
posted into this GL.
Revaluation split segregates revaluation profit / loss into:
l
Trading Profit / Loss – Profit / Loss due to revaluation of FCY entries posted into the GL
during the current day.
l
Revaluation Profit / Loss – Profit / Loss due to revaluation of opening FCY balances
(excludes current day’s turnover).
Loss General Ledger
If the result of revaluation is a loss, the loss amount is debited to this loss GL. If, for a GL, you
have opted for revaluation split, then Revaluation Loss (as opposed to Trading Loss) is posted
into this GL.
Revalue into
This GL account is debited if the result of revaluation is a profit; and credited if the result of
revaluation is a loss
This would typically be the GL code being revalued. For all non-contingent GLs belonging to
the asset or liability categories, the system defaults to the GL being revalued.
If you wish to specify a different account for posting these entries specify by selecting from
the list of maintained GLs. A list of all GLs would be displayed. Select.
Trading Profit Account/Trading Loss Account
This indicates the GL for posting profit/loss due to trading revaluation (Trading Profit / Loss)
if you have indicated that revaluation split is required for a GL.
Netting of offset entries
A check against this indicates whether the offset entries for all accounts linked to the GL code
need to be netted or not. If checked, a single consolidated entry would be passed (one for
profit and one for loss).
Note
Netting of offset entries is applicable only for normal account revaluation and not for accounting entry-based revaluation of Income/Expense GLs.
20-2
Accounting entry-based revaluation of Income / Expense GLs
Income/expense GLs that are marked for entry-based revaluation are picked up by the EOD
revaluation batch process, which executes before the account revaluation batch process on
a given business day.
In the Account Revaluation Maintenance, you must specify the following parameters that
would be used by the batch revaluation process, for revaluing FCY entries in Income/Expense
GLs:
l
Rate type
l
Transaction code for posting entry-based revaluation entries
You can maintain these parameters for specific Income/Expense GLs. If you wish to maintain
these parameters for all Income/Expense GLs, you can specify the ‘STDPNL’ option in the GL
Code field. The ‘STDPNL’ option signifies that the entry-based parameters being maintained
are applicable for all Income/Expense GLs.
When the revaluation batch revalues an Income/Expense GL, it uses the rate type and
transaction code maintained for the GL in the Account Revaluation screen. If no maintenance
exists for the specific GL, the parameters maintained for the ‘STDPNL’ GL Code option are
used.
20-3
21. Maintaining Branch Holidays
21.1 Introduction
For a year, you need to define your weekly holidays and your calendar year annual holidays.
This is done in the ‘Local Holiday Calendar’ screen.
The system uses the information maintained in this screen to do the following:

To check that the ‘value date’ of no Data Entry transaction falls on a holiday

To check that the start date / maturing date and schedule date of a loans and deposit
contract does not fall on a holiday

To effect a date change on the system -- today’s date and the next working date
For any schedule / contract maturing at a future date, say, 5 years hence, you can input a
future date, only if the calendar for that year has been maintained. It is not necessary to
maintain the list of all annual holidays, for future, you can merely define all regular weekly
holidays.
This screen is maintained for each branch, of your bank, from the respective branches; thus
making it possible to have a different set of holidays for different branches of the bank.
21.2 Invoking Local Holiday Screen
Invoke the ‘Local Holiday Calendar’ screen, by typing ‘STDLOCHL’ in the field at the top right
corner of the Application tool bar and clicking the adjoining arrow button.
21-1
The screen is as shown below:
In this screen you can specify the weekly and also the annual holidays, for your branch, for
any year between 1 AD and 4000 AD.
21.2.1
Steps to Define Yearly Holidays
To define holidays for a year, (for instance, for 2000) you have to do the following:
Building the calendar for the year
Step 1
Select ‘New’ from the Actions menu in the Application tool bar or click new icon
Step 2
Enter the year -- 2000 or move to the year 2000 using the arrows
Step 3
To build the calendar for the year, 2000 click the ‘Refresh’ button. This button is called the
‘refresh / build up’ button because it builds the calendar for you. Please note:

On invoking the calendar of any year, you will notice that Saturdays and Sundays are
marked as weekly holidays. This is the default setting of the system

For identification, the working days are marked in black and the holidays in red
21-2

21.2.2
All unauthorised records appear against a blue background. On authorisation of that
record, the background is cleared.
Defining Holidays
To define any other weekly holiday, other than the default, double click the day of the week,
listed on the top row of the screen. For instance, if you double click on ‘F’, all Fridays in the
year would be marked as holidays.
To clear off the default weekly holidays — Saturdays and Sundays, double click on ‘sa’ and
‘s’ written on the top row.
To specify, other annual holidays, double click on the date — the date would be marked as a
holiday.
If you want to unmark a day specified earlier as a holiday, double click on it, once again. You
will notice that the day gets marked in black. Because the change is yet unauthorised, it
appears against a blue background.
21.2.3
Annual Holidays
These are the holidays you have defined for the year calendar on display
You will observe that all holidays are marked in red, while working days in black. (All
unauthorised holiday dates appear against a blue background). To mark a date as a holiday,
double click on it. In case you wish to undo a date marked off as a holiday, double click on it
once again. It changes back to a working day.
With each modification you make, the Modification Number in the made by column below
moves up serially.
21.2.4
Designating Unexpected Holidays for Branch
The holiday calendar for your branch is maintained in the Branch Holiday Calendar screen.
In addition to the holiday calendar, you may need to designate certain days as holidays
unexpectedly, without forewarning. Alternatively, you may also need to roll back a previously
defined holiday date or set of dates. You can do this using the ‘Unexpected Branch Holiday
Maintenance’ screen. You can invoke this screen by typing ‘CGDUNHOL’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
21-3
The screen is as shown below:
In this screen, for the current branch, you can maintain a range of dates, every date within
which will be designated as holidays for the branch. You can also provide a reason for the
designation.
Every unexpected holiday you designate must be authorized for it to be effective
21.2.4.1 Reversing Designated Holiday
In the Unexpected Holiday Maintenance screen, you can also reverse a designated holiday
before the actual date. Specify the holiday date in the Holiday Date field, and check the
Reverse box field alongside it.
When you designate unexpected holidays, any bank or customer value dates for any
transactions, that coincided with the holiday are rolled forward. Any accounting entries passed
are reversed and fresh entries are passed to reflect the new value date.
Note
For the release of uncollected funds, the original transaction date is considered for availability calculations
21.2.4.2 Propagating Local Holidays
Oracle FLEXCUBE facilitates propagation of holiday details maintained in the head branch to
all other active branches. This propagation is based on the value maintained for the CSTB
parameter ‘PROPOGATION_OF_LOH’.
21-4
The system defaults the value as ‘N’ for ‘PROPOGATION_OF_LOH’, indicating that no
propagation is allowed for local holidays; however, you can set the value as ‘Y’ if you need to
allow propagation of holidays.
If the ‘PROPOGATION_OF_LOH’ value is maintained as ‘Y’, then the system will enable
propagation of holiday maintenance from Head branch to other active branches under the
following condition:

Holiday details are authorized.

Holiday details are not maintained for the year for the active branches

Only when the new holiday details are maintained and authorized for the first time.
Propagation of holiday maintenance at HO will be allowed for Un-authorized branch
also, subsequent modification after first authorization, if year is not maintained for the
branch.

When a new branch is created and authorized for the first time

Un-authorized branch with modifications after first authorization and no holiday details
maintained for the year

For the branches which are restricted
Propagated records will have the Maker ID and Checker ID details of the HO.
Propagation of Holidays during Modify Operation
After maintaining 'PROPOGATION_OF_LOH' flag as 'Y', if propagation of holidays during
modify operation is required, then the parameter 'PROPOGATION_OF_LOH_ON_MODIFY'
should also be set as 'Y' in CSTB_PARAM.
In this scenario when both parameters are set as 'Y', the propagation of holidays will also
happen during modification of head office record and the calendar for all branches will be
overwritten by the Head Office calendar.
21-5
22. Maintaining Currency Holidays
22.1 Introduction
You need to maintain a yearly list of holidays, for the currencies, defined in the currency
screen. This is done in the ‘Currency Holiday Calendar’ screen.
The system uses the information maintained in this screen to check whether any settlement,
involving a foreign currency (in the foreign Exchange, Money market, Funds Transfer, Loans
& Deposit modules) falls on that currency’s holiday. If yes, then the system will display a
message stating so, and ask the user for an override
For any schedule or contract maturing at a future date say, 5 years hence, you can input the
future date, only if the calendar for that year has been maintained.
The currency holiday screen is maintained at the Bank Level by the Head Office
22.2 Invoking Currency Holiday Screen
You can invoke this screen by typing ‘STDCCHOL’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
22-1
In this screen, you can maintain a list of holidays for each of the currencies maintained in the
‘currency screen’, for any year between 1 AD and 4000 AD.
22.2.1
Steps to Define Currency Holidays
To define currency holidays for a year, (for instance, for 2000) you have to do the following:
Building the calendar for the year
Step 1
Select ‘new’ from the Actions menu in the Application tool bar or click new icon. A blank
screen appears and the cursor moves to the field ‘Year’
Step 2
Enter the year -- 2000 or move to the year 2000 using the arrows
Step 3
To build the calendar for the year, 2000 click on the ‘Refresh’ button. This button is called the
‘refresh / build up’ button because it builds the calendar for you
Step 4
Select the currency for which you are defining holidays. Please note:
22.2.2

On invoking the calendar of any year, you will notice that Saturdays and Sundays are
marked as weekly holidays for the currency. This is the default setting of the system.

For identification, the working days are marked in black and the holidays in red.

All unauthorised records appear against a blue background. On authorisation of that
record the background disappears.
Defining Currency Holidays
To define any other weekly holiday for the currency, other than the default, double click the
day of the week, listed on the top row of the screen. For instance, if you double click ‘F’, all
Fridays in the year would be marked as holidays.
To clear off the default weekly holidays — Saturdays and Sundays, double click on ‘sa’ and
‘s’ written on the top row
To specify, other holidays, double click on that date — the date would be marked as a holiday
If you want to unmark a day specified earlier as a holiday, double click on it, once again. You
will notice that the day gets marked in black. Because the change is yet unauthorised, it
appears against a blue background
22.3 Uploading Holiday File
SWIFT provides a country-wise holiday file that can be uploaded into Oracle FLEXCUBE. For
all countries where ‘EUR’ is not the local currency, the respective holidays can be uploaded
into the currency holidays tables. For European countries, where ‘EUR’ is the currency, you
can upload the TARGET holidays. Oracle FLEXCUBE allows you to upload these currency
holidays through the ‘BIC/BICPLUS – Upload’ screen. You can invoke this screen by typing
22-2
‘ISDBICPU’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
Here you need to choose the source code as ‘CCH’ from the drop-down list. For further details
about this screen, refer the section titled ‘Uploading the BIC/BICPLUS files into Oracle
FLEXCUBE’ in the ‘Settlements’ User Manual.
The holiday file gets uploaded with two records:

HF Record – wherein ‘EUR’ is not the local currency

HS Record - wherein ‘EUR’ is the local currency
For more details on the file formats of these records, refer the chapter titled ‘Annexure – B –
File Formats’.
22-3
23. Maintaining Clearing Holidays
23.1 Introduction
You need to maintain a yearly list of holidays of your Clearing House. This is defined in the
‘Clearing House Holiday Calendar’ screen.
This set of holidays is maintained at the bank level, by the Head Office. You can invoke this
screen by typing ‘STDCLHOL’ in the field at the top right corner of the Application tool bar and
clicking the adjoining arrow button.
In this screen, you maintain a list of holidays of the Clearing House with which your bank is
associated with.
23.1.1
Steps to Define Clearing House Holidays
To define Clearing House holidays for a year, (for instance, for 2000) you have to do the
following:
Building the calendar for the year
23-1
Step 1
Click new icon.
Step 2
Enter the year — 2000 or move to the year 2000 using the arrows.
Step 3
To build the calendar for the year, 2000 click the ‘Refresh’ button. This button is called the
‘refresh / build up’ button because it builds the calendar for you. Please note:
23.1.2
l
Your clearing house can be identified with the name -- SYS, given to it by the Oracle
FLEXCUBE system. This is displayed in the field ‘Clearing House’
l
Saturdays and Sundays are marked as weekly holidays for the Clearing House. This is
the default setting of the system
l
For identification, the working days are marked in black and the holidays in red
l
All unauthorised records appear against a blue background. On authorisation of that
record the background disappears
Defining Clearing House Holidays
To define an additional holiday, click the particular date which you need to be considered as
holiday. The system will mark that date as a holiday. The system will change the color of the
date to red.
If you click a date that is already marked as a holiday, the system will clear the holiday and
treat that date as a working day. The color of the date text is changed to black, indicating that
it is no more a holiday.
23.1.3
Designating Unexpected Holidays for Clearing House
The holiday calendar for your clearing house is maintained in the Clearing House Holiday
Calendar screen
In addition to the holiday calendar, you may need to designate certain days as holidays
unexpectedly, without forewarning. Alternatively, you may also need to roll back a previously
defined holiday date or set of dates. You can do this using the ‘Unexpected Holiday
Maintenance’ screen.
23-2
You can invoke this screen by typing ‘CGDCLHOL’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
In this screen, for a clearing house, you can maintain a range of dates, every date within which
will be designated as holidays for the clearing house. You can also provide a reason for the
designation.
Every unexpected holiday you designate must be authorized for it to be effective
23.1.3.1 Reversing Designated Holiday
In the Unexpected Holiday Maintenance screen, you can also reverse a designated holiday
before the actual date. Specify the holiday date in the Holiday Date field, and check the
Reverse box field alongside it.
When you designate unexpected holidays, any bank or customer value dates for clearing
transactions, that coincided with the holiday are rolled forward. Any accounting entries
passed are reversed and fresh entries are passed to reflect the new value date.
Note
For the release of uncollected funds, the original transaction date is considered for availability calculations.
23-3
24. Document Maintenance
24.1 Introduction
Before opening an account, the customers are expected to furnish the documents to the bank.
The following sections in this chapter discusses about the type of document to be submitted
and the document checklist to be maintained.
24.2 Maintaining Document Type
You can maintain the various document types in the ‘Document Type Maintenance’ screen.
To invoke this screen, type ‘CSDDOCTY’ in the field at the top right corner of the Application
toolbar and click the adjoining arrow button.
Specify the following details:
Document Category
Specify the document category. The adjoining option list displays all the document categories
that are maintained in the system. You can select the appropriate one.
Document Type
Specify the type of document.
Document Description
Specify a brief description for the document.
24.3 Viewing Document Type Details
You can view the document type details in the ‘Document Type Summary’ screen. To invoke
this screen, type ‘CSSDOCTY’ in the field at the top right corner of the Application toolbar and
click the adjoining arrow button.
24-1
The screen is as shown below:
You can query on records based on any one or all of the following criteria:
l
Authorization Status
l
Record Status
l
Document Type
l
Document Category
l
Document Description
Click ‘Search’ button. The system identifies all records satisfying the specified criteria and
displays the following details for each one of them:
l
Authorization Status
l
Record Status
l
Document Type
l
Document Category
l
Document Description
24-2
24.4 Maintaining Document Checklist Details
You can maintain the various document checklist details in the ‘Document Checklist
Maintenance’ screen. To invoke this screen, type ‘CSDDOCHK’ in the field at the top right
corner of the Application toolbar and click the adjoining arrow button.
Specify the following details:
Process Code
Specify the process code. The adjoining option list displays the process codes that are
maintained in the system. You can select the appropriate one.
Stage
Specify the stage in which you need to maintain the checklist details.
Document Category
Specify the document category. The adjoining option list displays all the document categories
that are maintained in the system. You can select the appropriate one.
Document Type
Specify the type of document.
Mandatory
Indicates whether the document is needed for checklist.
24-3
24.5 Viewing Document Type Details
You can view the document type details in the ‘Document Checklist Summary’ screen. To
invoke this screen, type ‘CSSDOCHK’ in the field at the top right corner of the Application
toolbar and click the adjoining arrow button.
You can query on records based on any one or all of the following criteria:
l
Authorization Status
l
Record Status
l
Process Code
l
Stage
Click ‘Search’ button. The system identifies all records satisfying the specified criteria and
displays the following details for each one of them:
l
Authorization Status
l
Record Status
l
Process Code
l
Stage
24-4
25. Configuring Overrides
25.1 Introduction
The system displays messages in respect of errors that occur when you execute operations
during a work session, in any module. These error messages are also displayed in respect of
automatic or batch processes, such as end of day processes.
Depending upon your requirements at your installation, you might require some of the errors
to be ignored, and others to result in an override being sought from the user for the operation
to proceed. For still others, you might require an online authorization for the operation to
proceed. Accordingly, the implementers at your installation configure the sensitivity of such
errors. Subsequently, you might also need to configure errors to suit your requirements.
25.1.1
Types of Overrides
In Oracle FLEXCUBE, you can assign a level of sensitivity to each override that arises or
occurs during system operation. This level of sensitivity that you assign to an override
indicates the action that will result when that specific override occurs. Accordingly, you can
assign any of the following sensitivity levels to an override:
Ignore
This would mean that no override message would be displayed and the exception would be
ignored
Override
This sensitivity indicates that an override message should be displayed, seeking confirmation
from the user. If the user confirms or accepts the override, processing of the transaction would
proceed; if not, the exception would have to be corrected before transaction processing can
proceed.
For such overrides, you can assign an additional parameter to indicate whether an online
authorization is required if the override is accepted. If you have assigned online authorization
to be required, then, for transactions involving such overrides, an online authorization is
requested as a mandatory procedure. The online authorization limit specified for the
authorizer would be checked during authorization, in addition to the time level of the
authorizer, which should be greater than the user who is input the transaction.
For such overrides, if you have specified that no online authorization is required, the user can
accept the override, and it will not require any online authorization.
Error
This would indicate that, when an exception occurs, an override message would be displayed,
and the transaction cannot be processed further, that is, it would stop being processed until
the exception is corrected.
Online Authorization
This would indicate that an override message would be displayed, seeking confirmation from
the user. However, in this case, online authorization would be required as a mandatory
procedure, if the override were accepted.
Dual Authorization
This would indicate that an override message would be displayed, seeking confirmation from
the user. However, in this case, online authorization would be required as a mandatory
procedure, if the override were accepted. Also, at least two authorizers would be needed to
authorize the transaction.
25-1
Override Types for Batch Functions
For exceptions occurring during execution of automatic or batch processes, you can assign
the Ignore, Override or Error sensitivities.
25.2 Specifying Override Type
In the ‘Overrides Maintenance’ screen, all the error messages that would appear in each
module, with their respective error codes, are displayed. The functions, with respect to which
the error messages could be encountered, are also displayed. You can invoke this screen by
typing ‘CSDOVDME’ in the field at the top right corner of the Application tool bar and clicking
the adjoining arrow button.
In the Type field, you can specify, for each error message, the appropriate sensitivity level –
Ignore, Override, Error, Online Authorization or Dual Authorization.
For error messages in respect of automatic or batch functions, you can specify the
appropriate level in the Batch Type field – Ignore, Override or Error.
For certain overrides, (to which you have assigned the level Override, Online Authorization or
Dual Authorization), you can indicate whether the authorizer must also confirm the override,
by checking the Confirm box.
Note
You can make changes to configurable overrides in the Error Codes Maintenance screen
only after consulting the support team at your installation.
25-2
25.2.1
Maintaining Override Conversion
Click ‘Conversion’ button on the ‘Overrides Maintenance’ screen to maintain the conversion
error codes for the override error code using ‘Overrides Conversion’ screen.
You can enter the following details:
Branch Code
Specify the branch code. If ALL is specified, in all the branches the conversion will be done.
However if it is maintained for a specific branch, only in that branch the conversion will be
done.
Function Id
Specify function Id for which the override should be treated as error.
New Error Code
You can map an already existing error code as the conversion error code or can use the
‘Override Maintenance’ screen to define the same.
You are not allowed to maintain/map conversion error codes for the error code which is a
conversion error-code.
Note
25.2.2
–
If you encounter overrides while processing, the system will check if any conversion
error code mapped for the override for the combination of branch and function Id. If
available then the system will raise the mapped error code instead of the original
error code.
–
The system will allow you to map conversion codes only for the error codes with
type as ‘Override’.
–
If a modifiable error code is changed from ‘Override’ to ‘Error’, then the system will
delete all the conversion error codes maintained for the same.
Maintaining Error Codes
According to the requirements of your bank, you can configure the system to display an error
message if you have not opted for batch balancing at the time of opening a batch.
25-3
This is indicated in the ‘Overrides Maintenance’ screen before opening a batch.
You can invoke the ‘Overrides Maintenance’ screen by typing ‘CSDOVDMT’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
According to your instructions in the ‘Overrides Maintenance’ screen, Oracle FLEXCUBE will
either:

Display an error message if balancing is not allowed at the time of opening a batch
(system will allow you to enter the details of the journal entry only if the option
'Balancing’ is checked)

Display an override message reminding that the batch that has been opened will not be
balanced (even if the option ‘Balancing’ is unchecked, system will display an override
and allows you to proceed further and enter the journal entry details)

Ignore your selection for the option 'Balancing'. System will not display an error
message or override irrespective of your selection for the option ‘Balancing’ and you can
proceed to enter the details of the journal entry in the 'Journal Entry' screen.
According to the requirements of your bank, indicate your option (Error, Override, or Ignore)
for the error code DEBATBAL-1.
Depending on your selection in the ‘Overrides Maintenance’ screen for the error code
DEBATBAL-1, system will either display an error message or an override message or will just
ignore your selection for the option ‘Balancing’.
In the ‘Overrides Maintenance’ screen, if you have indicated the ‘Type’ as ‘Error’ and if you
don’t opt for ‘Balancing, system will display an error message as “The batch is not balanced”.
and ‘Balancing’ is automatically checked. In other words, it is mandatory to opt for balancing.
This is to ensure that all batches that are opened to post entries are balanced.
If you have indicated the Type as ‘Override’ and you haven’t checked the option ‘Balancing’
system will display an override message as “The batch is not balanced. Do you want to
proceed? Yes/No”.
25-4
You can proceed to enter the details of the journal transaction if you select ‘Yes’.
If you have opted for ‘Ignore’ in the ‘Error Codes Maintenance’ screen, irrespective of whether
you opt for balancing of batches or not, system will allow you enter the details of the journal
transaction in the ‘Journal Entry’ screen (system will not display an error message or an
override).
25-5
26. Maintaining Features
26.1 Introduction
In order to improve the performance of the system during online or batch processes, you can
install some features on need basis on the system. This chapter explains the process of
installing features.
26.2 Maintaining Feature ID
To maintain feature IDs, which can subsequently be selected in the ‘Feature ID Maintenance’
screen, invoke the ‘Feature Maintenance’ screen. To invoke this screen, type ‘CSDFTRMN’
in the field at the top right corner of the application tool bar and click the adjoining arrow
button.
Specify the following details in this screen:
Feature
Specify a feature ID which can be subsequently selected in the Feature Maintenance screen.
Applicable
Check this box to indicate whether this feature is applicable.
26-1
You can maintain required features using the ‘Feature ID Maintenance’ screen. You can
invoke this screen by typing ‘CSDFEMNT’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
You can specify the following details:
Branch Code
Specify the branch where the feature needs to be installed. The adjoining option list displays
all valid branch codes maintained in the system. You can select the appropriate one.
Branch Name
The branch name is displayed here based on the chosen branch code.
Feature Id
Specify the feature that should be installed in the branch. You can also choose any of the
following values from the adjoining option list:
Mode Online/Batch
Feature Id
Description
ACCRESTR
Account Restriction feature which need
to be enabled for replace amounts in
overrides with wild char (*)
Online
ACSTHAND
Account Statement Handoff during EOD
Batch
APY
Movement of Annual Percentage Yield
to history
Batch
CCYPOS
CCY position entries updation during
EOD
Batch
CUSTMIS
building of Customer MIS details Transaction/Composite/Fund
Online
26-2
DDRECLOG
During Demand Draft creation - update
of record log and field log
Online
DEFERLIQ
IC Deferred Liquidation
Batch
DORMUPD
Dormancy update during EOD
Batch
DRINTDUE
Dr. Interest Due
Batch
FCTDSTATS
Financial cycle wise account statistics
update
Batch
GLCUSTSTATS
Period/Financial cycle wise customer
GLs statistics update
Batch
GLFCTDSTATS
Financial cycle wise GL statistics update
Batch
GLPTDSTATS
Period wise GL statistics
Batch
ICINTSTMT
IC Interest Statement generation
Batch
ICRATECHG
Rate change Advice
Batch
IRASTMT
IRA Statement generation during EOD
Batch
LDSTMT
Loan Statements generation during
EOD
Batch
LINKSTMTAC
Update of Previous Statement Date and
No during statement generation
Batch
PRODTXNREST
Product and Transaction code restrictions applicability
Batch
PTDSTATS
Period wise account statistics update
Batch
RAC
Account entry serial number derivation
logic when multiple FCUBS instances
exists
Online/Batch
REGCC
Regulatory CC update for customer
account during EOD
Batch
TRACKACCRINT
Tracking of Accrued interest
Batch
USREGCHGS
US Regulatory changes
Batch
VDBALINIC
VD balance update. This is equivalent to
flag at bank parameters level
Online
Installed
Check this box to indicate that the feature should be installed in the branch.
Click save icon in the Application tool bar to save the changes.
26.2.1
Specifying UDF Values
All User Defined Fields (UDFs) linked to the function ID ‘CSDFEMNT’ are displayed in the
‘User Defined Fields’ screen. Invoke this screen by clicking ‘Fields’ button on the ‘Feature ID
Maintenance’ screen.
26-3
The screen is as shown below:
Here you can specify values for each UDF.
Refer the User Manual titled ‘User Defined Field’ for details about defining UDFs.
26.3 Viewing Feature ID Summary
You can view summary of all feature IDs installed across branches, using the ‘Feature ID
Summary’ screen. To invoke this screen, type ‘CSSFEAMT’ in the field at the top right corner
of the Application tool bar and click the adjoining arrow button.
The screen is as shown below:
You can query on records based on any one or all of the following criteria:
l
Authorization Status
l
Record Status
26-4
l
Branch Code
l
Feature ID
l
Installed
Click ‘Search’ button. The system identifies all records satisfying the specified criteria and
displays the following details for each one of them:
l
Authorization Status
l
Record Status
l
Branch Code
l
Feature ID
l
Installed
Double click on a record to invoke the detailed screen for that record.
26-5
27. Purging and Archiving Data
27.1 Purging Data
Purging is a process by which you remove unwanted data from the system. For example, you
may find the interest rates that you have maintained for a financial cycle useless a couple of
years later. You would want to remove such data from the system. You can achieve this by
‘purging’ the data of the system.
There are two types of purging data:

Module Purging

Entity Purging (User Defined)
27.2 Module Purging
The purge function of Oracle FLEXCUBE allows you to purge:

Contracts and transactions that you have entered into,

Data relating to transactions (such as, interest rates)

Limits history (Liability, Lines and Line Utilization history)

GL Average Balance and Customer Account statistics
You can purge the contracts (or transactions) that you have entered into in the following
modules of Oracle FLEXCUBE:

Foreign Exchange

Money Market

Loans

Deposits

Data Entry

Standing Instructions

Letters of Credit

Bills and Collections
You can purge data from the following modules:

Accounting

Currency

General Ledger

Interest and Charges

Messaging

MIS

Reconciliation

Receivable Liquidation
You can also purge data relating to transactions. For example, you can purge the currency
rates that you have maintained, the messages in the messaging system of Oracle
FLEXCUBE, the User Data Elements that you used to compute interest, interest statement
details, user information maintained in the Security Management System of Oracle
FLEXCUBE, customer information, and so on.
27-1
The system will automatically purge data according to the parameters that you define in the
Purge Details Maintenance screen.
27.3
Maintaining Purge Details
In the ‘Purge Details Maintenance’ screen, you can define the parameters for purging data
from the system. For instance, you may want to purge the contracts entered into in the
previous financial cycle. Or, you may want to retain exchange rates in the system for a specific
period. These are examples of parameters that you can define in the Purge Details
Maintenance screen. You can invoke this screen by typing ‘CSDPURGE’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
27.3.0.1 Specifying Module
In the Purge Details Maintenance screen you must first specify the module for which you are
defining parameters. All parameters that you define subsequently will only apply to the
module that you specify.
You can enter a description of the module for which you are maintaining purge details.
Note
For purging limits history which is Liability, Lines, and Lines Utilization history, you must
specify LM as the module code. Limits history data is purged for the current branch only.
27.3.0.2 Specifying Nature of Data to be Purged
You can opt to purge contracts (of the module you specified) along the following criteria. You
may either choose to purge any of the following:

Liquidated contracts

Closed (applicable only to the BC and LC modules)

Reversed contracts
27-2
When you run the purge process, only those contracts that are in the status that you specified
will be purged. That is, only contracts (in the module you specified) that are liquidated, closed,
and/or reversed, depending on your specification, will be purged from the system.
Similarly, if you want to purge

Exchange rates (from the Currency module), you should choose the ‘None’ option.

Data from the Reconciliation module, you should choose any of the following options,
depending on the data that you want to purge. The options available are:
–
System Date Relative
–
Match Relative
–
Closed Match
–
Closed External Statement
Retention Period
The retention period, as the term suggests, is the period for which data is stored in the system.
For each module in Oracle FLEXCUBE, you can specify the retention period.
When you run the purge process on any given day, only the data that is beyond the retention
period that you specified will be purged. The following example illustrates this concept.
For example,
The requirement: You would like to retain foreign exchange contracts that were liquidated 60
days prior to the running of the purge process, in the system. (That is, if the current system
date is 30 June 1999 and you do not wish to purge the foreign exchange contracts that were
liquidated between 1 May 1999 and 30 June 1999).
Solution: In the Retention Period field enter ‘60’ (note this value is expressed in days), and in
the ‘Status’ field choose the ‘Liquidated’ option.
Result: If this setup is authorised, and you run the purge process on 30 June 1999, the current
system date, all foreign exchange contracts that you liquidated prior to 1 May 1999 will be
purged. Contracts that were liquidated on or after 1 May 1999 will not be purged.
27.4 Entity Purging
In entity purging, you can archive or purge the data from the main tables and its child tables.
You can also configure the purge type and the frequency of data purging.
There are 3 parts in an entity purging:
Purge Parameter Definition
The purge parameter definition is achieved through ODT. The ODT generates the purge
source files which is then deployed in Oracle FLEXCUBE.
The ODT is used for the following:

Maintaining the list of entities that need to be purged.

Maintaining the purge behaviour.

Maintaining the mode of purge.

Maintaining he purge frequency.

Maintaining the archive table suffix if the purge behaviour is to archive the data.

Maintaining the filter criteria to determine what data to purge.
27-3
You can capture the above parameters to define the entity and purge preferences.
Purge Parameter Configuration
Once the ODT generated scripts are deployed in Oracle FLEXCUBE, they can be reconfigured in the purge parameter configuration.
Purge Execution
You can execute the purge in two modes:

Batch Mode - In the batch mode you have to maintain the purge entity batch
CSBPURGE. The AEOD batch process starts the purge process in which all the entities
that are scheduled for purge on that day gets purged.

Ad-hoc Mode - This mode supports purging of a single entity at any time.
You can define entities for purging in any module. However, pre-defined entities are available
for the following modules:
27.4.1

Accounting

Bills and Collections

Letters of Credit

Funds Transfer

SWITCH
Configuring Purge Parameters
You can configure the parameters for purging the data through ‘Purge Parameter
Configuration Maintenance’ screen. You can query and modify entities in this screen.
However new operation is not allowed. To invoke this screen type ‘STDPGMNT’ in the field
at the top right corner of the Application tool bar and clicking the adjoining arrow button.
The following details are captured in this screen:
27-4
Entity Id
Select the entity Id from the adjoining option list.
Purge Frequency
Select the frequency of purge from the adjoining drop-down list. The available options are:

Ad-hoc - If the frequency is selected as Adhoc, then this particular entity will not be
picked up for purging in the batch purge. This entity can be purged only by the Adhoc
Purge option.

Daily - The purge routine for the entity having daily frequency will run daily

Weekly - The purge routine for the entity having weekly frequency will run every week.
The day of the week will be determined based on the purge start date. If the purge start
day is a Monday, then the purge routine runs on every Monday. If you want to change
the day of the week, then ‘Next Purge Date’ needs to be updated.

Monthly - The purge routine for the entity having monthly frequency will run every
month. It is advised that the purge routines are not configured during the month-ends,
as Purge Anniversary dates so as to reduce the processing load on the month-ends

Quarterly - The purge routine for the entity having quarterly frequency will run every
quarter.

Half-Yearly - The purge routine for the entity having half-yearly frequency will run every
6 months.

Yearly - The purge routine for the entity having yearly frequency will run every year.
Last Purge Date
The system displays the date on which the entity is purged.
Next Purge Date
Specify the next date for purging the entity. The system populates this date if purge frequency
is not ad-hoc.
The next purge date is left blank initially. The system picks up for automatic purging of data
and updates the subsequent dates only if the next purge date is provided.
Commit Frequency
Specify the commit frequency while purging the data. The default value for commit frequency
is 100.
For example,
If the value is 100 (which is default), then the purge routine will commit after every 100
records.
Query
The system displays the full query for the entity.
Filter Details
Filter Name
The system displays the name of the purge filter criteria.
Column Data Type
The system displays the data type for the filter.
LHS
The system displays the LHS of the filter expression.
27-5
Operator
The system displays the operator for the filter.
RHS
The system displays the RHS or the value for the expression based on which data is purged.
However RHS can be modified.
Branch Restrictions
Click on ‘Branch Restrictions’ to allow or disallow entities across branches.
Entity Id
The system displays the entity ID.
Branch Restriction
Indicate whether the branch restriction is ‘Allowed’ or ‘Disallowed’.
Branch Code
The system displays the branch code. However, you can add the branch codes here.
You should configure the branch restrictions as part of first time entity configurations.
27.4.2
Viewing Purge Parameter Configuration Details
You can view the purge parameter configuration details maintained in the 'Purge Parameter
Configuration' screen using the 'Purge Parameter Configuration Summary' screen. You can
27-6
invoke this screen by typing 'STSPGMNT' in the field at the top right corner of the Application
tool bar and clicking on the adjoining arrow button.
In the above screen, you can base your queries on any or all of the following parameters and
fetch records:

Authorization Status

Entity Id

Record Status
Select any or all of the above parameters for a query and click 'Search' button. The system
displays the records meeting the selected criteria:
27.4.3

Authorization Status

Record Status

Entity Id

Description
Processing Ad-hoc Purge
You can process ad-hoc purge through ‘Ad-hoc Purge Process’ screen. An entity configured
as automatic can also be started from this screen. However, this would not change the regular
frequency cycle of the entity.The next purge date is not effected or changed if started from
27-7
this screen.To invoke this screen type 'AEDPGOP' in the field at the top right corner of the
Application tool bar and clicking on the adjoining arrow button.
Entity Id
Select the entity ID from the adjoining option list.
Purge Frequency
The system displays the purge frequency.
Number of Threads
The system displays the number of parallel streams in which the purge should be run.
However, you can modify it.The purge batch process is split into specified numbers and
executed in separate threads.
Description
The system displays description on the entity ID.
Next Purge Date
The system displays the next purge date.
Last Purge Date
The system displays the last purge date.
Query
The system displays the query for the entity.
The system displays the following details:

Filter Name - Name of the purge filter criteria

Column Data Type - Data type of the filter

LHS - LHS of the filter expression

Operator - The operator for filter

RHS - RHS or the value for the expression based on which data is purged. However,
you can modify this.
27-8
Note
27.4.4
–
Only ‘Execution Filter’ conditions are displayed in the Filter Condition Multi Entry
Block.
–
‘Business Filter’ conditions will not be displayed.
Parallel Stream Maintenance
You can inquire the number of streams through ‘Parallel Stream Maintenance’ screen. To
invoke this screen type 'CSDPSTMN’ in the field at the top right corner of the Application tool
bar and clicking on the adjoining arrow button.
Function Id
Select the function ID from the adjoining option list.
Number of Streams
The system displays the number of streams in which the purge should be run. The purge
batch process is split into specified numbers and executed in separate threads.
27-9
27.4.5
Inquiring Purge Log
You can inquire the purge history through the Purge Log Inquiry screen. To invoke this screen
type 'AEDPGLOG' in the field at the top right corner of the Application tool bar and clicking on
the adjoining arrow button.
Entity Id
Select the entity Id from the adjoining option list.
From Date
Specify the date from when the log should be enquired.
To Date
Specify the date till when the log should be enquired.
The system displays the following details:

Entity ID

Run ID

Date

Start Time

End Time

Status

Error

Number of Records

Query
27.5 Archiving Data
You can archive entities on a regular basis. Archival would involve moving data from the
production data stores to designated archival data stores based on the archival criteria
specified.
Following are the steps involved in setting up the archival function:
1. Archival Framework: You can define a framework for archival generically and perform
the following actions:
27-10

Identify and define functional areas that needs to be archived

Identify entities that should be archived and understand the relationships between them

Specify names for archival data stores

Define archival criteria, frequency and mode of archival. You can define the logic
needed for archival
The archival framework performs the archival for each functional area as mentioned below:

Defines archival data stores for each of the production data store. The archival data
stores are created in a separate schema in the production database itself.

For each of the archival data store, a synonym is created in the production schema.

The archival routine moves the data from the production data stores to the archival data
stores using the synonym created.
2. Execution of Archival Framework: Archival framework dynamically produces
executables for each functional areas identified for archival. These executables should be
scheduled using any scheduler to run at specified times
3. Retrieval of Archived Data: Data that has been archived can be retrieved on need basis
using SQL queries or by defining customized reports.
You can develop the following archival entities and configure the retention period and purge/
archival execution:
27.5.1

CASA and GL Transaction

ATM/POS/IVR Transaction Log

Payment (Zengin) Transactions

Branch Transaction Logs

Retail Teller Transaction Logs

Interface Gateway Logs

Generic Interface(File/Batch) Upload Logs

Closed CASA Archive

Matured TD Archive

Liquidated Loans Archival (Corporate and Retail)

Other Entities

Interest Rates History

Exchange Rates History

Security Management Logs

Audit Logs
Archival of CASA and GL Transaction History
You can archive the accounting entries posted to the customer and general ledger accounts
of CASA and GL transactions. During archive, all the transactions that satisfy the archival
criteria are moved to a different data store called the archival data store from the active data
store.
Following are the parameters to be used to setup the entities under CASA and GL
Transactions History:
27-11
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
ACTB_HISTORY and related data stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Proposed retention period is two years
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Definition or Archival Criteria
Following are the archival criteria:

You can archive the CASA and GL transactions prior to a cut-off date. Cut-off date can
be computed based on a retention period.

The cut-off date should always be a period end date.
Archival Process
You can trigger the archival process at the bank level, where the transactions are processed
branch by branch.

Customer Accounts (CASA): For all customer accounts, following are the archival
process:
–
The balance as of the cutoff date is computed by netting all the accounting entries
posted to the customer account prior to cutoff date.
–
All the entries posted to the account prior to the cutoff date is moved to the archival
data store.
–
One entry with the net balance computed for the account is inserted in the
accounting history data store. The value of individual fields are as follows:
Field Name
Value
Transaction date
Cut off date
Value date
Cut off date
Financial Cycle
Financial cycle of the cutoff date
Period Code
Period code of the cutoff date
27-12
Field Name
Value
Event code
PURG-A new Event code exclusively for
archival and purging
Module
PG
Transaction Code
PGR
Amount_tag
PURG_NET_BAL
Exchange Rate
This would be derived again based on the
netted FCY and LCY amounts

–
Book dated balance data store and value dated balance data store is archived for
all records for the account prior to the cut-off date.
–
One row for the cut-off date is inserted for the booked dated balance and value
dated balance data store.
–
Customer GL breakup data store is archived for all rows prior to and including the
financial cycle and period code of the cut-off date.
–
Customer GL balance in GL balance data store is archived for all financial cycle and
period codes prior to the financial cycle and period code of the cut-off date.
General Ledgers: For all General Ledger Accounts, following are the archival process:
–
For each internal leaf GL, the balance as of cut-off date is computed by netting all
the accounting entries posted to the General Ledger prior to the cut-off date.
–
All entries posted to the general ledger prior to the cut-off date is moved to the
archival data store.
–
One entry with the net balance computed for general ledger is inserted in the
accounting history data store. The transaction date and value date will be the cutoff date and financial cycle and period code will be that of the cut-off date.
–
All rows in GL balance table for the GL, financial cycle, period codes prior to and
including the financial cycle, and period code of the cut-off date is archived.
–
Rows for the GL in booked dated balance history and value dated balance history
are archived for all dates prior to the cut-off date.
–
One row each in book dated balance history and value dated balance history is
inserted for the cut-off date with the net balance computed as the balance.
Restriction of Back Valued Transactions
Back valued transactions including reversals are restricted for dates prior to the last archival
date as follows:

The date of archival is stamped for each branch where CASA/GL transactions are
archived.

Accounting entry posting mechanism checks the data of last archival for the branch
before posting transactions with the value date of the transaction.The system does not
allow the transactions, if the value date happens to be before the last archival date for
the branch.
Retrieval of Data
Data Retrieval for CASA and GL transactions process takes place as follows:
27-13
27.5.2

V12 Query Screens and Statements: Only transactions that are available in active
data stores are available for query from V12 query screens and statements. Archived
data cannot be queried from these screens.

Channel Queries: Queries from various channels like internet banking, mobile banking
and so on can access only active data. Channels cannot query archived data.

Archived Data: You can retrieve the data that has been archived on need basis by
using SQL queries or by defining customized reports.
Archival of Closed CASA Accounts
During archival of CASA account entity, only closed CASA account master details along with
its associated details are archived. Transactions posted to the CASA account are no part of
the CASA account entity archival. Archival process involves moving all records for accounts
satisfying archival criteria to an archive data store from the main active data store.
The archival parameters maintenance is as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Record level Purging, the related data in all
child data store shall be archived
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
STTM_CUST_ACCOUNT and related data
stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Two Years after the closure date
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Definition or Archival Criteria

Only Closed CASA accounts can be archived.

All CASA accounts closed prior to the cut-off date is archived. The cut-off date is
computed based on a configurable retention period. You can configure the retention
period.
Archival Process
The following processes are followed for archiving CASA account data:

The system picks all accounts that satisfy the archival criteria

For each account picked up, all the data and its associated information are moved from
the active data store to archival data store
27-14
Retrieval of Data
27.5.3

V12 Query Screens and Statements: Only data from active data stores are available
from V12 Query Screens and Statements. You cannot query archived data from these
screens.

Channel Queries: Queries from channels like internet banking, mobile banking, and so
on is restricted to active data. Archived data cannot be queried from these screens.

Archived Data: Data that has been archived can be retrieved on need basis by using
SQL queries or by defining customized reports. Standard query screens or reports
would not be provided for archived data.
Archival of TD accounts
You can archive the matured term deposit, structured deposit, dual currency deposit and triple
currency deposit.
Segregation of TD transactions
TD and CASA transactions share the same data store. Thus archival of CASA transaction
data store may result in archival of transactions belonging to active TD’s falling in the archival
period getting removed from the active data store. This will impact the TD account statements.
For segregating transactions that belong to active TDs, the following steps are performed:

While moving the data from the daily transaction logs to the transaction history logs, a
copy of the TD transactions are created in a separate data store. This would facilitate
the generation of the account statements even in case of archival of the history
transaction data of TD.

The ‘TD Audit Trial’ screen displays the data from the new TD data store as well.
Archival of Matured TD Accounts
TD account data refers to information related to TD account definition and the events during
the life cycle of the TD, such as deposit booking, accrual, maturity, interest liquidations and
so on. Archival involves moving all matured TD account data and its associated transactional
data to an archive data store from the main active data store. This archival is also applicable
to Structured Deposits (SD), Dual Currency Deposit (DCD) and Triple Currency Deposit
(TCD) accounts.
The archival parameters are as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Record level Purging, the related data in all
child data store shall be archived
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
STTM_CUST_ACCOUNT and related data
stores
27-15
Sl.No
Parameter Name
Value
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Proposed retention period is 2 years after
liquidation
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Definition of Archival Criteria

Only closed TD accounts and their associated data can be archived.

All closed TD accounts prior to a cut-off date will be archived. The cut-off date is
computed based on a configurable retention period. You can configure the retention
period.
Archival Process
For TD accounts that satisfy the archival criteria, all the TD definition data along with the
associated transactions data from the newly created TD transaction data store will be
moved to their respective archival data stores.
Retrieval of Data
27.5.4

V12 Query Screen: You can fetch data from the new TD transactional data store in the
‘Customer Account TD Audit Trail’ screen. In this screen, you can query only active
data.

Channels Queries: Queries from channels like internet banking, mobile banking and
so on is restricted to only active data stores.

Archived Data: You can retrieve the data that has been archived on need basis by
using SQL query or by defining customized reports.
Archival of Liquidated Loans
Loans account data comprises of data relating to loan definition, schedules, interest rates,
payments, and so on. Transactional Data are events that happen as part of the loan life cycle,
loan booking, disbursals, interest accruals, interest liquidation, loan re-payments and so on.
Archival of loan data involves moving all records satisfying the archival criteria to a set of
archival data stores from active data stores. Loan transactional data is archived along with the
loan account data.
The archival parameters are as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Record level Purging, the related data in all
child data store shall be archived
27-16
Sl.No
Parameter Name
Value
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
STTM_CUST_ACCOUNT and related data
stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period/Liquidation
days
Proposed retention period is 2 years after
liquidation
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Definition of Archival Criteria

Only closed loan accounts can be archived.

All closed loan accounts prior to a cut-off date is archived. The cut-off date is computed
using a configurable retention period. You can configure the retention period.
Archival Process
The archival process moves all the loan definition, schedules, rate records, payment records
and other loan associated data including loan transactional data to their respective archival
data store, for all loan accounts that satisfies the archival criteria.
Retrieval of Data
27.5.5

V12 Query Screen: You can use the ‘Events Diary’ query screen for loan data to query
data related to loan accounts and transactions from active data stores.

Channel Queries: Channels like internet banking, mobile banking can query only active
data stores for loan account and transaction information.

Archived Data: You can retrieve data that has been archived on need basis by using
SQL queries or by defining customized reports.
Archival of ATM/POS/IVR Transaction Logs
ATM, POS and IVR transaction logs are purged from the online data store to a history data
store on a daily basis. This activity is completed as part of the end of day (EOD) process.
The archival parameters for ATM/POS/IVR transaction logs are as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
27-17
Sl.No
Parameter Name
Value
3
Purge/Archival Frequency
Monthly
4
Main Entity to be Purged/
Archived
Data stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
End of Day Batch
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
ATM/POS/IVR transactions prior to a cut-off date should be archived. The cut-off date is
computed based on a retention period. You can configure retention period.
Archival Process
Each ATM/POS/IVR transaction log record that satisfies its archival criteria is moved from the
active data stores to their respective archival data stores.
Retrieval of Data
Archived Data: You can retrieve the data that has been archived on need basis by using SQL
queries or by defining customized reports.
27.5.6
Archival of Payment (Zengin) Transactions
Purging and Archival process within FP module allows moving old data from transaction table
to a corresponding set of archival tables. As a result only data that is relevant for operation of
the bank is retained in the transaction tables.
Payment (Zengin) Transactions are purged from the online data store to a history data store
on a periodic basis.
Archival for Payment (Zengin) transactions can be setup with the parameters as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly /Quarterly / Annual/
Ad-hoc)
4
Main Entity to be Purged/
Archived
PMTB_CONTRACT_HISTORY and related
data stores
27-18
Sl.No
Parameter Name
Value
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
You can capture archival criteria for each of the Zengin Payment transaction log. The criteria
for archival of each of the Zengin Payment transaction log data is cut-off date or a retention
period. The cut-off date can either be provided directly or can be indirectly computed using a
retention period.
Archival Process
Each of Zengin’s Payment transaction log data that satisfies its archival criteria based on the
archival rule will be moved from the active data stores to their respective archival data stores.
Retrieval of Archived Data
27.5.7

V12 Query Screens: V12 query screens are available for branch and Retail Teller
transaction logs, File/Batch Uploads using Generic Interface and Payment (Zengin)
Logs. You can only query the active data stores.

Channel Queries: Channels like internet banking, mobile banking, and so on. can
query only Payment (Zengin) transaction logs. Channels queries are restricted to active
data stores only and cannot access archived data stores.

Customized Reports: Customized reports can used for querying each of the Zengin’s
payment transaction logs. Customized reports can query both active and archived data
stores.
Archival of Branch Transaction Logs
You can archive Branch Transaction Logs from the online data store to a history data store
based on the archival days maintained in the branch parameter data store, which is
completed as part of branch end of day process. You can also use V12 archival framework to
archive the branch history data into another level of archival.
The archival for Branch Transaction Logs setup parameters are as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
3
Purge/Archival Frequency
Monthly
4
Main Entity to be Purged/
Archived
FBTB _OVD_HIST and related data stores
27-19
Sl.No
Parameter Name
Value
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
End of Day Batch
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
The cut-off date is computed based on the retention/purge days maintained. You can
configure the retention period as and when required.
Branch Transaction History Logs is purged prior to a cut-off date. This purging activity is
completed as a part of V12 archival process.
Archival Process
Each branch transaction log data that satisfies its archival criteria is moved from the active
history data stores to their respective archival data stores.
Retrieval of Data
Archived Data: Data that has been archived can be retrieved on need basis by using SQL
queries or by defining customized reports.
27.5.8
Archival of Retail Teller Transaction Logs
Retail Teller Transaction Logs are purged from the online data store to a history data store on
a daily basis as part of the end of day (EOD) process.
Archival for Retail Teller Transaction Logs is setup with the parameters as follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
3
Purge/Archival Frequency
Monthly
4
Main Entity to be Purged/
Archived
DETB_RTL_TELLER_HIST and related
data stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
End of Day Batch
27-20
Sl.No
Parameter Name
Value
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Retail Teller transaction log prior to a cut-off date can be archived. The cut-off date is
computed based on a retention period. You can configure the retention period as and when
required.
Archival Process
Each retail teller transaction log data that satisfies its archival criteria is moved from the active
data stores to their respective archival data stores.
Retrieval of Data
27.5.9

V12 Query Screens: V12 query screens are available for Branch and Retail Teller
transaction logs, File/Batch Uploads using Generic Interface and Payment (Zengin)
Logs. These screens can only query the active data stores.

Archived Data: Data that has been archived can be retrieved on need basis by using
SQL queries or by defining customized reports. Standard query screens or reports
would not be provided for archived data.
Archival of Interface Gateway Logs
Interface Gateway Logs are purged from the online data store to a history data store on a daily
basis as part of the end of day (EOD) process.
Archival for Interface Gateway Logs can be setup with the parameters as below
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
3
Purge/Archival Frequency
Monthly
4
Main Entity to be Purged/
Archived
GWTB_MSG_IN_HISTORY and related
data stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
End of Day Batch
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
27-21
Gateway Interface Logs prior to a cut-off date can be archived. The cut-off date is computed
based on a retention period. You can configure the retention period as and when required.
Archival Process
Each gateway interface log data that satisfies its archival criteria is moved from the active data
stores to their respective archival data stores.
Retrieval of Data
Archived Data: Data that has been archived can be retrieved on need basis by using SQL
queries or by defining customized reports.
27.5.10 Archival of Generic Interface (File/Batch) Upload Logs
Generic Interface (File/Batch) Upload Logs are purged from the online data store to a history
data store on a daily basis as part of the end of day (EOD) process.
Archival of Generic Interface (File/Batch) Upload Logs can be setup with the parameters as
follows:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging – All records satisfying the criteria would be archived
3
Purge/Archival Frequency
Monthly
4
Main Entity to be Purged/
Archived
GITA_UPLOAD_MASTER and related data
stores
5
Data Store for Archived Data
Archival data store names
6
Retention Period
3 Months - Records older than 3 months
would be archived
7
Purge/Archival Execution
End of Day Batch
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Generic Interface upload logs prior to a cut-off date can be archived. The cut-off date is
computed based on a retention period. You can configure the retention period as and when
required.
Archival Process
Each Generic Interface upload data or log data that satisfies its archival criteria can be moved
from the active data stores to their respective archival data stores.
27-22
Retrieval of Data

V12 Query Screens: V12 query screens are available for Branch and Retail Teller
Transaction Logs, File/Batch Uploads using Generic Interface and Payment (Zengin)
Logs. These screens can only query the active data stores.

Archived Data: Data that has been archived can be retrieved on need basis by using
SQL queries or by defining customized reports.
27.5.11 Archival of Exchange Rate History
Purge framework can be used to archive the exchange rate history.
Following are the parameters to setup the archival of the exchange rate:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
Data store names
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Proposed retention period is yearly
7
Purge/Archival Execution
Preferably any time apart from the EOD
time.
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Exchange Rate History data prior to a cut-off date can be archived. The cut-off date would be
computed based on a retention period. You can configure the retention period as and when
required.
Archival Process
Each history data record that satisfies its archival criteria is moved from the active data stores
to their respective archival data stores.
Retrieval of Data
Archived Data: Data that has been archived can be retrieved on need basis by using SQL
queries or by defining customized reports.
27.5.12 Archival of Security Management Logs
Purge framework can be used to archive the security maintenance logs.
27-23
Following are the parameters to setup the archival of the security maintenance logs:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
Data store names
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Proposed retention period is yearly
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Security Management Logs prior to a cut-off date can be archived. The cut-off date is
computed based on a retention period. You can configure the retention period as and when
required.
Archival Process
Each security log data that satisfies its archival criteria is moved from the active data stores
to their respective archival data stores.
Retrieval of Data
Archived Data: Data that has been archived can be retrieved on need basis by using SQL
queries or by defining customized reports.
27.5.13 Archival of Audit Logs
Purge framework can be used to archive the audit logs.
Following are the parameters to setup the archival of the audit logs:
Sl.No
Parameter Name
Value
1
Purging or Archival
Archival
2
Purge/Archival Mode
Bulk Purging
27-24
Sl.No
Parameter Name
Value
3
Purge/Archival Frequency
This can be setup by the bank as per their
requirement (Monthly/Quarterly/Annual/Adhoc)
4
Main Entity to be Purged/
Archived
Data store names
5
Data Store for Archived Data
Archival data store names
6
Retention Period
Proposed retention period is monthly
7
Purge/Archival Execution
Preferably any time apart from the EOD time
8
Retrieval of Archived Records
SQL Queries/Customized reports can be
used. Standard screen or report would not
be provided for Archived records
Audit Logs prior to a cut-off date can be archived. The cut-off date can be computed based
on a retention period. You can configure the retention period as and when required.
Archival Process
Each audit log data that satisfies its archival criteria is moved from the active data stores to
their respective archival data stores.
Retrieval of Data
Archived Data: Data that has been archived can be retrieved on need basis by using SQL
queries or by defining customized reports.
27-25
28. Support 24x7
28.1 Introduction
Oracle FLEXCUBE is available on a 24x7 basis for two broad channels Web service & Web
Branch. During EOD batch process, transactions are tanked and then get processed after the
batch is completed.
This document details about the 24x7 support feature in FCUBS.
28.1.1
Gateway Messaging
Oracle FLEXCUBE processes the following channel transactions, 24x7:

FLEXCUBE UBS - Gateway - Web service
–
Customer (New, Modify, Close)
–
Customer Account (New, Modify, Close)
–
Fund Transfer
–
Payment & Collections
–
Consumer Loans
All new requests for maintenance functions or online functions when the branch available
status is ‘No’ are accepted at the Gateway messaging layer. The Gateway messaging layer
does not route the transaction requests during the Date Change Window.
28.1.2
Web Branch
Oracle FLEXCUBE processes the following channel transactions, 24x7:

28.1.3
FLEXCUBE UBS - Retail Web Branch UI
–
Retail Teller
–
Instruments
–
Clearing
–
Utility Payments
–
Retail Loan
Batch Processing
Every day while processing a channel transaction, system checks for the branch availability
status. The system displays the Branch Available status. If the status is ‘Yes’, it indicates that
the branch can accept transactions for the day and if the status is ‘No’ , then it indicates that
the transactions will be accepted but it will be in effect only from the next business day.
Accordingly accounting entries will be passed checking the following, for tanking branch
transactions:

The Branch Available Status

The Branch date and host date i.e. entries will be tanked if branch date is ahead of host
date
When the Branch Available status is ‘NO’ or if branch date is ahead of host date, then the
transactions will be tanked. These transactions will be untanked by the BOD program which
runs post date change i.e. POSTDTCH.
28-1
The branch available status can be changed from Yes to No in two ways.


Auto
–
At the start of EOTI if the branch available status is not ‘No’.
–
At the start of ICEOD if the branch available status is not ‘No’.
–
At the start of EOFI if the branch available status is not ‘No’.
–
Drop of End of Transaction Input
–
System Date Change
Manual
–
Manual – Scheduling and Execution as EOD batch.
IC EOD Process
The account resolution during IC EOD process excludes accounts that are with account
creation status as Tanked.
Drop - End of Transaction Input (EOTI)
If the branch is not available during the Drop End Of Transaction Input, system automatically
resets the Branch available status to ‘Yes’. Also all the tanked transactions and accounting
entries are released.
All transactions that are tanked would be released with tanked status as No and advices and
payment messages if suppressed would be generated.
For the process that started when the branch available status was Yes, then the Status
change to ‘No’ cannot be changed till the completion of the process. This is applicable for DE
Batch upload process.
28.1.4
Processing Different Categories during EOD
During EOD batch process, the categories like maintenance and financial transaction process
are explained below.
28.1.4.1 Processing Maintenance
The maintenance process includes:

New Customer Creation

Customer Amendment

Customer Closure

New Account Creation

Account Amendment

Account Closure
Creating Customers
While creating customer if the branch available status is no, then the creation date gets set to
next branch working date. The customer details report requests are accepted and the
processing of the same starts only during the next branch available status. The report would
include the customer creation date also.
Creating Customer Accounts
The customer account creation requests are processed with the tanked status as ‘Yes’ if the
branch is not available for transaction and these accounts are not considered for Interest &
Charges calculation process
28-2
After the branch is available after the date change process, tanked status gets changed to
‘No’ and initiation entries of term deposit that are tanked are released with transaction date
moved to next working date.
Processing TD Account Creation
The Term Deposit creation requests are processed with the tanked status as ‘Yes’ if the
branch is not available for transaction. If the customer account is displaying as tanked, it
indicates that the customer account creation request was processed when the branch
available status is No or when branch date was ahead of host date.
The process when the TD account creation is received when the branch is unavailable or
when branch date is ahead of host date is as follows:

The TD account creation would be accepted with transaction status as Tanked.

The initiation accounting entries will be posted as tanked entries.
The Term Deposit accounts that are in tanked status will not be considered for Interest &
Charges calculation process.
After the branch available status is changed to ‘Yes’ then:

The TD account tanked status will set to No.

The Initiation entries of term deposit that are tanked would be released with transaction
date moved to next working date.
Processing TD Account Redemption
The Term Deposit Redemption Transactions are processed partially if the branch is not
available for transaction or when branch date is ahead of host date. Partial Redemption of the
account is processed even after branch available status is ‘No’ or branch date is ahead of host
date

For TD redemption by Transfer to Savings, TD redemption by Transfer to GL, the RT
Transaction done for moving the available funds will get tanked.

For TD redemption By Bankers Cheque, the Instrument Transaction done for Issuing
the BC will get tanked.
After the branch available status is changed to ‘Yes’ then:

The transaction status of the TD Redemption Transaction will be changed to Active.
The tanked accounting entries if any would be un-tanked by the batch process.
Processing Account Closure
The Close out Withdrawal Transaction is not allowed if the branch is not available for
transaction or when branch date is ahead of host date.
28.1.4.2 Processing transactions:
The transaction process includes:

Payments and Collections

Retail Loan

Fund Transfer

Retail Teller

Instruments

Standing Instructions

Clearing
28-3

Utility Payments
Processing Funds Transfer
The fund transfer requests are processed with tanked status if the branch is not available for
the transactions assuming that the FT Product cut-off time is maintained such that the cut-off
time is past for the FT transaction when the Branch available status is changed to No.
The process when the FT transaction is received when the branch is unavailable is as follows:

The FT transaction would be accepted with tanked status as Yes.

There would be no change in the debit & credit value date derivation which currently
takes in to consideration the value date spreads and cut-off time maintained in FT Value Date Spread maintenance.

There would be no change in the derivation of the following processing dates –
–
Messaging Date
–
Accounting Entry Date
–
Rate Date

If the Messaging Date of the FT transaction is derived as the application date then the
message generation would be suppressed and the message will be generated once the
branch available status changes to ‘Yes’

Accounting entries would be posted with tanked status if the accounting date derived is
as of the application date.

Advices associated with FT transaction events if any would be suppressed and
generated once the branch available status changes to ‘Yes’
After the branch available status is changed to ‘Yes’ after the business date change then

The tanked status of the FT transaction would be set to No

The tanked accounting entries if any would be un-tanked by the existing batch process
for releasing the accounting entries.

Advices of the FT transaction if suppressed would be generated.

If the payment message generation for FT transaction was suppressed, the same would
be generated during the transaction release.
The following FT operation requests when the branch available status is No would be
accepted and the processing would be deferred till the branch available status is yes. The
requests would be tanked at the FC UBS Gateway messaging layer.

Cancellation of FT Transaction

Amendment of FT transaction

Liquidate FT transaction

Reversal of FT transaction
Processing Payments and Collection
The PC requests are processed with the tanked status as ‘Yes’ if the branch is not available
for transaction assuming that the PC Product cut-off time is maintained such that the cut-off
time is past for the PC transaction when the Branch available status is changed to No.
If the PC request is received past the cut-off time maintained at the product/customer level,
the activation date would be moved to next working date with the other processing dates
resolved based on the activation date keeping as same. For Debit Liquidation - DRLQ event
and Credit Liquidation - CRLQ event dates derived is application date, then the accounting
entries are posted with tanked status.
28-4
For a book transfer, if the dispatch date derived is the application date then the offset
transaction is generated and processed. The offset transaction accounting entries as part of
DRLQ event and CRLQ event are posted with tanked status if the accounting entry date
derived is the application date. After the branch status is available, then the tanked accounting
entries if any would be un-tanked by the existing batch process for releasing the tanked
accounting entries.
The following PC operation requests when the branch available status is No would be
accepted and the processing would be deferred till the branch available status is yes. The
requests would be tanked at the FC UBS Gateway messaging layer.

Amendment of PC transaction

Reject/Recall of PC Transaction

Approval of Incoming collection

Reversal of PC transaction

Re-dispatch of Outgoing collection

PC periodic instruction setup transaction
Processing Retail Teller Transactions
The retail teller transactions are processed with the tanked status as ‘Yes’ if the branch is not
available for transaction. During the RT transaction query, the transaction can be viewed as
tanked, if the RT transaction is tanked and that the request was processed when the branch
available status is No or when branch date was ahead of host date.
The process when the RT transaction is received when the branch is unavailable or when
branch date is ahead of host date is as follows:

The RT transaction would be accepted with transaction status as Tanked.

The accounting entries would be posted with tanked status.

Message and advices of an RT transaction are suppressed.
After the branch available status is changed to ‘Yes’ then

The transaction status of the RT transaction will be changed to Active.

The tanked accounting entries if any would be un-tanked by the batch process for
releasing the tanked accounting entries.

The messages and the advices associated with the RT transaction that were
suppressed are also generated.

The transaction date of the RT transaction will remain unchanged during the process of
un-tanking.
Processing Clearing Transactions
The clearing transactions are processed with the tanked status as ‘Yes’ if the branch is not
available for transaction. During the clearing transaction query, the transaction can be viewed
as tanked, if the CG transaction is tanked and that the request was processed when the
branch available status is No or when branch date was ahead of host date.
The process when the clearing transaction is received when the branch is unavailable or
when branch date is ahead of host date is as follows:

The Clearing transaction would be accepted with transaction status as Tanked.

The accounting entries would be posted with tanked status.
After the branch available status is changed to ‘Yes’ then:

The transaction status of the Clearing transaction will be changed to Active.
28-5

The tanked accounting entries if any would be un-tanked by the batch process for
releasing the tanked accounting entries.
Processing Instrument Transactions
The instrument transactions are processed with the tanked status as ‘Yes’ if the branch is not
available for transaction. During the DD transaction query, the transaction can be viewed as
tanked, if the DD transaction is tanked and that the request was processed when the branch
available status is No or when branch date was ahead of host date.
The process when the instrument transaction is received when the branch is unavailable or
when branch date is ahead of host date is as follows:

The instrument transaction would be accepted with transaction status as Tanked.

The accounting entries would be posted with tanked status.
After the branch available status is changed to ‘Yes’ then:

The transaction status of the Instrument transaction will be changed to Active.

The tanked accounting entries if any would be un-tanked by the batch process for
releasing the tanked accounting entries.
Processing Standing Instructions
The standing instructions are processed with the tanked status as ‘Yes’ if the branch is not
available for transaction. During the standing instruction query, the instruction can be viewed
as tanked, if it is tanked and that the request processed when the branch available status is
‘No’ or when branch date was ahead of host date.
When the instruction is received while the branch is unavailable, then the process is as
follows:

The instruction is accepted with transaction status as ‘Tanked’.

Accounting entries are posted with the status ‘Tanked’.
Once the branch status is ‘Available’, then the following process is applicable:

The transaction status of the instruction is changed to ‘Un-tanked’

A batch process releases the tanked accounting entries

For all instructions whose booking date is the same as the Application date, the ‘Date
Change BOD Batch’ of that date updates the status to ‘Un-tanked’.

The transaction date of the instruction remains the same after un-tanking.
Processing Utility Payment Transactions
The utility payment transactions are processed with the tanked status as ‘Yes’ if the branch is
not available for transaction. During the UP transaction Query, the transaction can be viewed
as tanked, if the UP transaction is tanked and that the request was processed when the
branch available status is No or when branch date was ahead of host date.
The process when the utility transaction is received when the branch is unavailable or when
branch date is ahead of host date is as follows:

The UP transaction would be accepted with transaction status as Tanked.

The accounting entries would be posted with tanked status.
After the branch available status is changed to ‘Yes’ then:

The transaction status of the UP transaction will be changed to Active.

The tanked accounting entries if any would be un-tanked by the batch process for
releasing the tanked accounting entries.
28-6
The different categories which get processed during the End of the Day batch run are
explained in the table below:
Maintenance/
Transactions
Branch Status – Not
Available
Branch Status –
Available (After date
change)
Customer/Account
Creation
The process is tanked till
the branch available status is yes.
TD account status is
changed from tanked to
un-tanked.
Initiation accounting
entries will be posted as
tanked entries.
Initiation accounting
entries are un-tanked and
released with transaction
date moved to next working date.
TD Account
Redemption
Processed partially
Transaction status is untanked and accounting
entries if any would be
un-tanked
Account Closure
Not Allowed
Processed normally
Funds Transfer
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
Payments and Collection
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
Retail Teller Transactions
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
Clearing Transactions
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
Instrument Transactions
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
Utility Payment
Transactions
Transaction/Accounting
entries would be posted
with tanked status.
Transaction/Accounting
entries are un-tanked and
processed.
28.2 Supporting 24x7 Transactions
Oracle FLEXCUBE provides round the clock support for the following banking transactions.
28-7
28.2.1
24x7 Transactions through Channel
Below mentioned transactions will be supported 24x7 through Channels.
Sr.
no
Transaction Name
Function
IDs
1
Misc Debit
1008
2
Misc Credit
1408
3
Funds Transfer (A2A)
1006
4
TD Account Opening
STDCUSTD
5
TD Redemption
ICDREDMN
6
Zengin Funds Transfer
NA
7
Fee Collection (as part of Zengin)
NA
8
ATM Transactions
NA
9
POS Transactions
NA
10
Account Transfer By GL
1005
11
Zengin Funds transfer limit inquiry
NA
12
HL rate cycle rate change query
CLSACCVM
13
HL smart pay query
CLSACCNT
14
JGB DCD Account Opening
STDCUSTD
15
Multimoney TD Opening
STDCUSTD
16
NK225 TD Opening
STDCUSTD
17
Otemashi Gaika TD Opening
STDCUSTD
18
Power Builder TD Opening
STDCUSTD
19
Power chance TD Opening
STDCUSTD
20
Power setup gaika TD opening (USD)
STDCUSTD
21
Power setup TD Opening
STDCUSTD
22
Power Teiki plus TD Opening
STDCUSTD
23
Power Yokin Limit query and update
STDCUSAC
24
Power TD neo Opening
STDCUSTD
25
Triple currency TD Opening
STDCUSTD
26
Zengin Transfer
NA
27
Zengin Cancellation
NA
28
Zengin free transaction query
NA
28-8
28.2.2
Sr.
no
Transaction Name
Function
IDs
29
Zengin query
NA
30
Zengin Payee Maintenance
NA
31
Customer Channel wise Limit Maintenance
NA
24x7 Transactions through Branch or Call Centre
Below mentioned transactions will be supported 24x7 through branch or call centres.
Sr.
no
Transaction Name
Function
IDs
1
MISC Debit
1008
2
MISC Credit
1408
3
Fund Transfer
1006
4
Customer ATM Limit Maintenance
STDCUSAC
5
Cross Currency Rate Maintenance
CYDRATEE
6
Zengin Registration
NA
7
Customer Account Creation
STDCIF
8
Account Collateral Management
STDCUSAC
9
Limit Master Maintenance
GEDFACLT
10
Hold Funds
CADAMBLK
11
Customer Relationship
STDRETVW/
STDCUSAC
12
Customer Master Maintenance
STDCIF/
STSCIF
13
Customer Memo Maintenance
CSDINSTR
14
Standing Instruction
SIDTRONL
15
Account Schedule Generation
CLDACCVM/
CLDACCNT
16
Collateral Input
GEDCOLLT
17
Loan Account Creation
CLDACCNT
18
Loan Account Payment
CLDPYMNT
19
Deposit Detail Maintenance
STDCUSTD
20
Term Deposit Maturity Standing Instruction
STDCUSTD
28-9
Sr.
no
Transaction Name
Function
IDs
21
Collateral Pool Input
GEDMPOOL
22
Account Status audit trail inquiry
STSSTCHN/
STDSTCHN
23
Statement Enquiry
ACDABLQY
24
GL transactions/ Movements inquiry
GLDVWBAL/
ACDOPTN
25
Future dated Disbursement Inquiry
CLDMNDSB
26
Term Deposit Audit Trail Enquiry
ACDAUDTR
27
Deposit Renewal History Enquiry
STDCUSTD
28
Account Ledger Enquiry
ACDTRNQY/
ACDABLQY
29
Term deposit Interest Payout Enquiry
ACDTRNQY
30
Customer Account J-Debit Limit Maintenance
SWDCDMNT
31
Card Request
STDCRDMS
32
AOD Lien Maintenance
LMDCUSLT
33
AOD Lien for TD Maintenance
STDCUSAC
34
Customer Company Cross Reference
NA
35
User Maintenance
SMDUSRDF,
SMDUSHOL, SMDBANKP
36
Blocking/Unblocking Accounts Maintenance
STDBSTCH
37
FX Parameters Maintenance
CYDCYTHR,
CYDCCYPO
38
Plus Card Maintenance
STDCRDMS
28-10
Sr.
no
Transaction Name
Function
IDs
39
Account Master Maintenance
STDCUSAC,
STDCIF,
MSDCACAD,
ICDUDVAL,
STDACCLS,
ACDASTQY,
STDACSTA,
CADCHBOO,
STDTXWAV
40
Account Status Maintenance
STDSTCHN
41
AOD Customer Maintenance
STDCUSAC
42
Inquiry on Logged in Users
CLRU
43
Deposit Account Details
STDCUSTD,
ICDPRMNT,
ACDABLQY,
ICDREDMN,
STSAMBLK
44
TD Account Ledger Inquiry
ACDTRNQY,
ACDABLQY
45
Interest Payment History Inquiry
ACDAUDTR
46
Account FT Limits
STDCTLMT,
ISDITLMT
47
Account Additional Data
CLDACCNT
48
TD Product Rates Maintenance
CFDFLTRI,
ICDUDVAL,
STDACCL
S
49
TD Interest Adjustments
DEDMJONL
50
TD Audit Trail Maintenance
ACDAUDTR
51
Block/Unblock Account Status
STDSTCHN
52
Maruyu Inquiry
STDCIF,
STDCUSTD,
STDRETVW
28-11
Sr.
no
Transaction Name
Function
IDs
53
TCD Account Details Inquiry
STDCUSTD
54
DCD Account Details Inquiry
STDCUSTD
55
Deposit Account Booking
STDCUSTD,
RDDSCHEQ
56
Currency Position Cover Maintenance
CYDCYTHR
57
Account activation
STDMLACT,
STDMLACL
58
Furikomi
NA
59
Furikomi Predefined
NA
60
Zengin Inquiry
NA
61
Zengin Platinum Cust Inquiry
NA
62
Message Details Inquiry
STDEMDIN
63
E-Statement Registration Inquire
STDEMFLG
64
E-Statement Inquire
STDEMFLG
65
Alert Inquiry
STDEMDIN
66
Power Yokin Debit Transaction – Customer Parameters Maintenance
NA
67
Customer Email Registration
STDEMFLG
68
Customer Email ID Block
STDEMBLK
69
TD Renewal History
STDCUSTD
70
Customer Channel wise Limit Maintenance
STDCTLMT
71
Maruyu Details Maintenance
STDCIF
72
TD Currency Transfer
STDACCH,
STDCIF,
STDCUSTD
73
ILD Account Details Inquiry
STDCUSTD
74
Journal Operations Batch Browser
DEDBTTOT/
DEDBTHAU
Note
To have 24x7 support, Tanking Required field should be checked in the Function Description Maintenance screen (SMDFNDSC)
28-12
28.2.3
EOD handling
EOD will have below mentioned process through archival and purging routines of web branch
,Pre cut-off and cut-off:

WBPRGEOD- Separate routine for archival and purging of web Branch transactions can
be run during any time of the day. This process will archive all previous day’s
transaction, This is an intra day batch.

AEDCUOFF- This is an intra day batch.
Note
–
Opening and closing of Till and Vault will be done operationally.
–
Mark the time level to 9 for all the branches. This will enable ONLY users with time
level 9 or more to log into Oracle FLEXCUBE. Call centre users should be
maintained with Time Level as 9.
–
When the cut-off process is successfully completed then tanking process will start.
All branch and non-branch transactions will tanked with Transaction date and Value
date as next working date.
Once the cut-off process is completed, Oracle FLEXCUBE will start EOD cycle.
The AEDUCOFF has to be operationally controlled to run before the start of the MarkEOTI
batches.
During End of Day process the system displays the message, “EOD batch Process in
progress” in the transaction screens alone.
BASIDMTR will be used to monitor the status of intraday batches.
Drop End Of Transaction input will not be allowed once the Cutoff batch and MARKEOTI
batch process is run.
Scheduling of Batch Operations
During the scheduling of branch operations following configuration will be followed:
1. POSTEOD3 stage will not be configured with any Batch processing.But Head office
branch alone can be configured with AEDDATCH (Date Change batch) in POSTEOD3
stage
2. All the branches including Head office branch has to feature in a single End of day group.
3. EOD process for the 24/7 functionality has to be processed with the parallel thread mode.
4. If EOC process is executed manually, then the EOC operator should ensure that the
PEOD2 for all the normal branches is completed successfully before initiating the PEOD3
of Head office branch, since Date change batch is configured in PEOD3 stage of Head
office branch EOC program.
Channel transactions during cutoff:
If any transaction happens through channel then the channel will send the required value
dates/account opening dates through channel.
TD opening through Channel:
28-13
The channel will first send a request to find out the current host date. If the branch availability
is ‘N’, then the API will respond with next application working date. The channel will then send
the booking date for TD account opening.
CASA opening through Channel:
The channel will first send a request to find out the current host date. If the branch availability
is ‘N’, then the API will respond with next application working date. The channel will then send
the interest start date.
For host transaction, the user is expected to manually input the booking date and interest start
date.
Below mentioned table summarizes the step by step execution of EOD process
Process
Description
Sub Process
Head office
Process
AECUTOFF
Clearing of user/
Force Log-off all the users
Y
deletion of
pending transaction
Delete if any pending transactions are there in web
branch.
Note: FC Host transactions
has to be operationally controlled
Check Host pending transaction. If Pending transaction is
there then the same has to
be operationally controlled
either by deleting or authorizing the pending transactions.
Else AECUTOFF will abort
with error message.
Branch EODM processChange Branch Date to next
date
MarkEOTI (check to be
removed for pending transactions and users). Enable
MARKEOTI from initial end of
input status of ‘C’
N
Mark EOTI
Mark EOTI
(Running successfully across
all branches.
Post EOTI
batches
Post EOTI
batches
N
MarkEOFI
MarkEOFI
N
MarkEOD
MarkEOD
N
AEDDATCH
Date Change
Update all the branch availability status to ‘y’
Change the date across all
branches
28-14
Y
28.2.4
Head office
Process
Process
Description
Sub Process
Mark BOD
Mark BOD
Remove date change process from the BOD
Post BOD
batches
Post BOD
batches
N
Mark TI
Mark TI
N
WBPRGEOD
Web Branch
Archival and
purging
Web Branch Archival and
Purging (intra Day batch)
N
N
Call Centre Handling
Call centre will be set up as a virtual branch in FCUBS. Call centre users will log-in to a virtual
branch designated for them. Call centre users can do transactions on behalf of other branch
based on the branch that the customer belongs to.
28-15
29. Tanking of Maintenance Records
29.1 Introduction
The maintenance records that are created or modified in the system can be tanked till they
get authorized, so that it is possible to undo the modifications, if needed, before the records
are authorized. The maintenance log also will store the changes till they get authorized. The
new or the modified records are written to the static tables only after authorization.
29.2 Tanking New and Modified Maintenance Records
You can enable tanking of the creation and modification of maintenance records by selecting
the ‘Tanking Required’ option provided at the function Id level. You need to enable the
‘Tanking Required’ option in RAD tool as well.
You can enable ‘Tanking Required’ option for individual function Ids in ‘Function Description
Maintenance’ screen. You can invoke this screen by typing ‘SMDFNDSC’ in the field at the
top right corner of the Application tool bar and clicking on the adjoining arrow button.
To enable tanking of maintenance records for a function Id you need to select the function Id
in this screen and then select the ‘Tanking Required’ checkbox.
For more details on this screen, refer Security Management System user manual.
Note
Tanking of records has been enabled only for the following function Ids:
–
STDCIF
–
STDCUSAC
29-1
29.2.1
Tanking New Records
During the creation of a new record, if ‘Tanking Required’ option is enabled, the system tanks
the details of the newly created record till the record gets authorized. Any query on this data
retrieves this stored information.
29.2.2
Tanking Modified Records
All modifications to unauthorized records get tanked and the modified data gets written to
actual tables only after authorization. In this case, the record remains in ‘Authorized’ status in
the actual table and the unauthorized modifications will be kept pending for un-tanking. The
most recent modifications will be shown in both summary and detailed screens with the
Authorization status as ‘Unauthorized’.
29.2.3
Closing a Record
You can close a record only if it is in ‘Authorized’ state, without any unauthorized modifications
pending for un-tanking. Closure is possible only for records that are in ‘Open’ status. When
you close a record, the system tanks this and the record gets actually closed only after the
closure gets authorized.
29.2.4
Re-opening a Record
You can re-open a record only if it has been closed and the closure is authorized. Re-opening
of a record gets tanked till it gets authorized and the actual re-opening happens after the
authorization.
29.2.5
Authorizing a Record
All unauthorized modifications get displayed when you click ‘Authorize’ menu option. You can
select a modification number and the records get authorized till that modification. These
records are un-tanked and their status gets updated as ‘Authorized’. You can authorize the
modifications partially, if required.
29.2.6
Deleting a Record
All unauthorized records will be available for deletion. You can select a modification number
and system deletes all unauthorized modifications from the selected modification number. If
the modifications getting deleted are made by a user other than the current user, the system
displays an error message.
29.2.7
Viewing Summary of Records
All summary screens display data retrieved from both the summary data source and the table
that contains the unauthorized tanked records.
29.2.8
Modifying Tanking Preferences
You can modify the tanking preferences specified for a function Id, if required. This
modification is possible only if all records related to that function Id are in ‘Authorized’ status.
29-2
30. External Deal Maintenance
30.1 Introduction
You can capture the details of a deal booked in an external system using ‘External Deal’
maintenance screen. You can invoke this screen by typing ‘STDEXLIN’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
You can specify the following details in this screen:
FLEXCUBE Reference Number
This reference number is automatically generated by the system.
Account Number
Select the account number associated with the external deal from the option list which
displays all valid account numbers in the system.
External Deal Reference Number
Specify a unique identification number for the external deal.
Deal Currency
Specify the currency in which the external deal was carried out or select the deal currency
from the option list provided.
Account Currency
The account currency gets defaulted once you select the account number.
Deal Amount
Specify the amount associated with the external deal in terms of deal currency.
Equivalent Amount
The deal amount in terms of the account currency gets displayed here.
30-1
Equivalent Amount = Deal Amount * Exchange Rate
Exchange Rate
Specify the exchange rate to convert the deal currency in terms of the account currency.
Remarks
Specify any remarks associated with the external deal, if required.
Deal Booking Date
Specify the booking date of the external deal or select the deal booking date by clicking the
‘Calendar’ icon.
Deal Expiry Date
Specify the expiry date of the external deal or select the deal expiry date by clicking the
‘Calendar’ icon.
After specifying the above details you can save the record. An amount block equivalent to the
deal amount is automatically created once these details are authorized.
Note
You can not modify a record in this screen, after it has been authorized.
For more details related to amount block maintenance, refer the chapter ‘Maintaining Amount
Blocks’ in Current and Savings Account User Manual.
30-2
31. Annexure B - File Formats
31.1 Introduction
As mentioned earlier, SWIFT provides a country-wise holiday list that can be uploaded into
Oracle FLEXCUE using the ‘CCH’ source code. This file consists of the ‘HF’ and ‘HS’ records.
HF and HS are the tag identifiers through which the currency code can be obtained.
31.2 Upload File Formats
HF – Non-European countries
As mentioned before, the HF record comprises the holiday details for countries where ‘EUR’
is not the local currency. The currency code is obtained from the country code present in this
record. The holiday record is then uploaded into the Oracle FLEXCUBE holiday upload table.
The HF record has the following format:
Positi
on
Description
Length
Type
Manda
tory
Data
1
Tag Identifier
2
VARCHAR2
Y
‘HF’
3
Modification
Flag
1
VARCHAR2
Y
‘A’ addition
‘M’ modification
‘D’ deletion
‘U’ unchanged
4
Country
Code
2
VARCHAR2
Y
ISO Country
Code
6
Country
Name
35
VARCHAR2
Y
Country Name
(first part)
41
Country
Name
35
VARCHAR2
N
Country Name
(second part)
76
Date
8
VARCHAR2
Y
Date of a Holiday
84
Holiday type
1
VARCHAR2
Y
Code indicating
type of Holiday
(see below)
31-1
85
Special holiday info.
320
VARCHAR2
N
Restrictions
applicable if a
holiday is not
applicable
country-wide,
or is not a full
day
HS – For European countries
The HS record comprises the Target holiday details for countries where ‘EUR’ is the local
currency. The holiday record is uploaded into the Oracle FLEXCUBE holiday upload table.
The HS record has the following format:
Posi
tion
Description
Length
Type
Mand
atory
Data
1
Tag Identifier
2
VARCHAR2
Y
‘HS’
3
Modification
Flag
1
VARCHAR2
Y
‘A’ addition
‘M’ modification
‘D’ deletion
‘U’ unchanged
4
Service Code
3
VARCHAR2
Y
Value Added
Service Code
7
Date
8
VARCHAR2
Y
Date of a Holiday
15
Holiday type
1
VARCHAR2
Y
Code indicating
type of holiday(see below)
16
Special holiday info
320
VARCHAR2
N
Restrictions
applicable if a
holiday is not
applicable country-wide, or is not
a full day
31-2
32. Anti-Money Laundering Reporting
32.1 Guarding Against Money Laundering
In Oracle FLEXCUBE you can guard against Money Laundering by using the anti-money
laundering option wherein you will be required to maintain certain basic information as a
safeguard against Money Laundering activities that customers may indulge in.
The information that you need to maintain includes the maintenance of:
32.1.1

Product Categories

Limit Codes

Customer Groups
Creating Product Categories in Oracle FLEXCUBE
You have to create product categories in Oracle FLEXCUBE, for the purpose of grouping
common transactions. A product is a specific service that you offer your customers. Each
transaction that you process in Oracle FLEXCUBE should be linked to a product. By
maintaining amount limits at the product level, each time you link a transaction with a product
the system verifies the amount limit maintained for the product. If the transaction amount
exceeds the amount maintained at the product level the system intimates you with an
override.
32-1
You can invoke the ‘AML Product Categories Maintenance’ screen by typing ‘CSDAMLPC’ in
the field at the top right corner of the Application tool bar and clicking the adjoining arrow
button.
Product Category
You should identify each product category with an identification code by giving it a unique
name.
Description
With each product category you have to associate a brief description. This description is
meant for information purposes and will not be used for any processing.
Limit Currency
You have to identify the currency in which limits have to be tracked for transactions associated
with the product category.
A list of all the currencies maintained in Oracle FLEXCUBE is available in the option list
positioned next to this field. You can select the appropriate.
Product Type
Transactions grouped under a product can either be cash based or non-cash based.
Therefore, you would have created products catering to cash based and non-cash based
transactions.
While creating a product category, you have to indicate whether the products grouped under
the respective category cater to cash based or non-cash based transactions. You can select
the appropriate option.
32-2
Exchange Rate Code and Rate Type
The rate associated with this rate code will be used to derive the exchange rate when the
currency of the transaction is different from the limit currency of the product category.
Similarly, you have to select the Rate Type that is to be associated with the rate code. The
options available are as follows:

Mid

Buy

Sell
The rate code along with the rate type will determine the exchange rate that is to be used.
Debit/Credit Indicator
As part of Anti-Money Laundering you can indicate the manner in which the system should
track the Debit and Credit turnover limits for any of the limit types, for the product category.
The options available are:

Both (Aggregate Together) – absolute values of debits and credits will be aggregated
together

Both (Aggregate Separately) – debits and credits will be aggregated separately

Debits alone or Credits alone
Limit Code and Limit Amount
At the product category level, you can specify the limit amount that should be associated with
each limit code for a limit type.
A list of all the limit codes maintained for the specific limit type (Online, Individual, Daily
turnover Batch, Daily turnover Online and Monthly turnover), in the Limit Codes Maintenance
screen, will be displayed in the option list positioned next to this field. You can select the
appropriate limit code and specify the limit amount that is to be linked with the code.
Note
For a particular product category you can choose to maintain Limit Code and Amount combinations for all of any of the five Limit types. They are:
–
The Online transaction limit
–
Individual limits
–
Daily turnover limits
–
Monthly turnover limits
–
Online daily turnover limits
The transaction limits that you specify will be tracked online on a daily basis, whenever you
process a transaction involving the product category. However, individual, daily and
monthly turnover limits will be tracked only when the after the End of Day processes have
been run successfully.
32.2 Maintaining Limit Codes
Before you begin the maintenance of product category records, you should necessarily
maintain limit codes through the Limit Code Maintenance screen. While linking a limit amount
with a limit code in the product category screen, only valid limit codes that you have
maintained through this screen will be made available for mapping.
32-3
You can invoke this screen by typing ‘CSDAMLLM’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Limit Code
You can maintain limit codes for the various types of limit types like online tracking limits,
individual tracking limits, daily turnover limits and monthly turnover limits.
You have to specify a unique name to identify each Limit Code that you would like to define.
Subsequently, you can assign a brief description with each limit code that you define.
Limit Type
Since you can maintain separate limit codes for each limit type, you have to associate a limit
code with each limit type. The options available are:

Online Limit – tracks the limits of all online transaction that exceed limits

Individual Transaction – during the batch processed executed at EOD the limit
maintained for this type is used to tack all individual transactions that exceed the limit

Online Daily Turnover –all transactions processed during the day are considered for an
online tracking and an online reporting is done when the specified limit exceeds

Monthly Turnover – all transactions processed during the month that have exceeded the
specified limit will be reported

Daily Turnover – during the batch processes executed at EOD all transactions for the
business day that have exceed the limit will be reported
You can select the appropriate type from the list.
32.3 Maintaining Anti Money Laundering Customer Groups
Since you need to define transaction online, individual, daily and monthly limits for each
customer, each product category that you maintain should be linked with a customer. To
facilitate this linking, you are required to maintain AML Customer Groups. You have to link
one of the limit codes of the respective type attached to the product category to the customer
group
32-4
You can define product categories applicable to customer groups through the ‘AML Customer
Group Maintenance’ screen. You can invoke this screen by typing ‘CSDAMLCG’ in the field
at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Customer Group
This is the AML group to which the particular customer belongs. You can select from the
available option list and identify the AML group to which the customer belongs.
Note
In the CIF maintenance screen when you capture the customer code of a customer, the
same will be defaulted in the AML Customer Group field since the system recognizes each
customer code as a customer group. You can either choose to categorize the customer
under the same group or choose another customer group.
You can capture a brief description that should be associated with every AML group
Next Review Date
While maintaining customer group and product category records you can specify the next
date on which you would like to review the limits maintained for the various limit types.
Tracking
You have to specify whether the AML tracking is required for a customer or for all customers
within a group. The system performs a group level tracking if you select Customer group.
Conversely if you select Customer, the AML reporting, online tracking and data collection is
done only at the customer level.
Note
If you fail to indicate your preference specifically the system will perform a customer group
level tracking by default
32-5
Risk Profile
You can identify the risk profile of the customer group by selecting any one of the following
options:

High – indicating that the limits for the customer group need to be tracked regardless of
the amount involved since the customer group is meant for high-risk customers.

Low – indicating that the customer group is meant for low risk customers therefore
amount limits need not be tracked if the amount involved falls within the limit amount.
You can select the required specification.
32.3.0.1 Linking Product Category with Customer Group
You have the option of selecting and linking as many limit codes as required for each limit type
from the product categories maintained in the system. After you select the product category
that is to be linked to the customer group, you have to identify the limit code associated with
the limit type and in turn link it with the customer group.
Given below is a sample of the Customer Group maintenance record:
The Main details of the record are as follows:
Customer Group
AMLCUS01
Description
AMLCUSTOMER GROUP 1
Next Review Date
10-FEB-2003
Risk Profile
High
The Product Category linkage details are as follows:
Product
Category
Descriptio
n
Online
Limit
Code
Individual
Limit
Code
Daily
Limit
Code
Monthly
Limit
Code
Online
Daily
Turnover
PDT01
Product 1
LIM31
LIM01
LIM11
LIM21
LIM41
PDT02
Product 2
LIM36
LIM06
LIM16
LIM26
LIM46
Note
–
Consequently, while processing transactions for all customers linked to the
Customer Group AMLCUS01, the system does an online verification of transaction
limits based on the amount limits maintained for the limit code LIM31 (linked to the
product category PDT01) and LIM36 (linked to the product category PDT02)
respectively.
–
It is mandatory for you to maintain a generic Customer Group called ALL for the customers of your bank. When product categories have not been linked to a specific
customer or a customer group, the system picks up the limits maintained at the generic level for AML tracking purposes. Also, any new product category created and
associated to the transaction code should be mandatorily associated with the ALL
group.
32-6
32.4 Monitoring AML Accounting
For AML reporting purposes, while maintaining a transaction code you need to indicate
whether AML monitoring is required for all accounting entries linked to the transaction code.
You can invoke this screen by typing ‘STDTRNCD’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
The screen is as shown below:
If you indicate that AML tracking is required for transactions linked to the transaction code you
have to identify the product category with which the transaction code is to be linked.
Consequently, the system does a check for every accounting entry passed during online
processing. The system checks the transaction amount of the entry with the transaction online
limit maintained for the specific customer group (of the customer to whose account the entry
has been posted) and the product category (for the transaction code of the entry). If the
system finds that the limit amount has been exceed an override message informing you of the
same will be displayed.
During the End of Day (EOD) processing, the system identifies all accounting entries posted
during the day, which have been marked for AML monitoring, and verifies the individual
amount limit for the customer group and product category combination and stores this data in
the system. You will be able to view this data when you generate an AML report using
Business Objects.
32-7
As part of the EOD processes the system also updates the daily turnover limits for the
particular customer group and product category combination. Monthly turnovers are updated
for the Customer Number, Product Category and Currency combination.
32-8
33. Developer and Developer Project Maintenance
33.1 Introduction
In Oracle FLEXCUBE, you can maintain details of the real-estate developer and developer
projects. You can link the developers to loan accounts.
33.2 Maintaining Developer Details
You can maintain contact and project details of the developer in the ‘Developer Maintenance’
screen. You can invoke this screen by typing ‘CSDDEVDT’ in the field at the top right corner
of the Application tool bar and clicking the adjoining arrow button.
Here, you can specify the following details:
Developer Code
Specify the unique code of the developer.
Address
Specify the address of the developer.
Zip
Specify the ZIP code of the developer.
Country
Specify the code of the country to which the developer belongs. The adjoining option list
displays all valid country codes maintained in the system. You can choose the appropriate
one.
Country Name
The system displays the corresponding country name based on the specified code of the
country.
33-1
Developer Name
Specify the name of the developer.
Telephone
Specify the telephone number of the developer.
Email ID
Specify the Email ID of the developer.
Fax
Specify the fax number that should be linked with the specified developer.
Mobile
Specify the mobile number of the developer.
Website
Specify the URL of the website linked to the developer.
33.2.1
Viewing Project Details
You can view the details of the projects linked to the developer by clicking ‘Project’ button in
the ‘Developer Maintenance’ screen.
Here you can view the project names and descriptions that are linked to the specified
developer.
33-2
33.2.2
Viewing UDF Details
You can view the UDF details by clicking ‘Fields’ button in the ‘Developer Maintenance’
screen.
Here you can view the field names and its value.
33.3 Viewing Developer Maintenance Summary
You can view the summary of developer maintenance in the ‘Developer Maintenance
Summary’ screen. You can invoke this screen by typing ‘CSSDEVDT’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen, you can query based on any combination of the following fields:

Authorization Status

Developer Code

Record Status
After specifying the parameters for the query, click ‘Search’ button. The system displays all
the records matching the parameters specified. You can view the following details:

Authorization Status
33-3

Record Status

Developer Code

Website

Address

Developer Name

Country

Email ID

Zip
33.4 Maintaining Developer Project Details
You can maintain the details of real estate development projects in the ‘Developer Project
Maintenance’ screen. You can invoke this screen by typing ‘CSDDEVPR’ in the field at the
top right corner of the Application tool bar and clicking the adjoining arrow button.
Here you can specify the following details:
Project Name
Specify the name of the project.
Project Description
Specify a brief description about the project.
Address
Specify the address of the project location.
Status
Specify the status of the project.
33-4
Developer Code
Specify the unique code of the developer. The adjoining option list displays all valid codes
maintained in the system. You can choose the appropriate one.
Unit Details
Specify the following details.
Unit ID
Specify the unit ID of the developer project.
Unit Holder Name
Specify the name of the unit holder of the developer project.
33.4.1
Viewing UDF Details
You can view the UDF details by clicking ‘Fields’ button in the ‘Developer Project
Maintenance’ screen.
Here you can specify values for the UDF.
33-5
33.5 Viewing Developer Project Maintenance Summary
You can view the summary of developer project maintenance in the ‘Developer Project
Maintenance Summary’ screen. You can invoke this screen by typing ‘CSSDEVPR’ in the
field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen, you can query based on any combination of the following fields:

Authorization Status

Developer Code

Record Status

Project Name
After specifying the parameters for the query, click ‘Search’ button. The system displays all
the records matching the parameters specified. You can view the following details:

Authorization Status

Record Status

Developer Code

Project Name

Project Description

Address

Status
33-6
34. Project Financing
34.1 Introduction
Project financing is the financing of long-term infrastructure and industrial projects involving a
number of equity investors and a group of banks.
Project financing is a credit facility sanctioned to the contractors who execute large
infrastructure projects, residential complexes, commercial complexes, etc. These contractors
are awarded the contracts (projects) based on a BID system. Once the project is awarded to
a contractor, he approaches the bank seeking for finance.
The contractor can avail financing from the bank against PPC (Project Progress Certificate/
Project Payment Certificate) or Invoice or TD or a clean line. PPCs are one type of backing
against which OD is provided. The contractor can be a single entity or a joint venture (JV). In
case of a joint venture, the share of the overdraft for each contractor will depend on their share
in the joint venture.
34.2 Processing Finance for Project
The process of project financing is as follows:
34-1
1. A customer or a joint venture approaches the bank for project financing
2. The bank creates the customer in the system
3. If it is a joint venture, the bank creates the joint venture customer and enters the party/
customer details linked to the joint venture in the joint venture button screen.
4. The bank then creates the project account for the created customer/joint venture
customer.
5. The bank captures the following details in the ‘Project Maintenance’ screen:

Project header details

Sponsor/Pay-master details

Project milestone details
34-2

Joint Venture Parties Details (In case of Joint Venture Limit Tracking)

PPC Limits Details

Non-PPC Limits Details
6. Link the Non-PPC lines defined in project to the project account using Limits tab
7. The customer will utilize this clean limit line until he furnishes a PPC against part or full
completion of a milestone.
8. On receiving the PPC, the bank does the following:

Captures the PPC details

If it is a joint venture then the system will default the joint venture details to this screen
based on the details captured in the project maintenance venture details screen.

If ‘Auto Line Creation for PPC’ field is unchecked,

–
You should manually create the line whenever a PPC is received.
–
The line currency can be other than project currency also, but the PPC CCY should
be either project currency or line currency.
–
You should manually enter the limit line details in the project maintenance screen
limits tab, if the project lines are created manually and in the PPC maintenance
screen Joint Venture tab if PPC lines are created manually. If joint venture party
limits tracking is not required, then the system will attach one line for the project
customer with 100% tracking.
–
The system will also update the project ID and the PPC ID in the ‘Facility
Maintenance’ screen, once the linkage between a line and a PPC/ Project is
established manually during PPC maintenance
If ‘Auto Line Creation for PPC’ field is checked,
–
On authorizing the PPC, the system will create the limit lines for each of the PPC
for liability ID of the project customer
–
You should allocate the limit to the project line equal to the lendable value of the
respective PPC
–
You should allocate the limit to an individual customer limit lines based on the share
each has in the joint venture if ‘JV Limit Tracking Required’ is checked

On authorizing the PPC, the system will automatically create line commitment contracts
during the EOD. The rates used in the commitment are taken from project maintenance.

For each PPC authorized and if ‘Limits tracking through Commitment’ is checked, then
the system will create the following line commitment contracts:
–
Project line commitment contract, regardless of whether there is a joint venture or
not
–
Customer line commitment contract for each customer only in case of joint venture
9. The bank will view the details of a project and the status of its collaterals from a
Dashboard screen
10. You should manually mark the PPC as CLOSED, if the payment against it has been
received
11. You should manually close the project account, if the system receives the payment
towards all the PPC’s and all the PPC’s are marked as CLOSED
12. When multiple lines are available and system has to utilize the lines, the priority will be
determined based on the lowest interest rate + spread defined in the linkages screen.
13. Using the PPC liquidation screen, you can choose the payment of the loan or credit to the
project account. This transaction will be logged under the PPC.
34-3
14. PPC liquidation will be allowed even without the ‘Entry No.’, say, in case the contractor
did not receive money due to contractual terms elapse etc. The system will display an
override message when such an input is made.
15. Partial liquidation of PPC is allowed and they will be tracked. In case ‘Entry No’ is
provided, loan payment will be considered only to the extent of PRINCIPAL payment and
other component payments will not be considered.
16. Project closure activities include:
–
Liquidating PPCs
–
Marking PPCs as closed
–
All PPCs should be liquidated before they are closed
–
Closing all lines associated with the project
–
Manually created lines can be closed using the close button in the facility screen
–
Auto created lines (created by system) will be auto closed on the event of complete
repayment and complete PPC liquidation
–
Manually closing project account
–
All lines associated with the project account should be closed
–
All PPCs should be closed
–
Manually closing project
–
All lines associated with the project should be closed
–
Commitment contracts will be auto closed on commitment maturity date through CL
batch (Event: CLOC). Closure of commitment contracts before closure of project will
have to be operationally controlled.
34.3 Maintaining Project Financing Transaction
Oracle FLEXCUBE allows you to maintain the project finance transaction in a bank with the
details of the project undertaken with the contract. You can maintain these details using
‘Project Detail and Maintenance’ screen. To invoke this screen, type ‘STDPJMNT’ in the field
at the top right corner of the Application tool bar and clicking the adjoining arrow button.
34-4
The screen is as shown below:
34.3.1
Specifying the Project Details
Customer Number
Specify the customer number.
Project ID
Specify the project identification number.
Project Name
Specify the name of the project.
Project Account Branch
Specify the project account branch details.
Project Account
Specify the project account details.
Liability ID
Specify the liability ID.
Project Value
Specify the value of the project.
34-5
Remarks
Specify remarks, if any.
Ratio Change Allowed
Check this box if the joint venture ratio change is allowed during the course of the project.
This field is enabled only for new loans under the project financing.
JV Limit Tracking Required
Check this box if joint venture limit tracking is required.
Branch Code
The system displays the branch code.
Currency
Specify the currency details.
Number of PPCs
Specify the number of PPCs in the project.
Default PPC Clearance Days
Specify the default PPC duration for the payment.
Start Date
Specify the start date of the project.
End Date
Specify the end date of the project.
Sponsor Retention Margin (%)
Specify the retention margin for the sponsor while paying the PPC.
Bank Margin (%)
Specify the margin retained by the bank for the PPC..
Auto Line Creation for PPC
If you check this box, then the system will automatically create the credit lines while
authorizing the PPC. Else, you need to manually create the line and link them in the PPC
screen.
By default, this field will be checked.
Limit Track Required through Commitment
If you check this box, then the system will create the commitment contracts for every
automatic line creation.
34-6
34.3.2
Specifying the Main Details
You can specify the main details of the project such as sponsor details and consultant details
to validate the PPC and to recommend the sponsor for the payment.
34.3.2.1 Maintaining Sponsor Details
Sponsor ID
Specify the sponsor identification details of the project. If the sponsor is the customer of the
bank, then you can specify the CIF identification details.
Sponsor Name
Specify the name of the sponsor.
The system will display the sponsor name, if you had specified the CIF ID in the ‘Sponsor ID’
field.
Sponsor Address
Specify the address of the sponsor.
The system will display the sponsor address, if you had specified the CIF ID in the ‘Sponsor
ID’ field.
34-7
34.3.2.2 Maintaining Consultant Details
Consultant ID
Specify the consultant identification details of the project. If the sponsor is the customer of the
bank, then you can specify the CIF identification details.
Consultant Name
Specify the name of the consultant.
The system will display the consultant name, if you had specified the CIF ID in the ‘Consultant
ID’ field.
Consultant Address
Specify the address of the consultant.
The system will display the consultant address, if you had specified the CIF ID in the
‘Consultant ID’ field.
If the sponsor or consultant is not a customer of the bank, then the system will display only
the name and address of the sponsor or the consultant.
34.3.3
Specifying Milestones Details
You can specify the records of the various milestones in the project and percentage of
completion with respect to the project.
34-8
Milestone No
Specify the milestone number.
Description
Specify the description of the milestone.
Percentage Completion
Specify the percentage of completion with respect to the milestone.
Start Date
Specify the start date of the milestone.
End Date
Specify the end date of the milestone.
34.3.4
Specifying the Venture Details
You can maintain the details of the joint venture. You can also change the joint venture ratios
during the course of the project, but these ratios are effective only for future loans. Each loan
created for the project can store the ratios at the loan level which is defaulted based on the
application ratio at the time of loan creation. All limits tracking for joint venture parties will be
based on this ratio.
The system will create the limit lines for each of the project venture parties when joint venture
limit tracking is required at the project level. The line ID maintained at the limits is used to
create the limits automatically. Each time the PPC is created, the system will create a new
limit line using the same line for each of the liability of each joint venture. Different joint venture
parties will have the same commitment product which can have different interest rate.
34-9
The screen is as shown below:
Effective Date
Specify the effective date of the joint venture. For each effective date, the system maintains
the ratio among the joint venture partners. The sum of ratios for each effective date must be
equal to 100.
Party ID
The system displays the joint venture details of the project.
Party Name
The system will display the party name.
Liability ID
Specify the liability ID.
34-10
Ratio
Specify the percentage share of the joint venture party. The sum of all the ratios must be equal
to 100.
Default Interest Rate
Specify the default interest rate that is used for the external component in the commitment
product. The system will default this value to PPC.
Margin
Specify the margin applicable on the interest rate.
34.3.5
Specifying PPC Limits Details
You can create the clean limit (ToD) manually using the line ID for the amount. You should
then link this limit to the project account. The system creates the joint venture lines on
authorization of the PPC maintenance with joint venture tracking required.
In case of manual line creation, the system will create the lines in project currency. Whenever
there is a cross currency, the system will use a standard mid rate to convert from limit currency
to project currency to track utilization. The LCY difference that may arise due to exchange rate
differences will be handled by the ELCM CCY revaluation EOD batch.
You can view the limits detail such as line ID to create the project limits. There are two types,
namely, PPC Limits and Non PPC Limits.
The screenshot for PPC Limits is as follows:
34-11
Limit Type
Specify the type of limit.
Limit Description
The system displays the limit description.
Credit Line
Specify the credit line.
Serial No
The system displays the serial number for the limit created.
Commitment Product
Specify the commitment product details used when the respective limit line is created.
Rate
Specify the rate.
Margin
Specify the margin.
34-12
34.3.6
Specifying Non PPC Limits Details
The screenshot for Non PPC Limits is as follows:
34.3.6.1 Maintaining Joint Venture Line Details
Limit Type
Specify the type of limit.
Limit Description
The system displays the limit description.
Customer No
Specify the customer number.
Liability No
Specify the liability number.
34-13
Line Code
Specify the line code.
Line Serial
The system displays the serial number for the limit created.
Currency
The system displays the line currency details.
Rate
Specify the rate.
Margin
Specify the margin.
JV Line
This box will be checked by default.
34.3.6.2 Maintaining Party Line Details
Customer No
Specify the customer number.
Liability No
Specify the liability number.
Line Code
Specify the line code.
Line Serial
The system displays the serial number for the limit created.
Currency
The system displays the line currency details.
34.4 Maintaining PPC
Oracle FLEXCUBE allows the executor to maintain the PPC during the course of the project,
i.e. during the course of the project, once the executor completes the milestone should inform
the sponsor. The sponsor in turn, will inspect and confirms the completion of the milestone.
The executor is then allowed to raise the PPC with start date and the expiry date. The system
calculates the expiry date based on the default PPC clearance days. However, the sponsor
can change the expiry date. The system will accept the PPC in any currency. If there is a cross
currency, then the system uses a standard mid rate for converting from limit currency to
project currency.
34-14
You can maintain the PPC using ‘PPC Maintenance’ screen. To invoke this screen, type
‘STDPPCMN’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
34.4.1
Specifying PPC Maintenance Details
Project ID
Specify the project ID.
PPC ID
The system displays the PPC ID.
PPC Description
Specify the description of the PPC.
Start Date
Specify the PPC start date.
End Date
Specify the PPC end date.
Milestone No
Specify the milestone sequence number.
Currency
Specify the currency of the PPC.
PPC Amount
Specify the amount of the PPC. If the sum of the PPC amounts for all the PPCs presented
for the specific milestone is greater than the milestone percentage calculated amount an error
message is displayed.
34-15
The system will create the automatic limit lines for the lendable amount arrived at after
applying the sponsor retention margin and the bank margin.
Sponsor Retention Margin
The system displays the margin retained by the sponsor for this PPC. However, you can
amend this field while creating the PPC.
Sponsor Amount
The system displays the sponsor amount after applying the sponsor retention margin.
Bank Margin
The system displays the margin retained by the bank for this PPC. However, you can amend
this field while creating the PPC.
Lendable amount
The system displays the lendable amount after applying the bank margin.
Amount Paid
The system displays the amount that has been paid against this PPC.
Remarks
Specify remarks, if any.
34.4.2
Specifying Joint Venture Details
In case of manual line linkage, you need to operationally ensure the following points:

Synchronization of Line End date and PPC end date

Limit lines should have amounts equivalent to that of PPC lendable amount. In case line
currency is different from PPC currency, lines should be created for the equivalent of
PPC lendable amount by applying the rate conversion. If there is any mismatch in the
amounts, while linking the manual lines, the system will display an override message
Party ID
The system defaults the party ID from the project maintenance.
Ratio
The system defaults the joint venture share ratio from the project maintenance.
Credit Line
The system defaults the line ID. The system uses this limit line for tracking the exposure of
specific joint venture party.
If joint venture limit tracking is not required at project level, the system will not create the lines.
In case auto creation of lines is not chosen, then you need to manually create limit lines and
link them in this screen.
Serial Number
Specify the line serial of the credit line.
Currency
The system displays the line currency.
After specifying the PPC amount, click on ‘CALC” button. The will calculate the sponsor
margin and the bank margin and arrive at the sponsor amount and the lendable amount
respectively.
34-16
34.4.3
Maintaining PPC Liquidation
You can maintain the liquidation details in the PPC screen, where in you can choose the
payment of the loan or credit to the project account. This transaction is logged in the PPC. To
invoke the PPC Liquidation screen, type ‘STDPPCLQ’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Project ID
Specify the project ID.
Project Name
The system displays the name of the project ID selected.
PPC ID
Specify the PPC ID.
PPC Description
The system displays the description for the PPC ID selected.
Loan/Account Number
Specify the loan or the account number.
Entry Number
Specify the entry number. If you have not specified the entry number, then the system will
display an override message.
Amount
The system displays the amount for liquidation. However, you can amend this field.
Branch Code
Specify the branch code.
Currency
The system displays the currency details.
34-17
34.5 Viewing Dashboard Details
Oracle FLEXCUBE allows you to view the details of the PPC available in the project such as
joint venture ratios, balance in the project account, the project lines and their limits for each
project line, etc. You can view these details using ‘Dashboard Details’ screen. To invoke this
screen, type ‘STDPJDSH’ in the field at the top right corner of the Application tool bar and
clicking the adjoining arrow button.
The screen is as shown below:
You can view the following details:
34.5.1

Project ID

Project Name

Customer ID

Customer Name

Available Balance

Account Number

Account Currency

Project Limit

Project Utilization

Current Balance
Viewing PPC Details
You can view the PPC details by clicking on the ‘PPC Details’ tab in the ‘Dashboard Details’
screen.
34-18
The screen is as shown below:
You can view the following details:


34.5.2
Collateral Details
–
Collateral Type
–
Sequence
–
Collateral Description
–
Amount
–
Outstanding
–
Status
Venture Details
–
Party ID
–
% Share
–
Limit CCY
–
Limit
–
Available
Viewing Limit Details
You can view the limit details by clicking on the ‘Limit Details’ tab in the ‘Dashboard Details’
screen.
34-19
The screen is as shown below:
You can view the following details:


34.5.3
Project Line Details
–
Line ID
–
Line Serial
–
Limit
–
Utilized
–
Paid
Customer Line Details
–
Party ID
–
% Share
–
Line ID
–
Line Serial
–
Limit
–
Utilized
–
Paid
Viewing Commitment Details
You can view the commitment details by clicking on the ‘Commitment Details’ tab in the
‘Dashboard Details’ screen.
34-20
The screen is as shown below:
You can view the following details:
34.5.4

Contract Reference

Currency

Amount

Outstanding Amount

Maturity Date
Viewing Loan Details
You can view the loan details by clicking on the ‘Loan Details’ tab in the ‘Dashboard Details’
screen.
The screen is as shown below:
You can view the following details:

Contract Reference

Currency

Amount

Outstanding Amount

Maturity Date
34-21
34.6 Querying Dashboard Details
Oracle FLEXCUBE allows you to query the dashboard details based on the Project ID, Project
Name, Customer ID, Customer Name, Account Number. You can view these details using
‘Dashboard Summary’ screen. To invoke this screen, type ‘STSPJDSH’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
The screen is as shown below:
You can query the record based on the following details:

Project ID

Customer ID

Account Number

Project Limit

Project Name

Customer Name

Account Currency
You can double-click on a specific record to view the detailed screen.
34.7 Querying Accounting Entries
Oracle FLEXCUBE allows you to view the accounting entry serial number which can be used
in PPC liquidation screen for marking a specific credit entry for query. You can view these
details using ‘Customer Account Transaction Query’ screen. To invoke this screen type
‘ACDTRNQY’ in the field at the top right corner of the Application tool bar and click on the
adjoining arrow button.
34-22
The screen is as shown below:
You can query the record based on the following details:

Contract Reference

Account Number

Debit/Credit

Transaction Code

Currency

Event Code

Module Code

Value Date

Transaction Date

Related Reference

Related Account

From Date

Last N Number of Transactions

To Date
Clicking on the ‘Query’ button, the system displays the transaction details. You can doubleclick on a specific record to view the detailed screen.
34-23
Note
–
You can query for a specific number of previous records by entering the value in
‘Last N Number of Transactions’. By default, it is set as 100.
–
When you click ‘Query’ button, the system validates whether Last N.number of
transactions is greater than the menu level MAX_RES_ROWS of the function ID
‘ACDTRNQY’. If it is found greater than that, then the system displays a
configurable message ‘Last N number of transactions is greater than the allowed
maximum transactions to be retrieved’.
–
If you do not enter the last N number of transaction and click the ‘Query’ button, and
the number of transactions to be retrieved is greater than the menu level
MAX_RES_ROWS for the function ID ‘ACDTRNQY’, then the system will retrieve
only the first MAX_RES_ROWS number of transaction and display an information
message ‘Displaying only first[MAX_RES_ROWS] transactions’.
–
The starting balance and running balance fields of the Customer Account Transaction Query (ACDTRNQY) are not be applicable if you try to retrieve the Last N transaction.
34-24
35. Error and Error Codes for Project Financing
35.1 Error and Error Codes
Validation
Error Code
Description
System should not allow entering
PPCs if the total # of PPC’s already
entered exceeds the # allowed
ST-PPC-001
Max limit for number of
PPCs exhausted.
Whenever there is a change in the
# of PPC’s, the system should validate whether the change is an
increase or decrease. It should
only allow an increase in the # of
PPC’s
ST-CON003
Decreasing number of
PPCs not allowed
At the project maintenance, whenever there is a change in the project amount, the system should
validate and only allow an increase
in the project amount and not allow
a decrease
ST-CON005
Decrease of project
amount not allowed
In case of a JV, the total of the %
share of individual customers
should be 100%
ST-PROJ-009
Total share should be
100%
In case of a JV, each customer
should have a separate Liability ID
it is operational control.
ST-PROJ-028
Liability ID already in use
The milestone start date and end
date should be validated against
that of the project
ST-PROJ-004
The milestone start date/
end date should be equal
to or within the range of
project start and end date
The project status when changed
to CLOSED should be allowed only
when all PPC’s associated with the
respective project are in CLOSED
status
ST-PROJ-024
OPEN PPC’s exist. Project status cannot be
closed
In case of auto created lines, system should not allow amendment
on these lines
ST-CON012
Amendment of auto-created lines not allowed
The number of milestones cannot
exceed the number of PPCs
ST-PROJ-027
Number of milestones
cannot be greater than
the number of PPCs
At the project maintenance, each
project should have unique Line ID
for PPC lines.
35-1
The sum of the milestone percentage completion should be 100
ST-PROJ-010
The sum of milestone
completion should be
100
PPC end date is different from
PPC start date + PPC clearance
days. Configurable override
ST-PROJ-031
PPC End Date is different
from Project Start Date +
PPC Clearance days.
35-2
36. Reports
36.1 Introduction
You can generate the following reports:

List of deleted transactions

Accounting journal

Cash flow report

Balances of future dated transactions

Current Rates Report

Account Opening Confirmation

Activity Journal Report

Core Exception Report
36.2 List of Deleted Transactions
This report lists out the deleted transaction details pertaining to each product under each
module pertaining to every user. You can invoke this screen by typing ‘ACRDLTXN’ in the field
at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Specify the following details.
Module
Indicate whether the reports should be generated for a single module or for all modules.
If you choose ‘Single’, you need to specify the module for which the report needs to be
generated. The option list provided displays all valid module codes maintained in the system.
You can select the appropriate one.
Transactions
Indicate the type of transactions that should be covered in the report. The following options
are available:

All

This branch

Posted to Other Branch
36-1

This branch acted as bridge
Products
Indicate whether the reports should be generated for a single product or for all products.
If you choose ‘Single’, you need to specify the product code for which the report needs to be
generated. The option list provided displays all valid product codes maintained in the system.
You can select the appropriate one.
User
Indicate whether the reports should be generated for a transactions entered by all users or a
single user.
If you choose ‘Single’, you need to specify the user ID based on which the report needs to be
generated. The option list provided displays all valid user IDs maintained in the system. You
can select the appropriate one.
From
Specify the batch from which the transactions need to be considered for report generation.
To
Specify the batch until which transactions need to be considered for report generation.
Print Copies
Check this box to indicate that the report needs to be printed.
Click ‘OK’ to generate the report.
36.2.1
Contents of Report
The contents of this report are discussed under the following heads:
Header
The Header carries the title of the report, information on the branch code, branch date, the ID
of the user who generated the report, the date and time at which it was generated, the
modules covered in the report, the product codes covered in the report, batch information,
transactions covered in the report and printing preference.
Body of the Report
This report is sorted module-wise. For every module the following details are displayed.

Module

Product

User ID
The following transaction details are displayed.
Field Name
Field Description
Reference Number
This is the reference number of the deleted transaction
Account Branch
This is the branch where the account resides.
Account Number
This is the account number.
36-2
Currency
This is the currency of the transaction.
Debit/Credit
This indicates the nature of the transaction – debit or
credit.
Transaction Code
This is the transaction code.
Status
This is the status of the transaction
Value Date
Indicates the value date of the transaction
Account description
This is the account description.
Fcy Amount
This is the transaction amount in foreign currency.
Transaction Description
This is the description of the transaction code
Exchange Rate
This is the exchange rate
LCY Amount
This is the Amount in Local currency
Narrative
This is the narrative text associated with the transaction.
Instrument Number
This is the instrument number linked to the transaction.
Auth ID
This is the authorization ID
Total Debits
Total amount debited under the respective user, product
and module
Total Credits
Total amount credited under the respective user, product
and module
User ID
This is the user ID of the user who entered the transaction.
Grand Total Debits
This is the grand total amount of all the debit transaction
grouped by transaction code and user.
Grand Total Credits
This is the grand total amount of all the credit transaction
grouped by transaction code and user.
36-3
36.3 Accounting Journal
This report gives details of every journal entry transaction. You can invoke this screen by
typing ‘ACRJRNAL’ in the field at the top right corner of the Application tool bar and clicking
the adjoining arrow button.
Specify the following details:
Module
Indicate whether the reports should be generated for a single module or for all modules.
If you choose ‘Single’, you need to specify the module for which the report needs to be
generated. The option list provided displays all valid module codes maintained in the system.
You can select the appropriate one.
Transactions
Indicate the type of transactions that should be covered in the report. The following options
are available:

All

This branch

Posted to Other Branch

This branch acted as bridge
Products
Indicate whether the reports should be generated for a single product or for all products.
If you choose ‘Single’, you need to specify the product code for which the report needs to be
generated. The option list provided displays all valid product codes maintained in the system.
You can select the appropriate one.
User
Indicate whether the reports should be generated for a transactions entered by all users or a
single user.
If you choose ‘Single’, you need to specify the user ID based on which the report needs to be
generated. The option list provided displays all valid user IDs maintained in the system. You
can select the appropriate one.
36-4
From
Specify the batch from which the transactions need to be considered for report generation.
To
Specify the batch until which transactions need to be considered for report generation.
Print Copies
Check this box to indicate that the report needs to be printed.
Position Entries
Check this box to indicate that the report needs to cover position accounting entries.
Report Date
Specify the date as on which the report needs to be generated.
Click ‘OK’ to generate the report.
36.3.1
Contents of Report
The contents of this report are discussed under the following heads:
Header
The Header carries the title of the report, information on the branch code, branch date, the ID
of the user who generated the report, the date and time at which it was generated, the
modules covered in the report, the product codes covered in the report, batch information,
transactions covered in the report and printing preference.
Body of the report
The report is sorted by modules. Under every module, it lists out product-wise transaction
details.
The following transaction details are displayed.
Field Name
Field Description
Product
This is the product code of the transaction.
User Id
This is the user ID of the user who entered the transaction.
Reference No
This is the transaction reference number.
Account Branch
This is the account branch.
Account Number
This is the account number.
Currency
This is the currency of the transaction.
Dr/Cr
This is the nature of the transaction – either debit or credit.
Transaction Code
This is the transaction code while posting the journal entry.
Module
This is the module code of the report
Description
This is the description of the transaction code.
Status
Status of the transaction.
36-5
Value Date
This is the value date of the transaction.
Account Description
This is the description of the account.
Event
This is the event triggered on the transaction.
Fcy Amount
This is the transaction amount in a foreign currency
Exchange Rate
This is the exchange rate used if the transaction is in any other
currency.
Lcy Amount
This is the transaction amount in local currency.
Auth ID
This is the user ID of the user who authorized the transaction.
Total Debits
Total amount debited under the respective user, product and
module
Total Credits
Total amount credited under the respective user, product and
module
Grand Total Debits
This is the grand total amount of all the debit transaction
grouped by transaction code and user.
Grand Total Credits
This is the grand total amount of all the credit transaction
grouped by transaction code and user.
36.4 Cash Flow Report
The ‘Cash flow report’ gives details of the cash flow by accounts or by account class. The
report contains details of the Account Number or Account Class, and the list of Accounts or
Account Classes. You can invoke this screen by typing ‘ACRPCASH’ in the field at the top
right corner of the Application tool bar and clicking the adjoining arrow button.
The screen is as shown below:
36-6
Specify the following details.
Report Name
Specify the name of the report. The option list provided displays all valid reports maintained
in the system. You can select the appropriate one.
Report Type
Indicate whether the report should be a detailed report or a summary report.
Notice Contracts
Check this box to indicate that notice contracts should be covered in the report.
Call Contracts
Check this box to indicate that call contracts should be covered in the report.
Select Account Class/Account
Indicate whether the reports should be generated based on account class or account.
All/Specific Records
Indicate whether the reports should be generated for all records in an account class/account
or for specific records.
Account Class
If you have indicated ‘Account Class’ as the basis for report generation, specify the account
classes that should be considered. Click add icon to add rows. You can select a valid account
class from the adjoining option list.
Account
If you have indicated ‘Account’ as the basis for report generation, specify the accounts that
should be considered. Click add icon to add rows. You can select a valid account from the
adjoining option list.
Click ‘OK’ to generate the report.
36.4.1
Contents of Report
The contents of the cash flow report are discussed under the following heads:
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report, the module, page number and the date and time at which it was
generated.
Body of the Report
The report is sorted on the currency of the cash flow.
Field Name
Field Description
Interval
Indicates the interval of cash flow
Amount In
This is the amount debited into the particular account for the
particular period.
36-7
36.4.2
Account
This is the account number
Account Class
This indicates the account class
Amount Out
This is the amount credited from the account during the specified period.
Net Flow
Indicates the net flow
Currency
Indicates the currency of the transaction
Cash Flow (Summary) Report
The Cash Flow summary report summarizes the details of cash flow for particular Accounts
or Account Classes.
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report and the date and time at which it was generated.
Body of the Report
The report is sorted on the currency of the cash flow for different account classes and their
accounts. The following details are displayed.
Field
Name
Field Description
Amount In
This is the amount debited into the particular account for the specific period
Amount
Out
This is the amount credited from the account during the specified period
Net Flow
This is the net amount available in the account for the specified period
36-8
36.5 Future Dated Account Balance Report
This report gives balances of future dated transactions. You can invoke the screen by typing
‘ACRPFVBL’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
You can specify the following parameters:
Select Account Class/Account
Select account criteria for generating the report from the following options:

Account Class

Account
Report Preferences
Select report preference criteria for generating the report from the following options:

All Records

Specific Records
Account Class
Specify valid account classes for which you need to generate the report from the adjoining
option list, if you have selected ‘Account Class’.
Account
Specify valid account classes for which you need to generate the report from the adjoining
option list, if you have selected ‘Account’.
36.5.1
Contents of the Report
Header
The Header carries the title of the report, information on the branch code, branch date, the ID
of the user who generated the report, the date and time at which it was generated and the
modules covered in the report.
36-9
Body of the Report
The following details are displayed.
Field Name
Field Description
Date
This gives the date for which a future dated transaction is
booked for the account.
Reference Number
This is the reference number of the future dated transaction
Inflow
This is the inflow amount.
Outflow
This is the outflow amount.
Balance
This is the available balance.
Currency
This is the currency of the account
Customer
This is the name of the customer.
Account
This is the account number of the customer.
Account Class
This is the account class.
Opening
This is the opening balance of the account.
36.6 Current Rates Report
This report gives details on rates for currency pairs. You can invoke the screen by typing
‘CYRTCURR’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
Specify the following details.
36-10
Selection
Indicate whether the report should be generated for all currency pairs or for a given currency
pair.
Currency 1
If you have chosen, ‘Selected Currency Pair’, then specify the first currency that forms a pair.
The adjoining option list displays all valid currency codes maintained in the system. You can
select the appropriate one.
Currency 2
If you have chosen, ‘Selected Currency Pair’, then specify the second currency that forms the
pair. The adjoining option list displays all valid currency codes maintained in the system. You
can select the appropriate one.
Click ‘OK’ to generate the report.
36.6.1
Contents of Report
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report, the date and time at which it was generated, the module covered
in the report and reporting options.
Body of the report
The report is sorted by currency pairs. The following details are displayed.
Field Name
Field Description
Currency
Pair
This gives the currency pairs for which rate report has been generated.
Quotation
This indicates the quotation type – either direct or indirect.
No. of Units
This indicates the number of units of one currency being quoted
against the other.
Rate Type
This is the rate type.
Mid Rate
This is the mid rate used for conversion.
Buy Rate
This is the buy rate used for conversion.
Sale Rate
This is the sell rate used for conversion.
36-11
36.7 Rate History Report
This report gives details on history of rates for currency pairs. You can invoke the screen by
typing ‘CYRTHIST’ in the field at the top right corner of the Application tool bar and clicking
the adjoining arrow button.
Specify the following details.
Report For
All Currency Pairs
Select if you need all currency pairs.
Selected Currency Pair
Select if you need selected currency pair.
Selected Pair
Currency 1
If you have chosen, ‘Selected Currency Pair’, then specify the first currency that forms a pair.
The adjoining option list displays all valid currency codes maintained in the system. You can
select the appropriate one.
Currency 2
If you have chosen, ‘Selected Currency Pair’, then specify the second currency that forms the
pair. The adjoining option list displays all valid currency codes maintained in the system. You
can select the appropriate one.
Date Range
From Date
Specify the from date.
To Date
Specify the to date.
Click ‘OK’ to generate the report.
36-12
Header
The Header carries the title of the report, information on the branch code, branch date, the ID
of the user who generated the report, the date and time at which it was generated, the module
covered in the report, reporting options, currency pair, from date and to date .
Body of the report
The report is sorted by currency pairs. The following details are displayed.
Field Name
Field Description
Currency
Pair
This gives the currency pairs for which rate report has been generated.
Quotation
This indicates the quotation type – either direct or indirect.
No of Units
This indicates the number of units of one currency being quoted
against the other.
Rate Type
This is the rate type.
Date
The effective date of the rates applied.
Mid Rate
This is the mid rate used for conversion.
Buy Rate
This is the buy rate used for conversion.
Sale Rate
This is the sell rate used for conversion.
36.8 Customer Account Opening Confirmation Report
You can generate a report for the customer, confirming that his / her account with the bank
has been successfully opened. This report contains the following details:

Customer Type

Customer Number

Date
You can generate the Customer Account Opening Confirmation report for one customer or all
the customers at once, as of a specific date. To generate the report, invoke ‘Customer
Account Opening Confirmation’ screen.
You can invoke this screen by typing the code ‘CSRPACCO’ in the field at the top right corner
of the Application tool bar and click on the adjoining arrow button.
36-13
The screen is as shown below:
Customer Type
You can generate customer account opening confirmation report for one or all the customers.
Indicate your choice here. If you select ‘Single Customer’, you have to specify the customer
number in the space provided.
Customer Number
If you wish to generate a report specific to one customer, specify the customer number. The
option list displays all valid customer numbers maintained in the system. Select the
appropriate one.
Date
Specify the date as of which you want to generate the report.
Once you have set the preferences, click ‘OK’ button. The system displays the print option
screen, where you can set your preferences as to viewing and printing the report.
36.8.1
Contents of the Report
The contents of the report are discussed under the following heads:
Header
The Header carries the title of the report, information on the branch code, the run date and
time, the branch date, the user id, the module name and the page number of the report.
36-14
Body of the Report
Field Name
Field Description
Customer Name
Indicates the name of the customer
Customer Number
Indicates the customer number
First Nominee
Indicates the name of the first nominee
Second Nominee
Indicates the name of the second nominee
Address
Indicates the contact address for the customer whose
cheque has been rejected.
Client Account Number
Indicates the Account Number of the client
Subject
Indicates the subject
Account Details
First Account Holder Details
Name
Indicates the name
Address
Indicates the address
Street
Indicates the street
Place
Indicates the place
Date of Birth
Indicates the date of birth
Telephone
Indicates the telephone
Fax
Indicates the fax
Email
Indicates the email
Unique Number
Indicates the unique number
Account Opening Date
Indicates the account opening date
Alternate Account Number
Indicates the alternate account number
36.9 Activity Journal Report
This report gives details about activity journal in ‘Core Activity Journal’ screen. To invoke this
screen, type ‘CSRPACTJ’ in the field at the top right corner of the Application tool bar and
36-15
clicking the adjoining arrow button.
From Date
Specify the start date of the report date range. The system will include the details of the record
from this date.
To Date
Specify the end date of the report date range. The system will include the details of the record
until this date.
Report For
Specify whether you want to generate the report for all the modules or selected modules
alone. If you select ‘Selected Modules’, you need to specify the modules below.
Module
If you need to generate the report for selected modules, you need to indicate the modules
here. Use the add button to add more modules.
36.9.1
Contents of Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report, the date and time at which it was generated and the modules
covered in the report.
Body
You can find the following details in the body of the report:
Field Name
Field Description
Module
The module for which the report is being generated
Product Type
The type of product for which the report is being generated
36-16
Contract Ref No
The reference number of the contract being reported
Counter Party No
The CIF ID of the customer involved
Counter Party
Name
This is the name of the customer involved
User Def. Status
The status if the user defined elements
Event Date
The date on which the event took place
Seq. No
The sequence number of the event
Event Description
The description of the event
Contract Status
The status of the contract i.e., active, closed etc.
Maker ID
The identification number of the maker
Checker ID
the identification number of the checker
Reversed Seq. No.
The reversed sequence number
36.10 Core Exception Report
This report gives details about core exception in ‘Core Exception’ screen. To invoke this
screen, type ‘CSRPEXCP’ in the field at the top right corner of the Application tool bar and
clicking the adjoining arrow button.
The screen is as shown below:
From Date
Specify the start date of the report date range. The system will include the details of the record
from this date.
To Date
Specify the end date of the report date range. The system will include the details of the record
until this date.
36-17
Report For
Specify whether you want to generate the report for all the modules or selected modules
alone. If you select ‘Selected Modules’, you need to specify the modules below.
Selected List
If you need to generate the report for selected modules, you need to indicate the modules
here. Use the add button to add more modules.
36.10.1 Contents of Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The Header carries the title of the report, information on the branch code, the branch date, the
ID of the user who generated the report, the date and time at which it was generated and the
modules covered in the report.
Body
You can find the following details in the body of the report:
Field Name
Field Description
Module
The module for which the report is being generated
Contract Ref No
The reference number of the contract being reported
Counter Party
The name of the counter party
Counter Party
Name
The name of the counter party involved
Event Description
The description of the event
Exception
The description about the exception
36-18
36.11 Uncollected Funds Report
This report provides details of uncollected funds based on release date of the fund. You can
invoke this screen by typing 'ACRUNCOL' in the field at the top right corner of the application
tool bar and clicking the adjoining arrow button.
Specify the following details.
Accounts
Select the account for which the report is to be generated. The options are:

All - System fetches all the accounts which has uncollected funds.

One - If this option is selected, system fetches the report for a particular account, which
is selected in the option list.
Date option
Select the date for which report has to be generated:

Present Date: System fetches the uncollected fund which are available in the current
date

Between dates: If between dates is selected then From date and to date is mandatory.
System fetches the Uncollected fund details which are available in between dates.
From Date
Specify the From date.
To Date
Specify the To date.
36.11.1 Contents of Report
Header
The Header carries the title of the Report, information on the branch code, the branch date,
the user ID, the module name, the date and time at which the report was generated and the
page number of the report.
36-19
Body of the report
The details of the uncollected funds that would be displayed in the report are as follows:
Field Name
Field Description
Account
This is the account for which transaction details is being reported
Available Date
This indicates the available date
Transaction Reference
This is the reference number of the transaction for which
account has uncollected balance
Amount
This is the uncollected amount in the account
Total Amount
This is the total uncollected amount in the account
36.12 Account Revaluation Report
This report gives details of the memo revaluation funds. You can invoke this screen by typing
‘ACRREVAL’ in the field at the top right corner of the Application tool bar and clicking the
adjoining arrow button.
Memo or Normal
Specify the type of account revaluation report.
36.12.1 Contents of Report
Header
The Header carries the title of the Report, information on the branch code, the branch date,
the user ID, the module name, the date and time at which the report was generated and the
page number of the report.
36-20
Body of the report
The details of the uncollected funds that would be displayed in the report are as follows:
Field Name
Field Description
Currency
This is the currency for which transaction details is being
reported
Revaluation Rate
This is the revaluation rate
Account
This is the account for which transaction details is being
reported
Description
This is the description provided
Account Revalued
This is the revalued account
Account Balance
This indicated the account balance
LCY Equivalent (before
revaluation)
This indicates the amount equivalent to local currency
before revaluation
LCY Equivalent (after
revaluation)
This indicates the amount equivalent to local currency
after revaluation
Profit/ Loss
This is the profit or loss incurred
Profit/ Loss Amount
This is the profit or loss amount
P&L Account
This is the profit or loss account
Currency
This is the currency for which transaction details is being
reported
Rate
This is the revaluation rate
Category
This is the GL category
36-21
36.13 Accounts Movement Report
This report gives details of the movement of the accounts for that particular day. You can
invoke this screen by typing ‘ACRPMOVE’ in the field at the top right corner of the Application
tool bar and clicking the adjoining arrow button.
From Date
Specify the From Date from the option list.
To Date
Specify the To Date from the option list.
Account Number
Specify the account number from the option list.
Value Dated
Select if the report is value dated.
Booking Dated
Select if the report is booking dated.
Currency
Specify the currency from the option list.
Account Selection
Specify the type of account selection.
36.13.1 Contents of Report
Header
The Header carries the title of the Report, information on the branch code, the branch date,
the user ID, the module name, the date and time at which the report was generated and the
page number of the report.
36-22
Body of the report
The details of the uncollected funds that would be displayed in the report are as follows:
Field Name
Field Description
Account Number
This is the account number
Account Description
This is the brief description for the account
Account Currency
This is the currency of the account
Opening Balance
This is the opening balance of the account
FCY Amount
This is the opening balance of account in FCY
LCY Amount
This is the opening balance of account in LCY
Transaction Date
This is the transaction date
Transaction Description
This is a brief description of the transaction
Transaction Reference Number
This is the reference number of the transaction
posted to account
Value Date
This is the value date of transaction
FCY Amount
This is the amount of transaction in Foreign Currency
Rate
This is the exchange rate for FCY and LCY
LCY Amount
This is the amount of transaction in Local Currency
Current Balance
This is the current balance in the account
36.14 Customer Details Report
This report gives details of the customer and you can generate this report using the ‘Customer
Details’ screen.
36-23
You can invoke this screen by typing ‘STRCIF’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
36.14.1 Contents of Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The Header carries the branch, information on the branch date, the user ID, the module name,
the date and time at which the report was generated and the page number of the report.
Body of the report
The details of the customer information details that would be displayed in the report are as
follows:
Field Name
Description
Customer Information
Customer
Customer Identification Number of the customer
PID No
Indicates the Personal Identification number
Customer Name
Customer name
Address lines
Displays the address of the customer.
Country
The country the customer belongs to.
Nationality
The nationality of the customer.
Type
Type of the customer (individual or Corporate or Bank).
36-24
Unique ID Name
Displays the customer’s unique id name.
Unique ID Value
Displays the customer’s unique id value.
Creation Date
Displays the date of customer’s number creation.
Input By
The Login ID of the user that created the customer
record.
Input Date and Time
The date the customer record was created.
Auth By
The Login ID of the user that has authorized the record.
Auth Date and Time
The date of the authorization.
Mod Number
Displays the number of times the record was modified.
Auth Stat
Displays the current status of the customer record.
Record
Displays the record status.
Exposure Country
Displays the exposure country details.
Frozen
Displays the frozen status of the customer’s account.
Local Branch
Displays the customer’s local branch details.
Whereabouts Unknown
Gives the customer’s details regarding the whereabouts.
Deceased
Indicates whether the customer is fit or deceased.
Short Name
Customer’s abbreviated name.
Liability
This is the customer Liability ID number for which credit
facility granted to the customer.
Language
Language.
Category
Category of the customer of the bank.
Professional Details
Designation
Indicates Designation
Employer
Indicates Employer
Status
Indicates Status
Tenure
Indicates Tenure
36-25
Address
Indicates Address
Email
Indicates Email
Fax
Indicates Fax
Phone
Indicates Phone
Telex
Indicates Telex
Home Value
Indicates Home Value
Insurance
Indicates Insurance
Loans
Indicates Loans
Expenses
Indicates Expenses
Income
Indicates Income
Previous Designation
Indicates Previous Designation
Previous Employer
Indicates Previous Employer
Rent
Indicates Rent
Ret Age
Indicates Ret Age
Credit Cards
Indicates Credit Cards
IE Currency
Indicates IE Currency
Salary
Indicates Salary
Corporate Details
National Id
Indicates National Id
Name
Indicates Name
Currency Of Amounts
Indicates Currency Of Amounts
Incorporation Country
Indicates Incorporation Country
Incorporation Date
Indicates Incorporation Date
Net worth
Indicates Net worth
36-26
Capital
Indicates Capital
Registered Address
Indicates Registered Address
Address 2
Indicates Address 2
Address 3
Indicates Address 3
Country
Indicates Country
Business
Indicates Business
Director Name
Indicates Director Name
Personal Details
Prefix
Indicates Prefix
First Named
Indicates First Named
Middle Name
Indicates Middle Name
Last Name
Indicates Last Name
Date Of Birth
Indicates Date Of Birth
Sex
Indicates Sex
Domicile
Indicates Domicile
Line 2
Indicates Line 2
Line 3
Indicates Line 3
Domicile Cntry
Indicates Domicile Cntry
Minor
Indicates Minor
Legal Guard.
Indicates Legal Guard.
Passport Number
Indicates Passport Number
Issue Date
Indicates Issue Date
Expiry Date
Indicates Expiry Date
Permanent Address
Indicates Permanent Address
36-27
Address
Indicates Address
Country
Indicates Country
National Id
Indicates National Id
Phone
Indicates Phone
Telex
Indicates Telex
Email
Indicates Email
Fax
Indicates Fax
Domestic Details
Indicates Domestic Details
Accommodation
Indicates Accommodation
Dependent Child
Indicates Dependent Child
Dependent Other
Indicates Dependent Other
Education
Indicates Education
Marital Status
Indicates Marital Status
Spouse
Indicates Spouse
Spouse Employment
Status
Indicates Spouse Employment Status
The value of Maruyu Customer field will be derived from field Maruyu Status based on the
record with latest effective date which is less than or equal to the report date.
The system displays the Maruyu Limit Currency and Account Limit Amount based on the
Maruyu Limit record.
36.15 Customer Accounts Report
This report gives details of the customer account and you can generate this report using the
‘Customer Accounts’ screen.
36-28
You can invoke this screen by typing ‘STRCUSAC’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
36.15.1 Contents of Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The Header carries the branch, information on the branch date, the user ID, the module name,
the date and time at which the report was generated and the page number of the report.
Body of the report
The details of the customer accounts details that would be displayed in the report are as
follows:
Field Name
Field Description
Account Number
Details about customer account Number
Account Class
Details about account class
Account Description
Account Description
Opening Date
The opening date of the account.
Dormant
The account status as dormant
Frozen
Account status as frozen.
No Credits
Gives no credit status of the account number.
No Debits
Gives no debit status of the account number.
36-29
Stop Payments
Gives the accounts stop pay status.
Statement Cycle
Gives the account statement cycle.
Statement Day
Gives the account statement day.
Statement Type
Gives account statement type.
Alternate Account Number
Gives an alternative account number.
Branch Code
Gives the branch code.
Currency
Currency
Customer Number
Gives customer number.
Nominee1
Gives the first nominee details
Nominee2
Gives the second nominee details
Account Type
Gives the account type.
Dr GL
Gives all debit balances within a specific account class
Cr GL
Gives all credit balances within a specific account
class.
Dr HO Line
In this, all accounts belonging to account class will
report, if they move to the status being defined.
Cr HO Line
In this, all accounts belonging to account class will
report, if they move to the status being defined.
Dr CB Line
This is a GL to which all debit accounts belonging to an
account class should report to.
Cr CB Line
This is a GL to which all credit accounts belonging to
an account class should report to.
ATM Facility
Availability of ATM facility.
Cheque Book Facility
Availability of cheque book facility.
Passbook Facility
Availability of passbook facility.
Previous Statement Date
Gives the date of the previous statement.
Previous Statement Balance
Gives the balance of the previous statement.
Previous Statement Number
Gives the number of the previous statement
36-30
TOD Limit
The temporary overdraft limit facility granted to the
customer account
Sublimit
It the overdraft facility maximum permitted to this
account associated and tracked against the line id
maintained for the liability.
Limit Currency
Displays the currency code of the limit
TOD Limit Start Date
The start date for the temporary overdraft facility
TOD Limit End Date
The end date for the temporary overdraft facility.
Uncollected Funds Limit
The funds hit the account which are debited / credited
to the account with effect from the mentioned value
days
Line ID
The line code is associated with the liability ID against
which the overdraft facility is being tracked.
Tanked Status
It is the status of the transaction that hit the account in
a specific branch once the branch is marked for EOTI.
Account Balance
Gives the total account balance
Maker ID
The identification number of the maker
Maker Date Stamp
This is the date on which the contract was uploaded.
Checker ID
This is the Login ID of the user who authorized the
product.
Checker Date Stamp
This is the date on which the product was authorized.
Mod Number
Displays the number of times the record was modified.
Record Stat
Displays the current status of the external account
record.
Authorization Status
Displays the current authorization status of the record.
Joint Holder Code
Displays joint holder CIF ID
Joint Holder Description
Displays description of the joint holder
Joint Holder
Displays linked entities of the joint holder
The value of Maruyu Customer field will be derived from field Maruyu Status based on the
record with latest effective date which is less than or equal to the report date.
The system displays the Maruyu Limit Currency and Account Limit Amount based on the
Maruyu Limit record.
36-31
36.16 Document Check List Report
This report gives you the details of the customer account whose documents are pending for
submission, expired, or about to expire.
You can invoke this screen by typing ‘STRDOCL’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
Branch Code
Specify the branch code
Document Status
Specify the status of the document submitted by the customer from the adjoining option list.
You can select one of the following:

Pending

About to Expire

Expired
Note
–
If you select the document status as ‘About to Expire’, then the ‘From Date’ should
be greater than the current date.
–
If you select the document status as ‘Expired’, then the ‘To Date’ should be less than
the current date.
From Date
Specify the date from which details should be made available in the report. The system will
include all customers whose date is equal to or greater than this date.
To Date
Specify the date till which details should be made available in the report. The system will
include all customers whose date is equal to or lesser than this date.
Report Format
Select the format in which you need to generate the report from the adjoining drop-down list.
This list displays the following values:
36-32

HTML – Select to generate report in HTML format.

RTF – Select to generate report in RTF format.

PDF – Select to generate report in PDF format.

EXCEL – Select to generate report in EXCEL format.
Report Output
Select the report output in which you need to generate the report from the adjoining dropdown list. This list displays the following values:

Print – Select to print the report.

View – Select to print the report.

Spool – Select to spool the report to a specified folder so that you can print it later.
Printer At
Select location where you wish to print the report from the adjoining drop-down list. This list
displays the following values:

Client – Select if you need to print at the client location.

Server – Select if you need to print at the server location
Printer
Select printer using which you wish to print the report from the adjoining option list.
36.16.1 Contents of the Report
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report, the date and time at which it was generated and the modules
covered in the report.
36-33
Body of the Report
Field Name
Field Description
Branch Code
Current branch code
Customer Number
Customer identification number
Customer Name
Customer name
Customer Account
Number
Customer account number
Document Type
Type of document
Expiry Date
Expiry date of the document
Expected Date of
Submission
Expected date of document submission
Actual Submission
Date
Actual document submission date
36.17 Memo Revaluation Report
You can invoke this screen by typing ‘ACRMREVL’ in the field at the top right corner of the
Application tool bar and clicking the adjoining arrow button.
36.17.1 Contents of Report
Header
The Header carries the title of the Report, information on the branch code, the branch date,
the user ID, the module name, the date and time at which the report was generated and the
page number of the report.
36-34
Body of the Report
Field Name
Field Description
Currency
This is the currency for which transaction details is
being reported
Revaluation Rate
This is the revaluation rate
Account
This is the account for which transaction details is
being reported
Description
This is the description provided
Account Revalued
This is the revalued account
Account Balance
This indicated the account balance
Lcy Equivalent (before reval)
This indicates the local currency before revaluation
Lcy Equivalent (after reval)
This indicates the local currency after revaluation
Profit/ Loss
This is the profit or loss incurred
Profit/ Loss Amount
This is the profit or loss amount
P&L Account
This is the profit or loss account
Currency
This is the currency for which transaction details is
being reported
Rate
This is the revaluation rate
Category
This is the category
36.18 Black Listed During Contract Booking Report
You can invoke ‘Black Listed During Contract Booking Report’ screen by typing ‘CSRPBLCB’
in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow
button.
36-35
The screen is as shown below:
Date
Specify the date when the contract was black listed from the adjoining calendar.
36.18.1 Contents of the Report
The contents of the report are discussed under the following heads:
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
36-36
Body of the Report
Field Name
Field Description
Reference Number
Indicates the reference number
Customer Number
Indicates the customer number
Customer Name
This indicates the name of the customer
Nationality
Indicates the nationality of the customer
Unique ID Name
Indicates the unique identification name
RM Code
Indicates the relationship manager code
RM Name
Indicates the name of relationship manager
36.19 Black List Report During File Upload Report
You can invoke ‘Black List Report During File Upload’ screen by typing ‘CSRPBLUP’ in the
field at the top right corner of the Application tool bar and clicking on the adjoining arrow
button.
The screen is as shown below:
36.19.1 Contents of the Report
The contents of the report are discussed under the following heads:
36-37
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
Body of the Report
Field Name
Field Description
Customer Number
Indicates the customer number
Customer Name
This indicates the name of the customer
Nationality
Indicates the nationality of the customer
Unique ID Name
Indicates the unique identification name
Unique ID Value
Indicates the unique identification value
RM Code
Indicates the relationship manager code
RM Name
Indicates the name of relationship manager
36.20 Cheque Book Issued Report
You can invoke ‘Cheque Book Issued Report’ screen by typing ‘CSRPCHB’ in the field at the
top right corner of the Application tool bar and clicking on the adjoining arrow button.
The screen is as shown below:
Branch Code
You can generate this report for all the branches or a single branch alone. You can indicate
the branch for which the report is being generated using the following options:
36-38

All – If you choose this, the system will generate the report for all the branches.

Single – If you choose this, you need to specify the branch code for which the report
should be generated. The option list displays all valid branch codes maintained in the
system. Choose the appropriate one.
Date Range
From Date
Specify a valid date from when you wish to generate the report from the adjoining calendar.
To Date
Specify a valid date till when you wish to generate the report from the adjoining calendar.
36.20.1 Contents of the Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
Body of the Report
Field Name
Field Description
Date of Issue
Indicates the date of issue
Issuing Channel
Indicates the Issuing Channel
Account Number
Indicates the account number
Account Currency
Indicates the account currency
Account Name
Indicates the account name
Serial Number
Indicates the serial number
Maker ID
Indicates the maker ID
Checker ID
Indicates the checker ID
36.21 Demand Draft Issued Report
You can invoke ‘Demand Draft Issued Report’ screen by typing ‘CSRPDDRP’ in the field at
the top right corner of the Application tool bar and clicking on the adjoining arrow button.
36-39
The screen is as shown below:
Branch Code
You can generate this report for all the branches or a single branch alone. You can indicate
the branch for which the report is being generated using the following options:

All – If you choose this, the system will generate the report for all the branches.

Single – If you choose this, you need to specify the branch code for which the report
should be generated. The option list displays all valid branch codes maintained in the
system. Choose the appropriate one.
36.21.1 Contents of the Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
36-40
Body of the Report
Field Name
Field Description
Account Number
Indicates the account number
Account Name
This indicates the name of the account
Currency
Indicates the currency of the account
Amount
Indicates the amount
Instrument Number
Indicates the instrument number
Description
Indicates the description of the demand draft
Cheque Number
Indicates the Cheque Number
Drawn On
Indicates the date when the DD was drawn
Input On
Indicates the date when the data was provided
Reference Number
Indicates the reference number
Maker ID
Indicates the identification of the maker of the record
Maker Date Stamp
Indicates the date when the record was created
Checker ID
Indicates the identification of the checker who authorized the record
Checker Date Stamp
Indicates the date on which the record was authorized
36.22 PDC Input Report
You can invoke ‘PDC Input Report’ screen by typing ‘CSRPPDC’ in the field at the top right
corner of the Application tool bar and clicking on the adjoining arrow button.
36-41
The screen is as shown below:
36.22.1 Contents of the Report
The contents of the report are discussed under the following heads:
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
36-42
Body of the Report
Field Name
Field Description
Account Number
Indicates the account number
Account Name
This indicates the name of the account
Currency
Indicates the currency of the account
Amount
Indicates the amount
Instrument Number
Indicates the instrument number
Bank Name
Indicates the name of the bank
Clearing Date
Indicates the date of clearing
Value Date
Indicates the value date of the demand draft
Maker ID
Indicates the identification of the maker of the record
Maker Date Stamp
Indicates the date when the record was created
Reference Number
Indicates the reference number
36.23 Temporary Overdraft Report
You can invoke ‘Temporary Overdraft Report’ screen by typing ‘CSRTEMOD’ in the field at
the top right corner of the Application tool bar and clicking on the adjoining arrow button.
Temporary overdraft report displays only current and savings account of the customer.
36-43
The screen is as shown below:
Branch Code
You can generate this report for all the branches or a single branch alone. You can indicate
the branch for which the report is being generated using the following options:

All – If you choose this, the system will generate the report for all the branches.

Single – If you choose this, you need to specify the branch code for which the report
should be generated. The option list displays all valid branch codes maintained in the
system. Choose the appropriate one.
Customer Type
Select the type of customer from the following options provided:

Bank

Corporate

Individual

All
36.23.1 Contents of the Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The header carries the Report Name, Branch, Branch Date, User Id, Module, Run Date and
Time.
36-44
Body of the Report
Field Name
Field Description
Customer Account Number
Indicates the customer account number
Customer Name
This indicates the name of the customer
Customer Type
Indicates the type of customer
Account Description
Displays the description for the account
Branch
Indicates the branch of the account
Customer Number
Indicates the customer number
Account Class
Indicates the account class of the customer
Customer Category
Indicates the category to which customer belong to
MIS Code
Indicates the MIS code
Currency
Indicates the currency of the account
Holding Amount
Indicates the holding amount
LCY Opening Balance
Indicates the opening balance in local currency
ACY Opening Balance
Indicates the opening balance of the account currency
ACY Available Balance
Indicates the available balance of the account currency
ACY Current Balance
Indicates the current balance of the account currency
Temp OD Since
Indicates the date when the temp OD was started
Overdraft Since
Indicates the date when the overdraft was started
Temp OD Debits Today
Indicates the day’s temp OD debits
Temp OD Credits Today
Indicates the day’s temp OD credits
36.24 Daily Sales Report
36-45
You can invoke the screen by typing the code ‘CORDSLRP’ in the field at the top right corner
of the Application tool bar and click on the adjoining arrow button.
You can specify the following parameters here:
Branch Code
Specify the branch code from the adjoining option list.
From Date
Specify a valid date from when you wish to generate the report from the adjoining calendar.
To Date
Specify a valid date till when you wish to generate the report from the adjoining calendar.
36.24.1 Contents of the Report
The parameters specified while generating the report are printed at the beginning of the
report. Other content displayed in the report is as follows:
Header
The following details are displayed in the header section:
Field Name
Field Description
Branch
Indicates Branch Code and Branch Name
Branch Date
Indicates Current Date of the Branch
User ID
Indicates User ID
Date & Time
Indicates the Date and Time when the report was generated
Module
Indicates module for which report is generated.
36-46
Body of the Report
The following details are displayed as body of the generated report:
Field Name
Field Description
Module
Indicates the module code
Outstanding Amount
Indicates the outstanding amount
Product Code
Indicates the product code
Customer ID
Indicates the customer ID
Customer Name
Indicates the name of the customer
Product Description
Indicates the product description
Account Number
Indicates Customer Account number
Booking Date
Indicates the date of booking
Branch Name
Indicates Branch Name
RM Code
Indicates the relationship manager code
DS Code
Indicates the DS code
36.25 Exception Report
The report gives details of overrides accepted during transaction processing.(for example,
Available Balance * for * is less than the Min balance for the A/c Class, Signature Verification
not done, etc. You can specify the period for which you require the report when you invoke
the report function. In the Application Browser, this report is available under the Signature
Verification module.
To invoke this screen type ‘SVROV in the field at top right corner of the Application tool bar
and click the adjoining arrow button.
36-47
36.25.1 Contents of the Events Log
The contents of this report are discussed under the following heads:
Header
The Header carries the title of the report, information on the branch code, the ID of the user
who generated the report, the date and time at which it was generated, the branch date, the
modules covered in the report.
Body of the report
The following details are displayed in the report.
Module
The module of the report
Contract Reference
The contract reference number of the transaction
Event Sequence Number
The sequence number of the event
Instrument Code
The instrument code of the transaction
User Id
The Id of the user who generates the report
Auth Id
The Id of the person who authorized the transaction
Exception
Override message
36-48
37. Function ID Glossary
A
CYDCCYPE ..................... 14-10
CYDCCYPR ....................... 13-1
CYDCUSPR ....................... 15-3
CYDCYTHR ....................... 14-8
CYDRATEE ........................ 14-1
CYDSPRDF ........................ 15-1
CYRTCURR ..................... 36-10
CYRTHIST ........................ 36-12
CYSCYTHR ........................ 14-9
CYSRATES ........................ 14-4
ACDIBMNT ........................... 9-1
ACRDLTXN ........................ 36-1
ACRJRNAL ......................... 36-4
ACRMREVL ..................... 36-34
ACRPCASH ....................... 36-6
ACRPFVBL ......................... 36-9
ACRPMOVE ..................... 36-22
ACRREVAL ...................... 36-20
C
F
CFDCUMRG ...................... 15-4
CORDSLRP ..................... 36-46
CSDACRHM ....................... 5-35
CSDAMLCG ....................... 32-5
CSDAMLLM ....................... 32-4
CSDAMLPC ....................... 32-2
CSDDEMAN ....................... 11-1
CSDDEVDT ........................ 33-1
CSDDEVPR ....................... 33-4
CSDOVDMT ....................... 25-4
CSDPLMNT ...................... 10-24
CSDPXMNT ....................... 14-6
CSDRAMDN ......................... 3-1
CSRPACCO ..................... 36-13
CSRPACTJ ....................... 36-15
CSRPBLCB ...................... 36-35
CSRPBLUP ...................... 36-37
CSRPCHB ........................ 36-38
CSRPDDRP ..................... 36-39
CSRPEXCP ...................... 36-17
CSRPPDC ........................ 36-41
CSRTEMOD ..................... 36-43
CSSACRHM ....................... 5-36
CSSDEVDT ........................ 33-3
CSSDEVPR ........................ 33-6
CYDBATRT ........................ 14-5
FTDVDSPR ...................... 10-12
I
IADIBMNT ............................ 9-5
ISDINSTN ......................... 10-21
L
LMDTYPES ...................... 10-23
S
STDBANKP .......................... 2-1
STDBRANC .......................... 5-3
STDBRRES .......................... 2-8
STDDATES .......................... 7-1
STDDEALR .......................... 4-1
STDLOCHL ........................ 21-1
STDNETQY .......................... 9-6
STDSTSCD ........................ 18-1
STDTRCOD ....................... 19-1
STDTRNCD ........................ 32-7
STDTXCYL ......................... 5-31
STRCIF ............................. 36-24
STRCUSAC ...................... 36-29
STRDOCL ........................ 36-32
SVROV ............................. 36-47
37-1
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement