借助 MongoDB 和 BIAN 实现核心银行业务现代化

数据流

流程是细致的，以下步骤总结了集合如何参与过程流：

1. 付款指令将在付款中落地。

2. 同步付款执行会将执行的事实事务写入 transactions，并更新操作账户余额。

3. 事务上的变更流会触发分类帐本管道。

4. 分类帐分阶段为每个事务写入一个 ledgerEvent。

   分类帐事件包含两个腿和过帐模式，用于确定其下游路径。

   示例文档：分类帐本事件

   {
     "eventId": "LE-20260415-000042",
     "idempotencyKey": "PAY-20260415-0042",
     "groupId": "GRP-20260415-000042",
     "eventType": "PAYMENT_PRINCIPAL",
     "debitLeg": {
       "glAccountCode": "1001",
       "controlAccountCode": "1000",
       "amount": {
         "$numberLong": "100000"
       },
       "currency": "USD",
       "entityReference": {
         "entityType": "ACCOUNT",
         "entityId": "ACC-001234"
       }
     },
     "creditLeg": {
       "glAccountCode": "2100",
       "controlAccountCode": "2000",
       "amount": {
         "$numberLong": "100000"
       },
       "currency": "USD",
       "entityReference": {
         "entityType": "ACCOUNT",
         "entityId": "ACC-001235"
       }
     },
     "postingMode": {
       "type": "BATCH"
     },
     "postingStatus": "PENDING",
     "sourceReference": {
       "sourceCollection": "transactions",
       "sourceId": "PAY-20260415-0042",
       "sourceSystem": "LEDGER_PIPELINE"
     }
   }

5. 投影阶段为每个事件写入两个 subLedgerEntries。

   投影工作人员将一个 ledgerEvent 分成两个 subLedgerEntries，每条腿一个，在 ACID transaction 中一起写入。每个都可以作为完整的发布单元独立存在；journalEntryId 携带 "" 守卫直到 gl_batch 盖章真实 ID。

   示例文档：子分类账分录

   {
     "subLedgerId": "SLE-20260415-000042-D",
     "idempotencyKey": "LE-20260415-000042:DEBIT",
     "controlAccountCode": "1000",
     "side": "DEBIT",
     "amount": {
       "$numberLong": "100000"
     },
     "currency": "USD",
     "periodCode": "2026-04",
     "status": "POSTED",
     "journalEntryId": "",
     "entityReference": {
       "entityType": "ACCOUNT",
       "entityId": "ACC-001234"
     },
     "sourceReference": {
       "sourceCollection": "ledgerEvents",
       "sourceId": "LE-20260415-000042",
       "sourceSystem": "LEDGER_PIPELINE"
     }
   }

   其平衡信用边是第二个文档— 与 sourceId 相同，但 side 和 controlAccountCode 相反，entityId: ACC-001235。 journalEntryId ($gt: "") 上的部分索引会排除两者，直到批处理填充真实的日志ID。

6. 批处理路径写入平衡的 journalEntries。

   批处理会将子分类账分录聚合到一个日志中，其平衡行位于嵌入式数组中。

   示例文档：日志分录

   {
     "journalId": "JNL-20260623-EOD-1001",
     "idempotencyKey": "BATCH-20260623-EOD:1000:2026-06",
     "periodCode": "2026-06",
     "journalType": "LEDGER_EVENT_POSTING",
     "status": "POSTED",
     "totalAmount": {
       "$numberLong": "1000000"
     },
     "entries": [
       {
         "lineNumber": 1,
         "accountCode": "1000",
         "side": "DEBIT",
         "amount": {
           "$numberLong": "1000000"
         },
         "currency": "USD"
       },
       {
         "lineNumber": 2,
         "accountCode": "2000",
         "side": "CREDIT",
         "amount": {
           "$numberLong": "1000000"
         },
         "currency": "USD"
       }
     ]
   }

7. 验证器实施会计不变量

   三个集合验证器将会计规则推入数据库，因此，跳过服务层的写入仍然不会损坏账簿。ledgerEvents 验证器要求业务字段，并将 postingStatus 锁定到已知的 enum。

   _LEDGER_EVENTS_VALIDATOR = {"$jsonSchema": {
       "bsonType": "object",
       "required": ["eventId", "idempotencyKey", "groupId", "occurredAt", "valueDate", "eventType", "debitLeg", "creditLeg", "postingStatus", "sourceReference", "mappingVersion"],
       "properties": {
           "postingStatus": {"bsonType": "string", "enum":["PENDING", "POSTED", "FAILED"]},
           "debitLeg": _LEG_SCHEMA, "creditLeg": _LEG_SCHEMA,
       },
   }}

   subLedgerEntries 验证器将 side 锁定到 DEBIT 或 CREDIT，并将 status 锁定到 POSTED 或 FAILED，并要求每个文档上都有 journalEntryId — "" 前站可以满足这一要求，直到 gl_batch 打上真实 ID，因此条目不会超出该生命周期。

   journalEntries 验证器直接实施 Pacioli 平衡不变量：借记行的总和必须等于信用行的总和，在每次写入时使用 $expr 进行检查。

   _JOURNAL_BALANCE_VALIDATOR = {"$expr": {"$eq": [
       {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
           "cond": {"$eq": ["$$e.side", "DEBIT"]}}}, "as": "e", "in": "$$e.amount"}}},
       {"$sum": {"$map": {"input": {"$filter": {"input": "$entries", "as": "e",
           "cond": {"$eq": ["$$e.side", "CREDIT"]}}}, "as": "e", "in": "$$e.amount"}}},
   ]}}

   会计集合支持架构的财务侧。它们源自运营事件，而不是由账户或事务服务直接写入。

该链条可为您提供运营速度和会计控制。支付执行不会等待完整的 GL 过账，但每笔支付仍会解决为可审计的会计追踪。

为什么 MongoDB 是天然的选择？

客户数和账户数据是分层的，并会随着时间的推移而发生变化。支付记录通过轨道和渠道携带可变元数据。分类账目将相关会计事实分组为单一业务文档。

在 MongoDB 中，您可以存储帐户省/市/自治区、生命周期详情、KYC 上下文、付款事实和嵌入式过帖行，其形状与服务生产和消费数据的方式相匹配。您可以避免关系模型所需的重复平坦和重新组装。

使用 MongoDB 实现 BIAN

复制 Leafy Bank BIAN 解决方案