Architecture, compliance, and integration — answered by the team who built it.

Technical depth, not marketing copy. Nine questions covering Shariah enforcement, the 13 regulatory regimes, overlay integration, SEPA Instant, AI agents over MCP, native engines, sandbox-to-production, jurisdictions, and data residency. If yours isn't here, the architecture review covers the rest.
How does IOF enforce Shariah compliance at the API level rather than as post-hoc reporting?

Every contract is typed against an AAOIFI standard (SS-8 → SS-39); compliance is impossible to bypass.

  • 66 typed contract schemas — Murabaha, Ijarah, Musharakah, Sukuk, Takaful, Waqf, Zakat, +59 more
  • Type-level impossibility of riba / gharar / unapproved variants
  • Fatwa reference required on every create call; Shariah board log emitted
  • ABAC + per-transaction signed evidence pack — zero post-hoc reconciliation
Which 13 regulatory regimes are enforced in the same audit envelope?

13 regimes evaluated inline; per-transaction evidence packs exportable per regime, per bundle, or full.

  • AAOIFI (SS-8 → SS-39) · IFSB (prudential) · SOC 2 Type II · ISO 27001
  • GDPR · PSD2 · PSD3 (designed-for) · ISO 20022 (pacs.008, pacs.003, pain.001/008)
  • Basel III (capital, LCR, NSFR) · EU AI Act 2024/1689 (Annex III) · FATF · MiCA · DORA
  • Evidence packs: SHA-256 Merkle-anchored, 7-year retention, regime-filterable
What does “overlay, not rip-and-replace” mean for integration with an existing core?

We sit beside your core, not in front of it. Typical 4–8 weeks from sandbox to production.

  • @iof/banking-connector adapters: Temenos · Finastra · Mambu · Open Banking Protocol · custom
  • Your GL, IAM, KYC provider, and settlement-bank relationships stay where they are
  • 73 Shariah-native rails layer above: contract origination, governance, compliance, evidence
  • Existing deposit + loan books are not disturbed during integration
How fast is SEPA Instant settlement, and what happens when a payment is not SEPA-eligible?

Under 10 seconds across 37 EU/EEA jurisdictions; auto-fallback to SWIFT or local RTGS.

  • EUR-denominated, capped at €100k per EPC 2025 SCT Inst rulebook
  • Payments Engine auto-detects eligibility from country / currency / amount
  • Non-SEPA fallback: SWIFT MT with GPI tracking, or jurisdictional RTGS / CSD
  • Messaging Engine emits ISO 20022 (pacs.008.001.10 / pacs.003.001.09), XSD-validated
How do AI agents integrate with IOF? What is the MCP server surface?

First-class MCP server at mcp.islamicopenfinance.com — every rail exposed as a typed tool.

  • 73 rails as MCP tools with typed JSON schemas
  • JSON-RPC 2.0 over HTTP + SSE streaming
  • Compatible with Claude, GPT, Gemini, Llama, and any MCP-aware framework
  • Tenant-scoped tool namespaces · per-call policy eval · per-action evidence pack
What are the 11 IOF native engines, and why do they matter to integrators?

Each engine ships as an independent @iof/*-engine-core npm package — consume what you need.

  • Contract · Ledger · Payments · Messaging · Compliance
  • Evidence · Onboarding · Treasury · Rules · Settlement
  • Resilience, Recovery & Exception (NEW — banking-grade operational resilience: split-leg failure, suspense holdings, compensation, evidence packs)
  • Composable — adopt one engine without taking the full rail stack
  • Each engine has its own CLI, schema, and per-package SemVer cadence
How is the sandbox provisioned, and what is the path from evaluation to production?

Provisioning target: under one business day. Production go-live: 4–8 weeks.

  • No self-service signup — eligibility review keeps every sandbox at live-grade compliance
  • Day 1 architecture review · week 1 first end-to-end contract · weeks 4–8 production
  • Sandbox runs all 73 rails + 150 endpoints identical to production
  • Pre-seeded synthetic data, isolated namespace, design-partner cohort runs live with the IOF team
Which jurisdictions are supported, and how is per-jurisdiction Shariah governance handled?

37+ jurisdictions across SEPA, GCC, SE Asia, Türkiye, UK — each with its own Shariah authority.

  • GCC: SAMA · DFSA / HSA UAE · QCB · CBB · CBK · CBO
  • SE Asia: BNM-SAC Malaysia · DSN-MUI Indonesia · SBP Pakistan
  • Other: Türkiye (BDDK) · UK (FCA) · 27 EU + 3 EEA states
  • Each profile carries: regulator map · Shariah authority · currency · settlement rail · compliance overrides
How does IOF handle data residency, encryption, and regulator subject-access requests?

Per-region partitioning, customer-managed KMS, BYOC across AWS / GCP / Azure / on-prem.

  • Tenant data: logically isolated, physically partitioned per region (EU, GCC, SE Asia, UK)
  • Encryption: TLS 1.3 in transit, AES-256-GCM at rest, 90-day KMS rotation
  • GDPR Art. 30 record + Art. 15–22 subject-access / erasure flows as first-class exports
  • BYOC supports customer-managed KMS + VPC peering on AWS / GCP / Azure / on-prem

Still have questions?

Book a 30-minute architecture review with our engineering team — we map your stack against IOF rails and surface the integration plan.