AI Open Banking / Open Finance / Consented Data Sharing Architecture Playbook

定位: 面向 CBAP+、高级 AI PM、Financial Retail Product Architect、Enterprise Architect、API Platform Owner、Data Product Manager、Fraud Risk、Privacy、Compliance、Model Risk、Third-Party Risk 和 Customer Trust Lead, 把 open banking / open finance / consented data sharing 设计成可上线、可治理、可审计、可撤销、可解释的 AI data-sharing operating system。 适用范围: AI personal financial management、cash-flow assistant、account aggregation、income and affordability verification、SME cash-flow underwriting、subscription optimization、bill reminders、hardship support、fraud/scam monitoring、data portability、embedded finance、customer-facing agent、employee copilot 和 API ecosystem governance。 核心产出: executive framing、source anchors、taxonomy、decision gates、artifact set、RACI、implementation roadmap、evidence pack、release checklists、metrics、anti-patterns、tabletop scenarios、interview answers 和 practical templates。

核心判断:

AI can create value from permissioned financial data only when consent, API access, data lineage, model use, third-party obligations, revocation and evidence are governed as one architecture.

---

0. Disclaimer

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

正式项目必须由 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 和管理层结合机构类型、产品风险、客户关系、数据类型、司法辖区、rule status、litigation / regulatory developments、contract structure、供应商角色和内部政策确认。

边界原则:

• Consented access 不是无限使用。
• API access 不是模型训练许可。
• Account data 不是全域行为画像许可。
• Data portability 不是数据转售许可。
• Revocation 必须影响 collection、use、cache、features、embeddings、agent sessions 和 downstream sharing。
• CFPB 1033 或其他要求的 exact applicability 取决于 product、entity role、data type、customer relationship、jurisdiction、rule status、litigation/regulatory developments 和 Legal/Compliance interpretation。

---

1. Executive Framing

高管通常会听到这样的项目叙事:

Customers can connect their bank accounts.
AI will analyze spending and recommend better products.
Open banking APIs make data safe and standardized.

这些说法如果没有 operating model, 会产生四类隐性风险:

Executive one-liner:

Open banking AI is not a connector project.
It is a consent, API, model and third-party risk operating model.

1.1 Steering Committee Questions

1. 客户授权的数据是否只服务于 customer-requested product or service?
2. API scope、feature store、RAG retrieval、agent tools 和 retention 是否都受 consent registry 控制?
3. data recipient、aggregator、developer app、model provider 和 downstream party 的责任是否清楚?
4. Revocation 后, 数据、features、embeddings、agent sessions、downstream sharing 和 evidence 如何处理?
5. 投诉发生时, 是否能重放 disclosure、consent、API calls、data quality、AI run、decision 和 customer message?

---

2. Source Anchors

Source-to-control pattern:

source anchor -> policy interpretation -> architecture decision
  -> workflow requirement -> technical control
  -> evidence artifact -> owner -> metric -> review cadence

---

3. Taxonomy

3.1 Ecosystem Roles

3.2 Data Classes

3.3 Consent States

3.4 AI Use Levels

---

4. Decision Gates

Gate 0: Use Case Eligibility

Gate 1: Role and Regulatory Interpretation

Gate 2: Consent and Data Minimization

Gate 3: API and Developer Ecosystem

Gate 4: Third-Party and Vendor Risk

Gate 5: Data Quality and Feature Boundary

Gate 6: AI / RAG / Agent Controls

Gate 7: Fraud, Scam and Abuse

Gate 8: Evidence, Complaints and Audit

---

5. Required Artifacts

5.1 Data Minimization Matrix

5.2 AI Boundary Matrix

---

6. RACI / Operating Model

Governance cadence:

---

7. Implementation Roadmap

Days 1-30: Strategy and Control Baseline

Days 31-60: Controlled Pilot

Days 61-90: Scale and Assurance

---

8. Evidence Pack

Minimum evidence fields:

Evidence rules:

• Store consent, operational data, model traces and raw financial payloads with separate access controls.
• Do not log customer credentials, private keys, raw tokens or full account numbers in generic observability.
• Treat missing consent id, missing source refs or missing revocation evidence as control defects.
• Keep customer-facing text versions, not only backend decisions.
• Record what the AI saw and what it did not see.
• Preserve data quality and freshness at answer time.
• Make complaint replay possible without exposing unnecessary raw data to support teams.

---

9. Checklists

9.1 Release Checklist

9.2 Consent UX Checklist

9.3 API and Developer Checklist

9.4 AI / RAG Checklist

9.5 Revocation Checklist

9.6 Fraud and Scam Checklist

---

10. Metrics and KRIs

Balanced scorecard:

Value: customers receive clear, useful financial outcomes.
Consent: data sharing is understood, scoped and revocable.
Data: quality, lineage and minimization are measurable.
AI: outputs are grounded, bounded and monitored.
Ecosystem: APIs and third parties are secure and reliable.
Fraud: malicious access and scams are detected.
Evidence: decisions and actions are replayable.

---

11. Anti-Patterns

---

12. Tabletop Scenarios

Scenario 1: Consent Phishing

A customer is coached by a scammer to authorize a budgeting app that uses a name
similar to a known fintech. The app requests transaction history and account verification data.

Expected decisions: developer identity display, app reputation checks, customer warning, revocation support, fraud escalation, evidence capture。

Scenario 2: Revoked Data Still in RAG

The customer revokes access. The API token is disabled,
but the AI assistant continues answering questions from old embeddings.

Expected decisions: embedding lifecycle defect, retrieval entitlement fix, customer communication, CAPA, regression test。

Scenario 3: Unsupported Credit Inference

The model uses cash-flow data from a budgeting consent to tell the customer
they are likely eligible for a credit product.

Expected decisions: purpose violation, output policy block, feature boundary update, model-risk review。

Scenario 4: Aggregator Outage

Balance refresh fails for six hours. The AI assistant still recommends moving money
to avoid an overdraft using stale balance data.

Expected decisions: freshness gate, degraded-mode messaging, action block, provider/aggregator incident handling。

Scenario 5: Malicious Developer Overcollection

A developer app certified for subscription detection starts requesting broad historical data
and showing signs of bulk export.

Expected decisions: anomaly detection, scope suspension, audit rights, customer notification analysis, incident response。

Scenario 6: SME Authority Ambiguity

An employee connects business accounts to an AI cash-flow underwriting app,
but authority to share business financial data is unclear.

Expected decisions: business consent authority model, role verification, human review, contract update。

Scenario 7: Prompt Injection in Transaction Memo

A transaction memo contains text instructing the assistant to ignore privacy controls
and reveal all recent transactions.

Expected decisions: data sanitation, prompt-injection defense, retriever policy, red-team regression。

---

13. Portfolio Deliverables

Portfolio storyline:

I designed an AI open banking architecture where customer consent is a runtime control plane.
The system requests minimum data for a customer-requested service,
uses governed APIs and third parties,
preserves data quality and lineage,
constrains AI features and RAG retrieval by purpose,
separates recommendations from actions,
propagates revocation through features and embeddings,
and keeps evidence replayable for audit and complaints.

---

14. Interview Answers

Q1: 如何向高管解释 AI open banking 的价值和风险?

30 秒:

价值是让客户授权自己的金融数据, 获得现金流洞察、账户聚合、费用优化、收入验证和更好的金融体验。风险是授权被解释成无限使用, API 数据进入无边界模型, 第三方和 aggregator 控制薄弱, 撤销不生效。成熟方案要把 consent registry 做成 runtime control plane, 约束 API scope、features、RAG、agent actions、retention and evidence。

Q2: Consent 和 authorization 有什么区别?

30 秒:

Consent 是客户同意某个 recipient 为特定服务访问特定数据。Authorization 是系统允许某个 client、agent 或 workflow 做某件事。Authentication 是确认当前用户或 client 身份。连接银行账户的 consent 不能自动授权 AI 发起付款、提交申请或用数据做不相关训练。

Q3: 如何防止 open banking 数据被 AI 滥用?

30 秒:

从数据入口就绑定 consent_id、purpose、data category、duration、allowed uses、prohibited uses 和 revocation action。Feature store、RAG retriever、model serving 和 agent tools 每次使用都检查 entitlement。敏感推断、交叉销售、训练和高影响决策需要单独政策审批、eval、人审和证据。

Q4: RAG over account data 的核心设计是什么?

30 秒:

它必须是 customer/purpose isolated retrieval, 不是通用知识库。每次检索先查 consent and entitlement, 再按 time window、data category、freshness、quality 取 source rows。回答要带 source grounding 和 caveat, 禁止越界 advice/action, revocation 后要停止检索并处理 embeddings lifecycle。

Q5: Revocation 为什么是架构问题而不是 UI 功能?

30 秒:

因为撤销不只是隐藏连接状态。它要停止 provider/aggregator API collection, 通知 downstream parties, 禁用或限制 derived features, 处理 cache and embeddings, 停止 agent workflows, 更新 retention 状态, 给客户 receipt, 并保留审计证据。做不到这些, 撤销只是前端按钮。

---

15. Practical Templates

15.1 Use Case Boundary Card

Use case:
Customer-requested product/service:
Customer segment:
Jurisdiction / policy scope:
Data provider(s):
Data recipient:
Aggregator / vendor:
AI role:
Decision/action impact:
Required data categories:
Optional data categories:
Time window:
Refresh frequency:
Allowed AI uses:
Prohibited AI uses:
Human review triggers:
Revocation behavior:
Evidence requirements:
Accountable owner:
Risk owner:

15.2 Consent Disclosure Checklist

Recipient name:
Provider name:
Aggregator name if visible/applicable:
Requested product/service:
Data categories:
Required vs optional data:
Duration:
Collection frequency:
How data will be used:
How AI will be used:
Uses not permitted:
Downstream sharing:
Revocation method:
Customer support route:
Language:
Accessibility evidence:
Disclosure version:

15.3 Developer Onboarding Record

15.4 Feature Boundary Register

Feature name:
Business purpose:
Source data categories:
Consent purpose:
Transformation:
Confidence / quality dependency:
Allowed model use:
Allowed customer outputs:
Allowed decisions:
Prohibited decisions:
Sensitive inference review:
Fairness review:
Human review triggers:
Retention:
Revocation action:
Monitoring metric:
Owner:

15.5 RAG Control Record

RAG use case:
Retriever policy:
Consent check:
Customer/account isolation:
Purpose isolation:
Data categories:
Time window:
Freshness requirement:
Quality filters:
Prompt injection controls:
Source citation rule:
Output policy:
Human escalation:
Revocation behavior:
Eval scenarios:
Evidence fields:

15.6 Revocation Evidence Record

Revocation event id:
Customer ref:
Consent id:
Data recipient:
Data provider:
Aggregator:
Developer app:
Revoked at:
Customer channel:
API token action:
Provider notification:
Aggregator notification:
Downstream notification:
Collection stop confirmed:
Cache action:
Feature action:
Embedding action:
Agent workflow action:
Retention exception:
Customer receipt:
Evidence bundle:
Owner:
Closure time:

15.7 Complaint RCA Template

Complaint id:
Customer issue:
Consent id:
Disclosure version:
Data categories:
API request ids:
Data quality status:
Feature ids:
AI run id:
RAG source refs:
Human review:
Final customer message:
Alleged harm:
Root cause category:
Immediate remediation:
Customer remediation:
CAPA owner:
CAPA due date:
Closure evidence:

---

16. Final Operating Principle

这套 playbook 的成熟度可以用一个问题检验:

When an AI-enabled financial product uses customer-authorized open banking or open finance data,
can the institution prove the customer understood the value and scope,
the API enforced the consent,
the data stayed minimized and lineage-preserved,
the model used only permitted features and retrieval sources,
third parties honored purpose, retention and revocation,
fraud/scam controls monitored abuse,
agent actions required separate approval,
and every outcome can be replayed for customer trust, audit and remediation?

如果答案不清楚, 不是缺一个 bank-connection SDK。问题是 consented data sharing、API platform、data governance、AI governance、third-party risk、fraud controls、revocation lifecycle 和 evidence architecture 还没有成为同一套 operating system。