Islamic core banking & AAOIFI: a practical guide.

Roughly a quarter of the world's banking customers live in markets where Shariah-compliant finance is either the default or a fast-growing expectation. Yet most core banking platforms treat Islamic banking as an exotic add-on — a renamed interest field here, a workaround there. This guide explains what genuine conformance with AAOIFI (the Accounting and Auditing Organization for Islamic Financial Institutions) actually demands of a core platform, and how to tell native support from marketing.

Why “renamed interest” fails

Islamic finance is not conventional finance with different labels. The structures are economically and legally distinct: a Murabaha is a real purchase and resale with a disclosed margin; an Ijarah is a lease in which the bank genuinely owns the asset; a Mudaraba is an investment partnership in which depositors share profit and bear loss. A core that models these as interest-bearing loans with cosmetic renaming will fail three audiences at once: the Shariah board, the external auditor, and increasingly the regulator.

What a native platform must model

• Asset-backed lifecycles. Murabaha and Ijarah require the asset itself — acquisition, ownership, transfer — to exist in the product lifecycle, not just a financed amount.
• Profit, not interest. Accounting flows must compute and post profit distributions, not accrue interest and relabel it.
• Loss-sharing paths. Mudaraba and Musharaka pools need the loss leg modelled with the correct treatment — the hardest part to retrofit, and the first thing a Shariah auditor checks.
• The Hijri calendar. Zakat assessment runs on Hijri years. A platform that approximates Hijri windows from Gregorian dates in reports will eventually misstate someone's obligation.
• Shariah governance. Product approvals, fatwa references and board decisions should be first-class, audited workflow objects — evidence, not email threads.

AAOIFI Standard 35 and Zakat

Zakat is where conformance becomes concrete. AAOIFI's Standard 35 governs how Zakat is computed — across cash savings, investment certificates such as Sukuk, and capital placed in profit-sharing pools — per customer, per Hijri year. Doing this correctly requires the core to know each customer's zakatable base across products and time windows, and to produce statements a customer (and an authority such as DZIT in Saudi Arabia) can rely on. This is a cross-product computation that bolt-on Islamic modules, which see only their own product silo, structurally cannot perform. KORE's approach is described on the Islamic banking page.

The evaluation question is not “do you support Murabaha?” — everyone says yes. It's “show me the loss leg of a Musharaka pool, the Hijri-year Zakat statement, and the Shariah board's approval trail for this product — on the live system.”

The dual-core dividend

Many MENA banks run both books — a conventional window and an Islamic one, or vice versa. Running them on separate platforms doubles cost and splits the customer view. A platform built for both — two cores in one — shares the customer master, the ledger, the audit chain and the regulator packs, while keeping the product disciplines properly distinct. Investment products like Sukuk follow the same logic on the wealth side.

A buyer's checklist

• Are Islamic products first-class structures with their own lifecycles and accounting?
• Is the Hijri calendar computed in the platform spine?
• Can the platform produce AAOIFI Standard 35 Zakat assessments per customer?
• Are profit and loss distribution paths implemented for the pools?
• Is Shariah-board governance an audited workflow, not a document folder?
• Do conventional and Islamic books share one ledger and one audit chain?

Six yeses means the platform was built for it. Anything less means you're buying the retrofit — and the retrofit always surfaces at audit time.