AI Treasury / Liquidity / ALM Forecasting / Stress Evidence Architecture 解读

面向对象: CBAP+ Financial Retail PM / Senior BA / Treasury Product Architect / ALM Architect / Risk Data Product Lead / Model Risk Partner / Enterprise Architect / Board MI Owner。 核心问题: 金融机构如何把 AI 用在 treasury、liquidity forecasting、deposit beta/runoff、cash-flow ladder、ALM、IRRBB、FTP、portfolio scenario、stress testing、contingency funding 和 board MI 中, 同时让每个预测、压力假设、人工覆盖和资金行动都可解释、可追溯、可挑战、可审计? 学习目标: 建立 treasury/ALM 预测不是 generic prediction modeling 的心智模型, 形成 forecast-to-action architecture、stress evidence graph、model risk controls、committee operating model、data lineage、board MI 和面试可表达的产品架构语言。

---

0. Disclaimer

本文是学习、作品集和架构训练材料, 不构成法律意见、监管意见、流动性充足性结论、资本充足性结论、会计处理意见、模型验证报告、审计结论、投资建议、融资建议、风险偏好批准或应急融资执行建议。

正式项目必须由 Treasury、ALM、Finance、Risk、Model Risk、Legal、Compliance、Regulatory Reporting、Information Security、Data Governance、Architecture、Internal Audit、Business Line、Operations 和董事会/管理层授权委员会共同判断。具体适用范围、监管口径、报告义务、模型治理要求、数据使用限制和披露要求由 Legal / Compliance / Regulatory Affairs / Model Risk 等权责方确认。

本文把官方材料转成产品和架构训练语言。不要把任何 AI forecast、scenario output 或解释图直接视为流动性行动许可。资金调拨、批发融资、资产出售、hedging、FTP 调整、产品定价变更、客户沟通和 contingency funding action 必须走机构批准的 human committee、dual control、limit、policy 和 evidence process。

---

Source Anchors

访问日期: 2026-06-30。

一句话:

AI Treasury Architecture is not "predict tomorrow's balance". It is a governed forecast-to-action and stress-evidence system for liquidity survival, ALM decisions, FTP incentives and board challenge.

---

1. Thesis

Treasury / Liquidity / ALM 场景中的 AI 预测, 不能按普通 demand forecast 处理。普通预测的中心问题是:

What value will happen next?

Treasury/ALM 的中心问题是:

Under which balance-sheet, rate, customer, market, legal-entity and operational conditions
will the institution have enough usable liquidity,
at what cost,
with what management actions,
and what evidence proves that the assumptions were understood, challenged and acted on?

成熟架构的变化是:

from: spreadsheet cash position + static ALM model + committee slide pack
to: data-lineage-backed forecast + scenario/stress engine + model-risk controls
    + ALCO decision workbench + contingency action register + board MI evidence graph

AI 的价值不是替代 Treasurer 或 ALCO。AI 的价值是把以下能力产品化:

1. 更快识别 deposit behavior、payment flow、collateral、funding market 和 rate scenario 的变化。
2. 把 NMD beta、runoff、cash-flow ladder、NII/EVE、FTP、portfolio mix 和 CFP trigger 放在同一个 scenario fabric 中。
3. 用 probabilistic forecast、stress overlay、driver decomposition 和 uncertainty interval 支持行动选择。
4. 把人工覆盖、committee challenge、限额状态、action rationale 和后验表现保存在同一条证据链。
5. 让董事会看到的不是模型分数, 而是 liquidity position、stress survival horizon、assumption changes、control effectiveness 和 management action。

核心原则:

Treasury AI should recommend insight, not execute liquidity.
Forecast precision without action governance is operational risk.
Stress output without assumption lineage is weak evidence.
Deposit beta without segment and scenario is a dangerous scalar.
ALM model output without committee challenge is not decision architecture.
Board MI without source-to-action traceability is presentation, not oversight.

---

2. Treasury / ALM Domain Mental Model

Treasury/ALM 架构要同时处理四类不确定性:

Treasury/ALM 的关键对象不是单一时间序列, 而是 balance-sheet graph:

customer / counterparty
  -> account / product / legal entity
  -> contractual cash flow
  -> behavioral cash flow
  -> funding source / funding need
  -> collateral / encumbrance
  -> liquidity buffer
  -> scenario / stress assumption
  -> limit / risk appetite
  -> committee decision
  -> management action
  -> board evidence

2.1 Liquidity, ALM, IRRBB, FTP 的边界

PM/Architect 要把这些域连接起来, 但不能混成一个黑箱模型。

---

3. Why AI Changes Treasury Architecture

AI 对 treasury/ALM 的改变, 不是"更复杂模型更准"。真正变化在于: 预测、压力、解释、行动和证据的周期变短。

AI 同时放大风险:

• False comfort: 模型给出平滑 P50, 掩盖尾部流动性风险。
• Procyclicality: 模型根据近期流出提高假设, 触发过度收缩或激励错配。
• Explainability gap: ALCO 无法解释为什么 deposit beta 或 runoff assumption 改变。
• Data leakage: 使用事后可见的余额调整、pricing campaign 或 exception data 训练当时不可见的预测。
• Model misuse: 短期 cash forecast 被拿去支持长期 ALM 或 FTP 决策。
• Automation bias: 委员会接受 AI scenario ranking, 没有独立 challenge。
• Evidence break: 董事会看到的 survival horizon 无法追溯到数据版本、模型版本、scenario version 和人工覆盖。

高级设计的目标不是消除 judgment, 而是让 judgment 结构化、可挑战、可复盘。

---

4. Reference Architecture

source systems
  core deposits / loans / cards / payments / wires / ACH / treasury trades
  GL / product pricing / CRM / client concentration / collateral / securities
  market rates / yield curves / macro / competitor rates / news-event signals
  legal entity / regulatory reporting / limits / committee records

-> as-of data product layer
     balance snapshots
     cash-flow events
     deposit behavior features
     rate and market data
     collateral and encumbrance
     customer / segment / legal-entity mapping
     data quality and lineage

-> AI and analytics layer
     baseline forecasts
     deposit beta and runoff models
     cash-flow forecasting
     anomaly / early-warning signals
     scenario generator and stress overlays
     challenger models
     explanation and driver decomposition

-> treasury risk engines
     liquidity ladder
     stress survival horizon
     ALM / IRRBB NII and EVE engines
     FTP simulation
     portfolio scenario engine
     contingency funding capacity

-> decision layer
     ALCO / Treasury Risk workbench
     limit and trigger monitor
     action recommendation with constraints
     human committee challenge
     dual-control action registration

-> evidence and MI layer
     forecast contract
     model inventory
     scenario version
     data lineage
     override record
     action log
     board MI pack
     audit evidence export

4.1 Architecture Capabilities

4.2 Canonical Data Entities

---

5. Forecast Contracts: 预测必须绑定决策

Treasury AI 的第一个产品产物不是模型, 而是 Forecast Contract。

示例:

Forecast contract: retail NMD runoff under rate-up and confidence shock
grain: day x product x segment x legal entity
horizon: 30 / 90 days
outputs: P50/P90 runoff, beta estimate, segment contribution, top depositor concentration effect
decision use: ALCO review, liquidity buffer monitoring, FTP sensitivity, pricing strategy challenge
action boundary: no automatic funding action; red status triggers ALCO/Treasury Risk review
evidence: as-of deposit data, pricing offers, competitor rate feed, model version, scenario version, overlay reason

---

6. Deposit Beta And Runoff Architecture

Deposit beta 不是一个全行常数。Runoff 也不是余额时间序列外推。更成熟的模型对象是:

deposit behavior under a specified rate, confidence, relationship and liquidity scenario

6.1 Segmentation Logic

6.2 Beta / Runoff Model Portfolio

6.3 设计原则

---

7. Cash-Flow Forecasting And Liquidity Ladder

Cash-flow architecture 要同时区分四种 cash flow:

Liquidity ladder 不应只展示 net cumulative cash flow。它至少要展示:

opening liquidity
+ expected inflows
- expected outflows
+ usable liquidity sources
- encumbered / trapped / operationally unavailable liquidity
- stress runoff and contingent outflows
= survival horizon and buffer surplus / shortfall

7.1 Liquidity Ladder Design Table

---

8. ALM / IRRBB Integration

AI treasury forecast 必须进入 ALM/IRRBB 架构, 但不能吞掉 ALM discipline。

8.1 AI 在 ALM 中的合理角色

8.2 NII / EVE / Liquidity 的组合视角

8.3 IRRBB Assumption Register

---

9. FTP And Portfolio Scenario Architecture

FTP 是把 Treasury insight 变成业务激励的桥。没有 FTP, AI liquidity forecast 容易停留在风险报告; 有错误 FTP, 业务线会被错误激励。

9.1 FTP Decision Table

9.2 Portfolio Scenario Loop

business growth plan
  -> forecast deposit / loan / commitment / securities trajectory
  -> apply rate and liquidity scenarios
  -> calculate liquidity ladder, NII, EVE, FTP charges
  -> identify incentive mismatch and limit pressure
  -> propose portfolio / pricing / funding actions
  -> committee challenge and approval
  -> monitor actual behavior against scenario

PM implication:

The product manager for treasury AI is not optimizing model accuracy. They are aligning product growth, funding cost, contingent liquidity, ALM risk and management action through a traceable scenario loop.

---

10. Stress Evidence Architecture

Stress testing 的架构价值在于证据链, 不是情景数量。

10.1 Scenario Taxonomy

10.2 Stress Evidence Graph

scenario_id
  -> assumption_id
       -> source_data_version
       -> expert_judgment_record
       -> model_output_id
       -> overlay_id
  -> liquidity_ladder_result
  -> ALM / IRRBB result
  -> FTP / portfolio result
  -> limit status
  -> committee challenge
  -> management action
  -> board MI metric
  -> post-event backtest / lessons learned

10.3 Evidence Pack

---

11. Explainability: 从"模型解释"到"行动解释"

Treasury/ALM explainability 不是给 SHAP chart。它要回答六个行动问题:

1. 为什么 liquidity outlook 变差?
2. 哪些 segment、product、legal entity、currency、payment rail 或 depositor group 贡献最大?
3. 变化来自真实行为、市场利率、模型版本、数据质量、场景参数还是人工覆盖?
4. 这个变化对 cash position、survival horizon、NII、EVE、FTP 和 limits 的影响分别是什么?
5. 哪些管理行动可用, 每个行动的速度、成本、约束和副作用是什么?
6. 委员会为什么接受、调整或拒绝 AI 建议?

11.1 Explainability Layers

Memory rule:

Explainability for treasury AI = why the number changed + why the action is or is not justified.

---

12. Human Committee And Decision Rights

Treasury AI 要嵌入 committee operating model, 不是绕过它。

Decision boundary:

AI can detect, forecast, explain, simulate, draft and recommend.
AI should not independently approve liquidity risk appetite, execute emergency funding,
change FTP policy, sell assets, alter customer pricing, or declare regulatory adequacy.

---

13. Board MI Architecture

Board MI 必须从 production facts and evidence 生成, 不是 quarterly manual slide assembly。

13.1 Board Metrics

13.2 Board Tile Example

Decision topic: Retail deposit runoff and liquidity buffer under 90-day combined stress

Status: Amber
Driver: digital savings and money-market deposit runoff P90 increased by 18% vs last quarter.
Evidence: competitor-rate spread widened; top-50 depositor concentration unchanged; model challenger agrees directionally but lower magnitude.
Impact: survival horizon down from 54 to 43 days under combined stress; NII downside increases under high-rate retention strategy.
Management action: ALCO approved targeted retention pricing for operational relationship segments, no broad promotional campaign; FTP charge updated for high-rate promotional balances.
Controls: model limitation noted for new digital-only cohort; human overlay approved for 60 days; validation backtest scheduled after next month-end actuals.
Decision requested: Board Risk Committee to note amber status and challenge management on CFP dry-run completion.

---

14. PM / BA / Architect Implications

Minimum product artifacts:

---

15. Anti-Patterns

---

16. Interview-Ready Language

Q1: How would you design AI for treasury liquidity forecasting without making it a black-box model?

30 秒版本:

I would not start with a model. I would start with forecast contracts tied to treasury decisions: daily liquidity positioning, ALCO monitoring, CFP triggers, FTP sensitivity and board MI. The architecture needs as-of data lineage, deposit behavior features, scenario library, baseline plus challenger models, ALM/IRRBB integration, human committee workflow and an evidence ledger that links data, assumptions, outputs, overrides and actions.

2 分钟版本:

In treasury, the risk is not just forecast error; it is using a forecast for the wrong decision. I would separate cash-flow forecasting, deposit beta/runoff, ALM/IRRBB assumptions, FTP and stress testing into connected but governed services. Each forecast has a contract: grain, horizon, decision use, allowed action, explainability and evidence. For deposit behavior, I would model beta and runoff by product, segment, relationship, concentration and rate regime, with uncertainty and challenger models. The output feeds a liquidity ladder, ALM NII/EVE engine, FTP simulation and ALCO workbench. No AI output directly executes funding or pricing actions; committee challenge, dual control, limit checks and evidence capture are part of the product.

Q2: What is the difference between generic forecasting and treasury/ALM forecasting?

30 秒版本:

Generic forecasting predicts a value. Treasury/ALM forecasting supports liquidity survival, balance-sheet strategy, rate risk, FTP incentives and contingency actions under scenarios. The unit of design is not a time series; it is forecast-to-action with assumptions, stress, limits, committee challenge and evidence.

Q3: How would you handle deposit beta and runoff assumptions?

30 秒版本:

I would reject a single bank-wide beta. I would build an assumption register by product, segment, relationship depth, concentration and rate regime, with historical evidence, uncertainty, challenger model, stress overlay and ALCO approval. The assumption is a governed object, not a hidden model parameter.

Q4: What evidence should be available for a board liquidity metric?

30 秒版本:

The board metric should trace to a metric contract, source systems, data cutoff, quality checks, model and scenario versions, assumptions, overlays, committee challenge, threshold, management action and closure status. If we cannot replay the number, it is not mature MI.

Q5: Where do NIST AI RMF, ISO 42001 and SR 11-7 fit?

30 秒版本:

I use SR 11-7 for model risk discipline: inventory, validation, monitoring, effective challenge and model uncertainty. I use NIST AI RMF for Govern/Map/Measure/Manage across AI risk, and ISO 42001 for the operating system: roles, policy, performance evaluation, internal audit and continual improvement. Exact applicability remains Legal/Compliance/Model Risk-owned.

---

17. Final Memory Card

Treasury AI = forecast-to-action + stress evidence + human committee.

Good architecture proves:
  what was forecast,
  why it changed,
  which scenario and assumptions were used,
  which liquidity / ALM / FTP / board metric was affected,
  who challenged it,
  what action was approved or rejected,
  and whether actual outcomes later supported the decision.