BML Istiharat ICBS Islamic Core Bnaking Capabilities Guide 2015.1

INTEGRATED
COMPUTERIZED
BANKING
SYSTEM
ICBS
Islamic
Capabilities Guide
By BML Istisharat SAL

January, 2015
Ref: CAPG-I/2015.1
BML Istisharat ICBS - Islamic
Table of Contents
1 FOREWORD.....................................................................................................................................10
1.1 ICBS STRENGTH POINTS..........................................................................................................................................11
1.2 ICBS MODULES DIAGRAM......................................................................................................................................12
2 ICBS SELECTED REFERENCES............................................................................................................13
3 ICBS SUBDIVISION INTO MODULES.................................................................................................16
4 ICBS NUCLEUS AND STANDARD FEATURES.....................................................................................18
4.1 INTEGRATION AND EFFICIENCY..............................................................................................................................18
4.2 INTERACTIVITY AND EASE OF OPERATION THROUGH STANDARD GUI.................................................................19
4.3 ON LINE REAL TIME 24X7.......................................................................................................................................20
4.3.1 ON LINE REAL TIME........................................................................................................................................20
4.3.2 REAL TIME 24 X 7 MECHANISM.....................................................................................................................20
4.4 MULTILINGUAL.......................................................................................................................................................21
4.5 SECURITY & TRANSACTIONS CONTROL..................................................................................................................21
4.5.1 GROUP AND USERS PROFILES........................................................................................................................21
4.5.2 USERS AUTHENTICATION AND LOGIN............................................................................................................22
4.5.3 AUDIT TRAIL...................................................................................................................................................22
4.5.4 DATA INTEGRITY:............................................................................................................................................23
4.5.5 TRANSACTIONS, CONTROL AND VALIDATION................................................................................................23
4.5.6 ESCALATIONS AND EXCEPTION MANAGEMENT............................................................................................24
4.6 FLEXIBILITY & EXPANDABILITY................................................................................................................................25
4.6.1 CONFIGURABLE MENUS.................................................................................................................................25
4.6.2 CONFIGURABLE SCREENS AND REPORTS LABELS..........................................................................................25
4.6.3 CONFIGURABLE ERROR MESSAGES................................................................................................................25
4.6.4 CONFIGURABLE PROFILES..............................................................................................................................26
4.6.5 CODES, PARAMETERS AND PRICING TABLES.................................................................................................26
4.6.6 CONFIGURABLE PRODUCTS BUSINESS RULES................................................................................................26
4.6.7 CONFIGURABLE ISLAMIC ACCOUNTING PRODUCTS......................................................................................27
4.6.8 CONFIGURABLE OPERATIONS BUSINESS RULES............................................................................................32
4.6.9 CONFIGURABLE STANDARD AND PARTICULAR CONDITIONS........................................................................34
4.6.10 CONFIGURABLE MESSAGES, DOCUMENTS, STATEMENT AND CUSTOMERS NOTES.....................................34
4.6.11 WORKFLOWS..................................................................................................................................................34
4.6.12 CONFIGURABLE AUTOMATED BATCH PROCESSING......................................................................................34
4.7 MULTI-CURRENCY...................................................................................................................................................35
4.8 MULTI- ENTITY........................................................................................................................................................35
4.9 CUSTOMERS’ INFORMATION..................................................................................................................................35
4.9.1 INTRODUCTION..............................................................................................................................................35
Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 2

4.9.2 SCHEMATIC GLOBAL VIEW.............................................................................................................................37
4.9.3 INDIVIDUALS MANAGEMENT.........................................................................................................................38
4.9.4 CORPORATE MANAGEMENT..........................................................................................................................38
4.9.5 CUSTOMERS MANAGEMENT.........................................................................................................................39
4.9.6 OTHER MAIN ENTITIES RELATED TO CUSTOMERS INFORMATION................................................................40
4.10 GENERAL LEDGER ACCOUNTING............................................................................................................................41
4.10.1 PARAMETRIC CHART OF ACCOUNTS:.............................................................................................................41
4.10.2 PARAMETRIC COST CENTERS.........................................................................................................................42
4.10.3 MULTI SEGMENTS ACCOUNTING NUMBER...................................................................................................42
4.10.4 GENERAL LEDGER FEATURES.........................................................................................................................42
4.10.5 PAYABLES MANAGEMENT..............................................................................................................................43
4.10.6 BUDGET CONTROL.........................................................................................................................................44
4.10.7 TRANSACTIONS FEEDER.................................................................................................................................44
4.10.8 INTEGRATION WITH THIRD PARTY G/L AND ACCOUNTING SYSTEMS:..........................................................44
4.11 CUSTOMERS’ ACCOUNTS........................................................................................................................................45
4.11.1 IN GENERAL....................................................................................................................................................45
4.11.2 ACCOUNTS OPENING AND MAINTENANCE....................................................................................................45
4.11.3 CUSTOMERS’ ACCOUNTS CLOSING................................................................................................................47
4.12 RICH SET OF REPORTING........................................................................................................................................48
4.12.1 STANDARD REPORTS......................................................................................................................................48
4.12.2 SAMPLE OF REPORTS & INQUIRIES................................................................................................................49
4.12.3 REPORTS CUSTOMIZATION............................................................................................................................52
4.12.4 OPTIONAL REPORTING FROM REPLICATION SERVERS...................................................................................52
4.13 INTEGRATIONS WITH THIRD PARTY SOLUTIONS AND DELIVERY CHANNELS.........................................................53
4.14 FULLY DOCUMENTED.............................................................................................................................................53
4.14.1 FUNCTIONAL SPECIFICATIONS / USER MANUALS..........................................................................................53
4.14.2 TRAINING MANUALS......................................................................................................................................53
4.14.3 TEST PLANS.....................................................................................................................................................53
4.14.4 ADMINISTRATOR MANUALS..........................................................................................................................53
4.14.5 TECHNICAL DOCUMENTATION.......................................................................................................................53
4.14.6 DATA MODELS................................................................................................................................................53
5 CENTRAL PROCESSING & INTERFACES.............................................................................................54
5.1 CREDIT FACILITIES MANAGEMENT.........................................................................................................................54
5.1.1 SCOPE.............................................................................................................................................................54
5.1.2 GENERAL PROCEDURE....................................................................................................................................54
5.1.3 SCHEMATIC VIEW...........................................................................................................................................55
5.1.4 MAIN FUNCTIONS..........................................................................................................................................56
5.2 PROFIT DISTRIBUTION AND A’DAD CALCULATION.................................................................................................57
5.2.1 ISLAMIC SAVING AND TERM ACCOUNTS PROFIT CALCULATION AND DISTRIBUTION...................................57
5.2.2 PRODUCTS SPECIFIC CONDITIONS..................................................................................................................58

5.2.3 ADA’D POINTS COMPUTATION:.....................................................................................................................59
5.2.4 PROFIT DISTRIBUTION....................................................................................................................................60
5.2.5 ISLAMIC FIXED TIME DEPOSITS MANAGEMENT............................................................................................61
5.3 CENTRAL BANKS REQUIREMENTS..........................................................................................................................61
5.3.1 MAIN FEATURES.............................................................................................................................................61
5.3.3 EXCHANGE OF INFORMATION WITH CREDIT BUREAU..................................................................................62
5.3.4 INTERNATIONAL TRANSACTIONS REPORTING SYSTEM (ITRS).......................................................................62
5.3.5 FIGHTS AGAINST MONEY LAUNDERING........................................................................................................63
5.4 RECONCILIATION....................................................................................................................................................64
5.4.1 NOSTRO ACCOUNTS.......................................................................................................................................64
5.4.2 G/L ACCOUNTS...............................................................................................................................................64
5.4.3 REPORTS AND INQUIRIES...............................................................................................................................65
5.5 CARD MANAGEMENT, ATM, POS AND CDM INTERFACE.......................................................................................65
5.5.1 CARD MANAGEMENT INTERFACE..................................................................................................................65
5.5.2 ATM, POS AND CDM INTERFACE....................................................................................................................65
5.5.3 CREDIT CARD TRANSACTIONS INTERFACE.....................................................................................................65
5.6 OFFICE TOOLS INTEGRATION.................................................................................................................................66
5.7 SWIFT SOLUTION INTEGRATION.............................................................................................................................66
5.8 EMAILS, SMS, IVR AND MOBILE BANKING INTEGRATION.....................................................................................67
5.9 SIGNATURE VERIFICATION AND FINGERPRINTS SOLUTION INTEGRATIONS.........................................................67
5.10 INTEGRATION WITH ELECTRONIC CHECKS PROCESSING (ECC) SOLUTIONS..........................................................68
5.11 NATIONAL PAYMENT SYSTEMS, RTGS AND ACH SOLUTIONS................................................................................68
5.12 INTEGRATION WITH E-BANKING SOLUTION..........................................................................................................69
5.13 OTHER CENTRAL PROCESSING OPERATIONS.........................................................................................................69
5.14 SELECTED REPORTS.................................................................................................................................................69
5.14.1 SITUATION, ANALYSIS REPORTS & FINANCIAL STATEMENTS........................................................................69
5.14.2 CONSOLIDATION AND MIS REPORTS.............................................................................................................71
5.14.3 OTHER SAMPLE REPORTS...............................................................................................................................71
6 BRANCH OPERATIONS MODULES....................................................................................................73
6.1 INTRODUCTION......................................................................................................................................................73
6.2 CUSTOMERS INFORMATION SYSTEM.....................................................................................................................73
6.3 ACCOUNTS OPENING, CLOSING AND MAINTENANCE...........................................................................................73
6.4 TRANSACTION GENERAL PROCEDURE....................................................................................................................74
6.5 EXCEPTION HANDLING, OVERRIDE AND VALIDATION PROCESS............................................................................74
6.6 USAGE OF CONFIGURABLE OPERATIONS...............................................................................................................74
6.6.1 ICBS CUSTOMIZED OPERATION MODULE......................................................................................................74
6.6.2 OTHER OPERATIONS THROUGH DEDICATED MODULES................................................................................75
6.7 PASSBOOK MANAGEMENT AND UPDATE..............................................................................................................75
6.8 BRANCHES AND CASHIERS MANAGEMENT............................................................................................................75

6.8.1 BRANCH INITIATION AND MAINTENANCE.....................................................................................................75
6.8.2 BRANCH SESSIONS AND CASHIERS MANAGEMENT.......................................................................................76
6.8.3 OTHER END OF DAY BRANCH PROCESSING...................................................................................................77
6.9 ISLAMIC FIXED TIME DEPOSITS MANAGEMENT.....................................................................................................77
6.9.1 SETTING A NEW FIXED DEPOSIT (AS PART OF THE BRANCH OPERATION)....................................................77
6.9.2 FIXED TIME DEPOSIT FOLLOW UP..................................................................................................................78
6.9.3 MAIN REPORTS & INQUIRIES.........................................................................................................................78
6.10 CHECKBOOKS MANAGEMENT................................................................................................................................78
6.10.1 DIFFERENT TYPES OF CHECKBOOKS...............................................................................................................78
6.10.2 COMPLETE CHECKBOOK ORDER AND DELIVERY WORKFLOW:......................................................................79
6.10.3 HANDLING OF PERSONAL PRINTED CHECKS..................................................................................................79
6.10.4 STOP PAYMENT:.............................................................................................................................................80
6.10.5 SELECTED INQUIRIES AND REPORTS..............................................................................................................80
6.10.6 CERTIFIED CHECKS..........................................................................................................................................80
6.11 LOCAL CHECKS REMITTANCE AND COLLECTION....................................................................................................81
6.11.1 PREAMBLE......................................................................................................................................................81
6.11.2 CHECKS REMITTANCE & COLLECTION FUNCTIONALITY.................................................................................82
6.11.3 CLEARING OR PURCHASED CHECKS REMITTANCE.........................................................................................83
6.11.4 LOCAL CHECKS FOR COLLECTION REMITTANCE.............................................................................................83
6.11.5 SETTLEMENT OF CHECKS................................................................................................................................83
6.11.6 RETURNED UNPAID CHECKS / CHECKS ACCEPTANCE....................................................................................84
6.11.7 SELECTED INQUIRIES AND REPORTS..............................................................................................................85
6.12 RECEIVED CHECKS...................................................................................................................................................85
6.13 POST DATED CHECKS..............................................................................................................................................87
6.14 DECLARATION OF UNPAID CHECKS DRAWN ON US...............................................................................................87
6.15 DRAFT / CASHIER’S CHECKS....................................................................................................................................87
6.16 TRAVELER'S CHECKS MANAGEMENT.....................................................................................................................89
6.17 STANDING INSTRUCTION MANAGEMENT..............................................................................................................89
6.17.1 INTRODUCTION..............................................................................................................................................89
6.17.3 MAIN FUNCTIONS..........................................................................................................................................91
6.18 MULTIPLE TRANSFERS (UTILITY BILLS AND CORPORATE SALARIES)......................................................................91
6.18.1 INTRODUCTION..............................................................................................................................................91
6.18.3 AGREEMENTS AND SUBSCRIPTION MAINTENANCE AND FOLLOW UP..........................................................93
6.19 BILLS MANAGEMENT..............................................................................................................................................94
6.20 GENERAL BRANCH INQUIRIES AND REPORTS........................................................................................................94
7 ISLAMIC FINANCING MODULES.......................................................................................................96
7.1 GENERAL DEFINITIONS...........................................................................................................................................96
7.1.1 THE MURABAHA OPERATION........................................................................................................................96

7.1.2 THE MUSAWAMA OPERATION......................................................................................................................97
7.1.3 THE CHARITY LOAN........................................................................................................................................98
7.1.4 THE TAWARRUQ DEALS..................................................................................................................................98
7.1.5 THE FOREIGN MURABAHA.............................................................................................................................98
7.1.6 THE MUDARABAH OPERATION......................................................................................................................99
7.1.7 THE MUSHARAKAH OPERATION..................................................................................................................100
7.1.8 THE ISTISNA’A AND PARALLEL ISTISNA’A OPERATIONS...............................................................................101
7.1.9 THE SALAM AND PARALLEL SALAM OPERATIONS.......................................................................................102
7.2 ICBS ISLAMIC FINANCING MODULES....................................................................................................................103
7.2.1 INTRODUCTION............................................................................................................................................103
7.2.2 GENERAL PROCEDURE AND WORKFLOW....................................................................................................105
7.3 ICBS ISLAMIC FINANCING BASIC FUNCTIONALITY................................................................................................107
7.3.1 PRODUCTS CONFIGURATION.......................................................................................................................107
7.3.2 ILLUSTRATION / ORIGINATION – SET UP:....................................................................................................108
7.3.3 MULTILEVEL APPROVAL WORKFLOW AND FUNDS DISBURSEMENT PROCESSES........................................109
7.3.4 MURABAHA SAMPLE APPLICATION AND APPROVAL WORKFLOW.............................................................110
7.3.5 DEAL TRACKING AND FOLLOW UP:..............................................................................................................110
7.3.6 REPAYMENTS / SETTLEMENT:......................................................................................................................110
7.3.7 ARREARS, PAST DUE FOLLOW UP, CLASSIFICATION & REARRANGEMENTS:...............................................111
7.3.8 LEGAL CASES MANAGEMENT AND COLLECTIONS.......................................................................................111
7.3.9 SELECTED REPORTS AND INQUIRIES:...........................................................................................................111
7.4 MUDARABAH FINANCING SPECIFICITIES..............................................................................................................113
7.4.1 MUDARABAH AGREEMENT SCOPE:.............................................................................................................113
7.4.2 PRODUCTS DEFINITION................................................................................................................................113
7.4.3 CUSTOMER APPLICATION, APPROVAL AND VALIDATION............................................................................113
7.4.4 MUDARABAH UTILIZATION / DISBURSEMENTS...........................................................................................114
7.4.5 REPAYMENT / FOLLOW UP..........................................................................................................................114
7.4.6 EXPIRED MUDARABAH AND AMENDMENT.................................................................................................114
7.4.7 MUDARABAH CLOSING / SETTLEMENT - ‫تصفية‬............................................................................................115
7.4.8 MAIN REPORTS ARE:....................................................................................................................................115
7.5 MUSHARAKAH FINANCING SPECIFICITIES............................................................................................................116
7.5.1 MUSHARAKAH AGREEMENT SCOPE.............................................................................................................116
7.5.2 PRODUCTS DEFINITION................................................................................................................................116
7.5.3 CUSTOMER APPLICATION, APPROVAL AND VALIDATION............................................................................116
7.5.4 MUSHARAKAH UTILIZATION / DISBURSEMENTS.........................................................................................117
1.1.1 UPDATING PROJECT SPECIFICATIONS..........................................................................................................117
1.1.2 MUSHARAKAH AMENDMENT......................................................................................................................117
7.5.5 REPAYMENT / FOLLOW UP AND MUSHARAKAH SETTLEMENT ‫تصفية‬..........................................................118
7.5.6 MUSHARAKAH SALE / CLOSING...................................................................................................................118
7.5.7 MAIN REPORTS:............................................................................................................................................118

7.6 PARALLEL ISTISNA’A SPECIFICITIES.......................................................................................................................119
7.6.1 PARALLEL ISTISNA’A ORIGINATION..............................................................................................................119
7.6.2 PARALLEL ISTISNA’A DISBURSEMENT:.........................................................................................................119
7.6.3 PARALLEL ISTISNA’A AMENDMENT..............................................................................................................119
7.6.4 PARALLEL ISTISNA’A FOLLOW UP STAGES...................................................................................................119
7.6.5 RECEPTION OF AL MASNUU’........................................................................................................................119
7.7 SALAM / PARALLEL SALAM SPECIFICITIES............................................................................................................120
7.7.1 SALAM ORIGINATION...................................................................................................................................120
7.7.2 SALAM DISBURSEMENT...............................................................................................................................120
7.7.3 SALAM AMENDMENT...................................................................................................................................120
7.7.4 RECEPTION OF AL MUSLAM FIH (SALAM)....................................................................................................120
7.7.5 SALE OF AL MUSLAM FIH ON SPOT..............................................................................................................120
7.7.6 SALAM CANCELLATION................................................................................................................................120
7.7.7 PARALLEL SALAM.........................................................................................................................................120
7.7.8 DELIVERY OF AL MUSLAM FIH (PARALLEL SALAM)......................................................................................121
7.7.9 SALAM REEVALUATION................................................................................................................................121
7.7.10 PARALLEL SALAM DEAL CLOSING (LIQUIDATION)........................................................................................121
7.8 CREDIT CARD FINANCING.....................................................................................................................................121
7.8.1 SCOPE...........................................................................................................................................................121
7.8.2 CREDIT CARDS PRODUCTS DEFINITION........................................................................................................122
7.8.3 CARD APPLICATION AND APPROVAL WORKFLOW......................................................................................122
7.8.4 CARD CHANGE STATUS................................................................................................................................123
7.8.5 CARDS PROCESSING.....................................................................................................................................123
7.8.6 TRANSACTIONS PROCESSING.......................................................................................................................123
7.8.7 PERIODICAL PROCESSING.............................................................................................................................124
7.8.8 CASH BACK MANAGEMENT.........................................................................................................................124
8 INTERNATIONAL MODULES...........................................................................................................125
8.1 FOREIGN EXCHANGE & MONEY MARKET.............................................................................................................125
8.1.1 FOREX OPERATIONS.....................................................................................................................................127
8.1.2 COMMODITY MURABAHA PLACEMENT.......................................................................................................127
8.1.3 CUSTOMERS’ SPECIALIZED / RESTRICTED INVESTMENT..............................................................................127
8.1.4 COMMODITY MURABAHA BORROWING (COUNTERPART DEPOSITS).........................................................128
8.1.5 WAKALAH PLACEMENT................................................................................................................................128
8.1.6 WAKALAH BORROWING...............................................................................................................................128
8.2 OUTWARD TRANSFERS.........................................................................................................................................129
8.2.1 GENERAL PROCEDURE..................................................................................................................................129
8.2.2 POSSIBLE CONFIGURATION WORKFLOW.....................................................................................................130
8.2.3 MAIN FUNCTIONS........................................................................................................................................130
8.2.4 REPORTS AND MESSAGES:...........................................................................................................................131
8.3 INWARD TRANSFERS............................................................................................................................................132

8.3.2 INTERACTIVE FUNCTIONS............................................................................................................................133
8.4 FOREIGN CHECKS REMITTANCES..........................................................................................................................135
8.4.2 MAIN FUNCTIONS........................................................................................................................................136
8.5 IMPORT BILLS FOR COLLECTION...........................................................................................................................137
8.6 EXPORT BILLS FOR COLLECTION...........................................................................................................................139
8.7 IMPORT LETTERS OF CREDIT................................................................................................................................141
8.8 EXPORT LETTERS OF CREDIT.................................................................................................................................144
8.9 LETTERS OF GUARANTEE......................................................................................................................................146
9 CAPITAL MARKET MODULES.........................................................................................................148
9.1 FRONT OFFICE.......................................................................................................................................................148
9.1.1 CUSTOMER POSITION INQUIRY....................................................................................................................148
9.1.2 PLACING AN ORDER.....................................................................................................................................148
9.1.3 ORDER EXECUTION.......................................................................................................................................148
9.1.4 ORDERS FOLLOW UP AND MONITORING....................................................................................................149
9.1.5 CUSTOMER ACKNOWLEDGEMENT..............................................................................................................149
9.1.6 BACK OFFICE.................................................................................................................................................149
9.2 SHARES..................................................................................................................................................................150
9.2.1 FINANCIAL INSTRUMENTS DEFINITION........................................................................................................150
9.2.2 DAILY RATES UPDATE...................................................................................................................................150
9.2.3 MANAGEMENT OF LOCAL STOCK EXCHANGE ORDERS................................................................................150
9.2.4 PURCHASE & SELL.........................................................................................................................................150
9.2.5 SHARES HANDLING MANAGEMENT.............................................................................................................151
9.2.6 END OF DAY PROCESSING............................................................................................................................151
9.3 BONDS / SUKUK....................................................................................................................................................151
9.3.1 BONDS DEFINITION......................................................................................................................................151
9.3.3 PRIMARY MARKET SUBSCRIPTION / EXECUTION.........................................................................................151
9.3.4 PURCHASE & SELL.........................................................................................................................................152
9.3.5 BONDS HANDLING MANAGEMENT..............................................................................................................152
9.4 OPTIONS (IF APPLICABLE).....................................................................................................................................153
9.4.1 CONTRACT DEFINITION................................................................................................................................153
9.4.3 PURCHASE & SELL.........................................................................................................................................153
9.5 FUTURES (IF APPLICABLE).....................................................................................................................................154
9.5.1 CONTRACT DEFINITION................................................................................................................................154

9.5.3 PURCHASE & SELL.........................................................................................................................................154
9.6 WEALTH MANAGEMENT......................................................................................................................................155
9.6.1 STRATEGIES DEFINITION..............................................................................................................................155
9.6.2 STRATEGY PROPOSAL TO CUSTOMER..........................................................................................................155
9.6.3 PORTFOLIO MANAGEMENT.........................................................................................................................156
9.6.4 SPECIFIC REPORTS........................................................................................................................................156
9.7 BACK AND MIDDLE OFFICES REPORTING.............................................................................................................157
10 REAL ESTATE MANAGEMENT........................................................................................................159
10.1 SCOPE...................................................................................................................................................................159
10.2 REAL ESTATE DEFINITION:....................................................................................................................................160
10.3 REQUEST FOR ASSESSMENTS AND ASSIGNMENT OF EXPERT..............................................................................160
10.4 REAL ESTATE INFORMATION UPDATE / PARTITIONING / PRICE REVALUATION..................................................160
10.5 PURCHASING A REAL ESTATE...............................................................................................................................161
10.6 RENTING A REAL ESTATE OR RENTAL RENEWAL..................................................................................................161
10.7 SELLING A REAL ESTATE........................................................................................................................................161
10.8 BATCH PERIODICAL COLLECTION OF RENTS AND SCHEDULED KNOW CHARGES................................................161
10.9 RENTAL TERMINATION.........................................................................................................................................161
10.10 OTHER NON FINANCIAL EVENTS..........................................................................................................................161
11 FUNDS MANAGEMENT.................................................................................................................162
11.1 SCOPE...................................................................................................................................................................162
11.2 FUNDS DEFINITION...............................................................................................................................................163
11.2.1 BASIC INFORMATION...................................................................................................................................163
11.2.2 FEES & CHARGES..........................................................................................................................................163
11.2.3 INVESTMENT STRATEGY/ STRUCTURING.....................................................................................................163
11.3 FUNDS STRATEGY / STRUCTURING UPDATE........................................................................................................163
11.4 CUSTOMERS’ SUBSCRIPTION/PARTICIPATION, REDEMPTION AND JOINING......................................................163
11.5 BANK’S SUBSCRIPTION/PARTICIPATION AND REDEMPTION...............................................................................164
11.6 FUNDS TRANSACTIONS / INVESTMENTS..............................................................................................................164
11.7 PERIODICAL FEES DEDUCTION (IF APPLICABLE)...................................................................................................164
11.8 REVALUATION AND PROFIT DISTRIBUTION..........................................................................................................164
11.9 FUND SETTLEMENT OR LIQUIDATION..................................................................................................................165

1 FOREWORD
ICBS Islamic: (Integrated Computerized Banking System – Islamic Edition) is a comprehensive completely
Integrated Islamic Banking System totally designed and developed by BML Istisharat SAL to handle,
manage and control Islamic Financial Institutions front & back office operations.
ICBS Islamic: is a customer centric business oriented software application comprehensively covering Islamic
Banks various activities including:
 Islamic Retail Banking: Current, Checking, Islamic Deposits (Saving, Call Notice, Term deposit),
Checkbooks / Stopped checks, Checks Remittances and Clearing, Collection and Settlements,
Draft and Cahiers Checks, Certified checks, Travelers checks, Bills, Islamic Retail and Consumers
financing (Murabaha, Ijarah, Tawarruq, Social Loan, Al Qard Al Hasan), Utility bills payments, Bulk
transactions, Standing orders, Signatures verification.
 Islamic Corporate Banking: Including Credit Facilities, Islamic Commercial Financing
(Murabaha, Ijarah, Tawarruq, Istisna'a, Istisna'a Muwazi, Mudarabah, Musharakah, Salam, Salam
Muwazi), Trade Finance (Letters of Credit, Murabaha under L/C, Letters of guarantee and Bills for
collections).
 Islamic Treasury system: Foreign Exchange and Money market (Commodity Murabaha and
reverse Murabaha, Wakalah placements and deposits, Specialized and Restricted Investments).
 Islamic Investment and Capital Market: Securities (Shares, Bonds / Sukuk) and derivatives,
Investment in Real Estate, Portfolio and Fund management.
 International Payments and Remittances: Inward and Outward transfers.
 Integrated Comprehensive customers’ information system and proven accounting (Payables /
Receivables) and General Ledger System.
 MIS, Financial and Statutory / Central Bank reporting.
 Interfaces with delivery channels (Credit / Debit cards, ATM /POS, Swift, e-banking, IVR/Phone
Banking, mobile banking, SMS banking, Reuters, Payment systems: ACH and RTGS, Electronic
Checks Clearing solutions, etc).
ICBS Islamic is conceived in accordance with Islamic “Sharia’s” Rules and Laws rather than twirling
conventional banking system. ICBS Islamic allows banks offering “Financing and Investments techniques”
based on Partnership and Sharing of Trading Generated Profits,
Functionally, ICBS is the result of thirty two years of ongoing close cooperation between leading bankers
and BML Istisharat Banking Group engineers. This permanent cooperation allows BML Istisharat to
constantly add new features and modules in order to meet challenging and continuously evolving markets
demands.
Today, ICBS is widely adopted by the financial community. A large number of Institutions acquired totally
or partially ICBS in Paris (France), London (U.K.), Geneva and Zurich (Switzerland), Nicosia and Limassol
(Cyprus), Kuala Lumpur (Malaysia), Jeddah / Riyadh (Saudi Arabia), Kuwait (Kuwait), Amman (Jordan), Dubai
/ Sharjah (U.A.E.), Doha (Qatar), Muscat (Oman), Nouakchott (Mauritania), Casablanca and Rabat
(Morocco), Moscow (Russia), Baghdad, Erbil, Mosul (Iraq), Damascus (Syria), Sana’a (Yemen) and Beirut
(Lebanon), thus making it a best seller. This outstanding market acceptability is a clear indicator of the
capability of ICBS to meet a wide scope of the market requirements.
Technically, ICBS constantly updated to new industry trends using latest technology. BML Istisharat
research and development experienced, continuously trained team insure that ICBS modules are available
on up to date state of the art multi-tiers web enabled platforms.
ICBS Internet layer (e-ICBS) provides the financial institution customers with Home Banking transactions
and query facilities (for more details, please refer to e-ICBS capabilities guide.
NB: Enhancements are periodically made to the information herein. Any such enhancements will be
reported in subsequent revisions.

1.1 ICBS Strength Points

ICBS Banking Solution offers the following characteristics:
 Secure, proven, real time on-line, 24x7, completely integrated, multi-lingual, multi-currency, multi-
entities, user friendly and menu driven with a fully standardized GUI to improve Bank’s staff
productivity and reduce human intervention and errors.
 Flexible, evolving, fully parameterized and easily customizable in order to cover the bank’s actual and
future requirements thus facilitating introduction of innovative products and business processes
meeting challenging and continuously evolving markets demands while reducing time to market.
 Efficient and offering business process automation capabilities with default values based on user’s
defined standard business rules and particular conditions to streamline processes, reduce paper works,
redundancy and operation cost.
 Aligned to the international accounting standards and meeting the local specifications to insure
compliance with both International (IAS and IFRS) and Local regulations.
 Islamic modules conceived in accordance with Islamic “Sharia’s” Rules and Laws rather than twirling
conventional banking system to insure offering fully compliant Islamic products and in accordance with
accounting and auditing (AAOIFI) standards.
 International modules designed and continuously enhanced in accordance with prevailing regulations
generate and interpret / process financial messages including SWIFT formats.
 Comprehensive customers' information system offering global views with drill down to details:
 Offering complete and well informing customers’ view.
 Empowering effective customers’ relationships management and cross-sell opportunities.
 Increasing customers’ services and satisfaction
 Easing operations control and risk management monitoring.
 Rich set of reports while providing openness for third parties report generators with easy-to-use query
and reporting facilities.
 Standard set of APIs and web services for third party products integration in on line mode (Through
SOAP/XML, Third Party Middleware or Direct interaction) or batch transfers to service customers across
several delivery channels.
 Full audit trails logging user’s interaction with the system and storing data that could be used for
performance measurement and recognition.
 Based on modern Web enabled Multi-tiers technology Architecture, with Oracle Database Server and
Oracle Application Server ensuring:
a) High availability and proven scalability to meet expected growth and expansions.
b) Accurate transaction processing, record keeping, information retrieval and reporting.
c) Portability to a large number of operating systems: UNIX, LINUX and Microsoft Windows.
d) Deployment on wide range of hardware platform including high-end SMP environments.
e) Ease of integration with third parties applications and multiple delivery channels.
f) Unique capabilities to ensure availability of mission critical applications. Oracle Real Application
Clusters (RAC) supports the transparent deployment of a single database across a cluster of
hardware servers, providing fault tolerance from hardware failures or planned outages.
g) Proven Data Guard technology to protect from crippling events such as a power outage or natural
disaster. Set up and automatically maintain multiple remote standby copies of production
databases.
h) Industry leading security features such as fine grained/row level security, column security, fine-
grained auditing, data encryption, key management, proxy authentication, application context and
secure application roles. In addition to commonplace security features such as auditing, password
complexity checks, database roles, stored procedures and functions.
i) Low Total Cost of Ownership associated with deploying and operating.

1.2 ICBS Modules Diagram

ICBS is offered as a set of integrated modules allowing Banks to acquire only the required functionality with
the possibility to implement the remaining modules when necessary.
ICBS modules are all articulated around the Core Nucleus. Once this backbone of ICBS implemented, any
other module or sub-system can be added simply and smoothly stage by stage, on the basis of user
requirements and time and personnel availability. ICBS Nucleus consists of: Encapsulating Security features,
Referential and Parameters tables, Business rules setting tools, Central Customers’ information system,
Accounting system, A set of Engines including: Accounting entries generator, Advice and documents
generators, commissions and Charges calculator.
Moreover, ICBS operational modules can integrates easily with third parties applications and systems.
Schematically, the main modules of ICBS modules can be represented as follows:
ICBS Islamic provides configurable modules allowing the Bank offering wide range of products including:


2 ICBS SELECTED REFERENCES
CITIBANK PARIS
BPRNP (BANQUE POPULAIRE Group) PARIS
BLOM BANK PARIS
BLOM BANK LONDON
BLOM BANK BUCHAREST
APS Bank Ltd VALLETTA
BCM PARIS
LIMMAT INVESTMENT AG ZURICH
CARNI SA GENEVA
SOCIETE GENERALE PRIVATE BANKING (BELGIUM) GENT
VOSTOK BANK MOSCOW
PICTET (Canada) MONTREAL
IBL BANK – CYPRUS LIMASSOL
CREDIT LIBANAIS LIMASSOL
BSN BANK (**) KUALA LUMPUR
COMMERCIAL BANK OF KUWAIT KUWAIT
CAPIVEST (*) MANAMA
MASRAF AL RAYAN (*) DOHA
BLOM BANK – QATAR (**) DOHA
BLOM BANK (**) DUBAI
BLOM BANK (**) SHARJAH
INVEST BANK PSC (SHARJAH) SHARJAH
UNITED SAUDI BANK RIYADH
SAUDI CAIRO BANK JEDDAH
NATIONAL COMMERCIAL BANK JEDDAH
BANK OF JORDAN (**) AMMAN
JORDAN ISLAMIC BANK (*) AMMAN
SOCIETE GENERALE – JORDAN (SGBJ) AMMAN
CAIRO AMMAN BANK (**) AMMAN
SOMAFIC (AXA Group) CASABLANCA
CAISSE DE DEPOTS ET DE GESTION (CDG) RABAT
INTERNATIONAL BANK OF SOMALIA (IBS) (*) MOGADISHU
OMAN DEVELOPMENT BANK MUSCAT
UNION DES BANQUES DE DEVELOPPEMENT NOUAKCHOTT
BANK OF SYRIA AND OVERSEAS (BLOM BANK) DAMASCUS
BANK OF JORDAN – SYRIA DAMASCUS
YEMEN GULF BANK SANA’A
CENTRAL BANK OF IRAQ BAGHDAD
UNION BANK OF IRAQ BAGHDAD

NATIONAL BANK OF IRAQ BAGHDAD
ECONOMY BANK FOR INVESTMENT & FINANCE BAGHDAD
MIDDLE EAST AND AFRICA BANK BAGHDAD
MINARE BANK ERBIL
BANK OF ERBIL FOR INVESTMENT & FINANCE ERBIL
IBL BANK ERBIL
MOSUL BANK FOR DEVELOPMENT & INVESTMENT MOSUL
BANK OF LEBANON (CENTRAL BANK) BEIRUT
SOCIETE GENERALE – LEBANON (SGBL) BEIRUT
BANQUE NATIONALE DE PARIS (INTERCONTINENTALE) BEIRUT
EMIRATES LEBANON BANK BEIRUT
CREDIT LIBANAIS BEIRUT
CREDIT BANK BEIRUT
IBL BANK BEIRUT
IBL INVEST BEIRUT
SAUDI NATIONAL COMMERCIAL BANK (**) BEIRUT
MIDDLE EAST & AFRICA BANK BEIRUT
CREDIT COMMERCIAL DE FRANCE BEIRUT
ARAB BANK BEIRUT
ARAB INVESTMENT BANK BEIRUT
BLOM DEVELOPMENT BANK (*) BEIRUT
INVEST BANK PSC (SHARJAH) BEIRUT
LEVANT INVESTMENT BANK (LIBANK) BEIRUT
GAZPROMBANK – INVEST (LEBANON) BEIRUT
BANQUE LIBANO FRANCAISE (BLF)
BLF – FINANCE (BANQUE LIBANO FRANCAISE) BEIRUT
BLC BANK BEIRUT
BLC INVEST BEIRUT
FRANSA INVESTMENT BANK (FRANSABANK) BEIRUT
LEBANESE LEASING COMPANY (**) BEIRUT
AL MAWARID BANK BEIRUT
FNB BANK BEIRUT
MIDDLE EAST CAPITAL GROUP (FNB BANK) BEIRUT
AHLI INVESTMENT GROUP (AL AHLI BANK) BEIRUT
AMWAL INVEST HOLDING BEIRUT
ARAB FINANCE CORPORATION BEIRUT
FIDUS - SOCIETE GENERALE BEIRUT
CAPITAL FINANCE COMPANY (**) BEIRUT
OPTIMUM INVEST BEIRUT
LEVANTUM INVEST BEIRUT
CAPITAL INVESTMENT CORPORATION BEIRUT
MENA INVEST SAL BEIRUT
EXCILLIS FINANCE BEIRUT

SAUDI LEBANESE FINANCIAL INVESTMENT BEIRUT
GULF FINANCE & INVESTMENT HOLDING BEIRUT
(*) Full Islamic Bank ETC…
(**) Islamic Windows

3 ICBS SUBDIVISION INTO MODULES

ICBS Nucleus
Nucleus - Parameters and engines
1- Security & Log-on,
2- System Tables & Parameters
3- Accounting Engine
4- Advice generator engine
Nucleus - Customers & Accounts
1- Customers information system
2- Customers & Banks accounts
3- General ledger accounts
Nucleus - General Batch Processing (End of Day, End of Month, End of Year)
Central Modules
1- Credit Facilities Management
2- Islamic Profit Sharing and Distribution (Saving & Call Notice Accounts)
3- Islamic Profit Sharing and Distribution (Term Accounts)
4- Local Authorities requirements
5- General Batch Processing (Reconciliation, Consolidation, Revaluation).
6- Statistics and MIS
Branch Modules
1- Customized Operations Engine
2- Checkbooks & Clearing Checks Handling
3- Post dated checks
4- Traveler's checks
5- Draft checks (Banker’s checks)
6- Standing Instructions
7- Bills management
8- Multiple transfers & Utility bills payments
Financing Modules
1- Consumer (Murabaha, Ijarah, Tawarruq, Social Loan, Al Qard Al Hassan)
2- Corporate (Murabaha, Ijarah, Ijarah Wa Iqtena, Tawarruq,) Istisna'a, Istisna'a Muwazi
3- Salam, Parallel Salam
4- Mudarabah, Musharakah
5- Syndicated Financing

Foreign Exchange & Money Market
1- Foreign Exchange: Spot, Forward, Swap
2- Money Market: Placement and Deposits (Commodity Murabaha, Wakalah, Specialized
Investment, Restricted Investment)
International Payments / Remittances
1- Inward / Outward Transfers (Remittances)
2- Foreign Checks Remittances
Trade Finance
1- Import Letters of Credit
2- Export Letters of Credit
3- Letters of Guarantee
4- Import/Export Bills for Collection
Securities (Capital Market)
1- Shares
2- Sukuk (Bonds)
3- Options
4- Futures
5- Front Office Capital Markets
6-Wealth Management
7- Real Estate Management
8-Funds Management
Interfaces
1. SWIFT Interface
2. ATM / CDM/ POS and Card Management Interfaces (CMI)
3. MICR checks and Electronic Checks Clearing (ECC) solutions Interfaces
4. Phone Banking (IVR), SMS and e-Banking Interfaces
5. RTGS and ACH solutions interfaces
6. Interface with fingerprint solutions

4 ICBS NUCLEUS AND STANDARD FEATURES

4.1 Integration and Efficiency
A great concern was given to these features and the result is a fully integrated system.
All ICBS modules are:
• Fully Web Enabled - Available on the Same Platform
• Abide by the same standards
• Share a common centric database
• Use the same Engines and business rules setting tools for :
 Commission and charges calculation
 Value date calculation
 Accounting entries
 Receipts, contracts / Schedules
ICBS Full Integration ensures:
• High flexibility allowing the bank easily distributing roles (Centralized / Decentralized processing
approach) and accesses according to internal policies and procedures. Moving a function from the
front office to the back office or vice versa being only a matter of configuration.
• Streamline operation processing and user’s time optimization through:
o Default values automated generation based on standard rules and customers’ possible
granted privileges.
o Automatic generation of Accounting entries, SWIFT messages, Payment / Settlement
messages and advises. No data capture redundancy.
• Centric Customers Information with 360 o Customer's View and consolidated Information for
dashboards.
• Data integrity, High Availability and Ease of Disaster Recovery.
• On line real time transactions and queries bank wide (i.e. including inter branch and delivery
channels transactions) throughout all customers’ activity.
For example: for each transaction on a client's account, system automatically and based and Bank’s defined
business rules and parameters:
 Generates default commissions, fees and value date
 Generates references including unique accounting reference, operation/document
references.
 Generates required accounting entries
 Generates customer receipts, documents and possible passbooks
 Generates required payments / settlement messages (including SWIFT, Fedwire, ACH,
RTGS.)
 Updates client's accounts balances and possible credit limits
 Updates possible checks statuses and registry
 Updates Possible Cash and other general ledger accounts balances
 Updates possible registry and master tables

 Updates possible positions (including foreign exchange, treasury)
 Updates Bank’s possible set limits utilization (Including Counterpart, Currency, Country,
Product)
 Updates users possible daily / monthly allowed excess limits
 Updates audit trail tables
 Updates official statement of account
 Updates client's statistical data (including number of movements year-to- date and during
the month, highest, lowest and average balances, total movements debit and credit , number of
days the account is in excess of authorized facility, total commissions earned by nature of
operation, volume of F/X transactions)
 Updates archives.
4.2 Interactivity and Ease of Operation through Standard GUI

ICBS is a user-friendly system, designed with a multilingual Standard Graphical User Interface (GUI - Web)
with consistent look and feel across all modules. End users easily operate the system. Even at
administration levels no need for highly skilled people. Neither previous knowledge of computer languages
nor technical experiences are required. Users interact with ICBS through:
 A completely user defined multilingual dynamic configurable menu-driven system.
 User friendly navigation and interaction through:
o Mouse clicks or Keyboard keys having the same meaning throughout the system
o Toolbars, combo boxes, dynamic lists, radio groups, button and other GUI widget.
 A dialogue type of validation at data capture / form filling level assisted by:
o “Help” features and selection from pop up lists of values / drop down lists without having
to remember codes and values.
o Indication and Enforcement of mandatory fields, On line field validation and controls
preventing users errors
o Context sensitive multi criteria case sensitive queries with wild cards / partial field filling,
comparative conditions (Boolean Search).
o Bank defined multilingual screen labels.
o Context sensitive Bank defined clear error, warning and confirmation messages.
 Comprehensive inquiring facilities at any time and any level offering global views with drill down to
details.
ICBS is an easy-to-understand, easy-to-use numbering system: Customers accounts format is user defined
so accounts can be immediately identified by reading the self explanatory account number.

4.3 On Line Real Time 24x7

4.3.1 On Line Real Time
Interactive Transactions, whether hitting local branch accounts or inter branch accounts, are processed in
on-line real time mode. Upon user confirmation (or supervisor validation in accordance with Bank’s defines
business rules), balances, positions and all possible related limits utilization are immediately checked and
updated.
4.3.2 Real Time 24 x 7 Mechanism

4.3.2.1 Definitions
System handles for each and every account a set of fields reflecting:
 “Transactions of the day balance”: Updated in real-time on-line mode
 “Closed balance” : Account’s balance as at last End Of Day
 “Available balance” being at any moment equal to the sum of “Closed Balance” + “Transactions of
the day balance” thus providing “On Line, Real Time Available Balance”.
 Operation Date 1: applied to User’s / Customer’s Initiated transactions
 Operation Date 2: applied to End OF Day Batches processed
 Transaction Value Date according to Bank’s business rules.
 “Balances by Value Date” are maintained as well.
4.3.2.2 Measures before Launching End of Day process

 Prior to launching End of Day procedures, a process increments “Operation Date 1”. (Used for
User’s / Customer’s Initiated transactions)
 Starting this moment any operation triggered by the customers through any delivery channel will
have its operation date equal to the incremented one.
4.3.2.3 Mechanism during End Of Day Process

 All batch procedures are conceived to prevent any bulk locking of records. For Instance each
account is processed separately without locking a range or type of accounts.
 For each transaction being handled by the End of day process, system deducts it from the
“Transactions of The Day” Balance and applies it to the “Closed Balance”. This ensures a continuous
On line Real time “Available Balance” which is, as introduced above, is the sum of “Closed
Balance” + “Transactions of the day”
 End of day process tickles transactions with dates up to Operation date 2.
 Customers’ transactions initiated during the end of day (such as e-banking and ATM. and having
the already incremented Operation Date 1 as operation date) will be checked against the “Available
Balance” and will not be considered by the ongoing end of day process.
 New Transactions generated by End of Day process takes as operation date “Operation Date 2”
which is still not incremented at this level. These transactions do not need to update the
Transactions of the day” balance at this level (i.e. during End of Day process).
4.3.2.4 After End of Day:

Operation date 2 is incremented in anticipation to next end of day.

4.4 Multilingual
ICBS offers multilingual Forms and Reports. Screens are prompted according to Teller language selection.
Receipts and Documents are printed in customers preferred language. ICBS supports also right to left
languages. Screen labels (prompts) are user defined: This means that authorized users can amend the
labels of the screens fields. Moreover authorized users can define new labels in additional languages and
make it available to users.
On the other hand, system handles simultaneously two data field languages for the codes and parameters
tables as well as for the customers’ database. (i.e. upon implementation the bank would select a data basic
language and a data secondary language. The codes and parameters as well as the customer information
would be entered in both languages).
Right to left Languages (such as Arabic) are provided as native language.
4.5 Security & Transactions Control

Security is a major concern of Bank Management and greatest attention was given to this feature to ensure
it at all levels.
4.5.1 Group and users profiles

ICBS handles multilevel configurable groups and users profiles / roles offering personalized menus and
ensuring that users perform only allowed operations within authorized limits. This feature allows Security
Officer to define “Group Profiles” and attach users to already defined “Group Profile”. This avoids
redundant capture effort and data upon users’ definition.
For example, the security officer may define for example:
 Tellers profile
 Supervisors profile
 Assistant Branch Managers profile
 Branch Managers profile
 Dealers profile
 Security Office profile
 Administrator Profile
Group profile definition includes “Accesses rights” and “Modes” to the system’s functions (query, add,
update, delete and other possible critical actions) as well as operational limits: General operation limits,
Cash limits, Ability to override and authorize exceptions / excesses on credit lines, ability to approve
accidentally debtor accounts, Daily and Monthly limits, Specific limits on products and G/L accounts,
Compliance limits, Limits on inter branch operations.
Once Group Profiles are defined, Security Officer will assign each user to the adequate group and user will
automatically inherit the respective group authorizations and limits.
In addition Security Officer may:
 Defines specific information pertaining to the user such as: Username, Profile validity dates,
Password validly, A set of attributes pertaining to levels and hierarchy (secrecy level, ability to
access confidential accounts, ability to override default values level), Preferred language, Branch,
Department, Reporting to supervisors (direct supervisor, replacing supervisor, compliance
manager), Allowed range of IPs, Allowed number of simultaneous opened sessions, Possibility to
log to different workstations simultaneously, Default printer.
 Revoke / grant authorization accesses from/to the user. This means that at user level, the Security
Officer can change user ability to access the various functions, the access mode to each function
as well as the limits defined at group level.

In order to prevent backdoors access, passwords are encrypted based on standard practice algorithms and
on Bank’s defined encryption keys. Users will be requested to modify their password at first usage and
periodically through dedicated functions. Passwords are case sensitive and should abide by a number of
configurable best practices complexity conditions including:
a) Minimum password length (Bank defined)
b) Mandatory number of Alphabetic and Numeric Characters (Bank defined)
c) Different then user’s name
d) Old passwords not accepted
4.5.2 Users Authentication and Login

Menu access is subject to successful login using valid username and password (with optional fingerprint
verification).
System provides a set of controls to prevent logins during closing hours. Branches users will be allowed to
login only after branch opening and will not be allowed to perform transactions prior to session opening.
After session closing users will be able only to query and produce reports;
Unsuccessful attempts to login are recorded and reported. User would be deactivated after a number of
unsuccessful consecutive attempts,
Each user, and based on his defined profile, will be prompted with a personalized menu browsing only the
functions he is allowed to access. Navigations through menu and functions and accesses mode are also
subject to granted authorizations.
User’s session is subject to timeout to prevent unauthorized access of unattended workstations.
Integration with HR systems allows setting users to inactive status thus preventing accesses during users’
leave / absence.
4.5.3 Audit Trail

Audit Trails: Users’ interactions, accesses, updates and possible reversals are recorded into journals
providing full audit trails including:
o Users logging and navigation through the menus
o Updates on data information
o Exceptions and possible overrides / authorization
Logs are stored centrally in dedicated tables.
Recorded information includes:
o Stamps: User ID, Node ID/ IP address, Date and Time Stamps and Nature of interaction.
o In addition for data update: Updating program and updated data (for amendments system
records as well image before and after modification).
o In addition for validation / exceptions and supervisors limits overrides: Validation and /or
exception details, Manager’s ID, Node ID/ IP address, Date and Time Stamps, manager’s action /
decision (acceptance / rejection), comments and related details.
o Possible System logs failure
Audit trail tables can be accessed, by authorized users / security officers, through multi-criteria interactive
screens and reports for the purpose of query, reporting and investigations.
Security officer / authorized administrators are granted with tools to:
o Archive to a secondary database audit tables data after a Bank defined period

o Suspend / Resume auditing of no critical data interactions the Bank may judge as not required.
4.5.4 Data integrity:

Updating procedure was basically designed to provide maximum data integrity and easy recovery in case of
failure without risky interventions. Data base updating is controlled by “Commit/Rollback” cycles which
assures that in case of failure during data capture, loss will be limited to the last transaction in the worst
case. Moreover, the “Commit/Rollback” cycles warrantee that no partial transaction can be taken into
consideration (either the whole transaction is accepted or rejected).
In addition, ICBS is built on the top of Oracle RDBMS that provide:
 Unique capabilities to ensure availability of mission critical applications. Oracle Real Application
Clusters (RAC) supports the transparent deployment of a single database across a cluster of
hardware servers, providing fault tolerance from hardware failures or planned outages.
 Proven Data Guard technology to protect from crippling events such as a power outage or natural
disaster. Set up and automatically maintain multiple remote standby copies of production
databases.
 Industry leading security features such as fine grained/row level security, column security, fine-
grained auditing, data encryption, key management, proxy authentication, application context and
secure application roles. In addition to commonplace security features such as auditing, password
complexity checks, database roles, stored procedures and functions.
4.5.5 Transactions, control and validation

4.5.5.1 On-line Interactive transactions, control and validation
Programs check for validity and consistency of information before recording.
Critical operations are subject to maker and checker concept allowing manager validation before effective
posting, processing, cancellation or reversal. Operation not yet submitted for validation can be updated or
completed by the initiator.
Also all exceptions which are not binding to applicable standards are reported for multi level approval (see
next section).
During operation capture system triggers on line control verifying data consistency, validity including cross
field validation. For illustration purposes, we are listing hereafter a set of controls that we have selected for
a comprehensive list of on line validation:
 Operation Dates and Value dates
 Applied rates of commission by nature of operation,
 Profit Rates on clients accounts,
 Users’ operation limits (operation amount, override of default values)
 Customers Accounts status (Blocked, Dormant, Forbidden from with drawl or the like), referrals and
conditions,
 Checks status (Stopped, already used, not yet allocated, destroyed.)
 Customers balances in excess of authorized facilities,
 Customers possible granted Credit lines (percentage and max amount)and facilities limits; Balances
accidentally debtor,
 Compliance and AML limits; Global defined limits such as counterparts’ limits, currencies limits,
foreign exchange limits, country limits and products limits.
 Preset restrictions (including currency, branch, user, Product / Type of accounts, Cash limits, and
general ledger).
 Black lists alert
 Warnings and Annotations (Flashing messages) pop-up in interactive mode:
o Warning message/invitation for a required action
o Supervisor validation

o Blocking.

System provides tools for identity, signature and fingerprint verification along with respective authorized
amount and combination of signatures.
Each accounting transaction should be balanced (total debits = total credits globally and for each currency)
thus ensuring that each accounting transactions would at least 2 accounting entries leg for each involved
currency.
Authorized manager cancellations during the same day are recorded in dedicated audit tables and checked
on daily basis. Authorized Reversals whether the same day or during next days are performed based on the
initial operation accounting information and posted to accounting journals, the corresponding debit and
credit entries are reversed with same value date and entries details.
Context sensitive Bank defined clear error, warning and confirmation messages are prompted for user’s
appropriate action, confirmation, cancelation or possible escalation. Authorized user may decide to hold an
amount / post reservation on a part or the whole account balance. Reservation posting abides by the same
validation processing and control as for debit operation.
4.5.5.2 Batch Control and Anomalies Reporting
ICBS Provides automated configurable end of period batch procedures that abides by the set business rules
and conditions.
Processing indicators and references check for and prevent duplicate execution.
During batch processing anomalies are logged for further interventions.
4.5.6 Escalations and Exception Management

4.5.6.1 At Initiator level
Excess of facilities / exceptions and operations subject to validation are reported electronically to
appropriate managers for approval / rejection.
In accordance with the Bank’s defined policy and in case of exception occurrence (on local branch or
remote inter branch customer balances or credit lines excess, AML / compliance limits excess, value date
modification outside authorized range, commissions / charges modification outside authorized range,
account referral or any other Bank’s defined limit.) user is prompted with clear message inviting him to
perform one of the following:
ㄱ Option 1: Refuse (and therefore cancel) the transaction
ㄴ Option 2: Resume the transaction if he is authorized to (i.e. his corresponding limit allows him
to process such overdraw).
ㄷ Option 3: Submit the transaction to appropriate supervisor/manager asking him to check and
revert. Whereby the Appropriate supervisor / manager is identified by the system according to
criteria, for instance :
o In case the exception is due to an excess of the user’s transaction limit, message is routed to
the user’s supervisor (or replacing supervisor if this latter is not logged in).
o In case the exception is due to Customer’s account’ status, available funds, annotation,
stopped check or the like; the message will be routed to the account manager or “Group
Officers” defined at customer’s level. The account manager can be in the same branch or in a
different remote branch.
o In case of compliance issue, the message will be routed to the compliance manager.
In case of option 3, user screen will be freed and be able to process new transactions while waiting
for manager authorization / feedback.

4.5.6.2 Transaction Submitted to Appropriate Manager for Approval
When user submits a transaction to this manager, a notification message is flashed on the manager’s
screen asking him to intervene. Manager will browse transactions waiting for his decision. In case referred
to manager is not connected message will be automatically routed to the replacing supervisor. In case
both the supervisor‘s and replacing supervisor desks are signed-off, message will be routed to the
supervisor’s manager and so forth.
Designated manager (or the user’s supervisor) will inquire about the interrupted transactions sent to him
for approval. At this level, manager will be able to:
 Examine further the customer’s situation. He may inquire about the customer’s global position,
select all customer accounts, drill down to accounts details including: transactions and history,
statistical information, standing orders.
 And, perform one of the following:
1. Validate the transaction and automatically send a message informing the initiating user that he
is requested to resume transaction.
2. Reject the transaction and automatically send a message informing the initiating user that he
is requested to refuse the transaction.
3. Escalate the transaction to his hierarchical manager in case the decision to be taken is beyond
his authority. (Higher level for retail and transaction limit related exceptions; Officer’s direct
manager for corporate customers’ exception). Escalated to manager can be in the same
branch, in a different remote site or at the head office.
4.5.6.3 Transaction back to user
As mentioned earlier, user will be informed about his manager decision and therefore, in case of approval,
he will be able to resume the transaction without any loss of captured data. In fact user may only execute
the manager decision (to validate or to refuse).
4.5.6.4 Transaction logging
In all cases approved or rejected exceptions are all logged with the related details and manager’s decision
for further reporting, query and investigations.
4.6 Flexibility & Expandability

4.6.1 Configurable Menus
Menus are customizable by the system administrator to meet the bank requirements in term of menus
contents and hierarchy. When building the global menu, system administrator is in fact building the global
tree with the required nodes, sub-nodes and leafs. Each user will be browsed with the menus’ elements he
is allowed to access starting with a sub-menu. This facility provides an extended personalization tool.
4.6.2 Configurable Screens and Reports Labels

Prompts are user defined. This means that authorized users can amend the labels of the screens’ and
reports fields. Moreover authorized users can define new labels in additional languages and make it
available to users. This is possible since ICBS allows defining several labels (one in each language) to each
screen and report field. Whenever a user logs into the system, he will be prompted with screens labels
according to his language. Of course this requires that the related language labels be already defined.
4.6.3 Configurable Error Messages

Authorized users can also modify error messages texts. Similarly to screen labels it can be available in
several languages. Each error message is provided with a predefined code. Therefore, system administrator
will be able to change the message’s description in an already defined language or define it in a new
language by selecting the appropriate language and message codes.

4.6.4 Configurable Profiles

Please refer to above section “Groups and Users profiles configuration”.
4.6.5 Codes, Parameters and Pricing tables

ICBS depends extensively on codes and parameters and consequently is very flexible: when a element is
needed it is only required to introduce it as a new value in its table along with possible attributes, and it
becomes available to the system: any reference to it is validated through control of existence in the codes
& parameters database. For illustration purposes we are stating some of a comprehensive set of tables:
4.6.5.1 Examples of Common Simple Codes Tables
System tables, Branches, Currencies, Currencies rates by region, Holidays by currency, Countries, Regions,
Nationalities, Personal title code, Economic sectors, Customers types, Customers’ relation types, Customers
segments, Months names, Segments, Strategy, AML standard limits by segments.
4.6.5.2 Examples of More Advanced Codes Tables
Chart of accounts, Products, Accounts Conditions, Calculation Methods, Profit Rates, Commission
conditions, Value dates conditions, Cost Centers, Business rules parameters, Accounting transactions
parameters.
4.6.6 Configurable Products Business Rules

Each customer account is attached to a “Product”. Most of the business rules and conditions are defined at
the product level so it will be inherited by the customer’s account upon opening. The following sub sections
highlight the main parameters allowing Banks to define and configure required products in accordance with
its business rules. As part of a general concept, system allows:
 Attaching product to a General Ledger: Each product of customers’ accounts is related to a chart of
account element so any transaction hitting the customer account will be reflected to the
corresponding Nominative General Ledger account. For example, and when building the chart of
accounts and the types of accounts tables, we would have relation similar to the following:
Product (Type of accounts): 180 “Current Accounts”; Related to:
General ledger accounts: 461100 180 “Customers Current Accounts”.
 Attaching products to rates tables and conditions (for instance Islamic products Profit rates,
Commissions, fees and charge rates, Taxes rate) rather than capturing the rate at product or at
account level and this in order to offer the possibility of:
 Applying global periodical and upon request rates changes by amending the standard rates
defined by rate code, currency, application date and when applicable by tiers of amounts and
maturity tenor
 Centralizing, monitoring and inquiring about rates to be applied
 Setting Standard conditions for each combination of Product, Currency and Nature of customers.
For instance Bank would be configuring the following accounts products for:
Non profit sharing accounts ‫حسابات االئتمان‬
Current accounts ‫حسابات جارية‬
Sight accounts ‫حسابات ودائع تحت الطلب‬
Profit sharing accounts ‫حسابات االستثمار المشترك‬
Saving accounts ‫حسابات توفير‬
Notice accounts ‫حسابات تحت إشعار‬
Term deposit accounts ‫حسابات ألجل المستمر‬

Special Investments accounts ‫حسابات استثمار مخصص‬

 For each product the Bank would define conditions pertaining:
Purposes / Utilization ‫وجهة االستعمال‬

Possible currencies ‫عمالت مسموحة‬
Checkbook allowed ‫دفاتر شيكات مسموحة‬
Passbook existence ‫وجود دفتر‬
General Conditions (see note 1) ‫شروط‬
Profit calculation mode ‫طريقة احتساب األرباح‬
Profit distribution and availability ‫طريقة توزيع األرباح‬
Subject to expenses and charges ‫لنفقــات ومصاريف تخضع‬
Statement of accounts ‫كشوفات دورية‬
4.6.7 Configurable Islamic Accounting Products

4.6.7.1 Sharia Compliant Product Types examples:
System Administrator or Product Manager may define the required accounting products along with the
standard conditions. For instance he may define for example:
 Islamic Current, Call, Checking and Corporate accounts,
 Restricted and Unrestricted profit Sharing Accounts (Mudarabah Deposits):
o Islamic Saving Accounts, Kids and Students saving Account, etc.
o Islamic Term Accounts and Term Deposit
 Investment accounts
 Financing accounts: Murabaha, Musharakah, Mudarabah, Istisna’a accounts,
 Off balance sheet, etc.
Sharia compliant Islamic Accounts configuration / business rules setting the following:
• Islamic Pool Management for Profit Calculation and Distribution parameters and conditions:
• Subject to Profit or Not,
• Sharia compliant profit calculation, simulation and distribution conditions
• Product Participations %,
• Profit Equalization Reserve (PER)%,
• Mudarib fees % and Participants Shares%,
• Risk provision,
• Taxes.
• Calculation and Distribution Periodicities,
• Participating balance: Minimum, Average, Daily
• Minimum participation balance / Transactions
• Withdrawal / Closing Conditions, Etc.

• Other conditions by product: Rollout, Charges, Commissions, Check books, Passbooks, Behavior in
case of excess of limits / minimum balances, Dormancy rules, Zakat deduction and other conditions
highlighted hereafter.

4.6.7.2 Product’s General Main Conditions:

 Product Code
 Product Description and short Description
 Product Nature / Type
 Allowed currencies
 Allowed Branches
 Eligibility criteria such as:
o Allowed Customers Natures / Segments (for example: Individual – Standard, Individual
– Staff, Individual – Student, Individual – Orphan, Company, Government, Ministry.
Etc.)
o Age range, Nationality, Residence, Not black listed, Allowed Customer’s status
 Profit Sharing indicator
 Participation in lottery / draw system
 Statement conditions and periodicity
 Issue customers documents: Welcome letter, Product / Account conditions, Passbooks,
Certificate of Deposits, etc.
 Transaction Maker / Checker Validation conditions (Always on Debit, Always on Credit, Always,
Only in case of limits excess)
 Allowed delivery channels (Branches, ATM, CDM, POS, IVR, E-Banking, SMS, WAP, etc.)
 Subject to Particular Conditions at account level
 Subject to Standing instructions indicator
 Duration Historical is data kept on production database
 Auto Open Indicator
 Passbook Indicator
 Checkbook Indicator
 Certificate issuance Indicator
4.6.7.3 Islamic Profit Sharing Accounts

1) Profit Sharing General Conditions
 Minimum Balance Conditions:
o Minimum Balance Amounts: Define the balance threshold, for each applicable currency, to
be eligible for profit sharing.
o Dropping below minimum Balance Impact: Determines system behavior in case the
account’s balance goes below the minimum balance.
1- Keep profit sharing participation rights for the previous months
2- Clear Profit Sharing Points: Zeroize the previously cumulated Ada’d points.
 Participation Percentages: Specifies the participation percentage of account’s balance in the
profit sharing computation. A different percentage is defined for each product code and
allowed currency.

 Bank Risk Percentage: Identifies percentage of profit that will be deducted for possible
investment / financing risks provision.
 P.E.R. Percentage: identifies percentage of the profit that will be deducted for Profit
Equalization Reserve.
 Bank Profit Share Percentage (Mudarib Fees): Identifies percentage profit that the Bank is
entitled for as a Mudarib fees.
 Participants Share: Identifies percentage profit to be distributed to customers. Can be defined
by slice / tiers of amount.
 Suspense Account Type: The account type that would be used as a suspense account for
suspended not yet due profit. (If and when applicable)
 Tax and Over Taxes On Profit conditions
 Zakat Conditions
2) Saving Account Specific Conditions
 Profit Sharing Participation Balance : The account balance to be considered for profit sharing /
participation:
a. Minimum Balance (Available)
b. Minimum Balance (Accounting)
c. Average Balance (Available)
d. Average Balance (Accounting)
 Profit Payments periodicity: Periodicity of profit crediting to account during a year.
 Closure fees conditions
3) Term Account Specific Conditions
 Based On Balance : The type of the balance that is going to be used in order to compute the
Ada’d points for the account:
1. Minimum Balance (Available)
2. Minimum Balance (Accounting)
3. Average Balance (Available)
4. Average Balance (Accounting)
5. Minimum Monthly Transaction (Available)
6. Minimum Monthly Transaction (Accounting)
 Maturity Periodicity conditions Minimum, Multiple Of, Maximum Periodicity
 Premature Closing conditions: Fees, Waiving profit, etc.
 Partial Withdrawal conditions: Fees, Waiving profit, etc.
 Participating transactions possible conditions including ‘Minimum Transaction Amount’ per
currency (Only transactions that are above (or complete previous transactions to be above) this
minimum transaction amount will participate in the Ada’d calculation.
 Use Passbook Flag
 Renewal conditions

4) Fixed Time Deposit Contracts (when applicable)
Under Fixed Term Deposit Contract: Profit calculation is transaction based. Thus multiple agreements can
be accounted in a single account while each agreement may have its own conditions, for instance: Deposit
Amount, Maturity, Profit rate and periodicity, Rollover conditions.
Profit rate set at account opening is for illustration purposes while the effective profit will be distributed as
dividends according to effective realized profit.
ICBS offers a number of parameters allowing Banks to configure their deposit products including:
 Maturity Periodicity conditions (min, max multiple of)
 Profit tentative, payment periodicity and conditions (min, max multiple of)
 Withdrawal and Premature Closing Conditions: Charged fees, Waive profit.
 Indicates eventual amounts constraints per allowed currency:
1. Minimum balance
2. Minimum Initial Deposit Amount allowed
3. Maximum Total Deposit allowed
4. Recursive transactions allowed amounts (multiple of).
 Taxes and overtaxes conditions
 Renewal / Roll over conditions
1) Close (No renewal allowed)
2) Renew without profit or Capitalize (renew with profit)
3) Suspend waiting for customer’s instructions (that would be set to: Increase, Decrease) That
could be any of the following (1: Close, 2: Renew without profit, 3: Renew with profit, 4:
Change maturity periodicity, 5: Change amount (increase / decrease), 6: Change Rate)
 Taxes and overtaxes conditions
4.6.7.4 Additional conditions (per currency)

 Minimum Balance Commission Conditions
o Applicable on: Monthly balance, Yearly Balance, Any day balance, Combination of the
previous information.
o Threshold
o Action: Charged fees, Waive profit for the previous months, Combination of the previous
information.
 Transactions Conditions
o Applicable on: Number of selected transactions types during a defined period
o Threshold
o Action: (i) Forbidden or (ii) allowed subject to charged fees, Waive profit for the previous
months, Combination of charges and profit waiving.

4.6.7.5 Periodical Fees conditions

A list of charges / fees that could be charged periodically:
 Maintenance Fees calculation and periodicity
 Statements Fees calculation rules and periodicity
 ATM Fees and periodicity
 IVR Fees and periodicity
 Dormancy / Inactive conditions and possible charges while dormant and upon reactivation.
4.6.7.6 Dormancy rules include setting:

 If product is subject to dormancy if no customer’s direct transactions occurred during a period (i.e.
for example fees and charges are not considered as direct transactions)
 Period length in Number of days
 Dormancy fees condition (Account balance threshold, periodicity and calculation)
 Customer’s Transactions
 Reactivation fees
4.6.7.7 Participation in draw system / lottery conditions

 Minimum Balance Conditions: Minimum Balance Amounts: Define the balance threshold, for
each applicable currency, to be eligible for participation
 Draw chances per period calculation based on:
o Number and type of transactions
o Delivery channel
o Account Balance (Average or Minimum)
o Combination of the above
4.6.7.8 Related Accounts

To simplify parameters setting, a list of accounts types or G/L accounts to be debited / credited by the
respective by the various income / expenses amounts pertaining to:
 Attached nominative G/L for customer’s accounts consolidation
 Accrued profit
 Paid profit
 Posted commission
 Taxes and over taxes
 Periodical fees and expenses (Commitment, Dormant, Closure, Minimum balance, Transactions,
Checkbook)

4.6.8 Configurable Operations Business Rules

Financial Transactions Engine: ICBS allows system administrators or authorized users to define new
transactions according to bank policy and regulations using a set of parameters covering: screen layout,
commissions, charges, value dates, accounting entries, receipts (integration with Microsoft tools) and
payment messages (SWIFT, ACH, RTGS for example).
This concept was introduced to eliminate redundant and repetitive clerk work, handle complex operations
in a simple manner, handles complex control procedures automatically without manual intervention or
even personnel knowledge or involvement.
The total parameterization of the accounting aspect makes it even easy and quick to implement. A new
transaction is implemented in the system and made available to the users in a few minutes time. Once
implemented, this new transaction will work under its parameters control, until another amendment is
made on it (usually, transactions implemented and operating are never changed).
To each transaction user is able to define through the usage of a rich set of parameters to define:
 The commissions conditions and computation formulas
 The value dates condition and calculation
 The accounting entries to be generated
 The various customer notes, receipts and messages
 And for common banking / teller operations such as cash deposit, Cash withdrawal,
account to account transfer, debit note, credit note and the like, authorized user is able
also to define the interactive part of an operation thus for each field he will:
1. Select the field position
2. Define the field attribute
3. Define the field conditions: (Criteria, default value, restriction, cross field
validation).
4.6.8.1 Dictionary and variables:
To each module is associated a chapter (part of a global dictionary) containing a list of Variables: These
variables are the basic tools for system parameterization. It is used to define the accounting entries, the
commissions and value dates calculation, the advice and messages to be generated as well as Operations
Screens when applicable.
4.6.8.2 Configurable Conditions
Conditions are defined as a logical relation between variables of the same module. These conditions will be
the basis of the various selection criteria.
For example, a Deposit Operation may generate the following different accounting entries:
Case 1: The amount is in the same currency as the account
 Debit cash account
 Credit customer account
 Credit commission account
Case 2: The amount is not in the same currency as the account
 Debit cash account
 Credit position account
 Debit C/V account
 Credit customer account
 Credit commission account

The system, and, in order to identify which accounting entries to generate has to, for example, to compare
the account currency to the operation currency. Therefore the following comparison is required:
 Condition 1: Account currency = Operation currency
 Condition 2: Account currency Not = Operation currency.
Operations usually require more complex conditions in order to determine the correct case and trigger the
correct action. ICBS provides the system administrator with a rich set of tools allowing him to build the
required cases.
4.6.8.3 Screens Configuration
User selects the fields to be defined and their respective positions. When selecting a field, the user will
indicate if this field is to be used as:
 a Fixed Text (used as a screen prompt)
 a Variable Field (used to display and receive / store data)
User is able to define, the Fixed Text Values, the Variable fields property, width, height and position. For
example, in case of a Variable Field, system invites the user to select the adequate Variable Code from the
Module’s Dictionary. Based on the underlying Variable Nature, the system will display the variable
attributes and ask the user to:
1. Eventually modify those Attributes: Width, Height, Positions
2. Define a set of Conditions & Criteria, which depends on the field nature.
More precisely, the system asks the user to define the following:
1. Default value if any.
2. Generation criteria?
3. Field captured? Yes / No
4. In it captured, is it Mandatory?
5. Field properties
6. Dependency on other fields and cross validation.
Note: “Transactions Screen configuration feature” is mainly deployed for straight forward operations
(Requires ICBS Customized Operation Module to be implemented). While more complex operations subject
to multiple events, flow of transactions are covered through ICBS dedicated modules with screens built in
accordance with best practice to offer comprehensive automated follow up.
4.6.8.4 Accounting entries schema configuration
Usually each banking operation is requested to produce the adequate accounting entries. This task is
critical since it depends on several factors. In the previous section we stated an example for a simple
deposit operation. Imagine a more complex operation like an L/C issuance handling liabilities, margin and
commissions accounts along with an embedded foreign exchange operation.
ICBS is conceived with a facility allowing the system to automatically identify the required aspect and to
generate the adequate accounting entries. This of course, requires some parameters definition upon
system implementation.
In ICBS the adequate schema can be determined by a set of criteria using a set of user defined conditions.
This means that upon operation time: A Schema is selected if the Combination of the related Simple
Conditions is verified

4.6.9 Configurable Standard and Particular Conditions

ICBS allows authorized users to define system standards conditions including commission computation
formulas and value dates/maturity date calculation taking into consideration local holidays and for
international operations foreign holidays.
Particular conditions can be granted to selected class / nature of customer. specific privileged customers or
customers accounts.
4.6.10 Configurable Messages, Documents, Statement and Customers Notes

Documents handed to customers are printed by the system and / or notified to customers by email. These
documents (advises, transfer orders, receipts,...) can be designed by the Bank as templates that system
would use to populate the variable information according to the operation respective data.
The design process is parametric so that a new document can be introduced in the System and made
available to the end-user in a matter of minutes.
Possible insertion of advertising, marketing and courtesy messages in selected customers’ documents and
statements.
4.6.11 Workflows
ICBS is delivered with pre-built work flows that are developed based on best practices and industry
standards along with our rich and long experience in the banking industry.
More particularly, and in the context of the proposed modules, the delivered workflows allow the Bank to:
 Implement maker and checker approach for the required tasks (Including: Users profiles
management, Customers Information Management: Individual, Corporate, Customer, Accounts
Opening / Closing / Management, Various banking transactions generating accounting entries, stop
payments)
 Route exception handling to appropriate supervisor managers including:
o Users’ limit excess
o Customers’ limits excess
o Default values overrides
o AML Limits
Note: If required, ICBS can be integrated with an external third party tool to configure and manage
workflows. This would however require further study and customization and the cost for the exercise is not
included in this proposal.
4.6.12 Configurable Automated Batch Processing

ICBS is provided with a set of tools allowing system administrator to build the periodical batch procedures.
Thus administrator will be able to build the End of day, End of month and End of year batch procedures by
grouping the required ICBS processing and reporting functions into a global batch with the required order.
In production, operator will launch the global batch that:
 Ensures the run of the related functions in the determined sequence.
 Report and flags all executed tasks
 In case of anomaly occurrence:
o Logs the issue for further investigation / processing
o Move to the next operation, step and or function as set by the administrator.


4.7 Multi-Currency
ICBS is a proven full multicurrency solution providing accounts in different currencies and offering
embedded foreign exchange operations throughout where required.
ICBS maintains multiple simultaneous sale and purchase exchange rates for each currency. Base rates are
captured or refreshed from external source pricing (such as Reuters, Bloomberg or the like). Other rates are
updated based on Bank’s treasurer defined parameters against the base rates. All rates updates are stored
in the data base.
System administrator can configure the various banking operations parameters so each operation would
retrieve the default appropriate rates and compute the cross currency rates accordingly.
Default rate can be also subject to special conditions granted to privileged customer.
During operation user may override the generated rate, however operation will be submitted for supervisor
approvals.
With currency tracking & trading; related reports and balance sheets show the amounts in the currency
accounts as well as in the counter value in local currency using different rates (daily, monthly, average,
etc.).
4.8 Multi- Entity

ICBS offers multi entity handling capabilities where entities may share the same database instance (each
entity being a group of branches) or where each entity would run its own instance on the same or on
different database.
In all cases system provides for Multi-Entities consolidation and reporting.
4.9 Customers’ Information

4.9.1 Introduction
Nowadays, financial institutions are more and more demanding regarding information pertaining to the
people they deal with. The basic information usually offered within the customers file is not any more
sufficient. For instance, in addition to the standard required information (name, addresses, economic
sectors, resident codes, etc.) the financial institutions need to know:
 Who are their customers?
 What are their activities?
 What might be their concerns?
 Who are their guarantors?
 Who has a power of attorney (proxies) and on what?
 Is the customer made of a single person (called hereinafter an Individual or Physical person), a
company (called hereinafter a Corporate or Moral Person) or a multiple persons and / or
companies?
 What is the profession of the said Individual, what is his family situation, what is his study degree, is
he already dealing with a sister bank/company, what is his preferred language, etc.
 What are the activity, the capital and the paid capital of the said Corporate, who are the board of
directors, who are the shareholders, who are the signatories, etc?
Such Information pertaining to an Individual or a Corporate are not only necessary for risk assessments (an
Individual can be part of several customers while also being member of the board of a moral person which
is also a customer, etc.) but it can be very helpful when promoting new products such those pertaining to
personal financing, housing financing, consumable financing, etc. Moreover such information can be used
by sister companies such as life insurance and real estate companies.

ICBS puts the customer at the center of the bank’s business and helps achieve customer-centric banking. It
incorporates a sophisticated Customer Information System (CIS) that enables:
 True relationship banking with centrally stored detailed information (personal, demographic,
employment, financial, corporate, among others)
 A single view of the customer’s profile with “drill-down” inquiries
o From summary data such as Consolidation of customer’s accounting data, deposits,
lending, investment portfolio global figures, statistical information and activity allowing
managerial and risk follow-up, calculation of clients profitability and other consolidated
matters
o To individual transactions for each customer including Detailed balances, Overdraws,
Statistical data, Mini statement, Accruals, commissions & expenses, Accounts rates
changes, Standing instructions
 Combined statement for all the accounts held by the customer.
 Banks to leverage better customer analytics, increase cross-sell opportunities and minimize the risk of
fraud with follow up of “Individual person” impact and risks through his participation in various
Corporations and Customers.
 Follow up groups (Formal and Informal) positions and risks using various criteria.
 Customer classification, evaluation based on previous performance and historical data.
More precisely ICBS is conceived with a comprehensive management of Customers
Information System built around a set of related entities fully integrated will all other ICBS
modules and in particular branch operations / front end functionality:
Entity Description
Individuals Personal data collected about an Individual person
Corporations Corporation collected data (activity, financial, assets, contacts, etc)
Customers A corporate or a Set of individuals with a unique ID.
Customers’ Groups A set of customers grouped for consolidated risk management
Customer signatures and Attached set of signatures browsed during operations and
fingerprints fingerprints verified whenever required.
Proxies Authorized power of attorneys
Inherits standard condition from related products / type of
accounts (Profit calculation, periodicities, charges, etc.). Possible
exceptions at account level. Handling of account details, statuses,
Customers & Banks accounts
balances (accounting, value date and available), account credit
limits / overdraft limit when applicable, minimum balance,
statistical data, standing instructions, etc.
Privileges granted to classes of customers, a specific customer or a
Particular conditions
specific account.
Counter parties Recording of correspondents banks preferences
Correspondent Banks Nostro / Vostro Correspondents by country and currency
Black Lists Black Listed Individual or Corporate Customers directory

4.9.2 Schematic Global View
Illustrating a number of relationship including

 Individual to Corporate, Individuals and / or corporate t o customer,
 Customer to accounts,
 Customer to credit file and facilities,
 Customers to groups
Other relations are illustrated in the following sections and include:
 Relation between individuals (Introduced by, Guardian, Family membership, etc.)
 Account offices responsible of customers or accounts
 Power of attorneys / proxies on accounts given to individuals, corporate or different customers
In the following sections we will detail each of these entities. However, we would like to highlight the
following at this level:
 A customer may be made of multiple individual persons or corporate (i.e. it can be made of one
individual person, several individual persons, one corporate, and any other combination).
 A correspondent bank is also a Customer.
 Customers Accounts can only belong to Customers.
 Customers with no active accounts and no transactions in historical files are reported for possible
pursing.
Note 1: Customer’s Credit file information is described requires ICBS credit facilities management to be
implemented. Please refer to the respective section for details about:
 Received collateral and guarantees
 Corporate Collected financial figures (Assets / Liabilities, Income, Sales figures etc.)
 Granted Credit lines and Facilities

4.9.3 Individuals management

An individual is a person having established a relation with the bank. For example a person may be:
 Guardian of a Customer (relation between 2 individual persons),
 Member of a Customer (relation between an individual person and a customer),
 Member of the board of directors of a Customer (relation between an individual person and a
corporate),
 One of a corporate contact points (relation between an individual person and a corporate),
 Guarantor of a customer (relation between a customer and a guarantor that may be an individual
person, a corporate or another customer)
To each person, the system allocates:
 A set of basic information such as: first name, middle name, father first name, mother first name,
mother name, spouse first name, gender, birth date/ age , spouse name, managing branch code,
preferred language code, Activity status code, Bank staff indicator, National Number (CIVIL ID), Social
Security Number, Identification number and register locality, Economic sector code, Family situation
code, Locality code, Profession code, Profession status code, Employer, Employment date, Basic salary,
Monthly income, Prefix and Suffix codes, Residence code, Study degree code, Number of children, Legal
guardian, Judiciary guardians, Introduced by, Commercial register info, Alive Indicator, Comments,
Work permit for aliens, Place, Expiry;
 Dependents and possible beneficiaries details
 Configurable multiple addresses with drop down fields, including city, county, state, Zip code, country,
Emails, phone numbers, etc.
 KYC required information,
 Required documents statuses and incomplete file indicator
 A set of users defined relatively unlimited dynamic fields to be collected from “Individual persons”.
Each set of information is attributed a “code” a “Set of questions” and, when required, a list of possible
values.
Fields attribute utility allows system administrator to update the mandatory / optional / disable attribute of
the customers’ database entities. User is prompted for incomplete data / mandatory fields.
Obviously some fields are required for the good operation of ICBS and they will be displayed with their
corresponding check box “As is” checked; this means that system administrator is not allowed to change
the corresponding attributes. For other fields, system administrator would be able to change / specify if the
related field should be enabled (accessible to users) and if it should be mandatory (Required).
Alphabetical data are available in 2 languages
Note 1: Additional information is also available at “Credit File Management” Level for persons applying
for a Credit / financing product. This includes: Employment information, Revenues / Income, Owned assets,
possible relations with other institutions, etc.
4.9.4 Corporate management

A Corporate is any legal entity, bank or Institution.
Example a corporate can be:
 A customer by its own,
 Part of a holding, this latter being a customer
 An employer whose employees are customers
 A guarantor for a financed deal

To each corporate, the system allocates:
 A set of basic information such as: Managing Branch code, Name, Activity, Company rating code,
Residence code, Legal status code, Language code, Required signature combination, Introduced By,
Economic sector nature code, Nationality code, Capital information, Net worth, Usual Turnover,
registration information, Civil ID, Country of Risk, Foundation date, Company duration in years,
Relation Reason, Relation Date, Commercial Registration Number, Commercial Registration
Locality, Judiciary Ref., Number of employees,
 Configurable multiple addresses with drop down fields including city, county, state, Zip code,
country, Emails, phone numbers, web sites, phone numbers, Domestic Code / “Party Identifier”
assigned by the National /Domestic Clearing organization (Ex: US Fed Identifier or UK Domestic Sort
code), SWIFT codes, etc.
 KYC required information
 Alphabetical data in 2 languages
 Multiple relation with individuals to identify key persons, such as: Member of board of directors,
Main Shareholders / Partner, Chairman, General Manager, Assistant General Manager, Signatories,
 A set of users defined relatively unlimited dynamic fields and Fields attribute utility (Similar to
individual persons) allows for further configurations and flexibility to ensure mandatory fields are
captured.
Note: Additional information is also available at “Credit File Management” Level for corporate applying for
a Credit / financing product. This includes Credit file information such as segmentation, authority, previous
year’s financial figures (Assets, Liabilities & Equities, Net sales, Net income, etc.) and next year’s forecast,
Dynamic application questionnaire answers and classifications
4.9.5 Customers management

The “identification number” or Customer ID is a unique number system generated (see note 1) and
assigned to each customer and used to consolidate all the customer activities.
A customer is an Individual, a set of Individuals or a corporate. His ID is unique within all the bank branches
and allows for customers activity consolidation. This concept is used to allow defining a customer as a
combination of persons and companies. A person is defined once in the system and it can be used at
multiple levels without having to redefine his personal information.
To each customer, the system allocates:
 A set of basic information such as Customer Identification, Branch code, Name, Short name /
Embossing Name, Language code, Residence code, Country of Risk, Signature combination code,
Economic sector nature code, Customer type, Segmentations (Retail, Corporate, International,
Government) , Customer status code, Managed By, Secret flag, VIP flag, VIP special information,
Secrecy level / Confidentiality, Check book forbidden flag, Check Book Forbidden Date, Particular
commission flag, Particular value date flag, Taxable flag, Indicator identifying the address to be
used for mail, Indicator identifying the address to be used for special operations, Managed By
Group, Strategy Code, Taxable Reference, Customer Classification, Cash transaction Threshold and
AML control limits category, Consolidated Statement indicator.
 Configurable multiple addresses with drop down fields including city, county, state, Zip code,
country, Emails, phone numbers, web sites, phone numbers, Domestic Code / “Party Identifier”
assigned by the National /Domestic Clearing organization (Ex: US Fed Identifier or UK Domestic Sort
code), SWIFT codes, etc.
 A Customer may have several addresses (see details above).
 Alphabetical data are available in 2 languages.


 Multiple relation with individuals and corporate constituting the customer
 KYC required information (Sensitivity level, Estimated Turnover, Review Date),
 Enrolled details services through various delivery channels (e-Banking, IVR, SMS, email, etc.)
 A set of users defined relatively unlimited dynamic fields and Fields attribute utility (Similar to
individual persons) allows for further configurations and flexibility to ensure mandatory fields are
captured.
 Rating, Classifications and Customers status (Regular, Classified, bankrupted, etc.)
 Alphabetical search and access
Note 1: As a standard approach, system generates automatically customer ID number; nevertheless,
facilities are available to allow authorized users reserving special IDs to privileged customers.
4.9.6 Other Main entities related to customers information

These mainly consist of:
 Proxies (Granted to Individuals, Corporate or Other Customers)
 Granted privileges and standard conditions (Commissions, Value dates, Rates)
 Groups of customers.
 Black lists
 Counterparts and Correspondent banks
Note: Details can be provided upon request.

4.10 General Ledger Accounting

4.10.1 Parametric chart of accounts:
A set of functions are provided to define and maintain the General Ledger accounts based on the Bank’s
defined Chart of accounts. Once the Chart of accounts set by the bank, the general Ledgers accounts are
created / opened in the required Currencies and for the required Branches.
The Chart of accounts and consequently the General Ledgers accounts are:
· Follows a hierarchy of 7 levels
· These consist of:
6 consolidation levels
1 Operational level
A simple extract of the Chart of accounts would be for example:
5 Treasury and inter banks operations
50 Cash accounts
501 Banknotes and coins
5011 Banknotes
501100 Banknotes
501100 001 Petty Cash
501100 002 General expenses
501100 003 ATM
51 Central Banks
The general Ledger accounts are subdivided into classes:
1. Consolidation Classes: These consist of General ledger accounts levels 1,2,3,4,5 and 6 having
respectively their chart of account elements length equal to 1,2,3,4,5 and 6 characters. Their
balances are the results of the consolidation of the underlying accounts in the defined
hierarchy.
2. Nominative class: These consists of General Ledger accounts level 7 with their chart of account
elements of 9 characters subdivided as follows:
 The first 6 characters representing the main chart of accounts element
 The last 3 characters being an auxiliary or subsidiary.
Their balances are the results of the consolidation of attached to customers’ accounts.
Example: Customers’ Deposits, Customers’ liabilities under Letters of Credit, etc.
3. Internal Accounts: These also consists of General Ledger accounts level 7 with their chart of
account elements of 9 characters subdivided also as follows:
 The first 6 characters representing the main chart of accounts element
 The last 3 characters being an auxiliary or subsidiary.
However, these are the only General Ledgers accounts that are subject to direct Db and Cr
transactions. Example: Cash account, disbursement account, ATM account, etc.

4.10.2 Parametric Cost Centers

In addition each Internal Account can be split/ reflected to multiple Cost Centers. These cost centers can
be linked to the operating branch, Customer account Branch or Bank wide.
Cost centre can be defined at one of 3 following levels:
 Chart of account definition (L/C commission Account can be set to distribute all commissions
collected to this account between the operating branch 40% and Head Office 60%)
 Accounting lines parameters (Cash deposit Operation can be defined so that earned exchange
commission will be distributed between the Operating Branch 80% and Customer account Branch
20%)
 Operation level (Free format operation allows users to define cost centers for each accounting
line).
4.10.3 Multi Segments Accounting Number

Self explanatory GL Account numbers structure made of a branch code, a currency code and the chart of
account element. For example operational level accounts structure is as follows:
4.10.4 General Ledger Features

 Parameterized accounts types (Consolidation, Internal, Nominative, On/Off balance Sheet, Cost
Centers)
 User Defined G/L Grouping for reporting purposes.
 Automatic generation of ledgers and sub-ledgers accounts according to selected range of chart of
accounts elements
 Full Multi-currency: ICBS provides accounts in different currencies; related reports and balance sheets
show the amounts in the currency accounts as well as in the counter value in local currency using
different rates (daily, monthly, average, etc.).
 Multi-branch / Multi-entities system. Branches grouping within region for monitoring and
consolidations.
 On-line update of internal accounts based on transactions issued by ICBS modules

 User defined common operations in order to streamline accounting process by generating default
information and reducing human errors.
 User defined restrictions on GLs (GLs forbidden to specific operations, not allowed to go Debtor or
Creditor, Requiring manager approval before processing any transaction, etc.)
 Monitored upload of accounting entries (journals) received from third party systems.
 Automated posting of journals and updating of consolidation accounts.
 Possible cancellation of operations (prior to end of day procedures) with automated logging.
 Transactions Reversal capabilities after end of day procedures.
 Handling of accounts payables / accounts receivables
 Recording and Tracking of suppliers invoices (aging)
 Settlement of suppliers invoices according to recorded preferences (mode of payments)
 Processing of direct Credit / Debit notes
 Assets / Liabilities flexible reporting
 Automated periodical procedures and End of periods closing
 Possible overlapping of monthly & yearly accounting
 Historical transactions and journal storing and reporting
 Consolidation Reporting.
4.10.5 Payables Management

ICBS Payables Management covers:
 Agreements setup with Suppliers
 Invoices Reception and Settlement
 Credit Notes Reception and Processing
ICBS Payables is fully integrated with all other ICBS modules:
 Suppliers are defined on the top of information available in ICBS Customers’ Information
System, thus supplier needs fist to be identified as an already defined individual, corporate
or customer. Then additional information is recorded in a dedicated Suppliers’ table.
 Settlement can be in any form of: Credit to Account, Draft / Managers issuance, Cash. Etc.
 Modules such as Consumers financing management and Real Estate management record
generated payables / received invoices in the payables master table.
ICBS Payables Management offers maker / checker features thus requiring captured transactions to be
validated by appropriate supervisor before effective processing.
Recorded payables may be accrued over a defined period.
A single settlement may cover multiple payables.
A Payable may be settled through multiple partial payments.

4.10.6 Budget Control

The aim of the budget control sub module is to provide the bank's top management with tools allowing
them to define the original budget provisions, to compare it with actual figures (expenditure and income
accounts) and to compute the variances as well.
Budget can be handled at the following levels:
 General Ledger Accounts
 Cost Centers
Interactive functions
1. Cost centers definition
2. Budget Figures Definition by G/L Account
Used to define the budget figures by G/L account for a given year. Amounts can be defined for the
complete year or month by month.
3. Budget definition by cost Center
Used to define the budget figures by G/L Account, by Cost Center and for a given year. Amounts can be
defined for the complete year or month by month.
Distribution over the cost centers
For the Predefined operations: Accounting entries are generated and cost centers are affected
automatically as previously parameterized.
Free format operation: Authorized user will key in the required accounting entries and spread it on the
required Cost Centers.
Main Inquiries and Reports
Cumulative revenues & expenses / By Cost Center
Income & expenditure budget
Comparing budgets
Comparing Previous Year Budgets & Balances with Current Year Budget
Comparing Current Year Budgets & Actual Figures
4.10.7 Transactions Feeder

Transactions / accounting entries generated by third party system can be fed into ICBS through files
uploading procedures that perform the various consistencies and validation checking before porting it to
ICBS.
4.10.8 Integration with third party G/L and Accounting systems:

ICBS generates accounting entries in on line real time mode. Generated entries are recorded in ICBS
journals tables and can be posted to third party accounting / GL system (after formatting) In on line mode
or in batch mode.

4.11 Customers’ Accounts

4.11.1 In General
A customer's or correspondent bank's account is identified by its account number. Customers’ accounts
numbering is customizable.
For example a customer account number can be composed of:
 Branch code (where the account is opened)
 Currency code (the currency of the account)
 Product Type (As defined in the previous sections)
 Customer's ID (ID number of the client or the correspondent bank who opened the account)
 Counter allowing to identify accounts opened in same branch, same currency, same products
 Check digit: allows checking at data entry the validity of the account number keyed in.
4.11.2 Accounts Opening and Maintenance

4.11.2.1 Customers account opening
Accounts may be opened for parties defined under the customers’ entity. This includes Customers,
Correspondent banks, Suppliers, Collectors, Insurance Companies, Employees, Etc; In and off Balance Sheet
accounts can be opened in accordance with the defined accounting products business rules and conditions.
For instance upon account opening, user and following customer’s instructions:
 Selects the required product from the available products
 Selects the required currency code from the allowed currencies
 Selects Customer’s unique ID
System will retrieve the respective product’s and customers’ information to check customer’s eligibility and
prompt prevailing conditions whereby:
 Conditions abide by rules set for the combination of: Product code, Currency and Customer’s
Nature
 Eligibility is subject to products’ rules and customer’s data: Nature, Age, Nationality, Residence, Not
black listed, status.
User will capture account specific information and, if allowed, may override default conditions. However
this will be subject to supervisor checking.
Upon data capture confirmation, system generates:
 The unique account number. Account number is made of a branch code and an account number
within the branch (up to 16 Chars). The account number format can be defined according to Bank’s
during system implementation.
 Customers’ documents including accounts conditions and possible passbook.
Triggering of possible other services such as ATM Cards order, Checkbook order, Credit Card Application,
Standing Orders, Etc.

4.11.2.2 Accounts handled information

System provides also for:
 Alphabetical Access (Multi-criteria Searching)
 Access by Old Account number (useful after data migration from a third party system)
 Contract and Account’s conditions printing
Account’s main information fields are:
1. Critical information:
 Branch code: The branch in which the account is being opened.
 Currency code: The currency in which this account is being opened.
 Product code: Distinguishes between the various types of accounts: Current, Saving, Term, etc.
 Customer ID number: The unique customer ID.
 Serial number and check digits
 IBAN account number
2. General Information
 Default customer’s address for statement and for operation notification,
 Preferred language,
 Residence code and Economic sector,
 Critical dates: Opening date, First operation date, Maturity date (if any), Rollover date (if any), Last
modification date, Accounts’ conditions application dates, last statement date, last customer’s
movement date, etc.
 Managed by,
 Warnings and Annotations (Flashing messages) that will pop-up anytime the account is accessed
from any screen with the following options:
 Warning message/invitation for a required action
 Supervisor validation
 Blocking.
 Free text and notes.
3. Account Conditions and balances profit sharing conditions
 Subject to Profit sharing indicator
 Draw participation indicator
 Account’s particular conditions, with respective conditions application dates, as compared to
standard conditions.
 Data related to term / notice accounts: Blocking unit , Blocking period , Renewal instructions
 Data related to earned profit and periodicity,
 Last Profit distribution date
 Account status / referral: Normal, Closed, Dormant, Forbidden from withdrawal, Forbidden from
third party deposits, Data related to accounts management / expenses / taxes and periodicity,
 Affiliated account where profit will be recorded / posted.
 Standing instructions (Sweep accounts, periodical transfers, transfer balance above predefined
limit to another account, etc)
 Accounting data: Accounting balances, Cleared / Available balances, real time balances, brought
forward, renewal balance, statement balances, passbook balances, reserved amounts (triggered by
ATM / Card management or external operations),


4. Statistical data and other operational data
Historical transactions, End of month balances, Minimum / maximum / Average balances for each month,
exceptions, returned checks, etc.
Information pertaining to Passbook: Passbook number, Passbook balance, Passbook line, Passbook page,
outstanding transactions not printed on passbook.
Miscellaneous: Statement number, Statement printing redirection code, Last statement balance , Office
Code (Indicates if this account was opened from an office related to the branch), Old account number
(Mainly used for data conversion form the actual system to ICBS), Card Indicator (Indicates whether a credit
/ debit / ATM cards are attached to this account number), Number of attached Cards , etc.
4.11.3 Customers’ Accounts Closing

Account closing process is also subject to products conditions and rules.
Accounts can be close interactively (i.e. manually) or in batch mode (i.e. by the system).
According to Bank’s policy interactive closing tasks:
 Can be only performed only by authorized users
 May be subject to Maker / Checker process requiring supervisor validation.
4.11.3.1 Interactive Closing

Interactive closing is offered according to the following 2 options:
Option 1: On line Closing facility that implies:
 Possible Charges deduction
 Profit settlement / waiving.
Option 2: Off line Closing facility allowing:
a) Tellers to request accounts closing.
b) Batch closing with Charges settlement and profit posting / waiving
In both case, the closing workflow process would abide by the following:
1) User will inquire about all outstanding operations related to the account to be closed.
2) System will check if account can be closed based on a set of conditions:
a) No outstanding liabilities (Financing deals, Credit Card, etc.)
b) No unreleased guarantees / collateral
c) No unsettled No cash facility / limits
d) No Checks under collection
e) No Standing instructions
f) No active ATM card
g) Etc.
3) In case the above checking was concluded satisfactory, system will compute and post profit /
waive points according to account’s conditions. Closing charges will be deducted.
4) After the above process is completed, user will settle any remaining balance by selecting and
performing the adequate operation from the menu and according to the customer’s
instructions (pay cash, issue a check, account to account transfer or the like)
5) Upon customer’s requirement a statement of account will be printed.
6) Authorized user will then flag the account to Closed status

4.11.3.2 Batch Procedures

System also, offers batch facility for automatic closure of account that remains with zero balance and
reflects inactive status for specific period (by default one year), provided that no existing liabilities linked to
it. Periodical follow up reports are produced before triggering batch closure of accounts.
Closed accounts remain part of the active database and can be purged only after a Bank defined period and
only case active database does not hold historical transactions on these accounts so historical reports and
queries would not be affected.
4.12 Rich Set of Reporting

4.12.1 Standard Reports
ICBS is provided with a rich set of reporting functions that can be produced on line upon user request
through menus and/or run in automated scheduled batch mode (Daily, Weekly, Monthly, Quarterly, Yearly,
etc.).
Reports can be produced on paper, screen or saved to file (PDF, HTML, Excel CSV, etc.).
Customers’ documents, statements and certificates can be produced based on Bank defined templates and
printed to paper, saved (Microsoft office formats Word, Excel, PDF, HTML, etc.) and emailed.
Notifications and messages can be forwarded to customers as emails and /or SMS.
We are providing hereafter some of our standard reports for illustration purposes:
 Audit and Control reports: Groups and users profiles with granted authorization, Access
Authorization Change Log, Accounts updated within A Given Range of Dates, Accounts With
Transactions Within User Defined Range , Accounts’ information Change Log, Corporations
information Change Log, Customers’ information change Log, Individuals information Change Log,
List Of Canceled Transactions, List of Overdrawing / Excess Of Limits (authorized, rejected),
Parameters Change Log, System access log / Users’ Activity Log, Matching Customers accounts
totals with corresponding G/L accounts, List of passbooks movements in suspense, List of
exceptions on value dates
 Daily and Periodical transaction reports including: Journal, Trial Balance, Activity Transactions by
operation type, Transactions by user, List of closed/opened/frozen accounts, income and expenses,
purchases and sales of Foreign Currencies
 Multi criteria Customers information and Customers Accounts reports: Individuals List,
Corporations List, Customers List, Banks & Correspondents List, Customer Accounts List, Groups of
Customers List, Accounts’ Situation: Banks By Currency And Country, Accounts’ Statements:
Customers’ Situation By Date, Customers’ Deposits by Currency / type of accounts, Customers’
Deposits by Branch / Currency / type of accounts,
 Exception Reports including Overdrawing and overrides, canceled transactions, anomalies, Debtor
accounts in excess over limit, Unauthorized debtor accounts, Dormant accounts, Returned checks,
Incomplete Customers Accounts Information Report, Non Standard Value Dates and commission,
Unprocessed Transactions Report, Customer without accounts, Accounts opened without any
deposit and/or withdrawal transactions.
 Periodical and upon request Statements
 Module dependent reports are highlighted throughout the following sections of this document.

 Regulatory / Statutory reports: Reports are parameterized according to Central Bank

requirements. System administrator will be able to amend the format, add or remove reports fields
without the need of programmers’ intervention. Reports formats are user defined using Microsoft
Excel. ICBS offers a parametric tool for the generation of the file ITRS ‘International Transactions
Reporting System’ declaration file.
 Management Information system Reports: MIS, Statistics, Profitability / Profit & Loss reports,
Deposit analysis, Gap Analysis, Average Rate, Depositors by slices, Cash flow, Cost of funds.
4.12.2 Sample of Reports & Inquiries

4.12.2.1 CIS Reporting
 Multi criteria queries (with wild cards / drop down lists facilities with wild cards / partial field filling,
comparative conditions (Boolean Search)). and reporting functions offering global views and access to
details including:
C u sto m e r 's A c tiv ity

W h o Is ?
S e a r c h E n g in e
C o r p o ra te In fo In d iv id u a l In fo B la c k L is te d
C u s to m e r In fo A c c o u n tin g In fo O p e r a t io n s & P o r t fo lio
C r e d it F ile s : L in e s & G u a r a n te e s B a la n c e s T r a d e F in a n c e O p .
S ig n a tu r e s S ta te m e n ts Loans Op.
P r o x ie s A c c r u a ls C a p ita l M a r k e t P o r tfo lio
G ro u p s C o n d itio n s S ta n d in g In s tr u c tio n s
... ... ...
o Individual Persons details

o Corporate details
o Customers details
o Relationships
o Credit Lines and Possible collaterals / Guarantors
o Signatures and Fingerprints details
o Proxies details
o Particular conditions
o Groups of customers
o Black List details

o Customers Accounts balances with drill down to :
a) Account’s general data
b) Account’s annotation / referrals
c) Account’s balances details
d) Statement of accounts
e) Overdraft history
f) Statistical data
g) Standing Orders
h) Value date balances and corresponding details
i) Accruals and Profit
j) Historical transactions
 Counterpart and correspondents information
 Audit and control reports
 Notifications messages / reports (incomplete files, minors reaching adult age, rate change, account
statuses change, etc.)
 Periodical and Upon request statements (consolidated or individual, actual or previous periods)
 List of customers and banks accounts
 Customers Accounts Log file List
 Customers and Bank Accounts Alphabetical List
 Customers and Bank Accounts List by Customer I.D.
 Monthly report for all cases of No activity / No withdrawal which remain unchanged for more than
12 months.
 Report all significant balance (movement) to the related manager / officer with details of
transactions (Fights against money laundering purposes).
 Periodical report for Zero Balance
 Account Opening output
a) Possible standard printed form for all types of accounts, where only fields that are
applicable for the corresponding types of accounts will be shown
b) Includes a check list of all documents required for each type of account, in accordance with
customer’s type and legal entity
c) Automatic printing of Civil ID clarification form and salary transfer form for individual
customers (upon request).
d) Printing the terms and conditions of account opening:
 Automatic printing of the account’s terms and conditions as an integral part of the account
form.
 Terms and condition of the ATM, IVR, Internet, and checkbook will be printed as an
additional integral part of the account opening form.
 Allow reprinting of account opening form

 Consolidated Customers’ position list including the following:

 All Deposit and financing accounts: including number / type / currency / balance (Balance
in FC and equivalent in local currency)
 For individuals: full details of Credit and Debit Cards facility including Card number, limit,
utilized and outstanding balance/items
 Full details of collateral (deposit / shares & other with updated value), personal and other
types of Guarantee
 Average utilized balance on a to-date, monthly, yearly basis
 Account group of officer
 Full diary system for maturity, expiry, value date of facility / deposit / financings /
documents
 Clearance certificate and Balance certificate
 Account status change
 Inquiry on Closed Accounts
 Average Balance Inquiry.
 Multi criteria journal
 Trial Balance
4.12.2.2 Accounting & General Reports

ICBS provides a set of accounting general reports including: Daily Reports: Journals, official journal, Trial
balance, Balance sheet, Consolidation reports, Daily Activity and control reports, Transactions by operation
type, Transactions by user, Accounts overdrawing, List of canceled transactions, Exception Reports
4.12.2.3 Daily Reports

 Accounts Daily Position Report
 Daily Journals
 Daily Transactions List
 Daily Transactions List By General Ledgers
 Daily Transactions List By Third Parties (Customers, Suppliers, etc.) Accounts
 Daily Transactions List By Departments
 Daily Transactions List By Operations Type
 Daily Transactions List By Users
 Daily Transactions List On Cash Accounts (Cash Register)
 Daily Balance Sheet
 Daily Trial Balances
 Official Journals

4.12.2.4 Selected Exception reports

 Creditor accounts accidentally debtor
 Debtor accounts accidentally creditor
 Exceptions lists
 Incomplete Customers Accounts Information Report
 Non Standard Value Dates and commission
 Unprocessed Transactions Report
 List of authorized not utilized accounts
 List of debtor accounts in excess over limit
 List of dormant accounts
4.12.2.5 Selected Log Audit Trail / Log reports / control List

 Access Authorization Change Log
 Accounts updated within A Given Range of Dates
 Accounts With Transactions Within User Defined Range
 Accounts’ information Change Log
 Corporations information Change Log
 Customers’ information change Log
 Individuals information Change Log
 List Of Canceled Transactions
 List of Overdrawing / Excess Of Limits (authorized, rejected)
 List of accounts opened / closed during the month
 Parameters Change Log
 System access log / Users’ Activity Log
 Matching Customers accounts totals with corresponding G/L accounts
4.12.3 Reports Customization

ICBS open database:
 Allows for authorized users to develop and deploy ad hoc reports through the use of a number of
report generators. (Our proposal includes a Oracle Discoverer as report generator nevertheless the
Bank users may make use of tools that they are familiar with)
 Is a rich ground for Business Intelligence and Dashboards providing consolidated information with
drill down to details.
4.12.4 Optional reporting from replication servers

On the other hand and for performance purposes, Bank may replicate data to a secondary database (or
better use the Disaster Recovery database) for reporting purposes thus reducing the load on the
production platform and database.
Such replication and sifting of reporting service to DR platform can be easily triggered without any
programming effort just by launching Oracle RDBMS Data Guard feature and configuring the Report
services.

4.13 Integrations with third party solutions and delivery channels

With its open architecture structure ICBS integrates successfully with third party applications and delivery
channels:
 Directly through:
o Standard APIs
o Web Services
 SOAP,
 WSDL (XML/HTTP)
o Access to Stored Procedures
 But also upon customer’s request through:
o Middleware (ex: IBM MQ series)
o Gateways
o Channel Manager
Proven integration capabilities and integrated products brands and details can be supplies upon requests.
4.14 FULLY DOCUMENTED

A set of manuals describing the functional specifications of the applications software besides user manuals,
education materials and technical documentation are offered with the system.
4.14.1 Functional Specifications / User Manuals

Detailed explanation of all the ICBS functions; with screens and print-outs layout.
4.14.2 Training Manuals

Education Materials to help end-users prepare and follow the ICBS training sessions.
4.14.3 Test Plans

Document aiming to help the ICBS end-users prepare their test data guided with screen layouts and
detailed fields in / out explanations.
4.14.4 Administrator Manuals

It is an Implementation Guide describing all the steps to be performed for ICBS modules installation.
4.14.5 Technical Documentation

This document describes the technical aspect of the ICBS functions with detailed explanations. (Provided
only with source codes).
4.14.6 Data models

The data models document describes the ICBS Flow of Data, with all the related tables relationship and
attributes.

5 CENTRAL PROCESSING & INTERFACES

5.1 Credit Facilities Management
5.1.1 Scope
ICBS Credit Facilities Management module handles both corporate and retail credit administration and
covers:
 Customers’ Credit files management
 Credit application rating
 Customers’ submitted Guarantees / Collateral management
 Credit Lines granted to customers.
 Credit Classification
5.1.2 General Procedure

After having defined customers’ general information (For more information please refer to above section:
Customers’ Information System) building a Credit file for a customer (or a group of customers) is performed
as follows:
(i) Capturing collected information including: References, Identification, Expiry Date, Next Review
Date, Credit Nature, Codification, Classification and segmentation, Manager in charge, Credit
committees, Comments / Documents, Previous and forecasted Financial Statements figures:
Assets, Liabilities and Shareholders’ Equities, Net Sales, Net Income. Relation with other banks.
Scanning and attaching Documents
(ii) Entering collateral and received guarantees details: Real estates, Life insurance, Goods /
Machinery, Blocked amounts and / or accounts, Received banks guarantees, Securities,
Guarantors, etc.
(iii) A user friendly with on-line help and guidance credit matrix questionnaire / scoring offers
automated rating according to predefined questions and respective answers weights such as:
Obligor risk (Management quality & services, Management continuity and stability,
Relationship history), Economy risk (Regional economy, Activities and trends, Insurance),
Financial risk (Financial information, Auditor rating, Debt service capacity), Guarantees, etc.
(iv) Grating Multiple Levels / Multiple Currencies Credit lines according to parametric products and
facilities types. A credit line may:
 Be of Revolving, Digressive or Scheduled nature
 Involve a set of dates: Entry, Granted, Expiry and Renewal
 Related to respective facility (ies): Financing, L/Cs, L/Gs, etc.
 Represent a Global Facility encapsulating multiple limits, a Sub limit or Restricted to a set of
accounts
 Assigned a set of conditions with penalty and commitment fees.
(v) On line Real time Monitoring granted credit lines (Granted amounts V/S Used amounts and
Expiry date).

System offers the option of validating captured guarantees. Captured information will be recorded into a
transaction file waiting for supervisor validation before being moved to master tables. Validating a
guarantee generates the appropriate accounting entries and in case of a blocked amount / account
respectively reserves the corresponding amount or blocks the selected accounts.
Guaranties and Credit Lines attachments may be One to one, One to Many or Many to Many.
Granting / activating credit lines can also generate appropriate accounting entries and activate
commitment fees / commissions periodical deduction process.
During operation, system monitors the operation amount against granted lines and already used amounts.
Any excess is reported to the supervisor for validation. Approved excess can be subject to penalties.
Foreign currencies Credit lines are periodically re-evaluated based on closing currencies rates.
Within global inquiries, authorized users may browse the available credit balances (Granted lines, already
used amounts, available balances).
A set of optional functions allows gathering customer’s performance for evaluation classification purposes.
5.1.3 Schematic View
C r e d it F ile
G e n e r a l In fo r m a tio n C r e d it In fo C r e d it L in e s
C o r p o r a te In fo F ile In fo L in e s C o n d itio n s
C u s to m e r In fo F in a n c ia l In fo A tta c h m e n ts
G ro u p s R e la tio n s o th e r b a n k s M o n ito r in g
S ig n a tu r e s G u a r a n te e s D e ta ils R e -e v a lu a tio n
R a tin g Q u e s tio n n a ir e
D o c u m e n ts

5.1.4 Main Functions

Parameters Management
 “Credit file” parameters tables
 “Application Credit Rating” parameters tables
 “Guarantees” parameters tables
 “Facilities and Credit Lines” parameters tables
 “Customers’ Credit Classification” parameters tables
Credit file maintenance
Guarantees Management
 Data entry
 Validation
 Utilities
Application Credit Rating
Credit Lines
 Setting required credit lines
 Granting / activation
 Timely on line real time monitoring and updating
 Interactive Supervisor Intervention for Excess
 Periodical revaluation
 Commitment fees deduction
 Eventual Penalties (If applicable) Calculation / Posting
Credit Classification / Performance
 Loading Required Data
 Partial Classification based on: Total Deposits (Average Balances, Total Deposits, Credit Limits, Ratio
Dep./Cr Limit, Ratio on Highest Balance), Refused Checks Amounts and Numbers, Excess of Credit
Lines Amounts, Number of Time, Duration, Accidentally Debtor Balances, Duration, Due Not Paid
Balances, Duration, Guarantees Situation (Mortgage, Blocked Accounts)
 Final Fully Parametric Classification
Global Situation & Reporting
 Summary Position
 Follow up Position
 Detailed Position

5.2 Profit distribution and A’dad Calculation

5.2.1 Islamic Saving and Term Accounts Profit Calculation and Distribution
5.2.1.1 Definitions, Distribution Process and Global Conditions
 Profit Distribution is, in compliance with Sharia law and Bank’s set business rules, the allocation of
profit between the:
(i) Bank's Shareholders Equity (or Invested Capital – see hereafter)
(ii) And the investors (holders of unrestricted investment accounts)
Distribution to investors takes place according to a ratio based on each party share of investment.
 Customers’ Unrestricted Investment Accounts: Are the customers’ deposits (or funds received by
the bank from investors), whereby the bank is free to invest those funds in conformity with Shari'a
Regulation, without prior restrictions, including the mixing of these funds with the bank’s own
investment.
 Customers’ Restricted Investment Accounts: Are the customers’ deposits (or funds received by the
bank from investors), whereby the bank is invests those funds in conformity with Shari'a Regulation
according to predefined strategy.
 Capital: The bank’s share of investment (also known as Bank’s Shareholders Equity).
 Participation Percentages: Participation in profit varies between types of accounts. (Or accounting
products). For Instance the accounting products may be configured as follows:
o Current account, would not participate in the profit (i.e. participation would be set to 0%).
o Saving Accounts, from which customers can withdraw upon request, would participate in
the profit according to a specified percentage (ex: 60%)
o Time Deposits accounts, from which usually is not allowed to withdraw prior to its
maturity dates, would have a participation percentage function of their maturity. For
example: 70% for 3 months time deposit accounts, 75% for 6 months time deposit accounts
and 80% for 12 months time deposit accounts.
Note: Bank’s capital will participate at 100%.
 Ada’d are the monthly points granted to the customer’s account based on the account's balance.
These points will be considered for the purpose of profit calculation / distribution. Some Banks
calculate these points based on (i) the Average Accounting Balance of the month or (ii) the Average
Available Balance of the month, while other banks use the (iii) Minimum Accounting or the (iv)
Minimum Available Balance of the month. (See note 1). More precisely Monthly Ada'd represents:
o The considered monthly balance multiplied by the respective account type participation
percentage.
o It would be set to 0 in case the considered balance is below a minimum balance.
Note: Account's Ada'd calculation are subject to conditions and rules defined at products level,
deposits into account transactions, withdrawal from account transactions, minimum balance,
minimum transaction amount and account closure.
 Considered Balance / Method: Calculation is processed on a monthly basis with respect to
respective account's balance according to one of the following method:
o Minimum Balance of the Month
o Average Balance of the month

 Risk Reserve: Subject to possible Central Bank Regulation, bank would be required to create a risk
reserve. Risk reserve is computed as a percentage of the “outstanding total net direct credit
facilities”. It would be deducted from net profit before any distribution of profit.
 Bank Capital (or shareholders) Profit Share. Remaining profit after Risk Reserve deduction will be
split on prorata basis into (details is provided in the following example):
o Capital Share of Profit (the present information)
o And, "Gross Customers Shares of Profit"
 Profit Equalization Reserve (PER): This is the reserve which bank may hold in order to maintain the
percentage of profit during the year. It is usually defined as a percentage of the "Gross Customers
Shares of Profit". It would be also deducted prior to any distribution of profit to the customers.
 Mudarib Fees: This is part of the profit that goes as Bank Income. It is usually defined also as a
percentage of the "Gross Customers Shares of Profit". It would be also deducted prior to any
distribution of profit to the customers.
 Customers' Net Share: This is the amount distributed on the customers' accounts subject to their
respective Ada'd.
5.2.2 Products Specific Conditions

5.2.2.1 Islamic Saving Accounts Specific Conditions
Account profit participation is subject to a minimum balance under which account will have his monthly
Ada'd set to Zero.
Also Bank may decide to revoke all previous months Ada'd in case the balance drops below the defined
minimum.
5.2.2.2 Islamic Call Notice Accounts Specific Conditions

Notice Account is subject to a notice period defined on the product level:
 Notice Account Flag: Indicates if the account is a notice account.
 Notice Period: It defines the notice period to be provided by customer before withdrawal
and the period in which the customer is allowed to make the withdrawals.
In this case, the withdrawals that are done without any notice, the account will suffer from a penalty equal
to the amount withdrawn multiplied by the notice period.
For these types of accounts, the system will offer the facility allowing the bank to allow its customers to
withdraw their profit, whenever the profit is posted directly to the Adad account itself.
The system will create a notice transaction using the profit amount and the period specified in the ‘product
definition. Once the amount is withdrawn with the specified period, the customer will only loose the points
for the withdrawn amount, once this period is passed; withdrawals are treated as normal transactions.
5.2.2.3 Islamic Time Deposit Accounts Specific Conditions:

Similarly, a time deposit account is also subject to a minimum balance under which the account will not
participate in the Ada’d calculation.
Also these accounts may be subject to a ‘Minimum Transaction Amount’ under which deposit transactions
will not participate in the ado’s computation even if the account balance is above the minimum balance.
The time deposit accounts that use the ‘Minimum Transaction’ computation method are also subject to 2
types of transfers allowing the account holder to use his account or part of his account balance as a
guarantee or use its funds in an investment portfolio.

Note that the transfer for investment purpose can also serve for moving the funds (or part of these funds)
to another account in another branch.
1- Funds transferred for guarantee purposes: this option will be used, to transfer the account balance
(or part of the account balance) to a guarantee account. The point calculation process will detect
this transfer and will consider both accounts as merged (the term deposit account as well as the
guarantee account), and will compute points for the term account based on the combined balances
of both accounts.
2- Once the funds are transferred for investment purposes (or for moving the funds to another
account in a different branch), points will be kept for the main account during the month of the
withdrawal, and will be deducted from the total points starting the next month only (without going
back to the starting balance of the account or the latest deposit, as it happened normally with
accounts following the minimum transaction condition). Note that in this case, the user has the
choice of making the system create a hold transaction on the transfer amount to prevent the
account holder from withdrawing his funds from the new investment account before the end of the
month of the Adad calculation.
3- Full amount transfer is an option used to transfer the total balance of a term account to another
new term account. The two accounts must have the same computation method. Once this
operation is done, the system will make the following actions:
a. All transactions done on the first account, within the current profit distribution period, will
be considered as transactions of the new account. Thus will be taken into consideration in
the next point calculation process.
b. The maturity date of the new account is set to the lowest between both accounts.
c. Suspense account balance of the initial account is totally transferred to the suspense
account of the new account.
The full amount transfer option is restricted to one time for the same account
5.2.3 Ada’d Points Computation:

Ada’d points are computed on a monthly basis. Computation is subject to specific conditions defined at
accounting product level as described in the previous sections of this document.
Among the main conditions to be defined at product level are the following:
 Will Ada'd calculation be based:
o On the Accounting balances
o Or on the Available balances
 Will Ada'd calculation be based:
o On the Average balances
o Or on the Minimum balances
o Or on the Minimum Monthly Transactions (Only for Term Accounts)
o Or on the Daily Balance (Only for Sight Accounts)
For illustration purposes, reader may refer to the following examples:

5.2.3.1 Sight Accounts:

Sight accounts participating in the profit sharing would either be ‘Saving Account’ or ‘Call Notice
Accounts’. The formula for computing the yearly Ada’d points for Sight accounts is as follows:
A =∑ B × P
i
12
i=1 i
The Call notice account follows the same formula, however withdrawals that are not subject to the notice
implied by the bank, will loose from the total points, and the amount of the withdrawals, multiplied by the
notice period.
Where:
- Ai: The Ada’d points for the year
- Bi: The Balance to participate in Ada’d computation for month. (see above)
- P: The participation percentage for this account type.
5.2.3.2 Term Accounts:

In addition to “minimum balance conditions”,’ Term accounts’ may be also subject to additional
conditions such as:
 ‘Minimum Transaction Amount’
 Or ‘Modulo Amount’ Conditions
Whereby:
Minimum Transaction Amount:
If this condition is selected, deposited transactions will not be considered in the ada’d calculation,
unless the deposited amount is above a predefined threshold, (or unless it completes previously
deposited and not yet participating transactions so the total of these transactions will become
higher than the said threshold).
Modulo Amount Conditions:
If this condition is selected, the account balance that will be considered in the Ada’d calculation will
be the balance amount rounded down to the nearest multiple of the defined modulo.
5.2.4 Profit Distribution

Basically, profit distribution to customers takes place after deducting the Risk reserve, Bank Capital Share,
PER, and Bank Mudarib fees. For additional flexibility purposes ICBS provides at each type of account
(Accounting product) level the possibility to define different “Risk Share %”, “PER %” and “Mudarib Fees
%”. Consequently system allocates the respective amount in an automated way for each product type.
5.2.4.1 Distribution Process

Steps to be followed being:
1. Identifying and Booking the profit share of each Product (Account type)
2. Each Product Profit Share Allocation: For Banks that decided to define at each product level any of
the following Risk Reserve %, PER%, Mubarib %. This step will allow the respective shares
calculation and booking.
3. Customers’ Accounts individual profit share calculation
4. Customers’ Accounts profit release after possible tax deduction

5.2.4.2 Main Inquiries & Reports

 Accounts’ Adad Points Inquiry
 Products’ Profit Share Inquiry
 Products Profit Allocation
 Accounts’ Profit Share Inquiry
 Detailed List of Ada’d point
 Ada’d points cumulated by products
 Ada’d points cumulated by months
 Customer’s balances (Available or Minimum according to selected method)
 Profit distribution simulation
 Distributed Profit
5.2.5 Islamic Fixed Time Deposits Management

Under FTD the profit rate set at account opening is for illustration purposes while the effective profit will be
distributed as dividends according to effective realized profit. Fixed time deposit interactive functionality is
described under branch operations section. At this level we would highlight that FTD follow up functionality
includes:
a) A daily batch procedure will accrue profit
b) On Maturity Date and according to Product’s condition and customer’s instructions
system may:
i. Close the deposit and pay funds to a specific account
ii. Renew without profit
iii. Capitalize (Renew with profit)
iv. Renew with different maturity date or periodicity for the next period
v. Renew with different amount (Reduce) for the next period
vi. Renew with different (special) condition for next period
5.3 Central banks requirements

5.3.1 Main Features
Reports are parameterized according to Central Bank requirements. System administrator will be able to
amend the format, add or remove reports fields without the need of programmers’ intervention.
Reports formats are user defined using Microsoft Excel (except very few critical reports that are designed
using Oracle tools). Reports contents are user defined according to parameters specified by the Bank /
Institution. A cell content calls for information based on combinations of General Ledgers or Customers
accounts with the corresponding user defined criteria such as but not limited to: Balances sign, Maturities
and remaining days, Periodicities, Customers nature, Economic sectors, Residence code, Ranges of
amounts, Currency codes, Branch codes, Country codes, Credit Limits.
Moreover, these parameters allows the bank to define its own chart of accounts without being tied to
adopt the Central Bank chart of account
Information included in these reports covers details and hierarchy of totals: subtotals, totals, grand totals.
A built in facility allows duplicating parameters definition.

Reports printing can be either scheduled (daily, weekly, bi-weekly, monthly, quarterly, semi-yearly and
yearly) or upon request.


Reports definition is performed through 3 steps:
1. Define reports basic components (called also information code) where user will set for each component:
component / information code, description, information nature, consolidation indicator, results sign
restriction and of course source of information and predefined conditions.
2. Design the report format mainly using Microsoft Excel (otherwise Oracle tools will be used) in order to
draw the design and to indicate location of the report’s components.
3. Define report general information such as report name, related format, periodicity and other required
general information.
Usage of defined reports is according to the following sequence:
1. Periodical (preferably daily) data loading (a procedure that records all required elementary data).
2. Population of reports components (calculation and recording of parameterized information based
on elementary data and predefined parameters).
3. Once the components populated, reports can be printed either as scheduled or upon request.
5.3.3 Exchange of Information with Credit Bureau

Parametric configuration
Import Received Data & Updating Risk numbers
Preparing and Exporting Data
 Grouping: “Direct liabilities”, “Received guarantees”, “Off balance sheet liabilities”, “Fiduciary
Usage.
 Liabilities (Advances against: blocked account, banks guarantees, T. Bills; Advance against
mortgage; Advance against shares; Advance against personal guarantees; Overdraft; etc.)
 Financing deals types (Mid and Long term financing to productive sector; Housing financings,
Acceptances, Sponsored financings, etc.)
 Authorized / Used amounts (foreign and local currencies)
5.3.4 International Transactions Reporting System (ITRS)

ICBS offers a parametric tool for the generation of the file ITRS ‘International Transactions Reporting
System’ declaration file. It mainly consists of declaring transactions, between residents and non-residents,
which exceeds a predefined threshold. Declaration is performed by grouping transactions according to
related:
(i) A range of operation date
(ii) Customers’ economic sector classifications,
(iii) Customers’ residence codes,
(iv) Transactions purposes / reasons
(v) Transactions flow
 Total IN amounts between resident & non-resident
 Total IN amounts between non-resident & resident
 Total IN amounts between non-resident & non-resident
 Total OUT amounts between resident & non-resident
 Total OUT amounts between non-resident & resident
 Total OUT amounts between non-resident & non-resident

Thus the basic elements for such declaration are the:
a) ITRS Economic Sectors classification
b) Transaction Reasons / Purposes
c) Residence Code Table
d) Transaction Currency and Amount
And it affects operations of the following modules / functions:
 Dynamic Customized operations (usually teller operations)
 Checks remittances and checks returned unpaid
 Received checks
 Draft Checks
 Certified Checks
 Standing Orders
 Bills Management
 Financing Modules
 Outward / Inward transfers
 Letters of Credit Payments
 Bills for collection payments
 Stock / Equities deals
 Profit Posting
Note: This of course requires the related modules to be implemented.
5.3.5 Fights Against Money Laundering

In order to assist banks in their fights against “Money Laundering”, a set of procedures and controls were
made available in ICBS thus allowing to:
 Monitor and Report Cash Transactions (CTS)
 Detect suspicious international payments: Incoming (Inward) transfers, Outgoing (Outward)
transfers and Draft checks issuance.
Note: This of course requires the related modules to be implemented.
5.3.5.1 Cash Transactions
Banks are invited to define a set of ceilings and attribute appropriate thresholds to customers according to
their activities (Standard retail customers, Supermarkets / Malls with high cash transactions, Petrol
stations, etc.).
Whenever customer’s total deposits within a predefined period exceeds its respective threshold, a message
is generated to the teller’s supervisor (or to the manager in charge of cash transactions monitoring)
requesting his approval. Also, system automatically produces a Cash Transaction Slip (CTS) to be signed by
the depositor.
Moreover, ICBS provide a set of reports and inquiries to produce:
a) Statements of deposits and withdrawal operations based on user defined criteria such as
customer’s total deposits within a selected period,
b) List of accounts subject to frequent foreign exchange operations involving cash deposits,
c) Etc.

5.3.5.2 International Payments
These procedures were implemented to help the bank detecting and monitoring suspicious Incoming /
Outgoing payments transactions.
The bank will start by:
 Defining countries within groups such as: Local country, GAFI members, Other Group of countries
to be monitored, all other countries.
 Classifying customers within categories such as: Privileged Customer, Very Important Customer,
Important Customer , Normal Customer, Unclassified
 Attributing thresholds / ceilings for each combination of countries group and customers’ class.
System detects payments operations exceeding respective thresholds and requires management decision.
In case of approval, operation will resume normally, otherwise:
 Outgoing payments will be refused and recorded into log files for further reporting.
 Incoming funds will be credited to temporary account and recorded into a log files waiting for
further processing.
5.4 Reconciliation
5.4.1 Nostro Accounts
Selecting Nostro Accounts to monitor
Recording our Books Transactions:
 On daily basis (Movements Files)
 Periodically (Historical File)
Reception of Correspondents statements
Correspondents’ statements of accounts are either transferred into ICBS database (if received under
standard formats like SWIFT MT950) or keyed in.
Batch reconciliation – Multiple Matching rules
Automatic procedure will try to match the statements entries with the system-stored entries according to:
 Reference, Value Date & Amount
 Reference & Amount
 Value Date & Amount
Possible Manual Reconciliation function, user can manually reconcile the unmatched entries. Manual
reconciliation can be one to one, one to many or many to many.
A set of reports and inquiries showing collected data, reconciliation results (Matched / Unmatched),
Pending transactions and Actual situation.
5.4.2 G/L Accounts

Reconciliation Configuration
 Accounts Selection
 Same account, Or different account with possible crossings
Recording Transactions:
 On daily basis (Movements Files)
 Periodically (Historical File)
Batch reconciliation – Multiple Matching rules
Possible Manual Reconciliation


5.4.3 Reports and inquiries

Showing collected data, Reconciliation results (Matched / Unmatched), Pending transactions, Situations:
 Nostro account Matched entries
 Nostro account Unmatched entries
 Inter-entities G/L matched entries
 Inter-entities G/L Unmatched entries
5.5 Card Management, ATM, POS and CDM Interface

5.5.1 Card Management Interface
ICBS Card Interface sub-module provides comprehensive set of functions offering:
 Cards Products Definition (Credit Cards, Debit Cards, Charge cards) with related conditions
 Card requests (New, replacement, stop, etc.) application, multi level approval and submission to
the Card management system for further issuance / further processing.
 Acknowledgement / notification reception and update.
 Card delivery to customer triggering request for activation to the Card Management system.
5.5.2 ATM, POS and CDM Interface

ICBS ATM/POS / CDM provides interface with major ATM/POS Switches / monitors and CDM solutions. It
offers:
 ISO 8583 messages based On-line authorization or Bi-directional notification of transactions
updating accounts balances in an on-line mode
 Possible Batch procedures update of historical data or verification.
This interface handles different types of ATM transactions mainly:
 Cash withdrawal
 Cash Deposits
 Check book request
 Statement of account
 Account situation
 Checks deposit
 Account to account transfer
 Travelers checks purchase
 Utility bills payment
As well as POS Purchase and Refund transactions
5.5.3 Credit Card Transactions Interface

ICBS Credit Card Transactions interface Cover:
 Transactions File Reception and Processing
o Purchase (POS)
o Purchase Foreign Exchange
o Cash withdrawal / ATM transactions
o Cash withdrawal fees
o Refund
o Profit
o Payment
o Other Fees (Membership, Collection, etc.)
o Minimum due amount

o Adjustments

 Collection of due Amounts (Standing Instruction, Direct Debit, Domiciliation, etc.)

 Deposits
 Payables Settlement (Credit Card companies, PPI Insurance)
 Card fees accrual
 Commissions on POS
 Past due payments
o Penalty accruals
o Transfer to past due
o Settlement and Reactivation
 Cash Back / Bonus
o Instruction reception and recording
o Cumulating outstanding
o Reporting
o Payments
5.6 Office tools integration

ICBS integrates Microsoft Office word and excel.
Customers’ documents templates can be defined as word documents or excel sheets; ICBS engine
generates documents accordingly.
Statutory reports can be designed using excel sheets templates, ICBS engine generates outputs accordingly.
5.7 SWIFT Solution Integration

ICBS provides a configurable S.W.I.F.T. interface allowing the system to generate messages according to the
latest standards as defined by S.W.I.F.T. and to receive and interpret S.W.I.F.T. messages emanating from
other financial institutions thus reducing operator capture time.
The main functionality is:
 Definition of SWIFT standard formats (as per SWIFT regulation): Type of messages, sequences,
fields, lines, divisions and sub-divisions
 Assignment of the defined messages types to the various ICBS international modules database.
 Automatic generation of the SWIFT messages using predefined format and operations information.
 Parsing of received SWIFT messages thus optimizing user capture time.
For example:
- The Outward transfers module automatically generates the messages MT103 and MT202 upon operation
validation.
- A received message MT103 will fill in an Inward Transfer transaction and therefore, the operator
intervention will be reduced to the minimum.
Generated messages are transferred to the SWIFT terminal for further validation, (test key) and in order to
be transmitted to the adequate financial institution.

5.8 Emails, SMS, IVR and mobile banking integration

ICBS generated documents, statement, certificates and printed reports can be posted to the Bank’s email
server for dispatching.
Also ICBS provides a facility where transactions occurring on a customer’s account can generate a short
message that can be posted to the Bank SMS server for notification.
Integration with SMS (Push and pull) and WAP solution allows for customer to be notified about
transactions occurring on his account and to initiate transactions in ICBS.
Sample of received notification (Push Message)
 Amount withdrawals or any other debit
 Check collection, Received Salary or any other credit
 Standing instruction execution status and events
 Periodic balance reporting
 Insufficient fund alert
Sample of Initiated Transaction (Pull Message):
 Balance enquiry
 Mini statement request
 Stop payment
 Reporting stolen / lost card
 FX rate or Profit rate inquiry
 IVR solution can be hooked to ICBS for information retrieval as well as for possible transaction
initiation.
5.9 Signature verification and Fingerprints Solution Integrations

ICBS offers a set of functions allowing:
a) Signatures/ Fingerprint management:
 Scanning (through Interface with scanner devices and drivers ) and attaching signatures to
individual person profile
 Configurable Fingerprint capturing (through Interface with fingerprint devices and drivers) and
attaching fingerprints to individual person profile
 Define Customer's / Customer's Account Allowed Signatures / fingerprints by ranges of amounts.
b) Signatures browsing and Fingerprints verification during transactions processing:
 Front office / Tellers operations Signature browsing and / or Fingerprint verification during: Cash
Withdrawal, Account to account transfer, Draft Check issuance request and the like.
 Back office signature browsing during processing of Checks received from clearing house.
c) Set of inquiry functions
 Inquiry on signatures attached to an individual profile
 Inquiry Customer or Customer's Account signatures / fingerprints conditions
 Inquiring on transactions and browsing respective presented signatures / fingerprints

5.10 Integration with Electronic Checks Processing (ECC) Solutions

On line interface with ECC solutions / Gateway covering various scenarios incoming and outgoing checks
including:
1. Purchased checks drawn on other banks (Remittance)
a) Remitted checks are captured at ECC solution level
b) ECC solution calls an ICBS procedure that returns the customer's (remitter's) name, account's to be
credited status and any other required information.
c) ECC solution transfers the required information to the Central Bank / Drawn On bank requiring
authorization to honor the check.
d) In case of authorization, ECC solution calls another ICBS procedure that posts the required accounting
entries; Otherwise in case of rejection a commission may be perceived.
2. Received Checks (checks drawn on us and remitted at other banks)
a) A signal initiated by Central Bank / Remitter Bank is received by ECC solution. ECC solution calls an ICBS
procedure that returns the customer's (drawee's) and the check's required information.
b) ECC solution performs the technical checking. In case the check is technically valid an ICBS procedure is
called to perform ICBS internal checking (account's status, available balance, again check's status, etc.) and:
b.1) If conditions are satisfied, triggers the required accounting entries generation, updates the
check's information and return to ECC solution a successful return code.
b.2) Otherwise ICBS returns an error code and triggers a commission deduction transaction and
updates check's information.
b.3) ECC solution may call an ICBS procedure to force account debit and check settlement.
c) ECC solution reports the outcome to Central Bank/Remitter Bank
5.11 National Payment Systems, RTGS and ACH solutions

Interfacing with third party solution and Gateways to handle RTGS and ACH Bulk and Individual messages
to:
 Issue generate payment instructions
 Process received payments instructions
 Performs reconciliation
For instance RTGS interface covers formatted Payment messages, Credit Advice, Debit Advice, Statements
and Acknowledgement messages.
While ACH interface covers formatted Small value payment orders (SVPO), Direct debits (DD), Direct Debit
refusals (DDR), Checks (CH) and Check refusals (CHR).
Received messages (single or multiple instructions) trigger ICBS procedures to parse, decode validate and
process the received instructions according to defined business rules and accounting schemas. Processing
can be in STP on line mode, or subject to supervisor final confirmation or in Batch mode.
For outgoing messages ICBS functions and according to configurable business rules, generates the required
message and transmit it over the RTGS interface for dispatching purposes.
Batch reconciliation procedures are implemented according to business rules.

5.12 Integration with E-banking solution

Interface with E-banking solution allows for customer to perform comprehensive query and transaction
through the internet including:
 Balance inquiry
 Statement of account
 Fixed term deposit inquiry
 Transfer to third party beneficiary
 Checkbook request
 Credit Card request
 Bill settlement
 FX and Profit rates query
Also bank may make use of the E-banking interface to distribute e-certificate and e-statement with
publishing of marketing and advertising messages.
Note: Also ICBS E-banking interface allows for advanced operations such as Letter of Credit, Letter of
Guarantee and Financing deal Application, Trading portfolio query and follow up.
5.13 Other Central Processing Operations

Central Processing Department may process operations in relation with other modules detailed in the
corresponding paragraphs; these are mainly related to:
a) Corporate employees’ salaries processing: Uploading received files or data. Automatic posting
to customer accounts after verification.
b) Inward clearing: Automatic captures and uploading of data. Provision for entry and
verification in case of manual postings. Automatic routing / report printing of overdrawn checks
to appropriate branch /credit officers.
c) Outward clearing checks (not on us checks) facility to compile details of checks based on the
local bank codes for the purpose of preparing required files.
d) Inward remittances (See international payments hereafter)
e) Standing instructions processing
5.14 Selected Reports

5.14.1 Situation, Analysis Reports & Financial Statements
 Accounts’ Situation: Banks By Currency And Country
 Accounts’ Situation: GLs And Auxiliaries
 Accounts’ Situation: Third Parties (Clients, Suppliers, Etc.)
 Accounts’ Statements: GLs And Auxiliaries
 Accounts’ Statements: On Request
 Accounts’ Statements: Periodical Statements
 Accounts’ Statements: Received From Banks
 Accounts’ Statements: Third Parties (Customers, suppliers, etc.)
 Assets & Liabilities Report
 Average Balances: GL And Auxiliary Accounts
 Average Balances: Third Parties (customers, suppliers) Accounts

 Balance Sheet
 Cash Accounts’ Situation
 Customers’ Credit lines report
 Customers’ Situation By Date
 Customers’ Deposits by Currency / type of accounts
 Customers’ Deposits by Branch / Currency / type of accounts
 Debtor Accounts By Customer Natures
 Debtor Accounts By Economic Sector
 Debtor Aging Report
 Detailed Balances At A Given Date
 Detailed Debtor Accounts Situation
 Detailed End Of Month Balances
 Foreign Currencies Positions
 GL Detailed Accounting Balances
 Group of GLs Detailed Balance
 Historical Transactions List/Date
 Profit Accruals
 Incomes & Expenses List
 Multiple Criteria G/L Balances Report
 Non Resident Customer Accounts Details
 Non-Resident Customer. Situation By Country
 Payables / Maturity Date (Aging)
 Payables Report
 Profit & Loss Reports
 Receivables / Maturity Date
 Reevaluation Report
 Summary Journal
 Treasury Position Report
 Trial Balance
 Trial Balance At A Given Date (Selective)
 List of value date balances
 List of stopped checks
 Deposit accounts profit
 Deposit accounts accruals
 Passbook suspended entries
 List of requested checkbooks
 Term accounts maturities diary

5.14.2 Consolidation and MIS Reports

 Consolidated Auxiliary Balances by Currency/Type/ID
 Consolidated Balances according to user defined GL Groups
 Consolidated End of month Balances
 Consolidated G/L accounts situation
 Consolidated GL Balances
 Consolidated GL within a range of user defined dates
 Foreign Currencies Consolidated Balance
 Global Consolidated Balance
 Profit & loss reports
 Profitability reports (customers, branches, etc.)
 Treasury position reports
 Assets / Liabilities reports
 Expected Cash flow reports
 Statistical reports
5.14.3 Other Sample Reports

‫كشف بوضعية العمالت األجنبية المقومة بالعملة المحلية‬ 
‫كشف بأجمالي حركة المشتريات و المبيعات من العمالت األجنبية مقومة بالعملة المحلية‬ 
‫وضعية مراكز القطع‬ 
‫ البنك في الخارج بالعملة االجنبية‬9‫كشف تفصيلي بتوزيع اداعات و استثمارات‬ 
‫مدينة مختلفة‬ 
‫دائنة مختلفة‬ 
‫الميزانية‬ 
‫تحليل العمولة‬ 
‫المصروفات‬ 
‫إيرادات االستثمار‬ 
‫إيجارات مستحقة غير مقبوضة‬ 
‫أرباح مستحقة غير مدفوعة‬ 
‫مقيم بالعمالت األجنبية‬ 
‫غير مقيم بالعمالت األجنبية و المحلية‬ 
‫ودائع البنوك المحلية باألجنبي‬ 
‫ودائع البنوك المحلية بالعملة المحلية‬ 
9‫ودائع البنوك الخارجية باألجنبي‬ 
‫ودائع البنوك الخارجية بالعملة المحلية‬ 
‫األثاث المستجد و المباع‬ 
‫الموجودات و المطلوبات‬ 
‫أرصدة الفروع المحلية‬ 
‫أرصدة البنوك المحلية‬ 

‫‪BML Istisharat‬‬ ‫‪ICBS - Islamic‬‬
‫أرصدة البنوك الخارجية‬ ‫‪‬‬
‫الكمبياالت المخصومة و القرض الحسن‬ ‫‪‬‬
‫الكمبياالت المستحقة غير مدفوعة‬ ‫‪‬‬
‫تمويل المضاربة‬ ‫‪‬‬
‫تمويل المشاركة‬ ‫‪‬‬
‫تمويل المرابحة‬ ‫‪‬‬
‫تمويل المرابحة المستحقة‬ ‫‪‬‬
‫كمبياالت التمويل‬ ‫‪‬‬
‫كمبياالت تمويل ستحقه غير مدفوعة‬ ‫‪‬‬
‫المكشوفين في الحسابات الجارية‬ ‫‪‬‬
‫أرصدة و مخصصات العمالء في الكفاالت‬ ‫‪‬‬
‫الكفاالت التي انتهت مدتها و لم تعد‬ ‫‪‬‬
‫كفاالت المراسلين‬ ‫‪‬‬
‫االعتمادات المستندية‬ ‫‪‬‬
‫بوالص االعتمادات‬ ‫‪‬‬
‫شيكات التحصيل باألجنبي‪9‬‬ ‫‪‬‬
‫حوالت واردة‬ ‫‪‬‬
‫حجم التعامل مع البنوك الخارجية‬ ‫‪‬‬
‫حساب االستثمار‪ 9‬المخصص‬ ‫‪‬‬
‫المقايضة ـ السواب‬ ‫‪‬‬
‫االستثمارات الخارجية‬ ‫‪‬‬
‫الشيكات المعادة‬ ‫‪‬‬
‫الشيكات المؤشرة‬ ‫‪‬‬
‫الحسابات المفتوحة‬ ‫‪‬‬
‫محضر جرد موجودات النقد‬ ‫‪‬‬
‫حركة تعاملنا مع الصرافين‬ ‫‪‬‬
‫قروض القطاع الخاص الخارجية‬ ‫‪‬‬
‫أرصدة الوزارات‪ 9‬و الدوائر و المؤسسات‬ ‫‪‬‬
‫النقد المنقول‬ ‫‪‬‬
‫موجدات النقد ‪ /‬مكتوم‬ ‫‪‬‬
‫البيانات النقدية الشهرية‬ ‫‪‬‬
‫تحاويل االستراد و الحسابات النظامية‪.‬‬ ‫‪‬‬
‫المشتريات من لعملة االجنبية من البنك المركزي‪9‬‬ ‫‪‬‬
‫المشتريات من لعملة االجنبية من البنوك الخارجية‬ ‫‪‬‬
‫‪Capabilities Guide -‬‬ ‫‪© Copyright BML Istisharat‬‬ ‫‪CAPG I 2015.1- Page 81‬‬
6 BRANCH OPERATIONS MODULES

6.1 Introduction
ICBS Branch Operations modules offer a comprehensive Branch Universal Front Office (tellers) and Back
office solution covering operations on all defined accounting products including Current and Checking
accounts, Saving and Time deposit accounts.
ICBS branch operations modules are fully integrated with all other ICBS modules and share the same centric
database and customers’ information system, same standards and features including Groups and User
profiles access rights, Audit trails, Standard user friendly graphical user interface with help facilities and
drop down lists, same accounting and documents engines, multilingual, multi entity and multi currency
capabilities, On line Real time local and inter branch transactions processing validation and control, black
lists and interactive AML limits controls, comprehensive global inquiries with drill down to details, rich set
of reporting functions and all other features stated under Section 4: ICBS Nucleus and Standard Features.
6.2 Customers Information System

CIS accesses including possible global view with drill down to details access, possible update, signatures and
fingerprints verification abides by the same standards and benefit from all the previously illustrated
features.
In particular, authorized teller, attended by the system multi criteria (IDs, name, etc.) searching features
and wild cards, may accesses customers’ global view function, browse selected customers’ consolidated
information and drill down to details including:
 Customers’ global information and relationship
 Customers’ Held accounts (Conventional and Islamic) details, balances and conditions
 Customers statement of accounts
 Transactions details and status
 Account’s annotation / referrals
 Overdraft history
 Statistical data
 Standing Orders
 Value date balances (floats) and corresponding details (Operation with forward value date
including checks and clearing).
 Accruals and Profit
 Historical transactions
6.3 Accounts Opening, Closing and Maintenance

Full integration with ICBS nucleus modules allows user to:
 Browse the products’ catalogue and bank offering; inquire about the related terms and conditions
and in order to transmit it to customers.
 Performs account opening / closing transactions in accordance with products inherited conditions.
 Generates the required documents (passbook, accounts conditions, etc) and triggers requests for
available services such as checkbook, ATM card and possible PIN generations through possible
interfaces.
 Perform authorized maintenance and update action: Update Customer data, change accounts
condition, change accounts status, block account, set referrals, set manual annotation. Operation
updates abiding by Maker and Checker concept and that will be effective only after required
manager validation.

6.4 Transaction General Procedure
On line validation during data capture including:
 Customers Accounts and Checks status (Stopped, already used, etc.)
 Preset restrictions (Currency, Branch, User, Product / Type of accounts, Cash limits, Compliance
Limits, etc).
 Customer granted lines excess (percentage and max amount)
 Users limits excess (operation amount, override of default values)
 Customer signature visualization and fingerprint checking
 Dormant account checking
 MICR / OCR checks reading
Electronic messages (notifications) to / from supervisor for exception approval / rejection while freeing
teller. Automatic generation of accounting entries and On line update of balances and positions.
Popping-up of warning and annotations (Flashing messages) whenever account is accessed through any
interactive function:
 Warning informative message/invitation for a required action
 Supervisor validation
 Blocking.
Alert for possible blacklisted customer.
Immediate update of Passbooks (or recording into suspended entries).
Automatic generation Receipts / Customers’ documents (Possibility of reprinting)
Monitoring /Tracking on cash balances, customer’s activity with position view with drill down possibility to
details.
Authorized user may also post a reservation / hold an amount on a part or the whole account balance.
Reservation posting abides by the same validation processing and control as for debit operation.
Sweep: Automatic transfer of funds - between same currency and cross currency accounts when balance
falls below or exceeds pre determined limits
Flexible Reporting; Security / Logging / Audit Trail
6.5 Exception Handling, Override and Validation Process

As per the facilities and standards described under section 4.5 “Security and Transactions Control”.
6.6 Usage of Configurable Operations

6.6.1 ICBS Customized Operation Module
In accordance with ICBS configuration tools and parameters, “ICBS customized operation module” allow
tellers and branch users to operate completely configurable operations (screens, formulas, accounting
entries, advices) such as:
 Cash Movements: Withdrawal, Deposit, Debit Note, Credit Note,
 Account to account transfer,
 Purchased checks drawn on the Bank (or Check encashment),
 Purchase travelers’ checks
 Visa / Credit Card advance

 Debit / credit advice, utility bill settlement at counter, etc.
All transactions and according to predefined parameters can integrate foreign exchange operations thus
allowing for operations such as:
 Withdrawal with FX
 Deposit with FX
 Account to account transfer with FX,
 Purchase and Sale of Foreign currencies
 FX Cash to Cash
6.6.2 Other Operations Through dedicated modules

Other more complex operations may be subject to multiple events, flow of transactions and consequently
are ensured through ICBS dedicated modules to offer comprehensive automated follow up.
These modules are detailed through the various sections of the present document (for instance: Checks
clearing and collection, postdated checks, selling traveler checks, draft checks, contract based fixed time
deposit, standing instructions setup, multiple transfer, inward/outward transfer).
While it is worth re-stressing on the fact that all operations whether initiated by “ICBS Customized
Operation” module or through any other ICBS module, do share the same accounting generation engine,
value date calculation engines, commissions / charges calculation engine, customers’ document generation
engine and abides by ICBS general standard control and validations rules.
6.7 Passbook Management and update

Deposit accounts’ possible passbooks are updated by the system. Operator has to feed in the passbook at
the time of transactions data entry. But if the passbook is not available, or movements are issued by batch
processing (after profit distribution for instance), the movements are sorted until passbook is again
available. At this time, all movements in suspense are updated at once.
Upon account opening system issues a first passbook. New passbooks are issued when the previous one is
full or upon customer’s request after proceeding with the required verifications.
System allows handling passbooks stock centrally and at branches level. System provides dedicated
functions for distribution to branches, reception confirmation or return to central stock.
A number of reports / query function allow following up passbooks stocks, Allocated passbooks as well as
Movements in suspense waiting to be printed.
6.8 Branches and Cashiers Management

6.8.1 Branch Initiation and Maintenance
A main advantage of ICBS full integration and centric solution approach is that a new branch can be opened
in no time and maintained centrally with minimum efforts.
As far as ICBS is concerned, in most cases, opening a new branch, only requires that system administrator:
 Sets the branch attributes within the Branches entities
 Launches a procedure that generates the branch required accounts
 Defines the various tellers and sets the users profile by attaching them to the related groups profile
Branch will be immediately operational.
Obviously in case the business rules set by the Bank includes possible restrictions or special handling by
Branch, these may need to be extended to this new branch. Authorized administrator will set the business
rules accordingly.
Note 1: In accordance with the bank business rules and policy user profile may be managed centrally and or

by branch authorized officers or managers.
6.8.2 Branch Sessions and Cashiers Management

A set of functions to automate workflows driving daily branch and working sessions opening, multi
currencies cash distribution and control management, session and branch closing.
Branch System Opening: At the beginning of the day system opening by the branch manager or assistant
manager.
Branch Session Opening: At the beginning of the session, shift opening by supervisor or higher level
allowing tellers / users to log in. Possible distribution of cash to the branch’s various tellers / cashiers from
the branch main vault.
Teller Session Opening: Following the session opening by the supervisor, Teller logs in at a desk and
confirms the eventual received cash amounts.
Teller’s Transactions: Tellers will start operations and system monitors and updates timely the cash
balances.
 If cash balance drops below predefined threshold (Cash Low) system issue a cash request to the
supervisor in charge (optional).
 If cash balance exceeds predefined threshold (Cash Excess) system issue a notification message to
the supervisor (Alert Message).
 At any time during the day, teller may transfer / receive cash to / from other tellers or main vault
Cash transfer between tellers, between teller and branch vault, between branch vault and main vault,
transfer to / from ATM / CDM.
Teller Session Closing / Cash balancing: Cash balancing can take place at any time during the day. At end of
session teller will balance his cash and return amounts exceeding his overnight allowed balances to the
main vault.
Branch Session Closing: At the End of the Session, Shift closing by supervisor or higher level. After collecting
back the cash amounts and making sure that all tellers have closed their respective sessions, branch
manager or person in charge will launch the closing session process. A facility allows forcing still active
tellers to log off. Also tellers will not be able to log-in or perform any operation before a new day / session
is opened.
Branch System Closing: At the End of the day, system closing by the branch manager or assistant manager.
Note 1: Branch vault supply: Periodically or upon request exchange of cash between Branch Main vault
and External sources or Head office. (Receiving Cash From Supplying Co / Head Office and Returning Cash
To Supplying Co / Head Office).
Note 2: Head Office main vault supply: Periodically or upon request exchange of cash between Head Office
Main vault and External sources (Central Bank or Supplying company)
Note 3: All transactions recorded in a Log table. Log records will be used to reconcile cash transfers
(confirmation by the receiving party) and inquiry / reporting purposes.
Note 4: System monitors and updates in real time mode accounts balances being affected by the various
users’ transactions. Moreover, and in the context of centralized configuration, inter-branch operations
accounting entries generation can (subject to the bank selected accounting schemas) follow the same rules
as local operations. Also system does not accept unbalanced operations.
Note 5: Opening and Closing vaults operations as well as Cash Supply, Reception Acknowledgement Return
and Transfer calls for Cash Currencies Denominations Quantity Counting and Recording to be reconciled
with vaults / tellers cash balances.

6.8.3 Other end of day branch processing

ICBS provides facility so End of Day would be run centrally for the branches and for the head office limiting
branch End of Day process to cash closing/balancing and producing branch reports.
Nevertheless bank may decide to run branch end of day. For instance triggering procedures related to
 Checks dispatching settlement
 Standing instruction execution
 Bulk payments/settlement
 Interbranch account settlement/reconciliation
 Foreign Exchange revaluation
 Closing Foreign Exchange P&L
 Closing Forex Exchange position with head office
6.9 Islamic Fixed Time Deposits Management

Under FTD the profit rate set at account opening is for illustration purposes while the effective profit will be
distributed as dividends according to effective realized profit.
6.9.1 Setting a new Fixed Deposit (As part of the Branch Operation)
The General workflow for a FTD contract booking governed by maker and checking concept would be as
follows:
Step 1: Open a deposit account in the currency of the deposit using the general purpose account opening.
The account type product to be selected would be in accordance with the projected FTD deposit product.
Step 2—Optional: Making available funds through funding account (Customer’s current or saving account)
using one of the available teller’s operations. For example make use of:
a) Cash deposit
b) Account to account transfer
c) Inward transfer (remittance)
Step 3: Book the Fixed Deposit contract using the “Fixed Deposit Opening” function to:
a) Select the adequate product. The FTD opening process will be conditioned by the conditions
defined at Product Level.
b) Setting the deposit maturity date and entering the deposit amount
c) Optionally FTD may have a different periodicity for profit payment
d) Selecting a previously opened FTD account in accordance with the selected product
e) System generates the default tiered rate according to the selected product, currency code, deposit
of amount and maturity date. Rate may be changed within user’s allowed margin but will be
highlighted during supervisor validation.
f) Setting the default renewal instructions:
 Close at Maturity and pay funds to specific account (No renewal allowed)
 Automatically Renew without profit
 Automatically Renew including profit
 Suspend renewal action waiting for instructions
g) Selecting the funding account for the initial deposit.
h) Selecting the account that will be credited by the foreseen profit.
Step 4: Fixed Deposit Validation by a supervisor who will be able to browse the deposit conditions with
highlighted eventual changes to standard product’s conditions. Upon validation system generates, and in
accordance with defined parameters, the required accounting entries as well as customer’s documents
including possible certificate of deposits.
Note: Multiple Fixed Time Deposit contracts can be accounted on the same FTD account, each deposit
will abide by its own conditions. A facility allows FTDs maturating the same day to be merged into one

contract during rollover.
6.9.2 Fixed Time Deposit Follow Up

During the life of the Fixed Deposit:
c) A daily batch procedure will accrue profit
d) According to Product’s condition, profit may be settled periodically to the selected
profit account.
e) At any time, customer may decide to amend the Deposit’s Instructions within the
Product’s constraints / conditions. For instance customer’s may decide to :
i. Amend the previously set renewal instructions
ii. Change the deposit current and profit accounts
f) Customers’ document such a Certificate of Deposits can be reprinted.
On Maturity Date:
a) Customer’s, and always within Product’s constraints / conditions, may call to:
i. Close the deposit and pay funds to a specific account
ii. Renew without profit
iii. Capitalize (Renew with profit)
iv. Renew with different maturity date or periodicity for the next period
v. Renew with different amount (Reduce) for the next period
vi. Renew with different conditions for next period
b) Otherwise, if customer didn’t call to amend the deposit instructions, system will
execute the previously set Deposit Conditions during the End of Day Process.
c) If customer didn’t call on maturity date and if the renewal instruction was set to
“Suspend waiting for instructions”, system will settle the profit according to the deposit
instructions and leaves the deposit in a wait status waiting for further intervention.
Partial withdrawal and premature closing
a) If allowed, partial withdrawal would be performed subject to product’s predefined penalties
b) Allow premature closing is subject to conditions and penalties.
6.9.3 Main Reports & Inquiries

1- Daily Transaction Register
2- Outstanding Customer Deposits
3- FTD Maturity Diary
4- Average Rate
5- Accruals results
6- FTD Events
6.10 Checkbooks management

6.10.1 Different Types of checkbooks
The bank might use different types of checkbooks. Checkbook types differ by their format and the number
of checks per checkbook. ICBS allows the definition of different types (format and/or number) of
checkbooks. For each different type, the bank defines:
 The checkbook type (two numeric characters code).
 Its description in two languages, and

 The number of checks for the checkbook.
 Charges per checkbook that can be perceived upon order, reception or allocation level.
6.10.2 Complete checkbook order and delivery workflow:

A complete set of function ensuring full process automation:
 Request received at branches or through delivery channels (Branch, Internet, ATM or any other
service channel made available by the Bank)
 Possible request cancellation
 Requests consolidation at Head office,
 Interface with checkbooks printing solution or formatted file transmission to manufacturer for
printing
 Printed checks reception along with checkbooks details and uploading / recording at head office
level / Stock Management
 Possible cancellation of received printed checks
 Distribution to branches,
 Branches stock management
 Allocation / Delivery to customer
 Possible revoking from customer.
ㄱ The check can afterward be presented for payment:
ㄱ At a counter, or
ㄴ Via clearinghouse
ㄴ If a check is refused, the refusal is registered along with the refusal reason, amount, and beneficiary.
ㄷ Checkbooks stock management where a checkbook can be in one of the following status:
ㄷ Ordered
ㄹ Ordered and sent for printing
ㅁ Printed and in stock at Head Office
ㅂ Printed and in stock at Branch
ㅅ Delivered to customers
ㅇ Destroyed / Scratched
ㄹ A check status can be one of the following:
ㅈ Valid (not yet used)
ㅊ Paid
ㅋ Certified
ㅌ Refused
ㅍ Stopped
ㄱ Users can inquire about the checks/checkbooks status and details by customer account or check
number.
ㄴ System may issue notification for checkbook reorder.
6.10.3 Handling of personal printed checks.

ICBS allows handling or personal checks (I.e. checks printed by the customers). Usually bank is not aware
of these checks unless they are presented for payments or stopped.
Nevertheless, ICBS provides additional facilities allowing recording received personal checks details. For
instance and for additional security reasons, customers would send the checks details to the bank asking
him not to pay non-declared checks. Checks declaration may be restricted to the numbers of the checks

issued or may also include information such as: Declared amount, declared issuing date, declared
beneficiary name and details. In such cases ICBS is able to check these details upon payments.
6.10.4 Stop Payment:

A set of functions for the registration and follow up of checks stopped from payment.
 Based on customer’s instruction, users might stop a series of checks or a complete checkbook from
payment.
 The stop payment reason and the checks details are registered.
 Only valid check are accepted for stop payment
Charges can be perceived for stopped checks.
 Among the handled information are:
a) The data entry date, time and user code (effective system date and time are stored).
b) The reason for stop payment: check's lost, stolen, etc.
c) The drawer, beneficiary, amount and issuance date.
 If a stopped check is presented for payment (at counter or received through the clearing house), the
operation is suspended waiting for supervisor's approval.
 A stop payment can be later on Removed or Cancelled if necessary.
 Stop payments events (Stopping and Removal) are recorded in a log table for further review,
investigation and printing.
6.10.5 Selected Inquiries and Reports

 Inquiry about checks by account number.
 Inquiry about stop payments:
 Inquiry About Check Stop Payment History
 Requested Checkbooks list
 Checkbooks not yet delivered to customers
 Status of Checkbooks delivered to customers
 Stop payments report.
 Situation of stopped checks:
6.10.6 Certified checks

ICBS offers a set of function to manage checks certification request as well as related the payment
operations.
Certification procedure
Keying in the account number to be debited and the check number to be certified in the account currency.
The check number should be a valid check belonging to this customer.
The certification date is generated as today’s date.
Keying in the check amount and the beneficiary name.
The commission amount and the value date are generated by default and can be modified within the user's
limits.
Allow capture of commission account and exchange operation if commission account currency is different
from check’s currency
Upon confirmation
Customer account is debited

A transitory account is credited.
Corresponding customer’s advices are generated.
Payment of a certified check
The payment of a certified check is similar to an ordinary check. It may be presented at the counter or
through the clearinghouse. The difference is that the temporary account credited at certification time will
be debited instead of the real customer account.
6.11 Local Checks Remittance and Collection

6.11.1 Preamble
Checks remitted at the banks may be:
Clearing Checks: To be cleared through the “Clearing House”
Checks for collection: To be sent for collection through other banks.
 In the first case “Clearing Checks”, the bank usually credits immediately the customer’s account with an
adequate forward value date / float. Nevertheless some banks may even settle immediately the check’s
amount; these checks will be referred to “Purchased Checks”. While some other banks prefer to credit
the check’s account to transitory accounts waiting for clearing confirmation.
 In the second case “Checks for collection”, banks credit transitory accounts (The transitory account is
system generated) until receiving collection confirmation. Thus real customers’ accounts are credited
only after collection through a specific payment function. Payment is interactively requiring user
intervention or in batch mode.
Returned unpaid checks
ㄱ These may consist of:
1. Clearing checks
1. Checks sent for collection
ㄴ In the first case, the checks are returned through the “Clearing House” and remitting customers are
debited back accordingly.
ㄷ In the second case, the “Payable at / Drawee bank” decision is communicated to the remitting
customers and transitory accounts debited accordingly.
Received checks
ㄹ These consist of checks drawn on the Bank’s customers and presented for payment through
clearinghouse.
ㅁ After processing the required checking, the bank will either:
Honor the check by debiting the customer account
Or, refuse the check and return it back.
Consequently, this module provides functions at:
ㅂ Branches level (remittances)
ㅅ Branches in charge of clearing checks level
ㅇ Selected Remittance features
o Possibility to enter remitted checks
 Manually or using MICR readers (in case of local checks)
 Without previous sorting by region
 Multiple checks per remittance
o Possibility to credit a customer account with a currency different from the checks currency.

o System generated / retrieved clearing region
o System generated value dates are based on parametric number of days set by Clearing region and
Currency code and taking into consideration holidays as well as possible Customer’s particular
conditions.
o Generated commissions are on parametric formula set by Clearing region and Currency code and
taking into consideration possible Customer’s particular conditions
o Generated accounting entries per region and value date
o Generated Labels
o Generated customer’s receipts (possibility to have different receipts grouped by region and value
dates).
o Possibility to cancel:
 A remittance (All checks)
 A check (with advice generation and reprinting of the remittance receipt)
ㅈ Selected Clearing features
o Possibility to configure Branches in charge of clearing or centralized clearing at HO.
o Available Interface with checks processing systems / electronic checks clearing solutions.
o Received checks validation & control before accounting entries generation
o Session temporary / final closing
o Batch file preparation
o Possibility to postpone check clearance dates and consequently increase value dates subject to
sudden holidays.
6.11.2 Checks Remittance & Collection functionality

This section is dedicated to checks drawn on local banks.
The trend in most countries is to implemented automated checks clearing rather than dispatching checks
in lot and sessions to national clearing center (Central Bank or Clearing authority). ICBS proven ability to
integrate with such solution gateway has been already exposed.
The following functions would be implemented at Branches level:
Capturing functions
ㅊ Remitted checks (Clearing or Purchased – Immediate Credit)
ㅋ Checks for collection drawn on local banks (Credit after collection)
Cancellation of remitted checks
Dispatching of remitted checks
Inquiry on remitted checks
Remitted checks reports
Checks remittance date will be set to next working day after cut off time (parameter)
The following functions may be implemented at the Branches In Charge level or centralized at Head Office:
1. Dispatching to clearing regions
1. Receiving returned unpaid checks
1. Checks for collection payment

6.11.3 Clearing or Purchased Checks Remittance

The following applies for both:
 Clearing checks (Checks that will be credited to customer’s account with the adequate
forward value date / float)
 Purchased checks (Checks paid in cash).
Remittance Workflow
Checks are captured by currency.
Capturing process includes:
ㅌ Checks’ Currency code
ㅍ Customer or Cash account to be credited (when applicable)
ㅎ Customer’s Account Number. The account may be in a currency different from the
checks’ currency. This will trigger a foreign exchange operation with exchange rate
ㄱ In case of Cash settlement remitter details will be captured.
ㄴ Feeding in the remitted checks in the reader (Or Manual Capture or remitted checks) to capture
checks information check number, payable at bank code, drawer account number, payable at
branch code as well as the check’s amount.
ㄷ Possible keying in of the check’s drawer name.
System will generate the:
1. Region code according to the check’s currency and the “payable at” Bank and Branch
codes.
1. Value Dates and Commissions according to Region’s code and eventual customer ’s
particular conditions.
User may override the generated value date and commission within his allowed range.
Totals of amounts and commissions are displayed and incremented automatically for each new check keyed
in. Confirming the remittance generates:
1. Accounting entries grouped by value dates and region code.
1. Customer receipt(s)
6.11.4 Local Checks for Collection Remittance

This applies for checks drawn on Local Banks.
Remittance Workflow is similar to clearing checks however, amounts are posted to temporary accounts
waiting for collection.
6.11.5 Settlement of Checks

Clearing checks are usually considered as “Paid” unless advised otherwise by the “payable at” bank before
value date / clearing cycle end date. While checks for collection, would rather require a confirmation from
the paying party (Paid / Unpaid).
In this section we will describe the following functions:
1. Returned Unpaid Checks
2. Individual Payment of a check for collection
3. Global Payment of checks for collection

4. Payment of collection checks cancellation
6.11.6 Returned unpaid checks / Checks acceptance

a) Return unpaid procedure
These may consist of:
 Clearing checks
 Checks sent for collection
In the first case, the checks are returned through the “Clearing House” and remitting customers are debited
back accordingly.
In the second case, the “Payable at / Drawee bank” decision is communicated to the remitting customers
and transitory accounts debited accordingly.
In all cases unpaid checks are recorded in specific table.
b) Accepting paid checks procedure
For the “Clearing Checks”, and after processing the returned unpaid checks, a batch procedure may be run
to confirm acceptance of all the checks that were not returned unpaid.
Optionally and depending on the bank’s business rules and policy, accounting may be are generated in
order to credit the customer accounts if these latter were not credited upon remittance time.
More precisely, this batch procedure:
 Flags as paid all the Checks that were not returned unpaid on a given clearing cycle, and
 Eventually generates the corresponding accounting entries if the checks were credited to a
transitory account upon remittance.
c) Individual payment of a check for collection
This function is used to process payment of a check sent for collection. It may be processed centrally at the
central processing unit.
For each check to be paid system generates the commission and the value dates that can be overridden
within allowed limits.
In case of exchange operation, induced by the eventuality that remitter’s account can be in a different
currency from the check’s account, an exchange rate is also available to be used for the counter value of
the:
 Check’s paid amount (in case today’s rate is to be applied for checks after collection)
 Commission / charges
d) Global Settlement of checks
This function is used to globally process payment of checks that were not yet “Returned unpaid” nor
individually paid. It may be processed centrally at the central processing unit.
Possible exchange rates and charges will be retrieved automatically from the respective tables.
Upon confirmation, system will consider that all of these checks were paid thus generating the
corresponding accounting entries based on predefined parameters.

6.11.7 Selected inquiries and reports

 Multi-criteria Inquiry on Remitted Checks:
 Inquiry on Remitted checks by account number:
 Inquiry on Remitted checks by bank code
 Inquiry on Remitted checks by bank code
 Remitted checks by accounts to credit report
 Remitted checks report by customers IDs
 Remitted checks report by collecting parties
 List purchased checks
 Returned Unpaid checks.
 Dispatching letters.
 Remitted checks report by bank code
 List of customers with 3 or more returned unpaid checks
6.12 Received checks

These consist of checks drawn on the Bank’s customers and presented for payment through clearinghouse.
After processing the required checking, the bank will either:
 Honor the check by debiting the customer account
 Or, refuse the check and return it back.
General Workflow
Phase 1: Uploading and Consistency Checking

 Uploading received checks files (or data entry): User will upload / key in the following data for
each received check: Check number, Routing (Bank, Branch, Region Codes),Customer account
number, Currency code, Check amount, Sequence number, Eventually the check’s image.
 Batch Control: A batch procedure checks for the following:
ㄹ Customer account indicators: Blocked for withdrawal, Dormant account, Blocked
account
ㅁ Not belonging to the customer’s account, Stopped check, Already used
ㅂ Closed account
In case one of the above cases is true, the check will be flagged automatically as “Refused”
otherwise it will be “Preliminary accepted”.
 Interactive Control Function Allowing to:
o Visualize checks details and their respective image
o Visualize the stored signatures in front of each the received check image and signature
o Possibility to refuse the check for bad signature or bad wording reasons.
o Up to 4 refusal reasons could be entered
Phase 2: Dispatching of technically refused checks to person in charge / branch operation
 Dispatching of refused checks to customers’ services / adequate decision makers.
 A monitoring screen (Dashboard) allows visualizing branches status to which refused checks were
submitted:
a) Branch code and description
b) Number of checks submitted

c) Status (0. Not yet submitted, 1. Sent to branch for technical validation, 2. Returned from
branch after technical validation, 4. Sent to branch for non funds availability checking, 5.
Returned from branch after fund checking)
d) Number of checks which status has been changed (after return from branch)
 Authorized user would
a) Visualize received refused checks
b) Possibly (after getting necessary approvals and getting in contact with customer):
1. Override possibly refused checks in case of: Bad signature or incorrect wording
2. Replace closed account by another valid one and accept check
3. Ask for the reactivation of a dormant account then accept check
4. Ask for removal of possible blocking indicator (forbidden from transaction or from
withdrawal , if applicable) and then accept check
5. Send back confirmation of completion.
 Dashboard related info will be updated to reflect above status).
Phase 3: Funds availability checking

 Automatic Validation A batch procedure that scans not refused checks verifying funds availability.
Checks drawn on same account can be ordered for example by Ascending heck Amount (Small
amounts first), Check number and Date.
o If funds are available system holds the required amount.
o In case of excess (i.e. in case funds were not available,) the check is flagged as refused for
non fund availability and it is transmitted for approval to the account officer or to the
branch manager (according to account’s branch number).
 Account Officer: Through a dedicated function browses the checks refused for non funds
availability and submitted to him. He will be able to select a check and:
o Either refuse excess authorization
o Or Attempt to override the system automatic decision. At this level standard overdraw
approval cycle (as for actual implemented process for interactive operations; i.e. according
to prerogatives continue its way ascending) will be triggered.
 The dashboard related info is updated to reflect above status and provides access to details of
refused and accepted checks.
Phase 4: Accounting entries generation / Feedback to clearing houses

This function generates appropriate accounting entries for both accepted and refused checks
For accepted checks, system will debit the customer’s account (releasing previously generated
reservation) and credit adequate general ledger account. Credit lines are usually consolidated.
Note: This function can be performed only when all pending checks have been validated by the
respective supervisor.
Reports and Inquiries
The following reports and inquiries will be modified to meet new requirements:
 “Received check inquiry
 “List of checks by status
 “List of refused checks by bank
 “List of accepted / refused checks
 Monitoring Dashboard

6.13 Post Dated Checks

ICBS Post Dated Checks main functions are:
 Postdated Entry (Or Generation based on a Financing Deal repayment schedule)
 Upon Maturity Postdated Checks
o Transfer To Clearing (If drawn on other local banks)
o Transfer To received Checks (If drawn on us)
 Postdated Checks Deletion (Physical Deletion from registry)
 Postdated Checks Cancellation (Status set to cancelled but remains in registry)
 Transferred Cancellation (Return to Post Dated)
 Change of Beneficiary Account
6.14 Declaration of Unpaid Checks Drawn On Us

 Keep detailed records of these checks.
 Notify respective customers’ (the Drawers) about these returned checks and related reasons within
n days from refusal date. Thus, asking them to settle / make available the due amounts within a
period not exceeding m working days from the refusal date.
 Report to the central bank, the refused checks that were not settled within the above stated m
working days. Reporting performed through electronic file.
 Report to central bank possible settlements.
 Report to central bank possible updates / cancellation of declared information.
 Import data received from central banks pertaining to Black listed individuals / Corporate following
defaulting checks through local banks.
6.15 Draft / Cashier’s Checks

The Draft Checks module covers:
Local currency checks (called also cashier checks)
Foreign currencies checks (or checks drawn on our correspondents).
Manager checks (or checks drawn on us).
Issued for both:
Customers
Non-Customers
The draft check module:
Offers complete follow up of checks:
From reception at Head office
Until payment / settlement through reconciliation with correspondents
Handles stop payment
Prints on correspondents supplied checks formats
Offers stock by correspondent management. Specific correspondent ID identifies the manager
checks
Generates commissions


General procedure:
Checks stocks are received and recorded at Head Office.
Main stock is centralized at Head Office level. Formats of the checks to be printed can be different by
correspondent.
Checks are distributed to branches. Upon request, the branch can renew its stock for a specific
correspondent. Branches register / confirm checks reception.
Checks can be issued upon the request of Customers or Non Customers (Cash account). Correspondent can
be notified.
Later on the check may be presented at the counter for payment (usually this is the case of the cashier’s
checks) or settled through the correspondent (Usually foreign draft checks).
Draft checks may be also stopped. In case of a correspondent check, a stop request is communicated to the
correspondent.
Full integration with ICBS Nucleus and other ICBS modules:
Using standard ICBS engines (Accounting customer documents, commission calculation, value date,
etc) and abiding by common control and validation standards.
Automated issuance of checks based on payments issued by other modules.
Possible check events / status:
In stock at Head Office
Distributed to branch
In stock at a branch
Issued
Printed
Stopped / Damaged
Paid
Therefore, ICBS Draft Checks functions are distributed between the Head Office and the branches to offer
the following facilities:
Head Office
1. Stock reception from correspondents
1. Stock distribution to branches
1. Reception of branches transactions (Checks’ issuance and stop checks request).
2. Generation of corresponding Swift messages (MT110: “Advice of Check” and MT111: “Request for
stop payments of a Check”).
3. Eventual Stock Return from branch
4. Possible issuance and printing of checks for head offices purposes
5. Integration with other modules to issue bulk checks.
Branches
1. Stock Reception from Head Office
1. Issuance of checks
2. Printing
3. Reprinting/replacement of checks (paper jam, destroyed, etc.)
1. Payment
1. Stop payment request

6.16 Traveler's Checks Management
Besides the accounting aspect of selling traveler's checks activity which is handled by the generated
transactions sub-system, the system takes care of its management aspect consisting complete stock
workflow (Reception at head office, Distribution to branches, Return to Head Office) per currency,
correspondent and denomination.
6.17 Standing Instruction Management

6.17.1 Introduction
ICBS standing orders module is conceived to automate repetitive operations: “Internal Standing Orders”.
More precisely this module handles the following types of Orders:
Operation Types Purpose
Automatically triggered by an event
Interactive Sweep Account During interactive operations and in case an account with
sweep instructions (i.e. the monitored account) does not
have enough funds, the operation can be settled by debiting
another pre-selected account(s) (the covering account (s)).
In this case, multiple covering accounts can be pre-selected
for one monitored account along with user defined priority.
Batch Triggering
Launched upon request (usually within end of day procedures)
In these cases, relation between accounts is one-to-one.
"Fixed amount" account to account Periodical account-to-account transfer of fixed amount
periodical transfer debiting one account by a predefined amount to be credited
to a second account.
“Conditional Amount” based on Transfer to another account any balance that exceeds
account’s threshold balance. predefined threshold.
Example used to transfer to a saving account, balance that
exceeds a predefined threshold within a non-earning profit
account.
“Conditional Amount” calculated To cover a percentage of a debtor account balance (the
as a percentage of a debtor monitored account) by debiting the calculated amount to
balance percentage another account (the covering account). Amount to be
debited is subject to a minimum amount.

 Standing orders are recorded in the system using the "Standing instructions definition" function. It
applies for both conventional and Islamic accounts taking into consideration possible restrictions set at
product level.
a) Selecting the standing order product’s type
b) Selecting from the centric CIS the account to be debited (In case of Sweep instruction, multiple accounts
can be set with respective priority). User will proceed with the ordering party identify verification
including possible signature. User may set / override the customer name if the ordering party is different
from the account’s owner.
c) Selecting the account to be credited. Entering beneficiary’s name and address if different form account’s
to be credited information

d) In case of “instruction” selecting charity institution / association from the related table
e) According to product’s conditions, setting when applicable:
 For conditional instruction’s setting the corresponding conditions
 Instruction periodicity, start and number of times / expiry dates.
 Hunting (retrial) number of days
 Summer advance payments conditions
 Various commissions and charges to be deducted. Possibility to override the party that will be
charged for these commissions, charges and fees.
 Generating set up charges
f) Selecting economic code and order reason from their respective tables
g) Capturing optional additional references.
h) System generates standing instruction reference; instruction is recorded with a status “waiting for
supervisor approval” (i.e. not activated yet).
 In order to be activated, defined standing instructions needs supervisor validation. During validation,
user overridden charges / commissions conditions will be highlighted.
 Triggering of due, active and non-expired orders:
o “Interactive Sweep Account” instructions are automatically triggered in interactive mode
whenever the operation amount exceeds the "monitored account" available balance and
according to defined priority.
o “Batch Standing orders” are triggered during end of day procedure if the predefined conditions
are verified. During this batch processing, eventual non-executed instructions are reported in a
“Non executed orders” reports (see also notes 2, 3 and 4)
o Moreover, “Batch standing orders” can be, exceptionally, triggered interactively by authorized
uses. This facility is mainly used to execute instructions in advance (prior to due date) or late
unsettled instructions. System will browse due instructions and user would select those to be
triggered. Execution will be one by one. In case of exceptions (funds not available or the like)
operation can be submitted to supervisor for approval.
Note 1: System offers a facility to Stop or temporary suspend standing orders execution.
Note 2: In case an instruction cannot be executed due to insufficient funds, system can keep trying to
execute it on daily basis during a specified number of days within expiry date. Also after a number of
consecutive unsuccessful executions (i.e. after a number of periods, example 7 months) instruction will be
automatically cancelled.
Note 3: In case applicable commission / fees cannot be deducted due to insufficient funds, unsettled
amount will generate a reservation that will be settled when funds will be available (i.e. similar to account’s
products’ commissions).
Note 4: In case of fixed periodical transfer, system allows also setting instructions whereby multiple
executions should be triggered at the eve of a multiple months’ holidays.
Note 5: Multiple standing instructions can be set for the same customer.


 Instructions’ Products’ Types definition and maintenance
 Third party Institutions definition
 Standing Order Setting and Maintenance
 Standing Orders Validation
 Orders Suspension / Reactivation
 Cancel Instruction
 Orders Execution
o Interactive Automated triggering of Sweep instructions
o Automated bulk processing according to due dates, events and periodicity
o Possible Interactive triggering of bulk
 A set of inquiries and reports
o Products details
o Multi criteria Instructions details
o Log list
o Inquiry on covering instructions
o List of Cancelled Instructions
o List of Stopped Instructions
o List of executed orders
o Notification to customers on processed orders
o Periodical Report to customers
o Execution / Fate Notifications (SMS or Emails)
o Executions results with failed instructions
o List of Instructions by Maturity date
o List of covering instructions by account
o List of events occurred on instructions definition
6.18 Multiple Transfers (Utility Bills and Corporate Salaries)

6.18.1 Introduction
This sub module handles operations such as:
 Corporate payments instructions including Salaries payment processing according to instructions
received from corporate (information can be captured, imported from received files with possible
recurrent periodic instructions)
 Utilities bills payments according to agreement with customers (domiciliation) and instructions
received from Utility companies (MET, Electricity, Cellular phone and the like). These latter are
usually imported from received files.
Orders executions include deduction of commissions and charges and are monitored by instructions validity
and funds availability procedures.
The objective of this section is to illustrate the management of the Utility Bills and Salaries Payment
functions.
More generally, this module handles the following types of “Multiple-transfers” operations:
 Type 1: Crediting multiple accounts by debiting a single account with appropriate
commissions’ deduction.
 Type 2: Debiting multiple accounts in order to credit a single account with appropriate
commissions’ deduction.

Examples of multiple-transfers operations:
Type Example Procedure
1 Corporate payments Initialization Phase:
instructions
This facility starts by
a) Recording the agreement reached between the
Salaries payment to company and the bank.
employees of a corporate
b) Opening accounts for the company’s various
upon receiving this latter
employees and recording their authorizations.
order.
Payments:
Periodically, company will submit instructions to debit its
account and credit the employees’ respective accounts.
Possible Recurring instructions

2 Settlement of periodical Initialization Phase:
utility companies bills
This facility starts by recording:
(Mobile Phones, Electricity,
Water, etc.). a) The agreement reached between the utility
company and the bank.
b) Customer’s authorization to debit their accounts in
order to settle utility company bills.
Bills Settlement:
Periodically, utility company will submit instructions to debit
customers’ accounts and credit its account.

6.18.2.1 Agreements setup
In order to be able to offer a new service to a utility company and its subscribers or to a corporate and its
employees, the following initializations steps have to be performed:
 Make sure that such type of services is already defined in the available services table.
 Make sure that the company / corporate is part of the Centric Information System and the required
accounts.
 Record agreement reached with the company, thus
o Selecting the company’s and required accounts
o Selecting the service product (among a list of offered services)
o Capturing instructions and limits
o Setting the charges and commission.
 Configure possible exchanged files formats
 Open accounts to the various customers / subscribers (in case they do not already have accounts in
the appropriate customers’ accounts types).
 Record utility companies’ subscribers’ or (Optionally) company’s employees’ authorizations /
instructions and limits.
Note 1: Customer may beneficiate from multiple services simultaneously.

6.18.2.2 Customers’ Authorizations

This function is used to record:
(i) Subscribers’ authorizations to debit their account in order to settle bills that will be received
from the respective utilities companies.
(ii) Or, (optionally) Employees accounts that will be credited for salaries payments upon
employer’s instructions receptions.
User will start by selecting the service ID (see previous functions) and the currency code and then he will
capture the following information:
 The authorization reference (example phone number in case of mobile phone company, or
subscriber reference in case of electricity company provider, etc.)
 Customer’s account number that will be debited by the bill amount or credited by the salary
amount.
 Customer’s account that will be debited by the bank fees / charges:
(i) An indicator informing if standard charges / fees are to be deducted or if are any particular
condition is to be applied.
(ii) The eventual particular charges / fees amount.
A ceiling above which bills should not be accepted
6.18.2.3 Payments / Settlements

 Upload file or capture instructions received from each company. The data entry function is a multi-
users process allowing the instructions’ set to be broken into multiple batches for easier capturing.
 An automated validation process scans the recorded instructions in order to check customers’ pre-
authorizations validity, accounts statuses and funds availability. For each possible payment, system
reserves the corresponding amount within the appropriate account to be debited; otherwise,
instructions that cannot be performed are reported in an exception list showing respective
accounts situations.
 Authorized supervisor may override the automatic funds availability decision; thus he may accept
automatically some of the rejected instructions and reject automatically accepted instructions.
 A batch process generates appropriate accounting entries and cancels previously made
reservations.
 All transactions are recorded with related details for further reporting / query.
6.18.3 Agreements and Subscription maintenance and follow up

Including subscription stopping and reactivation
6.18.3.1 Main functions and reports

Agreements Setup
 Available Services / Products
 Agreements with companies including exchanged files configuration
 Customers’ Authorizations
Payments / Settlements
 Uploading received file instructions / Capturing Received Instructions and / or Reloading /
Retrieving recurrent payment instructions including
o Due Bills
o Multiple payments / Corporate salaries Salary Process
 Automated Batch Validation

 Possible Interactive override / rectification
 Execution / Settlement Processing
Reporting / Queries
 Offered services
 Agreement with companies
 Services’ Subscribers list
 Received instructions to pay
 Received invoices to claims
 Execution results
 Printing Invoices Advices
 Statements / Notification to customers on processed orders
6.19 Bills Management

This sub-module covers the management of:
 Commercial or Discounted bills
 Bills for collection
 Guaranteed bills.
Complete follow-up and management of the bills from their respective entry date until their settlement:
 Bills data entry with possible multiple drawees (allowing drawees’ follow up and risk
evaluation)
 Possible validation by a supervisor
 Possibility of sending bills for collection (domiciliation)
 Settlement of bills
 Automatic periodical tracer (before and after maturity)
 Manual tracer upon request
 Transfer to unpaid (Manual or Automatic x days after due date, Transfer of all bills’
remittance to unpaid after non payment of a predefined number of bills)
 Transfer to litigious
 Settlement of unpaid or litigious bills
Accounting entries generation, based on the generated transactions sub-system, at the "Bordereau" or
"List of Bills" registration and at the bills payment.
Automatic profit and commission prorating
Rich set of Inquiries and reports (by customer, drawer, maturity date, status: Outstanding, sent for
collection, paid, unpaid, litigious, etc.)
6.20 General Branch Inquiries and Reports

Samples of general purposes reports that are usually made available at branches level:
Central Customer Information
Client’s accounts
Consolidated client accounts
Daily listing of transactions by serial number
Daily listing of transactions by account number
Daily Cash register
Teller Cash register

List of overdrawing, authorized and processed or suspended
List of passbooks movements in suspense
List of exceptions on value dates
List of issued certificate
Daily transactions by product
Daily movements on Term accounts
Diary of term accounts maturity on dd./mm/yy
Daily movements on Debtor accounts with old and new balances
Daily purchases and sales of Foreign Currencies (Foreign Exchange Trade report)
Detailed Balance of Ledgers and Auxiliaries
Consolidated balance (all currencies)
Official Journal
Daily Journal
Trial Balance
Customers’ accounts position (totals by chapter/currency)
Accounts opened during the month
Accounts closed during the month (reason for closing)
Number of clients / of clients' accounts
Currency revaluation result
Reconciliation result (Matched not matched)
List of unprocessed transactions (including delivery channel transactions)
Cancel transaction
Certified check list
Reserved amount (hold or stopped payment)
Account exception list
Pending transactions/overdraft
Interbranch transaction list
Statement of Account
Average balance report
List of opened closed account
List of updated account
Dormant account reactivated list
Blocked and unblocked account
Statistical transactions reports (by user, by type of operation, by currency, etc).

7 ISLAMIC FINANCING MODULES

7.1 General Definitions
7.1.1 The Murabaha operation
Murabaha is a deal between the bank and the customer where the latter desires to acquire some goods
whether from the local market or from abroad.
Bank will study the customer situation and application and if convinced of the customer credentials, the
bank will directly purchase the goods. Bank and Customer will agree on the resale value and on the terms
of payment.
Bank makes its profit not by charging an interest, but from the difference between the purchase price and
the sale price to the customer. The sale price is equal to the purchase price plus the bank ’s profit (markup).
The bank’s profit is a percentage of the purchase price. In addition, the bank may require an insurance to
be issued, and therefore a premium is also to be paid by the customer.
7.1.1.1 Usual General Procedure
Client approaches the bank for a possible Murabaha deal and fill an application.
The application contents depend on:
 The Murabaha type: Local ‫ داخلي‬/ Foreign ‫خارجي‬
 The client type: The client can be an individual, a trader or a company.
 The nature of goods the client is looking to acquire to acquire.
The main application forms are:
1) One time financing request ‫طلب تمويل لمرة واحدة‬
2) First time financing limit request ‫طلب مخصصـات ألول مرة‬
3) Renewal of financing limit request ‫طلب تجديد سقف سنوي‬
4) Increase of financing limit request ‫طلب تعديل سقف‬
5) Excess of financing limit request ‫طلب تجاوز لمرة واحدة‬
Application of type 1 is usually dedicated to Individuals while the remaining types are for traders and
companies. Depending on the application type and the nature of goods the main information to be
provided by the customer are usually:
For individuals For traders and companies
Name, Address, Profession, Company name, share holders names and
Salary and other incomes statement, personal ownership, Address,
Nature of goods, Company activities, registration certificate,
permits
Detailed description of the goods,
Previous years balance sheet,
Pre-invoice, (pro-format invoice)
Turn over for the last four years,
Required investment amount,
Nature of goods
Investment period,
Detailed description of the goods,
Guaranties (Real estate, cars, machines and
equipment, cash, bonds, bank guarantee, etc.) Pre-invoice (pro-format invoice),
Guarantors Required investment amount,
Investment period,
Guaranties (real estate, cars, machines and
equipment, cash, bonds, bank guarantee, etc...)
Guarantors.

7.1.1.2 Typical Murabaha Workflow Process
7.1.1.3 Some Typical Murabaha conditions

 Individuals must have their salaries domiciliated at (transferred to) the bank while traders companies
must have a good relationship with the bank.
 Guarantors financial situation is considered. For example in case of an employee guarantying others, the
total guaranteed amount should not exceed a percentage of his income.
 Investment period depends on the nature of goods.
 In a number of Murabaha cases (Car Murabaha) customer may be requested to pay an initial down
payment and the remaining amount will constitute the financing amount.
 In Murabaha cases and upon receiving customer’s signed promise to purchase, the effective “Matter Of”
asset will be purchased from the supplier to be sold back to the customer.
 A grace period may be accepted, but this period is deducted from the investment main period.
 Stamps and other fees are deducted from the customer account.
 If the Investment amount is greater than a certain amount the bank must declare the operation to the
central bank via a secret number.
7.1.1.4 Typical Payment Mode
On due date customer's account is automatically debited if the account balance allows and an advice is sent
along with the promissory note to the customer. In case the account balance is less than the installment (or
promissory note) amount, a tracer is sent to the customer and the guarantors.
If after n days (n to be defined) the installment is still not paid, then the installment shift from installment
to be collected to due unpaid installment. Warnings are sent to the customer and to the guarantors and
the bank may proceed to collect the payment by taking the available customer account balance and settle
the remaining amount from the guarantors accounts.
7.1.2 The Musawama operation

Similar to Murabaha, yet without the need to disclose the cost price.

7.1.3 The Charity loan

The only investment operation where funds are given directly to the customer (and not to a third party
from which customer is acquiring services or goods) is the “Charity loan”. Charity loan is granted to
individuals suffering from financial problems. Bank does not make any profit from such operation. Usually,
funds are reimbursed within a period of 12 months.
In case the beneficiary is an employee, Charity loan is called ‫سلفة راتب‬
Otherwise it is called ‫سلفة اجتماعية‬
7.1.4 The Tawarruq Deals

Similar to above Murabaha process with additional features and link to ICBS Capital Market (see
hereafter ICBS Capital Market modules for more details) modules whereby:
 The Financial Institution buys the Assets / Shares (Using Standard Capital Market functions)
 Sell it to the customer under a Murabaha deal
 Sell the Assets / Shares on behalf of the customer’s thus supplying him with the proceeds of the
sale.
7.1.5 The Foreign Murabaha

Foreign Murabaha operations are applicable only to “Sight Payment” Import Letters of Credits (see
hereafter ICBS Import Letters of Credit for more details).
 Relation between the Bank and the foreign Correspondents / Beneficiary
(exporter), abides by International Import Letters of Credit regulations.
 Relation between the Bank and the Customer (importer) is as follows:
Step1: The customer presents a Pro-format invoice issued by the beneficiary (exporter) and fills and
application that will be submitted for the bank study and evaluation.
Step 2: The bank will study and may approve or reject the submitted application.
The following steps take place only in case of approval.
Step 3: Contract signature and eventual submission of additional guaranties. Contingent liabilities
accounting entries are recorded without real payments
Step 4: Upon documents reception, above accounting entries are reversed and customer is
requested to sign the promissory notes and new accounting entries are generated.
In case of arrival of goods before documents: Provision (margin) is raised to 100%, customers signs a sight
promissory note for the total amount in the L/C currency.

7.1.6 The Mudarabah operation
The Mudarabah operation is an agreement between the bank "Rabb-Ul-Mal" and a customer the
"Mudarib" in order to invest in a project, commercial enterprise. The management and labor is an exclusive
responsibility of the "Mudarib". The Mudarabah can be restricted to specific investment (Al-
Mudarabah al-muqayyadah) or unrestricted (Al Mudarabah al-mutlaqah.
It is necessary for the validity of Mudarabah that the parties agree, right at the beginning, on a definite
proportion of the actual profit to which each one of them is entitled.
More precisely any profit is shared between the two parties based on the initially agreed ratio.
The customer does not share any loss due to the investment. The bank "Rabb-Ul-Mal" bears all the losses
that might occur provided this loss in not attributable to negligence or misconduct of the "Mudarib".
Consequently under a Mudarabah Financing project:
- Banks participates in the Mudarabah by financing the project.
- Customer (applicant) participates by providing his experience, his effort and his labor.
Customer may be required to provide guaranties and possibly sign sight promissory note with an amount
equal to the Mudarabah full amount. This allows the bank to have a control on the behavior of the
customer (Investing the funds in the good fields, and good book keeping).
Mudarabah operations workflow main sequences are:

Step1: Customer submits an application showing the project details and his experience in the field.
Step2: Bank studies the application and may approve or reject the application. The approval can take the
form of:
 Permanent deal, whereby customer is granted with a yearly limit (ceiling) automatically renewed.
 One time investment.
The following steps take places only in case of approval.
Step 3: Profit distribution shares are agreed upon (Bank and Mudarib percentages). This rate is applied on
the profit generated from the Mudarabah operation in order to distribute the profit between the bank and
the customer. As well as:
• Draw Down Period and Amount,
• Possible reimbursement Period / Schedule
• Insurance / Takaful, Fees calculation / Setting
• Required documents , Required guarantees and Contract term
Step 4: Opening of a Mudarabah account from which Mudarabah and various expenses are debited.
Step 5: Payment (or reimbursement or settlement) takes place as follows:
 (i) According to schedule or (ii) each time project generates income Mudarabah account is
credited.
 Upon Mudarabah settlement (whether the Mudarabah account is creditor or debtor), the
result is distributed on the bank and on the customer as per agreement.

7.1.7 The Musharakah operation

Musharakah operation is an investment deal that the bank may enter into with its customers. The bank
shares the equity with the customer by financing the project. The Musharakah operations end up by
transferring the ownership to the customer. ( ‫) مشـاركة متنـاقصة المنـتـهية بالتــمليك‬
Musharakah main operation types are the following:
 Musharakah operation on a property example : parcel of land , flat ( ‫شقة‬ ‫) عقار أو‬
 Musharakah operation with artisans ( ( ‫الحرفيين‬
Musharakah operations sequences:
Step1: customer submits an application presenting the required documents.
For example in case of artisans, the following purposes are accepted:
.‫ معدات‬،‫ اثاث‬،‫ ديكور‬،‫ خلو‬, ‫ايجار‬
Provided that the following documents are submitted:
‫ ضمانات‬،‫ كفالء‬،‫ معرفين عن الشخص‬،‫ شهدات الخبرة‬،‫ شهدات دراسية‬،‫ اقتصادية‬9‫جدوى‬
Step2: Bank studies the application and may approve or reject the application.
The following steps take places only in case of approval.
Step 3: Opening of a Musharakah account to which all expenses are debited. In case of Real Estate project,
a mortgage is raised against the property (‫)العقار‬, Otherwise in case of Artisans, a sight promissory note is
to be signed by the customer.
Step 4: An income distribution rate is agreed upon. This rate is applied on the incomes generated from the
Musharakah operation in order to settle the Musharakah account, and share income between the bank and
the customer.
Step 5: income may be the result of rents, premium (‫خلو‬ ‫)أجار أو‬
Incomes are distributed as follows:
a) Settlement of Musharakah capital.
b) Bank revenue share
c) Customer revenue share
When all the Musharakah investment capital is reimbursed (Paid back) the property ownership is
transferred to the customer. In case incomes are higher than Musharakah capital, the difference is due to
the customer. In case customer lives in the flat, he will have to pay a percentage of the Musharakah
amount as rent. Those payments (the rent) are used partially as bank profit and partially to pay back the

capital.

7.1.8 The Istisna’a and Parallel Istisna’a Operations

7.1.8.1 Definition
 Sale contract between the ultimate purchaser "Al-Mustasni" and the seller "Al-Sani"
 Al-Sani, based on the order from the Al Mustasni,
o Undertakes to have manufactured
o Or acquires the "Al-Masnoo" according to specification
o Sells it to Al-Mustasni for:
 Agreed Upon Price
 Agreed upon Method of settlement
 By installment,
 Or deferred to a specific future time.
 Al-Sani should provide the raw material and the labor.
7.1.8.2 Products
1. Istisna’a:
• A sale of commodity before it comes into existence
• Process similar to Murabaha / Ijarah products with specific terms and conditions
2. Parallel Istisna'a:
• A separate contract with a manufacturer to provide the subject matter of Istisna’a.
• A set of functions to allow follow up, settlement o due amount and reception of goods
7.1.8.3 Typical Istisna’a and Parallel Istisna’a Process
7.1.8.4 Istisna'a Conditions

• Assets
1. Real estate (building)
2. Use of other assets evaluated on case by case basis.
• Finance Tenor
1. Open - will be evaluated on case-by-case basis
2. Depends on the economic life (depreciation) of the asset and the purpose of the financing.
3. Maximum tenure decided by credit and risk department based on bank's policy.
• Financing Amounts (Min and Max)
• Fees (Study, Late Payments if applicable, Other)
• Grace Periods (Max, Methods)

• Early / Prepayment (Partial, Full, Fees)
• Approval Policy and Eligibility
• Required Documents
• Required Guarantees
• Contracts Output
• Pricing
• Insurance (Takaful)
• Detailed Descriptions
7.1.8.5 Parallel Istisna'a
• Deal Booking
– Selecting a contractor
– Separate contract, Assigning the construction job to him
– Detailed conditions and Good Descriptions
– Deliveries Schedule
– Required Documents and Guarantees
– Periodical Expertise to certify stages of completion
– Advance / Progressive payments
– Delivery / Reception of goods / Assets
– Possible Penalty
– Customer may be authorized to receive goods directly from manufacturer
• Disbursements (multiples withdrawals)
• Delivery / Reception of Al Masnuu
• Possible Penalty In case of Late Delivery
• Reports and Inquiries
7.1.9 The Salam and Parallel Salam Operations

Under this operation, the bank would be buying goods at a pre-determined future date in exchange of an
advanced price fully paid.
Within the Salam deal, the following would be specified:
 Quality & quantity of goods
 Date & Place of Delivery
 Possible security or guarantee
Also, the bank may enter in a separate deal with another customer to sell the purchased goods (“Off-take”
agreement or Parallel Salam).
This new deal would abide by the following:
 Separate Contract from the initial purchase agreement
 Receiving a promise to buy from a third party
 Receiving pre-determined price on delivery

7.2 ICBS Islamic Financing Modules

7.2.1 Introduction
“ICBS Islamic Financing Deals Management” is a comprehensive, proven, flexible, user friendly sub-system,
fully integrated with other ICBS modules, designed and conceived in accordance with Sharia laws and rules
to help Islamic Banks and Islamic Financial institutions automate their various customers’ Islamic financing
products including:
Islamic Financing Basic Products:
(i) Consumer Murabaha (Murabaha for the Purchase Order – MPO, Bai Bithaman Ajil
– BBA, etc.)
(ii) Housing Murabaha,
(iii) Musawama
(iv) Ijarah (Ijarah wa-Iqtena or Ijarah Muntahia Bi Tamlik )
(v) Commercial (Murabaha, Ijarah),
(vi) Charity Loan (Qardul Hasan)
(vii) Islamic Credit Cards
Islamic Financing Advanced Products:
(i) Personal (Tawarruq, Bai Inah)
(ii) Istisna’a and Parallel Istisna’a (Muwazi)
(iii) Syndicated Financing
Islamic Financing Extended Products:
(i) Mudarabah
(ii) Musharakah
(iii) Salam and Parallel Salam (Muwazi)
“ICBS Islamic Financing Deals Management” is an easily configurable solution allowing banks and financial
institutions:
 Offering Sharia compliant tailored products to meet evolving highly competitive market needs
and business rules,
 Improving staff productivity and customers’ services,
 Streamlining business processes operations procedures,
 Implementing automated workflow and decision support based on parametric eligibility
criteria,
 Monitoring customers’ activities and controlling operations’ risk
 Managing agreement with third parties (Agents, Merchants, Suppliers, Insurance Companies,
etc.).
“ICBS Islamic Financing Deals Management” functions and features cover financing operations various
stages and events including:
 Simulation and origination / setup,
 Disbursement or financing deal execution Sharia compliant required steps (see note 1 hereafter) .
 Repayments / settlements and option to buy,
 Monitoring, arrears delinquency follow up and rearrangements, rescheduling
 Collections, foreclosure and Legal cases.

In accordance with ICBS general design standards and modules full integration, flexibility and efficiency
“ICBS Financing Deals Management” insures:
• Profit, commissions and fees calculation and accruals full automation,
• Customers’ privileges dynamic considerations,
• Accounting entries generated in line real time,
• Real time liabilities, positions and limits management, control and monitoring,
• Alert messages, Notifications Mail / SMS triggering,
• Full customer’s documents creation, legal notice.
Note 1: ICBS Islamic Financing Deals Management manage products specific relevant information and
process including:
• Processing of customer’s “Promise to Purchase” and Urbun, Hamish Jaddiyah or “Advance
Payment”
• “Matter of” Assets details
• Cost Price, Selling Price and Markup
• “Assets” purchase form “Supplier” with possible involved “Agent / Officer”,
• “Settlement to supplier(s)” / Checks issuance,
• Credit Scoring / Eligibility Criteria,
• Possible Takaful (insurance), Taxes and VAT,
• “Matter Of” project definition, details and stages
• Possible “Draw Down” Schedule
• Agreed on Financing Contribution Shares and Profit Distribution Shares,
• Possible “Residual Value”, “Option to buy” for Leasing deals;
• “Billing of additional charges and expenses”,
• Possible “Subsidization”,
• Possible “door to door” collection and Reconciliation with collectors
• Etc.
Note 2: BML Istisharat can also offer the following bundled functionalities
 Purchase Orders (procurements) and goods reception
 Stock control (inventory)
 Fixed Assets
Details of these modules functions are available in Administrative functions Separate Capabilities guide and
can be supplied upon request.

7.2.2 GENERAL PROCEDURE AND WORKFLOW

7.2.2.1 Notice
In the following and for illustration purpose we are stating the workflow of most common “Islamic
Financing Products” including as Murabaha, Ijarah and Istisna’a.
While other products workflows, such as Mudarabah, Musharakah are described in dedicated sections
throughout this document.
7.2.2.2 Most Common Products General Procedure and Workflow
After having defined the various Islamic products (Murabaha, Ijarah, Istisna’a, Charity Loan, Tawarruq, etc.)
to be offered to the customers and after having set / attached the eventual scoring tables, set up conditions
and follow up processes would take as follows:
1. Possible deal simulation for illustration purposes.
2. Financing application data entry guided by the selected product’s conditions and business rules.
Unacceptable diversions from the product’s conditions generate blocking messages while other
diversions are highlighted and will be reported to supervisor during the validation / approval
process.
Recording of Collateral and Guarantees / Guarantor(s) and other submitted documents with
possible scanning.
Specific fields are available to handle products specificity such as:
• Asset’s details, Cost Price, Selling Price, Markup, Down Payment, Agent and
Supplier’s and additional expenses / charges including Takaful (risk insurance)
premium, registration and maintenance,
• Project stages, financed items and possible draw down conditions,
• Possibly Subsidy,
• Etc.
Payment Schedule is generated according to Product’s conditions and Deal captured information
and shows the payment / rent details at the respective schedule dates.
3. Deal proposal is printed for study and checking purposes.
4. Application is transmitted to credit officer(s) / supervisor(s) for validation / approval and this in
accordance with defined workflow. Applicant is checked against the black list. Supervisor(s) can
browse application’s details, applicant’s credit historical data (if any) including previous financing
deals or applications, unpaid installments etc. Application’s items that diverted from the product’s
conditions are highlighted. Each supervisor may approve, escalate to higher levels or reject the
application thus sending it back to the originator with alternative proposal guidance. Originator
may amend the application according to the supervisor recommendation and resubmit it for
validation.
5. Validated application is notified to the originator and final contracts, possible promissory (notes)
and when applicable, customer’s promise to purchase and order to supplier are printed.
6. Missing documents and / or guarantees are reported to be claimed.

7. After having received the required documents with possible down payment / promise to
purchase and depending on the product’s configuration / permissible actions:
a. In case of Murabaha:
i. A purchase order is issued to the supplier with respective payables
ii. Followed by the Murabaha execution through the “Granting” function
b. Or in case of single disbursement: Credited to customer’s account through the

“Granting” function.
c. Or in case of multiple disbursements, funds are made available through “Drawn

down” function. The repayment schedule will be aligned to effective allocation
dates.
In all cases set up charges and fees are deducted / collected.
8. Periodical process calculates and posts accruals, perceives possible fees and commissions. Under
specific products additional fees and expenses can be charged and billed as well.
9. Deals subject to automated rate changes have their payment / rental schedule updated.
10. Reminders are generated x days before maturity with possible email, SMS notifications.
11. Automatic payment option: Installments amount including profit are settled according to agreed on
schedule through an automatic account to account transfer function to debit current and/or saving
accounts. For deals linked to salary, the salary payment process may trigger installment settlement.
In case the available balance of the billing account is less than due installments, system and based
on pre-defined instructions may either process a partial payment or record an unpaid amount. Due
unpaid amounts will be recorded in a due file and will be subject to a hunting process.
12. At the counter payment option : Customers may also call at the branch to process payment for due
or not yet due installments. Payment may cover one or more installments. Payment can be in cash,
from an account or by a check. Late settlement may generate penalties / delay charges. Early
settlement may generate return of profit / grant gift to customer.
13. Direct debit through other institutions and Door to Door Collection may be also performed through
professional companies / collectors. For this purposes ICBS handles job orders and allow batch
payment of collected installments with appropriate reconciliation procedures.
14. Deals status with past due will have their status changed according to the number of unpaid
duration from “Regular” to “Under Branch Observation”, “Under Collection Unit Observation”,
“Doubtful”, “Bad”.
15. Tracers are generated periodically for Past Due. (Tracers may be sent to Customer, Guarantor or
Employer with possible email, SMS notifications). All events / actions are recorded; User may also
insert records in “events table to record interactions with the borrower. Delinquent deals can be
assigned to lawyers for further legal cases management and collection follow up.
16. Deals can be rescheduled / extended or foreclosed / written off.
17. Leasing Settlement or exercising of the Option to buy can take place according to agreed on
conditions.


18. Handling of Payables to third parties including suppliers, insurance companies, maintenance, etc.
19. A set of reports and inquiries:
 Show incomplete applications (application where required document are still not presented).
Output Details of Co-applicant / Guarantor / collateral. Showing the accounts of the guarantor
related to the financing deal. Print approved application by manager.
 Produce deal full details: original amount / installment amount, Nb of installments, outstanding
balance, and projected repayment schedule. Deals being selected according to a set of criteria
including Customer’ s ID, Name, Civil Id.
 Produce Deals History including: Due Date, Date Posted, Principle Installment, profit Collected.
 Produce statements: Display / print on-line (or batch request) all Financial / Non-financial
history, with Ability to carry fully descriptive source / Initiation dates / Review dates / Free
form or table entry comments.
 Provide Arrears history / Early payment / Extension / Reschedule. Showing the past due
installments and their status. List Written off deals Inquiry.
 Provide Consolidated reports for each type of financing / classified as regular / irregular /
profitability & cost of funds.
7.3 ICBS ISLAMIC FINANCING BASIC FUNCTIONALITY

7.3.1 Products Configuration
“ICBS Islamic Financing Deals Management ” module provides a configurable tool allowing Banks and
Financial Institution defining Sharia Compliant Retail and Corporate Financing Products according
to their business rules and regulations.
Defining a product requires authorized users / administrators setting its conditions and business
rules including:
(i) Product Financing Type: Such as Murabaha (Consumer: Car, Goods; Housing
Murabaha, Corporate Murabaha), Ijarah (Ijarah Muntahia Bil Tamlik, Bai El Ajil),
Personal (Tawarruq), Istisna'a and consequently setting the following information:
(ii) Profit calculation methods to be applied:
a. Discounted Profit through methods such as: “Fixed Equal Payments”, “Discounted”
or “Flat”. (For instance applicable for Retail Murabaha)
b. Or Profit in arrear methods such as “Capital”, “Added On” or “Defined Schedule”
(For instance applicable for Ijarah and Istisna’a).
(iii) Profit rates conditions: Fixed or Variable rate (Indexed Libor +, Central Bank rate, or
similar). Variable Rate would be set for Ijarah products to allow rental changes.
(iv) Product’s limits, constraints and policy checklist for decision support and monitoring
purposes.
(v) Funding or Disbursement conditions: Single amount granting or multiple draw downs /
disbursement within draw down period and ceiling amount. (For instance applicable
for Istisna’a).

(vi) Settlement conditions: Grace period, Capital Reimbursement schedule and / or Profit
Payment / Compounding periodicities, Early and late payment rules and penalties
(when and if applicable)
(vii) Commissions, charges, stamps, processing fees, handling fees, evaluation, mortgaging
fees, insurance / Takaful plans and premium,
(viii) Required documents, guarantees / collateral,
(ix) Output: Contract, reimbursement plan or promissory notes, tracers / reminders
(x) Decision support, monitoring Limits and constraints :
a. Size of financing (Tiers)
b. Pricing / profit (Override)
c. Secured / Unsecured (Guarantor validity / different type of guarantees)
d. Credit policy checklist and rules (Set of configurable conditions)
(xi) Dynamic Scoring / eligibility criteria for retail consumers’ products.
(xii) Dynamic multi criteria approval workflow: Required profiles for each combination
(Scoring / Eligibility results, Guarantees, Range of amount, Pricing conditions)
(xiii) Also possible Link with Administrative modules (Stock control), Trade Commodity
Trading, Finance (Letters of credit) or Real Estate modules
7.3.2 Illustration / Origination – Set Up:

Product selection and filling of the required information according to product’s conditions and
type: Retail Murabaha, Corporate Murabaha, Ijarah, Istisna'a, etc.
For instance, for a commercial deal, a corporate profile would have been already defined including:
Corporate general information, Credit file with financial figures, Submitted Guarantees / Collateral, Credit
Lines, Accounts and conditions.
For a consumer / personal financing, borrower personal information may be already available (case of an
already existing customer) or filled during application. This includes:
 Personal information and addresses, Income and assets,
 Employer’s details and eventually liabilities with other financial institutions.
 Additional dynamic questions may be made available to complete the applicant scoring evaluation.
 “Matter Of” Asset / financing Deals (see note 1):
In all cases, deal’s conditions should be set up including Financed Amount (if applicable Cost Price, Down
Payment, Registration and Maintenance changes as part of the financed amount) and Reimbursing
conditions: Start date, number of payments, periodicities, possible insurance / Takaful premium, payment
mean, subsidy, etc.
System and according to product’s conditions and application information will highlight deviations,
calculate and browse the repayment schedule.
Possible customization of repayment schedule (for applicable products)
Required documents and guarantees should be respectively collected, scanned and attached.
System’s will produce the required output including proposal, schedules etc.
Note 1: Samples of Products Specific details
 For Murabaha products possible:
o Purchased goods details.
o Calculation of sale price based on cost price
o Link to purchase orders and stock control modules
o Link to Investment in Real Estate
o Letters of Credit module.


 For Tawarruq:
o Purchased goods details.
o Calculation of sale price based on cost price
o Link to Commodity trading
 For Ijarah Muntahia Bitamlik (IMB) products possible:
o Fixed rents or reset on specific dates
o Libor + rate setting
o Transfer of property subject to a Final Payment (Balloon)
 For Istisna'a / Ijarah Muntahia Bitamlik (IMB) products possible:
o Schedule based on Multiple disbursements period and ceiling
o Financed items details
o Libor + rate setting
7.3.3 Multilevel Approval Workflow and Funds Disbursement Processes
Triggering of approvals workflow in accordance with defined rules, approval matrix and financing deal’s
application information.
Credit evaluation and complete study by the concerned profiles, including: Application details and
submitted documents, Applicant’s Situation, Debt/Income Ratio, Credit History, Scoring / Eligibility criteria
results, etc.
Approval / Escalation process (with email notification and comments) ending with:
 Approval by required profile(s) according to defined workflow and application information
 Rejection of the current application / Sent back with observation for update and review.
In case of approval:
(i) Documents Mgmt: Contract / Agreements, confirmation, notifications, vouchers, other defined
templates
(ii) Promise to purchase and down payment (when applicable )
(iii) Verification that all required document were supplied
(iv) Purchase order issuance, settlement to supplier and assets delivery reception (when
applicable)
(v) Financing deals execution or Multiple Withdrawals within a drawdown period and limit.
ICBS financing modules are integrated with ICBS credit facilities management, and consequently,
for:
a. A Corporate Customer or a customer with already granted “Financing Credit Lines”,
system will link the application with the customer’s available facility. In case of
multiple lines, user will be able to select one of the available lines. System will
check if this new deal fits within the line available amount.
b. A Retail Customer or a customer with No granted “Financing Credit Lines”, system
will create, upon application approval, a punctual credit line for this approved
financing amount.
Note: Possible Integration with other modules as:
o Purchase Order, Goods Reception and Delivery (Stock control),
o Payables to third parties (suppliers, goods risk insurance companies, collectors, etc.)
o Real Estate management (For Investment in Real Estates)
o Trade finance settlement financing (For Foreign Murabaha)
o Commodities purchase financing (For Tawarruq deal)

7.3.4 Murabaha Sample Application and Approval Workflow
7.3.5 Deal Tracking and Follow Up:
Events recording, Profit and Commission Accruals, (according to calculated effective rates), Profit
posting, Periodical tracers (before, after maturity), Rates changes when applicable and update of
the repayment / rental schedule, possible refund of subsidized amount.
7.3.6 Repayments / Settlement:

Various possible payment methods:
(i) Batch Automatic Direct Debit according to maturities / schedule,
(ii) At the counter (Customer or Cash Account),
Settlement at counter covering various cases:
 Reimbursement at Maturity,
 Early and late payments with fees / charges,
 Payment of a single installment,
 Payment of an amount covering multiple and / or partial installment,
 Balloon / residual value settlement,
 Global payment / deal closing.
Note: For Personal, Consumers and Micro Credit deals system handles:
(i) Door to door collection through collectors companies (Job schedule, Collection reception /
validation / Posting, Change of assignments)
(ii) Employees financing link with salaries payment process
(iii) Settlement from “Saving” accounts / Link to Salaries settlement
(iv) Payables to: Suppliers, Insurance Companies, Collectors, Others

7.3.7 Arrears, Past Due follow up, Classification & Rearrangements:

• Hunting due amounts (see note 1 hereafter),
• Changes of statuses and classification
o Payments: Due, Unpaid
o Deals: Regular”, “Under Branch Observation”, “Under collection Unit Observation”,
“Doubtful”, “Bad”, etc.
o Status triggered Actions: Accounting entries generation, Profit / Accrual moving to
suspense or Stopped for non-performing deals, Commissions, Notice letters.
• Flexible Classification rules (Integrated with global classification / Statutory reporting)
• Provisioning reporting (Integrated with global classification / Statutory reporting).
• Rescheduling, Rearrangements / Extension,
• Foreclosure / Write Off
Note 1: Hunting is a batch process that scans a due file where all due payments are recorded. Hunting
process will try to settle these due amounts according to the Bank predefined priority and subject to funds
availability in the customer’s authorized accounts. For more information please refer to “Due File”
management document.
7.3.8 Legal cases management and collections

• Sending legal notice,
• Lawyers assignments,
• Legal Actions, Escalation, Courts events and decision recording and follow up,
• Fees / Charges posting,
• Collection management
o Assignment to collectors,
o Configurable file job orders issuance,
o Follow up,
o Recovered amount reception and Processing,
o Reconciliation
• Lawyers’ / Collectors fees settlement.
7.3.9 Selected reports and inquiries:

• Deals situation with drill down to full details
• Expected cash flow Earned and / or expected profit
• Accrual / Realized Income by borrower / product
• Maturities list
• Financing deals by status
• Outstanding payments / Due payments
• Unpaid installments by borrower / product
• Customer historical situation
• Daily activities
• Application:

• Deals History

• Consumer / Personal Products
– Payables inquiries
– Collections inquiries
– Inquiry by guarantors
• Legal Cases and Actions
• Delinquent – Defaulters List
• Non Performing Deals
• Deals History
• Statistical reports: Breakdown of portfolio by:
• Customers’ Annual Turnover
• Customers’ Number of Employees
• Customers’ Geographic Location
• Customers’ Economic Sectors
• Products
• Income Type
• Credit Exposure

7.4 Mudarabah Financing Specificities

7.4.1 Mudarabah Agreement Scope:
 Banks participates in financing the project (Capital)
 Customer participates by providing his experience, effort and labor (Work)
 Customer provides required Guarantees, Guarantors or Sight promissory notes with an amount
equal to the Mudarabah full amount
 Customer does not share any loss due to the investment.
 The bank bears all the losses that might occur.
7.4.2 Products Definition

Products’ conditions and constraints definition process is similar to Murabaha Products, thus allowing
setting the boundaries and general condition to which deal should abide.
Specific Mudarabah products information being mainly:
 Restricted or Unrestricted “Mudarabah”
 Multiple Withdrawal Allowed or Forbidden
 Allowed Withdrawal Period (in Months)
 Bank Profit Share Percentage
 Customer Profit Share Percentage
 Behavior in case the deal expires: Settle / Liquidate the Deal or Extend validity
 Allowed Project Expenses types
7.4.3 Customer Application, Approval and Validation

Customer’s information file, Credit facilities application, collateral and list of required documents are
handled through ICBS credit file customer’s information and Credit Facilities management module.
Additional functionality is provided to record Mudarabah deal details including:
a) Mudarabah Deal Reference
b) Project description / Economical Purpose ("‫)"جدوى اقتصادية‬.
c) Mudarabah approved limits (Maximum Amount and Expiry date)
d) Customer’s accounts (Mudarabah and Current)
e) Profit distribution shares
 Customer’s share (% of profit)
 Bank’s share (% of profit)
f) Narrative conditions that describes the deal.
g) Conditions pertaining to the nature of expenses that the Mudarabah would cover.
h) Charges and expenses: Stamps and fees (such as Application study fees).

7.4.4 Mudarabah Utilization / Disbursements

User selects the Mudarabah deal reference and the system will browse the related information such as:
Product code, Product Account, Outstanding deal Amount, Previously made withdrawals / disbursement,
etc.
Customer presented bill, required disbursement and Bank's approved expenses are captured.
The amount to be withdrawn cannot exceed the outstanding deal amount (In case more funds are
required, the Mudarabah amendment function can be used to grant additional limit).
The various utilizations / purchase of goods are recorded and generate the required accounting entries,
mainly to:
 Debit Mudarabah account
 Credit beneficiary party: (i) Correspondent account in case of an L/C, (ii) Supplier’s or Customer’s
account, (iii) Also possibly cash account.
In case of Trading Mudarabah Items to be purchased are recorded.
In case of foreign Mudarabah, an L/C may be issued. L/C expenses (commissions and charges) will be
debited to the Mudarabah account. No margin is required.
7.4.5 Repayment / Follow Up

Basically, once customer starts to sell back the purchased goods or when the activity starts to generate
income, proceeds will be remitted to the bank with the supporting documents (example copy of customer’s
issued invoices / receipts) who will credit the Mudarabah account.
Nevertheless, repayments can be:
 Either in accordance with a pre-agreed schedule similar to Murabaha, Ijarah or Istisna’a (for this
case please refer to ICBS Islamic Financing Common Operations described above).
 Or free repayment subject to project activity.
This function is used in case of free repayment Mudarabah operations. User will select the Mudarabah deal
number and system will browse the related information such as: Product code, Product Account, Deal
Amount, total Withdrawn Amount, Total Paid Amount, etc
Payment can be:
a) In Cash
b) By Customer’s account debit.
c) By Remitted Clearing Checks account.
System will compute the unrealized profit or loss upon each payment.
For Trading Mudarabah deal, sold Items can be recorded.
7.4.6 Expired Mudarabah and Amendment

In case the expiry date set within the Mudarabah deal is reached and depending on the contract
conditions:
a) It may be extended
b) Customer may be forced to purchase the outstanding stock
ICBS provides:
a) Expiring Mudarabah deals report
b) A Mudarabah amendment function allowing extending the validity date.
c) The above repayment function that also can be used to record the proceeds of the stock liquidation.


7.4.7 Mudarabah closing / Settlement ‫ تصفية‬-

Similarly to the settlement process, Mudarabah closing can be:
 Either automated in accordance with a pre-agreed schedule similar to Murabaha, Ijarah or Istisna’a
(for this case please refer to ICBS Islamic Financing Common Operations described above).
 Or manual closing subject to project activity.
This function allows manual closing the Mudarabah deal.
User will key in an outstanding Mudarabah deal reference and the related information such as: Product
code, Product Account, Deal Amount, previous Withdrawn amounts, total Withdrawn Amount, previous
Paid amounts, total Paid Amount, etc… is retrieved from the deal info, the withdrawals and payments
tables, and then displayed.
The remaining amount to be paid in order to settle the deal is debited either to the customer current
account or to a G/L account thus allowing making a final payment.
System will compute the total realized profit and distribute it between the bank and the customer
according to their respective predefined % of profits.
a) In case of profit, it will be divided according to previously agreed on share.
b) In case of loss, the bank will bear it all. Losses will not be claimed later on to customer and there
will be no unpaid amount follow up.
Partial settlement may take place. ‫تصفية جزئية‬
In all cases, the settlement situation and status are recorded.
Note 1: In case losses are proven to be due to customer’s negligence or dishonesty, guarantees will not be
released and the case will be handled by legal department outside the Mudarabah module.
7.4.8 Main reports are:

 Detailed Monthly statement showing a range of Mudarabah operations by type.
 Monthly statement showing Mudarabah balances.
 Detailed Monthly statement showing Mudarabah operations income.
 Detailed Monthly statement showing Mudarabah operations settlements.
 Statistics by economic sectors
 Profit & Loss statements

7.5 Musharakah Financing Specificities

7.5.1 Musharakah Agreement Scope
 Defining Purposes and Operation types, examples:
o Financing Real Estate ( ‫) عقار أو شقة‬
o Financing Business Start up ( ( ‫الحرفيين‬
 Defining Capital Contribution and Risk Sharing accordingly
 Defining Income / Profit Distribution Rates
 Defining Roles
 Income distributed according to :
o Settlement of Musharakah Capital
o Bank revenue share
o Customer revenue share
 Possible additional income is due to the customer.
 Diminishing Musharakah ‫ مشـاركة متنـاقصة المنـتـهية بالتــمليك‬ends up by transferring ownership to
customer.
7.5.2 Products Definition

Products’ conditions and constraints definition process is similar to Murabaha Products, thus allowing
setting the boundaries and general condition to which the deal should abide.
Specific Musharakah products information being mainly:
 Musharakah Type Diminishing or Investment
 Multiple disbursement allowed or forbidden
 Allowed disbursement Period (Months)
 Contribution Shares:
o Bank Capital Contribution Percentage
o Customer Capital Contribution Percentage
 Income Distribution:
o Capital Recovery Share Percentage
o Bank Profit Share Percentage
o Customer Profit Share Percentage
 Behavior in case the deal expires: Settle / Liquidate the Deal or Extend validity
 Allowed Project Expenses types
7.5.3 Customer application, Approval and Validation

Customer’s information file, Credit facilities application, collateral and list of required documents are
handled through ICBS credit file customer’s information and Credit Facilities management module.
Additional functionality is provided to record Musharakah deal details including:
a) Musharakah Deal Reference
b) Project description / Economical Purpose ("‫)"جدوى اقتصادية‬. Within this study customer provides also
the expected income over the coming years: ‫خلو‬ and Rents (for each partition and globally). And
accordingly an expected duration for the recovery of funded amounts.
c) Musharakah contributions
d) Musharakah approved limits (Maximum Amount and Expiry date)

e) Customer’s accounts (Musharakah and Current)
f) Profit distribution shares
 Musharakah recovery share (% of income)
 Bank’s profit share (% of income)
 And in some exception cases customer’s profit share (% of income)
g) Narrative conditions that describes the deal.
h) Conditions pertaining to the nature of expenses that the Mudarabah would cover.
i) Charges and expenses: Stamps and fees (such as Application study fees).
After studying all documents, the Bank conducts a calculation to determine the number of year is required
to recover the funded amount. In case the number of year is acceptable (depending on the region and
shares) the Bank would approve the deal.
7.5.4 Musharakah utilization / disbursements

This function is used to allow withdrawals / disbursements operations.
User selects the Musharakah deal reference and the system will browse the related information such as:
Product code, Product Account, Outstanding deal Amount, etc.
Customer presented bill or required disbursement is captured.
required, the Musharakah amendment function can be used to grant additional limit).
This amount is credited either to the customer current account or to a G/L account.
The second screen of this function shows all the:
o Previously made withdrawals / disbursements
o Bank's approved and posted charges (If applicable)
1.1.1 Updating Project Specifications

This function is used to describe / update the Diminishing Musharakah project’s specifications. (In case of
Building Projects). User will select the Diminishing Musharakah Deal Number and then capture the project’s
specifications such as: Project Number, Project Name, Location, Space, Number of Apartments, Number of
Floors, Expected Yearly Rent Amount, Expected Key Money Amount, etc…
1.1.2 Musharakah Amendment

This function is used in order to allow amendments on the deal contract. User will inquire about the
outstanding Musharakah deals and then extend the Expiry Date or Increase or Decrease the deal amount.
In case of decreasing the deal amount, the new amount cannot be less than the total already withdrawn
amount. A commission for Amendment can be charged to the customer.

7.5.5 Repayment / follow up and Musharakah Settlement ‫تصفية‬

Basically, once the activity starts to generate income, proceeds will be remitted to the bank with the
supporting documents (example copy of customer’s issued invoices / receipts) that will credit the
Musharakah account / distribute received income in accordance with agreement.
Nevertheless, repayments can be:
 Either in accordance with a pre-agreed schedule similar to Murabaha, Ijarah or Istisna’a (for this
case please refer to ICBS Islamic Financing Common Operations described above)...
 Or free repayment subject to project activity.
This function is used in case of free repayment Musharakah operations. This function allows recording the
received income and will credit according to the deal set percentages:
a) The Musharakah account.
b) Bank’s profit account
c) And if applicable: Customer’s current account.
The objective remains to recover the funded amounts, settle the Musharakah and transfer ownership to
customer. Thus in case income is higher or less than excepted. This would shorten or lengthen the recovery
period.
7.5.6 Musharakah Sale / closing

Similarly to the settlement process, Musharakah closing can be:
 Either automated in accordance with a pre-agreed schedule similar to Murabaha, Ijarah or Istisna’a
(for this case please refer to ICBS Islamic Financing Common Operations described above).
 Or manual closing subject to project activity.
This function allows manual closing the Musharakah deal.
User will select an outstanding Musharakah deal reference and the related information such as: Product
code, Product Account, Deal Amount, previous Withdrawn amounts, total Withdrawn Amount, previous
Paid amounts, total Paid Amount, total Recovered amount, etc… is retrieved from the deal info, the
withdrawals and payments tables, and then displayed.
The remaining amount to be paid in order to recover the disbursed amount is debited either to the
customer current account or to a G/L account allowing thus to make a final payment.
System will compute the portion of the settlement amount which recovers the capital and the remaining
amount (profit) will be distributed between the bank and the customer according to their respective
predefined % of profits.
7.5.7 Main Reports:

 Detailed Monthly statement showing a range of Musharakah operations by type.
 Monthly statement showing Musharakah balances.
 Detailed Monthly statement showing Musharakah operations income.
 Detailed Monthly statement showing Musharakah operations settlements.
 Statistics by economic sectors
 Profit & Loss statements

7.6 Parallel Istisna’a Specificities

Parallel Istisna’a is a contract of purchase of specified items to be manufactured or constructed with an
obligation on the part of the manufacturer or builder to deliver them to the bank upon completion.
Another form of deal known as Istisna’a’ takes effect through another contract. In this contract, the bank
acts in the capacity of a seller and concludes another contract with a customer to sell the specified items.
7.6.1 Parallel Istisna’a Origination

This function is used to capture a Parallel Istisna’a’ contract. User will select the required Parallel Istisna’a’
product and the related Product's conditions will be retrieved. Data entry process takes place.
Upon validation, system generates the Customer's Parallel Istisna’a’ account, the accounting and
customer's document / notes according to Bank's predefined parameters. In case of any excess of the
granted facility or in case no facility (credit line) the overdraw process is triggered.
7.6.2 Parallel Istisna’a Disbursement:

This function is used to allow withdrawals / disbursements operations. User will select the Parallel Istisna’a’
deal reference and the system will browse the related information such as: Product code, Product Account,
Outstanding deal Amount, Previously made withdrawals / disbursement, etc.
required, the Parallel Istisna’a’ amendment function can be used to grant additional limit).
This amount is credited either to the customer current account or to a G/L account.
7.6.3 Parallel Istisna’a Amendment

outstanding Parallel Istisna’a’ deals and then extend the Delivery Date or Increase or Decrease the deal
amount.
In case of decreasing the deal amount, the new amount cannot be less than the total already withdrawn
7.6.4 Parallel Istisna’a Follow Up Stages

This function is used in order to follow up the completion of each stage of the project.
User will select a ‘Parallel Istisna’a’’ deal number with a stage number and then capture the completion
percentage, the completion date or the new expected delivery date of Al Masnuu’.
If the new expected delivery date is greater than the delivery date agreed on upon the Parallel Istisna’a’
Origination, then the customer may be charged a penalty amount.
7.6.5 Reception of Al Masnuu’

This function is used in order to capture the delivery date of Al Masnuu’.
User will inquire about the Outstanding Parallel Istisna’a’ deal from the Deal Information and capture the
delivery date of Al Masnuu’.
If the delivery date is greater than the Delivery date agreed on upon the Deal Origination, then the
customer may be charged a penalty amount.

7.7 Salam / Parallel Salam Specificities

7.7.1 Salam Origination
This function is used to capture a Salam contract. User selects the required Salam product and the related
Product's conditions will be retrieved. Data entry process takes place. Upon validation, system generates
the Customer's Salam, the accounting and customer's document / notes according to Bank's predefined
parameters.
7.7.2 Salam Disbursement

This function is used to perform the withdrawal operation. The amount to be disbursed is equal to the deal
amount and cannot be modified (in general, the customer withdraws the total deal amount in one
withdrawal operation upon performing the Salam contract). This amount is credited either to the customer
current account or to a G/L account.
7.7.3 Salam Amendment

outstanding Salam deals and then extend the Delivery Date or Increase or Decrease the deal amount. In
case of decreasing the deal amount, the new amount cannot be less than the total already withdrawn
7.7.4 Reception of Al Muslam Fih (Salam)

This function is used in order to capture the delivery date and Goods of Al Muslam Fih. User will capture
the delivery date of Al Muslam Fih. Upon Validation, System will produce the required accounting entries in
case the commodity or goods are not available (fully or partially).
7.7.5 Sale of Al Muslam Fih on Spot

This function is used in the absence of a prior "Parallel Salam" agreement.
Thus at the term of the initial "Salam" deal, bank will use the present function to sell back the received
goods (Al Musalam Fih).
User will select the respective salam deal, capture the Sale Amount
System will calculate and post the profit.
Accounting entries and customers' document will be generated according to bank defined business
rules.
7.7.6 Salam Cancellation

This function is used in order to allow Total or Remaining Amount (Percentage of Goods not yet delivered)
Cancellation of Salam Deal Contract. User will enter a Cancellation Percentage; thus cancelled % of Deal
Amount and Margin Amount will be computed accordingly. Upon Validation, System will produce the
required accounting entries` in case of:
 Total cancellation of Salam Deal.
 Partial cancellation of Salam Deal.
Customer may be charged a penalty amount.
7.7.7 Parallel Salam

This function is used in order to capture a Parallel Salam deal. User will select the Outstanding Salam deal
reference and system will browse the related information such as: Product Code, Product Account,
Delivery Date, Purchase amount which is the Salam deal amount, etc. User will capture the new customer
id with whom the bank is issuing a Parallel Salam as well as the Sale amount. The difference between the

Sale amount and the Purchase amount determines the Bank profit or loss.
7.7.8 Delivery of Al Muslam Fih (Parallel Salam)

This function is used in order to capture the delivery date and goods description of Al Muslam Fih. User will
inquire about the Outstanding Parallel Salam deal from the Deal Info table and capture the delivery date of
Al Muslam Fih. Upon Validation, System will produce the adequate accounting entries.
7.7.9 Salam Reevaluation

This is an optional function allowing the bank to re evaluate the already received or to be received goods
(Al Musalam Fih) according to the present market price.
User will select the respective Salam deal, capture present market price
System will calculate and post the re evaluation figures.
Accounting entries and possible document will be generated according to bank defined business
rules.
7.7.10 Parallel Salam Deal Closing (Liquidation)

This function is used in case the initial "Salam" agreement was cancelled and the Bank was not able to
deliver fully or partially the goods under the "Parallel Salam" deal.
User will select the respective "Parallel Salam" deal and confirm cancellation of the outstanding delivery.
Accounting entries and customers' document will be generated according to bank defined business
rules.
7.8 Credit Card Financing

7.8.1 Scope
ICBS “Credit Card Financing” and “Card Management” interface provides automation tools for the following
processes:
 Products Management: Defining the various cards products offered by the Bank / Financial
Institutions along with the respective category, terms and conditions, business rules, eligibility
criteria, conditions and business rules.
 Origination: Receiving and recording customers’ credit cards application requests with subsequent
details and documents.
 Approval: Automating card issuance multilevel approval cycle and documents validation in
accordance with respective product’s approval matrix.
 Executing cards requests:
o Issuing cards requests and submitting it to supplier (issuer) with all the required details and
approved limits.
o Receiving supplier responses and updating cards details.
o Delivering cards to customer and issuing activation requests.
 Handling Events On Cards and subsequent messages exchange with suppliers (issuers):
o Limits update
o Replacements requests
o Renewal requests
o Additional Cards request
o Stopping requests

 Automating Periodical Procedures including

o Receiving and processing transaction files
o Receiving and processing minimum due file
o Possible computation of charges, commissions and fees
o Deposits and Settlements
o Reconciliation and confirmation files
Note: This module is not intended to replace a “Card Management System” but rather provides interfaces
to third party solutions.
7.8.2 Credit Cards Products Definition

Using this module, System Administrator starts by defining the various Card Products the Bank will be
offering to its customers.
For instance authorized user would define for each card type:
 Product Code and Name
 Product Type: Example Revolving, Charge Card, Prepaid, etc.
 Supplier
 Card Category: Gold, Platinum, etc.
 Allowed currencies and the related accounts’ types (including accounts that will be used to register
transactions, settle due payments and eventually records unpaid due amounts).
 Fees Condition Set, Annual fees, Various Standard and Late payment Charges and Commissions to
be applied
 Settlements conditions : Minimum payment percentage and amount
 A set of indicators that will monitor the processing of the received transactions and settlement.
 Products boundaries, limits and transactions limits
 Eligibility criteria and Possible attached scoring card table
 Required documents and Takaful plans (insurance)
 Multilevel Approval matrix
 Transfer to delinquency conditions
7.8.3 Card Application and Approval Workflow

7.8.3.1 Card application Capture
This function is used to record Customers Application for one of the offered products. Process is as follows:
 Selecting the card product
 Conditions defined at product level will be displayed by default.
 Selecting Customer’s ID, Accounts numbers, entering required information, answering to
application fields and score cards.
 Possible overriding of products conditions.
 Capturing, scanning and recording the required documents and guarantee
Note 1 A facility to define walk-in customer’s information thus filling a complete application with answers
to Score Card for automatic evaluation is also available.

7.8.3.2 Multi level Approval Workflow

Applications are submitted for supervisors / managers for verification (information, documents,
guarantees, customer’s possible history, black list etc.) and approval or rejection.
Triggering of approvals workflow in accordance with defined rules, approval matrix and credit cards
application information.
Credit evaluation and complete study by the concerned profiles, including: Application details and
submitted documents, Applicant’s Situation, Debt/Income Ratio, Credit History, Scoring / Eligibility criteria
results, etc.
Approval / Escalation process (with email notification and comments) ending with:
 Approval by required profile(s) according to defined workflow and application information
 Rejection of the current application / Sent back with observation for update and review.
Approved application generates Cards Issuance Requests to the Cards Management System (Files or
messages).
Issued cards confirmations, including cards numbers are received from this latter and updated
automatically.
7.8.4 Card Change Status

Use this function to record instruction to:
 Replace a card, Renew
 Block
 Re-Edit pin
 Modify expiry Date
 Activate
 Pickup lost, Pickup stolen
User selects the required card by issuing a query using the following fields: Member ID (Customer ID),
Name, Account number, Card number, and delivery or Expiry date.
Then he will choose the required action. Modifying the expiry date requires entering the new date.
Requests are transmitted to the Card Management System.
7.8.5 Cards Processing

 Send Card File: Function used to extract into a message or file all validated Card Application to be
sent to card service provider.
 Reception of Card File: Program that loads received messages or files from card provider and
updates related data into ICBS such as card expiry date and card number.
7.8.6 Transactions Processing

Transactions Messages / File Reception: Receive messages / file containing all accepted transaction on
Credit Card products.
Received Transactions are subject to a validation process and can be rejected in case of exceptions.
Checking is against:
 Stopped Cards and Not yet activated cards
 Expired Cards
 Amount Exceeds account limit
Rejected transactions with related exceptions are recorded in a log table.
Processed transactions are saved into a historical table for further reporting.

7.8.7 Periodical processing

 Credit Card Monthly transaction confirmation reception from Credit Card Companies containing
detailed customers’ statements and eventual claimed fees.
 Calculation of POS / Transactions fees, Periodical fees and Due Amount.
 Collecting due amounts from Customers.
 Settlement of claimed amounts to Credit Cards companies.
7.8.8 Cash Back Management

Credit Card companies, and for promotion purposes, may grant customer some cash back or cash rebate
facilities. Cash back instructions may be received periodically (i.e. monthly) with a yearly total confirmation.

8 INTERNATIONAL MODULES
8.1 Foreign exchange & Money market
This module handles the following wholesale banking operations:
 Spot contracts (customers and correspondents),
 Forward contracts (customers and correspondents),
 Swap contracts (customers and correspondents),
 On line Dealer Plotter update
 Commodities Murabaha (Placements and deposits). Bank's International Murabaha and Reverse
Murabaha (commodities based): Sharia compliant (halal assets based) Murabaha with differed
profit making through deals with international counterparts
o Appointing a counterparty as “Agent” to buy “Commodities” from an agreed on Market
(ex London Metal Exchange)Settling / transferring due amount
o Selling commodities to the counterparty on a differed payment basis at their purchase
price plus a margin
 Bank's Wakalah Deposit / Lending
 Customer's Restricted Investment - Structured Specialized Investments
 Banks transfers for its own account.
Maker and checker concept thus offering:
1- Deals capture:
Operations are stored in a file that can be inquired on using several criteria as: operation reference,
counterpart ID, etc.
2- Supervisor Validation
Thus triggering automated accounting entries generation, limits and positions control (and
consequently possible hierarchical approval in case of exception), positions update, documents and
confirmation messages issuances.
Automated Accounting entries generation for all events:
- Contract date,
- Value date (batch automated event)
- Maturity date (batch automated event)
- Periodical Accruals
Treasury and Forex operations positioning and diary monitoring:
At any time, user can inquire about:
The foreign exchange dealer or global position by:
 Currency/value date,
 Currency all values added,
The treasury position by:
 Currency
 Bank /value date,

The treasury diary by:
 Currency consolidated for all banks
Customer position (Collateral & margin account).
Confirmation and Automated Settlement with advises issuance
Confirmation advises (Swift, letters) are automatically generated by the system, and can be produced on
pre-printed forms or continuous forms when applicable.
These advices are user defined and easily parameterized.
Interactive functions
Counterparts file management,
Deals input for all operations,
Operations cancellation,
Operations renewal,
Operations amendment.
Control, Validation and Processing:
Control and validation,
Batch processing at contract date,
Batch processing at value date,
Batch settlement processing at maturity date,
Batch accruals processing.
Inquiries
Forex position by currency, by value,
Forex position by currency, all values added,
Treasury position by currency, by bank and by value,
Treasury diary by currency, consolidated for all banks.
Reporting functions
List of correspondents,
Detailed list of deals,
Forex position by currency by value,
Forex position by currency all values added,
Treasury position by account by value,
Treasury diary by currency consolidated for all banks,
Monthly profit rate mismatch (all currencies consolidated),
Monthly Profit rate mismatch (by currency),
Beyond 2, 4, 6 and 12 months mismatch report,
Daily cash flow,
Correspondents money market and forex limits and utilization,
Correspondents limits and utilization by country,
FC/LC outright transactions register,

FC/LC swap book,
Daily gap report by currency,
Daily transactions register,
Statement of outstanding lending borrowing to correspondents.
Daily maturity (forward/swap),
Journal accruals (swap/forward,
Daily spot operations
Daily spot/forward operations (without swap),
Daily journal of exchange operations (with swap),
List of premium/discount (forward/swap) charges to pay,
List of premium/discount (forward/swap) product to receive,
List of premium/discount not yet due (charges to pay),
List of premium/discount not yet due (charges to receive),
Forward operations: facility/HO/customer,
List operation for forward fixed risk,
List of customer deposits in currency by branch,
Customer profitability,
8.1.1 Forex Operations

A set of functions to capture Foreign Exchange deals (spot, Forward and Swap) operations with
comprehensive deals information including:
 General Information: Reference and Deal Numbers, Transaction Date, Value Date, Operation
type, Directing and Secondary Currencies, Directing Amount, Equivalent in Secondary and in
Reference / Local currencies, Applied Rate(s)., Counterparts Id, Dealer, Contact Mean, Broker.
 Purchase Side of the deal: Currency, Amount, Value Date, To Receive At Correspondent ID,
 Sale Side of the deal: Currency, Amount, Value Date, To Deliver At, Correspondent ID, Medium Of
Correspondent ID, Intermediary Bank
 Bank to Bank Info / Narratives.
8.1.2 Commodity Murabaha Placement

This function appointing a counterpart as ‘Agent’ to buy commodities from an agreed on market and to sell
the commodity back to the counterparty on a differed payment basis at their purchase price plus a margin.
Deals information includes: Reference and Deal Numbers, Operation Date, Value Date, Commodity,
Currency and Market Price, Quantity, Cost Price, Margin, Maturity Date, Counterpart Id, Contact Mean,
Broker, Agent Commission, Number Of Days. Periodicity, Correspondents Banka (To Deliver At, Medium Of,
On Maturity To Receive At, Intermediate Bank), Bank To Bank Info
8.1.3 Customers’ Specialized / Restricted Investment

8.1.3.1 Deal Set Up
Similar to Murabaha Deposit but offering “Customer’s participations” in the investment and profit sharing.
Consequently it allows entering a Bank Participation amount less than the total investment amount while
accepting customers’ participations for the remaining amount. Mudarib fees percentage can be set to be by
slice of amount thus allowing having different fees percentage by customer according to this latter

participant.
8.1.3.2 Deal Template

A facility allowing retrieving outstanding or closed restricted investment deal and setting up new one
based on the retrieved data thus reducing data entry mainly when it comes to participations.
8.1.3.3 Participants Quitting Before Maturity Date

A utility allowing participant pulling out from the deal before maturity. Surrendered amount will go to the
Bank to complete the deal and the invested amount will be reimbursed back to the leaving participant.
Leaving participant may be also granted a part of the profit accrued so far and this on a prorated basis of
his participation, the period between deal booking date and surrendering date and the Mudarib fees.
8.1.3.4 New Participants Joining

Similarly, this utility allows a new participant joining the deal after deal booking date. Participation amount
will be deducted from the Bank’s own participation who will receive in return the new participation
amount from the joining participant. Joining participant would be also requested to pay to the bank a
compensation equal to the profit accrued so far and this on prorata basis of his participation, period
between deal booking date and joining date.
8.1.4 Commodity Murabaha Borrowing (Counterpart Deposits)

This function is used to enter a Commodity Murabaha Borrowing deal. It allows the user to buy
commodities from a counterpart on a differed payment basis at their purchase price plus a margin.
8.1.5 Wakalah Placement

This function is used to enter a placement with correspondent or bank. The funds are delivered upon
confirmation value date. At maturity correspondent returns the funds plus a margin.
8.1.6 Wakalah Borrowing

This function is used to enter a borrowing from a correspondent or bank. The funds are received upon
confirmation value date. At maturity they will be remitted back to the correspondent plus a margin.

8.2 OUTWARD TRANSFERS

ICBS Outward Transfer Module covers the following operations in local and in foreign currencies:
Customers Outward Transfer
Including different cases:
a. Simple case, a direct relationship between sender and receiver.
b. With an ordering Bank
c. With Ordering Bank and "Account With" Bank.
d. With intermediary
e. With Cover sent to Sender's Correspondent Bank (Reimbursing)
f. With Cover sent to Receiver's Correspondent Bank
g. With Reimbursement through both sender's and receiver's correspondent banks.
Customer outward transfer standing instruction management:
This set of functions allows executing periodical transfer for beneficiary outside the bank it covers both:
 Fixed amount transfer
 Conditional transfers based on available balance
Interbank transfers orders
Bank transfer for its own account
Bank transfer order in favor of other banks
A set of Queries and reporting functions
As per ICBS standards “Outward Transfer" module provides:
 A complete transactions follow up,
 Control, validation and generation of :
 Payment messages and advises,
 Accounting entries.

 The customer calls on the bank to give his instructions, he may:
o Ask for a Fast Transfer (SWIFT, Fedwire, etc.) or a Check letter (Draft Check).
o Ask the bank to debit his account or pay cash.
o Pay in a different currency (foreign exchange).
o Specify the amount to be transferred or the Counter Value of the amount to be transferred
o Ask to settle charges and commissions or to be deducted from the transfer amount
 The request is studied and in case it is valid, the primary information is captured, (Customer account
number and Customer’s instruction). User will be able to check the customer’s signature.
 Validity and limits checking are processed, default values are generated.

 Information are subdivided into categories and screens were conceived accordingly:
a) Customer’s and transfer’s amount and payment mode related fields
b) Beneficiary’s information
c) Transfer order receiver’s information
d) Eventually covering correspondents
e) Commissions and charges
 All information is recorded into a transaction file for supervisor validation (Maker and Checker).
 As long as the supervisor does not validate the outward transfer, it can be modified or cancelled.
 Upon validation by the supervisor and according to the payment and covering modes and defined
business rules, system generates:
 Adequate accounting entries.
 The customer’s documents
 Correspondent messages (SWIFT) or a settlement message to a domestic clearinghouse or
institution (Such as a Fed wire message in the US) and post it to the respective terminal
selected Queue
8.2.2 Possible Configuration Workflow

Upon implementation the Bank may decide to:
Option 1. Implement the complete module at Branch Level
Option 2. Implement the complete module at Head Office level
Option 3. Split the operation between the branch and the head office whereby:
a. Transfer is initiated at branch level (At branch the customers instructions including
the beneficiary and bank of the beneficiary addresses are captured; the
commission are calculated and the branch notes and accounting entries are
generated to debit the customer account and credit a branch with head office
account).
b. Upon validation at branch level, Transfers are transmitted to Head office for further
processing.
c. At the head office the receiver bank and the eventual covering correspondents are
captured; messages are generated and correspondents are credited.

Interactive Functions
Customer Outward Transfer:
- Payment advice to the receiver, using nostro/loro account
- Payment advice to the receiver, using his head office nostro/loro account
- Payment advice to the receiver, followed by a covering through the clearing house
- Payment advice to the receiver, followed by a covering through our correspondent
- Payment via the clearing house
- Payment by issuing a check
Interbank transfer for its own account
Interbank transfer favor another bank
Modification of a not validated transaction

Cancellation of a not validated transaction
Control validation and processing
Control and validations (Technical and Overdraw)
Batch processing
Inquiries (Daily and historical)
Outward transfer's inquiry by reference number,
Outward transfer’s inquiry by date and by currency,
Outward transfer's inquiry by customer ID,
Outward transfer's inquiry by correspondent,
Outward transfer's inquiry by date and amount counter value in local currency,
Outward transfer's inquiry by date and import country code,
Inquiry about deleted outward transfers.
8.2.4 Reports and messages:

Swift/wire type 103 payment order,
Sheet payment order,
Swift/wire Type 202 covering order,
Swift/wire type 200 bank transfer for its own account,
Check letter,
Clearing house transfer order,
Outward transfers list by reference number,
Outward transfers list by beneficiary,
Outward transfers list by correspondent Id,
Outward transfers list between two dates,
Outward transfers list by transfer's currency code,
Outward transfers list by import country code,
Outward transfers list by customer Id,
Deleted outward transfers list,
Audit report by operator code,
List of daily transactions,
List of not validated transactions,
List of pending transactions,
List of transactions by type of operations.

8.3 INWARD TRANSFERS

The Inward Transfer Module covers the following operations - in Local and in Foreign Currencies:
 Inward transfer in favor of Customers
o Funds are received through a nostro/loro account,
o Funds are received via a transfer through the clearing house
 Inward Transfer in favor of Non Customers: In this case, payment order will be recorded in the
system and according to received transfer instructions:
o Keep it at disposal for the beneficiary,
o Or retransfer it to another bank.
 Interbank transfers orders execution
As per ICBS standards “Inward Transfer" module provides:

The Bank receives a Payment Order issued by an ordering bank.
This order is received through
a) An electronic file transfer in a standard format like a Swift message (MT103)
b) A different type of Media / Message
In case of electronic standard format, the order information can be uploaded automatically and processed
through one of the following procedures:
1) Straight Through Processing (STP)
If account is clean (readable) and amount is less than a predefined limit, beneficiary account is
credited automatically after deducting the bank charges.
2) Manual Intervention
If the amount is greater than the predefined limit or beneficiary account belong to the bank but not
clearly entered, order instructions are uploaded to the inward transfer function, user will have to
complete/confirmed the received information before crediting the beneficiary account.
3) If beneficiary instruction are not well defined or does not contain a clear bank account number
funds are kept at disposal until further processing.
On the other hand bank account to be debited depends on the following criteria:
 If the funds received are in foreign currency, the ordering bank (our correspondent) is inputted or
identified by its Swift code and correspondent account to be debited is selected from the
correspondent by currency table.
 If the funds received are in local currency the ordering bank (Sender) and the local bank
(Intermediate) are inputted but the Clearing account is debited.
In case of order are received by other type of Media all information is captured manually.

Main Functions
8.3.2 Interactive Functions

- Inward transfers in favor of customers:
 Funds are received through a nostro/loro account,
 Funds are received via a transfer through the clearing house
- Inward transfer in favor of non-customers with direct payment,
- Inward transfer in favor of non-customers, funds are kept at disposal, waiting for the beneficiary
instructions.
- Payment to the non customer after receiving instructions:
 Payment to non customer via one of our branches (Cash for example)
 Payment to non customer by a transfer advice to the receiver, using nostro/loro account
 Payment to non customer by a transfer advice to the receiver, using his head office
nostro/loro account
 Payment to non customer by a transfer advice to the receiver, followed by a covering
through the clearing house
 Payment to non customer by a transfer advice to the receiver, followed by a covering
through our correspondent
 Payment to a non customer by transfer via the clearing house
 Payment to a non customer by issuing a check
- Interbank Transfer Execution
- Modification of a non-validate transaction
- Cancellation of a non-validate transaction.
- Control and validations.
- Batch processing
Inquiries
Inward transfers inquiry by reference number,
Inward transfers inquiry by date and currency,
Inward transfers inquiry by date and customer ID,
Inward transfers inquiry by beneficiary name,
Inward transfers inquiry by correspondent,
Inward transfers inquiry by date and operation type,
Inward transfers inquiry by date and country code,
Inward transfers inquiry by date and amount counter value in local currency,
Inquiry about canceled inward transfers.

Reports and messages
Detailed inward transfers report,
Customer credit advice's/ advice for non customer,
Check letter,
Clearing house order,
Swift/wires messages,
Inward transfers list,
Inward transfers list by beneficiary,
Inward transfers list by correspondent,
Inward transfers list received between 2 dates,
Inward transfers list by currency and customer ID,
Inward transfers list by currency and reference number,
Inward transfers list by country,
Deleted inward transfers list,
Audit report by operator,
None validated transactions.

8.4 FOREIGN CHECKS REMITTANCES

8.4.1 General procedure
The Foreign Checks Remittances module provides a complete follow up for the local and foreign currencies
checks drawn on foreign banks (i.e. which cannot be collected via local clearing house). Check remitter can
be a direct customer, an affiliated bank customer or non customer.
The check remitted at one of the bank branches, trigger one of the predefined banking procedures based
on the international banking criteria and bank policy. Usually the choice of the procedure depends on the
following:
 The remitter is a customer or not,
 The check is in local or foreign currency,
 The check is drawn on one of the bank's correspondent,
 The check's currency is the same or is different from the currency of the drawn on country,
 A previous agreement exists with the correspondent selected to collect the check.
The following critical information will guide the user through the different cases and steps and display the
adequate screens of the above listed functions:
- Credit mode:
 Immediate,
 After collection,
- Covering mode:
 Through a correspondent with "guarantee agreement" (cash letter),
 Through a bank with agreement on commission,
 Through a bank with no particular agreement. The selected bank will transfer the
- Funds using one of the following modes:
 Directly credit our account,
 Credit our account at one of our correspondents bank,
 Issue a new check in our favor
- Check return status:
 Paid,
 Unpaid,
 Paid with commissions/charges deduction.
As per ICBS standards “Foreign Checks Inward Transfer" module provides:

8.4.2 Main functions

- Checks remittances,
- Checks individual settlement,
- Cash letters' checks collective settlement,
- Manual tracer.
Control, validation and processing
- Control and validations
- Batch processing (including automatic tracers).
Inquiries
Remitted checks inquiry by date and reference number,
Remitted checks inquiry by date and currency,
Remitted checks inquiry by date and customer ID,
Remitted checks inquiry by correspondent and currency.
Returned paid checks inquiry by date and reference number,
Returned paid checks inquiry by date and currency,
Returned paid checks inquiry by date and customer ID,
Returned unpaid checks inquiry by date and reference number,
Returned unpaid checks inquiry by date and currency,
Returned unpaid checks inquiry by date and customer ID.
Reports
List of outstanding checks by:
- Reference number,
- Date and customer ID,
- Date and checks currency,
- Correspondent ID,
- Remittance date.
List of settled checks (paid and unpaid) by:
- Settlement date and reference number,
- Settlement date and customer ID,
- Settlement date and checks currency,
Checks for collection statistical report,
Detailed checks for collection report.

8.5 IMPORT BILLS FOR COLLECTION

The Import Bills for Collection sub-system of the ICBS International covers the different types of the bills for
collection (Documentary/Clean check, Sight payment/Acceptance/Mixed, Foreign/Local currency, etc.)
through the following functions:
- Import bills for collection reception,
- Shipping L/G Issuance
- Modification request and advice of fate,
- Import bills for collection modification,
- Import bills for collection acceptance with or without return draft,
- Import bills for collection cancellation (all types).
- Import bills for collection payment

The "Import Bills For Collection" subsystem provides:
- A complete transactions follow up,
- Control, validation and generation of:
 Swift messages and advises,
Reception of a bill for collection (documentary/clean check),
Shipping L/G issuance
Modification of a bill for collection (documentary/clean check),
Import bill of collection acceptance,
Reception of a request for modification / advice of fate,
Refund of margin (in case of guaranteed bills)
Cancellation of a bill for collection,
Modification of payments schedule
Not paid bill for collection,
Bill for collection payment :( after bill reception or direct payment)
 Payment advice to the remitting bank using nostro/loro account
 Payment advice to the remitting bank using his head office nostro/loro account
 Payment advice the remitting bank followed by a covering through the clearing house
 Payment advice the remitting bank followed by a covering advice to our correspondent
 Payment via a transfer through the clearing house
 Payment by issuing a check
Return of LG note

Control, Validation and Processing
Control and validations (technical and overdraw),
Batch processing
Inquiries (Daily and historical)

Bills for collection inquiry by reference number
Inquiry by maturity date and currency
Inquiry by customer
Inquiry by remitting bank
Reports
Import bills for collection and detailed list,
Advice of a collection order reception,
Swift/telexes and advises (Payment advice, Covering message, Reception acknowledgment, Advice
of acceptance, Advice of fate and Request for instructions, etc.),
Outstanding bills for collection list,
Bills for collection listing by customer,
Bills for collection listing by remitting bank,
Bills for collection listing by covering correspondent,
List of received collection between two dates,
List of settled collection between two dates,
List of canceled collection between two dates,
Daily diary of import bills for collection,
Outstanding Sight bills for collection,
Accepted bills for collection,
Accepted against guarantee,
Bills received under acceptance,
Outstanding Shipping L/Gs,
Outstanding bills for collection by currency and type,
Monthly financial report,
Global situation report,
Not paid bills for collection,
Bills transferred to other bank,
Shipping LGs endorsements.

8.6 EXPORT BILLS FOR COLLECTION

The Export Bills For Collection sub-system of the ICBS International covers the different types of the Bills for
Collection (Documentary/Clean Check, Sight payment/Acceptance/Mixed, Foreign/Local currency, etc.)
through the following functions:
- Export bills for collection remittance,

- Export bills for collection modification,
- Acknowledgment of reception,
- Reception of request for modification (Followed by an execution or refusal),
- Tracer,
- Export bills for collection acceptance reception,
- Export Bills discount
- Export bills for collection cancellation,
- Export bills for collection not paid,
- Export bills for collection payment.
The "Export Bills For Collection" subsystem provides:

Export bills for collection remittance (documentary/clean checks),
Export bills for collection modification (documentary/Clean checks),
Acknowledgment of reception,
Reception of a request for modification,
Refusal of a request for modification,
Tracer,
Export bills for collection acceptance reception,
Export bills for collection cancellation,
Export bills for collection not paid,
Export bills for collection payment:
-. Reception of funds through our correspondent
- Reception of funds through the clearing house
- Reception of a check in foreign currency
- Reception of a check in local currency

Control and validations,
Batch processing.
Inquiries
Export bills for collection inquiry by reference number
Export bills for collection inquiry by maturity date and currency
Export bills for collection inquiry by customer
Export bills for collection inquiry by collecting bank
Reports
Export bills for collection detailed list,
Swift/telexes and advises (Drawer's advice, Tracer, Collection order amendment, etc.)
Outstanding export bills for collecting report by currency,
Outstanding export bills for collecting report by customer,
Outstanding export bills for collecting by collecting bank,
Outstanding export bills for collection by type and currency,
Outstanding export bills for collection payments by maturity date,
Settled export bills for collection between 2 dates,
Daily transactions list,
Sight export bills for collection
Unpaid export bills for collection
Accepted bills for collection
Export bills for collection guaranteed by us.

8.7 IMPORT LETTERS OF CREDIT

The Import Letters of credit module covers the different type of L/Cs (i.e. : Revocable / Irrevocable,
Revolving, Confirmed, Not Confirmed, Transferable, Standby, Red Clause, Back to Back, Payment at
sight/Under acceptance/Negotiation/Differed Payment, Global or Partial Shipment, etc.) through the
following functions :
Import Letters Of Credits:

 Pre advice,
 Issuance of all types of L/C ( sight, time & mixed ) and transfer,
 Amendment
 Cancellation.
Documents:
 Reception, (with or without discrepancies)
 Withdrawal,
 Payments (including Advance payments, At sight payment, At maturity payment, Payment
upon certificate presentation).
 Cancellation of document with discrepancies
Shipping L/G Issuance,
Murabaha Trade Finance

 Bank will buys the goods
 Customer will be reimbursing (the goods price + a bank profit) according to an agreed-on
differed payments schedule.
Historical files management,

Customer risk management.
The "Import Letters Of Credit" subsystem provides:

 Letters of credit, Telexes, swift messages and advises,

Import LC pre-advice,
Import LC issuance,
Import LC amendment (Increase, decrease, validity extension, etc.),
Import LC cancellation,
Import LC Advance payments,
Import LC documents reception,
Import LC documents withdrawal,
Import LC payments on maturity,
Import LC shipping LG issuance,
Receipt of documents under collection basis,
Settlement of documents received under collection basis,
Cancellation of documents received under collection basis,
Control and validations (technical and overdraw),
Batch processing.
Inquiries
Import LC situation inquiry
Import LC confirmation inquiry
Risk under LC inquiry
Daily transactions inquiry
Reports
Import LC Detailed situation,
LC confirmation,
Short telex confirmation - issuance,
Full telex confirmation - issuance,
LC amendment confirmation,
Telex confirmation - amendment,
Documents arrival advice to branches,
Daily operations on LC,
Daily accounting entries on LC,
Daily statement of documents sent to branches,
O/S LC by advising bank,
O/S LC by paying bank,
Settlement letters,

Customers O/S LC,
Customers LC monthly report,
Customers O/S acceptance under LC,
Advances on documentary credit situation,
Daily diaries for advances maturities,
Daily diaries for acceptances maturities,
Expired LC report,
Correspondent intermediate A/C reconciliation,
Customers daily risk situation,
Customers profitability under import LC,
LC opened during the month,
LC settled during the month,
Import financing report by nature of goods,
O/S LC under shipping LG,
LC statistics by countries,
LC statistics by currencies.

8.8 EXPORT LETTERS OF CREDIT

As for the Import Letters of Credit, the Export Letters of Credit Sub-System Module covers the different
type of LC through the following functions:
Export Letters Of Credits:

 Reception of preadvice.
 Notification of all types of L/C ( Sight, Time & Mixed ),
 Amendment,
 Cancellation.
Documents:
 Negotiation (document with or without discrepancies, sent for approval)
 Settlement (on maturity dates, advance payment, payment upon certificate presentation).
 Discount
 Cancellation of document with discrepancies and refused.
Historical files management.
The "Export Letters Of Credit" subsystem provides:

Export LC Reception of preadvice,
Export LC notification,
Export LC amendment,
Export LC cancellation,
Export LC advance payment,
Export LC documents sent on approval,
Export LC documents negotiation,
Export LC discount,
Export LC time settlement maturity.
Export LC cancellation of documents with discrepancies and refused.


Batch processing.
Inquiries
Export LC situation inquiry
Daily transactions inquiry
Reports
Export LC detailed situation,
Export LC daily operations,
Export LC daily accounting entries,
Export LC monthly opened,
Export LC monthly settled,
Export LC settled confirmed by us,
Export LC monthly expired,
Export LC by nature of goods,
Export LC by currency,
Export LC by country,
Outstanding export LC,
Daily diaries for acceptances maturities,
Export financing report by nature of goods.
Statistics by countries
Statistics by currencies.

8.9 LETTERS OF GUARANTEE

The Letters of Guarantee sub-system covers the different types of Letters of Guarantee (Foreign/Local, Bid
Bond, Shipping, Performance, Private/Public Sectors, Automatic Renewal, Partial commission payment,
etc.) from the date of Issuance till cancellation.
The Letters of guarantee sub-system main purposes are:
 Complete automation of local and foreign letters of guarantee (counter guarantee),
 Issuance of letters of guarantee and amendments notes,
 Confiscation of a letter of guarantee
 Cancellation of a letter of guarantee
 Renewal of a letter of guarantee
 Partial commission payment
 Control details of customers risk under LG,
The "Letters Of Guarantee” subsystem provides:
 Letters of guarantee, SWIFT, telexes and advises,

LG reception and issuance (with or without counter guarantee)
LG amendment (Increase, Decrease, Validity extension),
LG confiscation
LG cancellation
LG renewal
Partial commission payment

Batch processing (prorated commissions and automatic renewals).
Inquiries
LG situation inquiry
LG risk inquiry
Reporting Functions
LGs detailed situation
LGs daily operations
Letters of guarantee confirmation
O/S liabilities under LG
Customer outstanding liabilities under LG
Customer risk under LG.
LGs over a defined amount & margin less than 100%
Outstanding LGs monthly statement
Banks and branches O/S LGs
Private sector LG's
LGs maturity diaries
LGs opened between two dates
Confiscated LGs report
Shipping guarantees with 45 days passed since issuance date
Expired foreign LGs
Outstanding foreign LGs.
Foreign LG's Commissions
O/S LG's Monthly Statement
Commissions cashed in advance
Partial commissions due date
LG's Stamps Situation
Comparison of present year against previous year.
Comparison of the year / last year
Confiscated LG's
O/S Shipping Guarantee from 45 Days

9 CAPITAL MARKET MODULES

9.1 front OFFICE
The Front Office module is designed to covers capital market dealing room operations through the
following functions:
 Customer global position inquiry with drill down facility to details
 Orders placing / execution with on line, real time position update
 Orders situation inquiry (pending, executed, etc.)
9.1.1 Customer position inquiry

When broker receives a call from a customer, he would inquire about customer’s portfolio situation with a
possibility to access detailed information through a drill down inquiries showing:
 Portfolio details (Stock / Equities, Bonds / T. Bills, Futures, Options, Mutual Funds)
 Pending orders,
 Margin call / Buying power,
 Accounts positions & Statement of accounts,
 Marked to Market Revaluation.
9.1.2 Placing an order

A user-friendly function to promptly record customers’ orders including:
 Traded instrument,
 Buy or sell action,
 Number of contracts
 Pricing conditions,
 Order validity, (GTC or DO),
 Order type (At Market, Stop loss, Stop limit, Covering Short, Market on Open, Market on
Close, Market if Touched,)
 Session (Floor, Before Open, After Close)
 Eventual conditional orders (OCO, FOK, AON, IF DONE)
Moreover, a closing order can be filled automatically by simply clicking on the held instrument from the
customer global position screen.
In addition to the automatically generated deal number, and for auditing purposes, system logs the current
broker id, the date & time stamps, node id, etc.
Whenever and order is placed, system automatically holds in reserve the related amount and alerts the
trader.
9.1.3 Order execution

A timely updated screen browsing all pending orders with their last status (waiting to be performed, in
process, partially executed).
Interactions are timely recorded:
 Order placing with correspondent mentioning correspondents’ dealer
 Order execution confirmation (including: execution price, executed quantity)
Upon order execution, system automatically updates customer’s position and transfers order’s details to
Middle and Back offices for further processing.

9.1.4 Orders follow up and monitoring
At any time, authorized users can inquire about received orders statuses. Orders list is browsed by
customer / in chronological order and offers access to detailed information.
9.1.5 Customer acknowledgement

At any time, broker can inquire about the statuses of his orders. Upon selection of a specific order, related
detail and trader confirmation will be displayed.
The broker will acknowledge the customer accordingly. And deal will be submitted automatically to the
back office.
9.1.6 Back Office

The Back Office receives the operations of the Front Office, complete them and validates them.
At validation level
イ The accounting entries will be generated.
ロ The real time balances of the accounts and the position of the portfolio will be updated.
ハ The amounts and the quantities reserved will be reversed.
Front Office Back Office
Customer
Call the Broker
and put an Order
send the Order

Back Office User
complete the operation
Customer
Reserve
Account
Broker operation
Temporary
Inquir about Customer Position amount
Amount
Includig reserved amounts
Put an Order
or
Cancel pendig Orders Customer Remove
Update reserved Cancel
Portfolio
temporary Amount Temporary
No Temporary
position
Position
Update Supervisor
Validate the operation
Chech
Overdraw Yes
Generate Related Output

Confirm
the operation Generate Related Output
Management
No
Approval
Accounting
Yes Customer
entries and
Account
Advises
Customer
Portfolio
Dealer
receives orders from
Brokers and send Orders Send
to the Correspondent Operation Operation
To Back Office
Operation End of Day Processing
Operation
send the Order Confirm

the operation
Correspondent
Process orders and send
confirmation to the Dealer

9.2 Shares
Shares module is integrated with other ICBS modules and covers customers’ and own portfolios the stocks /
equities and mutual funds trading operations through the following functions:
 Instruments definition
 Daily price management (Including Automatic upload from REUTER)
 Commission rates definition
 Buying and selling operations
 Transfers of shares
 Handling charges collection and payment
 Dividends settlement
 End of month processing for the French Market (SRD – Differed Settlement)
 Mortgage
 Revaluation
 Stock events handling: Split, Reverse split, mergers, etc.
9.2.1 Financial instruments definition

All the financial instruments are defined in the system in order to be accessible from the trading functions.
 Trading Place
 Kind of Shares (Nominal or Bearer)
 Trading and National Currency
 Economic Sector and Nationality Etc.
9.2.2 Daily rates update

Every day, daily rates are captured (or automatically uploaded from Reuters).
9.2.3 Management of local stock exchange orders

An optional buying and selling orders function is available for emerging markets including handling of
nominal shares, shareholders numbers and certificates issuance.
9.2.4 Purchase & Sell

Handling of the various customers and bank’s operations with on-line portfolio update including
Spot and Monthly delivery (for French Market). Generation of user defined accounting entries and
confirmation messages / customer notes / etc.
Main information is:
 Purchase and sale, Trading or Investment
 Spot or end of month Delivery
 Operation for our own position, for our customers position or other banks position.
 Customer and correspondent price for spread operations
 Commission collected and commission paid
 On line Profit and Loss computation

 Handling of grouped orders and offering pools management
9.2.5 Shares handling management

 Shares transfer (deposit / withdrawal)
 Handling charges Collection/Payment
 Dividend collection and payment to customer
 Stock Split & Merger
9.2.6 End of day processing

 Update the historical tables,
 Revaluate bank portfolio, Revaluate customers portfolio
9.3 Bonds / SUKUK

Sukuk/Bonds modules are integrated with other ICBS modules and covers customers’ and own portfolios
the bonds trading operations through the following functions:
 Instrument and eventual periodical circulars definition
 Daily price management (Including Automatic upload from REUTER)
 Commission rates definition
 Buying and selling operations
 Transfers of Bonds
 Mortgage
 Revaluation, Premium amortization
 Accrual Processing, Coupon Payment, End of day and maturity processing
9.3.1 Bonds definition

All the financial instruments are defined in the system in order to be accessible from the trading functions.
 Trading Place, Trading and National Currency
 Economic Sector and Nationality
 Bonds type (Fixed Rate, Floating rate, Zero Coupon and Discounted)
 Calculation method (Actual/actual, Actual/360, Actual/364, Actual/365, US (NASD) 30/360,
European 30/360, etc.)
 Coupon frequency with possible different first coupon date for non-regular bonds.
9.3.2 Daily Rates Update

Every day, daily rates are captured (or automatically uploaded from Reuters) in the system.
9.3.3 Primary Market Subscription / Execution

For primary market T. Bills customers’ subscriptions are recorded, investment amounts are provisioned and
orders are communicated to issuing institutions. After receiving issuer confirmation, accepted deals are
booked accordingly.


Handling of the various customers and bank’s operations with on-line portfolio update. Generation
of user defined accounting entries and confirmation messages / customer notes / etc.
Main information:
 Purchase and sale, Trading or Investment
 Operation for our own position, for our customers’ position or other banks position.
 Customer and correspondent price
 Issuance, Maturity, Last coupon, Next coupon and Settlement dates
 Profit rates yield and price
 Nominal, Face and Purchase values
 Accrued profit, premium, profit and Loss
9.3.5 Bonds Handling Management

 Bonds transfer (deposit / withdrawal)
 Handling charges Collection/Payment
9.3.6 End Of Day Processing

 Revaluate bank portfolio, Revaluate customers portfolio
 Premium amortization
 Accruals calculation
 Pay profit at coupon date, Settle bonds at maturity date.

9.4 Options (If Applicable)

Options module is integrated with other ICBS modules and covers customers’ and own portfolios options
trading operations through the following functions:
 Contract Definition
 Prices and rates Management
 Purchase & Sale
 Manual exercise of options
 Automatic exercise of options at maturity
 Operation Cancellation
 Daily Confirmation printing
 Margin Maintenance
 Maturity Process
9.4.1 Contract definition

All options are defined in the system in order to be accessible from the trading functions.
 Trading Place
 Option Style (American/European)
 Put or Call
 Underlying equity
 Contract Size and Nominal Value
 Strike price
 Maturity date and exercising conditions

Every day, prices and rates are captured (or automatically uploaded from Reuters) in the system.

Main information is:
 Open or Close
 Purchase and sale
 Put or Call
 Premium, Margin and commissions


At each end of day a process is launched in order to:
 Revaluate bank portfolio
 Revaluate customers portfolio
 Premium amortization
At Maturity or coupon date in order to:
 Exercise or close the outstanding matured options
9.5 Futures (If Applicable)

Futures module is integrated with other ICBS modules and covers customers’ and own portfolios Futures
trading operations through the following functions:
 Contract Definition
 Prices and rates Management
 Purchase & Sale
 Operation Cancellation
 Daily Confirmation printing
 Maturity Process
9.5.1 Contract definition

All Futures are defined in the system in order to be accessible from the trading functions.
 Trading Place
 Underlying equity
 Contract Size and Nominal Value
 Future Prices
 Maturity date

Every day, prices and rates are captured (or automatically uploaded from Reuters) in the system.

Main information are:
 Purchase and sale

 Margin and commissions

At each end of day a process is launched in order to:
 Revaluate bank portfolio
 Revaluate customers portfolio
At Maturity or coupon date in order to: Settle future contracts
9.6 Wealth Management

Wealth Management module was developed in addition to the Securities module in order to track
customer’s profitability and portfolio performance through the following functions:
Strategy definition
Strategy proposal to customers
Portfolio constitution
Deposit/Withdrawal
Analysis Reports
9.6.1 Strategies Definition

This function consists of defining investment strategies and percentages of each investment.
The main information are:
 Strategy Number,
 Date
 Base currency,
 Initial investment,
 Investment Period.
 Distribution
 Type of investment (Cash, Shares, Bonds, Options, Futures).
 Instrument Code,
 Instrument Description
 Instrument Currency
 Percentage
 Amount
9.6.2 Strategy Proposal to Customer

This function serves to make a proposal to a customer, while applying the selected strategy to an
investment amount.
These proposals are stored with their currencies rates and used instruments to be able to revalue them in
the future and to test their performance.

9.6.3 Portfolio Management

This function serves to constitute/update customer portfolios:
The main information are:
 Today date,
 Customer ID,
 Strategy number,
 Initial investment amount,
 Base currency,
 Investment period,
 Debit and credit value dates
 Current account
 Initial Account of the portfolio
 Related Accounts
9.6.4 Specific Reports

Monthly performance
This report will show
1. The evolution of the invested amount (Initial amount, deposit/withdrawal)
2. The evolution of the managed funds and the number of accrued day
3. Monthly profit and losses
4. Monthly and accrued Returns rates
5. Returns rates for the period (Net Result / weighted average Funds)
6. Yearly Returns rates
Portfolio Breakdown
This reports allows to show Breakdown of customer's portfolio by different criteria (Currency, Country,
Economical Sector, Type of investment)
Performance Simulation of a proposal
This report allows evaluating of proposal already assigned to a customer. It prints the initial state of the
proposal and its value at today’s prices.

9.7 Back and Middle Offices Reporting

The reports provided by the system are the following:
 Advance On Security
 Alert Report
 Bank Financial Instrument
 Bank's Bonds Maturity Diary
 Commission Report
 Confirmation (Deal By Deal, Daily)
 Custodian Open Position
 Customer Open Position
 Customer Statement Of Transactions
 Customer's Bonds Maturity Diary
 Customers Short Position
 Daily Close Out
 Daily List Of Orders
 Daily Operation Register
 Daily Rates Report
 Depository Position
 Depository Statement Of Transaction
 Historical Of A Specific Instrument
 List Of Cancelled Deals
 List Of Cancelled Orders
 List Of Daily Operation
 List Of Grouped Orders Including Details
 List Of Not Executed Orders.
 List Of O/S Orders
 List Of Options In The Money
 Margin On Future
 Margin On Short Option
 Margin On Short Equities
 Monthly Performance
 Net Asset Value
 Physical Stock Movement
 Portfolio Distribution
 Portfolio Valuation
 Portfolio Valuation By Date
 Realized Profit & Loss

 Securities Position
 Securities Position By Date
 Statement Of Transactions
 Volume Of Trade (List Of Movement On A Specific Shares For A Specific Period)
 Volume Of Transaction Of One Or More Customer For A Specific Instrument.
 Local Market Daily Rates Variations
 Local Market Daily Statement
 Local Market Daily Summary Report
 Local Market Expired Orders
 Local Market Netting With Correspondent
 Local Market Outstanding Orders
 Local Market Shares Netting

10 REAL ESTATE MANAGEMENT

10.1 Scope
ICBS Real Estate Management functions are developed to automate management of Real Estates: Lands or
Built properties.
These functions can be used:
 Separately independently from any fund management where a real estate could be:
o Purchased for trading, investment or even acquirement from a defaulting customer.
o The object or the underlying asset of a Financing Operation (Murabaha, Ijarah,
Musharakah or Employee Housing Financing).
 Or within the investments activities of a defined fund. In this latter case, the functions of this
present module would be used in order to invest part of the fund’s raised amount in Real
Estate operations.
The general process being as follows:
1 Before acquiring a Real Estate it needs to be defined and estimated (assessed).
2 Acquired real estate:
2.1 May be subject to expenses
2.2 Are periodically re-evaluated
2.3 May be partitioned / developed
2.4 May be sold (or out of Bank assets following an event, see hereafter) or rented.
Consequently the present sub module covers the following functionalities:
1 Real Estate Definition
2 Request for Assessment of a real estate
3 Expert Assignment for assessing a real estate
4 Information Update / Revaluation
5 Real Estate Transactions
5.1 Acquisition / Purchase of A Real Estate
5.2 Rental and Rental Renewal
5.3 Expenses settlement and collection
5.4 Rental termination
5.5 Sale of a Real Estate
5.6 Non Financial Events Recording

6 A comprehensive Set of Reports & Inquiries including:
6.1 Real Estate Information Details
6.2 Assignment Orders
6.3 Profit & Loss from Real Estate Activities
6.4 Rents and Expenses Aging

6.5 Events and Transactions on Real Estates
6.6 Multicriteria Daily Transaction on Real Estates

10.2 Real Estate Definition:

A Maker and Checker process where a user will enter the known information and submit it for supervisor
validation. Some data may not be available at this level and would be completed upon receiving expert’s
detailed report (see hereafter). ICBS provides for comprehensive Real Estate information including:
 Real Estate type or category
o Land
o Not Partitioned Building (including possible piece of land and a number of built sections)
‫غير مفروز‬
o Built Section(s) (such as Flat-Apartments, Garage-parking, offices, etc.) within a building or
commercial center
 Real Estate reference, status, detailed geographical and location information.
 Real Estate General Information (Including dimension, assessment details, Bank adopted estimate
value, co-owners, Bank owned shares, ownership date / status and purpose, Possible link with
other operations (Murabaha , Ijarah Muntahia Bil Tamlik deal, Ijarah Bail el Ajil, Musharakah deal,
Employee Housing Financing), Direction of use Classification, Negative and Positive factors
influencing evaluation, Charges.
 Category Dependent detailed Real Estate information:
o Land Specific Information:
o External Building description / common utilities Specific Information
o Building within a partitioned or not partitioned Real Estate
o Sections: Flat / Apartment / Partition Specific Information
Supervisor browses pending operations. Validated movements are recorded into the master table(s).
10.3 Request for Assessments and Assignment of Expert

A request may be related to a Land, Building or Built Section Real Estate. Request may be issued by an
agent (internal or external party) along with: Assessment reason, Request date, References.
Then a user would select an assessment request with the underlying information (Real Estate to be
assessed, Requesting agent) and proceed with the expert’s assignment. Upon confirmation, system
generates a report with the Assignment order details.
10.4 Real Estate Information Update / Partitioning / Price Revaluation

This function is used to either capture the expert received report’s details and assessment results and / or
the Bank’s internal revaluation, development or partitioning information.
A maker and checker process, where captured data are submitted to a supervisor for validation. Upon
validation, real estate master information is updated, previous information logged and possible accounting
entries generated to reflect revaluation on Assets accounts and P&L accounts.

10.5 Purchasing a Real Estate

A multistep workflow where:
 User capturing an acquirement transaction and submits it to a supervisor for validation.
 Supervisor browsing captured transactions submitted to him for validation, approving the
transaction and system automatically:
o Updating Real Estate status and related information,
o Generating the respective accounting entries,
o Generating the acquirement contract
o And dependent on selected payment mode possibly initiating a check
issuance.
 Checks printing.
Operation main information being: Acquirement date, Purchase purpose, Number of shares, Agreed on
transaction currency, amount and value date, Settlement details.
10.6 Renting a Real Estate or Rental Renewal

Through the present function, bank would handle Operational Rental transactions. Otherwise (Leasing /
Ijarah Muntahia Bil tamlik or Bai El Ajil against issuance of differed bills need to be conducted through
respective ICBS financing modules. (For more information please refer to above section “ICBS Financing
modules”).
User captures a rental transaction for an already acquired not neither rented nor sold Real Estate.
Transaction includes possible definition of deposit amount and possible charges to be paid upon contract
signature.
Upon supervisor approval system issues the rental contract and generates required accounting entries for
instance to post deposit and charges.
10.7 Selling a Real Estate

Through the present function, bank would handle immediate payment selling transactions. Otherwise
(Term and / or scheduled payments selling with profit will be conducted through respective ICBS financing
modules (For more information please refer to above section “ICBS Financing modules”).
User captures a selling transaction for an already acquired not neither rented nor sold Real Estate.
Transaction will include the selling price and possible charges to be paid upon contract signature.
Upon supervisor approval system issues selling contract and generates required accounting entries.
10.8 Batch Periodical Collection of Rents and Scheduled Know charges

A to process scans rented apartments due from customer and not already paid periodical payments (rent
and known periodical charges defined as fixed amount or percentages) in order to:
 Generate respective accounting entries according to predefined parameters
 Update the due payment statuses accordingly.
In case due funds are not available, after x number of days (system parameter) system will debit an unpaid
account (type of account defined as a system parameter) related to the customer’s ID to settle the due
amount. A report will be produced accordingly.
10.9 Rental Termination

Set Real Estate / Section Status to available for sale or rent.
Settlement of all due and unpaid bills and possible return of Deposit to the customer
10.10 Other Non Financial Events

This function allows recording non financial events for follow up purposes.
Entered date will be recorded in the events table and would be browsed / printed through respective

functions.

11 FUNDS MANAGEMENT
11.1 Scope
Funds module is fully integrated with other ICBS modules and covers the life cycle of a fund since its
inception until settlement through the following functions:
 Fund’s Definition (Conditions and Investment Strategy) covering both:
o “Closed Funds” (i.e. funds with limited subscription period and capital)
o “Open Funds” (i.e. funds with unlimited subscription period and capital)
 Customers’ Subscriptions (or Participations)
 Closed Fund Conditions’ Modification before starting the investment phase:
o Subscription period extension
o Projected Capital Increase / Decrease
o Closing of subscription Period (For closed funds)
o Subscription period closure after having raised the required capital
 Funds Transactions and Investment of raised capital in the selected sectors and integration with
the related modules:
o Investing and Trading in Capital Market: Buying and Selling Capital Market Instruments
(Shares, Bonds / Sukuk, etc.).
o Placements in Commodities Murabaha / Wakala
o Financing Murabaha, Ijarah, Istisna’a, Mudarabah, Musharakah and Salam.
o Investing and Trading in Real Estates.
 Periodical Fees Deduction
 Periodical Fund Reevaluation
 Periodical Distribution of Profit
 Transfer of Shares between the Customers and the Bank:
o Customer’s Quitting: Withdrawal or Redemption from the Fund (i.e. Bank buying customer’s
units).
o Customer’s Joining:
 New Subscriptions increasing the Fund Capital (Open Fund)
 Bank selling from his own share to a customer.
 Fund Settlement or Liquidation
 A comprehensive Set of Reports & Inquiries including:
o Fund’s Issuance Circular
o Fund’s Conditions and Strategy
o Fund’s Subscription Certificate
o Fund’s Participants
o Fund’s Situation and Performance
o Fund’s Valuation
o Fund’s Calculated and Distributed Profit

o Profit to be distributed
o Fund’s Daily Transactions
11.2 Funds Definition

This function allows the fund manager defining the fund's conditions and related strategy. For instance he
will start by setting a Code and a Description for the fund being created indicating if the "Fund Type" needs
to be:
 A "Closed Fund": Limited Subscription Period and Capital to be raised
 Or an "Open Fund": Unlimited Subscription Period and Capital.
Then he would be requested to enter a number of information during fund creation / maintenance such as:
11.2.1 Basic Information

Inception Date, Maturity Date, Number of Items, Unit Price, Currency, Revaluation Periodicity (Daily,
Monthly), Index of reference, Minimum Investment, Minimum Subscription, Minimum Redemption.
11.2.2 Fees & Charges

Fees are defined as a percentage of the Initial value, the Net Actual Value (NAV) or the profit amount. Fees
types are Participation Fees, Management Fees/ Bank’s profit percentage, Custody Fees, Auditor Fees.
11.2.3 Investment Strategy/ Structuring

Diversification percentages are defined by type of investments, such as:
 Financing Products: Murabaha, Ijarah, Istisna'a, Mudarabah and Musharakah, Salam.
 International Murabaha / Wakalah
 Real Estate
 Securities / Shares Invest. In Shares Seq., Securities Country, Securities Currency, Securities
Market , Securities Type, Securities Economic Sector, Securities %
11.3 Funds Strategy / Structuring Update

This function allows browsing and updating the fund strategy in term of adding a new product or
redistributing percentages among products.
11.4 Customers’ Subscription/Participation, Redemption and Joining

Investors can participate by purchasing units of the funds. Investor’s money is combined and invested
according to each fund’s specific investment objectives.
 A function allows registering customers’ made subscription / participation in defined fund. Upon
confirmation, system generates the accounting entries reflecting the invested amount in addition
to possible fees and commission deduction.
 A similar function is provided for customer’s withdrawal from a fund (or redemption). Redemption
can be made in whole or in part at any time during the life cycle of the fund. Depending on funds
conditions and Bank’s defined business rules, withdrawal would take place according to “Bank
Purchase Price” (set after the last revaluation) or at a “Fixed Price” in accordance with Fund’s
Redemption conditions. Redeemed units may be automatically acquired by the Bank to reach
defined minimum subscription threshold (i.e. added to the Bank’s portfolio or participation).
 During the life of a fund, and depending on the fund’s conditions and rules, customer may Join for
the first time or submit additional subscription. The bank may be selling to the customer’s from its
own portfolio (participation) or from available units.
Note: Subscribed units can be held as collateral against granted credit facilities. Units will be flagged as

blocked collateral for credit facilities and possible accounting entries generated. Upon collateral release,
system reverses the accounting entries.
11.5 Bank’s Subscription/Participation And Redemption

This function is to be used by the fund administrator in order to possibly subscribe the Bank for the balance
of the remaining “Issued” and “Still Available” units (i.e. issued units but “Not subscribed to” by
Customers”). Upon confirmation of entered information, system generates accounting entries reflecting
the invested amount in addition to possible fees and commission deduction (If applicable).
11.6 Funds Transactions / Investments

Fund manager will invest the raised fund into the various sectors according to the fund’s defined strategy /
structure. To do so, standard ICBS modules would be used for these purposes and in favor of the selected
fund.
Type of Investment Through ICBS Module
Financing Murabaha ICBS Financing Operations: Murabaha
Financing Ijarah ICBS Financing Operations: Ijarah
Financing Istisna’a, ICBS Financing Operations: Istisna’a
Financing Mudarabah ICBS Financing Operations: Mudarabah
Financing Musharakah ICBS Financing Operations: Musharakah
Financing Salam ICBS Financing Operations: Salam Sections
Placements in International Murabaha ICBS Foreign Exchange and Money Market:
International Murabaha & Wakala
Investing in Capital Market: Shares & Sukuk ICBS Securities Operation : Shares & Sukuk
Buying and Selling Real Estates ICBS Real Estate Management
11.7 Periodical Fees Deduction (If Applicable)

Function used to calculate and post fund fees and commission such as management, auditor and custody
fees. Fees percentage and periodicity are according to fund’s definition.
11.8 Revaluation and Profit distribution

Revaluation takes place periodically and by stages.
Different items may have different revaluation periodicity, for instance:
 Securities (Shares and Sukuk) may be revaluated daily following the import / introduction of the
market pricing (Mark to market). Accounting entries will be generated based on the held securities
information, uploaded market price and Bank defined parameters.
 While Real Estate may be revaluated manually (and less frequently) using the above Periodical
estimates / Assessment / Price Re-evaluation function.
 As for financing deals and placements (International Murabaha and Wakala), no revaluation would
take place. The respective profit accruals procedures allow posting the accrued profit to date.
 Also (if applicable) fees may be deducted as described in the previous sections.
Depending on the fund’s type and condition, the unit value may be:
 Computed by dividing the total value of the portfolio, plus all income, including accrued income,
less management fees and any expenses, by the total number of units outstanding at that time.
 Kept as fixed amount.

Following Fund Revaluation process run completion, profit calculation and distribution allows at defined
periodicity:
 Summing up the profit booked so far
 Distribute the calculated profit according to the rules set at the respective fund definition level.
More precisely to distribute the profit according to the following sequence:
1. PER calculation and deduction
2. Mudarib Fees calculation and deduction
3. The General and Special provisions calculation and deduction
4. The Taxes calculation and deduction
5. Profit distribution to investors’: According to Customers’ and Bank’s participation / held
number of units. Profit distribution to investors’ would be based on:
 Option 1: Units held by each investor at a specified time
 Option 2: Adad points calculated based on the monthly minimum balance of each
investor account over a period (basically between last and actual profit distribution
dates).
11.9 Fund Settlement or Liquidation

Upon fund’s maturity date, using this batch function, fund manager will be able to settle / close funds thus
redeeming all outstanding participations including remaining profits to the investors’ based on:
 The last revaluate pricing.
 The outstanding profit
 Investors’ participations.
 Product’s conditions taking into consideration:
o PER calculation and deduction
o Mudarib Fees calculation and deduction
o The General and Special provisions calculation and deduction
o The Taxes calculation and deduction
o Profit distribution to investors’: According to Customers’ and Bank’s participation / held
number of units (see note 1).
Consequently system, will:
 Update Customer’s and Bank’s portfolios.
 Generates the accounting entries to reflect the above liquidation.

BML Istiharat ICBS Islamic Core Bnaking Capabilities Guide 2015.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BML Istiharat ICBS Islamic Core Bnaking Capabilities Guide 2015.1

Uploaded by

Copyright:

Available Formats

INTEGRATED

By BML Istisharat SAL

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 2

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 3

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 4

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 5

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 6

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 7

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 8

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 9

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 10

1.1 ICBS Strength Points

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 11

1.2 ICBS Modules Diagram

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 12

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 13

2 ICBS SELECTED REFERENCES

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 14

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 15

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 16

3 ICBS SUBDIVISION INTO MODULES

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 17

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 18

4 ICBS NUCLEUS AND STANDARD FEATURES

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 19

4.2 Interactivity and Ease of Operation through Standard GUI

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 20

4.3 On Line Real Time 24x7

4.3.2 Real Time 24 x 7 Mechanism

4.3.2.2 Measures before Launching End of Day process

4.3.2.3 Mechanism during End Of Day Process

4.3.2.4 After End of Day:

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 21

4.5 Security & Transactions Control

4.5.1 Group and users profiles

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 22

4.5.2 Users Authentication and Login

4.5.3 Audit Trail

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 23

4.5.4 Data integrity:

4.5.5 Transactions, control and validation

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 24

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 25

4.5.6 Escalations and Exception Management

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 26

4.6 Flexibility & Expandability

4.6.2 Configurable Screens and Reports Labels

4.6.3 Configurable Error Messages

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 27

4.6.4 Configurable Profiles

4.6.5 Codes, Parameters and Pricing tables

4.6.6 Configurable Products Business Rules

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 28

Special Investments accounts ‫حسابات استثمار مخصص‬

Purposes / Utilization ‫وجهة االستعمال‬

4.6.7 Configurable Islamic Accounting Products

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 29

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 30

4.6.7.2 Product’s General Main Conditions:

4.6.7.3 Islamic Profit Sharing Accounts

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 31

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 32

4.6.7.4 Additional conditions (per currency)

Capabilities Guide - © Copyright BML Istisharat CAPG I 2015.1- Page 33