AI 扩展计划 / Playbooks
AI Core Banking Modernization / Strangler / Evidence Playbook
面向 CBAP+ 金融零售 Senior PM、Senior BA、Solution Architect、Enterprise Architect、Core Banking Transformation Lead、Data Migration Owner、Technology Risk、Operational Resilience、Internal Audit、Vendor Management
691 行AI_CORE_BANKING_MODERNIZATION_STRANGLER_EVIDENCE_PLAYBOOK.md
AI Core Banking Modernization / Legacy Strangler / Evidence Architecture Playbook
面向 CBAP+ 金融零售 Senior PM、Senior BA、Solution Architect、Enterprise Architect、Core Banking Transformation Lead、Data Migration Owner、Technology Risk、Operational Resilience、Internal Audit、Vendor Management 和核心包/主机现代化团队。本文不讲基础 BA 访谈和普通需求模板, 而是把 AI、产品、解决方案架构和企业架构放在同一个现代化控制面里, 训练你设计可分阶段迁移、可对账、可回滚、可审计、可运营、可解释客户影响的核心银行 modernization program。
核心判断:
核心银行现代化的主线不是“旧核心到新核心”的技术搬迁, 而是“事实源、客户影响、运营责任和审计证据”的受控迁移。
本文是学习、作品集和内部架构训练材料, 不构成法律意见、监管解释、合规结论、审计意见、会计处理结论、供应商选型建议、迁移批准或生产 cutover 指令。正式项目必须由机构授权的 Business Owner、Technology Owner、Data Owner、Risk、Compliance、Legal、Finance、Operations、BCP、Third-Party Risk、Internal Audit 和 Vendor 结合业务、合同、牌照、司法辖区和内部政策确认。
访问日期: 2026-06-30。
1. Source Anchors
| Anchor | Official link | 本 playbook 使用方式 |
|---|---|---|
| FFIEC Architecture, Infrastructure, and Operations IT Handbook | https://ithandbook.ffiec.gov/it-booklets/architecture-infrastructure-and-operations/ | 用 enterprise architecture、data flow diagrams、technology assets、change、operations、monitoring、resilience、third-party oversight 设计 modernization control plane。 |
| FFIEC Development, Acquisition, and Maintenance IT Handbook | https://ithandbook.ffiec.gov/it-booklets/development-acquisition-and-maintenance/ | 用 development / acquisition / maintenance governance、risk management、testing、change control 和 vendor acquisition 组织核心包、主机改造与新平台建设。 |
| FFIEC Management IT Handbook | https://ithandbook.ffiec.gov/it-booklets/management | 用 governance、risk management、enterprise architecture、project management、monitoring/reporting、quality assurance 支撑转型责任和管理层汇报。 |
| FFIEC Business Continuity Management IT Handbook | https://ithandbook.ffiec.gov/it-booklets/business-continuity-management | 用 BIA、risk assessment、continuity strategy、BCP、training、exercise、maintenance、board reporting 组织 cutover、rollback、degraded mode 和恢复演练。 |
| NIST SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems | https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final | 用 systems security engineering 视角设计可信系统边界、生命周期、交互、失效模式和可生存性。 |
| NIST SP 800-218 Secure Software Development Framework | https://csrc.nist.gov/pubs/sp/800/218/final | 用 SSDF 的 secure SDLC 语言组织代码、配置、供应链、测试、漏洞和缺陷响应。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 定义 AI 在核心现代化中的用途边界、风险度量、人工复核和持续改进。 |
| ISO/IEC 42001 AI management systems | https://www.iso.org/standard/81230.html | 用 AI management system 的责任、运行控制、绩效评价和持续改进管理 AI-assisted modernization。 |
2. Executive Framing
核心银行现代化 program 通常同时面临四种压力:
- 业务压力: 新产品、实时服务、开放银行、个性化、费用和利率策略、渠道体验被旧核心 release cycle 卡住。
- 技术压力: 主机人才稀缺、batch window 紧张、接口脆弱、数据结构历史包袱重、核心包升级慢。
- 风险压力: 客户余额、交易、利息、费用、账务、报表、投诉、审计证据不能出错。
- 转型压力: 管理层希望看到现代化进展, 但 big-bang replacement 的风险过高。
高级 playbook 的目标不是押注某个银弹, 而是设计一套 transition architecture:
legacy estate
-> controlled coexistence
-> strangled capabilities
-> target platform and core package integration
-> evidence-backed source-of-truth transfer
-> legacy retirement by capability
2.1 成功标准
| 维度 | 低成熟度成功标准 | 高成熟度成功标准 |
|---|---|---|
| Scope | 新核心上线 | 每个 capability 的 source-of-truth、运营责任和证据责任完成迁移 |
| Data | 数据装载完成 | population manifest、mapping、DQ、reconciliation、exception closure 可证明 |
| Channels | 接口打通 | 渠道通过 ACL 使用稳定 intent API, 不吸收新旧核心差异 |
| Risk | 测试通过 | customer harm scenarios、rollback、BCP、parallel-run、control evidence 达标 |
| AI | AI 提高效率 | AI 辅助受治理, 不拥有核心事实、写入、cutover 和审计结论 |
| Audit | 项目文档归档 | evidence architecture 支撑查询、复盘、监管问询和管理层报告 |
3. Modernization Decision Matrix
核心现代化不是只有 replace。常见选项应按 capability、风险、收益、供应商约束和证据成熟度组合使用。
| Pattern | 适用场景 | 优点 | 风险 | Gate |
|---|---|---|---|---|
| Encapsulate / Wrap | 旧能力仍稳定, 但渠道需要 API 化 | 快速降低渠道耦合 | 只包接口不改语义会固化旧复杂性 | ACL contract、semantic mapping、operational SLO |
| Rehost / Replatform | 技术基础设施过旧, 业务语义暂不变 | 降低基础设施风险 | 业务能力没有现代化 | Performance, DR, security, batch equivalence evidence |
| Refactor | 局部代码和规则可控 | 降低维护风险 | 对隐式规则理解不足 | Rule mining、unit/regression evidence、SME approval |
| Core package extension | 新核心包适配特定产品/地区 | 利用供应商能力 | 参数和定制可能形成新 legacy | Parameter governance、vendor release impact |
| Strangler by capability | 业务能力可拆, coexistence 可控 | 分阶段释放价值 | 需要强 ACL、recon 和运营编排 | Slice readiness、source-of-truth registry、rollback |
| Big-bang replacement | 规模小、产品少、旧系统简单或监管窗口允许 | 结束 coexistence | 风险集中、rollback 困难 | Exceptional approval、full rehearsal、BCP proof |
高级判断:
对复杂金融零售机构, strangler 常是主线, package replacement 常是目标平台的一部分, ACL / evidence / reconciliation 是降低 coexistence 风险的核心能力。
4. Core Constraint Inventory
启动前先建立约束清单, 不要先画目标架构。
| Constraint domain | 必查对象 | 关键问题 | Evidence |
|---|---|---|---|
| Products | 存款、贷款、卡、透支、费用、利率、优惠、豁免、历史产品 | 哪些规则隐含在核心参数、批处理或人工 SOP 中 | Product rule catalog、parameter extract、exception list |
| Accounts and customers | CIF、账户、joint account、relationship、KYC、状态、冻结、限制 | 客户和账户状态是否一对多、多对多、跨系统冲突 | Entity relationship map、source-of-truth register |
| Transactions | posting、pending、reversal、adjustment、hold、chargeback、fee | 金额、币种、日期、顺序、幂等、冲正语义如何表达 | Transaction taxonomy、sequence evidence |
| Ledger | subledger、GL、settlement、suspense、interest accrual | 新旧账务是否能每日、月末、期末对齐 | Ledger mapping、GL reconciliation |
| Batch | 日终、月终、计息、收费、对账、报表、文件传输 | 哪些时间窗口不可打断, 哪些任务有上游下游 | Batch dependency graph、critical path |
| Interfaces | 渠道、CRM、支付、卡、征信、报表、数据仓库、供应商 | 谁直接读写旧核心, 哪些字段被外部误用 | Interface inventory、consumer impact |
| Data quality | 历史编码、缺失、重复、格式漂移、手工修复 | 哪些数据迁移前必须清理或例外披露 | DQ profile、defect backlog |
| Operations | 柜面、客服、后台、财务、投诉、风险、催收 | Coexistence 时员工看哪个系统, 如何解释差异 | SOP, training evidence, unified workbench plan |
| Vendor | 核心包、系统集成商、主机服务商、云、数据工具 | 环境、接口、批量、补丁、支持时限、退出条款 | Contract controls、SLA、release calendar |
5. Capability Slicing Model
不要按组织架构切, 也不要按数据库表切。用 business capability + data fact + operational responsibility 切。
5.1 Slice Candidate Table
| Slice | 适合先迁信号 | 需要谨慎信号 | 典型策略 |
|---|---|---|---|
| Customer profile read | 读多写少, 可容忍 freshness 标注 | KYC / consent / privacy 强耦合 | Read replica + canonical profile API |
| Product catalog / pricing display | 参数可抽取, 规则可版本化 | 费用和利率直接影响账务 | Product rule registry + human-approved publication |
| Statement / transaction search | 历史查询压力大, 写入少 | 实时 pending / dispute 状态复杂 | Event capture + searchable read model |
| Alerts and servicing tasks | 可作为运营辅助, 不直接改账 | 错误任务会误导员工 | Workflow strangler + case evidence |
| Fee waiver workflow | 独立审批和回写点清晰 | 费用账务和客户承诺敏感 | Draft/approve/write via policy-gated ACL |
| Deposit account opening | 新账户路径可隔离 | 需要 KYC、funding、card、statement、GL 集成 | New capability + core account creation adapter |
| Loan servicing changes | 高业务价值 | 还款计划、利息、征信、催收耦合强 | Shadow calculation and long parallel run |
| Posting engine / ledger | 现代化收益大 | 客户余额和 GL 风险最高 | Shadow ledger before controlled cutover |
5.2 Slice Readiness Score
| Criterion | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| Business value | 主要技术债 | 明确运营效率或渠道价值 | 直接释放收入、风险控制或战略产品能力 |
| Coupling | 与核心 posting、batch、GL 深耦合 | 有可隔离接口 | 可通过 ACL 清晰隔离 |
| Data readiness | 源数据混乱, DQ 未知 | 已有 profiling 和主要缺陷 | 有 manifest、DQ profile、lineage 和 fix path |
| Test oracle | 结果难以判定 | SME 可抽样判断 | 可自动对账, 有 golden scenarios |
| Operational readiness | SOP 不清 | 可通过培训支持 | 有 workbench、runbook、queue、escalation |
| Rollback feasibility | 回退不可行或损失大 | 可手工补救 | 可恢复路由、重放事件、补偿交易 |
建议先选择总分高但 ledger 风险中低的 slice, 用它打磨 ACL、evidence、reconciliation 和运营模型。
6. Reference Architecture
Digital / branch / contact center / partner channels
|
v
Experience orchestration and workflow layer
|
v
Anti-corruption layer
intent API | canonical model | entitlement | validation | policy | idempotency
|
+--------------------------+--------------------------+
| | |
v v v
Legacy core estate Modernized services Core package platform
mainframe / batch / account, product, deposit, loan,
COBOL / package workflow, ledger servicing modules
| | |
v v v
Event capture and CDC Shadow / active ledger Vendor adapters
batch extract, journal, read models, commands parameter, batch,
file, API events and workflow state API, file exchange
\__________________________|__________________________/
|
v
Control and evidence plane
source-of-truth registry
migration manifest
mapping decision record
reconciliation engine
cutover command log
customer harm monitor
AI assist evidence
audit / regulatory evidence pack
6.1 Architecture Principles
No direct channel dependency on legacy semantics.
No source-of-truth transfer without registry update and approval.
No core write without policy, idempotency, trace and recovery path.
No migration without population manifest and reconciliation.
No cutover without customer harm monitoring and rollback authority.
No AI suggestion without source citation, owner review and usage boundary.
No vendor black box without evidence obligations and exit path.
7. Anti-Corruption Layer Contract
ACL 是核心现代化的产品化边界, 不是技术临时层。
| Contract area | Must define | Evidence |
|---|---|---|
| Intent API | 业务动作名称、输入、输出、错误码、幂等键、权限、风险等级 | OpenAPI / AsyncAPI、consumer approval、version history |
| Canonical model | 核心实体、字段语义、状态机、金额精度、日期语义、as-of time | Model registry、decision log、lineage |
| Mapping rules | legacy field / package field 到 canonical / target 的规则 | Mapping table、rule owner、sample tests |
| Validation | 输入合法性、业务规则、risk policy、customer harm guardrail | Rule suite、policy decision log |
| Idempotency | 重复请求、重放、超时恢复、队列 drain | Idempotency key spec、replay test |
| Sequencing | event ordering、batch cutover、transaction priority | Sequence contract、late event handling |
| Error handling | 技术错误、业务拒绝、未知状态、人工升级 | Error taxonomy、runbook |
| Evidence | trace、event、source snapshot、approval、side effect | Evidence event schema、retention profile |
7.1 ACL Write Tiers
| Tier | Example | Allowed path | Control |
|---|---|---|---|
| Read only | account inquiry、transaction search | read replica or legacy read adapter | Freshness and entitlement |
| Draft | fee waiver draft、servicing note draft | new workflow only | Human approval before any core effect |
| Low-risk write | preference update、non-financial note | policy-gated ACL | Idempotency, audit log, rollback note |
| High-risk write | fee reversal、hold release、limit change、account closure | dual control or explicit approval | Approval, side-effect id, recon |
| Ledger-impacting write | posting、interest adjustment、loan schedule change | restricted command path | Formal change authority, reconciliation, rollback plan |
8. Canonical Model and Event Capture
8.1 Canonical Objects
| Object | Minimum semantics | Common traps |
|---|---|---|
| Customer | identity, relationship, segment, KYC status, consent, vulnerability flag | 把 CIF 当唯一客户真相, 忽视 joint / household / business relationship |
| Account | account id, ownership, product, status, open/close dates, restrictions | 状态码跨系统语义不同 |
| Balance | ledger balance, available balance, pending, holds, as-of time, currency | 没有 as-of time 和 freshness 导致客户误解 |
| Transaction | authorization, posting, reversal, adjustment, fee, interest, source channel | 把 authorization 和 posting 混为一谈 |
| Product | product code, terms, fees, rates, eligibility, effective date | 旧产品代码和当前产品目录断裂 |
| Loan schedule | due date, principal, interest, escrow, delinquency, payment hierarchy | 提前还款、追溯调整、催收状态复杂 |
| Hold / restriction | reason, scope, start/end, legal/regulatory basis, release rule | 错误释放或错误保留造成客户伤害 |
| GL mapping | subledger account, GL account, cost center, legal entity, period | 客户账和财务账对不上 |
8.2 Event Capture Contract
| Field | Purpose |
|---|---|
event_id | 全局唯一事件标识 |
event_type | account.opened, transaction.posted, fee.assessed, interest.accrued, hold.placed |
source_system | legacy core、core package、workflow、adapter |
source_record_ref | 源记录、batch、journal、file、API call 指针 |
business_time | 业务发生时间或生效日期 |
capture_time | 捕获时间 |
as_of_time | 数据快照时间 |
sequence | ordering / replay 控制 |
idempotency_key | 去重和恢复 |
schema_version | 事件契约版本 |
evidence_hash | 源证据或 payload hash |
8.3 Read Replica Rules
| Rule | Reason |
|---|---|
| 每个 read model 显示 freshness 和 source | 防止员工或客户把副本当实时核心 |
| 高风险客户影响答案必须引用 source and as-of | 支持投诉、争议和审计 |
| Replica 不执行核心写入 | 防止绕过核心控制 |
| Replica 缺失时有 degraded mode | 保障客服和运营可继续安全工作 |
9. Shadow Ledger and Parallel Run
9.1 Shadow Ledger Use Cases
| Use case | Why shadow ledger helps | Exit criteria |
|---|---|---|
| Deposit interest | 验证日计息、月结、利率阶梯、例外利率 | 多个周期差异在 tolerance 内, 差异已分类和关闭 |
| Fee assessment | 验证费用触发、豁免、退费、税费 | 样本和全量对账达标, 客服解释一致 |
| Loan payment allocation | 验证本金、利息、罚息、费用、escrow 顺序 | 还款计划和余额差异可解释 |
| Holds and restrictions | 验证冻结、释放、可用余额影响 | 客户伤害场景无重大差异 |
| GL projection | 验证 subledger to GL mapping | 日终和月末对账达标 |
9.2 Reconciliation Dimensions
| Dimension | Examples |
|---|---|
| Balance | ledger balance、available balance、principal、interest、escrow |
| Transaction | count、amount、type、status、posting date、effective date |
| Product rule | rate、fee、waiver、limit、eligibility |
| Customer/account status | active、closed、frozen、delinquent、charged-off |
| GL | debit/credit、legal entity、cost center、suspense |
| Operations | case status、manual adjustment、approval state |
| Customer impact | rejected transaction、wrong fee、wrong statement、complaint |
9.3 Break Taxonomy
| Break type | Root cause candidate | Owner |
|---|---|---|
| Data defect | 源数据缺失、历史编码、重复、手工修复 | Data Owner |
| Mapping defect | 字段、状态、产品代码、日期、金额精度映射错误 | Data Architect / BA |
| Rule defect | 利息、费用、还款、状态机规则理解错误 | Product SME / Architect |
| Timing defect | batch、event sequence、as-of、late arriving data | Integration Architect |
| Vendor defect | 核心包参数、API、batch extract、环境问题 | Vendor Manager |
| Operational defect | 人工调整、SOP、审批或培训问题 | Operations Lead |
| Evidence defect | trace、manifest、approval、hash、recon record 缺失 | Evidence Owner |
10. Migration Evidence Factory
把 migration 当成 evidence factory, 不要当成一次性 ETL。
| Stage | Evidence artifact | Acceptance |
|---|---|---|
| Population selection | migration population manifest | 范围、排除项、记录数、金额总计、hash、owner 明确 |
| Source extraction | source snapshot certificate | extract time、batch id、file checksum、record count、retention class |
| Data profiling | DQ profile and defect list | 缺失、重复、异常、历史编码、不可迁移项分类 |
| Mapping | mapping decision record | 字段、状态、规则、产品参数、SME approval、sample evidence |
| Transformation | transformation run manifest | code version、parameter version、input/output counts、error report |
| Load | target load evidence | load id、target count、rejects、retry、environment |
| Reconciliation | recon report | tolerance、break count/value、aging、materiality、owner |
| Exception handling | exception register | 每个例外有 business decision、risk acceptance 或 fix evidence |
| Approval | migration signoff pack | Data、Business、Tech、Risk、Ops、Finance 按范围签署 |
| Retention | evidence retention record | 保存位置、访问控制、保留期限、legal hold path |
10.1 Data Migration Guardrails
| Guardrail | Why |
|---|---|
| Source extract freeze must be explicit | 防止源数据继续变化导致对账失效 |
| Population manifest before transformation | 防止范围漂移 |
| Mapping changes require version and regression | 防止最后一刻改映射破坏已验证结果 |
| Rejects must be business-classified | 技术 reject 可能代表客户影响 |
| Recon tolerance must be pre-approved | 上线当天临时放宽 tolerance 是红色信号 |
| Manual adjustment needs maker-checker | 防止人工补数成为风险入口 |
| Migration evidence must be queryable by account/customer/product | 事故和投诉需要快速定位 |
11. Cutover, Downtime and Rollback
11.1 Cutover Strategy Table
| Strategy | 适用场景 | 优点 | 风险 | Required evidence |
|---|---|---|---|---|
| Blue/green routing | 渠道可路由, 能快速回切 | 回滚快 | 数据写入一致性难 | Route log、dual-write policy、replay plan |
| Phased cohort | 按员工、分行、地区、产品、客户 cohort 逐步迁 | 风险分散 | Coexistence 复杂 | Cohort manifest、customer impact monitor |
| Business-date cutover | 按日终/月末切 | 对账语义清楚 | downtime / batch window 压力 | Freeze proof、batch completion、GL recon |
| Read-first cutover | 先切读, 后切写 | 降低风险 | 双读差异会影响客服 | Freshness disclosure、read recon |
| Shadow-to-active ledger | shadow 达标后切 active posting | 信心高 | 切换点和历史重放复杂 | Shadow scorecard、activation approval |
| Big-bang | 能力小或环境简单 | 快速结束旧系统 | 风险集中 | Full rehearsal、BCP、rollback proof |
11.2 Cutover Command Log
每个 cutover command center 应记录:
- 时间线、执行人、审批人、观察员。
- 前置检查、环境状态、批处理状态、供应商状态。
- 数据 freeze、queue drain、routing change、smoke test、reconciliation checkpoint。
- 决策点、异常、风险接受、rollback 判断。
- 客户影响、投诉、交易失败、余额差异、运营队列。
- 恢复普通运营的批准证据。
11.3 Rollback Decision
Rollback 不是技术脚本, 是企业决策。
| Trigger | Decision owner | Required action |
|---|---|---|
| Balance variance above materiality | Migration Authority + Finance | Stop affected capability, preserve evidence, assess customer impact |
| High-risk write uncertainty | Technology Owner + Risk | Disable write path, switch read-only or manual-first |
| Customer-visible misinformation | Business Owner + Customer Ops | Stop impacted journey, issue corrected script, monitor complaints |
| Vendor package critical defect | Vendor Manager + Tech Owner | Activate vendor escalation, route around or rollback |
| Evidence loss for Tier 1 flow | Evidence Owner + Risk | Stop or downgrade affected flow, local capture, preservation hold |
| BCP dependency failure | BCP Lead + Command Center | Move to pre-approved degraded mode |
Rollback plan 必须说明:
- 恢复到哪个 source-of-truth 状态。
- 已进入新路径的交易如何补偿、重放或人工处理。
- 客户通知和客服脚本如何更新。
- 财务、对账、报表如何处理 cutover window。
- 证据如何 preserved, 哪些日志进入 hold。
12. Customer Harm Control Checklist
| Harm | Pre-cutover control | Runtime signal | Remediation |
|---|---|---|---|
| Wrong balance | Full balance recon, high-risk account sampling | Balance variance, customer inquiry spike | Freeze affected accounts, manual review, corrected communication |
| Duplicate posting | Idempotency test, queue drain proof | Duplicate detection, recon breaks | Reverse duplicate, notify ops, root cause fix |
| Missing posting | Sequence and replay test | Pending aging, transaction count mismatch | Replay or manual post with approval |
| Wrong fee | Fee engine shadow run | Fee complaint, fee variance | Refund/waive with approval and root cause |
| Wrong interest | Interest shadow calculation | Interest variance by product | Correct adjustment and customer explanation |
| Transaction decline | Eligibility and hold mapping test | Decline rate spike | Route rollback or manual override path |
| Lost servicing case | Case migration recon | Case backlog, SLA breach | Restore case, prioritize affected customers |
| Wrong statement | Statement sample and period close recon | Statement suppression / correction events | Corrected statement process |
PM 高级表达:
我不会把客户伤害当上线后的运营问题, 而是把它前置为 cutover gate、monitoring signal 和 remediation playbook。
13. Vendor / Core Package Integration
核心包现代化常见误区是把 vendor platform 当成目标架构答案。真正需要管理的是 vendor 的语义、配置、接口、证据和运营责任。
| Vendor area | Control question | Evidence |
|---|---|---|
| Product parameters | 参数如何表达本机构产品规则、历史例外和未来变更 | Parameter workbook、approval、diff report |
| API / file interface | 接口语义、错误码、幂等、重试、版本如何治理 | Interface contract、test evidence |
| Batch and calendar | 核心包日终、月终、节假日、时区如何处理 | Batch calendar、run evidence |
| Data extract | 数据抽取字段、时间、完整性、重跑能力 | Extract manifest、checksum |
| Upgrade / patch | 供应商 release 是否影响映射、参数、API、证据 | Release impact assessment |
| Environment | 测试、parallel-run、performance、DR 环境是否足够 | Environment readiness report |
| Support | cutover window 响应、严重问题升级、SLA | Support plan、contact tree |
| Exit / portability | 数据、配置、证据如何导出 | Exit plan、data portability test |
13.1 Vendor Evidence Clauses
核心现代化合同和 SOW 应明确:
- 交付物不只包含配置和接口, 还包含 mapping evidence、test evidence、runbook 和 operational support。
- 供应商必须支持 parallel-run 数据抽取、reconciliation、defect triage 和 root cause evidence。
- 供应商环境和支持窗口必须覆盖 cutover rehearsal、production cutover 和 stabilization。
- 供应商缺陷分类、修复 SLA、patch regression 和 release note 必须进入项目证据链。
14. AI Assist Operating Model
14.1 Safe AI Use Cases
| Use case | How AI helps | Control |
|---|---|---|
| Requirements mining | 从需求、SOP、Jira、监管材料、供应商文档抽取规则、冲突和未决问题 | Source citation, reviewer, conflict log |
| Legacy code understanding | 解释 COBOL、copybook、JCL、batch dependency、SQL、参数文件 | Read-only access, code reference, SME validation |
| Mapping suggestion | 建议 legacy to canonical / target mapping | Mapping owner approval, sample tests, version |
| Data profiling narrative | 总结 DQ patterns、异常、边界样本 | Data classification, reproducible query |
| Test generation | 生成边界场景、negative tests、parallel-run comparison cases | QA selection, golden set, no self-approval |
| Cutover rehearsal analysis | 聚合演练日志、耗时、错误、dependency delay | Runbook owner review, time-stamped evidence |
| Defect clustering | 将 recon breaks / UAT defects 聚类为根因候选 | Issue owner confirms closure |
| Runbook copilot | 帮 command center 检索步骤、联系人、历史问题和判断依据 | Read-only, cited runbook version, no autonomous action |
14.2 AI Must Not Own
| Prohibited ownership | Reason | Enforced by |
|---|---|---|
| Final migration decision | 涉及事实迁移、客户影响、财务和风险接受 | Steering / Migration Authority signoff |
| Unreviewed core writes | 可能改变余额、状态、费用、额度和客户权利 | Tool gateway, policy, approval, dual control |
| Customer-impacting cutover | 涉及服务中断、通知、交易和投诉 | Command center, BCP authority |
| Source-of-truth changes | 改变事实责任和审计边界 | SoT registry workflow |
| Reconciliation closure | 关闭差异代表接受事实和风险 | Recon owner and materiality policy |
| Compliance / audit conclusions | 需要授权角色判断 | Human approval and disclaimer |
| Customer remediation decision | 影响补偿、通知和客户权利 | Business, Legal, Compliance, Customer Ops |
14.3 AI Evidence Fields
| Field | Purpose |
|---|---|
ai_use_case_id | 追踪 AI 辅助场景 |
source_refs | 证明建议基于哪些文档、代码、数据 |
prompt_version | 复现 AI 辅助过程 |
model_id | 模型和供应商追踪 |
reviewer_id | 人工复核责任 |
approved_use | AI 输出被批准用于什么 |
rejected_reason | 防止错误建议被重复采纳 |
linked_artifact | 映射、测试、缺陷、runbook 或决策记录 |
15. Evidence and Control Matrix
| Control ID | Control objective | Control activity | Evidence | Owner | Gate |
|---|---|---|---|---|---|
| CBM-001 | 现代化范围和事实责任明确 | 建立 capability inventory and SoT registry | Capability map, SoT registry | EA / Data Owner | Program initiation |
| CBM-002 | Legacy constraints 被识别 | 完成 batch, interface, product, data, vendor constraint assessment | Constraint inventory | Architect | Slice selection |
| CBM-003 | 迁移切片可控 | 对每个 slice 评分并批准 sequencing | Slice scorecard | Product / EA | Roadmap approval |
| CBM-004 | 新旧语义隔离 | ACL contract 覆盖 canonical model、policy、idempotency、evidence | ACL spec, contract tests | Solution Architect | Build gate |
| CBM-005 | 数据迁移可证明 | 每批迁移有 manifest、DQ、mapping、recon、approval | Migration evidence pack | Data Migration Lead | Migration gate |
| CBM-006 | Core writes 受控 | 写操作通过 policy-gated tool/command gateway | Write log, approval, side-effect id | Tech Owner | Production readiness |
| CBM-007 | Parallel run 可信 | Shadow ledger / dual-run 覆盖高风险场景 | Parallel-run scorecard | QA / Finance / SME | Cutover gate |
| CBM-008 | Customer harm 被前置 | 建立 harm scenarios、signals、remediation | Harm checklist, monitoring dashboard | Product / Ops | Cutover gate |
| CBM-009 | Cutover 可恢复 | 演练 downtime、rollback、queue drain、BCP | Rehearsal report, rollback proof | Release / BCP Lead | Cutover approval |
| CBM-010 | Vendor evidence 可用 | 供应商交付 mapping、test、defect、support evidence | Vendor control pack | Vendor Manager | Vendor gate |
| CBM-011 | AI 辅助受治理 | AI suggestions 有引用、review、approval 和使用边界 | AI assist log | AI Governance / PM | Ongoing |
| CBM-012 | 运营准备充分 | SOP、培训、workbench、command center、support model 准备 | ORR pack | Operations Lead | Go-live |
| CBM-013 | 审计证据可查询 | Evidence events 支撑 account/customer/product/slice 查询 | Evidence catalog, audit queries | Evidence Owner | Audit readiness |
| CBM-014 | Legacy retirement 受控 | 退役前确认数据保留、只读、归档、接口停用 | Retirement pack | EA / Ops / Records | Decommission gate |
16. Operational Readiness Review
ORR 必须覆盖业务、技术、数据、运营、供应商、风险和证据。
| ORR area | Evidence |
|---|---|
| Business readiness | 产品规则确认、客户话术、费用/利息解释、投诉路径 |
| Operations readiness | SOP、培训、队列、手工 workaround、权限、值班 |
| Technology readiness | Environment、monitoring、capacity、release、rollback、DR |
| Data readiness | Migration recon、DQ exceptions、retention、lineage |
| Finance readiness | GL recon、adjustment process、period close impact |
| Risk readiness | Controls, exceptions, residual risk, approvals |
| Vendor readiness | Support window, escalation, defects, release freeze |
| Evidence readiness | Trace, event, command log, evidence pack, audit queries |
| AI readiness | Use-case registry, access control, prompt/model version, reviewer workflow |
17. Resilience / BCP / Degraded Mode
17.1 BCP Scenarios
| Scenario | Degraded mode | Key evidence |
|---|---|---|
| Legacy core read unavailable | Serve limited cached read with as-of disclosure or manual inquiry | Cache freshness, customer script |
| Target service unavailable | Route back through legacy path where SoT remains legacy | Route log, rollback decision |
| ACL degraded | Disable high-risk writes, allow approved read-only paths | Policy decision, write block log |
| Vendor package outage | Manual-first or legacy fallback by capability | Vendor incident, BCP activation |
| Evidence pipeline lag | Local append-only capture, restrict Tier 1 writes if evidence missing | Local ledger, preservation record |
| Reconciliation engine unavailable | Delay cutover or freeze affected migration | Gate exception, risk decision |
| Identity / entitlement issue | No personalized or sensitive view, manual verification | Access denial log |
| AI workspace unavailable | Continue modernization with approved human process | AI dependency note, no customer impact |
17.2 Impact Tolerance Examples
| Dimension | Example tolerance |
|---|---|
| Customer-facing balance accuracy | Known incorrect balance display for Tier 1 account flows triggers immediate safe-stop |
| Transaction posting | No unclassified duplicate posting beyond approved materiality |
| Evidence completeness | Tier 1 cutover commands and core writes require complete trace and command log |
| Manual backlog | No regulatory or contractual deadline breach in complaint/dispute queues |
| Rollback time | Route rollback must fit tested recovery window for each slice |
| Vendor response | Critical cutover defect must have named vendor escalation with response commitment |
18. Architecture Runway Backlog
| Runway item | Purpose | First usable milestone |
|---|---|---|
| Source-of-truth registry | Track fact ownership by capability and data object | Registry covers first two slices |
| Canonical model registry | Prevent semantic drift across adapters | Customer, account, balance, transaction v1 |
| ACL platform | Govern intent API, mapping, policy, idempotency, evidence | Read API and one controlled write path |
| Event capture | Feed read models, recon, evidence | Legacy transaction and account events |
| Reconciliation engine | Automate variance detection and break workflow | Balance and transaction recon |
| Shadow ledger | Validate target ledger or posting rules | One product family in shadow mode |
| Migration evidence store | Store manifests, snapshots, mappings, recon | Query by account/product/population |
| Operational cockpit | Monitor cutover and coexistence | Customer harm and error dashboard |
| Vendor control pack | Make vendor obligations observable | Release calendar and defect evidence |
| AI governed workspace | Enable safe AI assistance | Read-only docs/code RAG with review workflow |
19. 30 / 60 / 90 Roadmap
Day 0-30: Diagnostic and Control Foundation
| Workstream | Outputs |
|---|---|
| Scope and governance | Capability inventory, RACI, modernization principles, decision rights |
| Constraint discovery | Batch/interface/product/data/vendor constraint inventory |
| Source-of-truth | Initial SoT registry by data object and capability |
| Slice selection | Readiness scorecard, first slice candidates, customer harm model |
| Evidence design | Evidence taxonomy, migration artifact list, cutover command log template |
| AI governance | AI use-case registry, safe-use policy, forbidden boundaries, access controls |
Exit criteria:
- Management understands modernization as staged source-of-truth transfer.
- First slices selected with explicit risks and evidence requirements.
- AI workspace is read-only or review-gated, not connected to production writes.
Day 31-60: Build Runway and Prove One Slice
| Workstream | Outputs |
|---|---|
| ACL | Intent API, canonical model v1, mapping tests, idempotency design |
| Event/read model | Event capture for first slice, read replica with freshness metadata |
| Migration factory | Population manifest, DQ profile, mapping decision record, recon report |
| Parallel run | Shadow or dual-run for selected scenarios |
| Operations | SOP, workbench view, training, command center draft |
| Vendor | Interface evidence, environment readiness, support model |
| AI assist | Requirements mining, mapping suggestions and test generation with review evidence |
Exit criteria:
- One non-trivial slice proves ACL, evidence, recon and operational model.
- Break taxonomy and ownership are working.
- Cutover rehearsal plan is approved.
Day 61-90: Rehearse Cutover and Scale Sequencing
| Workstream | Outputs |
|---|---|
| Cutover rehearsal | Full timeline, queue drain, smoke test, rollback drill, evidence capture |
| Customer harm monitoring | Balance/transaction/error/complaint signals and remediation path |
| BCP | Degraded mode scenarios, impact tolerance, vendor escalation |
| Governance | Cutover gate, exception process, residual risk pack |
| Scale plan | Next 3-5 slices, architecture runway gaps, funding and team topology |
| Legacy retirement | Read-only, archive, interface shutdown, records retention approach |
| AI operations | Defect clustering, rehearsal analysis, runbook copilot under read-only controls |
Exit criteria:
- First production cutover or controlled pilot has evidence-backed approval.
- Rollback and degraded mode have been exercised.
- Next slices have sequencing based on value, coupling, evidence and readiness.
20. Anti-Patterns and Corrections
| Anti-pattern | Why it fails | Correction |
|---|---|---|
| Treat modernization as procurement | 新核心包不会自动解决语义、数据、运营和证据问题 | Define transition architecture and operating model |
| Wrap legacy APIs only | 渠道继续依赖旧语义, 未来迁移更难 | Build ACL with canonical model and policy |
| Migrate by table | 表迁移不等于业务事实迁移 | Migrate by capability, account population and fact type |
| Close recon breaks with spreadsheet comments | 差异不可追溯, 审计和事故复盘困难 | Break workflow with owner, cause, evidence and approval |
| Let AI generate final mapping | 映射错误直接造成客户和账务风险 | AI suggestion, human approval, sample and regression |
| Ignore branch/contact center | 员工无法解释旧新差异, 投诉上升 | Unified workbench, script, training, escalation |
| Cutover without rollback authority | 发现问题时没人敢停或回切 | Named rollback owner and triggers |
| Evidence after cutover | 事故后补证据不可信 | Evidence-by-design in pipeline and command center |
| Retire legacy too early | 历史查询、争议、报表和 records retention 断裂 | Retirement gate with archive and read-only strategy |
21. Interview Answers
Q1: 你如何规划核心银行现代化?
30 秒版本:
我会把核心现代化定义为受控的 source-of-truth 迁移, 而不是一次系统替换。先做 constraint inventory 和 customer harm model, 再按 capability slicing 选择低耦合、高价值、证据成熟的切片。架构上建立 ACL、canonical model、event capture、read replica、reconciliation engine、shadow ledger 和 evidence plane。每个 cutover 都要有 migration manifest、parallel-run scorecard、rollback、BCP、运营准备和授权签署。
2 分钟版本:
核心银行承载客户余额、交易、利息、费用、贷款计划、总账和监管证据, 所以现代化不能只看目标系统。我的第一步是盘点旧核心约束: mainframe batch window、产品参数、接口耦合、数据质量、供应商节奏、运营 SOP 和客户伤害场景。
第二步是 capability slicing, 不是按数据库表迁移。对每个 slice 评估业务价值、耦合度、数据成熟度、测试 oracle、运营准备和 rollback 可行性。先用一个中低风险但有真实价值的 slice 证明 ACL、canonical model、event capture、reconciliation 和 evidence process。
第三步是 evidence-backed cutover。迁移要有 population manifest、source snapshot、mapping decision、DQ profile、parallel-run result、recon breaks、exception approval、customer harm monitoring 和 rollback proof。AI 可以帮助理解文档和代码、建议映射、生成测试和分析缺陷, 但不能拥有最终迁移决定、核心写入、source-of-truth 变更或客户影响 cutover。
Q2: Strangler 和核心包替换如何结合?
30 秒版本:
核心包可以是目标能力平台, 但 strangler 是迁移方式。我要用 ACL 把渠道和业务流程从旧核心语义中解耦, 再按 capability 把读、工作流、产品参数、开户、服务变更、ledger 能力逐步迁到核心包或新服务。关键是每个能力都有 SoT 状态、对账证据和回滚策略。
2 分钟版本:
很多项目失败在于把核心包当完整目标架构, 忽视 transition。我的做法是把核心包能力纳入 target state, 但通过 strangler 控制迁移节奏。旧核心、核心包和新微服务会共存一段时间, 所以 ACL 必须提供 intent API、canonical model、mapping、policy、idempotency 和 evidence。
对适合核心包承接的能力, 例如标准存款账户、产品参数和部分服务流程, 我会用 vendor adapter 和 parameter governance。对差异化能力, 例如数字化开户体验、运营工作流、AI 辅助客服或数据产品, 可以放在外围服务。所有写入必须通过受控命令路径, 所有事实源迁移都进入 SoT registry。
Q3: 如何证明数据迁移质量?
30 秒版本:
我会建立 migration evidence factory。每批数据都有 population manifest、source snapshot、DQ profile、mapping decision、transformation run、target load、reconciliation report、exception register 和 approval pack。质量不是“装载成功”, 而是新旧业务事实在账户、交易、余额、利息、费用、状态和 GL 上可对账、差异可分类、例外可批准。
2 分钟版本:
数据迁移最危险的是只看技术行数和装载成功率。核心银行迁移必须从业务事实证明: 迁移了哪些客户和账户, 源数据冻结在什么时间, 字段和状态如何映射, 产品参数如何转换, 哪些数据有质量缺陷, 新旧余额和交易是否一致, 差异是否在预先批准的 tolerance 内。
我会把 recon breaks 分成 data defect、mapping defect、rule defect、timing defect、vendor defect、operational defect 和 evidence defect, 每类有 owner 和关闭证据。对 ledger-impacting 能力, 我会用 shadow ledger 或 parallel run 跨日终/月终周期验证, 再进入 cutover gate。
Q4: AI 在核心现代化里最大的价值和边界是什么?
30 秒版本:
最大价值是加速理解和验证: requirements mining、legacy code/document understanding、mapping suggestion、data profiling、test generation、cutover rehearsal analysis、defect clustering 和 runbook copilot。边界是 AI 不能做最终迁移决策、未经审批核心写入、客户影响 cutover、source-of-truth 变更、reconciliation closure 或合规审计结论。
2 分钟版本:
我会把 AI 放在 governed workspace 中, 让它帮助处理大量非结构化材料和复杂规则。比如从 COBOL、copybook、SOP、供应商文档和 Jira 中抽取规则冲突, 为字段映射提供候选, 根据历史缺陷生成测试, 聚类 parallel-run 差异, 分析 cutover 演练日志。
但 AI 输出必须有引用、版本、置信度、reviewer 和批准用途。高风险工具默认只读或 dry-run, 核心写入需要 policy gate、审批、幂等、side-effect id 和 recon。AI 不得自动关闭差异, 不得自动批准 mapping, 不得指挥 production cutover。这样既利用 AI 提效, 又不把客户事实和监管责任交给模型。
Q5: 如何向管理层解释为什么不能 big-bang?
30 秒版本:
我会用风险集中度解释。Big-bang 把数据、渠道、运营、供应商、客户影响、财务对账和证据风险集中到一个窗口, rollback 也最复杂。Strangler 不是慢, 而是把风险拆成可证明的 capability increments, 每个 increment 都交付价值、证据和学习。
2 分钟版本:
我不会简单说 big-bang 不行, 而是展示风险对比。核心银行不是单系统上线, 它牵动账户、交易、利息、费用、贷款、总账、客服、投诉、监管报表和历史证据。Big-bang 的问题是所有未知同时暴露, 且一旦写入新核心后 rollback 涉及交易补偿、客户通知和财务处理。
Strangler 让我们先迁读能力、运营工作流、产品目录、低风险写入, 同时构建 ACL、event capture、recon、shadow ledger 和 cutover muscle。每个切片都有客户伤害监控和回退路径。管理层看到的是有节奏的风险下降和能力释放, 不是无限期双系统。
22. Portfolio Exercise
为一家拥有 mainframe deposit core、第三方 loan servicing package、数字渠道和数据仓库的零售银行设计一个 90 天 modernization pilot:
| Deliverable | 期望内容 |
|---|---|
| Capability slice | 选择一个具体切片, 说明为什么不是先切 ledger |
| ACL contract | Intent API、canonical objects、write tier、error taxonomy |
| Evidence model | Migration manifest、mapping、recon、cutover log、AI assist log |
| Parallel-run plan | 覆盖哪些场景、周期、tolerance、break taxonomy |
| Customer harm model | 3-5 个伤害场景、监控信号和补救路径 |
| AI boundary | 安全辅助清单、禁止边界、review workflow |
| 30/60/90 plan | 每阶段 exit criteria 和管理层汇报指标 |