R18 1

R18 3
R18 4
 In this learning unit, we will understand the Murabaha product and the workflow
involved along with the amendments to Murabaha product.

R18 5
 Murabaha is the most popular and most common mode of Islamic Financing. It is also
known as Mark up or Cost plus financing. The word Murabaha is derived from the
Arabic word 'Ribh' that means profit.
Murabaha is a “cost-plus sale” finance in which parties bargain on the margin of
profit over the known cost price.
The seller has to reveal the cost-incurred by him for acquisition of the goods and
provide all cost-related information to the buyer. Repayments are paid usually in
instalments is specified in the contract.
The seller is obliged to tell the buyer his cost price and the profit he is making.
The price, once fixed as per agreement it cannot be further increased.
In case of default in repayment of the finance, any penalty charged to the client is
taken to charity rather than to the bank’s PL account.

R18 6
 The prospective seller in Murabaha is required to disclose all aspects relating to the
commodity any defects or additional benefits and the mode of payment to the
original seller/supplier.
Goods to be traded should be real, but not necessarily tangible. Rights and royalties
are examples of non-tangibles that can be traded through Murabaha, as they have
value, are owned and can be sold on credit.
Murabaha Finance revolves around the purchase of an asset by the bank and the
onward sale of the same by the bank to the customer. The Bank makes a profit on the
transaction, which is the difference between the price, which it pays to the supplier
of the goods and the price at which it sells the commodity to the customer. This
Mark-up will be agreed between Bank and the customer in advance.

R18 7
 Murabaha work flow:

The Customer and the Bank sign Master Financing Agreement along with Agency
Agreement.

Agency agreement is required if Bank appoints customer as an agent.

Customer identifies the asset to be purchased and finalizes a purchase deal for a
particular asset with a supplier

Customer makes a request to the bank for the purchase of the identified Asset.

The bank then purchases the asset and sells to the customer at cost plus.
The customer makes payment for the asset either in instalments or bullet based on
agreement between them

R18 8
R18 9
 The parameter tables like IS.PARAMETER, IS.STATUS, IS.COMMODITY and Asset tables
are to be set up mandatorily prior to entering a Murabaha contract.

In addition AA related Product Conditions are to be set up. AA Islamic products are
defined under the LENDING Product Line which should be publishe before

referencing in IS.PARAMETER.

R18 10
 In IS.PARAMTER, for Murabaha, the finance product is selected as MURABAHA.FIN in
the field Finance Product.

FIN.ELIG.STATUS is ‘Purchase’

Each of the work flow statuses for the products can be defined in EB.LOOKUP. In
Murabaha the process work flow is defined as Request, Approval and Purchase.Other
fields in IS.PARAMETER are discussed in the Work flow document.

R18 11
 In IS.STATUS, the workflow of Murabaha product is set with Request, Approval and
Purchase statuses.
This table defines the accounting entry at each status.
In case of Murabaha; Request stage will not raise any accounting. Approval stage will
raise approval accounting entries and during Purchase stage, the approval entries are
reversed and purchase entries are posted.

R18 12
 IS.COMMODITY is a common table which captures the Quantified assets/commodity
details to be used across various products.

Named Asset details are captured using EB.TABLE.DEFINITION which can be used
across various products.

Other tables like IS.VENDOR is mandatory while IS.REVIEWER,

IS.BROKER table is used for Retail commodity Murabaha product.

R18 13
R18 14
 The 1st step to buy and sell asset is to capture the details of the asset.
EB.TABLE.DEFINITION table is used to define Named Assets, where the fields like
customer, currency, vendor, units price, asset description are mandatory input. Static
Information is captured if needed.

Possible to amend the details from the Version : Amend – Asset Capture details

R18 15
 After authorisation of asset capture, amendment to Asset Capture is allowed till the
IS.CONTRACT stage where Asset Request is input and authorized as the first stage.

Once the Asset request is authorised, it is not possible to amend the asset capture
details. However if the asset request is reversed system allows to amend the asset
capture details.

It should be noted that the decision on the type of finance product is taken at the
IS.CONTRACT stage. During asset capture stage only the details of the named assets
like Car, Machinery, real estate are recorded.

For Quantified Assets, the commodity details can be directly captured during the
‘Asset Request stage

R18 16
 In case of quantified assets (eg. Iron, Platinum, agricultural produce etc.) the asset
details can be given directly during the ‘Asset Request stage’ where the commodity
can be chosen from the dropdown. This is captured in IS.CONTRACT.
For quantified asset, the commodity details, with Units, unit price , quantity ,
customer, currency, vendor , asset description can be input here.

R18 17
R18 18
 Asset Request stage captures the details of the finance product or links the asset
captured earlier with a particular finance product with details of Customer, down
payment, cost etc. In Asset request stage, details like currency of the asset, deal date,
purchase quantity , value date, customer account are captured. For Named asset,
Asset reference field to be chosen from the dropdown.
In case of quantified asset, the commodity details, with Units, unit price , quantity
can be mentioned here directly.

R18 19
 Along with the asset details, the details of down payment , additional costs and
action tasks can also be captured in this stage.
No accounting entries are generated at is stage. Also the status field is updated to
“Request”.

R18 20
 The Work flow for Murabaha product is defined in IS.PARAMETER.
The flow is : Request  Approval  Purchase.
COS.IS.CONTRACT.AMEND – summarizes and guides the user to complete the
Murabaha process before doing the financing.
The version ‘Workflow Change/Modification of contract’ can be used to view the
previous, current and next statuses.
Allows to do next action / Amend the contract / Reverse Contract.

R18 21
R18 22
 Once the asset request is authorised, the next stage is approval. At approval stage, an
agreement is entered between
the bank and the client which promises the purchase of asset.
System allows the user to modify the details like status value date, asset description,
down payment , cost, action tasks, customer account if needed.
The status field is updated to ‘Approval’ .

R18 23
 Once the Approval is authorised, system generates accounting entries (based on the
set up in IS.STATUS)

R18 24
R18 25
 The next stage is the Purchase of asset by the bank where the asset is brought into
the bank’s books of account.
System allows the user to modify the details of down payment , cost, action tasks,
customer account, status value date, asset description if needed.
At this stage, the ‘Status’ field is updated as ‘Purchase’.

R18 26
 Approval Accounting gets reversed and Purchase accounting entries are raised.

R18 27
R18 28
 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 or as a fixed amount in fields
DP.PERCENT and DP.VALUE respectively.
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.
DP.CONTRIB.TYPE refers to whether the Customer contribution is made as Cash or
Asset. System generates accounting entries only for ‘Cash’ type of contribution to
‘Bank’. This amount is held in an Internal account as per category defined in
IS.PARAMETER.

R18 29
 Down payment can also be partially paid. Booking of Sale in AA is possible only after
full Down payment is paid by the customer.
Accounting entries are generated upon authorisation of down payment.

R18 30
 In the above screenshot, all possible types of down payments are shown.
When the asset value is USD100,000 and down payment is USD40,000 (amount) or
40% (percentage), then customer contribution in total is USD40,000 and the bank
contribution is USD60,000 .
Out of the four types, Accounting entries are generated only for ‘Cash’ type of
contribution towards ‘Bank’.
In this case once the down payment of USD10,000 marked in the above slide is paid
by customer to bank, this amount is added to bank contribution to make a vendor
payment. Hence vendor payment of USD70,000 is to be made.

R18 31
 Down payment can be partially paid. Booking of Sale in AA is possible only if down
payment is made in full.
In the above example (continuation of the previous page), down payment is to be
done for USD10,000.
This screenshot shows that partial down payment of USD 3000 being made and the
accounting entry.
Sale can be processed only upon the balance USD7000 being paid.

R18 32
R18 33
 Payment to vendor can be made on a Adhoc or scheduled basis which is processed in
IS.PAYMENT table.
Adhoc is used whenever any immediate payment is to be made and Scheduled is
where the payment to vendor has to be in installments at specified dates, then the
payment can be scheduled accordingly. Vendor payments can be processed via Funds
transfer or Teller.
The Retention percentage or amount specified here will be withheld in an internal
account (category for this is defined in RETENTION.CAT field of the IS.PARAMETER)
which can be paid any time later.

R18 34
 Accounting entries are generated upon payment’s being authorised.
When retention amount is paid, the retention account is debited and vendor account
is credited. In some cases, the bank would not be willing to pay the entire retained
amount to the vendor , in which case PL account is credited.

R18 35
 Look at the Adhoc payment to vendor through IS.PAYMENT.
When a vendor payment is input through IS.PAYMENT, system automatically
generates an FT by debiting the multi-supplier account and crediting the vendor
account.

R18 36
 Look at the scheduled payment to vendor via IS.PAYMENT
There are 2 payments scheduled here, 1st is on 22 Apr, 2nd payment on 25 Apr.
The payments will happen on scheduled day’s COB.

R18 37
 This slide details the vendor payment through funds transfer application with
accounting entries.

R18 38
R18 39
 Cost to counterparty is related to the costs incurred during the purchase of a
contract. Cost payment can be made on a Adhoc basis or scheduled basis.
Cost payment can be paid by 3 types: Contract/Finance/Vendor.
Except for "Contract" option, the cost amount has to be paid to the counterparty
using "Cost Payment - Adhoc or Scheduled" options.

R18 40
 The 3 types of Cost defined at the contract input stage.

1. Contract: The cost payment when mentioned as Contract will be paid during the
contract stage itself (Upon authorisation, accounting entries are raised as per
parameter set up for Cost in IS.STATUS ). Depending on the agreement, Cost can
be by paid customer or bank. If cost is paid by bank, the expenses account is
debited.

2. Finance: When cost is defined of Finance type, then this cost is added to the
finance amount (eg. if the finance amount after down payment was originally
USD60,000. After this cost being defined, the finance amount during sale will be
USD60,500) . This cost is thus collected from customer in the finance stage. Hence
an adhoc/scheduled cost payment can be to be made to cost counterparty by
debiting the Multisupplier account.

3. Vendor : If cost payment is by vendor, separate cost payment to vendor is to be

R18 41
 Cost payments can be paid in fully or partially.
Cost can be paid by adhoc basis where payment date will be current date of process.
Upon authorisation, account entries are generated.

R18 42
 This slide provides details of a scheduled cost payment.
There are 2 payments scheduled here, 1st is on 22 Apr, 2nd payment on 25 Apr.
The payments will happen on scheduled day’s COB.

R18 43
R18 44
 Retention amount can be specified in IS.PAYMENT . This amount can either be paid at
a later date to the vendor or taken to the PL.
Retention percentage or amount specified will be withheld in an internal account
(category for this is defined in RETENTION.CAT field of the IS.PARAMETER) which can
be paid to the vendor any time later.

R18 45
 Look at the screenshots of a retention payment with account entries.

Accounting entries are generated at the time of authorisation.

R18 46
R18 47
 Asset Review captures details of the reviewer (appraiser), reviewer's account number,
review date, valuation fees.

Valuation fees can be shared by customer and bank - Customer share and bank’s
shares are specified.

Upon authorisation, customer’s account is debited for his share and bank’s PL is
debited for bank’s share and credited to the Reviewer Wash Account defined in the
IS.PARAMETER

Reviewer payment debits the wash account and credits the fees to the reviewer’s
account.

R18 48
 This slide details the steps to input a Asset review.

R18 49
 The next step is making payment to the reviewer. Look at the steps to create a review
payment.

R18 50
 Look at the account entries. The valuation fees defined was USD1000, in which
USD400 was customer’s share and USD600 was bank’s share.
Hence we can see the account of customer and PL of bank are debited and both are
credited to the Reviewer wash account.
Once the payment is authorized, the wash account is debited for USD1000 and the
reviewer account is credited with same.

R18 51
R18 52
 Once the asset is purchased by the bank, the next step is to sell the asset to the
customer.
This sale to customer is processed in AA.
The details like date, customer , currency, IS.Product and IS.CONTRACT.REF are
captured initially.

R18 53
 Details such as commitment amount, term or maturity date, Profit amount or
percentage are defined here for the sale.

R18 54
 Penalty profit is charged to customer in case of Overdue’s. The penalties charged to
client can be posted to an internal account which any time later can be provided for
charity by banks. This is achieved by flagging the field Non-Sharia flag.

Bonus option is available for banks to pay a bonus amount to customer whenever
customer does a Early closure of the finance.
For this a Bonus percentage can be set which calculates the bonus for the unaccrued
profit.

Payment schedules and settlement instructions are defined here.

R18 55
 In this workshop, we will open a Murabaha contract with the details as per slide.

R18 56
R18 57
 Asset details are captured here. Customer, currency, vendor, unit price and asset
description are mandatory inputs.
Other asset specific details can be additional given.

R18 58
 Look at the slide to authorise asset capture.

R18 59
 Next step is asset request.

R18 60
 In the asset request, the units, unit price, customer account are be given.
The next status to the current workflow is defaulted in the field Next.Status (as per
the set up in IS.PARAMETER)

R18 61
 The down payment here is USD20,000 (customer contribution) . Out of this
USD10,000 is of Cash contribution to Bank and
other USD10,000 is of asset contribution to Bank.
Hence the bank contribution here is USD80,000.

The cost defined here is USD1,500 and the cost payment type is contract (hence will
be paid to cost counterparty at Purchase stage)
As per workshop, cost is paid by bank so we are debiting the expenses account.

R18 62
 Look at the steps to authorise asset request.

R18 63
 Upon authorisation of the asset request ,the current status now shows ‘Request’.
The next status shows as ‘Approval’. Using the next action button above, the approval
status details are input.

R18 64
 Follow the steps to authorise asset approval.

R18 65
 The next status is Purchase. Upon authorisation Purchase accounting entries are
raised.
(Accounting entries are shown in a separate slide after the Sale)

R18 66
 Follow the steps to authorise asset purchase.

R18 67
 Down payment is done, for customer’s cash contribution to bank for which
accounting entries are raised.
This down payment is debited from customer and credited to an Internal account as
defined in IS.PARAMETER.

R18 68
 Follow the steps to authorise the Down payment.

R18 69
 Payment to vendor is made for the purchase of asset. The above shown is a Adhoc
payment done to vendor.

R18 70
 Look the steps to authorise the Vendor payment created.

R18 71
 Sale of asset to customer is done in AA. The following slides explain the navigation in
AA.

R18 72
 Commitment amount is defaulted by the system, other details like maturity date or
term needs to input here.
The profit percentage or amount is also to be specified. System shows the AA account
number created under Account tab.

R18 73
 Penalty profit and bonus can be defined here.
As per workshop, a constant schedule is defined here. Settlement instructions can be
updated.

R18 74
 Follow the slides to authorise AA Sale.

R18 75
R18 76
R18 77
 Look at the Payment schedule and accounting entries of Purchase and Cost.

R18 78
 Look at the Accounting entries of Down Payment and Vendor Payment.

R18 79
 Look at the Accounting entries for Sale.

R18 80
R18 81
 Considering the same finance amount (USD80,000), same profit rate (5%) with
different maturity dates, let us discuss the different types of Repayment Schedules
that can be set for a AA Murabaha Sale.

In a constant schedule, the total amount due is the same throughout the finance
tenor and is based on Equated Periodic Installment payments.

R18 82
 Linear Schedule where the total due varies. Profit calculation is based on
Principal repayment schedule.
Number of installments for principal repayment can be captured in the schedule tab
using Linear payment type. For Profit, Payment type ‘Profit.Only’ can be chosen by
which profit is calculated based on the profit rate given. Both principal and profit can
be collected in installments by defining the frequency.

R18 83
 Profit Only plus Constant where Initial repayments is only Profit payments
and later on Constant payments are scheduled.
Repayment of profit amount for certain period of the contract and then pay the
equated installment amount to settle the outstanding can be achieved through this
payment schedule . For this 1st ‘Profit.Only’ payment type is to be defined with the
no. of installments and then ‘Constant’ payment type to be defined for the following
equated installments.

R18 84
 Special plus Profit.Only:
Special repayment type can be used to manually specify the installments for the
Principal amount. For profit, ‘Profit.Only’ payment type can be used with frequency
by which the Profit is collected in installments.

R18 85
 Constant plus Balloon type where Balloon payments are defined in between
the constant repayment schedule.
Equated instalment amount with balloon payment in between. Balloon payment
dates and amount can be captured in the schedule tab with payment type as ‘Special’.
Equated instalment amount is calculated for the finance amount based upon the
term, repayment frequency, balloon payment amount profit rate.

R18 86
R18 87
 Once the Sale is authorised, upfront accounting entries are raised for the profit
amount.
This profit amount is amortized during COB as per frequency set in
AA.ACCRUAL.FREQUENCY.

R18 88
 Lets take an example of a Sale, where the commitment amount is USD60,500 .
1st screenshot is the accounting entries raised on authorisation of the sale, the profit
amount calculated is USD773.06
2nd screenshot gives the details of the amortized deferred profit.

R18 89
 AA.INTEREST.ACCRUALS table gives the details of the amortized amount with number
of days and dates (refer screenshot) .
Other 2 screenshots shows the movement of profit amount being amoritised to PL.

R18 90
R18 91
 Murabaha contract can be reversed at Request, Approval or Purchase stages.
Accounting entries thus generated are reversed during reversal of contract.

R18 92
 The screenshots show reversal at Request status. In case of named assets, the asset
already captured can be used for additional purchase if needed.
Note : Request status has no accounting entry.

R18 93
 Once request is authorised, the next status is ‘Approval’.
Upon authorisation of approval, accounting entries are generated (shown above) .

R18 94
 The current status is ‘Approval’. When Approval is reversed, system reverses both
approval and request.
Accounting entries are reversed upon authorisation of reversal.

R18 95
 Once request and approval are authorised, the next status is ‘Purchase’
Upon authorisation of approval and Purchase , accounting entries are generated
(shown here) .

R18 96
 The current status is ‘Purchase’. When Purchase is reversed, system reverses
Purchase, approval and request.
Accounting entries are reversed upon authorisation of reversal.

R18 97
 When a purchase is done with down payment as shown above, reversal of purchase
will reverse the accounting entries of Purchase and approval.

R18 98
 Purchase can be reversed even before creating an FT for down payment, system
reverses the accounting entries of both Purchase and approval.

R18 99
 If down payment is specified, the purchase transaction and the down payment are to
be individually reversed.
Purchase reversal will reverse accounting entries of Purchase and Approval.

R18 100
 FT reversal will reverse accounting entries raised by FT for down payment.

R18 101
 When a purchase is done with cost payment as shown above, reversal of purchase
will reverse the accounting entries of Purchase and approval including the costs
payments.

R18 102
 Reversal of Purchase with cost is shown here.

R18 103
R18 104
 Once a finance is given to customer, the customer may wish to pay the installments
earlier. In this case, a bonus payment is made to the customer based on bonus
percentage set during the Sale.
Request Payoff (marked here) is used for a AA Payoff i.e early closure.

R18 105
 When request Payoff is chosen, a payoff screen is populated to input the payoff date.
On committing this record, a simulation process starts for the same
(AA.SIMULATION.SERVICE to be started simultaneously).
The status of the service shows ‘processing’ when service is running and the status
changes to ‘Executed-Successfully’ – if service has run without errors.
Upon successful completion, the payoff statement can be viewed which will give the
details of Principal amount, profit and the bonus.
Hence the installment is to be paid for the net amount.

R18 106
 Next step is to process an FT/TT to pay the installment.
Shown above is the accounting entry upon authorisation.
Bonus percentage is defined in the arrangement. Based on the percentage define,
during early maturity system will calculate the bonus amount on the unaccrued profit
and debit the PL to credit arrangement. The customer shall pay net of bonus amount
to pre-closure the sale.

R18 107
 Once the FT payment has been processed and authorised, the arrangement status
has changed to Pending Closure which will be automatically closed during COB.

R18 108
R18 109
 Overdue of bill happens when the installments are not paid on scheduled dates.
System creates overdue when the customer account does not have sufficient funds
on the scheduled date.
Look at this sample of an arrangement which shows the overdue status as
‘Delinquent’ and the total overdue amount.

R18 110
 The bills tab will give the details of the overdue installments.
In the example above, there are two overdue bills.

R18 111
 Look at the overdue details for payment date 03Mar2016.

R18 112
 Look at the overdue details for payment date 03Apr2016.

R18 113
 Overdue bills can be settled by means of making a Funds transfer(FT) or through
Teller (TT).
FT/TT can be made for the full overdue amount or the same can be made in parts.

R18 114
 Once the FT/TT is authorised, the overdues are closed.

R18 115
R18 116
 Amendments to Sale/Finance can be done through: FT, TT or Change
activity in AA.

R18 117
 Important Note: The profit amount will
remain constant during amendments to the
Murabaha arrangement. The field profit
method (INTEREST.METHOD) should be
defined as Fixed in Interest property class for
Profit constant products.

R18 118
 In AA repayment, an adhoc payment is made by the customer to the bank.
In the case of Murabaha and other profit constant products, the total Profit amount
remains constant.
Shown in this slide is the screenshot of the AA Sale that is to be amended.

R18 119
 This amendment can be done either using an FT or TT as shown. With respect to
schedules the output will look the same for both FT and TT.

Using Funds Transfer (FT): Debit account is the customer’s current/saving account and
credit account is the AA account to which the amount is paid.
Currency, amount and value date details to be input here.

Using Teller (TT): Details like arrangement id, currency, amount, denomination and
value dates are to be input.

R18 120
 Look at the Payment schedule before and after amendment.

R18 121
 In AA principal decrease, an adhoc payment is made by the customer to the bank
In Murabaha and Profit Constant products, the Profit amount is kept constant.
Shown in this slide is the screenshot of the AA Sale that is to be amended.

R18 122
 In this slide, the amendment is done via Funds transfer (FT)
Details such as arrangement id, currency, amount paid, value dates are to be input.

R18 123
 Look at the Payment schedule before and after amendment.

R18 124
 AA Pay-off amendment will close the finance by paying off the outstanding finance
receivable. When doing a early closure, a bonus amount is paid to
the customer as per the bonus percentage defined during the Sale. Upon
authorisation, the status of the finance would state ‘Closed’ .
Shown in this slide is the screenshot of the AA Sale that is to be amended.

R18 125
 To know the payment amount, a simulation is run using ‘Request payoff’ option in the
AA overview screen.
When request Payoff is selected, a payoff screen is populated to input the payoff
date. On committing this record, a simulation process starts for the same
(AA.SIMULATION.SERVICE to be started simultaneously).
Upon successful completion, the payoff statement can be viewed which gives details
of amount to be paid with the bonus details.

R18 126
 This amendment can be done either using a FT or TT as shown. With respect to
schedules the output will look the same for both FT and TT.

Using FT: Debit account is the customer’s current/saving account and credit account
is the AA account that is to be done a early closure.
Currency, amount and value date details to be input here.
Payoff amount will be the Outstanding finance receivable minus bonus calculated.

R18 127
 Look at the Payment schedule before and after amendment.

R18 128
 In a ‘Change term’ amendment, the tenor of the finance can be reduced or extended
by performing a ‘Change Term’ amendment but the profit amount will remain
constant.
In Order to initiate this amendment, the New activity is to be chosen as shown in the
slide. Upon authorisation, the payments are amended and rescheduled
based on the term changed.

R18 129
 Lets take an example of an arrangement, where the original maturity date was 12th
April 2017.
In the amendment, the term has been curtailed to 02 Jan 2017.

R18 130
 Look at the Payment schedule before and after amendment.
You will notice that the installment amount has been altered accordingly.

R18 131
 In a ‘Change settlement instructions’ amendment, settlement accounts for
repayment, disbursement and other payouts can be amended.
In Order to initiate the amendment, New activity is to be chosen as shown here.

R18 132
 The screenshots show the details before and after amendment.

R18 133
 Schedules once defined can be amended by the Reschedule option.
Depending on the change in frequency, the payments are rescheduled accordingly
keeping the profit amount constant.

R18 134
 The original frequency defined was monthly. In this amendment the frequency of
payment is changed to once in 2 months.
Upon authorisation of the amendment, the installment amounts now vary based on
change in schedule.

R18 135
 Look at the payment schedule before and after amendment.

R18 136
 In the learning unit, we have learnt the Murabaha finance product, its workflow and
the amendments related to Murabaha.

R18 137
R18 138
R18 139