1. 概述

1.1 目标

本文描述私人银行税务与费用管理平台的通用需求与设计，覆盖三项核心能力：境外预提税追讨、费用管理（客户侧与银行侧）、实时报表与监控门户。

三项能力共享同一条主线：在跨国、多市场、多来源差异下，把”该收/该退的钱”和”该看见的数据”做成可计算、可追溯、可审计的闭环。

1.2 能力地图

1.3 设计原则

1. 税务与交易强解耦：交易引擎不内嵌税率计算，只”抛出税务事件”，由独立税务引擎订阅计算。
2. 三要素索引 + 规则配置化：资产属地、客户税收居民地、记账机构三要素作为复合索引；税率与豁免以规则表维护。
3. 费用两阶段解耦：先做 NAV 估值支柱（锁定历史价格），再做费率匹配与扣款，避免月度计费的价格溯源问题。
4. 读写解耦的展示架构：核心账本与只读展示分离，展示数据由核心实时单向同步，避免高并发查询冲击记账。
5. 全链路留痕：税务凭证、退税单据、费用扣款、审计日志全程可追溯。

1.4 架构总览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

flowchart TB
    subgraph SRC["事件与数据源"]
        TRD["交易 / 公司行动 / 分红"]
        POS["持仓与行情"]
    end
    subgraph TAXE["税务引擎"]
        NEXUS["三要素连结点"]
        EVT["税务事件引擎 TAX2_EVT"]
        RULE["国家级税制规则表"]
        EXT["外部综合税务引擎（年度申报）"]
        REC["退税凭证与追讨流转"]
    end
    subgraph FEE["费用引擎"]
        NAVP["阶段一：费用 NAV 支柱"]
        CALC["阶段二：费率匹配与扣款"]
    end
    subgraph REP["报表与门户"]
        AFS["只读展示（AFS）"]
        OUT["客户输出（通知单 / 结单）"]
        PORTAL["在线报表与监控门户"]
    end
    TRD --> NEXUS
    NEXUS --> EVT
    RULE --> EVT
    EVT --> EXT
    EVT --> REC
    POS --> NAVP
    NAVP --> CALC
    CALC --> AFS
    EVT --> AFS
    AFS --> PORTAL
    AFS --> OUT
    AFS --> REC

2. 境外预提税追讨（Withholding Tax Recovery）

2.1 需求

平台应提供完全外包的境外预提税追讨服务：在跨境股息、利息与基金分红场景下，尽可能在源头适用税收协定优惠税率；无法源头减免时，按法定税率代扣后发起退税追讨。✅（税务机制）/ ⬜（”全外包”服务本身）

2.2 设计

2.2.1 三要素税收连结点（Tri-Factor Nexus）

系统不为每个国家硬编码孤立逻辑，而是用三要素组合判定适用规则：

1
2
3
4
5
6
7
8
9
10

flowchart TD
    A["① 资产属地连结点<br/>标的发售国 / 金融类别 / 计价币种<br/>OBJ_ASSET"]
    B["② 客户纳税连结点<br/>税收居民国 / TIN / W-8 / W-9 / CRS<br/>OBJ_BP / DOCP_BP_TAX_ATX_HDET"]
    C["③ 记账机构连结点<br/>银行分行法人所在地 BU_ID"]
    D["④ 双边税收协定 DTA/DTT<br/>协定优惠税率 vs 法定税率"]
    E["税务裁决与计算"]
    A --> E
    B --> E
    C --> E
    D --> E

三要素分别读取：资产发售国与子类型（OBJ_ASSET.COUNTRY_DOMI_ID）、客户税收居民国与身份（OBJ_BP.COUNTRY_TAX_ID 与 DOCP_BP_TAX_ATX_HDET，含 TIN、US Person、W-8BEN/W-8BEN-E、CRS 申报国）、记账机构（会话上下文 BU_ID，如 HK/SG/CH/UK 分行）。✅

2.2.2 源头减免 vs 事后退税

1
2
3
4
5
6
7
8

flowchart TD
    DIV["分红 / 利息事件"] --> CHK{"客户已提供有效居民身份与协定声明？"}
    CHK -->|是| ROS["源头优惠减免<br/>按协定优惠税率代扣<br/>（如美国 30% → 10%/15%）"]
    CHK -->|否| WHT["按法定税率全额源头代扣"]
    WHT --> VOUCHER["生成股息凭据（Tax Voucher）"]
    VOUCHER --> CLAIM["触发退税追讨流程<br/>向境外税务局递交申请"]
    ROS --> NET["净额入账"]
    CLAIM --> NET

• 源头优惠减免（Relief at Source）：客户提供经核验的居民身份与协定申请（如 W-8BEN），系统在分红发放时直接采用协定优惠税率。✅
• 事后退税追讨（Tax Reclaim）：无法源头减免时，先按全额法定税率代扣，随后生成具有法律效力的股息凭据（Tax Voucher），触发退税追讨流程向境外税务局递交多扣税款的追讨申请。✅

2.2.3 预提税计算与事件引擎

以基金/股票分红为例，公司行动流程在登记日截取客户有效持仓，联动税务引擎计算预提税并生成代缴凭证：✅

$$
\text{GrossDividend} = \text{EligibleShares}_{\text{RecordDate}} \times \text{DividendRate}
$$

$$
\text{TaxWithheld} = \text{GrossDividend} \times \text{WithholdingTaxRate}
$$

$$
\text{NetCashPaid} = \text{GrossDividend} - \text{TaxWithheld}
$$

跨币种税款折算不使用任意时点均价，而是强制选取与交易发生时刻序号距离最小的成交汇率：✅

$$
\min_{r}\ \left| \text{Rate_Seg_Nr}_r - \text{Entry_Seq_Nr} \right|
$$

对撤销、部分退还或冲正的交易，系统不物理篡改原始纳税单据，而是路由至冲正流程生成相反符号的负向分录，并在客户账户生成退税代发单据，保持双向合规凭据链。✅

2.2.4 跨国税制配置矩阵（节选）

平台把多国税制抽象为结构化维度，规则与税率以配置表维护，专业年度申报委托外部引擎：✅

三层分工：① PL/SQL 负责税务事件调度与批次税池结转；② CODE_*_TAX_* 规则表维护税率、豁免额度与协定矩阵；③ 外部专业税务报表引擎（如 BearingPoint EasyTax，接入 18 个过程）负责年度综合申报表排版。✅

2.3 证据边界

• ✅ 三要素连结点、源头减免/事后退税的机制与调用点、预提税公式、事件引擎的汇率匹配与冲正路由、各国税制规模与规则表。
• ⬜ 退税追讨流程内部（申请组装、税务局回执、到账追踪）、“完全外包服务”本身（属商业服务承诺）、各国具体税率与豁免口径（在配置表与包体内，未逐一取证）、EasyTax 内部排版逻辑。

3. 费用管理（Fee Management：客户侧与银行侧）

3.1 需求

平台应提供面向客户与银行的费用管理：对客户按协议计提并扣收管理费、托管费、业绩报酬与顾问费；对银行形成可核算的收入与成本视图。✅（引擎与调用点）/ ⬜（费率公式）

3.2 设计

3.2.1 两阶段费用架构

1
2
3
4
5
6
7
8
9
10

flowchart TD
    A["持仓明细 POS + 每日收盘行情 MD"] --> B["阶段一：费用 NAV 支柱<br/>TASK_FEE_PVAL_NAV"]
    B --> C["锁定 NAV 快照 FEE_PVAL_NAV_SERPIL"]
    C --> D["阶段二：任务编排与并发分片<br/>TASK_FEE"]
    D --> E1["Head Phase：首对象隔离单跑"]
    D --> E2["Chunk Phase：对象哈希并发分片"]
    D --> E3["Tail Phase：尾对象归集提交"]
    E2 --> F["匹配阶梯费率协议并计算"]
    F --> G["生成费用扣款单据 DOC_FEE"]
    G --> H["联动借记结算"]

• 阶段一（费用 NAV 支柱）：为每个计费周期逐日生成持仓 NAV 快照，锁定历史报价，解决月度计费的价格溯源。估值日期遵循回溯规则：✅

$$
\text{EvalDate} = \begin{cases} \operatorname{COALESCE}(\text{LastNAVDate}-1,\ \text{CalculationDate}) & \text{启用 LastNAV 逻辑} \ \text{CalculationDate} & \text{标准情况} \end{cases}
$$

$$
PVAL_{pos} = \operatorname{MP_CURRY.RD}(\operatorname{MD#.VAL}(\dots),\ PositionCurrencyAsset)
$$

• 阶段二（编排与结算）：读取支柱数据，匹配阶梯式费率协议，并发计算并生成扣款单据，联动借记结算。✅

3.2.2 费用类型与计费基准

费用计费采用高并发三阶段防死锁模型：Head Phase 单独执行首对象完成字典缓存与参数初始化；Chunk Phase 按账户哈希把客户合同切成互不相交批次并发执行、独立分段提交；Tail Phase 单独执行尾对象并汇总释放锁。✅

3.2.3 银行侧收入与客户侧分摊

• 收入分成：证券借贷收益按代理协议在客户与银行之间按比例分成（如客户 70%、银行 30%），按日计提借出费率。✅（机制）/ ⬜（具体分成比例）
• 交易成本分摊：母单成交后按子订单比例回填成交量，并以币种法定精度分配应计利息、交易税费与经纪佣金，保证分摊总和等于交易所总账单（零分钱误差）。✅
• 手续费承担方：支付支持我方承担（OUR）、收款人承担（BEN）与共同分摊（SHA）。✅
• 成本汇总：已过账成本按单据与事件汇总，不重算费率/税额/汇率：✅

$$
Cost = \operatorname{NVL}\left(\sum_{p \in P} -,p.QTY_1 \times \operatorname{SIGN}(p.EVT_ID),\ 0\right)
$$

• 客户价值视角：客户生命周期价值可由 AUM × 综合费率 + 交易费 − 服务成本折现评估，综合费率包含代销分佣、托管费率与咨询费。✅（模型）/ ⬜（取值）

3.2.4 费用金额分配与提取

费用金额在对象/FEEP/分类维度上的分配由专用例程执行（调用点可证）；汇丰定制过程只从已完成的费用 NAV 支柱中按报表模板提取字段并组装外发文本，不做 NAV 计算或费率推导。✅（调用点与提取）/ ⬜（分配公式）

3.3 证据边界

• ✅ 两阶段架构、NAV 快照公式、费用类型、三阶段并发模型、扣款单据与结算联动、交易成本分摊、成本汇总、提取边界。
• ⬜ 费率、阶梯、最低/最高费、折扣、返佣、高水位、利润分成、费用应计的实际公式（在费用 package 内，未定位）；具体费率取值；历史统计类数字。

4. 实时报表与监控门户（Reporting & Monitoring Portal）

4.1 需求

平台应提供基于在线报表门户的实时报表与监控：客户与顾问可自助查看持仓、收益、税务与费用信息，并支持批量输出。✅（展示与输出架构）/ ⬜（”实时”承诺与门户 UI）

4.2 设计

4.2.1 读写解耦的展示架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

flowchart TB
    subgraph K["核心账本（K）"]
        TXN["交易 / 记账 / 主数据"]
    end
    subgraph S["同步"]
        TRG["行级触发器复制"]
        ERR["DML 错误日志 ERR$_"]
    end
    subgraph A["只读展示（AFS）"]
        WIDE["宽表化展示实体（305 张）"]
        DYNMON["错误表监控视图"]
    end
    subgraph P["门户与输出"]
        PORTAL["网银 / 移动端 / 顾问工作台"]
        OUT["通知单 / 结单"]
    end
    TXN --> TRG
    TRG --> WIDE
    TRG --> ERR
    ERR --> DYNMON
    WIDE --> PORTAL
    WIDE --> OUT

• 双 Schema 解耦：核心账本负责强一致事务，只读展示采用宽表化反范式存储，专为高并发读优化；核心实体变动经行级触发器实时单向同步至展示层。✅
• 错误隔离：大批量同步采用 DML 错误日志机制，个别脏数据被记录而不阻断整批提交，并由监控视图向运维告警。✅
• REST 接入：外部请求经队列入队/出队，令牌缓存集中管理访问令牌摘要与过期时间。✅

4.2.2 客户输出与报表

• 交易通知单：每笔买卖、换汇、大额存款或分红派息按法定格式生成成交确认函，列示执行价格、汇率、税费与起息日；支持多语言与本地化数字格式。✅
• 定期结单：季度/年度生成综合资产估值结单，覆盖资产配置、收益走势与持仓清单。✅
• 税务与费用报表：费用 NAV 支柱的对外提取、FATCA 自动报送（XML 组装）、外部税务引擎的年度申报表。✅（提取与组装）/ ⬜（报表内部逻辑）
• 保密机制：支持代保管信件（Hold Mail），物理信函转内部金库归档，仅授权人员可调阅。✅

4.2.3 监控与审计

• 不可篡改审计：对客户资料、合同关联、授权权限与系统配置的变更，在同一事务内写入审计日志，记录操作者、终端、时间与变更前后快照。✅
• 关系展开审计：对多层树状客户/合同关系递归展开角色、签署权与访问权，捕捉底层子关系上的越权授予。✅
• 监管报送：MiFID II RTS 22/24 与 EMIR 交易报送通道可证，构成对外报告面。✅
• 在线监控：同步错误表监控、违规与额度报表、费用与税务提取共同构成可观测面。✅（数据集）/ ⬜（门户实时大屏）

4.3 证据边界

• ✅ 只读展示架构、触发器同步、错误日志、REST 令牌、客户输出（通知单/结单）、审计与监管报送、税务/费用提取。
• ⬜ “实时”承诺（底层是触发器近实时同步 + 异步队列，端到端时延未取证）；门户 UI 布局与前端部署不在审计范围；具体 SLA、并发量与响应时间等历史统计不可作验收依据。

5. 通用设计要点

1. 事件驱动：税务、费用、输出均由业务事件触发，而非在交易主流程内硬编码。
2. 规则配置化：税率、豁免、费率阶梯以规则表/参数维护，换市场不改代码。
3. 两阶段解耦：先固化估值凭证（NAV 快照），再做计费与扣款。
4. 读写分离：高并发只读展示与强一致账本分离，单向同步 + 错误隔离。
5. 分部/多市场：以记账机构（BU_ID）为维度隔离规则与可见范围。
6. 全链路留痕：凭证、单据、审计与报告可追溯、可回放。

6. 术语表

1. 概述

1.1 目标

本文描述私人银行信贷与融资平台的通用需求与设计，覆盖七项核心能力：信贷与抵押品、信用风险、信贷运营、抵押贷款与不动产、信贷结构与审批、企业风险管理、风险限额管理。

平台的目标是让信贷业务在”风险规则内嵌于流程、额度与抵押品可配置、全链路可追溯“的前提下运转，而不是把风险控制留在事后稽核。

1.2 能力地图

1.3 设计原则

1. 风险规则内嵌流程：抵押、额度、偿付能力校验在单据推进前执行，越界即拦截，而非事后稽核。
2. 折算与限额可配置：抵押品折算阶梯、限额规则、压力参数以规则表/参数驱动，而非硬编码。
3. 层级额度双重约束：交易可用资金同时受子账户本地额度与母集团可用空间约束。
4. 全链路留痕：单据版本、审批记录、额度与抵押品快照全程可追溯。
5. 监管参数本地化：以瑞士 SBA/FINMA 规则为一等公民实现，并按市场替换为当地规则。

1.4 架构总览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

flowchart TB
    subgraph CLIENT["客户与顾问"]
        C["私人银行客户"]
        R["顾问 / 信贷专员"]
    end
    subgraph PROCESS["授信流程"]
        DOC["授信单据（DOC）"]
        CHK["校验与审批（4-eyes）"]
        DEC["决策与放款"]
    end
    subgraph ENGINE["风险与额度引擎"]
        COL["抵押品折算与估值"]
        LIM["额度层级与敞口"]
    end
    subgraph MON["监控与处置"]
        VIOL["保证金缺口 / 违规监控"]
        ACT["追缴 · 冻结 · 平仓 · 工单"]
    end
    C --> DOC
    R --> DOC
    DOC --> CHK --> DEC
    DEC --> COL
    DEC --> LIM
    COL --> VIOL
    LIM --> VIOL
    VIOL --> ACT
    ACT --> DOC

授信是”流程 + 引擎 + 监控“的闭环：流程负责把业务意图变成受约束的决定，引擎负责把资产与额度变成可用空间，监控负责在风险越界时把决定拉回来。

2. 信贷与抵押品（Lombard）

2.1 需求

高净值私人银行客户以投资组合中的资产质押获取流动性；银行按折价率核定借款额度；当市场下跌使抵押品缩水时，系统必须自动触发追缴、限制与平仓。✅（业务概念可证）

2.2 设计

2.2.1 质押授信与折算

客户将持有的蓝筹股、高等级债券、主权基金份额或现金作为质押物，银行按资产类型的折价率（Haircut / LTV） 核定借款信用额度。✅

2.2.2 阶梯式抵押品折算编译

针对大额抵押证券，系统采用阶梯式折算率（例如前 500 万抵押率 70%、500–2000 万抵押率 50%、超出部分 0%），防止个券集中度导致的抵押品流动性断崖。✅

编译过程读取按序号递增排序的活动 lot 累计百分比 $p_i \in [0,100]$（满足 $p_i \ge p_{i-1}$），转换为区间有效的分段比例与累计上限：

$$
d_i = \operatorname{Round}\left(\frac{p_i - p_{i-1}}{100},\ 16\right),
\qquad
CV_MAX_i = \operatorname{Round}\left(\frac{p_i}{100},\ 16\right)
$$

• 16 位精度规范：过程强制 Round(..., 16)，确保多档阶梯拆分在 16 位十进制下完全守恒、无累积漂移。✅
• 字段：DISTR（分段有效系数）、CV_MAX（该段最高覆盖率上限）、DISTR_CAP（该段最大限额资本，可选）；cap 必须指定币种、对应非零分段且为非负整数。✅
• 全量替换语义：编译成功后以结果整体替换 COLLAT_LOT_DISTR，避免新旧规则并存。✅
• 抵押品单据明细由 DOC_CREDFDM_COLLAT_DET 承载（资产列表、锁定数量、初始估值与折算后放贷价值）。✅

2.2.3 保证金缺口扫描与追缴

系统对每个授信合同计算抵押品放贷价值与保证金缺口：

$$
\text{LendingValue} = \sum_{k} \text{AssetQuantity}_k \times \text{Price}_k \times \text{EffectiveLTV}_k
$$

$$
\text{MarginDeficit} = \max(0,\ \text{TotalOutstandingDebt} - \text{LendingValue})
$$

当 $\text{MarginDeficit} > 0$ 时，系统按赤字占抵押物的比例自动在 WFC_STATUS 中切断客户账户的出金操作，并按级别生成预警记录，进而触发补仓通知（Margin Call）乃至强制平仓（Liquidation）。✅

1
2
3
4
5
6
7
8

flowchart TD
    A["质押资产：股票 / 债券 / 基金 / 现金"] --> B["按资产类型折算（Haircut / LTV）"]
    B --> C["阶梯式分段编译 COLLAT_LOT_DISTR#CMPL"]
    C --> D["可用授信额度"]
    D --> E["放款 / 出金"]
    D --> F["实时监控：市值 × 折算率 vs 借款余额"]
    F -->|足额| G["正常"]
    F -->|缺口 > 0| H["补仓通知 / 限制出金 / 强制平仓"]

1
2
3
4
5
6
7
8
9
10

stateDiagram-v2
    [*] --> NORMAL
    NORMAL --> WARNING: 市值下跌，缺口逼近阈值
    WARNING --> MARGIN_CALL: 缺口 > 0，发出补仓通知
    MARGIN_CALL --> BLOCKED: 未补仓，冻结出金与买入
    BLOCKED --> LIQUIDATION: 持续未补仓，强制平仓偿债
    MARGIN_CALL --> NORMAL: 客户补仓，缺口归零
    BLOCKED --> NORMAL: 补仓或价格回升
    LIQUIDATION --> CLOSED: 债务清偿
    CLOSED --> [*]

3. 额度层级与流动性

3.1 需求

在家族与跨国企业架构中，信用额度并非孤立分配给单一账户，而是组织为树状额度层级（Limit Hierarchy，LIHI）：母集团额度、子账户拆分额度、以及”本地额度与母层级空间”的双重约束。✅

3.2 设计

3.2.1 树状额度层级

• 母集团总额度：家族最高控股实体持有的总综合信贷上限。
• 子账户拆分额度：分配给离岸信托专户、私人投资公司（SPV）或直系亲属的独立授信额度。
• 汇总快照 LIHI_AGGR_SERPIL 保存：LIHI_FAM_ID、LIMIT_ID、PARENT_LIMIT_ID、TOP_LIMIT_ID、EXPOSURE、LIMIT_AMOUNT、LIMIT_FREE_AMOUNT、HIERARCHY_FREE_AMOUNT。✅

3.2.2 双重硬约束

对属于额度家族 $F$ 的任意子账户节点 $k$：

$$
\text{LocalFreeAmount}_k = \max(0,\ \text{LimitAmount}_k - \text{Exposure}_k)
$$

$$
\text{HierarchyFreeAmount}_k = \min\left(\text{LocalFreeAmount}k,\ \text{HierarchyFreeAmount}{\text{Parent}(k)}\right)
$$

业务铁律：交易系统下达买卖指令时，可用资金检查强制使用 $\text{HierarchyFreeAmount}$，防止下属公司各自用满本地限额而导致家族整体信用爆仓。✅

1
2
3
4
5
6
7
8
9

flowchart TB
    P["母集团总额度 10,000,000"]
    A["离岸信托 A<br/>限额 6,000,000<br/>已用 5,000,000<br/>本地剩余 1,000,000"]
    B["私人投资公司 B<br/>限额 4,000,000<br/>已用 3,000,000<br/>本地剩余 1,000,000"]
    G["母集团全局剩余 = 10,000,000 − (5,000,000 + 3,000,000) = 2,000,000<br/>任一子账户最高可动用 = min(本地剩余, 全局剩余)"]
    P --> A
    P --> B
    A --> G
    B --> G

3.2.3 日内预占与交割释放

交易日中，尚未结算的外汇与证券买卖单据预先冻结信用额度（Pre-Settlement Exposure）；一旦后台资金交割完成，系统实时释放额度占款，避免流动性虚假挤兑。✅

当证券交易或出账支付从 EXECUTED 推进至 SETTLED 时：调用额度释放过程 → 冲销日内交易对手预占敞口 → 恢复 LIHI_AGGR_SERPIL 中的可用空间。✅

信贷头寸处理队列（PRCQ_BOOK_POS_CRED_VIOL、PRCQ_BOOK_POS_CRED_BLOCK）是任务包装器：前者在信贷违反记账返回单据后置 DONE_PRC，否则 FAIL；后者按 Julian 日期判定未来日期不记账、当日或历史日期入队，返回 DONE_PRC 或 RDY_RETRY。它们只编排、不计算。✅

4. 信贷运营与产品

4.1 需求

平台应能方便地建模与实现信贷产品，覆盖复杂融资结构与复杂贷款类型。✅（产品谱可证）/ ⬜（复杂结构见 4.3）

4.2 设计

4.2.1 统一单据模型

贷款以统一业务单据（DOC）承载，单据元类型包含 LOAN；由工作流状态机管理其生命周期（草稿 → 提交 → 审批 → 执行 → 结算）。利息、续贷等作为单据组件存在，组件语义属包体边界。✅（单据模型）/ ⬜（组件内部）

4.2.2 已证实的产品谱

货币市场与证券借贷的授信可用性校验调用点（如 CHK#CREDIT_CHECK）可证，但校验内部规则不可证。✅（调用点）/ ⬜（规则实现）

4.2.3 复杂结构的实现框架（⬜）

远期贷款（forward loans）、银团贷款（syndicated loans）、担保贷款（secured loans）在全部取证文档中未出现，属产品需求。建议的实现框架是在既有模型上扩展，而非新增平行模型：

• 额度树：银团参与方份额作为额度树的参与维度；
• 抵押品组：担保贷款复用抵押品 lot 与折算阶梯；
• 参与方 / 份额：银团通过”参与方 + 份额 + 角色”记录，而非复制合同；
• 现金流组件（含远期起息）：远期贷款复用单据的现金流与起息组件。

4.3 证据边界

• ✅ 产品谱、统一单据模型、工作流生命周期、授信可用性校验调用点。
• ⬜ 远期/银团/担保贷款的产品定义与规则；利率、应计、利息分配等计算；贷款组件内部语义。

5. 抵押贷款与不动产

5.1 需求

平台应能管理不动产与不动产担保（realties and real securities）的详细信息，用于按揭的发放与管理，并通过专用模块评估经济可行性。✅（主体可证）/ ⬜（附加评估模块内部）

5.2 设计

5.2.1 产品与展期向导

不动产抵押贷款由 DOC_MORTG 承载，支持固定利率按揭、SARON 按揭与浮动利率贷款。✅

展期向导（DOC_MORTG_RENW_WZRD）：按揭到期前（例如 3 个月）自动启动，试算利息并出具有约束力的展期要约，保存 RENEW_INTEREST_RATE（新优惠利率）与 PROPOSED_TENOR_MONTHS（展期月数）。✅

5.2.2 偿付能力与 LTV

按瑞士银行家协会（SBA）与 FINMA 规范，系统执行两道审查：

① 房贷比上限

$$
\text{LTV} = \frac{\text{TotalMortgageDebt}}{\text{AppraisedPropertyValue}} \le 80%
$$

首付至少 20%，其中自筹资金至少 10%。✅

② 虚拟偿付能力（Tragbarkeit，压力测试）：强制采用 5.00% 的虚拟压力利率，并要求年化负担不超过净年收入的三分之一：

$$
\text{AnnualCost} = \text{Debt} \times 5% + \text{ScheduledAmortization} + \text{MaintenanceFee}(1%) \le \frac{1}{3} \times \text{NetAnnualIncome}
$$

越界时工作流抛出合规拦截。✅ 估值与收入基础由 DOC_HOMEFINA 的 ESTIMATED_VALUE、BORROWER_INCOME、LTV_RATIO 承载。✅

1
2
3
4
5
6
7
8
9

flowchart TD
    A["购房融资申请 / 抵押物评估 DOC_HOMEFINA"] --> B["LTV ≤ 80% 与 5% 压力利率偿付能力审查"]
    B -->|通过| C["按揭合同分段建立 DOC_MORTG<br/>固定利率 + SARON 浮动"]
    B -->|不通过| X["合规拦截并说明原因"]
    C --> D["Terravis 电子抵押设立 NETW_TERRAVIS#BUILD_1620"]
    D --> E["公证处 / 州土地局审核 → 回调 NETW_TERRAVIS#HDL_840"]
    E --> F["电子抵押证 Register-Schuldbrief 确权"]
    F --> G["解锁放款"]
    C --> H["到期前展期向导 DOC_MORTG_RENW_WZRD"]

5.2.3 Terravis 电子土地登记

平台深度内嵌了多达 72 个存储过程，与瑞士国家电子土地登记平台 SIX Terravis 点对点直连，以无纸化方式设立、变更或注销电子不动产抵押证明（Register-Schuldbrief）：构建符合瑞士电子政务 eCH 标准的 XML 报文，向公证处与州土地局发送抵押权设立申请；收到回调后更新质押证件编号，方可解锁贷款放款动作。✅

1
2
3
4
5
6
7
8
9
10
11
12
13
14

sequenceDiagram
    actor RM as 顾问 / 信贷专员
    participant Core as 核心（房贷单据）
    participant Ter as Terravis 网关
    participant Notary as 公证处
    participant Land as 州土地登记局
    RM->>Core: 发起房贷申请 + 抵押物信息
    Core->>Core: LTV 与偿付能力校验（SBA / FINMA）
    Core->>Ter: BUILD_1620 构建 eCH 标准 XML 申请
    Ter->>Notary: 提交抵押权设立申请
    Notary->>Land: 递交登记
    Land-->>Ter: 登记结果（抵押证编号）
    Ter-->>Core: HDL_840 回调更新质押证件
    Core-->>RM: 确权完成，解锁放款

5.3 证据边界

✅ 产品类型、展期向导、LTV 与压力利率规则、Terravis 过程边界与放款解锁条件。
⬜ 不动产估值口径与”经济可行性附加模块”的内部算法不在审计范围。

6. 信贷结构与审批

6.1 需求

平台应覆盖从 发起（initialization）到发放（disbursement） 的完整授信流程，服务企业与私人客户，在风险与信贷政策内运作，并追求尽可能快的决策。✅（流程可证）/ ⬜（决策速度与企业信贷细节）

6.2 设计

6.2.1 单据工作流状态机

信贷单据由通用工作流引擎驱动，标准状态为：草稿 100 → 待审批 200 → 已批准 300 → 已执行 500 → 已结算 600 → 已作废 900。校验在状态推进前执行，由校验分派器（*_DOC_VALID_DO）顺序调用各校验例程（如 CHK#MANDATORY、CHK#CREDIT、CHK#SETTLECHECK）。✅

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

stateDiagram-v2
    [*] --> DRAFT: 发起授信
    DRAFT --> SUBMITTED: 提交
    SUBMITTED --> VALIDATED: 必填 / 金额期限 / 定价 / 抵押 / 额度校验
    SUBMITTED --> REJECTED: 校验失败
    VALIDATED --> PENDING_APPROVAL: 需审批（4-eyes）
    PENDING_APPROVAL --> APPROVED: 双人复核通过
    VALIDATED --> APPROVED: 额度内免审批
    APPROVED --> DISBURSED: 放款 / 出金（占用额度）
    DISBURSED --> MONITORED: 存续监控（保证金 / 额度 / 违规）
    MONITORED --> MATURED: 到期
    MATURED --> RENEWED: 续贷
    RENEWED --> MONITORED
    MATURED --> CLOSED: 结清
    REJECTED --> [*]
    CLOSED --> [*]

6.2.2 审批校验与双人复核

• 校验分流：不同订单类型与动作对应不同校验例程；例如按揭有专用校验分派器（MORTG_RE$257_DOC_VALID_DO），抵押品有抵押品校验分派器。✅（分派调用点）/ ⬜（被调例程内部）
• 双人复核（4-eyes）：核心客户生命周期事件采用 Maker/Checker 隔离授权矩阵（如高净值开户、高风险 KYC、风险覆盖、强制清户），信贷发放遵循同一原则。✅（4-eyes 制度与矩阵）/ ⬜（信贷事件的具体授权配置）

6.2.3 发放前检查

在单据推进与支付环节，分派器会调用信贷与现金额度检查（如 PAY$6_DOC_VALID_DO 中多组动作调用 chk#credit_check、chk#cash_limit）；检查失败即抛出校验异常，阻止提交。调用点可证，检查内部的余额取数、阈值比较、占用与锁定逻辑在包体之外。✅（调用点）/ ⬜（规则实现）

6.3 证据边界

⬜ 审批的最终允许/拒绝算法、企业信贷与银团审批细节不在可读过程集合内；”最快决策”是产品目标而非文档结论。归档旧版中的信贷校验模板含存疑标记，不作验收依据。

7. 信用风险治理

7.1 需求

平台应支持对复杂融资的信用风险进行采集、评估、监控与报告，并计算关键风险计量。✅（数据与报表可证）/ ⬜（计量计算）

7.2 设计

风险治理是一个”采集 → 评估 → 监控 → 报告 → 处置”的闭环：

1
2
3
4
5
6

flowchart TB
    CAP["采集：头寸 / 抵押品 / 额度 / 单据"] --> EVA["评估：折算率 · 敞口 · 缺口"]
    EVA --> MON["监控：违规扫描与限额占用"]
    MON --> REP["报告：违规报表 · PD/LGD 矩阵 · RMC 提取"]
    REP --> ACT["处置：补仓 · 冻结 · 审批 · 工单"]
    ACT --> CAP

7.3 证据边界（重要）

• ⬜ PD / LGD / haircut 的计算不在可读过程集合内：相关聚合过程当前只做域白名单校验（仅接受有限域值），不含聚合、评分或违规计算；审计报告明确说明”信贷额度/PD/LGD、抵押品市值/haircut 的核心例程位于当前过程集合之外”。
• 🚫 不得写入：信用额度 90% 告警、担保折扣表、LCR/NSFR 等，审计将其列为”不能替代源码的旧内容“，没有可读源码或回归样本支撑。
• 当前过程范围内未发现可据以确认 AI 模型实现的证据。

8. 企业风险管理与风险限额管理

8.1 企业风险管理（Enterprise risk management）

需求：平台应能监控操作风险、信用风险与企业风险，并整合流动性风险、市场风险与信用风险分析工具。✅（信用与交易对手风险）/ ⬜（市场、流动性、操作风险的度量）

设计：

此外，监管报送通道（MiFID II RTS 22/24、EMIR）可证，构成对外报告面。✅

证据边界（重要）：VaR、Brinson、GIPS、流动性比率（LCR/NSFR）、操作风险资本模型的具体公式与阈值未在可读过程内定位，不得写入；前端流动性字段来源未证实，只能作为界面展示线索。

8.2 风险限额管理（Risk limit management）

需求：建立风险控制机制，跟踪与报告不同风险类型的内部与外部限额，并监控、控制、限制组织头寸的全部暴露。✅（内部限额）/ ⬜（外部限额）

1
2
3
4
5

flowchart TB
    SET["设定限额：层级 / 集中度"] --> OCC["占用与敞口：本地额度 + 母层级空间"]
    OCC --> MON["监控：违规扫描与额度报表"]
    MON --> CTL["控制：阻断 · 审批 · 交割释放"]
    CTL --> SET

设计：

1. 内部限额（层级）：树状额度 LIHI——母集团总额度、子账户拆分额度；LIMIT_AMOUNT / LIMIT_FREE_AMOUNT / HIERARCHY_FREE_AMOUNT / EXPOSURE。✅
2. 双重约束：交易可用资金 = min(本地剩余, 母层级剩余)，防止家族整体爆仓。✅
3. 日内预占与释放：未结算单据预占额度，EXECUTED → SETTLED 时释放。✅
4. 集中度限额：单一标的、单一发行人、非流动性资产上限（投资契约侧 DOCP_CLTA_CONCENT_RULE）。✅
5. 监控与控制：信用违规表（POS_CRED_VIOL / DOC_TAB_POS_CRED_VIOL）与违规报表；WFC_STATUS 阻断出金/买入；支付分派器调用信贷与现金额度检查（调用点可证）。✅
6. 报告：交易对手额度/敞口报表（HS$TASK_CNPRTY_LIHI_EXPO）、违规报表、PD/LGD 矩阵、RMC 提取。✅
7. 外部限额：⬜ 文档未见显式的”外部限额”建模；监管报送通道可作外部报告面，但不等同于外部限额跟踪。

9. 通用设计要点

1. 规则可配置：折算阶梯、限额规则、压力参数按市场监管参数配置，而非硬编码。
2. 双重约束优先：任何可用资金判断先取层级可用额，再看本地额度。
3. 监控闭环：违规 → 阻断 → 工单 → 补仓/解除，形成可追溯的处置链。
4. 全链路留痕：单据版本、审批记录、额度与抵押品快照均可回放。
5. 监管参数本地化：以 SBA/FINMA 与 Terravis 为参照实现，其他市场按当地规则替换。
6. 快照与报表分离：额度/抵押品报表读取既有 SERPIL 快照，不重复计算、不写回真相。

10. 术语表

11. 附录：证据锚点

本文档为产品与架构设计说明，不构成对源码审计文档的证据修订；落地实现前须核对源文件。

1. 概述

1.1 目标

本文描述私人银行数字渠道的通用需求与设计，覆盖五项核心能力：安全认证、财富总览、支付、投资建议、交易。

1.2 能力地图

1.3 设计原则

1. 读写解耦：面向客户/顾问的高并发只读展示与核心交易账本分离，展示数据由交易账本实时单向同步，避免大量查询冲击记账。
2. 安全内建：接入令牌、角色权限、不可篡改审计、传输加密与数字签名作为基础能力，而非后置补丁。
3. 合规内建：制裁名单、适销性、限额与结算校验嵌入支付、建议与交易流程。
4. 能力复用：支付、交易、绩效、建议等能力在网银、移动端与顾问工作台之间共享同一套业务规则。
5. 全链路留痕：契约、建议、签署、支付与交易全程可追溯，满足审计与合规。

1.4 架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

flowchart LR
    subgraph CHANNEL["渠道"]
        Client["客户（移动端 / 网银）"]
        RM["顾问工作台"]
    end
    subgraph ACCESS["接入层"]
        GW["API 网关 / BFF"]
        AUTH["认证与权限"]
    end
    subgraph CORE["核心"]
        LEDGER["业务单据与交易账本"]
        PAY["支付与结算"]
        TRADE["交易与撮合"]
        PROP["投资建议"]
        FRONT["前台展示服务（只读）"]
    end
    Client --> GW
    RM --> GW
    GW --> AUTH
    GW --> LEDGER
    Client --> FRONT
    RM --> FRONT
    LEDGER -. 实时单向同步 .-> FRONT
    LEDGER --> PAY
    LEDGER --> TRADE
    LEDGER --> PROP

2. 安全认证（Secure authentication）

2.1 需求

• 平台应提供可靠且准确的接入安全，且不牺牲响应速度与使用便捷性。
• 平台应支持最新的生物识别，包括人脸识别与指纹识别。

2.2 设计

• 展示与交易解耦下的安全边界：客户端经统一 REST 接口接入，请求经队列入队/出队，认证与授权在接口层完成后再进入核心账本。✅
• 访问令牌：对外部数字渠道与移动客户端的接入令牌做集中缓存，存储访问令牌摘要值与过期时间，支持令牌生命周期管理。✅
• 认证强度分级（step-up）：区分「登录级 / 查看级 / 交易级 / 高风险操作级」；支付、下单、变更受益人或权限等高风险操作要求二次认证与事务签名。⬜
• 设备与渠道绑定：令牌与设备指纹绑定，支持异常设备提示与令牌吊销。⬜
• 角色权限（RBAC）：按职责分离原则定义角色（如客户关系经理、合规官、出纳、清算、系统管理员），实行特权用户定期审查与双人审批。✅
• 不可篡改审计：对客户资料、合同关联、授权权限与系统配置的变更，在同一事务内写入审计日志，记录操作者、终端、时间戳与变更前后快照。✅
• 关系展开审计：对多层树状的客户与合同关系，递归展开角色、签署权与访问权，使仅在底层子关系上私自增加的权限也能被完整捕捉。✅
• 传输与报文安全：对报文采用强加密与数字签名；用户账号支持登录失败锁定与密码过期策略。✅

2.3 关键控制清单

3. 财富总览（Wealth overview）

3.1 需求

• 平台应提供自助式组合报告，包含财富总览——客户整体财富的快照。
• 总览应内嵌组合分析工具，让客户快速理解自身财富并采取纠偏动作。

3.2 设计

• 只读展示层：以宽表化的只读展示实体承载客户账簿、地址、支付组等视图，由交易账本经行级触发器实时单向同步；批量同步采用错误日志机制，个别异常行被捕获记录而不阻断整批提交。✅
• 财富总览聚合：基于多币种持仓与估值，汇总整体财富，包括持仓市值、本币折算市值、资产配置分布与净值走势。✅
• 组合分析工具：
  • 多层级持仓权重：按大类、货币、行业、国家穿透至个券；✅
  • 收益分析：时间加权收益率、资金加权收益率与对标基准；✅
  • 损益归因：将总损益拆分为市场纯价格变动与汇率波动，并保持恒等守恒；✅
  • 累计与年化收益率。✅
• 口径与新鲜度：每块数据携带 as-of 时间戳与估值口径（价格来源、折算汇率），避免”看似实时、实则过期”的误判。⬜
• 展示与账簿对账：定期比对只读展示与核心账簿，差异超阈值即告警并定位行级错误日志。⬜
• 纠偏动作：总览可直接衔接至再平衡与投资建议能力，使用户在看到偏离后能快速采取行动。✅（衔接机制）/ ⬜（前端交互）
• 定期结单：按季度/年度生成综合资产估值结单，包含资产配置分布、收益走势、大类收益归因与持仓清单，并以多语言与本地化数字格式呈现。✅

4. 支付（Payments）

4.1 需求

• 平台应提供本地市场的完整支付类型，包括国内与国际、SEPA、直接借记与 Scan&Pay。
• 平台应提供支付助手与支付模板，便于便捷执行多笔支付。

4.2 设计

• 统一结算模型：跨国汇款、行内转账、外汇结算与证券交割资金清算由统一结算单据覆盖。✅
• 支付类型与清算网络：
  • 出账支付：向第三方银行电汇或欧洲单一支付区清算；✅
  • 入账支付：代理行或清算所进账资金匹配到客户活期账簿；✅
  • 清算网络覆盖 SWIFT、SEPA、SIC、Fedwire、CHIPS 等；✅
  • 手续费分摊支持我方承担、收款人承担与共同分摊。✅
• 结算复制与汇率锁定：在分拆结算、冲正撤销或生成对应方交付单据时，完整复制账户、税务明细与清算路径，重算费用，并将即期汇率原子性锁定为锁定状态，避免汇率漂移。✅
• 端到端追踪：为每笔支付生成全球端到端交易参考号，支持跨行追踪。✅
• 工作流前置校验：在单据推进前集中校验账户余额、制裁名单、清算网络合规拦截、支付冲正保护与外部系统指令格式约束。✅
• 限额与授权：按客户/账户/渠道设置单笔与累计限额；超限或高风险收款人触发授权与审批。⬜（限额与授权策略属产品需求，校验框架已有）
• 幂等与重试：以端到端参考号作为幂等键，防重复提交；失败可按回执重试，避免重复扣款。⬜
• 冲正、撤销与退汇：支持撤销未清算指令、冲正已清算交易、处理退汇并回滚相关费用。✅（冲正保护机制）/ ⬜（渠道侧发起）
• 支付助手与模板：
  • 数字收款人数据集：按业务单元、日期、客户、合同、账户、收款人、昵称等条件筛选与管理收款人；✅
  • 支付组群：将多笔支付组织为组，支持批量、便捷执行；✅
  • 支付服务配置、支付扩展与支付拦截原因等以配置驱动。✅
• 直接借记：通过外部电子金融订单渠道受理直接借记等指令。✅

4.3 支付流程示例

1
2
3
4
5
6
7
8

flowchart TD
    A["客户发起支付"] --> B["工作流校验：余额 / 制裁 / 合规 / 格式"]
    B -->|通过| C["结算单据创建与费用重算"]
    B -->|拒绝| R["拒绝并提示原因，全程留痕"]
    C --> D["结算复制与即期汇率锁定"]
    D --> E["生成 UETR 端到端追踪码"]
    E --> F["清算网络报文外发"]
    F --> G["回执 / 退汇 / 冲正处理"]

4.4 支付状态与异常处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> VALIDATED: 余额/制裁/格式校验通过
    DRAFT --> REJECTED: 校验失败
    VALIDATED --> PENDING_APPROVAL: 超限额/需授权
    PENDING_APPROVAL --> RELEASED: 审批通过
    VALIDATED --> RELEASED: 免审批
    RELEASED --> SENT: 生成报文并锁定即期汇率
    SENT --> SETTLED: 收妥确认
    SENT --> RETURNED: 退汇/失败
    RETURNED --> DRAFT: 修正后重提
    SETTLED --> REVERSED: 冲正/撤销
    REJECTED --> [*]
    REVERSED --> [*]
    SETTLED --> [*]

5. 投资建议（Investment proposals）

5.1 需求

• 平台应向客户推送投资建议，为前台团队增加一条销售渠道，从而提升效率。
• 客户应能在数字渠道上签署接受建议，或提出修改意见。

5.2 设计

• 建议生成与注入：由外部投研平台生成个性化投资建议，经标准化接口提交适销性建议订单；平台在落单前自动校验客户契约风险等级与当前持仓偏离度，无违规时生成待审批建议单据。✅
• 适销性约束：建议须同时满足产品风险与客户风险等级匹配、大类配置在容差带内、单一标的/发行人集中度不超过限额；越界时拦截或报警。✅

  术语说明：本文统一使用「适销性（suitability）」，与部分文档中的「适配性」同义。

• 软预警与硬阻断：轻微偏离弹窗告警并可确认继续（留 Override 日志）；风险等级越界、无衍生品知识评估等属硬阻断，须合规签批后方可放行。✅
• 数字签署与修改：
  • 支持以数字签名方式完成签署，配合电子文档的认证与可见性控制；✅
  • 客户接受后进入后续执行流程；客户提出修改则回到待修改/待审批状态；⬜（前端状态流转）
  • 契约签署、版本升级与审批执行双人复核并全程留痕。✅
• 建议状态与版本：每份建议有版本号与失效期；推送、签署、修改、作废均可追溯。⬜
• 销售渠道与效率：建议以电子方式批量推送，前台无需逐户手工准备，从而覆盖更多客户、提升转化效率。✅（批量推送机制）

1
2
3
4
5
6
7
8
9
10
11
12

stateDiagram-v2
    [*] --> GENERATED: 投研平台生成建议
    GENERATED --> PENDING_APPROVAL: 适销性通过，待审批
    GENERATED --> BLOCKED: 适销性硬阻断
    PENDING_APPROVAL --> PUSHED: 审批通过并推送客户
    PUSHED --> SIGNED: 客户数字签署
    PUSHED --> REVISE_REQUESTED: 客户提出修改
    REVISE_REQUESTED --> GENERATED: 修改后重新生成
    SIGNED --> EXECUTING: 进入执行流程
    EXECUTING --> EXECUTED: 下单/成交
    BLOCKED --> [*]
    EXECUTED --> [*]

6. 交易（Trading）

6.1 需求

• 平台应支持广泛的自助交易能力，包括自助下单与交易跟踪。
• 平台应提供广泛的工具覆盖，从股票、债券、货币基金、私募基金、商品期货、外汇远期、掉期、期权与结构化票据（⬜ 加密资产为产品需求，未在审计文档的工具分类中列出）。

6.2 设计

• 自助下单与跟踪：交易以统一业务单据承载，并由工作流状态机管理其生命周期（草稿→提交→审批→执行→结算）；客户与顾问可自助发起并跟踪订单状态。✅
• 下单校验：余额/持仓充足性、市场时段、受制裁/受限证券黑名单与适销性校验。✅（制裁与适销性）/ ⬜（市场时段等渠道前置校验）
• 工具主数据与覆盖：按国际分类标准将工具细分为股票、固定收益债券、货币基金、私募基金、商品期货、外汇远期、掉期、期权与结构化票据；单一工具可映射 ISIN、SEDOL、CUSIP 等国际标准代码，以及各交易所本地代码与行情商代码；是否可交易由主数据控制。✅
• 行情报价：支持单位价格、票面百分比与收益率/贴现率等报价惯例，覆盖多币种、多市场的实时行情与日终官方收盘价。✅
• 订单合并池：将同一时段内多客户对同一标的的订单合并为母单执行，降低佣金、优化大额成交价格并减少市场冲击；成交后按比例分配并做残差吸收，保证多客户账单与交易所回单一致。✅
• 外汇交易：支持即期外汇（T+2 交割）、远期外汇（锁定未来汇率以套期保值）与外汇掉期；远期定价遵循利率平价模型。✅
• 货币市场：支持通知存款、定期存款/拆借与信托委托存款等流动性工具，并校验正利率、授信可用性与结算路径。✅
• 合规与确认：下单时执行受制裁/受限证券黑名单与适销性校验；成交后自动生成交易通知单，列示执行价格、汇率、税费与起息日。✅

6.3 订单状态机

1
2
3
4
5
6
7
8
9
10
11
12
13
14

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> SUBMITTED: 客户/顾问提交
    SUBMITTED --> VALIDATED: 余额/持仓/制裁/适销性校验
    SUBMITTED --> REJECTED: 校验失败
    VALIDATED --> PENDING_APPROVAL: 需人工审批
    PENDING_APPROVAL --> APPROVED: 审批通过
    VALIDATED --> APPROVED: 免审批
    APPROVED --> POOLED: 进入订单合并池
    POOLED --> EXECUTED: 母单成交
    EXECUTED --> ALLOCATED: 按比例分配与残差吸收
    ALLOCATED --> SETTLED: 交割与资金清算
    REJECTED --> [*]
    SETTLED --> [*]

7. 通用设计要点

7.1 核心原则

1. 展示与交易解耦：高并发只读展示与强一致交易账本分离，实时单向同步。
2. 安全与合规内建：令牌、RBAC、审计、加密、签名与制裁/适销性校验作为默认能力。
3. 多渠道一致：网银、移动端与顾问工作台共享同一套业务规则与数据。
4. 本地化适配：支付类型、清算网络、语言与数字格式按本地市场配置。
5. 全链路留痕：契约、建议、签署、支付与交易全程可追溯，满足审计与合规。

7.2 非功能与合规要求

7.3 术语表

1. 概述

1.1 目标

本文描述投资管理平台的通用需求与设计，覆盖三项核心能力：投资建议、监控、投资组合再平衡。文档面向产品与架构设计，只描述能力、业务规则、数据模型与流程，不绑定任何具体实现、厂商或技术栈。

1.2 能力地图

• 投资建议：客户画像与风险画像、投资契约与授权模式、组合构建、事前适销性校验、与外部投研平台的协同。
• 监控：风险-收益特征度量、资产配置与限额监控、损益归因、授信与抵押监控、按时间与客群可配置的巡检、合规监控与报送。
• 投资组合再平衡：单笔与批量再平衡、限制评估、多方法再平衡引擎、现金管理与外汇对冲。

1.3 设计原则

1. 决策与账本分离：投资决策（目标配置的生成）与持有、资金、账务（真实持仓与交割）由不同系统承担，通过标准化指令差分对接。
2. 可配置：校验规则、巡检周期、客群范围、再平衡方法与门槛均以配置驱动，而非硬编码。
3. 可追溯：契约、建议、审批、再平衡版本与最终单据全程留痕，支持回溯与审计。
4. 解耦：外部系统只发布「目标与差额」，平台依据客户个性化持仓与真实账户资金生成可落地的交易。

2. 投资建议（Investment Advice）

2.1 需求

• 平台应支持将投资适销性检查、组合构建与风险分析自动化。
• 平台应支持基于客户风险画像与战略资产配置快速设定并维护客户画像。
• 投资活动应严格遵循客户与机构签署的投资契约及合规适销性约束。

2.2 设计

2.2.1 投资契约与授权模式

以具有法律约束力的**投资政策声明（Investment Policy Statement，IPS）**作为投资授权的载体，记录投资目标、风险偏好、投资期限、损益底线、业绩基准与有效期。系统支持三类授权模式：

2.2.2 风险画像与资产配置蓝图

采用两层资产配置蓝图：

• 第一层——战略/战术资产配置（SAA / TAA）：设定各大类资产（股票、固收、另类、流动性）的基准配置比例，并给出允许浮动的容差带（Corridor）。
• 第二层——模型投资组合（Model Portfolio）：将宏观大类比例细化为具体标的的目标权重，每个标的给出下限 / 最优目标 / 上限三段区间。

目标权重可由外部投研平台批量同步，也可由内部模型生成。

2.2.3 事前适销性校验

订单录入时，由流程引擎触发事前自动校验，逐层判定「产品风险是否匹配、大类配置是否越界、集中度是否超限」：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

flowchart TD

Order[新录入订单] --> RiskCheck{产品风险等级 <= 客户风险等级？}

RiskCheck -- 否 --> Warning[拦截交易 / 要求客户签署风险自担声明]

RiskCheck -- 是 --> CorridorCheck{调仓后大类比例是否在容差带内？}

CorridorCheck -- 否 --> BreachAlert[报警：偏离基准配置范围]

CorridorCheck -- 是 --> ConcentCheck{单一标的风险暴露 <= 集中度上限？}

ConcentCheck -- 否 --> RejectOrder[强制阻断：触犯集中度限制]

ConcentCheck -- 是 --> Pass[放行并推进订单]

大类比例漂移校验：订单执行后的预期大类权重为

$$w_{post} = \frac{V_{class,current} + \Delta V_{order}}{NAV_{portfolio}}$$

并满足约束 $\text{MinWeight}{class} \le w{post} \le \text{MaxWeight}_{class}$；越界时由流程引擎抛出带宽越界异常并阻断。

集中度限额按规则类型管理：单一标的集中度、单一发行人集中度、非流动性资产上限；每条规则配置最大允许持有比例。

2.2.4 与外部投研平台的协同

• 外部投研平台负责生成个性化调仓建议，并通过标准化接口提交「适销性建议订单」；平台在落单前校验客户风险等级与当前持仓偏离度，无违规时生成待审批建议单据。
• 外部平台下发的资产级预交易合规门槛，与内部契约限制项做一致性对账。
• 客户与外部投研平台之间建立唯一映射，外部测算的风险指标（如预期短缺、年化波动率）可回写至客户档案，供后续分析与展示使用。

2.2.5 组合构建与治理

• 客户、自然人、合同/账户三层模型解耦：客户为法律/经济主体，自然人为生物个体（承载国籍、税务居民地、政治敏感人物、实益拥有人信息），合同为投资与结算关系载体。
• 支持批量将最新模型投资组合挂接至客户组合。
• 契约签署、版本升级、双人复核审批（4-Eyes）由异步流程驱动并留痕。

3. 监控（Monitoring）

3.1 需求

• 平台应能优化并监测风险-收益特征，确保其处于既定风险偏好之内。
• 平台应支持设置按时间与客群（分段）可配置的健康检查，覆盖从资产配置监控到组合风险的全过程。
• 监控结果应可输出为报告并满足合规报送要求。

3.2 设计

3.2.1 风险-收益特征度量

采用国际通行的投资业绩计量口径（如 GIPS）：

• 时间加权收益率（TWRR）：剔除外部资金进出影响，衡量投资管理能力。将现金流按业务分类（出入金、红利、税款、交易手续费、利息等）分别计算日收益因子并链式累乘：

$$F_{g} = \prod_{t \in g} f_{t}$$

• 资金加权收益率（MWRR / IRR）：纳入资金进出的时点权重，反映客户实际回报。构建按天加权的净现金流：

$$NCF = \sum_t NCF_{t}, \qquad WNCF = \sum_t (\Delta\mathrm{days}t + timing_t) \times NCF{t}$$

其中日初现金流计时因子取 1、日终取 0。

• 多层级持仓权重：支持按大类、货币、行业、国家穿透至个券的树状权重分析；分母为零时输出空值而非零。
• 组合离散度：衡量同一策略模型下不同客户组合的收益分化，仅在样本净值大于零且有效成员数达到门槛时对外发布。
• 累计与年化收益率：对月度收益率序列 $r_k$，

$$C_j = \prod_{k=1}^{j}(1+r_k), \qquad R_{cum,j}=C_j-1, \qquad R_{ann,j}=C_j^{12/j}-1$$

历史每日收益率、累计因子与对标基准写入时间序列表，用于报告与图表输出。

3.2.2 配置监控、组合风险与损益归因

• 资产配置监控：在线校验 SAA/TAA 容差带与集中度限额；支持对客户持仓做批量合规扫描。
• 损益归因：将投资总损益拆分为「市场纯价格变动」与「汇率波动」两部分，汇兑损益以残差方式推导，保证恒等式成立：

$$Profit_{mkt} + Profit_{fx} \equiv Profit_{total}$$

以多币种折算不产生分钱级悬空差额。

• 额度与授信风险：额度按树状层级组织，子账户动支同时受本地额度与上级剩余空间双重约束：

$$\text{LocalFree} = \max(0,\ \text{Limit} - \text{Exposure})$$

$$\text{HierarchyFree}_k = \min(\text{LocalFree}k,\ \text{HierarchyFree}{parent})$$

后台交割完成时实时释放日内预占敞口。

• 抵押品与追缴监控：抵押品按阶梯折算率编译为高精度分段比例；保证金赤字

$$\text{MarginDeficit} = \max(0,\ \text{TotalDebt} - \text{LendingValue})$$

赤字为正时触发补仓通知、限制出金或强制平仓。

• 净值与费用监控：为每个计费周期生成每日逐笔净值估值快照，作为阶梯式管理费、托管费、业绩报酬与顾问费的计提依据；快照完整性状态用于阻断不完整的计费。

3.2.3 按时间与客群可配置的健康检查

巡检能力建立在统一的任务/队列框架之上。可配置性体现在两个维度：

• 时间维度：期间起止、调度周期、计费周期、运行日期。
• 客群/对象维度：业务单元隔离、重点客户名单、按对象分片并行。

实时合规监控由异步队列承担：客户信息或交易对手变化时，实时与制裁名单比对，命中即阻断单据进入交割。

3.2.4 结果输出与报送

• 客户结单与交易通知单等输出由统一输出管理生成。
• 满足监管报送要求（如交易类 T+1 报送、场外衍生品存续与估值上报）。
• 所有变更由审计与权限体系留痕。

4. 投资组合再平衡（Portfolio Rebalancing）

4.1 需求

• 平台应支持单笔与批量（mass）再平衡，并集成限制评估。
• 平台应提供20 余种再平衡方法，涵盖策略再平衡、外汇对冲、现金管理，以及单资产与多资产再平衡。

4.2 设计

4.2.1 决策分工与两层蓝图

• 投资委员会 / 首席投资官：制定战略资产配置（SAA），并定期微调战术资产配置（TAA）。
• 多资产投资组合管理团队：将大类比例转化为模型投资组合，选定具体标的并赋予目标权重。
• 外部投研/组合管理平台：作为投资决策来源，输出目标配置与调仓差额。
• 投资管理平台核心账本：作为真实持仓、资金与报送来源，依据目标差额与真实账户资金生成可落地交易。

外部平台通过标准化协议发布「目标与差额」，平台对账后更新目标权重。

4.2.2 执行流水线

再平衡引擎采用确定性多阶段流水线：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

flowchart TD

Holdings[当前持仓] & Target[目标配置] --> DriftCalc[1. 偏离度测算 ΔV / ΔQ]

DriftCalc --> MultiCont[2. 多账户候选调拨]

MultiCont --> MultiContEval[买入/卖出跨账户可用性排序]

MultiContEval --> UnitRound[3. 交易单位规整与门槛过滤]

UnitRound --> Sweep[4. 现金扫账]

Sweep --> Validation[5. 工作流前置校验]

Validation --> OrderGen[6. 建议单据生成]

OrderGen --> Pool[分发至交易撮合池]

• 阶段一：偏离度与调仓差额试算

$$\Delta V_i = (W_{target,i} \times NAV_{total}) - V_{current,i}, \qquad \Delta Q_i = \frac{\Delta V_i}{Price_i}$$

$\Delta V_i>0$ 触发买入（需检查流动性），$\Delta V_i<0$ 触发卖出（需调取可变现头寸）。

• 阶段二：多账户流动性调配：在家族/关联账户群中计算跨子账户的现金与头寸可用性。

• 阶段三：交易单位规整与门槛过滤：将小于市场最小撮合单位的零碎挂单向上规整为整数倍；低于配置门槛的挂单静默抑制，避免无意义碎单与高额手续费。

• 阶段四：现金扫账：对配置了百分比扫账的账户，将超过流动性保留比例的富余现金转入高流动性工具：

$$Balance_{target} = \frac{p}{100} \times NAV \times FX$$

• 阶段五：前置校验：账户/合同未处于司法或合规冻结；模型权重满足归一化 $\sum W_{target,i} = 100%$；标的无陈旧价格与停牌；杜绝非授权做空。

• 阶段六：建议单据生成：形成待审批批次，确认后拆包为标准交易订单进入撮合池。

4.2.3 再平衡方法库与计算模式

引擎支持可配置的再平衡计算方法与行情快照模式：

• 计算方法：完全按权重重置、现金优先渐进平衡、偏离度绝对值优先。
• 行情模式：即时现价、官方前收盘价、加权均价。

在上述模式下，覆盖的再平衡方法家族包括：

4.2.4 限制评估

再平衡在计算阶段即携带契约个性化风控输入：

• 个券黑名单、大类排除（如符合特定教法或 ESG 约束的排除清单）；
• 特定账户类型的资金防火墙（如免税账户禁止跨账户借调资金）。

提交前由校验分派器执行舍入、多账户、组合/模型、链接组、冻结状态、零余额、空头/符号变化与陈旧价格检查；限制评估结果持久化保存。

4.2.5 单笔、批量与版本化

• 单笔与批量：既支持账户级单笔再平衡，也支持再平衡矩阵批量操作，由再平衡动作、再平衡日期、成本来源、资产排除等配置驱动；支持以文件上传等方式触发批量再平衡。
• 版本化持久化：每个再平衡版本保存汇总指标、组合头寸、证券交易、外汇交易与限制评估明细；采用替换式保存，并以生成单据标识关联最终落地交易。

5. 更低成本的顾问服务（Lower cost of advice）

5.1 需求

• 平台应支持以规模化的批量再平衡与批量监控，在不牺牲客户体验的前提下降低顾问服务成本。

5.2 设计

• 规模化批量再平衡：一次为大量账户生成调仓订单，经订单合并池统一挂牌与成交，摊薄交易佣金、买卖价差与市场冲击成本。
• 规模化批量监控：按时间与客群批量执行配置、限额与风险巡检，替代逐户人工核对，降低运营成本。
• 不牺牲客户体验：每笔成交仍按各自子订单比例精确回填，利息、税费与佣金按交易币种精度分摊，客户账单独立、准确、可追溯。

6. 订单合并池（Order Pooling）

6.1 需求

• 平台应支持将同一时段内多个客户对同一标的的买卖指令合并为一个母单执行，以降低佣金、获取更优的大额成交价格并减少市场冲击。
• 母单成交后，平台应按各子订单比例精确回填成交量，并按币种精度分摊应计利息、交易税费与经纪佣金。
• 平台应执行严格的防超配校验，杜绝分配数量符号翻转（买变卖、超额卖出）。
• 全链路金额应满足守恒，分摊后总和精确等于外部成交回报，实现零分钱误差。
• 平台应与外部投研/风险平台保持订单生命周期与敞口的双向同步。

6.2 设计

6.2.1 对象模型

1
2
3
4
5
6
7
8
9
10

flowchart TD
    A[客户子订单 A] --> Chk[入池兼容性校验 18+3]
    B[客户子订单 B] --> Chk
    C[客户子订单 C] --> Chk
    Chk --> Master[合并主订单 挂牌/成交]
    Master --> Mkt[市场成交回报]
    Mkt --> Alloc[按比例分配 + 防超配校验]
    Alloc --> A2[子订单 A 分配 费用/利息]
    Alloc --> C2b[子订单 B 分配]
    Alloc --> C2[子订单 C 分配 尾数吸收]

6.2.2 入池兼容性校验

子订单加入母单池时，执行 18 项无条件一致性校验 + 3 项条件分支校验：

• 18 项无条件校验：目标市场、多市场交易能力、标的证券、市场交易币种、结算币种、汇率设定、倒签标志、订单类型组、订单子类型、到期日、限价、触发价、冰山单可见数量、数量/金额驱动标志、跨品种调仓标志、前台受理实体、交易对手方合同、托管传播模式。
• 3 项条件校验：市价单有效性约束；特定托管传播模式要求合同完全一致；另一类托管传播模式要求客户完全一致。

6.2.3 池剩余量动态扣减

子订单入池时按驱动方式扣减母单可用量：

• 数量驱动池：$Q_{pool} := Q_{pool} - Q_{member}$
• 金额驱动池：$G_{pool} := G_{pool} - G_{member}$

6.2.4 市场成交分配与防超配

市场分笔成交后，对已挂单总量执行防超配校验：

$$Q_{after} = Q_{market} - Q_{linked} - Q_{placed} - Q_{newAlloc} - Q_{diffPool}$$

不变量守恒律：若 $Q_{after} \ne 0$ 且其符号与 $Q_{market}$ 相反，系统立即拒绝本次分配并回滚，杜绝买变卖或超额卖出。

6.2.5 比例分摊与残差吸收

非末尾池成员按绝对数量占比计算权重（保留高精度浮点，不做向下截断）：

$$w_i = \left| \frac{q_i}{Q_{abs}} \right|$$

各项金额按交易币种资产精度舍入：

$$AccruedInterest_i = \mathrm{Round}{curry}(-AccruedInterest{market} \times w_i)$$
$$CashToReceive_i = \mathrm{Round}{curry}(-CashToReceive{market} \times w_i)$$
$$Cost_{i,b} = \mathrm{Round}{curry}(Cost{market,b} \times w_i)$$

尾数吸收：最后一个池成员承接全部计算剩余值，使分摊总和精确等于市场总清算账单：

$$\text{Amount}n = \text{Total}{market} - \sum_{i=1}^{n-1} \text{Amount}_i$$

6.2.6 市场分配传播与外部对账

• 市场分配传播：母单成交后，按市场与托管关系将成交量与金额传播到各子订单，并执行上述尾数吸收，保证多客户账单与交易所回单一致。
• 外部对账：对外部投研/风险平台发起或受其监控的订单，平台在异步单据补充分派中做双向对账——记录外部接口状态、状态时间戳，并透传代理资产，确保跨市场代理挂单在外部风险账本中保持实时敞口同步；该机制同样适用于外汇远期、利率掉期与期权等产品。

6.2.7 与规模化降本的关系

订单合并池是「更低成本的顾问服务」的执行底座：批量再平衡一次产生的大量子订单经入池合并后统一成交，摊薄佣金、价差与冲击成本；同时大批量监控保证分配与费用分摊依然逐客户准确、可对账，从而在不牺牲客户体验的前提下实现规模化降本。

7. 通用设计要点

1. 决策与账本分离：外部决策系统只发布目标与差额，平台依据客户个性化持仓与真实资金生成落地交易。
2. 两层目标蓝图：宏观大类容差带与个券模型权重分层继承与校验，避免将配置简化为单一标签。
3. 配置驱动：规则、巡检、方法与门槛均可配置，适配不同客群与监管辖区。
4. 全链路留痕：契约、审批、再平衡版本与最终单据可回溯，满足审计与合规报送。
5. 精度与守恒：多币种与费用计算保持明确的舍入口径，关键恒等式（如损益拆分）保持守恒，杜绝分钱级悬空差额。

《介绍 System One 模型与 Jev》— 中文翻译

Reinforcement Learning

原文：Introducing System One Models & Jev 作者：Diogo Almeida，TypeSafe AI 创始人 发布日期：2026 年 9 月 出处：https://typesafe.ai/blog/introducing-system-one-models-and-jev，Diogo Almeida，创始人，TypeSafe

介绍 System One 模型与 Jev

语言模型在聊天上超越人类已有多年，那么自动化究竟在哪里？

这是我过去四年一直在追问的问题。在 OpenAI 时，我参与构建了让语言模型能够有效遵循指令、与人对话的方法。那项工作最终成为了 ChatGPT 背后的研究。当时我以为，也许聊天模型会通向 AGI，但尽管炒作不断，我越来越清楚地意识到：真正重要的东西缺失了。

在隐身模式（stealth）下度过两年、经历无数技术挑战与研究突破之后……我无比激动地宣布：今天，TypeSafe AI 发布我们的首个 System One 模型——一类全新的前沿模型，专为做出软件可以直接使用的、快速而结构化的决策而构建。

我们构建了一套全新的、完全聚焦于自动化（automation）的技术栈：全新的模型架构、追求最高效率的并行采样器，以及一种我们称之为”校准决策强化学习（Reinforcement Learning for Calibrated Decisions，RLCD）”的训练方法。

我们的首个公开模型是 Jev，今日开放早期访问。在 System One 类任务上，Jev 达到了与现有 LLM 相近的智能水平，同时快两个数量级、效率高出两个数量级。虽然 Jev 放弃了字符串生成（string generation），但它针对结构化输出做了优化，并且不可能产生幻觉。

把 Jev 想象成一个前沿智能的函数调用：输入非结构化状态（unstructured state），输出带类型的概率化决策（typed probabilistic decisions）。

非同寻常的主张需要非同寻常的证据，所以请看下文中的”收据”。

前沿，旧与新

证据 / 技术结果

我们喜欢怀疑者，我们自己就是怀疑者。

有些主张你可以轻松验证：

• 单次调用速度： 我们确实有那么快，尽管我们公布的评测通常是在西海岸的笔记本电脑上跑的（我们的服务目前也部署在那里）。
• 单次调用成本： 我们让定价透明。我们无法证明它没有被补贴；我们需要长期来证明我们定价的可持续性（我们预期价格会下降，而不是上涨）。
• 无类型错误： 这本来很容易用一个反例就证伪，但它在数学上是不可能的。

对于那些更大胆的主张，我们希望尽可能提供细腻的说明。

并排演示

我们的并排演示展示了我们模型与 LLM 之间的一个关键差异：Jev 并行地输出所有概率，而不是自回归地逐 token 生成。字符串极其强大而通用，但代价高昂。”放弃”字符串实际上赋予了我们许多超能力！

细节说明

• 对于拥有 TypeSafe 早期访问权限的人，这里是实际查询。
  • 该查询被高度简化，questions 被特意设计为带有描述性的、人类可读的键，以便屏幕上的输出易于理解。
  • state 也是一段简短、密集、详细的文字，以强调采样方法上的差异。相对更短的输入让我们的模型显得更有优势。
• 对于眼尖的人：在录制的这次运行中，唯一与 GPT-5.6 Terra 的分歧在于”流失可能性等级（Churn likelihood level）”。在我们看来，那个真实答案确实是模棱两可的。
• 此例中我们使用默认推理设置下的 GPT-5.6 Terra，因为我们发现它在平均智能水平上与 Jev 最具可比性。
• 有趣的事实：一个类似的演示，正是让我们决定全力押注 System One 模型方向的原因！

工作流评测

我们创造了一种新型评测，用来衡量 AI 在代码内部工作的效果。我们不针对某个标准答案分类做优化，也不允许评测框架和模型发生变化（那可能通过”评测框架工程”导致过拟合）。相反，我们假设存在一张正确的计算图（一个用代码表示的”工作流（workflow）”），并以最大、最聪明、最昂贵的外部模型的预测作为参考概率。

换种说法：每个模型拿到相同的工作流。我们测试它们与最聪明模型（在此例中是 Astra 和 Fable）的平均值相比表现如何。

Jev 高得离谱——几乎在横跨两个数量级的范围内占据帕累托前沿（Pareto frontier）。我们也与那些把全部逻辑写进思维链（chain-of-thought）的提示词模型做了比较，但这类做法通常显著差于直接使用工作流本身。

注意，这里的调用比上面的并排演示要复杂得多。因为它们更能代表真正实现业务自动化所需的生产级工作负载。下面是我们公布的 4 条工作流中最简单的一条：

最可靠的现实世界工作流，往往包含许多相互独立的、分解后的问题，其细粒度行为依赖于概率而非离散决策。最终结果是离散的分支，但我们要得到最终答案，涉及大量必须高度一致地完成的领域特定工程。

详见我们的工作流评测网站：示例、分歧、完整查询，以及每条工作流。

细节说明

• 我们首页上”快 193.6 倍、便宜 444.6 倍”的主张正来源于此，我们预期这些数字处于真实世界收益的偏高端。
• 这些工作流的内容并非为了让我们模型显得好看而刻意挑选或构造，也不在我们的训练分布中。不过，它们是由我们模型能力团队的成员制作的，因此可能存在一些偏差。
• 我们使用 GPT-6 Astra 与 Fable 5.1 的平均值作为参考答案，这会使答案偏向 OpenAI 和 Anthropic 的模型。我们很可能低估了自家模型以及 DeepSeek 系列模型的相对表现。
• 这些 LLM 使用我们的 System One LLM 封装，该封装将 LLM 约束为输出与我们 API 兼容的结构化决策。我们发现这是从 LLM 获取决策的最准确方式，但这往往比不带概率地给出决策更慢、更贵。

幻觉与类型安全

幻觉与类型安全本质上相关，我们认为后者是自动化的入场券。一个产生幻觉的工具调用，在 Agent 里只是不便；但如果它是一个有延迟保证的系统的一部分，或者埋在依赖链的好几层深处，那就是绝对的致命伤。现有模型无论多聪明，仍会产生幻觉并出现类型错误。

细节说明

• LLM 的数字来自 OpenRouter，也就是说这里几乎肯定存在偏差：更复杂的查询可能被路由到更好的模型。
• 我们的数字不是经验性的。模式匹配（Schema matching）是有保证的，因此我们可以自信地在图中加入 0%。

有趣的演示

也许我们工作中最激动人心的部分，是开启新的用例。我们还有更多东西要展示给你，但以下是团队最喜欢的几个：

Doom

我们很喜欢这个 doom（毁灭战士）演示，它展示了实时智能，以及代码 + AI 能做到什么。背后的工程师曾担心每秒 10 次查询（最终约合 $7/小时的费用），但我们其余人都认为这比预期更低！它实在太有趣了，我们不仅打算发布一份深入的分步讲解，还打算举办一些活动来一起 hack 它。

细节说明

• 该演示基于作为数据结构（含文本）的结构化状态，而不是图像（目前还不支持）。
• 一个非 AI 的 doom bot 可能打得更好，但我们想要一个能对不同表示形式的游戏状态做出反应的 bot，而最重要的是……遵循指令实在太酷了！

Wikiracing（维基竞速）

这个游戏的目标是：从一个维基百科页面出发，仅使用你在浏览中遇到的链接，到达另一个指定的维基百科页面。每一步都可能意味着在数百到数千个链接中做选择！这是绝佳的试验场，不仅展示”每秒智能”，还展示在高基数选择下不产生幻觉所带来的复利收益。

细节说明

• 据我们所知，第 2 和第 3 个挑战都以”Rubber Duck”开头纯属随机。作者是在团队指出后才注意到的。
• 我们在这里的提速往往远小于之前的演示。因为这是在与模型的非推理模式竞争（Astra 除外，它被设为最低推理档）。这也是为什么 Jev 往往用更少的步数完成（智能更高的标志）。这样做是为了让演示更便于观看。若开启推理，这些 LLM 在此任务上的表现会差得多。
• Jev 支持最高 255 的基数。对于更高的基数选择，我们采用两阶段系统：先独立打分，再做出显式选择，因此偶尔会有变慢。

下一步

我们仍处在 Jev 的早期阶段。我们还有大量产品在管道中，非常兴奋能够持续发布 🔥。

今天，我们开放早期访问，并尽可能快地把开发者从等待名单上放出来。我们想知道你需要自动化哪些决策、Jev 在哪些地方好用、在哪些地方不足。告诉我们你想构建什么样的科幻！

我们创办 TypeSafe，是因为我们相信 AI 需要一个软件可以依赖的接口。我们迫不及待地想看到新的用例*持续扩散（continuously diffuse）*到社区与经济之中。

我们也有 FAQ

“System One 模型”和”Jev”这两个名字从何而来？

我们受到了 Daniel Kahneman 的《思考，快与慢》（Thinking, Fast and Slow）启发。模型类名取自快速、直觉的”系统 1（System 1）”思维与缓慢、审慎的”系统 2（System 2）”推理之间的区分。

“系统 1 思维”也一直隐含着”容易出错”之意。出于我们未来会展开的原因，我们相信 System One 模型可以被做得比其他替代方案更可靠。

我们用 William Stanley Jevons 来命名 Jev。我们预期机器智能会走上与煤炭相似的路径——蒸汽机效率提升最终导致了对煤炭需求的增加。智能成本每下降一个数量级，就会解锁多出几个数量级的用例。

为什么需要一种新的训练算法？

每个实验室在基于人类反馈的强化学习（RLHF）阶段优化的都是同一个任务：产出人类评分者更偏爱的文本。对于聊天产品来说，这是正确的任务；但对于自动化来说，这是错误的任务。这就是我们所说的”最苦涩的教训（bitterest lesson）”：为正确的任务做优化，比数据、算力或算法都更重要。

RLVR 对于可用简单程序化验证的任务非常出色，但现实世界中大多数判断任务并不符合那种形态。这往往会导致尖刺式／不稳健的智能（spikey / non-robust intelligence）。

Jev 适合哪些用例？

我们已经在各行各业发现了 Jev 的多样化用例。我们在文档中列出了一些，也非常期待看到开发者们还能构建出什么。

Jev 只是一个更小的 LLM 吗？

Jev 既不”小”，也不是一个 LLM，因此它才会脱离智能的帕累托曲线。

Jev 在公开基准上表现如何？

我们刻意选择不公布在公开基准上的表现。事实上，我们计划只在做产品更新时发布一次性的评测（one-off evals）。

既然我们正在为模型开辟一片新前沿，我们就在推动一些更有用的最佳实践：

• 不要给公开基准任何权重。
• 鼓励用户为自己的用例创建自己的评测（System One 任务要容易评估得多）。
• 披露你评测中的细微之处。
• 即便你领先时，也要淡化基准的重要性。

关于我们围绕”为基准做优化”的哲学，见我们关于此话题的博文。

我们的训练数据从何而来？

TypeSafe 首先是一家数据研究实验室，而 AI 领域最重大的成果正是这样诞生的。所有数据都由我们自己制作。即便你要求，我们也不会拿你的数据来训练（无意冒犯）。我们做了一些相当复杂的事情，但如果你想了解更多，我们恐怕得把你招进来。

这些结果有点疯狂——怎么可能做到？

见我们关于”AI 最苦涩的教训”的博文。简短的回答是：你优化什么，就得到什么。LLM 被优化成出色的聊天机器人和副驾驶，这让它们在那类人在回路任务上超越人类。而我们优化的，是 System One 接口。