Islamic Finance Software: The Modules a Sharia-Compliant Platform Needs — Murabaha, Ijara, Sukuk, Takaful — and How to Build Them

Most searches for Islamic finance software end on a vendor page that lists products without explaining what makes them different in the code. This guide is the opposite: it walks through the modules a Sharia-compliant banking, financing, investment or insurance platform actually needs, what each one has to do that a conventional system does not, and how to decide what to build and what to buy. It is written for product owners, CIOs and engineering leads at Islamic banks, windows of conventional banks, fintechs and Takaful operators in the Gulf, Malaysia, South Asia and Europe.

One principle first. A Sharia-compliant platform is not a conventional core with the interest rate field hidden. Interest-based lending and Islamic financing differ in what the contract *is* — a sale, a lease, a partnership, an agency — and software that models the wrong thing will produce the wrong ledger entries, the wrong customer disclosures and the wrong audit trail no matter how it is labelled. The standards published by AAOIFI, the Bahrain-based Accounting and Auditing Organization for Islamic Financial Institutions, exist precisely because the accounting treatment follows the contract, not the cash flow.

The contract modules

Murabaha (cost-plus sale). The institution buys an asset the customer wants and sells it to the customer at a disclosed cost plus an agreed profit, paid in deferred instalments. As software: an asset-purchase step with evidence of ownership before the sale, a disclosed cost and markup captured at contract time and frozen thereafter, an instalment schedule whose total is the sale price rather than a principal accruing interest, and — the part that breaks conventional cores — no interest on late payment. Late-payment handling is a charity-donation flow under the institution's Sharia policy, not income. Commodity Murabaha (Tawarruq) adds a broker leg and a same-day sale that must be evidenced in order. Search Console shows product owners searching for "murabaha financing software" as a distinct need; this module is the reason.

Ijara (leasing). The institution owns the asset and leases it; ownership stays with the lessor throughout, which drives everything else — the asset register, maintenance and takaful obligations attached to ownership, rental schedules that may be fixed or benchmarked and revised at agreed points, and, for Ijara Muntahia Bittamleek, a transfer of ownership at the end through gift or sale. Ijara software is asset-lifecycle software with a rental engine, not a loan book.

Musharakah and Mudarabah (partnership). Capital contributed by partners (Musharakah) or by a capital provider to an entrepreneur-manager (Mudarabah), with profit shared by an agreed ratio and loss borne in proportion to capital. The module holds capital contributions, the profit-sharing ratio as a first-class contract term, periodic actual-profit calculation from the venture's accounts, and — for diminishing Musharakah, the common home-finance structure — a unit-purchase schedule through which the customer buys out the institution's share over time while paying rent on the share still held. Product owners searching for "musharakah origination software" are usually describing this diminishing structure.

Sukuk (certificates). Sukuk represent proportional ownership in an underlying asset pool or venture rather than a debt claim. Issuance software covers structuring (the asset pool, the special-purpose vehicle, the contract type the sukuk is built on — Ijara, Wakalah, Murabaha, hybrid), the register of holders, periodic distribution calculated from the underlying asset returns, event handling (purchase undertakings, dissolution), and reporting to the trustee, the Sharia board and the regulator. "Sukuk issuance management" queries reaching our site are a signal that issuers want workflow and registry tooling rather than spreadsheets; that is a well-defined build.

Takaful (cooperative insurance). Participants contribute to a fund that pays claims; the operator manages the fund for a fee (Wakalah), a share of investment profit (Mudarabah) or a hybrid, and any surplus belongs to participants. The engineering consequence is two separated ledgers — participants' risk fund and operator's shareholder fund — with the fee model, surplus calculation and distribution rules encoded as contract terms, plus Retakaful arrangements and claims handling that never blur the two funds. A conventional policy-admin system has one pool; Takaful has two, and the wall between them is the compliance.

Zakat. Calculation on eligible assets at the nisab threshold and the applicable rate, per the institution's Sharia policy and jurisdiction, with a distribution register. Small as a module, frequently requested, and a good first delivery because it touches customer data, Sharia rules and reporting in one bounded workflow.

The engines around the contracts

Profit distribution for investment accounts. Islamic banks fund themselves largely through investment accounts (unrestricted and restricted) rather than interest-bearing deposits, and account holders receive a share of actual profit from the pooled assets. The engine pools assets and funding, calculates period profit, applies the Mudarib share and the account holders' share, handles the reserves institutions use to smooth returns — the profit equalisation reserve and investment risk reserve — and produces the disclosures. It is the single most computationally sensitive module in an Islamic core, and questions about it can be raised years after the period in question, so every calculation needs its inputs and rules versioned and replayable.

Sharia governance workflow. New products, changes to existing products and unusual transactions go to the Sharia supervisory board; the platform should carry the submission, the approval, the conditions and the periodic Sharia audit as a workflow with an immutable trail, so the answer to "who approved this contract template, when and with what conditions" is a query rather than a search through email. Regulators in Bahrain, Malaysia and elsewhere have Sharia governance expectations that this trail serves directly.

Purification and non-compliant income. Income that fails Sharia screening — a late-payment penalty, a dividend from a screened-out portion of a holding — is separated and donated under the board's policy. That is a ledger rule and a reporting line, and it must be automatic.

Integration with conventional rails. Payments, cards, open-banking APIs, core-banking adapters and regulatory reporting are shared with the conventional world. The wall to keep is at the contract and ledger layer: an Islamic window inside a conventional bank can share channels and rails while keeping separate funds, separate accounting and separate governance.

Where conventional cores break

Institutions that try to run Islamic products on a conventional core by configuration hit the same walls. Interest fields that cannot be zero without breaking amortisation. Late-fee modules that book penalties as income. Deposit products that cannot express a profit-sharing ratio. Asset ownership that the system does not model because a loan book never owned anything. Reports that describe a sale as a loan. Each is fixable in isolation; together they are the reason product owners search for purpose-built Islamic banking software rather than a configuration guide.

Build, buy, or both

Buy the commodity: payment rails, card issuing, KYC and AML, document storage, general ledger if a Sharia-capable one fits. Build the contract modules, the profit-distribution engine and the Sharia governance workflow when the institution's product set, jurisdiction or Sharia board policies do not match a packaged system — which, in our experience, is most of the time for anything beyond plain-vanilla retail products. And build the integration layer regardless, because that is where an Islamic window meets its parent's systems.

Two rules keep this honest. First, Sharia approval belongs to the institution's board and its advisers; a vendor can build the system to the board's rulings and produce the evidence, but cannot certify compliance. Second, the platform must be able to explain any figure it produced — profit share, instalment, surplus — from stored inputs and stored rules, at any later date.

Where Masarrati fits

Masarrati builds Sharia-compliant fintech platforms for institutions in the Gulf and beyond — Murabaha, Ijara and diminishing Musharakah financing modules, Sukuk issuance and registry tooling, Takaful platforms with separated funds, Zakat tooling and profit-distribution engines — as custom software delivered into your environment with the audit trails your Sharia board and regulator expect. We build interest-free by firm principle: Masarrati does not build riba-based products of any kind. Where AI helps — document extraction for Murabaha asset evidence, assistants for customer questions about profit calculations — we add it as agentic automation with human sign-off retained. Sharia rulings and regulatory approvals remain with your board and advisers; we build the system that lets you demonstrate them. See also our earlier guide to Islamic fintech development and our work with institutions in Bahrain, home of AAOIFI and one of the deepest Islamic finance markets in the region.