IIAB：约旦伊斯兰合规数字银行现代化

伊斯兰银行不是换了些说法的传统银行，这个区别在架构上是有意义的，而且它会在一个没有在这个领域工作过的开发者进入之前以他们没有预料到的方式显现。

伊斯兰国际阿拉伯银行（iiabank.com.jo）是一家在约旦经营的沙里亚合规银行，依据伊斯兰金融原则提供个人账户、企业银行和中小企业服务。在 Talentera 任职期间，我参与了他们数字银行平台的后端现代化工作—Web 门户、移动集成层、Apple Pay 和 IIAB Pay 实现，以及支持沙里亚合规验证的后端工作流。

沙里亚合规在后端上下文里意味着什么

核心区别：伊斯兰金融禁止利息（riba）。实际上意味着金融产品的结构不同—利润共享（Mudaraba）、成本加成融资（Murabaha）、融资租赁（Ijara）、股权合伙（Musharaka）。这些不是换了名字的附息贷款的等价物，有不同的法律结构、不同的支付计划、不同的披露要求和不同的审计轨迹。

对后端来说，这意味着：

产品模型比传统银行更复杂。一个 Murabaha 融资协议（银行购买资产后以成本加利润卖给客户）有与贷款不同的字段、不同的状态转换和不同的合规检查要求。数据模型必须准确表示这些—不是螺栓固定在贷款 schema 上的特殊情况，而是有自己工作流的一等实体。

沙里亚合规工作流是真实的。交易和产品必须满足从银行沙里亚监事会指导方针派生的验证规则。这些规则不是静态的—它们会被更新、审计和审查。系统需要应用当前版本的规则、记录应用了哪个版本，并维护内部沙里亚审计和外部监管审查所需的审计轨迹。

把这个建成传统银行后端上的一个复选框，是你以合规噩梦收场的方式。把它作为领域模型的核心部分来构建，是你得到银行能真正审计的系统的方式。

数字银行平台：有什么和需要改变什么

IIAB 的数字化产品覆盖个人客户、企业账户和中小企业板块—不同的产品、不同的入网流程、不同的额度结构、不同的监管报告。

我进入现代化工作时，后端有经营多年的金融机构的常见问题：功能上没问题但在老化，业务逻辑有机积累，与展示层分离得不好。那种一个产品的支付计划要改，就需要仔细追踪整个技术栈里其他什么假设了那个计划的代码库。

移动集成工作是最立竿见影的可交付成果。IIAB Pay 和 Thuraya 忠诚度计划集成、Apple Pay 连接、app 消费的移动银行 API 界面。2018 年约旦的移动银行不是事后的想法—这是相当大一部分客户群进行真实银行业务的地方。把 API 合同弄对很重要。更重要的是把移动体验的故障模式处理优雅：一笔在手机上看起来失败但在后端成功了的支付，是那种会造成真实客户损害、需要人工干预来解决的不一致。

支付系统里的幂等性：平淡无奇的必需品

每个支付工程师都有一个关于幂等性的故事。我的涉及一个在做它应该做的事—重试失败的网络调用—的重试机制，在一个把每次重试当作新交易处理的后端上。结果不是灾难性的，但很有教育意义。

在沙里亚合规的上下文里，这有额外的维度：重复交易不只是运营问题，也是合规问题。一笔随后被退款的双重收费，仍然是一个必须在沙里亚审计中解释、追溯原因并记录在案的事件。清理不只是数据库修复，而是一条纸质轨迹。

每个支付变更 API 调用上的幂等键。处理层的 exactly-once 语义。这些是支付的标准最佳实践，在银行里不是可选的。直说，因为我见过跳过它们时会发生什么。

客户细分以及为什么它们在架构上重要

个人、企业和中小企业不只是营销类别，它们有不同的：

• 入网工作流（文件要求、沙里亚合规验证、KYC 深度）
• 产品可用性（不是所有产品都对所有细分客户可用）
• 额度结构（交易限额、账户限额、融资限额因细分和监管要求而异，不只是业务政策）
• 报告要求（约旦的中小企业账户比个人账户有不同的税务和监管报告义务）

把这些当作具有不同标志的同一个客户处理的后端，最终会在额度规则和产品可用性规则和报告要求的交叉处产生 bug。在构建时正确建模每个细分客户的工作流的后端，通过构建来避免这类 bug。领域层的额外复杂度，在生产里没有微妙合规失败的情况下得到了回报。

我从这里带走了什么

伊斯兰金融是真正独特的领域。技术工作是真实的—支付、移动集成、安全、合规工作流—而领域增加了一层需要理解而不只是绕过实现的特异性。

受监管的金融机构、双语市场（阿拉伯语为主）、移动优先的客户行为和沙里亚合规要求的组合，产生了一套让工程更有要求、也更有意思的约束，比表面面积显示的要多。

我此后在更大规模下工作了（auxmoney 的信贷处理链路跑着严肃的 Kafka 吞吐量，HAKEEM 的国家 EHR）。把支付相关后端工作做对的纪律—幂等性、审计轨迹、合规工作流建模—是基础性的。你在 IIAB 的规模上正确构建它，当风险上升时你就有了那种本能。