IIAB：ヨルダンのシャリーア準拠デジタルバンキング近代化

イスラム金融は言葉を変えただけの従来の金融じゃない。この区別はアーキテクチャ上重要で、その空間で働いたことがない開発者が実際にその中に入るまで予測しない方法で重要だ。

イスラム国際アラブ銀行（iiabank.com.jo）はヨルダンで営業するシャリーア準拠銀行で、イスラム金融原則の下で個人口座、ビジネスバンキング、SME サービスを提供している。Talentera での勤務中に彼らのデジタルバンキングプラットフォームのバックエンド近代化—ウェブポータル、モバイルインテグレーションレイヤー、Apple Pay と IIAB Pay の実装、シャリーア準拠バリデーションをサポートするバックエンドワークフロー—に貢献した。

シャリーア準拠がバックエンドコンテキストで何を意味するか

コアの区別：イスラム金融は利息（リバー）を禁止する。実際のところ、これは金融商品の構造が違うことを意味する—利益分配（ムダーラバ）、コストプラス融資（ムラーバハ）、リースから所有権（イジャーラ）、エクイティパートナーシップ（ムシャーラカ）。これらは別の名前の利息付きローンの同等物じゃない。異なる法的構造、異なる支払いスケジュール、異なる開示要件、異なる監査証跡を持っている。

バックエンドにとって、これは：

製品モデルが従来の銀行より複雑だ。ムラーバハ融資契約（銀行が資産を購入し顧客にコストプラス利益で販売する）はローンスキーマにボルトで取り付けられた特殊ケースとしてではなく、独自のワークフローを持つファーストクラスエンティティとして—ローンとは異なるフィールド、異なる状態遷移、異なるコンプライアンスチェック要件を持つ。データモデルがそれを正確に表現しなければならない。

シャリーア準拠ワークフローは本物だ。トランザクションと製品は銀行のシャリーア監督委員会のガイドラインから導出されたバリデーションルールを満たさなければならない。これらのルールは静的じゃない—更新され、監査され、レビューされる。システムはルールの現在のバージョンを適用し、どのバージョンが適用されたかをログに記録し、内部シャリーア監査と外部規制レビューに必要な監査証跡を維持する必要がある。

従来のバンキングバックエンドのチェックボックスとしてこれを構築するのは、コンプライアンスの悪夢で終わる方法だ。ドメインモデルのコア部分として構築するのは、銀行が実際に監査できるシステムで終わる方法だ。

デジタルバンキングプラットフォーム：あったものと変える必要があったもの

IIAB のデジタル提供は個人顧客、ビジネス口座、SME セグメントをカバーしていた—異なる製品、異なるオンボーディングフロー、異なる上限構造、異なる規制報告。

近代化の作業に入ったとき、バックエンドは長年営業してきた金融機関の共通の問題を持っていた：機能するが老朽化していて、有機的に蓄積されてプレゼンテーションレイヤーとうまく分離されていないビジネスロジックを持つ。ある製品の支払いスケジュールを変更するのに、スタック内のどこかでそのスケジュールを仮定する他のものを慎重にトレースする必要があるコードベース。

モバイルインテグレーション作業が最も即座に見えるデリバラブルだった。IIAB Pay と Thuraya ロイヤルティプログラムのインテグレーション、Apple Pay 接続性、アプリが消費するモバイルバンキング API サーフェス。2018年のヨルダンのモバイルバンキングは後付けじゃなかった—実際のバンキングをしている顧客ベースの実質的な部分がそこにいた。API コントラクトを正しく設定することが重要だった。モバイルエクスペリエンスの障害モードを優雅に処理することはさらに重要だった：電話では失敗したように見えるがバックエンドでは成功した支払いは、本物の顧客への損害をもたらして手動介入が必要な種類の不一致だ。

決済システムの冪等性：地味だが必須

すべての決済エンジニアには冪等性についての話がある。私のは、失敗したネットワーク呼び出しをリトライすることになっていたリトライメカニズムが—まさにすべきことをやっていた—各リトライを新しいトランザクションとして処理しているバックエンドに対して動作していた話だ。結果は壊滅的じゃなかったが、教育的だった。

シャリーア準拠コンテキストでは、これには追加の次元がある：重複トランザクションは単なる運用上の問題じゃなく、コンプライアンスの問題でもある。後で返金される二重請求は依然としてシャリーア監査で説明される、原因がトレースされる、文書化されるべきイベントだ。クリーンアップはデータベースの修正じゃない。それは書類だ。

すべての支払い変更 API 呼び出しに冪等性キー。処理レイヤーでの exactly-once セマンティクス。これらは決済の標準的なベストプラクティスだ。銀行ではオプションじゃない。スキップされたときに何が起きるかを見てきたので率直に述べる。

顧客セグメントとそれがアーキテクチャ上なぜ重要か

個人、ビジネス、SME はマーケティングカテゴリーだけじゃない。それぞれ異なるものを持つ：

• オンボーディングワークフロー（文書要件、シャリーア準拠バリデーション、KYC の深度）
• 製品の利用可能性（すべての製品がすべてのセグメントで利用できるわけじゃない）
• 上限構造（トランザクション制限、口座制限、融資制限はセグメントと規制によって異なる、ビジネスポリシーだけじゃなく）
• 報告要件（SME 口座はヨルダンで個人口座とは異なる税と規制の報告義務を持つ）

これらを異なるフラグを持つ同じ顧客として扱うバックエンドは、最終的に上限ルールと製品利用可能性ルールと報告要件の交差点でバグを生む。各セグメントのワークフローを正しくモデル化するバックエンドは構造的にそのクラスのバグを避ける。ドメインレイヤーでの追加の複雑さは本番での微妙なコンプライアンス失敗の不在で報われる。

これから持ち帰ったもの

イスラム金融は本当に独自のドメインだ。技術的な作業は本物—決済、モバイルインテグレーション、セキュリティ、コンプライアンスワークフロー—そしてドメインはその中に実際にいることを理解することを要求する特殊性のレイヤーを追加する、周りを実装するだけじゃなく。

規制された金融機関、バイリンガル市場（アラビア語主体）、モバイルファーストの顧客行動、シャリーア準拠要件の組み合わせが、表面積が示唆するよりも要求が高くて興味深いエンジニアリングを生む制約のセットを生む。

その後、より高いスケールで働いてきた（auxmoney の与信パイプラインは本格的な Kafka ボリュームで、HAKEEM の国家 EHR）。決済に隣接するバックエンド作業を正しくやり遂げる規律—冪等性、監査証跡、コンプライアンスワークフローモデリング—は基礎的だ。IIAB のスケールで正しく構築すれば、ステークスが上がるときのための直感が身についている。