AI Open Banking / Open Finance / Consented Data Sharing Architecture 解读

面向对象: Advanced AI PM / Senior BA / Product Architect / Enterprise Architect / Financial Retail Architect / Data Product Owner / API Platform Lead / Fraud Risk Architect / Privacy / Compliance / Model Risk / Third-Party Risk / Customer Trust Lead。 核心问题: AI 系统如何在 open banking / open finance 生态中使用 customer-authorized financial data, 既能提供真实客户价值, 又能控制 consent、data minimization、revocation、API contract、third-party risk、RAG grounding、model feature boundary、fraud/scam、audit evidence 和 customer trust? 学习目标: 建立 consented data sharing architecture、data provider / data recipient / aggregator role model、developer onboarding、API ecosystem governance、AI/RAG over account data、feature boundary、data quality lineage、revocation handling、fraud controls、third-party oversight、evidence replay 和 senior PM/architect decision framework。

0. Disclaimer

本文是学习、架构训练和作品集材料, 不构成法律意见、监管意见、CFPB 1033 适用性判断、合规期限判断、实体义务判断、第三方授权充分性判断、隐私影响评估结论、模型验证报告、信息安全认证、消费者通知建议、供应商推荐或业务上线批准。

正式项目必须由 Legal、Compliance、Privacy、Information Security、Fraud Risk、Financial Crime、Model Risk、Data Governance、API Platform、Third-Party Risk Management、Vendor Management、Customer Experience、Operations、Accessibility、Product Owner、Architecture、Internal Audit 和必要外部顾问共同判断。CFPB 1033 或其他 open banking / open finance 要求的具体适用性, 取决于 product、entity role、data type、customer relationship、jurisdiction、rule status、litigation / regulatory developments、contract structure、partner role、data flow、use case 和 Legal / Compliance interpretation。

本文只讨论架构和治理方法。它不推断任何机构是否是 data provider、authorized third party、data aggregator、service provider 或 covered entity; 不推断任何数据字段是否属于 covered data; 不推断任何合规日期、宽限期、豁免、诉讼影响或监管解释。所有 rule-status 和 implementation 相关问题必须以 Legal / Compliance 对官方来源的最新解释为准。

---

Source Anchors

一句话:

Consented financial data sharing is not "AI can read bank data". It is a purpose-bound, revocable, API-mediated trust architecture that lets AI consume only authorized data, reason within governed boundaries, and act only with explicit customer and policy authorization.

---

1. Thesis

AI open banking / open finance 的核心架构变化, 不是把 screen scraping 换成 API, 也不是把银行流水丢给 LLM 总结。真正变化是:

from: broad data harvesting + credential sharing + opaque enrichment
to: customer-authorized access + standardized API contract
  + purpose-bound use + revocation + evidence replay
  + AI data-use boundary + fraud and third-party controls

成熟架构必须同时回答十二个问题:

1. 客户授权的是哪个 data recipient, 面向哪个 requested product or service, 访问哪些 data categories, 多长时间, 多高频率?
2. data provider、data recipient、data aggregator、developer app、AI platform 和 downstream processor 各自是什么角色?
3. API contract 如何表达 scope、field semantics、quality、latency、pagination、error、consent state、revocation 和 incident behavior?
4. AI 是否只使用为当前 purpose 授权的数据, 是否阻止 cross-sell、targeted advertising、unrelated profiling 和 unrestricted training?
5. 客户能否像授权一样容易地 revoke, revoke 后 collection、use、retention、cache、vector index、features 和 agent sessions 如何停止或降级?
6. data minimization 是产品策略、API scope、feature engineering、prompt grounding 和 retention policy 的共同约束, 还是只是隐私文案?
7. RAG over account data 是否做到 tenant / customer isolation、source citation、freshness、entitlement check、prompt-injection defense 和 evidence capture?
8. model features 是否有 allowed uses / prohibited uses, 是否把 transaction patterns 变成未经授权的 sensitive inferences?
9. fraud / scam controls 是否覆盖 account takeover、authorized push payment scam、malicious third-party app、data exfiltration、synthetic behavior 和 agent overreach?
10. developer onboarding 是否有 security, privacy, data-use, operational, financial crime, model-risk 和 exit controls?
11. 客户价值是否足够清楚, 让客户理解自己为什么要分享数据, 以及分享后能获得什么?
12. 事后能否重放 authorization disclosure、consent receipt、API calls、data transformations、AI run、human decision、customer communication 和 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.

---

2. Why It Matters

金融零售 AI 正把 open banking 从 data-access program 推向 AI decision and action ecosystem:

高级 PM / Architect 的问题不是:

How do we plug Plaid-like data into the AI feature?

而是:

For this customer-requested outcome,
what data is necessary,
which party is authorized to collect it,
how is access technically constrained,
how will AI use be bounded and evidenced,
what happens on revocation,
and how do we prove the ecosystem behaved as promised?

---

3. Consented Data Sharing vs Unrestricted Data Harvesting

consented data sharing 与 unrestricted data harvesting 的边界必须写进产品、API、数据和模型架构, 不能只写进 privacy notice。

判定测试:

If the customer cannot explain who gets what data for what purpose,
and the institution cannot technically enforce that boundary,
the architecture is data harvesting with a consent screen.

---

4. Ecosystem Role Model

AI open banking 必须先做 role clarity, 再做 data flow。一个机构可能在不同旅程中同时扮演 data provider、data recipient、aggregator client、model operator 或 service provider。

架构上建议把每个 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

---

5. Data Scope and Open Finance Taxonomy

open banking 常从账户和支付相关数据起步, open finance 会扩展到更广泛的金融生活图谱。AI 架构必须避免把范围扩大解读为“任何有用数据都可以拿”。

Design rule:

Each data family must carry:
source, consent, purpose, freshness, quality, allowed uses,
AI use boundary, downstream sharing rule, retention, revocation action.

---

6. Consent and Authorization Architecture

Consent 是客户允许访问和使用数据的表达。Authorization 是系统和政策允许某个 actor 做某件事。Authentication 是确认当前 session / user / client 的控制权。三者不可混用。

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

弱设计:

Customer clicked "Connect bank"; all transaction data enters generic data lake.

强设计:

Customer authorized cash-flow assistant to access transaction history and balance
from Bank A for 90 days.
API tokens are scoped.
RAG and feature store check consent before use.
Cross-sell, targeted ads and model training are prohibited unless separately authorized and approved.
Revocation stops collection, disables derived features where required, and closes agent sessions.

---

7. Reference Architecture

参考架构:

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

关键组件:

架构边界:

consent registry
  -> entitlement checks
  -> API scopes
  -> data lake tags
  -> feature store policies
  -> vector index lifecycle
  -> prompt/tool policies
  -> evidence retention

如果 consent 只在前端展示, 不进入上述控制链, 就不是 production-grade consented data sharing。

---

8. API Contract and Developer Onboarding

Open banking 的产品体验由 API contract 决定, 不由单个 AI prompt 决定。API contract 应覆盖数据语义、可靠性、授权状态、错误、撤销和运营承诺。

8.1 API Contract

8.2 Developer / Third-Party Onboarding

Developer onboarding 要把“能调用 API”变成“能被治理”。对于 AI app, 还要额外收集:

model providers
prompt / tool architecture
whether customer data enters model training
feature store and vector store lifecycle
customer-facing claims
human review triggers
advice / recommendation boundaries
eval evidence
complaint and correction flow

---

9. Data Quality, Enrichment and Lineage

Open banking data 的可用性不等于高质量。交易数据尤其容易出现 merchant normalization、pending/posted duplication、category inconsistency、refund matching、subscription detection、timezone、currency、joint account 和 business/personal mix 的问题。

Enrichment 要分层:

raw_provider_data
normalized_data
enriched_data
derived_features
model_inferences
customer_visible_answer

每层都应保留:

source
transformation_version
confidence
consent_id
purpose
quality_score
freshness
allowed_uses
retention_rule
revocation_action

高级原则:

Never let enrichment erase consent, uncertainty or lineage.

---

10. Model Feature Boundaries

AI 使用 open banking data 最常见的风险, 是把交易历史变成无边界的行为画像。Feature boundary 要在 feature store、model serving、RAG retrieval 和 policy engine 中可执行。

Feature record 建议:

feature_name
source_data_categories
consent_purpose
customer_requested_service
allowed_products
allowed_decisions
prohibited_decisions
model_ids
human_review_required
fairness_review_required
retention
revocation_action
evidence_refs

不要只问“模型能不能预测”。要问:

Should this feature exist under this customer authorization?
Can the customer understand the value?
Can the institution explain the use?
Can revocation unwind future use?
Can monitoring detect misuse?

---

11. RAG over Account Data

RAG over account data 是高价值场景, 也是高风险场景。账户数据不是通用知识库, 它是 consent-bound, customer-specific, time-sensitive financial evidence。

11.1 Safe RAG Pattern

user question
  -> authenticate user/session
  -> check consent and purpose
  -> determine allowed accounts/data categories/time window
  -> retrieve source transactions/balances/terms
  -> apply data quality/freshness filters
  -> ground answer with citations and caveats
  -> block prohibited advice/actions
  -> capture AI run and sources

11.2 RAG Controls

弱回答:

"You can afford this loan because your bank data looks healthy."

强回答:

"Based on transactions you authorized for this budgeting feature,
your average monthly inflow over the selected three-month period was X
and recurring obligations we detected were Y.
This is a budgeting estimate, not a credit approval or financial advice.
Some transactions may be pending or miscoded."

RAG 不应:

• 使用 revoked consent 的历史 embeddings 继续回答。
• 把 transaction memo 当成绝对事实。
• 从交易推断敏感属性并用于 eligibility。
• 让 agent 自动发起付款或申请而无 action approval。
• 把单一账户数据说成客户完整财务状况。
• 在投诉中无法列出支撑回答的 source rows。

---

12. Agentic AI and Action Boundaries

AI agent 可以读、解释、建议, 但“行动”必须单独治理。Open banking data access 不等于 payment authorization、product application authorization、account change authorization 或 advice acceptance。

Agent authorization record:

agent_id
workflow_run_id
customer_ref
data_access_consent_id
allowed_tools
allowed_data_categories
purpose
time_bound
action_bound_approval_required
approval_id
revocation_reference
human_review_triggers
evidence_bundle_id

关键原则:

Data access consent lets the agent know.
Action authorization lets the agent do.

---

13. Fraud, Scam and Access Controls

Open banking / open finance 会改变欺诈攻击面。数据分享本身可能成为 fraud vector, 尤其当恶意 app 获取客户授权、诈骗者诱导授权、或账户数据被用于 social engineering。

FFIEC-style design lessons:

• authentication risk assessment must include customers, employees, third parties, applications, service accounts and devices。
• MFA or equivalent strength controls should be risk-proportionate, especially for high-risk access and actions。
• layered controls matter because any single control can fail。
• customer-permissioned entity access needs specific risk assessment, monitoring, logging and reporting。

---

14. Governance Model

将 NIST Privacy Framework、NIST AI RMF 和 ISO/IEC 42001 组合成 operating model:

14.1 Operating Evidence

---

15. Product / Architecture Decisions

---

16. Control Matrix

---

17. Metrics and KRIs

Balanced executive dashboard:

Value: customers get useful financial outcomes.
Control: every data use is purpose-bound and revocable.
Safety: AI does not exceed consent, evidence or advice boundaries.
Trust: customers can understand, revoke and contest.
Ecosystem: APIs and third parties perform reliably and securely.
Evidence: each answer, recommendation and action can be replayed.

---

18. Failure Modes

---

19. Interview-Ready Takeaways

Q1: Consented data sharing 和 data harvesting 的本质区别是什么?

Consented data sharing 是 customer-requested service 下的 purpose-bound, scoped, revocable, evidenced data access。Data harvesting 是用宽泛同意收集尽可能多的数据, 再用于不相关目的、训练、广告、交叉销售或转售。架构区别在于 consent 是否进入 API scope、data lineage、feature store、RAG retrieval、agent tool 和 revocation enforcement。

Q2: AI open banking 架构中最重要的控制点是什么?

不是单一 API 或模型, 而是 consent registry 作为 runtime control plane。它要驱动 API scope、data lake tags、feature policies、RAG retrieval、agent permissions、retention and revocation。没有这个 control plane, AI 很容易把授权访问变成无边界使用。

Q3: 如何设计 RAG over account data?

按 customer、purpose、consent 和 time window 做隔离检索; 每次检索检查 entitlement; 输出必须引用 source rows 和 freshness; prompt-injection、sensitive inference、prohibited advice 和 agent action 都要受 policy engine 控制; revocation 后要停止未来检索并处理 embeddings lifecycle。

Q4: open banking 数据能否用于模型训练?

不能默认可以。训练用途要和 customer-requested service、授权、隐私政策、合同、适用法律/监管解释、de-identification、retention、model-risk approval 和 customer expectation 一起评估。尤其不能把为预算或账户验证授权的数据自动用于 unrelated model training。

Q5: Senior PM 如何评估 open banking AI feature?

同时看 value, consent, minimization, API reliability, data quality, third-party risk, model boundary, fraud/scam controls, revocation, evidence and customer trust。能上线的不是“模型很聪明”, 而是“客户授权清楚、系统边界可执行、撤销有效、结果可解释、风险可监控”。

---

20. Practical Templates

20.1 Use Case Data Sharing Card

20.2 API Scope Contract

Scope name:
Data category:
Fields:
Purpose:
Required consent version:
Maximum lookback:
Refresh frequency:
Freshness requirement:
Error semantics:
Revocation behavior:
Downstream sharing:
AI allowed uses:
AI prohibited uses:
Retention:
Evidence fields:
Owner:

20.3 AI Feature Boundary Record

Feature:
Source data categories:
Customer-requested service:
Consent ids:
Transformation lineage:
Allowed model ids:
Allowed decisions:
Prohibited decisions:
Sensitive inference risk:
Fairness review:
Human review triggers:
Revocation action:
Monitoring metric:
Evidence reference:

20.4 RAG Answer Evidence Record

Question:
Customer/session:
Consent check:
Purpose:
Retriever policy:
Source records:
Data freshness:
Quality caveats:
Prompt version:
Model version:
Output policy checks:
Final answer:
Customer message id:
Retention rule:

20.5 Revocation Runbook

Revocation event:
Customer:
Data recipient:
Data provider:
Aggregator:
Consent ids:
API token action:
Data collection stop time:
Cache action:
Feature action:
Embedding action:
Agent/session action:
Downstream notification:
Customer receipt:
Exceptions:
Evidence bundle:
Owner:

---

21. Final Operating Principle

成熟的 AI open banking / open finance architecture 可以用一个问题检验:

Can the institution prove that every AI answer, feature, recommendation and action
used only the financial data the customer authorized for that purpose,
through governed APIs and third parties,
with quality and freshness understood,
with revocation propagated,
with fraud and scam controls active,
with inferences separated from facts,
and with evidence sufficient for audit, complaint and customer trust?

如果答案不清楚, 企业不是缺一个 open banking connector。它缺的是 consent control plane、API ecosystem governance、AI feature boundary、RAG evidence、third-party risk controls、fraud/scam monitoring、revocation lifecycle 和 customer trust operating model。