

Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path
Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests
Leg, One Document — Every Contract Leg Hash-Chained and Timestamped
Product
SANAD by IOTA
IOTA’s loan origination platform (LOS) for KSA and UAE lenders — a product-agnostic origination engine with Shariah-compliant product modules: Murabaha supply chain finance (Wasl), Tawarruq, BNPL and embedded lending, with each institution’s Shariah rulings held as configuration.
Year
2026
Industry
Lending — Banks, Finance Companies & Fintechs, KSA and UAE
SERVICE USED
Digital Engineering, AI Development, Cybersecurity
Challenge
Conventional origination bolts a compliance layer onto a loan book — Saudi institutions need origination that is Shariah-compliant by construction and ruled on by their own boards
(iota — the problem)
Conventional supply chain finance is a sale of debt and cannot be made Shariah-compliant. Institutions need origination that produces real trade — evidenced ownership, a disclosed markup, and rulings their own Shariah board can configure.
(iota — solution)
Origination that is Shariah-compliant by construction
SANAD (سند) is IOTA’s loan origination platform for SAMA-regulated banks, finance companies and fintechs in Saudi Arabia, and for lenders in the UAE: one origination engine, with product modules that each deploying institution enables under its own Shariah Supervisory Board — Murabaha supply chain finance, Tawarruq, BNPL and embedded lending, consumer and SME, on one core. Its first module, Wasl (وصل), finances SME supply chains under Murabaha: the institution buys the goods, takes title, bears the ownership risk for an evidenced interval, and sells them on at a disclosed markup. Goods, ownership, possession and custody are first-class in the domain model — and the Murabaha engine has no interest construct in it.
What the platform does
Contract Sequencing Engine — hard gates so no sale can be offered before ownership and possession are evidenced, typed evidence that is appended and superseded but never edited, and contract legs that are hash-chained and timestamped by an attested time source. There is no override role.
Decisioning — a credit policy language, engine, snapshot and decision record, so every limit, threshold and approval is versioned, effective-dated configuration that can be replayed.
Pricing and obligation — sale price is cost plus profit and nothing else, a total that can never increase, one-directional waivers, and late amounts posted to a segregated charity liability, never to income.
e-Invoice-anchored trade — ZATCA FATOORA e-invoices as the keystone against fake invoices, duplicate financing and unverifiable SME revenue, with each financed invoice registered once per tenant.
Board-ruled configuration — anything a Shariah board can rule on is configuration, nothing a board can rule on is code. Two institutions can differ on the risk-holding interval, on what evidence discharges possession, and on how a limit is sized, without a line of code between them.
Every invariant, enforced four times
Each Shariah invariant is enforced in the type system, in the service layer, in the database and in an adversarial test suite where a test passes only when the forbidden attempt fails: no sale before the gates, a total that never increases, one leg per document, no duplicate financing, late charges that are never income, and no rate anywhere in the Murabaha engine.
Technology stack
Frontend: Next.js with React and Tailwind CSS
Services: Node.js and TypeScript, with Temporal durable workflows driving contract sequencing that runs for hours or days
API management: IBM API Connect with DataPower gateways
Data: PostgreSQL via Supabase for development, with row-level security per tenant and domain schemas that are never exposed through the auto-generated API — portable to self-hosted, in-Kingdom PostgreSQL for bank deployments
Cache and queues: Redis
Core banking: Tuum for parties, accounts, ledger, payments and schedules — SANAD keeps all Islamic contract logic
Documents and e-signature: Nutrient, self-hosted in-Kingdom
Credentials: partner keys held in Supabase Vault, moving to a customer-managed key in an in-Kingdom HSM
KSA rail adapters: Nafath, Yakeen, Tahaqoq, Wathq, SIMAH, Bayan, GOSI, ZATCA e-invoicing and tax, SADAD, the Payments Hub, Open Banking, a commodity broker and a rate publisher — each behind a capability-named port with a circuit breaker and recorded fixtures
Also in the repository: UAE adapters, licensing and screening adapters, and a consumer application
Assurance: security scanning, hosted checks and an adversarial compliance suite run in CI on every change
Status
SANAD is in development. The design is not frozen: it is subject to the rulings of each deploying institution’s Shariah Supervisory Board, and where the platform takes a position on a contested point it takes it as configuration. Data residency is treated as non-negotiable — in-Kingdom storage and keys for every production deployment.
Early access: tell us about your institution through the form on our home page and our team will connect with you.
(iota — in our words)
Wasl is not a lending system with a compliance layer. It is a trading system that produces a financing outcome: the institution buys the goods, takes title, bears the ownership risk, and sells on at a disclosed markup.

IOTA Labs Team
Digital Engineering Practice


Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path
Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests
Leg, One Document — Every Contract Leg Hash-Chained and Timestamped
Product
SANAD by IOTA
IOTA’s loan origination platform (LOS) for KSA and UAE lenders — a product-agnostic origination engine with Shariah-compliant product modules: Murabaha supply chain finance (Wasl), Tawarruq, BNPL and embedded lending, with each institution’s Shariah rulings held as configuration.
Year
2026
Industry
Lending — Banks, Finance Companies & Fintechs, KSA and UAE
SERVICE USED
Digital Engineering, AI Development, Cybersecurity
Challenge
Conventional origination bolts a compliance layer onto a loan book — Saudi institutions need origination that is Shariah-compliant by construction and ruled on by their own boards
(iota — the problem)
Conventional supply chain finance is a sale of debt and cannot be made Shariah-compliant. Institutions need origination that produces real trade — evidenced ownership, a disclosed markup, and rulings their own Shariah board can configure.
(iota — solution)
Origination that is Shariah-compliant by construction
SANAD (سند) is IOTA’s loan origination platform for SAMA-regulated banks, finance companies and fintechs in Saudi Arabia, and for lenders in the UAE: one origination engine, with product modules that each deploying institution enables under its own Shariah Supervisory Board — Murabaha supply chain finance, Tawarruq, BNPL and embedded lending, consumer and SME, on one core. Its first module, Wasl (وصل), finances SME supply chains under Murabaha: the institution buys the goods, takes title, bears the ownership risk for an evidenced interval, and sells them on at a disclosed markup. Goods, ownership, possession and custody are first-class in the domain model — and the Murabaha engine has no interest construct in it.
What the platform does
Contract Sequencing Engine — hard gates so no sale can be offered before ownership and possession are evidenced, typed evidence that is appended and superseded but never edited, and contract legs that are hash-chained and timestamped by an attested time source. There is no override role.
Decisioning — a credit policy language, engine, snapshot and decision record, so every limit, threshold and approval is versioned, effective-dated configuration that can be replayed.
Pricing and obligation — sale price is cost plus profit and nothing else, a total that can never increase, one-directional waivers, and late amounts posted to a segregated charity liability, never to income.
e-Invoice-anchored trade — ZATCA FATOORA e-invoices as the keystone against fake invoices, duplicate financing and unverifiable SME revenue, with each financed invoice registered once per tenant.
Board-ruled configuration — anything a Shariah board can rule on is configuration, nothing a board can rule on is code. Two institutions can differ on the risk-holding interval, on what evidence discharges possession, and on how a limit is sized, without a line of code between them.
Every invariant, enforced four times
Each Shariah invariant is enforced in the type system, in the service layer, in the database and in an adversarial test suite where a test passes only when the forbidden attempt fails: no sale before the gates, a total that never increases, one leg per document, no duplicate financing, late charges that are never income, and no rate anywhere in the Murabaha engine.
Technology stack
Frontend: Next.js with React and Tailwind CSS
Services: Node.js and TypeScript, with Temporal durable workflows driving contract sequencing that runs for hours or days
API management: IBM API Connect with DataPower gateways
Data: PostgreSQL via Supabase for development, with row-level security per tenant and domain schemas that are never exposed through the auto-generated API — portable to self-hosted, in-Kingdom PostgreSQL for bank deployments
Cache and queues: Redis
Core banking: Tuum for parties, accounts, ledger, payments and schedules — SANAD keeps all Islamic contract logic
Documents and e-signature: Nutrient, self-hosted in-Kingdom
Credentials: partner keys held in Supabase Vault, moving to a customer-managed key in an in-Kingdom HSM
KSA rail adapters: Nafath, Yakeen, Tahaqoq, Wathq, SIMAH, Bayan, GOSI, ZATCA e-invoicing and tax, SADAD, the Payments Hub, Open Banking, a commodity broker and a rate publisher — each behind a capability-named port with a circuit breaker and recorded fixtures
Also in the repository: UAE adapters, licensing and screening adapters, and a consumer application
Assurance: security scanning, hosted checks and an adversarial compliance suite run in CI on every change
Status
SANAD is in development. The design is not frozen: it is subject to the rulings of each deploying institution’s Shariah Supervisory Board, and where the platform takes a position on a contested point it takes it as configuration. Data residency is treated as non-negotiable — in-Kingdom storage and keys for every production deployment.
Early access: tell us about your institution through the form on our home page and our team will connect with you.
(iota — in our words)
Wasl is not a lending system with a compliance layer. It is a trading system that produces a financing outcome: the institution buys the goods, takes title, bears the ownership risk, and sells on at a disclosed markup.

IOTA Labs Team
Digital Engineering Practice


Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path
Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests
Leg, One Document — Every Contract Leg Hash-Chained and Timestamped
Product
SANAD by IOTA
IOTA’s loan origination platform (LOS) for KSA and UAE lenders — a product-agnostic origination engine with Shariah-compliant product modules: Murabaha supply chain finance (Wasl), Tawarruq, BNPL and embedded lending, with each institution’s Shariah rulings held as configuration.
Year
2026
Industry
Lending — Banks, Finance Companies & Fintechs, KSA and UAE
SERVICE USED
Digital Engineering, AI Development, Cybersecurity
Challenge
Conventional origination bolts a compliance layer onto a loan book — Saudi institutions need origination that is Shariah-compliant by construction and ruled on by their own boards
(iota — the problem)
Conventional supply chain finance is a sale of debt and cannot be made Shariah-compliant. Institutions need origination that produces real trade — evidenced ownership, a disclosed markup, and rulings their own Shariah board can configure.
(iota — solution)
Origination that is Shariah-compliant by construction
SANAD (سند) is IOTA’s loan origination platform for SAMA-regulated banks, finance companies and fintechs in Saudi Arabia, and for lenders in the UAE: one origination engine, with product modules that each deploying institution enables under its own Shariah Supervisory Board — Murabaha supply chain finance, Tawarruq, BNPL and embedded lending, consumer and SME, on one core. Its first module, Wasl (وصل), finances SME supply chains under Murabaha: the institution buys the goods, takes title, bears the ownership risk for an evidenced interval, and sells them on at a disclosed markup. Goods, ownership, possession and custody are first-class in the domain model — and the Murabaha engine has no interest construct in it.
What the platform does
Contract Sequencing Engine — hard gates so no sale can be offered before ownership and possession are evidenced, typed evidence that is appended and superseded but never edited, and contract legs that are hash-chained and timestamped by an attested time source. There is no override role.
Decisioning — a credit policy language, engine, snapshot and decision record, so every limit, threshold and approval is versioned, effective-dated configuration that can be replayed.
Pricing and obligation — sale price is cost plus profit and nothing else, a total that can never increase, one-directional waivers, and late amounts posted to a segregated charity liability, never to income.
e-Invoice-anchored trade — ZATCA FATOORA e-invoices as the keystone against fake invoices, duplicate financing and unverifiable SME revenue, with each financed invoice registered once per tenant.
Board-ruled configuration — anything a Shariah board can rule on is configuration, nothing a board can rule on is code. Two institutions can differ on the risk-holding interval, on what evidence discharges possession, and on how a limit is sized, without a line of code between them.
Every invariant, enforced four times
Each Shariah invariant is enforced in the type system, in the service layer, in the database and in an adversarial test suite where a test passes only when the forbidden attempt fails: no sale before the gates, a total that never increases, one leg per document, no duplicate financing, late charges that are never income, and no rate anywhere in the Murabaha engine.
Technology stack
Frontend: Next.js with React and Tailwind CSS
Services: Node.js and TypeScript, with Temporal durable workflows driving contract sequencing that runs for hours or days
API management: IBM API Connect with DataPower gateways
Data: PostgreSQL via Supabase for development, with row-level security per tenant and domain schemas that are never exposed through the auto-generated API — portable to self-hosted, in-Kingdom PostgreSQL for bank deployments
Cache and queues: Redis
Core banking: Tuum for parties, accounts, ledger, payments and schedules — SANAD keeps all Islamic contract logic
Documents and e-signature: Nutrient, self-hosted in-Kingdom
Credentials: partner keys held in Supabase Vault, moving to a customer-managed key in an in-Kingdom HSM
KSA rail adapters: Nafath, Yakeen, Tahaqoq, Wathq, SIMAH, Bayan, GOSI, ZATCA e-invoicing and tax, SADAD, the Payments Hub, Open Banking, a commodity broker and a rate publisher — each behind a capability-named port with a circuit breaker and recorded fixtures
Also in the repository: UAE adapters, licensing and screening adapters, and a consumer application
Assurance: security scanning, hosted checks and an adversarial compliance suite run in CI on every change
Status
SANAD is in development. The design is not frozen: it is subject to the rulings of each deploying institution’s Shariah Supervisory Board, and where the platform takes a position on a contested point it takes it as configuration. Data residency is treated as non-negotiable — in-Kingdom storage and keys for every production deployment.
Early access: tell us about your institution through the form on our home page and our team will connect with you.
(iota — in our words)
Wasl is not a lending system with a compliance layer. It is a trading system that produces a financing outcome: the institution buys the goods, takes title, bears the ownership risk, and sells on at a disclosed markup.

IOTA Labs Team
Digital Engineering Practice


Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path
Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests
Product
SANAD by IOTA
IOTA’s loan origination platform (LOS) for KSA and UAE lenders — a product-agnostic origination engine with Shariah-compliant product modules: Murabaha supply chain finance (Wasl), Tawarruq, BNPL and embedded lending, with each institution’s Shariah rulings held as configuration.
Year
2026
Industry
Lending — Banks, Finance Companies & Fintechs, KSA and UAE
SERVICE USED
Digital Engineering, AI Development, Cybersecurity
Challenge
Conventional origination bolts a compliance layer onto a loan book — Saudi institutions need origination that is Shariah-compliant by construction and ruled on by their own boards
(iota — the problem)
Conventional supply chain finance is a sale of debt and cannot be made Shariah-compliant. Institutions need origination that produces real trade — evidenced ownership, a disclosed markup, and rulings their own Shariah board can configure.
(iota — solution)
Origination that is Shariah-compliant by construction
SANAD (سند) is IOTA’s loan origination platform for SAMA-regulated banks, finance companies and fintechs in Saudi Arabia, and for lenders in the UAE: one origination engine, with product modules that each deploying institution enables under its own Shariah Supervisory Board — Murabaha supply chain finance, Tawarruq, BNPL and embedded lending, consumer and SME, on one core. Its first module, Wasl (وصل), finances SME supply chains under Murabaha: the institution buys the goods, takes title, bears the ownership risk for an evidenced interval, and sells them on at a disclosed markup. Goods, ownership, possession and custody are first-class in the domain model — and the Murabaha engine has no interest construct in it.
What the platform does
Contract Sequencing Engine — hard gates so no sale can be offered before ownership and possession are evidenced, typed evidence that is appended and superseded but never edited, and contract legs that are hash-chained and timestamped by an attested time source. There is no override role.
Decisioning — a credit policy language, engine, snapshot and decision record, so every limit, threshold and approval is versioned, effective-dated configuration that can be replayed.
Pricing and obligation — sale price is cost plus profit and nothing else, a total that can never increase, one-directional waivers, and late amounts posted to a segregated charity liability, never to income.
e-Invoice-anchored trade — ZATCA FATOORA e-invoices as the keystone against fake invoices, duplicate financing and unverifiable SME revenue, with each financed invoice registered once per tenant.
Board-ruled configuration — anything a Shariah board can rule on is configuration, nothing a board can rule on is code. Two institutions can differ on the risk-holding interval, on what evidence discharges possession, and on how a limit is sized, without a line of code between them.
Every invariant, enforced four times
Each Shariah invariant is enforced in the type system, in the service layer, in the database and in an adversarial test suite where a test passes only when the forbidden attempt fails: no sale before the gates, a total that never increases, one leg per document, no duplicate financing, late charges that are never income, and no rate anywhere in the Murabaha engine.
Technology stack
Frontend: Next.js with React and Tailwind CSS
Services: Node.js and TypeScript, with Temporal durable workflows driving contract sequencing that runs for hours or days
API management: IBM API Connect with DataPower gateways
Data: PostgreSQL via Supabase for development, with row-level security per tenant and domain schemas that are never exposed through the auto-generated API — portable to self-hosted, in-Kingdom PostgreSQL for bank deployments
Cache and queues: Redis
Core banking: Tuum for parties, accounts, ledger, payments and schedules — SANAD keeps all Islamic contract logic
Documents and e-signature: Nutrient, self-hosted in-Kingdom
Credentials: partner keys held in Supabase Vault, moving to a customer-managed key in an in-Kingdom HSM
KSA rail adapters: Nafath, Yakeen, Tahaqoq, Wathq, SIMAH, Bayan, GOSI, ZATCA e-invoicing and tax, SADAD, the Payments Hub, Open Banking, a commodity broker and a rate publisher — each behind a capability-named port with a circuit breaker and recorded fixtures
Also in the repository: UAE adapters, licensing and screening adapters, and a consumer application
Assurance: security scanning, hosted checks and an adversarial compliance suite run in CI on every change
Status
SANAD is in development. The design is not frozen: it is subject to the rulings of each deploying institution’s Shariah Supervisory Board, and where the platform takes a position on a contested point it takes it as configuration. Data residency is treated as non-negotiable — in-Kingdom storage and keys for every production deployment.
Early access: tell us about your institution through the form on our home page and our team will connect with you.
(iota — in our words)
Wasl is not a lending system with a compliance layer. It is a trading system that produces a financing outcome: the institution buys the goods, takes title, bears the ownership risk, and sells on at a disclosed markup.

IOTA Labs Team
Digital Engineering Practice
(iota — 05)
More products



(iota — 15)
OUR PRINCIPLES
Book a
free call
We design AI systems that improve real work —
not just demonstrate technology.
We’ll review your
workflows, identify
where AI can create
impact, and outline
a clear path forward.
We’ll review your workflows, identify AI opportunities, and outline a clear path forward.
We’ll review your workflows, identify where AI can create impact, and outline
a clear path forward.
No preparation needed — we’ll guide the conversation
and focus on what matters.
No preparation needed — we’ll guide the conversation and focus on what matters.
7 AI products
100%
deployable on-prem, air-gapped


