R18 1

R18 3
R18 4
 Islamic Banking is Asset based banking where Asset is bought by the Bank and Sold to
the client on deferred payment basis. The Bank purchases the asset making payment
to the supplier of the asset and sells to the client who pays the bank on deferred
basis.

R18 5
 Islamic Banking is Asset based banking where Asset is bought by the Bank and Sold to
the client on deferred payment basis. The Bank purchases the asset making payment
to the supplier of the asset and sells to the client who pays the bank on deferred
basis.

R18 6
 The workflow is pictorially represented here. The process flow depicted is generally
followed. Asset Repossess and resale are for information and is slated for future
development.

R18 7
 Asset request is the 1st stage of the workflow where an agreement of promise to
purchase the asset is entered between the client and the bank.

Asset can be a named asset eg. vehicle, machinery, equipment etc. (or) quantifiable
asset eg. agricultural produce, minerals etc.
During this stage, the details of the client, supplier/vendor, asset cost, number of
units, currency are captured along with other static details of asset.

R18 8
 In the Asset pre-approval stage, the Sharia or credit auditor reviews and approves the
transaction. At this stage, the details such as down payment, additional cost incurred
can be recorded. This cost can be paid either by the Client or Bank. It is also possible
to add the cost to the finance amount and repayment schedule.

The next stage is the asset purchase, where the asset is purchased by the bank & is
accounted in the Bank’s books of accounts. It is also possible to link multiple assets
under a same purchase. If required, details such as down payment, additional cost
incurred which has been recorded already can be modified at this stage.

R18 9
 After the asset purchase stage, the subsequent payments are to be done. Payments
to vendor, cost counterparty, reviewer, broker can be made.
Payments can be consolidated vendor wise which can be paid by adhoc or scheduled
basis. Also a percentage of the payment can be retained by the bank and paid
subsequently as Retention amount payment any time later.

In the Sale/Finance/Lease stage, the purchased asset held by the bank is sold to the
client for which the repayments are made as deferred installments.
In a lease (Ijara) where the client is a Lessee, lease rentals are paid to the bank. Sharia
based finance products available in T24 are Murabaha, Musharaka, Ijara, Istisna,
Salam, Modaraba, Wakala etc.

R18 10
 After the asset purchase stage, the subsequent payments are to be done. Payments
to vendor, cost counterparty, reviewer, broker can be made.
Payments can be consolidated vendor wise which can be paid by adhoc or scheduled
basis. Also a percentage of the payment can be retained by the bank and paid
subsequently as Retention amount payment any time later.

In the Sale/Finance/Lease stage, the purchased asset held by the bank is sold to the
client for which the repayments are made as deferred installments.
In a lease (Ijara) where the client is a Lessee, lease rentals are paid to the bank. Sharia
based finance products available in T24 are Murabaha, Musharaka, Ijara, Istisna,
Salam, Modaraba, Wakala etc.

R18 11
 For Islamic banking in T24, tables are classified as: Parameter related and transaction
related.

Note: Repurchase, Resale and Third Party/ outright sale are not part of this release.

R18 12
 The basic parameter tables which are to be set for Islamic banking in T24 are listed
here.

Note : IS.MUSH.PARAM – Is for future Use.

R18 13
 Transaction related tables for Islamic banking in T24 are listed here.
Islamic finance (sale) stage is processed in AA.

Note : IS.DISBURSEMENT – is work in progress.

R18 14
 The 1st level table in Islamic banking is the IS.PARAMETER which is the mandatory
table to define the Islamic Banking product related features.
The ID of the table is numeric - Values 1 to 999 can be specified. Product name is
described in the field DESCRIPTION.

AA Islamic products are defined under the Lending Product Line which is to be
proofed & published before defining the IS.PARAMETER, upon this the AA.Product
field in the parameter can be set which refers to the AA.Product. Single or multiple
Islamic products can be linked.

R18 15
R18 16
 Each of the work flow statuses for the products can be defined in EB.LOOKUP table
with prefix IS.WF.STATUS (eg. IS.WF.STATUS*PURCHASE)
which is displayed as a dropdown in the field STATUS which can be multi-valued.
Status like Request, Approval, Under Construction, Purchase, Advance Purchase,
Delivery, and Resale have been created in the system.
User defined status can be created based on client requirement which is displayed in
STATUS in this table, STATUS gets auto updated at the time of contract processing.
The order of the status defines the order of the workflow for each product.

R18 17
 Accounting rules can be parameterised in the Table IS.STATUS for each of the STATUS
defined here.
FIN.ELIG.STATUS refers to the status that enables a sale
process to be carried out. For some of the products like
Bai Salam, the eligibility for sale
is delivery of the asset.
COMPANY and the associated Sub value RESTRICT.ASSET
specifies the Company/s which allow creating
transactions under the defined product as well as the
restricted assets under the companies.
The Category codes and transaction types are used at the time of accounting.

R18 18
 It is possible to retain part of payment amount that was
paid to vendor or supplier and credit to an Internal
account for releasing at a later date. RETENTION.CAT defines the
category code to hold the retention amount and RETENTION.PCT defines the
percentage of amount that is to be retained.
The retained funds are paid to the supplier/vendor through IS.PAYMENT either as
external or Internal payment.

R18 19
 Restrict.Cost defines the cost/s which are restricted for the product.

Additional Cost can be specified for the Asset purchase which can be paid to the cost
counterparty by the client or the bank. Also this cost if needed can be added to the
finance amount as well. The cost/s are defined in IS.COST.TYPE table where
FT.CHARGE.TYPE or FT.COMMISSION.TYPE to default additional cost during purchase.

R18 20
 The number of decimal places for specifying the unit price of the Asset can be
specified in the field DECIMAL.PRICE.
CONTRIB.BY.ASSET - This field if checked will allow the Down payments to be made as
Asset.
DP.STAGE defines at which stage the Down payments can be made to a deal whether
at the contract stage or at the finance stage.
In order to track delivery of quantifiable assets and named assets the field
TRACK.DELIVERY is checked. By this it would enable delivery tracking for products like
Bai Salam and Tawarruq.

R18 21
 SALE.SETTLE.CAT, SALE.PROFIT.CAT, SALE.LOSS.CAT are related to the sale which can
be at premium or discount in products which tracks delivery.
SALE.PL.TXN refers to the Transaction ID defined in the TRANSACTION table. If
TRACK.DELIVERY is set as YES, these fields are mandatory inputs by user.
DISBURSE FT Type refers to the FT.TXN.TYPE.CONDITION in Construction finance for
supplier payments.
Repay FT Type is for payments to AA Finance for reducing the commitment amount.
These fields are related to disbursements handled through IS.DISBURSEMENT
application.

R18 22
 The Broker categories and Transaction codes specified
are used in Treasury Islamic products to cater to Broker
payment accounting.
The Review related categories, Transaction codes and Transaction type is related to
the reviewer functionality. Reviewer functionality covers Appraiser, Surveyor
management and accounting.

R18 23
 IS.STATUS application defines the accounting rules for each of the workflow status
defined in EB.LOOKUP. The accounting entries gets generated based on the flag
specified against each Accounting Status. Accounting Entries for each of the
Accounting status is pre-defined.
Eg. If PURCHASE Status accounting entries are flagged as yes for Reverse Approval,
Purchase and Cost entries in the IS.STATUS. This means accounting entries will be
generated for Asset Purchase, Pre approval reversal and Cost.
User defined status can be specified and the related accounting entry can be selected
. Accounting entries for Approval, Reverse Approval, Purchase and Cost are hard
coded in the system.

R18 24
 Listed here are the accounting entries at Approval, Reverse Approval, Purchase and
cost stages.

R18 25
 IS.COMMODITY defines the details of the asset or commodity
ASSET.TYPE is a mandatory input field that is used to specify the type of commodity. It
can have two values, NAMED or QUANTIFIED. Examples of Named Assets are Vehicle,
Machinery, Buildings, real estate, Machinery etc. and Quantified Assets are natural
ores, Iron, Tin, Agricultural produce or any other commodity that is quantifiable.
Templates for capturing Named assets can be designed using EB.TABLE.DEFINITION
with product as IS.
The status of an Asset is defined in the field STATUS. The value to this field is defined
in the EB.LOOKUP table with prefix IS.STATUS.

R18 26
 Clients are free to define the necessary Status which is a mandatory selection field for
this table. Options available are active and inactive.
The warehouse address or the address in which the commodity is present can be
captured in LOCATION field.
Units are defined in the EB.LOOKUP table with prefix IS.UNIT. This field is specific for
quantified assets which defines the units eg. Kg, Ounces, Tons etc.
ASSET.TABLE is a mandatory field to be specified for Named assets along with the
asset prefix.
BUY.BROKER and SELL.BROKER are related to Treasury modules which deals with
Broker accounting for Purchase and sale of commodities. The Broker customer IDs
are defined in the table IS.BROKER.
ALLOWED.UNIT and DECIMAL.QTY are related set of fields which defines the units
and the decimals places allowed in a deal for the commodity/asset.

ALLOWED.UNIT and DECIMAL.QTY are related set of fields which defines the units
and the decimals places allowed in a contract for that commodity/asset.

R18 27
 Named Assets are defined in EB.TABLE.DEFINITION where the asset related static
fields are defined. Some of the available assets in model bank are Vehicle, Equipment,
Realestate, Miscellaneous Asset (Miscasset), Movequipment.
Additional Named Assets can be defined by clients from EB.TABLE.DEFINITION.
The fields CUSTOMER ID, CURRENCY, VENDOR ID, UNIT.PRICE and ASSET.DESCRIPTION
are mandatory. Static fields can be added.

R18 28
 Once the EB.TABLE.DEFINITION is created for the asset, the corresponding IS asset
table can be defined.
PURCHASE.REF is updated by the system with the Purchase ID upon authorisation of
the Purchase transaction for the asset.
Eg. IS.VEHICLE is the application to capture the asset details for vehicle.

R18 29
 Reviewer refers to Appraiser, Project Cost Evaluator, Project Auditor, Advisor, Legal
Consultant and all those who are involved in the project and who service for a fee.
Different types of Reviewers can be user maintained in EB.LOOKUP with prefix
REVIEW.
Existing Customer ID is the ID of the reviewer table. The Customised Reviewer name
is specified in the field NAME. The STATUS of the reviewer is user defined in
EB.LOOKUP with Prefix IS.REVIEWER.STATUS.
The fee settlement account can be maintained in the field ACCOUNT which can be
specified for a COMPANY and CURRENCY. BENEFICIARY details are
given in case of settlement to a Nostro account. Specific comments about the
Reviewer is maintained in the field COMMENTS.

R18 30
 IS.VENDOR table captures the Vendor details. All payments in Islamic requires
creating a Vendor ID which is mandatory at Asset Request stage.
STATUS of a vendor can be specified and is User maintained.
COMPANY and the related sub value fields CURRENCY , ACCOUNT can be maintained .
BENEFICIARY details can be maintained for Nostro accounts.

R18 31
 IS.BROKER application is used to capture the broker details. Broker accounting and
functionalities are specific to Islamic Treasury operations.
ID for IS.BROKER is a valid T24 CUSTOMER ID and Customer record must be created
prior to defining the customer as Broker.

The status of the Broker is Active or Inactive and needs to be defined mandatorily.
The values in this field is defined in EB.LOOKUP table with prefix IS.STATUS.

COMPANY refers to the company to which the broker Customer ID belongs to. The
Currency, Broker Account and Beneficiary (In case of Nostro account) forms a sub
value set of fields under each Company. The WASH.CATEG is the Broker Wash
Account category.
OPERATION refers to the type of operation a Broker could perform. A broker can
operate as a Buy or a Sell broker. In case the broker operates for
both Buy and sell commodities, BOTH can be selected.

R18 32
 User defined tasks and actions can be defined in the
table IS.CONTRACT.TASK which is tracked during Asset
Purchase as check list. The tasks can be either generic
type or Verification type of tasks. The ID of the table can
be any text in Alphanumeric format.
IS.COST.TYPE table defines the various costs incurred during purchase of an asset. All
the possible additional cost incurred during the process of purchase is defined in this
table.

R18 33
 STATUS of the Cost type can be active or Inactive. User defined STATUS can be
specified in EB.LOOKUP table with Prefix IS.STATUS.
Cost can be paid to the cost counter party by the bank or the client or added to the
finance amount. Defined in IS.COST.TYPE where FT.CHARGE.TYPE or
FT.COMMISSION.TYPE can be specified for defaulting additional cost during purchase
and can be modified if required.
In the field CHARGE.CODE either an FT.CHARGE.TYPE or FT.COMMISSION.TYPE can be
specified in order to default the charge amount for the cost in the Purchase contract.

R18 34
 IS.CONTRACT is the main application to create Islamic Contracts. The entire workflow
of the product with different statuses are captured here.
The functionality supports capturing the Asset definition reference and defaulting
values to the relevant fields.
The user can input the quantity of the asset for purchase along with customer
settlement account. It also supports definition of Down payment and capturing cost
related information. Accounting entries are generated based on the workflow status.
Customer of the contract can be chosen from the dropdown and Product refers to the
Islamic product maintained in IS.PARAMETER.

R18 35
 STATUS set up in the IS.PARAMETER gets defaulted based on the product selected.
NEXT.STATUS defines the next status of the contract as defined in IS.PARAMETER
Status.Value.Date is the date on which the STATUS is effective.
CURRENCY of the contract can be specified.
STATUS date of the previous STATUS is maintained in the field PREV.STATUS.DATE.
VALUE.DATE refers to date of the purchase contract, which defaults to system date.
This date cannot be future dated.

R18 36
 There are two types of assets : Named Assets and Quantifiable assets. COMMODITY
field can be multi valued. It is possible to link more than a commodity in the
IS.CONTRACT application.
Vendor account gets defaulted when Vendor ID is specified.
Commodity UNITS, UNIT.PRICE and QUANTITY can be defined for each Commodity
selected.
For named commodity, it is not required to specify the units of measurement.
Purchase Price is calculated using the formula, Purchase Price = Purchase Quantity *
Unit Price

R18 37
 The TOTAL.PURCHASE.PRICE is calculated as the sum of purchase price of all the
commodities / assets.
The fields NO.OF.UNITS and UNIT.VALUE are related to Diminishing Musharaka where
the system captures the unit details of the Asset finance and calculates the
Diminishing value of the Musharaka.
Customer Account relates to the Account pertaining to the customer for settlement
purpose.
VENDOR.WASH.ACCOUNT is an internal account parameterised to which the
Purchase accounting credits the proceeds for vendor payment processing. The
Internal account created by using the category set up in IS.PARAMETER > MULTI
SUPPLIER category is the category used as Vendor wash account.
WAKALA.REF is applicable for the product Wakala Musawama, a structured product.
The AA Wakala reference is captured in this field.

R18 38
 Down payment can be defined either at the commodity level or at the Asset
Reference level, it is captured in the fields DP.COMMODITY and DP.ASSET.REF.
Down payment can be specified as a Percentage of the Individual asset or commodity
– DP.PERCENT or DP.VALUE in case of Down payment amount specified.
DP.CONTRIB.PAYTO specifies whether the Down payment is paid to the Supplier or to
the bank. In case of payment to supplier, it reduces the amount from the final finance
amount. However if the payment is to the bank, the payment is accounted in the
Purchase accounting by debit to the customer account.
DP.CONTRIB.TYPE refers to whether the Customer contribution is made as Cash or
Asset. For Asset type of contribution system does not generate accounting entries
Down payment related information can be captured in the “Down payment details”
tab. Down payment is input as Percentage or Amount. If down payment is input as
Percentage the down payment amount can be calculated as, Down payment =
Purchase price * Down payment percentage / 100

R18 39
 The customer and bank contribution percentage is calculated by using the below
formula,
Customer contribution = Down payment %
Bank contribution = 100 – Customer contribution
Customer contribution to the contract can be “Cash” or “Asset”. Also customer
contribution can be paid directly to the “Supplier” or it can be paid to the “Bank”.
If customer contribution is set as “Cash” and down payment paid to is set as “Bank”
then it can be collected by using the down payment screen.
If customer contribution is set as “Asset” and paid directly to the “Supplier” or
“Bank”, Customer contribution is set as “Cash” and paid directly to the “Supplier”
then sum of these amounts are subtracted from finance amount during Asset sale.
System generates accounting entries only for ‘Cash’ type of contribution to ‘Bank’.

R18 40
 Payment to cost counterparty is defined in the field COST.PAY.TYPE which supports
three types: Contract, Vendor & Finance.
CONTRACT : The cost counter party maintains an account with the T24 bank and the
amount is credited upon authorisation of Purchase.
VENDOR : Cost payment from purchase is credited to an Internal account and is
paid to cost counterparty.
FINANCE : The additional cost gets added to the Total Finance Amount and is paid
to Cost Counterparty.

R18 41
 Check lists for the deal is maintained in IS.CONTRACT.TASK.
ACTION.CODE displays the Action tasks maintained in IS.CONTRACT.TASK.
The fields ACTION.COMPLETED and ACTION.SUCCESS can be marked as Yes or No
based on the successful completion of the action.

R18 42
 IS.ASSET.REVIEW captures the review particulars of the asset and asset inspection
related information like Date of Review, result of review, project status etc. It is
possible to specify a Fee for the service rendered. Bank and Customer contribution of
the fee amount can be captured and accounted.
For example the total fee of USD 1000 can be split as Bank Payment USD 800 and
Customer payment USD 200. Validation is built to ensure that the total fee sums
up to customer and banks contribution. The Review fee is credited to an Internal
account parameterised and paid to the Reviewer.
The PROJECT.STATUS can be captured as well as the NEXT.DATE of review

R18 43
 IS.PAYMENT is an application that handles the functionality which cover payments to
the Vendor/Supplier, Cost Counterparty, Reviewer, Retention amount, Broker etc.
The payments can be made on Adhoc or Scheduled basis. Multiple purchase
transactions of a vendor can be grouped and paid either as ad hoc payment or
scheduled. A portion of the amount paid to the vendor can be retained in Retention
account and paid at a later date.
PAYMENT.TYPE field specifies the type of counterparty for payment like Broker, Cost,
Down Payment, Retention, Review, Vendor.
The field OPERATION refers to whether the transaction is a new payment or reversal
of a payment done already.

R18 44
 Payment types :

Vendor – It is used to make payment to the Vendor by

using both “Adhoc” and “Schedule”
Cost – It is used to make payment to the Cost
counterparty by using both “Adhoc” and “Schedule”
Review – It is used to make payment to the reviewer by
using “Adhoc” payment method.
Down payment – This is for future purpose
Retention – It is used to pay the retention amount to the
Client/ PL which is retained during payment to the
Vendor.

R18 45
 Broker – It is used to pay broker payment to Buy broker/
Sell broker. The accounting entries are generated for
broker payment from Broker wash account on the bill
date and payment balance file gets updated.
PAYMENT.CURRENCY is the currency in which the payment is to be done based on the
Vendor/ Cost Account Currency or Nostro.
The VALUE.DATE defines the value date of the payment.
Payment methods can be Adhoc, DD, Cash, Schedule.

R18 46
 Payment methods can be Adhoc, DD, Cash, Schedule.

ADHOC – This option is used to make immediate payment to the vendor account. The
adhoc payment can be done multiple times as required. The value date cannot be
future dated.

DD – This option is used for updating necessary balance files – IS.PAYMENT.BALANCES

when making a payment through an external application like FUNDS.TRANSFER. The
payment reference made through cash TT and DD (FT) is updated in the field
PARENT.REFERENCE.

CASH - This option is used for updating necessary balance files –

IS.PAYMENT.BALANCES when making a payment through an external application like
TELLER. The payment reference made through cash TT and DD (FT) is updated in the
field PARENT.REFERENCE.

SCHEDULE – This option is used for scheduling payment on future dates. The payment
will be processed on the scheduled date using the IS.SOD.PAYMENT.SCHEDULE.
Payments scheduled is recorded in the live file IS.AUTO.PAY.SCHEDULES.

R18 47
 RETENTION.AMT and RETENTION.PCT refers to the amount or percentage of
retention amount to be held back before making a vendor payment.
RETENTION.ACCT is the account to which the retention amount is credited which is to
be manually paid later on.
PAYMENT.AMT is the Amount that is actually paid to the Vendor from the specified
BILL.AMT as on the date given in the field BILL.DATE.

For every asset purchase, the fields ASSET.REF, COST.REF, PAYMENT.REF can be
updated.

ASSET.REF : This field is mandatorily updated with the asset reference while making a
vendor payment.

COST.REF : This field is mandatory for cost payment, where the cost type captured
during purchase is updated.

PAYMENT.REF : If an IS.PAYMENT is to be reversed, the details of the payment

reference is updated here.

R18 48
 IS.DISBURSEMENT application is used to do the disbursement from an arrangement
to Vendor/ Multi supplier account during the construction phase

Contribution type can be “Cash” or “Asset”. Also contribution can be paid directly to
the “Supplier” or it can be paid to the “Bank”.
-If contribution type is set as “Cash” and contribution paid to is set as “Bank”, the
down payment amount specified in IS.DISBURSEMENT will be paid into AA account as
re payment.
-If contribution type is set as “Asset” and paid directly to the “Supplier” or “Bank” and
if contribution type is set as “Cash” and paid directly to the “Supplier”, the Down
payment will decrease the AA Commitment.

R18 49
 Upon authorisation, the amount in the field BILL.AMOUNT is used for making the
disbursement from arrangement.
Amount calculated as Cash contribution in the field CASH.CONTRIB is used for making
repayment to arrangement.
Amount calculated as commitment decrease in the field COMMIT.DECR.AMT is used
for doing Commitment decrease in the arrangement.

R18 50
 IS.COMMODITY.SALE is used for selling the delivered commodities to clients either
partially or fully.
The asset held by the bank can be sold to different customers, hence the commodity
sale details are captured before the actual sale of asset.
While financing in AA, this commodity sale reference is chosen.
Customer Id will be the customer to whom the asset is to be sold
Details such as purchase reference, currency, sale unit price & sale quantity are to be
input.
Based on the Purchase price & sale price, net profit/loss amount is accounted by the
system.

R18 51
 As per workshop, view the specific parameter tables related to Islamic banking

R18 52
 Listed here are the System Maintained Tables.

R18 53
 Listed here are the System Maintained Tables.

R18 54
R18 55
R18 56
R18 57