AI 底层逻辑 / 经典论文
AI Open Banking / Open Finance：授权数据共享架构
Consented financial data sharing 不是“AI 可以读取银行数据”。它是一套 purpose-bound、revocable、API-mediated trust architecture：把客户授权、第三方角色、API scope、数据质量、AI 允许用途、撤销传播和行动授权统一成运行时可执行的边界。
250 行ai-foundations/papers/135-ai-open-banking-open-finance-consented-data-sharing-architecture.md
AI Open Banking / Open Finance / Consented Data Sharing Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_OPEN_BANKING_OPEN_FINANCE_CONSENTED_DATA_SHARING_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论 open banking / open finance 生态中 AI 使用 customer-authorized financial data 的产品与架构设计，不构成法律、监管、CFPB 1033 适用性、合规期限、实体义务、授权充分性、隐私影响评估、模型验证、信息安全认证、供应商推荐或业务上线结论。Data provider、authorized third party、aggregator、service provider、covered data、合规日期、诉讼影响和监管解释必须由 Legal/Compliance 基于官方来源的最新状态判断。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| CFPB Personal Financial Data Rights final rule | https://www.consumerfinance.gov/rules-policy/final-rules/required-rulemaking-on-personal-financial-data-rights/ | 用作 U.S. personal financial data rights、secure and reliable consumer / authorized third-party data access、privacy protections、open banking 方向的官方锚点 |
| CFPB Regulation 1033 / Personal Financial Data Rights | https://www.consumerfinance.gov/rules-policy/regulations/1033/ | 用 § 1033 的 covered data、developer interface、authorized third party、authorization disclosure、third-party obligations、revocation 和 recordkeeping 结构组织架构问题 |
| CFPB Personal financial data rights compliance resource | https://www.consumerfinance.gov/compliance/compliance-resources/other-applicable-requirements/personal-financial-data-rights/ | 用作 rule status、implementation resources、official interpretations 和 regulatory-development watch 的入口; 不在本文推断适用性或期限 |
| CFPB guidance / circulars landing page | https://www.consumerfinance.gov/compliance/circulars/ | 用作 CFPB guidance / circulars / supervisory materials 的官方入口, 支持 horizon scanning 和 policy update workflow |
| FFIEC Authentication and Access to Financial Institution Services and Systems | https://www.ffiec.gov/press/pr081121.htm | 用 authentication、access risk assessment、layered security、MFA / equivalent controls、third-party / customer-permissioned entity access 风险组织 access controls |
| NIST Privacy Framework | https://www.nist.gov/privacy-framework | 用 privacy risk management、data processing purpose、governance、control design、customer trust 和 minimization 组织 privacy-by-architecture |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 思路组织 AI 风险识别、eval、monitoring、incident response 和 evidence |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、policy、roles、operation、performance evaluation、internal audit 和 continual improvement 建立 operating model |
核心导读
Consented financial data sharing 不是“AI 可以读取银行数据”。它是一套 purpose-bound、revocable、API-mediated trust architecture：把客户授权、第三方角色、API scope、数据质量、AI 允许用途、撤销传播和行动授权统一成运行时可执行的边界。
AI 改变的是从数据可携带到数据可决策的链条。Open banking API 让余额、交易、账户、账单和现金流数据可以进入 budget assistant、affordability review、subscription optimizer、fraud defense、RAG answer 或 agent workflow；但每一步都要问：数据是否仍在授权目的内，是否足够新鲜和准确，是否可以进入 feature store 或 vector index，是否允许训练，是否只是建议还是要提交动作，撤销后哪些 cache、embedding、session 和 derived feature 必须停止使用。
本篇的核心学习点是 consent control plane，而不是 connector integration。证据链要能重放 disclosure、consent receipt、OAuth grant、API call、normalization、feature policy、RAG source、AI run、human/action approval、customer message 和 revocation handling。治理边界必须把 data authorization 与 payment/account action authorization 分开，把 customer-requested service 与 cross-sell/training/secondary use 分开，把 API 可访问的数据与模型可使用的数据分开，并把 aggregator、developer app、AI platform 和 downstream processor 的责任显式化。
问题定义
Open banking / open finance 的架构变化不是从 screen scraping 换成 API，而是从 broad harvesting 走向 customer-authorized access、standardized contract、purpose-bound use、revocation、AI data-use boundary、fraud/third-party controls 和 evidence replay。
必须回答：
客户授权的是哪个 recipient，为哪个 requested product/service，哪些 data categories，多长时间，多高频率?
provider、recipient、aggregator、developer app、AI platform、downstream processor 分别是什么角色?
API contract 如何表达 scope、field semantics、quality、latency、error、revocation 和 evidence?
AI 是否只使用当前 purpose 授权的数据?
revocation 后 collection、cache、features、embeddings、agent sessions 如何停止或降级?
RAG over account data 是否做到 customer/purpose isolation、source citation、freshness 和 prompt-injection defense?
model features 是否有 allowed/prohibited uses?
fraud/scam controls 是否覆盖 malicious app、ATO、data exfiltration、agent overreach?
事后能否重放 consent、API calls、data transforms、AI run、decision、message 和 revocation handling?
边界原则：
Consented does not mean unlimited.
Available through API does not mean usable for every model.
Data portability does not mean downstream data resale.
Account history does not mean behavioral surveillance license.
AI personalization does not override purpose limitation.
Revocation must affect data, features, embeddings, agents and evidence.
核心原理/方法
Consent、authorization、authentication 必须分开：
| Layer | 问题 | Artifact |
|---|---|---|
| Customer disclosure | 客户是否看到 third party、service、data categories、duration、revocation? | disclosure version、UI capture |
| Express consent | 客户是否明确授权，记录可重放? | consent receipt、timestamp、channel、language |
| API authorization | client/aggregator 是否获得 scoped token? | OAuth grant、scope、token hash、client credential |
| Runtime entitlement | 每次 API/RAG/feature/tool call 是否检查 consent state and purpose? | entitlement log |
| Revocation | 撤销是否停止 collection、通知 ecosystem、处理 cache/features/embeddings? | revocation receipt、propagation log |
| Action authorization | AI/app 要提交申请、支付、变更账户时是否另行批准? | action approval、transaction confirmation |
Use case data sharing passport：
use_case_id
customer_requested_product_or_service
data_provider
data_recipient
aggregator_if_any
data_categories
purpose
duration
frequency
consent_version
revocation_route
ai_allowed_uses
ai_prohibited_uses
retention_rule
evidence_bundle_id
Open banking data 必须携带 source、consent、purpose、freshness、quality、allowed uses、AI boundary、downstream sharing、retention 和 revocation action；否则进入 feature store 或 vector index 后会失去治理语义。
系统/架构模型
参考架构：
customer
-> consent and authorization disclosure UX
-> data recipient / developer app
-> aggregator or direct API connection
-> data provider developer interface
-> API gateway / auth / scope / rate limit
-> raw consent-bound data zone
-> normalization / quality / lineage service
-> purpose-bound feature store
-> customer-isolated vector / retrieval index
-> AI orchestration and tool policy
-> recommendation / decision / agent action workflow
-> human review / fraud / operations
-> customer communication
-> evidence ledger / monitoring / revocation service
核心组件：
| Component | 职责 |
|---|---|
| Consent registry | 记录 disclosure、scope、duration、revocation、AI allowed/prohibited uses，并作为 runtime enforcement source |
| Developer onboarding portal | app registration、certification、security review、sandbox、contract、data-use attestation |
| API gateway | client auth、token validation、scope、rate limit、logging、anomaly monitoring |
| Data normalization | merchant/category mapping、dedup、timezone、currency、pending/posted status，并保留 lineage |
| Quality service | completeness、freshness、accuracy feedback、source uncertainty |
| Feature policy service | allowed decisions、prohibited decisions、training flag、revocation action |
| Consent-aware retriever | 按 customer、purpose、account、time window 检索 account data |
| Agent action gate | read/reason/recommend/prepare/submit/value movement 分级授权 |
| Fraud/security layer | malicious recipient、consent phishing、ATO、exfiltration、APP scam、synthetic affordability |
| Evidence ledger | 链接 consent、API、data、AI、human、final message、revocation |
关键机制与取舍
Role clarity：
| Role | AI 架构问题 |
|---|---|
| Customer | 是否理解数据如何用于 AI，能否查看、撤销、投诉和纠错 |
| Data provider | developer interface 是否安全、可靠、可监控 |
| Authorized data recipient | 是否只收集、使用、保留合理必要数据 |
| Aggregator | 是否有 contract pass-through、security、revocation propagation、accuracy and incident controls |
| Developer app | 是否通过 onboarding、security、data-use attestation、monitoring |
| AI system | 是否只能访问授权上下文，feature/purpose 是否 runtime enforced |
| API platform | scope 是否细到 data category/purpose，error/revocation 语义是否契约化 |
| Fraud/security | 是否监控 third-party access pattern 和 permissioned entity risk |
RAG over account data：
user question
-> authenticate session
-> check consent and purpose
-> determine allowed accounts/categories/window
-> retrieve source rows
-> apply freshness and quality filters
-> ground answer with citations and caveats
-> block prohibited advice/actions
-> capture AI run and sources
Agent boundary：
| Agent capability | Example | Required control |
|---|---|---|
| Read | 查询余额、交易、账单 | consent + scope + session auth |
| Reason | 总结现金流、找订阅 | grounded RAG + caveats |
| Recommend | 预算提醒、账单提示 | recommendation boundary |
| Prepare | 预填申请、生成 dispute/hardship package | source citation + customer review |
| Submit | 提交申请、开 case | action-bound approval |
| Initiate value movement | payment、transfer | separate payment authorization + scam controls |
| Change account | 更新地址、取消订阅 | business authorization + confirmation |
关键取舍：
| Decision | 强边界 |
|---|---|
| 请求哪些数据 | 最小 data categories、accounts、time window，绑定 requested service |
| 访问多久 | purpose-specific duration、reauthorization、runtime consent check |
| 能否训练模型 | 默认不能；需单独 policy/consent、de-identification、model-risk approval |
| 能否 cross-sell | 仅在单独许可且符合客户期待和政策时 |
| aggregator 选择 | 评估 coverage、consent UX、security、revocation、data quality、exit |
| revocation | 不只是 delete token，还要处理 cache、features、embeddings、agent sessions |
证据与控制
Consent object：
consent_id
customer_ref
data_provider_id
data_recipient_id
aggregator_id
requested_product_or_service
data_categories
field_scope
purpose
collection_frequency
duration_limit
granted_at / expires_at / revoked_at
revocation_method
language
disclosure_version
ai_allowed_uses
ai_prohibited_uses
training_allowed_flag
downstream_sharing_allowed_flag
evidence_bundle_id
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 建立政策/合规基础 | review role、jurisdiction、data type、product scope | approval record、interpretation memo |
| 最小化收集 | data category/time-window/account selection tied to requested service | minimization matrix、API scopes |
| informed authorization | 清楚披露 recipient、provider、service、categories、duration、revocation | disclosure version、consent receipt |
| runtime consent enforcement | API、feature store、RAG、agent tools 全部 entitlement check | consent check logs |
| revocation | easy revoke、ecosystem notification、collection stop、derived-data handling | revocation receipt、propagation log |
| API access governance | client registration、auth、token binding、scope、rate limit、anomaly | developer record、gateway logs |
| third-party risk | due diligence、contract restrictions、audit rights、incident obligations、exit | TPRM file |
| data quality | freshness、completeness、dedup、lineage、quality scores | quality dashboard |
| AI feature boundary | allowed/prohibited uses for features、inferences、training、decisions | feature policy、model card、eval |
| secure RAG | customer/purpose isolation、citations、prompt injection controls | retrieval trace、RAG eval |
| control agent action | separate action-bound approval | approval id、action hash |
| audit replay | link consent、API、data、AI、human、final message | evidence bundle |
金融零售/AI产品场景
- AI cash-flow assistant：客户授权 90 天交易和余额用于预算提醒；RAG 只能使用授权窗口内 source rows，撤销后禁用 refresh、features 和 embeddings。
- Account verification：open banking account ownership signal 进入 payout setup；不能自动替代完整 KYC。
- Affordability review：收入/交易数据用于客户请求的申请或 hardship review；model features 标记 allowed decisions 和 prohibited decisions。
- Subscription optimization：agent 可找出 recurring payments 和起草取消步骤，但取消或变更账户需要 action approval。
- Fraud/scam defense：客户被诱导授权 malicious app，系统通过 developer reputation、domain warning、access anomaly 和 revocation notification 防护。
- Third-party app ecosystem：developer 必须通过 onboarding、scope review、monitoring、incident and exit controls。
反模式
| 反模式 | 风险 | 更好的控制 |
|---|---|---|
| consent screen 当 blanket waiver | 授权被解释成无限使用 | purpose-bound consent object + runtime enforcement |
| generic data lake ingestion | data 失去 consent/purpose/revocation metadata | consent-bound data zone and lineage tags |
| RAG indexes all account data | cross-purpose and post-revocation leakage | isolated entitlement-aware retrieval |
| transaction 推断敏感属性 | privacy harm and unfairness | sensitive inference policy and prohibited uses |
| revocation 只删 token | cache/features/embeddings 继续使用 | lifecycle propagation tests |
| API error 当金融事实 | stale/failed data 伤害客户 | freshness gates and error-aware prompts |
| aggregator 只看覆盖率 | hidden security/quality/exit risk | TPRM and architecture review |
| 默认模型训练 | 违反目的期待 | explicit AI training policy |
| data consent 当 action authorization | 未授权付款/申请/账户变更 | separate action approval |
| complaint 无 evidence chain | 无法解释或补救 | consent-to-AI-to-decision bundle |
最终心智模型
Open banking AI 的核心不是 connector，而是 consent control plane。成熟系统应能证明：每个 AI answer、feature、recommendation 或 agent action 只使用客户为该目的授权的数据，经由受治理 API 和第三方，在 freshness/quality 可解释的前提下运行，撤销能传播到数据、特征、索引和 agent，会话有 fraud/scam 控制，推断与事实分开，证据足以支撑审计、投诉和客户信任。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。