—UTC,7:55 AM
BOOK A DISCOVERY CALL
BOOK A DISCOVERY CALL
0

Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path

0

Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests

0

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.

A man looks left

IOTA Labs Team

Digital Engineering Practice

0

Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path

0

Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests

0

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.

A man looks left

IOTA Labs Team

Digital Engineering Practice

0

Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path

0

Layers Enforcing Every Shariah Invariant — Types, Services, Database, Tests

0

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.

A man looks left

IOTA Labs Team

Digital Engineering Practice

0

Interest Constructs in the Murabaha Engine — No Rate Field, Column or Code Path

0

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.

A man looks left

IOTA Labs Team

Digital Engineering Practice

VALUES • VISION • BELIEF •VALUES • VISION • BELIEF •
VALUES • VISION • BELIEF •VALUES • VISION • BELIEF •

(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

(iota — end)

Closing Frame

Built Right

AI systems designed for clarity, reliability, and real
operational environments — not just experiments.

Home
Home
Updates
Updates
Products
Products
About Us
About Us
Contact Us
Contact Us

Socials

001.

LINKEDIN

Legal

001.

PRIVACY POLICY

002.

LEGAL ENTITY

003.

TERMS OF SERVICE

© 2026

IOTA Technologies Company

IOTA Labs builds production AI systems for regulated enterprises.

(iota — end)

Closing Frame

Built Right

AI systems designed for clarity, reliability, and real
operational environments — not just experiments.

Home
Updates
Products
About Us
Contact Us

Socials

001.

LINKEDIN

Legal

001.

PRIVACY POLICY

002.

LEGAL ENTITY

003.

TERMS OF SERVICE

© 2026

IOTA Technologies Company

IOTA Labs builds production AI systems for regulated enterprises.