AI 扩展计划 / Playbooks

AI Banking Reference Models / BIAN / FIBO / ISO 20022 Playbook

这些来源作为行业参考模型和 AI 风险治理锚点, 不构成法律, 合规, 审计或供应商选型意见。落地时仍需结合所在国家/地区监管, 银行内部数据标准, 模型风险管理和架构治理流程。

608 行AI_BANKING_REFERENCE_MODELS_BIAN_FIBO_ISO20022_PLAYBOOK.md

AI Banking Reference Models Playbook: BIAN, FIBO, ISO 20022

适用对象: AI PM, AI Architect, Business Architect, Data Product Manager, Financial Services BA, Enterprise Architect, AI Governance Lead. 核心问题: 当银行 AI 产品需要跨核心银行, 支付, KYC, AML, 信贷, 财富管理, 数据平台和审计团队协作时, 如何用行业参考模型建立一致的业务边界, 金融概念语义, 消息数据契约和 AI 治理证据。 学习目标: 把 BIAN, FIBO, ISO 20022 从"标准知识"转化为 AI 需求分析, RAG 知识边界, agent/tool contract, semantic layer, audit evidence 和 cross-system integration 的架构资产。 前提假设: 读者已具备成熟 PM/BA/金融零售系统经验和 CBAP 级业务分析能力。本手册不讲业务分析基础, 重点是金融 AI 产品架构和银行业务架构表达。

Source Anchors

Anchor	Official source	本手册使用方式
BIAN	https://bian.org/	用 Service Landscape 和 Service Domain 语言拆分银行业务能力, 服务边界, API ownership, workflow handoff 和 AI tool boundary.
BIAN Service Landscape	https://bian.org/deliverables/service-landscape/	用于建立 capability-to-service-domain mapping, 判断 AI use case 应连接哪些银行服务域, 以及哪些域不能被一个 agent 混在一起。
FIBO	https://spec.edmcouncil.org/fibo/	用作金融业务概念, 合约, 产品, 法人, 关系, 证券, 衍生品和监管语义的 ontology anchor.
ISO 20022	https://www.iso20022.org/	用 Business Model, Message Definition 和 Payments/Securities 语义组织支付, 证券, cash management 和监管消息的数据契约。
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern, Map, Measure, Manage 组织 reference-model-driven AI 风险识别, eval, control evidence 和持续治理。

One-Sentence Positioning

BIAN defines banking capability and service boundaries, FIBO defines financial meaning, ISO 20022 defines message and transaction semantics, and AI architecture turns them into executable contracts for requirements, retrieval, tools, data, integration and audit.

1. 为什么金融 AI 需要行业参考模型

金融 AI 项目失败时, 团队常把问题归因于模型能力, RAG 效果或数据质量。但在银行场景里, 更深层的问题通常是业务边界, 概念语义和系统契约没有先治理:

同一个词在不同系统中含义不同: customer, party, account, arrangement, facility, exposure, beneficiary, counterparty.
AI assistant 把流程知识, 政策知识, 客户事实, 交易消息和审计证据混在同一个回答里。
RAG 检索到相似材料, 但材料属于错误业务域, 错误产品线, 错误地区或错误生效期。
agent tool 看似能调用很多系统, 但没有按银行服务域设置最小权限和业务动作边界。
数据平台有表和字段, 但缺少金融概念层, 无法解释字段在业务, 风险, 会计, 报文和监管上下文中的意义。
审计要求重放 AI 输出时, 团队只能提供 prompt 和模型日志, 不能说明引用的业务能力边界, 概念定义, 消息字段和控制依据。

行业参考模型的价值不是"遵循标准"本身, 而是把银行复杂性压缩成可沟通, 可映射, 可评审, 可执行的架构语言。

没有参考模型的 AI 交付方式	使用参考模型后的 AI 交付方式
以 UI story 或 prompt 开始	以 business capability, service domain, concept model, message contract 开始
RAG 文档按文件夹或系统来源分类	RAG corpus 按业务域, 概念, 消息类型, 权威层级和权限边界组织
agent 工具按已有 API 暴露	tool contract 按 service domain, action type, entitlement 和 approval gate 暴露
数据字典只解释字段名	semantic layer 解释业务概念, 关系, 消息元素, lineage 和 valid context
测试只看回答是否合理	eval 同时检查 domain fit, concept correctness, message-field grounding, permission 和 audit replay
作品集展示 demo	作品集展示 mapping matrix, semantic gap log, domain service card, control evidence

高级表达:

In banking AI, reference models are not documentation artifacts. They are control surfaces for domain boundaries, semantic precision, regulated integration and auditability.

2. Reference Model Stack for Banking AI

Layer	主要模型	解决的问题	AI 架构产物
Business capability boundary	BIAN Service Landscape	业务能力和服务域如何拆分, owner 在哪里, agent 不应跨越哪些边界	Capability map, service domain card, tool boundary design
Financial concept semantics	FIBO	金融概念, 合同, 法人, 产品, 关系, 证券, 风险暴露如何定义	Ontology subset, glossary, entity-relation model, semantic validation rules
Message and transaction semantics	ISO 20022	支付, 证券, cash management 等消息如何表达业务数据和状态	Message mapping, field lineage, event schema, payment/settlement data contract
Enterprise semantic layer	Internal data standards + FIBO/ISO mapping	内部表, API, events, metrics 如何映射到权威语义	Data product contract, metric contract, lineage, access policy
AI knowledge and retrieval	Policy/SOP/product docs + reference model tags	RAG 如何限制在正确业务域, 概念, 消息类型和权限范围	Source registry, retrieval filter, claim contract, citation policy
Agent and tool contracts	BIAN service boundary + internal API catalog	agent 能做什么, 调哪个服务, 需要什么审批和回滚	Tool contract, action scope, maker-checker gate, audit log
Governance and evidence	NIST AI RMF + model risk + audit	如何证明 AI use case 被识别, 度量, 控制和持续管理	Risk-control matrix, eval report, release gate memo, audit evidence pack

设计原则:

BIAN is the boundary layer. 用来决定"这个 AI use case 属于哪些银行服务域, 哪些服务域只读, 哪些服务域可写, 哪些动作需要人工审批"。
FIBO is the meaning layer. 用来决定"这个概念到底是什么, 它和哪些金融对象有关, 哪些同义词和近义词不能混用"。
ISO 20022 is the message layer. 用来决定"支付或证券交易事实如何在跨系统消息中表达, 哪个字段是事实来源, 哪个状态可以触发流程动作"。
NIST AI RMF is the risk operating layer. 用来组织 AI 风险治理, 评测, 监控, 控制和管理层沟通。

3. BIAN: 用 Service Landscape / Service Domain 定义能力和服务边界

BIAN 的关键价值是为银行业务能力和服务边界提供共同语言。对 AI PM / Architect 来说, 重点不是背 Service Landscape, 而是用它回答五个问题:

这个 AI use case 属于哪个业务域和服务域组合?
哪个 service domain 是 source of truth, 哪个只是 consumer 或 orchestration participant?
AI agent 的 tool/action 是否跨越了不该合并的职责边界?
哪些服务域的动作必须 human-in-the-loop 或 maker-checker?
作品集里如何证明你的服务拆分不是按 UI 页面或组织习惯随意拆的?

3.1 BIAN 在 AI 架构中的使用方式

AI 架构问题	BIAN 用法	产物
需求边界	把业务需求映射到 service domains, 避免一个 story 混合 customer, account, payment, risk, compliance 和 ledger 职责	Reference Model Mapping Matrix
RAG 边界	给知识源打 service domain tag, 检索时按业务域过滤	Knowledge Source Registry with BIAN tags
Tool contract	每个 agent tool 绑定一个 service domain 或明确的 orchestration pattern	Domain Tool Contract
权限控制	按 read, recommend, pre-fill, execute 划分 action scope	Tool Entitlement Matrix
集成设计	用 service domain 判断 API ownership, event ownership 和 data stewardship	API/Event Ownership Map
审计证据	说明 AI 输出和动作使用了哪些服务域, 哪些域只读, 哪些域经过审批	Domain Boundary Evidence

3.2 Service Domain Boundary Heuristics

判断问题	架构含义	AI 风险
这个域是否拥有业务状态变更权?	决定 tool 是否可写	agent 越权修改系统事实
这个域是否是 customer/account/payment 的 system of record?	决定事实引用和 citation 优先级	回答引用了派生数据或缓存事实
这个域是否产生监管或审计证据?	决定日志, retention 和 replay 要求	输出无法支撑 audit inquiry
这个域是否涉及资金移动或客户权利义务?	决定 maker-checker 和审批门槛	自动化动作造成 financial harm
这个域是否只是编排或体验层?	决定是否需要调用底层权威服务	agent 把 UI 状态当权威事实
这个域是否跨产品线复用?	决定 capability owner 和 reusable tool boundary	局部 prompt 变成企业级不一致能力

3.3 Example: Payments Exception Copilot with BIAN Thinking

业务问题	BIAN-style boundary decision	AI 设计含义
查询 payment status	Payment execution / payment order 相关服务域应提供权威状态	AI 可以只读查询, 引用 transaction status 和 timestamp
解释 return reason	Payment rail rulebook 和 message interpretation 属于知识和消息语义层	RAG 必须按 rail, message type, effective date 过滤
判断 ledger impact	Ledger/accounting 相关服务域拥有记账事实	AI 只能解释影响, 不应自行调整 ledger
推荐 repair action	Exception handling 是 workflow orchestration, 需调用支付服务和规则服务	AI 可生成 repair checklist, 执行需 maker-checker
联系客户	Customer communication / servicing 域负责话术和渠道	AI 可生成草稿, 需遵守客户认证, 隐私和渠道偏好
关闭 exception case	Case/workflow 服务域拥有 case state	AI 可建议 closure reason, 人工确认后更新

面试表达:

I would not expose a broad "payment agent" to every payment API. I would map the use case to BIAN-style service domains, separate read-only inquiry, repair recommendation, customer communication and state-changing payment actions, then attach different entitlement and approval controls to each boundary.

4. FIBO: 用金融概念语义支撑 RAG, 数据层和推理边界

FIBO 的价值是为金融概念提供 ontology 语言。对金融 AI 产品而言, 它可以帮助团队把概念歧义前置解决, 而不是让 LLM 在上下文里猜。

典型概念风险:

party, customer, client, counterparty, beneficial owner, account holder 混用。
facility, loan, commitment, exposure, outstanding balance, available credit 混用。
payment instruction, payment transaction, settlement, clearing, posting, reconciliation 混用。
security, instrument, position, holding, portfolio, order, trade, allocation 混用。
legal entity, branch, organization unit, merchant, sponsor bank, processor 混用。

4.1 FIBO 在 AI 架构中的使用方式

AI 架构问题	FIBO 用法	产物
术语统一	将高价值金融概念映射到 ontology class/property, 建立 approved glossary	Financial Concept Glossary
RAG 检索	用 concept tag, relation tag 和 synonym control 改善召回和过滤	Concept-tagged Knowledge Index
GraphRAG	用 entity/relation model 组织 party, account, product, agreement, obligation, collateral, instrument	Financial Knowledge Graph Schema
数据语义	将内部字段映射到金融概念, 说明字段含义和适用范围	Semantic Data Mapping
eval	检查 AI 回答是否混淆近似概念	Concept Correctness Test Set
审计	证明高风险回答使用了批准概念定义和来源	Concept Definition Evidence

4.2 Concept Boundary Examples

概念组	容易混淆点	AI 设计处理
Party vs Customer vs Account Holder	party 是参与方概念, customer 是关系状态, account holder 是账户权利义务角色	RAG 和工具输入必须声明 role, 不只传 `customer_id`
Beneficial Owner vs Authorized Signer	UBO 关注所有权/控制, signer 关注授权操作	KYC assistant 必须区分 ownership evidence 和 signing authority
Loan Facility vs Loan Account	facility 是授信安排, account 是账户或账务承载	Lending assistant 不可把账户余额直接等同授信承诺
Payment Instruction vs Settlement	instruction 是发起指令, settlement 是资金/义务最终结算过程	Payment copilot 回答状态时必须说明当前处于 instruction, clearing, settlement 或 posting 阶段
Holding vs Position vs Transaction	holding 是持有结果, position 可包含风险敞口, transaction 是事件	Wealth AI 不可用单笔交易替代客户投资组合敞口
Exposure vs Balance	exposure 可能包含未使用额度, 担保, 衍生品或净额安排	Credit risk AI 不可只用账面余额解释风险敞口

4.3 FIBO-Driven Semantic Validation

Validation	示例规则	AI release gate
Role distinction	`beneficial_owner` 不得被回答为 `authorized_signer`	KYC 高风险回答 fail
Product hierarchy	`mortgage_loan` 必须是 lending product, 不得归为 deposit	Lending retrieval filter fail
Agreement linkage	advice, fee, covenant, rate, collateral 必须能追溯到 agreement 或 policy	Wealth/lending citation fail
Counterparty relationship	counterparty risk answer 必须区分 borrower, guarantor, merchant, beneficiary	Risk explanation fail
Temporal validity	concept definition 或 product rule 必须有 effective date	Regulated answer limited release
Jurisdiction context	税务, KYC, suitability, payments rule 必须绑定 jurisdiction	Cross-border response fail

高级表达:

FIBO helps me turn financial vocabulary into controlled semantics. For AI, that means fewer hallucinated joins, clearer entity roles, better retrieval filters and stronger audit evidence for concept-sensitive answers.

5. ISO 20022: 用消息和支付/证券数据语义建立跨系统契约

ISO 20022 对 AI 的价值不只在支付报文格式, 而在于它提供了跨机构, 跨系统, 跨流程的数据语义。对银行 AI 来说, 这尤其适用于 payments exception, cash management, sanctions screening, reconciliation, securities operations 和 regulatory reporting。

5.1 ISO 20022 在 AI 架构中的使用方式

AI 架构问题	ISO 20022 用法	产物
消息理解	将 payment/security message elements 映射到业务概念, 状态和异常原因	Message Semantic Map
支付异常解释	用 message type, status, reason code, party fields, remittance information 支撑诊断	Exception Explanation Contract
RAG 边界	按 rail, message family, message type, version, effective date 过滤 rulebook 和操作手册	Rail/Message-aware Retrieval Policy
数据血缘	从报文字段追踪到内部事件, case, ledger posting 和客户沟通	Field-to-Decision Lineage
工具契约	agent 调用 repair/retry/return 工具时必须提供结构化 message context	Payment Tool Input Schema
eval	检查 AI 是否引用正确字段解释状态和异常	Message Grounding Eval

5.2 Message Semantics for AI

ISO 20022 语义对象	AI 需要理解什么	风险控制
Message family	该消息属于 payments, cash management, securities 还是其他业务域	防止用错误规则解释消息
Message definition	该消息表达 instruction, status, report, advice 还是 investigation	防止把状态报告当执行指令
Party elements	debtor, creditor, agent, ultimate party, intermediary 等角色	防止误识别责任方或客户身份
Account elements	账户标识, 账户服务机构, 账户类型	数据最小化和权限过滤
Amount/currency	instructed amount, settlement amount, charges, FX 信息	金额解释和差错影响评估
Status/reason codes	当前处理状态和原因	exception 分类和 repair path
Remittance information	付款用途, 发票或参考信息	RAG/LLM 使用前做 PII 和 prompt injection 防护
Supplementary data	特定机构或市场扩展	版本控制和 compatibility 测试

5.3 Payment Exception AI Pattern

flowchart LR
  MSG[ISO 20022 message] --> PARSE[Message parser and validator]
  PARSE --> SEM[Message semantic map]
  SEM --> CASE[Exception case context]
  SEM --> RAG[Rail rulebook and SOP retrieval]
  SEM --> LEDGER[Ledger and posting inquiry]
  RAG --> AI[AI exception explainer]
  LEDGER --> AI
  CASE --> AI
  AI --> REC[Repair recommendation]
  REC --> HITL[Maker-checker approval]
  HITL --> TOOL[Repair / return / retry tool]
  AI --> AUDIT[Field-level citation and audit evidence]

关键设计:

LLM 不直接解释原始 XML/JSON 报文。先由 message parser 结构化, 校验和脱敏。
AI 输出的每个异常解释必须引用 message field, rulebook source, ledger/case fact 或人工输入。
repair action 工具需要结构化入参, 包括 message type, payment id, reason code, party role, amount/currency, approval id.
remittance text 和 free-text investigation notes 必须作为 untrusted input 处理, 防 prompt injection 和敏感信息泄露。

高级表达:

ISO 20022 gives payment AI a shared transaction language. I would use it to ground exception explanations, repair workflows, reconciliation lineage and cross-system evidence rather than treating payment messages as free text for an LLM.

6. AI Use Case Mapping

Use case	BIAN boundary	FIBO semantic focus	ISO 20022 focus	AI pattern	核心控制
Payments exception copilot	Payment order, payment execution, case/workflow, ledger inquiry, customer communication	debtor/creditor, account, payment obligation, settlement, charges	payment status, reason code, party/account/amount fields, remittance info	RAG + message parser + workflow copilot	repair action maker-checker, field-level citation, rail rule version
KYC remediation assistant	Customer profile, party data, customer agreement, document handling, case management	party, beneficial owner, legal entity, role, control, identity document	limited, only if payment data supports activity profile	RAG + classifier + document extraction	authority hierarchy, UBO/signatory distinction, human approval
AML investigation copilot	Customer behavior, transaction monitoring, case management, sanctions, relationship graph	party, account, counterparty, beneficial ownership, relationship, risk typology	transaction/message evidence, party fields, payment route	GraphRAG + evidence summarization	no autonomous SAR/STR decision, evidence path, restricted data
Lending underwriting assistant	Product eligibility, credit facility, collateral, agreement, decision workflow	borrower, guarantor, facility, exposure, collateral, covenant, obligation	limited, cashflow evidence if bank statement/payment messages used	rules + RAG + document understanding	deterministic calculations, fair lending controls, decision authority retained
Wealth compliance guardrail	Customer suitability, advisory workflow, product governance, communication review	investor, instrument, holding, portfolio, suitability, risk rating, advice	securities messages where trading/settlement context matters	RAG + rules + communication classifier	approved content, suitability evidence, supervision log

6.1 Fit / No-Fit Decision

Question	Good fit signal	No-fit or limited-fit signal
Can the use case be mapped to clear service domains?	Yes, with owner and action boundary	No, it is a broad "banking assistant" without domain limits
Are key concepts controlled?	FIBO/internal glossary can define roles and relationships	Critical terms remain ambiguous across teams
Is message or transaction evidence structured?	ISO 20022 or internal event schema can ground facts	Mostly free text, screenshots or manual notes
Can AI outputs be evaluated against domain-specific tests?	Concept correctness, message grounding, citation, permission tests exist	Only subjective "answer quality" review exists
Can state-changing actions be gated?	Tool scopes and maker-checker controls are explicit	Agent directly executes high-risk actions
Can audit replay prove why an output was generated?	Source, concept, message field, tool call and approval evidence are logged	Logs only include prompt and response

7. 金融零售案例

7.1 Payments: ISO 20022-grounded Exception Handling

Dimension	Architecture decision
Business problem	Repair queue, return, retry, duplicate payment, missing reference, reconciliation break and customer inquiry require cross-system diagnosis.
Reference model use	BIAN separates payment, ledger, case and customer communication boundaries. ISO 20022 grounds payment status and reason. FIBO clarifies party/account/payment obligation concepts.
AI capability	Explain exception, summarize timeline, cite rail rule, suggest repair checklist, draft customer/internal communication.
Tool boundary	Read payment status and ledger impact; pre-fill repair form; execute only after maker-checker approval.
Evidence	Message field citation, rulebook version, ledger inquiry result, case note, approval id, action log.
Eval	Correct exception classification, correct status/reason interpretation, no wrong party identification, repair recommendation precision, false repair prevention.

7.2 KYC: Beneficial Ownership and Remediation

Dimension	Architecture decision
Business problem	Periodic review and remediation need consistent handling of legal entity, beneficial owner, controller, authorized signer, tax status and document evidence.
Reference model use	BIAN separates party/customer profile, document handling, case workflow and compliance review. FIBO controls party roles and ownership/control relationships.
AI capability	Detect missing evidence, explain requirement, generate outreach draft, summarize document pack, route exception.
Tool boundary	Read customer/KYC status; extract document fields; recommend remediation task; update master data only after approved review.
Evidence	Policy clause, concept definition, source document id, reviewer decision, effective date, customer communication record.
Eval	UBO/signatory distinction, jurisdiction-specific requirement accuracy, document extraction quality, refusal when evidence is insufficient.

7.3 AML: Investigation Evidence Copilot

Dimension	Architecture decision
Business problem	Analysts need to connect alerts, customer profile, transactions, counterparties, typologies, adverse media and prior cases without losing evidence traceability.
Reference model use	BIAN separates transaction monitoring, case management, customer data and sanctions/adverse-media capabilities. FIBO helps model party, account, relationship, counterparty and obligation semantics. ISO 20022 grounds payment evidence where available.
AI capability	Alert summary, transaction timeline, relationship graph explanation, red-flag checklist, narrative draft with citations.
Tool boundary	Read investigation context; create draft narrative; no autonomous close/escalate/SAR decision.
Evidence	Alert id, transaction/message field, relationship edge, policy/typology source, citation span, analyst approval.
Eval	Evidence recall, citation precision, unsupported claim rate, typology correctness, permission leakage, narrative defect rate.

7.4 Lending: Underwriting Assistant

Dimension	Architecture decision
Business problem	Underwriters need consistent policy interpretation, financial extraction, exception detection, collateral/guarantor context and explainable decision support.
Reference model use	BIAN separates loan application workflow, product eligibility, credit decision, collateral and agreement servicing. FIBO clarifies borrower, facility, exposure, obligation, collateral and covenant.
AI capability	Income/cashflow summary, policy checklist, exception explanation, memo draft, adverse-action reason suggestion.
Tool boundary	Deterministic calculators and policy rules remain separate from LLM narrative. AI does not approve/decline credit.
Evidence	Source document, calculation trace, policy clause, FIBO-aligned concept mapping, underwriter attestation.
Eval	Calculation support accuracy, policy citation, missing-risk detection, concept confusion tests, subgroup performance and fairness review.

7.5 Wealth: Advisory Compliance Guardrail

Dimension	Architecture decision
Business problem	Advisors need pre-send and pre-meeting guardrails for suitability, risk disclosure, approved product language and misleading performance claims.
Reference model use	BIAN separates customer suitability, advisory workflow, product governance and communication supervision. FIBO clarifies investor, portfolio, instrument, holding, risk rating and advice. ISO 20022 can support securities operations context when relevant.
AI capability	Detect prohibited language, missing disclosure, suitability mismatch, off-policy claim, unapproved product mention.
Tool boundary	Review and suggest revisions; no independent investment advice or trade execution.
Evidence	Client profile version, product risk rating, approved content source, policy clause, original/revised communication, supervisor log.
Eval	Compliance issue recall, false positive burden, suitability rule coverage, citation correctness, surveillance defect reduction.

8. Template: Reference Model Mapping Matrix

Use this when framing any banking AI use case before writing requirements.

Field	Guidance
Use case name	Stable business name, not a model name. Example: Payments Exception Copilot.
Business decision/workflow	What workflow, decision or operational bottleneck is being improved?
Primary user	Analyst, underwriter, operations specialist, advisor, RM, customer service agent, supervisor.
BIAN business area	Which business area or capability group anchors the use case?
BIAN service domains	Which service domains are read, recommend, pre-fill or execute participants?
Service domain owner	Who owns authoritative business behavior and API/event contract?
FIBO concepts	Which financial concepts must be controlled?
Internal glossary mapping	Which internal terms map to external concepts, and where do they diverge?
ISO 20022 messages/elements	Which message family/type/field/status/reason code grounds facts?
Source systems	Systems of record and derived systems used by AI.
AI pattern	RAG, GraphRAG, classifier, document extraction, rules+LLM, workflow copilot, agent.
Allowed AI actions	Read, summarize, recommend, draft, pre-fill, execute with approval.
Prohibited AI actions	Decisions or state changes AI must not perform.
Eval dimensions	Domain fit, concept correctness, message grounding, citation, permission, business outcome.
Audit evidence	Sources, concept definitions, message fields, tool calls, approvals, output version.

Example:

Field	Example: Payments Exception Copilot
Business decision/workflow	Resolve payment exceptions faster while preventing incorrect repair or customer miscommunication.
BIAN service domains	Payment inquiry, payment execution, case workflow, ledger inquiry, customer communication.
FIBO concepts	debtor, creditor, account, payment obligation, settlement, charge, counterparty.
ISO 20022 elements	payment status, reason code, instructed/settlement amount, debtor/creditor agent, remittance information.
Allowed AI actions	Explain, cite, summarize, recommend repair checklist, pre-fill repair form.
Prohibited AI actions	Directly execute high-value repair, alter ledger, close case without approval.
Eval dimensions	status interpretation, wrong-party prevention, repair precision, citation correctness, approval path.
Audit evidence	message id, field citation, rulebook version, ledger query, case id, approval id, output id.

9. Template: Semantic Gap Log

Use this when internal terminology, reference model terminology and system fields do not align.

Gap ID	Internal term/field	Reference model anchor	Gap type	Business risk	AI impact	Resolution decision	Owner	Evidence
SG-001	`customer_type = business`	FIBO legal entity / organization / party role	Concept ambiguity	KYC rules differ by legal structure	AI may request wrong documents	Split into legal entity type, customer segment and relationship role	KYC data owner	Glossary update, data contract
SG-002	`payment_status = failed`	ISO 20022 status/reason semantics	Status compression	Repair path depends on reason	AI may recommend wrong repair	Store status plus reason code and rail-specific interpretation	Payments owner	Message mapping
SG-003	`balance`	FIBO balance/exposure/facility concepts	Overloaded metric	Credit exposure understated	Lending AI may misstate risk	Separate booked balance, outstanding exposure, available facility	Credit data owner	Semantic model change

Gap types:

Gap type	Meaning
Concept ambiguity	Same term has multiple business meanings.
Role ambiguity	Entity role is unclear, such as customer vs beneficiary vs owner.
Status compression	Multiple workflow or message states collapsed into one internal code.
Field overload	One field stores different concepts under different conditions.
Missing lineage	Field cannot be traced to authoritative source or message element.
Temporal mismatch	Effective date, posting date, settlement date or reporting date is unclear.
Jurisdiction mismatch	Rule or concept differs by region but field does not encode region.

10. Template: Domain Service Card

Use this to define AI-safe service/domain boundaries before exposing tools to an agent.

Section	Questions
Service domain name	What banking service domain or internal capability is represented?
Business responsibility	What business outcome or state does this domain own?
Source-of-truth status	Is it authoritative, derived, cache, orchestration or presentation layer?
Key entities	Which parties, accounts, agreements, products, cases, messages or transactions are in scope?
Owned actions	Which actions can this domain execute or approve?
Read APIs/events	What can AI read? What sensitivity and entitlement apply?
Write APIs/events	What can AI pre-fill or execute? What approval is required?
Reference model mapping	Which BIAN service domain, FIBO concepts and ISO 20022 elements apply?
Data contracts	Required schema, semantic, freshness, quality and retention expectations.
AI use policy	Allowed use, prohibited use, required citations, refusal conditions.
Controls	HITL, maker-checker, rate limits, transaction thresholds, audit logs, rollback.
Eval obligations	Domain-specific tests before release and monitoring after release.
Incident response	Who responds when AI misuse, wrong answer, wrong action or data leakage occurs?

Example summary:

Field	Example
Service domain	Payment Exception Case Management
Responsibility	Owns exception case lifecycle, assignment, status, closure reason and operational SLA.
Source-of-truth	Authoritative for exception case state, not authoritative for payment settlement or ledger posting.
AI policy	AI may summarize and recommend closure reason; human must approve closure.
Controls	Role-based access, case note citation, maker-checker for closure, immutable audit log.

11. Template: AI Use Case Fit

Dimension	Score 1	Score 3	Score 5
Service boundary clarity	Use case crosses many domains without owner	Domains known but action boundaries incomplete	BIAN-style domain map and owners clear
Concept maturity	Key terms ambiguous	Glossary exists but not enforced	FIBO/internal ontology mapping exists with validation
Message/data grounding	Mostly free text	Structured data exists but lineage incomplete	ISO/internal message mapping and field-level lineage available
Risk/action control	AI action scope unclear	HITL exists for some actions	Read/recommend/pre-fill/execute gates explicit
Eval readiness	Manual review only	Some golden examples	Domain, concept, message, permission and business outcome evals defined
Audit replay	Prompt/output logs only	Source citations exist	Source, concept, message field, tool call, approval and version replay available
Business value	Interesting demo	Workflow pain exists	Baseline metrics, cost/risk impact and owner committed

Decision guidance:

Total score	Decision
7-14	Do not build production AI. First resolve domain, semantic or control gaps.
15-24	Limited pilot with read-only or draft-only capabilities.
25-31	Controlled production candidate with release gates and monitoring.
32-35	Strong portfolio and enterprise scaling candidate, assuming data/security approvals pass.

12. Template: Portfolio Evidence Pack

Use this to convert a case into interview-ready evidence.

Evidence	What to include	Why it matters
Reference Model Mapping Matrix	BIAN domains, FIBO concepts, ISO 20022 fields, internal systems	Shows business architecture discipline, not prompt-first thinking
Semantic Gap Log	Internal term mismatches and resolution decisions	Shows senior BA/architect ability to remove ambiguity
Domain Service Cards	AI-safe service boundaries and tool/action scopes	Shows agent governance and integration maturity
RAG Boundary Design	source registry, authority, domain tags, concept tags, message tags	Shows retrieval is governed by banking semantics
Tool Contract Spec	inputs, outputs, permissions, approval, idempotency, rollback, audit	Shows AI tool use is production-grade
Eval Matrix	domain fit, concept correctness, message grounding, citation, permission, business KPI	Shows requirements-to-eval maturity
Risk-Control Matrix	NIST AI RMF mapping, HITL, maker-checker, monitoring, incident response	Shows governance and auditability
Executive Memo	options, recommendation, cost/risk/value, release gates	Shows PM-level decision framing

Portfolio claim example:

I designed a payments exception AI copilot using BIAN-style service boundaries, ISO 20022 message semantics and FIBO-aligned financial concepts. The result was not just a chatbot, but a governed workflow assistant with field-level evidence, maker-checker controls, message-grounding evals and an audit replay pack.

13. Requirements-to-Eval Pattern

Requirement type	Example requirement	Reference model anchor	Eval
Domain boundary	AI must not combine payment repair execution with ledger adjustment	BIAN service separation	Tool-call policy test rejects cross-domain action
Concept correctness	AI must distinguish beneficial owner from authorized signer	FIBO concept mapping	KYC concept confusion test
Message grounding	AI must cite payment status and reason code when explaining exception	ISO 20022 message semantics	Message field citation precision
Retrieval boundary	AI must retrieve only rulebooks applicable to rail, jurisdiction and effective date	ISO 20022 + internal policy metadata	Retrieval filter pass rate
Evidence quality	High-risk answer must cite policy/source fact, not model memory	FIBO/source authority	Unsupported claim rate
Human oversight	AI may pre-fill repair form but cannot execute without approval id	BIAN tool boundary + NIST Govern/Manage	Approval-gate simulation
Monitoring	Drift in reason code distribution triggers review	ISO 20022 status/reason mapping	Drift alert and incident workflow

13.1 Eval Slices

Slice	Why it matters
Product line	Deposit, card, loan, payment, wealth rules differ.
Jurisdiction	KYC, lending, payments and advice controls differ by region.
Customer segment	Retail, SME, corporate, HNW and vulnerable customer rules differ.
Channel	Branch, mobile, call center, API and batch operations have different evidence.
Message type	Payment status, investigation and reporting messages have different meanings.
Service domain	Read-only inquiry and state-changing action require different controls.
Authority level	Policy, SOP, FAQ, system fact and analyst note cannot be treated equally.

14. Architecture Pattern: Reference-Model-Grounded AI Control Plane

flowchart TB
  subgraph Ref[Industry and Enterprise Reference Models]
    BIAN[BIAN service landscape]
    FIBO[FIBO ontology subset]
    ISO[ISO 20022 message semantics]
    INT[Internal glossary and data standards]
  end

  subgraph Gov[Governance and Design Assets]
    MAP[Reference model mapping matrix]
    GAP[Semantic gap log]
    CARD[Domain service cards]
    POLICY[AI use policies]
  end

  subgraph Data[Knowledge, Data and Messages]
    SRC[Policy/SOP/source registry]
    MSG[Message parser and field lineage]
    SEM[Semantic layer and data contracts]
    GRAPH[Ontology/knowledge graph]
  end

  subgraph AI[AI Runtime]
    RET[Governed retrieval]
    EVAL[Eval harness]
    AGENT[Agent orchestration]
    TOOLS[Domain tools]
  end

  subgraph Evidence[Controls and Evidence]
    HITL[HITL and maker-checker]
    LOG[Audit log and replay]
    MON[Monitoring and drift]
    RMF[NIST AI RMF evidence]
  end

  BIAN --> MAP
  FIBO --> MAP
  ISO --> MAP
  INT --> GAP
  MAP --> CARD
  GAP --> SEM
  CARD --> POLICY
  POLICY --> RET
  SRC --> RET
  MSG --> RET
  MSG --> SEM
  SEM --> GRAPH
  GRAPH --> RET
  RET --> AGENT
  EVAL --> AGENT
  AGENT --> TOOLS
  TOOLS --> HITL
  HITL --> LOG
  AGENT --> LOG
  LOG --> MON
  MON --> RMF

14.1 Control Plane Capabilities

Capability	Minimum expectation
Reference model registry	Stores approved mappings to BIAN domains, FIBO concepts, ISO 20022 messages and internal terms.
Semantic policy engine	Enforces concept, domain, jurisdiction, effective-date and authority filters before retrieval or tool use.
Tool gateway	Requires domain card, entitlement, structured input schema, idempotency, approval and audit policy.
Message grounding service	Parses and validates payment/securities messages before AI consumption.
Eval harness	Tests domain fit, concept correctness, message grounding, source citation, permission and action gating.
Audit replay service	Reconstructs prompt, sources, concept definitions, message fields, tool calls, approvals and model version.
Governance workflow	Routes mapping changes, semantic gap decisions, tool changes and release gates to accountable owners.

15. Common Anti-Patterns

Anti-pattern	Why it fails	Better architecture
"Enterprise banking chatbot" as first scope	No service domain boundary, permissions too broad, eval impossible	Start with a bounded workflow such as payment exception or KYC remediation
Uploading standards PDFs into RAG	Standards become ungoverned text and may be misapplied	Use standards as mapping anchors, not raw answer source unless validated
Exposing all APIs to an agent	Tool misuse and cross-domain state changes	Tool gateway with domain service card and action scopes
Treating ISO 20022 as only technical XML	Loses business semantics and field-level evidence	Build message semantic map and field-to-decision lineage
Treating FIBO as a full enterprise ontology project	Too heavy, slow and disconnected from use case value	Use FIBO subset for high-risk concepts and semantic validation
Treating BIAN as a replacement for internal architecture	BIAN is a reference model, not your actual org/system map	Map BIAN to internal capabilities, systems, owners and APIs
Measuring only answer helpfulness	Does not catch financial concept errors or wrong message interpretation	Add domain, concept, message, permission and action evals
Saying "human in the loop" without tool gates	Human review becomes a phrase, not a control	Require approval id, role, threshold, audit log and exception handling

16. Interview Expression

16.1 30-second Answer

For financial AI, I use industry reference models as architecture controls. BIAN helps me define banking service boundaries and tool scopes. FIBO helps me control financial concepts and entity relationships. ISO 20022 helps me ground payments and securities data in structured message semantics. Then I connect these to RAG boundaries, semantic data contracts, evals, human approval gates and audit evidence.

16.2 2-minute Answer

In a bank, a generic AI assistant is risky because banking terms, service ownership and message states are highly specific. My approach is to start with the reference model stack. First, I use BIAN-style service domains to map the use case to banking capabilities and decide which domains are read-only, which can recommend, and which can execute only after approval. Second, I use FIBO or an internal FIBO-aligned glossary to control concepts like party, customer, beneficial owner, facility, exposure, payment obligation or instrument, so the model does not confuse roles. Third, for payments or securities operations, I use ISO 20022 message semantics to ground status, party, account, amount, reason code and remittance fields.

This changes the product architecture. RAG is not just vector search; it is filtered by domain, concept, message type, jurisdiction and effective date. Agent tools are not broad APIs; they are domain-scoped contracts with entitlement, approval, idempotency and audit logging. Eval is not just answer quality; it includes concept correctness, message grounding, citation precision, permission leakage and action-gate tests. The result is an AI product that can be explained to business owners, engineers, risk, compliance and audit with the same evidence pack.

16.3 Follow-up Questions

Interview question	Strong answer angle
Why not just use internal data dictionaries?	Internal dictionaries are necessary but often system-specific. Reference models provide cross-domain semantics and help expose hidden gaps between systems, policies and messages.
Would you implement all of FIBO?	No. I would implement a use-case-driven subset for high-risk concepts, then map internal glossary terms and test concept confusion in eval.
Is BIAN a microservice blueprint?	No. It is a banking reference model for service boundaries and capabilities. I would map it to internal systems and ownership, not copy it mechanically.
How does ISO 20022 help AI beyond payments formatting?	It provides structured business semantics for message status, party roles, account references, reason codes and remittance context, which can ground explanations and audit evidence.
How do you prevent an agent from doing too much?	I bind tools to service domains, split read/recommend/pre-fill/execute actions, require approval ids for state changes and monitor tool-call policy violations.
What would you show in a portfolio?	A reference model mapping matrix, semantic gap log, domain service cards, RAG boundary design, tool contract, eval matrix and risk-control evidence pack.

16.4 Executive Framing

The business value is not that we "use BIAN/FIBO/ISO 20022". The value is reduced ambiguity, safer automation, faster integration, better audit readiness and reusable semantic assets across AI use cases.

17. Personal Capability Statement

Use this as a concise positioning line for portfolio or interviews:

I can design banking AI products using industry reference models: BIAN for capability and service boundaries, FIBO for financial semantics, ISO 20022 for message-level grounding, and NIST AI RMF for risk governance. My deliverables connect product requirements to RAG boundaries, tool contracts, semantic data models, eval gates, human controls and audit evidence.