Islamic Banking

Seven financing and deposit products in which the return comes from a real transaction or venture rather than from an announced interest rate. The platform stores each of them once and exposes them through two addresses — a secular one and a religious one.

This page is for platform operators. If you are integrating as a partner, the secular reading is documented in Participatory Finance.

---

One contract, two readings

Product	Religious reading (this page)	Secular reading
Musharaka	/api/v1/baas/islamic-banking/musharaka	Partnerships
Murabaha	/api/v1/baas/islamic-banking/murabaha	Instalment sales
Ijara	/api/v1/baas/islamic-banking/ijara	Leases
Mudaraba	/api/v1/baas/islamic-banking/mudaraba	Managed investments
Sukuk	/api/v1/baas/islamic-banking/sukuk	Certificate issues
Wadiah	/api/v1/baas/islamic-banking/wadiah	Safekeeping deposits
Mudaraba deposit	—	Investment deposits

The two readings share one storage layer and one set of arithmetic. The same table, the same schedules, the same ledger postings. What differs is the address, the contract-number prefix, and one rule.

The rule that differs

In the religious reading a review is mandatory. Funding is unreachable without a conclusion from the review board: a Murabaha, Mudaraba, Ijara or Sukuk that has not passed approve cannot advance to the transitions that move money. In the secular reading the review is optional — a contract may be funded straight from draft.

This is enforced in the model, not in the controller. There is no route through the API that funds a religious-reading contract without a conclusion.

Readings are isolated

A contract created in one reading is not visible or mutable through the other. Requesting a secular contract at a religious address returns 404, and the reverse is also true — the lookup filters by reading before it filters by identity.

This matters operationally: an operator who offers both cannot accidentally show a customer's secular partnership as though a review board had passed on it, and cannot mutate one through the other's transitions.

---

Access

Two conditions, both on the organization:

• Organization type must be bank. These are BaaS endpoints.
• The islamic_finance module must be activated. Without it every endpoint answers 403 with module_not_active.

The secular reading is gated separately, by the participatory_finance module. An operator may enable either, both, or neither.

Authorisation is admin or client — the religious endpoints are not open to partner credentials. Partners reach the secular reading only.

---

Endpoints

GET  /api/v1/baas/islamic-banking/stats
GET  /api/v1/baas/islamic-banking/regions
GET  /api/v1/baas/islamic-banking/screen
GET  /api/v1/baas/islamic-banking/{product_type}
POST /api/v1/baas/islamic-banking/{product_type}
GET  /api/v1/baas/islamic-banking/{product_type}/{id}
POST /api/v1/baas/islamic-banking/{product_type}/{id}/{action}

{product_type} is one of murabaha, mudaraba, musharaka, ijara, sukuk, wadiah. Anything else returns 400.

Portfolio counts

GET /api/v1/baas/islamic-banking/stats

{
  "data": {
    "products": [
      { "product_type": "murabaha", "count": 512 },
      { "product_type": "mudaraba", "count": 47 },
      { "product_type": "musharaka", "count": 18 },
      { "product_type": "ijara", "count": 203 },
      { "product_type": "sukuk", "count": 6 },
      { "product_type": "wadiah", "count": 1874 }
    ],
    "total": 2660
  }
}

These are counts of contracts, from a count query — not page sizes. A portfolio of five hundred Murabaha contracts reports five hundred.

Supported regions

GET /api/v1/baas/islamic-banking/regions

Returns the regions where these products are available, and separately those operating a dual-banking system, where conventional and participatory products run side by side under one regulator.

Screening

GET /api/v1/baas/islamic-banking/screen

Checks an asset or a transaction for compliance.

---

Response shape

The religious endpoints return the stored record with empty fields removed, plus product_type and organization_id:

{
  "data": {
    "id": "3b9c2f18-77a4-4e0d-8c15-6ad2f9e40b31",
    "product_type": "murabaha",
    "contract_number": "MRB-AE-20260823-4A7F1C",
    "status": "active",
    "purchase_price": 180000000,
    "markup_amount": 27000000,
    "sale_price": 207000000,
    "organization_id": "…",
    "inserted_at": "2026-08-23T09:14:22Z"
  }
}

Lists add a meta block:

{ "data": [ … ], "meta": { "total": 50, "product_type": "murabaha" } }

Two differences from the secular endpoints matter for integration:

• Amounts come back as integers, not strings. Minor units either way, but a large contract will lose precision if you parse the response with a JavaScript JSON.parse and treat the number as a number. Read it as BigInt or handle the raw text.
• Field names are the neutral column names — compliance_review, markup_rate, custody_type — because both readings write the same columns. Religious vocabulary lives in the contract documents and in the cabinet, not on the wire.

Pagination is page and per_page, defaulting to page 1 and 50 per page.

---

Actions

POST /api/v1/baas/islamic-banking/{product_type}/{id}/{action}

All parameters go in one flat body. What is accepted depends on the action.

Product	Actions
murabaha	approve, order_asset, purchase_asset, deliver_asset, activate, record_payment, record_delinquency
mudaraba	approve, reject, fund, activate, distribute_profit, record_loss, complete
ijara	approve, reject, acquire_asset, activate, record_rental, record_arrears, record_owner_expense, mark_transfer_pending, transfer_ownership, return_asset, terminate
sukuk	approve, reject, start_offering, subscribe, close_subscription, activate, distribute_profit, mature, redeem, redeem_early, default
musharaka	buyout_unit
wadiah	grant_hibah

An unknown action returns 422 with Unsupported action: {name}. A transition the state machine refuses — a second approve on an already-approved contract, for instance — returns 409.

Musharaka and Wadiah are thinner here

The religious reading of Musharaka exposes only buyout_unit, and Wadiah only grant_hibah. The other transitions of those two products — funding, activation, profit and loss for a partnership; deposits, withdrawals and blocking for a safekeeping account — are reachable through the secular endpoints and through the operator's cabinet, but not through this address family.

If you operate these two products under the religious reading and need their full lifecycle over the API, raise it with your platform contact rather than working around it.

The approval

POST /api/v1/baas/islamic-banking/murabaha/{id}/approve

{
  "approved_by": "Sharia Supervisory Board, resolution 2026/14",
  "fatwa_reference": "SSB-RES-2026-014"
}

Both approved_by and fatwa_reference are required and must be non-blank. Sukuk additionally accepts board_id, the identifier of the board that issued the conclusion.

The platform does not fabricate these. An approval submitted without a real reference is refused rather than filled in with a placeholder — the point of recording who approved and on what basis is defeated the moment the system invents an answer.

---

What the operator's cabinet shows

The personal cabinet for operators carries the religious reading of these products: the portfolio by product type, each contract's stage and money breakdown, and the transitions above. Approvals are entered there with the same two required fields.

The secular reading appears in the partner cabinet, where partners manage their own contracts.

---

Choosing what to offer

You want	Enable
Participatory products without religious framing	participatory_finance
Products under AAOIFI standards with board review	islamic_finance
Both, to the same customer base	Both — the readings do not interfere

Enabling both is the usual configuration in dual-banking jurisdictions. Because the readings are isolated, a customer's secular contract and another customer's religious contract of the same kind sit in the same table without either being visible from the other's address.