AI 扩展计划 / Playbooks
AI Account Opening / KYC / Onboarding Decision Playbook
核心判断:
1,044 行AI_ACCOUNT_OPENING_KYC_ONBOARDING_DECISION_PLAYBOOK.md
AI Account Opening / KYC / Onboarding Decision Architecture Playbook
定位: 面向 CBAP+ Senior BA、高级 AI PM、Product Architect、Digital Banking Architect、Identity Platform Architect、AML/KYC Product Lead、Fraud Technology Lead 和金融零售转型负责人，把 account opening、digital onboarding、KYC/CIP/CDD、identity proofing、KYB/UBO、risk-tiering、exception queue、funding activation、fraud/AML handoff、客户沟通和 audit evidence 设计成可运行、可复核、可治理的 onboarding decision architecture。 适用范围: consumer deposit onboarding、small business onboarding、digital checking / savings、card / wallet-linked deposit account、branch-assisted digital onboarding、remote identity proofing、CIP/KYC/CDD operations、fraud/synthetic identity review、AML referral、initial funding、early-life monitoring、account activation and decline / hold communication governance。 核心产出: source anchor map、decision taxonomy、account opening state machine、gate-by-gate architecture、identity/CIP/CDD/KYB evidence model、small business UBO flow、risk-tiering matrix、exception queue design、customer harm dashboard、adverse/denial communication ownership model、model risk plan、consent/privacy controls、audit evidence binder、RACI、release gates、KRI dashboard、anti-patterns、30-day lab 和 portfolio pack。
核心判断:
Digital onboarding succeeds when the institution can prove why an applicant moved to approve, hold, decline, restrict, fund or activate, not when an IDV vendor returns a green check.
0. Disclaimer
本文是学习、作品集、架构训练和内部治理讨论材料。
本文不是法律意见、合规结论、BSA/AML 合规判断、CIP/CDD 充分性结论、SAR filing decision、身份核验合格结论、欺诈处置指令、模型验证报告、客户通知建议、拒绝/不利行动法律分析、隐私影响评估或 vendor endorsement。
正式项目必须由 Legal、BSA/AML Compliance、Fraud Risk、Financial Crime、Sanctions、Privacy、Information Security、Model Risk、Operations、Product、Customer Experience、Accessibility、Vendor Management、Internal Audit、Business Owner 和管理层结合机构类型、司法辖区、产品、客户群、渠道、数据来源、第三方条款、内部政策和监管关系确认。
关键边界:
- AI 可以辅助资料抽取、身份信号解释、risk-tier recommendation、queue routing、review summarization、evidence completeness check、customer friction analytics 和 QA。
- AI 不应单独决定客户身份真实、是否提交 SAR、是否关闭账户、是否拒绝客户、是否通知客户具体金融犯罪原因或是否解除账户限制。
- IDV / liveness pass 不等于 CIP / CDD pass。
- CDD risk profile 不等于 SAR determination。
- Fraud decline、AML hold、product eligibility decline、identity proofing failure 和 funding hold 的 owner、证据、文案、申诉/补件路径不同。
- Beneficial ownership、BOI、CDD、KYB 和小企业开户的具体适用性与阈值由 Legal / Compliance / BSA owner 判断。
- 对客户造成实质影响的 decline、hold、restricted activation、account closure、funding delay、notice、appeal、exception 和 remediation 必须有明确 owner、reason code、evidence 和 approved communication path。
1. Source Anchors
以下官方来源是本文的设计锚点。本文把它们转成产品、流程、架构、控制、证据和治理语言，不把任何来源简化为单一检查表。访问日期按 2026-06-30 记录。
| Anchor | Official link | 本 playbook 使用方式 |
|---|---|---|
| FFIEC BSA/AML Manual - Customer Identification Program | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/01 | 用 written CIP、risk-based identity verification、account-opening method、available identifying information、risk factors、无法形成合理信念时的 account use / non-opening / closure / SAR path 设计 CIP decision gate |
| FFIEC BSA/AML Manual - Customer Due Diligence | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/02 | 用 customer risk profile、nature and purpose、ongoing monitoring、risk-based update 设计 CDD profile service 和 onboarding-to-monitoring handoff |
| FFIEC BSA/AML Manual - Beneficial Ownership Requirements for Legal Entity Customers | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/03 | 用 legal entity customer、control prong、ownership prong、beneficial owner identification/verification、recordkeeping、无法验证时的处理路径设计 small business KYB / UBO flow |
| FFIEC BSA/AML Manual - Suspicious Activity Reporting | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/04 | 用 suspicious activity identification、SAR decision making、supporting documentation、confidentiality、continuing activity 和 management notification 设计 fraud/AML referral 和 SAR-sensitive evidence boundary |
| FinCEN CDD Final Rule resources | https://www.fincen.gov/resources/statutes-and-regulations/cdd-final-rule | 用 CDD 四个核心要求: identify and verify customers、identify and verify beneficial owners、understand nature and purpose、ongoing monitoring 组织 CDD/KYB product requirements |
| FinCEN BOI resources | https://www.fincen.gov/boi 和 https://www.fincen.gov/boi/Reference-materials | 用 BOI reporting / access / safeguards official materials 约束 BOI source usage；当前 BOI reporting 范围有官方更新，开户架构必须保留 source provenance 并由 Legal/Compliance 判断适用性 |
| FinCEN BSA Filing Information / SAR resources | https://www.fincen.gov/resources/filing-information | 用 SAR form、BSA E-Filing、filing instructions and operational resources 设计 AML case handoff，不让 AI 或前台渠道拥有 filing decision |
| NIST SP 800-63-4 Digital Identity Guidelines | https://pages.nist.gov/800-63-4/ | 用 digital identity assurance、fraud requirements、forged media、security、privacy、customer experience 和 continuous evaluation metrics 设计 remote onboarding |
| NIST SP 800-63A-4 Identity Proofing and Enrollment | https://pages.nist.gov/800-63-4/sp800-63a.html | 用 identity resolution、evidence validation、attribute validation、identity verification、enrollment、exception handling 和 proofing option risk management 组织 identity proofing gate |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI model inventory、intended use、eval、monitoring、human oversight、incident learning 和 risk reporting |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 视角组织 AI roles、policy、operation、performance evaluation、internal audit、management review 和 continual improvement |
Source-to-control pattern:
source anchor -> control objective -> onboarding requirement
-> decision gate -> evidence object -> owner -> metric -> review cadence
2. Executive Framing
常见目标:
Reduce onboarding friction.
Approve more good customers.
Use AI to automate KYC.
Lower manual review cost.
Improve fraud detection.
这些目标合理但不完整。更成熟的目标是:
Create a governed onboarding decision architecture
that approves eligible customers quickly,
routes ambiguous cases to the right owner,
prevents unsupported identity / KYC / AML / fraud decisions,
minimizes customer harm and abandonment,
controls funding and activation risk,
and can replay every material account-opening decision.
高管应问的问题:
| Executive question | Strong answer requires |
|---|---|
| 哪些 decision gate 影响开户、限制、拒绝、入金或激活 | decision taxonomy and state machine |
| 哪些 gate 是产品资格，哪些是 KYC/CIP/CDD，哪些是 fraud/AML | owner map and reason taxonomy |
| IDV pass 如何映射到 CIP reasonable belief | CIP decision policy and evidence bundle |
| 小企业 UBO/KYB 如何处理 ownership、control、authority 和 BOI source | KYB object model and source provenance |
| AI 在哪些地方只是 routing / scoring / summarizing | intended-use inventory and model risk tier |
| 客户被 hold / decline 时看到什么、谁负责文案 | communication ownership and approved reason catalog |
| 如果客户被误拒、被卡住或重复上传，如何发现和补救 | customer harm / abandonment monitoring |
| 审计六个月后抽一个 case 能否 replay | evidence ledger and audit binder |
2.1 One-liner
Account opening AI is a decision-control system for eligibility, identity, financial crime risk and activation, with evidence as the product backbone.
3. Decision Taxonomy
不要把开户失败统称为 KYC fail。至少需要以下 taxonomy:
| Decision family | Primary question | Example outcome | Owner |
|---|---|---|---|
| Eligibility | 客户、产品、地区、年龄、业务类型、风险偏好是否允许 | not eligible, alternate product, continue | Product / Legal / Compliance |
| Consent / privacy | 是否已取得相称、目的绑定的数据处理、第三方共享和生物识别/IDV告知 | continue, request consent, stop | Privacy / Legal / Product |
| Identity proofing | 申请人与真实自然人及证据是否建立足够关联 | pass, retry, alternate proofing, review | Identity Platform / KYC Ops |
| CIP verification | 是否能按机构 CIP 形成对客户真实身份的合理信念 | verified, discrepancy, hold, decline | BSA/AML Compliance |
| CDD risk profile | 是否理解关系性质、目的、预期活动和风险等级 | standard, enhanced, restricted, review | BSA/AML Compliance |
| KYB / UBO | 法人实体、授权人、控制人和实益拥有人是否可识别/验证 | pass, RFI, KYB review | KYB / BSA Ops |
| Fraud / synthetic identity | 是否存在 stolen identity、synthetic identity、mule、device farm、deepfake 或 ATO risk | pass, review, decline, restrict | Fraud Risk |
| Sanctions / screening | 是否命中或可能命中制裁、PEP、adverse media 或内部 watchlist rules | clear, possible match, review | Sanctions / Compliance |
| AML referral | 是否需要 AML/CDD/EDD/SAR-sensitive review | no referral, referral, SAR-sensitive case | BSA/AML Compliance |
| Account creation | 是否可以在核心系统建立客户和账户 | create, create restricted, do not create | Product / Operations / Core Banking |
| Funding and activation | 是否允许入金、转账、发卡、出金、提高限额 | active, restricted, hold funds, delayed activation | Deposit Ops / Fraud / Payments |
| Communication / recourse | 客户收到什么说明、下一步和补件/申诉路径 | notice, RFI, safe hold message | Legal / Compliance / CX / Product |
3.1 Decision Boundary Rule
Every customer-impacting outcome must name:
decision family + owner + reason code + evidence refs + customer-safe communication + review/recourse path.
如果这些字段为空，系统不应直接进入 decline、account closure、funding freeze 或 customer notification。
4. Account Opening State Machine
prospect
-> application_started
-> consent_captured
-> eligibility_screened
-> identity_proofing_in_progress
-> cip_verification_in_progress
-> cdd_profile_created
-> kyb_ubo_review_in_progress if legal entity
-> fraud_screening_in_progress
-> compliance_screening_in_progress
-> decision_pending
-> approved / approved_restricted / rfi / manual_review / declined / abandoned
-> account_created
-> opened_not_funded
-> funding_pending
-> active / active_restricted / closed_after_failed_verification
-> early_life_monitoring
4.1 State Definition Table
| State | Meaning | Entry event | Exit control |
|---|---|---|---|
application_started | 申请已创建，客户尚未完成关键输入 | first save / submit | abandonment timer and consent check |
consent_captured | 客户完成当前用途所需的 disclosure / consent | consent event | version and purpose bound |
eligibility_screened | 基础产品资格已评估 | eligibility service response | approved rule set or decline reason |
identity_proofing_in_progress | 证据采集、验证、verification 未完成 | IDV session started | proofing result or exception route |
cip_verification_in_progress | CIP 信息与 documentary / non-documentary 方法正在验证 | CIP service started | verified / discrepancy / no reasonable belief route |
cdd_profile_created | 已建立初始 risk profile and expected activity | CDD profile service completed | standard / enhanced / update needed |
kyb_ubo_review_in_progress | 法人/小企业 ownership、control、authority 仍需判断 | legal entity scope detected | KYB pass / RFI / enhanced review / decline |
fraud_review_pending | 欺诈信号需要人工或增强控制 | fraud score / rule / graph flag | reviewer disposition and reason |
aml_review_pending | AML/CDD/SAR-sensitive 队列接管 | red flag referral | restricted disposition and audit evidence |
approved_restricted | 可以建户但账户能力有限 | decision service restriction | activation release criteria |
opened_not_funded | 核心账户已建，未完成首次入金 | core account id created | funding success, timeout, closure route |
active_restricted | 账户可部分使用，限制仍存在 | activation with controls | restriction review / release |
abandoned | 客户超时或退出 | timer / drop-off | re-engagement or closure of application |
4.2 State Transition Guardrails
| Bad transition | Risk | Required guard |
|---|---|---|
identity_proofing_failed -> declined without triage | false reject and accessibility harm | retry policy, alternate proofing, reason owner |
fraud_review_pending -> customer generic decline | unsafe or unsupported communication | fraud-approved customer-safe message |
aml_review_pending -> detailed customer reason | SAR confidentiality risk | restricted communication template |
approved_restricted -> active without release evidence | mule / synthetic activation risk | release rule and reviewer proof |
opened_not_funded -> active on weak funding source | return / fraud loss | funding risk and settlement controls |
abandoned -> marketing winback for high-risk unresolved case | reactivation of risky or harmed application | risk-aware re-engagement policy |
5. Target Architecture
Channels
mobile / web / branch-assisted / contact center / partner
Control plane
consent-disclosure service
journey orchestrator
policy decision service
model routing and feature service
evidence ledger
communication template service
case / exception workbench
Decision services
eligibility service
identity proofing service
CIP verification service
CDD risk profile service
KYB / UBO service
fraud and synthetic identity graph
sanctions / AML referral interface
funding risk and activation service
Systems of record
CRM / customer master
core banking
case management
AML case system
fraud case system
document / records repository
model inventory and monitoring
Governance and assurance
model risk
privacy and consent registry
vendor management
QA and sampling
audit evidence binder
management information dashboard
5.1 Key Architecture Principle
The journey orchestrator should not be the policy owner. It coordinates steps, but each decision service owns its decision logic, reason codes, evidence and review queue.
5.2 Decision Signal Contract
Every AI or rule component should output a bounded decision signal:
signal_id: sig_kyc_doc_validation_20260630_001
application_id: app_8f27
decision_family: identity_proofing
source_system: idv_vendor_a
intended_use: evidence_validation_signal
result: inconclusive
confidence_bucket: medium
reason_codes:
- DOCUMENT_IMAGE_GLARE
- ADDRESS_FIELD_MISMATCH
customer_safe_category: additional_information_needed
evidence_refs:
- doc_id_1902
- session_id_771
model_or_vendor_version: idv_a_2026_05
policy_version: idproof_policy_2026_q2
owner: identity_platform_ops
allowed_actions:
- retry_capture
- route_manual_review
prohibited_actions:
- final_decline_without_review
retention_class: kyc_evidence_restricted
5.3 Why Contract Matters
| Without contract | With contract |
|---|---|
| Vendor returns opaque green/yellow/red | system knows result, boundary, owner and evidence |
| LLM summary influences queue silently | summary has intended use and prohibited actions |
| Reviewer cannot see source evidence | evidence refs open source-first review |
| Customer receives generic failure message | communication maps from approved customer-safe category |
| Audit cannot replay model versions | model / policy / vendor versions captured |
6. Gate-by-Gate Architecture
Gate 0: Consent, Disclosure and Purpose
| Requirement | Design implication |
|---|---|
| Data collection must be purpose-bound | tag each field and artifact with purpose: account opening, identity proofing, CIP, CDD, fraud prevention, AML, funding |
| Third-party IDV / data broker / biometric processing may require specific disclosure or consent depending on context | disclosure service owns versions and channel proof |
| AI logs may contain sensitive ID / biometric / financial crime data | logging policy must classify raw media, derived signals, prompts, summaries and reviewer notes |
| Reuse across products needs explicit purpose review | do not silently reuse failed IDV artifacts for marketing or unrelated analytics |
Consent record:
consent_id: cns_20260630_001
customer_token: cust_tok_349
application_id: app_8f27
channel: mobile
consent_scope:
- identity_verification
- document_capture
- fraud_prevention
- account_opening_communications
notices:
- privacy_notice_v2026_04
- electronic_records_notice_v2026_02
- idv_vendor_notice_v2026_05
purpose_tags:
- cip
- cdd
- fraud
- funding_activation
timestamp: 2026-06-30T14:20:11Z
Gate 1: Product Eligibility
| Check | Examples | Owner | Evidence |
|---|---|---|---|
| Product scope | consumer vs small business, deposit vs credit-linked, student/minor/senior product | Product | product rule id |
| Geographic / channel | state availability, branch footprint, partner channel | Legal / Product | eligibility policy |
| Customer type | individual, sole proprietor, LLC, nonprofit, trust | Legal / Compliance | customer type classification |
| Existing relationship | duplicate customer, existing profile, prior closure | Customer Master / Risk | matching result |
| Prohibited / unsupported business | cash-intensive, virtual asset, adult, high-risk merchant where applicable | Compliance / Risk | business type policy |
Guardrail: product eligibility decline is not a KYC decline. The reason code family and customer message should not imply identity or financial crime suspicion.
Gate 2: Identity Proofing
Use NIST SP 800-63A-4 as mental model:
identity resolution
-> evidence validation
-> attribute validation
-> identity verification
-> enrollment
| Step | Onboarding meaning | Typical evidence | Failure route |
|---|---|---|---|
| Resolution | claimed identity maps to a unique real-world person in served population | identity attributes, authoritative / credible source match, duplicate search | manual review / additional evidence |
| Evidence validation | supplied evidence is genuine, authentic and accurate | ID document result, data source validation, tamper check | retry / alternate evidence / review |
| Attribute validation | core attributes are accurate | name, DOB, address, ID number, phone/email, business attributes | RFI / discrepancy queue |
| Identity verification | applicant is associated with the evidence | selfie/liveness, branch-assisted verification, trusted referee | alternate path / review |
| Enrollment | bind identity to account and authenticators | customer id, authenticator binding, device registration | restricted enrollment / no activation |
Identity proofing output should be a structured proofing result, not a final account decision:
| Proofing result | Account decision implication |
|---|---|
| pass | can proceed to CIP/CDD/fraud gates |
| inconclusive | request additional evidence or route review |
| fail recoverable | provide retry or alternate proofing |
| fail high risk | fraud / KYC review depending on reason |
| vendor unavailable | fallback policy based on product risk |
Gate 3: CIP Verification
CIP gate answers:
Can the institution form a reasonable belief that it knows the true identity of the customer, according to its written program and risk-based procedures?
Architecture fields:
| Field | Why it matters |
|---|---|
cip_subject_type | individual, sole proprietor, legal entity opener, beneficial owner |
information_required | policy-defined identifying information by subject type |
documentary_methods | ID, passport, business docs, copies allowed where policy permits |
non_documentary_methods | database match, phone/address verification, bureau-like source, existing relationship |
verification_status | verified, discrepancy, insufficient, pending |
reasonable_belief_status | yes, no, pending, conditional per policy |
discrepancy_resolution | what mismatch occurred, how resolved, who approved |
account_use_terms_while_pending | if account opened before completion, what limits apply |
Decision table:
| CIP state | Action | Evidence required |
|---|---|---|
| Verified and low conflict | continue | verification method and result |
| Minor discrepancy resolved | continue with note | discrepancy, resolution, reviewer or automated rule |
| Missing required information | RFI or assisted path | missing field, customer request, timer |
| Inconsistent or unverifiable | hold / review / do not open per policy | methods attempted, reason, owner |
| Cannot form reasonable belief after attempts | decline, restrict, close, or SAR referral per policy | policy id, decision owner, communication boundary |
Gate 4: CDD Risk Profile
CDD gate is not only a compliance form; it is the bridge from onboarding to monitoring.
| CDD element | Product / architecture implication |
|---|---|
| Nature and purpose | expected account use, source of funds, business purpose, customer intent |
| Customer risk profile | initial risk tier and risk factors |
| Ongoing monitoring | downstream transaction monitoring expects CDD context |
| Update triggers | material change, unusual activity, new product, review cycle |
CDD profile object:
cdd_profile_id: cdd_20260630_001
customer_type: small_business
relationship_purpose: operating_account
expected_activity:
inbound_methods: [ach, card_settlement]
outbound_methods: [ach, debit_card]
expected_monthly_volume_band: 25k_100k
cash_activity_expected: low
risk_factors:
- new_business_under_12_months
- ecommerce_merchant
risk_tier: standard_plus
owner: bsa_aml_compliance
update_triggers:
- volume_exceeds_expected_band
- ownership_change
- high_risk_counterparty_pattern
Gate 5: Small Business KYB / UBO
Small business onboarding must separate:
entity identity
+ applicant authority
+ beneficial ownership / control
+ business nature and purpose
+ expected activity
| Decision point | Evidence | AI support | Owner |
|---|---|---|---|
| Entity exists | formation document, registry result, EIN/TIN evidence, business address | name normalization, registry matching, document extraction | KYB Ops |
| Applicant authority | officer title, operating agreement, resolution, owner attestation | authority document summary, role extraction | KYB / Legal Ops |
| Beneficial owner / control person | ownership percentages, control person, ID evidence, attestation | ownership graph consistency, duplicate detection | BSA/KYB |
| Business activity | website, MCC/NAICS, invoices, licenses, expected transactions | business classifier, risk signals | BSA/Fraud/Product |
| BOI source usage | FinCEN BOI, customer attestation, registry, vendor, internal profile | source provenance and conflict detection | Legal/Compliance |
UBO guardrails:
- Do not overwrite customer-provided beneficial owner data with vendor data without preserving provenance.
- Do not treat FinCEN BOI materials as a universal KYB source; official BOI scope and access safeguards change over time.
- Do not let AI infer hidden owners as a fact. It can flag ownership inconsistency or nominee risk for review.
- Do not combine authority failure, entity mismatch and beneficial ownership discrepancy into one customer message.
Gate 6: Fraud / Synthetic Identity
| Signal family | Examples | Action |
|---|---|---|
| Device / network | emulator, device farm, VPN/proxy, unusual geolocation, repeated attempts | step-up, review, block by policy |
| Identity graph | shared SSN/phone/email/address/device, mule cluster, synthetic pattern | fraud queue or enhanced review |
| Document / media | forged ID, liveness warning, injection indicator, duplicate document | IDV/fraud specialist review |
| Velocity | multiple applications, rapid edits, repeated failed sessions | throttling and review |
| Funding behavior | risky source, return history, stolen instrument pattern | restrict activation or funding hold |
| Behavioral | copy-paste pattern, bot behavior, anomalous journey | session risk treatment |
Fraud decision boundary:
fraud signal != fraud conclusion
fraud review disposition != SAR decision
fraud decline message != AML explanation
Gate 7: AML / Sanctions / SAR-sensitive Handoff
AML handoff should be explicit and access-controlled:
onboarding red flag / screening signal
-> AML referral object
-> AML case queue
-> analyst review
-> disposition
-> customer action decision through approved policy
-> SAR decision owned by BSA/AML Compliance
Referral object:
aml_referral_id: amlref_20260630_001
application_id: app_8f27
trigger_source: cdd_risk_profile
red_flag_ids:
- rf_expected_activity_inconsistent
- rf_entity_ownership_obscured
evidence_refs:
- cdd_profile_id
- ubo_package_id
- application_snapshot_id
customer_visibility: restricted
sar_sensitive: possible
owner_queue: aml_onboarding_review
Customer-facing rule: do not expose SAR-sensitive information, AML typology, thresholds, watchlist details or investigative steps through app, email, chat, branch script or LLM assistant.
Gate 8: Funding and Activation
开户 approval 不等于 fully active。Funding and activation 是单独风险域。
| Activation state | Use case | Controls |
|---|---|---|
created_no_funding | customer id and account id created, no initial deposit | no outbound transfer, no card issuance |
funding_pending | ACH / card / wire / cash funding initiated | return risk, source verification, hold period |
active_restricted | basic access allowed, high-risk actions limited | transfer limits, card limits, beneficiary cooling-off |
fully_active | all standard product capabilities enabled | early-life monitoring remains |
activation_blocked | critical KYC/fraud/AML/funding issue | safe customer message and review owner |
Funding guardrails:
- Do not allow high-risk outbound movement before identity/CIP/CDD and funding risk gates clear.
- Do not hide funding holds inside generic onboarding review; customers need safe status and next action.
- Do not let first funding success override unresolved KYC/AML issues.
- Do link early-life transaction monitoring to onboarding evidence and risk tier.
7. Risk-Tiering Architecture
Risk tier is a composite decision object, not a single model score.
risk tier = product risk + customer / entity risk + channel risk
+ identity assurance + CDD risk + fraud risk + funding risk
+ geography / business activity + previous relationship + unresolved evidence gaps
7.1 Tier Matrix
| Tier | Meaning | Default path | Controls |
|---|---|---|---|
| R0 prohibited / unsupported | outside policy or product appetite | do not open / alternate path | approved reason and communication |
| R1 low | existing customer or strong evidence, low product risk | straight-through processing | sampling QA and early-life monitoring |
| R2 standard | normal digital onboarding risk | standard IDV + CIP + CDD | normal limits and monitoring |
| R3 enhanced | extra evidence or review needed | manual / enhanced review | limits, RFI, specialist queue |
| R4 restricted relationship | can open with controls | restricted activation | transfer/funding limits, review cadence |
| R5 decline / exit candidate | unresolved critical identity, fraud, AML or policy risk | decline / close / referral | Legal/Compliance/Fraud owner |
7.2 Risk Factor Catalog
| Factor | Examples | Owner |
|---|---|---|
| Product | overdraft, instant debit card, RTP, wire, crypto on-ramp, high limit | Product / Risk |
| Channel | remote unattended, partner channel, branch-assisted, contact center | Product / Operations |
| Identity | weak evidence, failed liveness, attribute mismatch, thin file | KYC / Identity |
| Entity | new LLC, complex ownership, foreign registration, nominee concern | KYB / BSA |
| Behavior | repeated applications, device velocity, bot signals | Fraud |
| Geography | high-risk jurisdiction or out-of-footprint pattern | Compliance |
| Expected activity | cash-intensive, high inbound/outbound mismatch, unusual purpose | BSA/AML |
| Funding | risky source, return risk, first-party fraud pattern | Payments / Fraud |
| Relationship history | prior closure, charge-off, fraud loss, complaint sensitivity | Risk / Customer Master |
7.3 Decision Policy Example
| Scenario | Suggested route | Notes |
|---|---|---|
| Strong identity, low-risk checking, existing verified customer | approve and activate | use existing CIP reliance per policy only if allowed |
| New remote customer, IDV pass, address mismatch | RFI or manual review | avoid final decline until discrepancy path exhausted |
| Small business with clear entity docs but unclear control person | KYB / UBO RFI | do not activate high-risk payments |
| Synthetic identity graph cluster with new funding instrument | fraud review and restricted activation | customer communication must be safe |
| CDD expected activity inconsistent with business type | AML/CDD review | SAR-sensitive boundary applies |
8. Exception Queue Design
Exception queue is a control system, not a back-office dumping ground.
8.1 Queue Taxonomy
| Queue | Trigger | Reviewer skill | SLA design |
|---|---|---|---|
| Identity proofing review | IDV inconclusive, document mismatch, liveness warning | IDV / KYC specialist | short SLA, customer retry path |
| CIP discrepancy | name/DOB/address/ID mismatch, non-documentary failure | KYC Ops | policy-based timers |
| CDD enhanced review | nature/purpose ambiguity, high-risk profile, expected activity conflict | BSA/CDD analyst | risk-prioritized |
| KYB / UBO review | entity mismatch, authority issue, ownership conflict | KYB specialist | business-hour and escalation path |
| Fraud review | synthetic/mule/device/funding signal | Fraud analyst | urgent for account creation / funding |
| AML referral | red flags, possible suspicious activity | AML analyst | restricted access and SAR-sensitive handling |
| Funding exception | ACH return risk, first funding anomaly, source mismatch | Deposit Ops / Fraud | settlement-aware SLA |
| Accessibility / assisted proofing | customer cannot complete digital proofing | CX / assisted onboarding | no-dead-end automation |
| Communication / appeal | customer disputes reason, requests review | Customer Care + owning risk team | case SLA and evidence replay |
8.2 Queue Workbench Requirements
| Capability | Why it matters |
|---|---|
| Source-first evidence viewer | reviewer sees original evidence and structured extraction |
| Decision family filter | prevents fraud reviewer from acting as AML owner |
| Reason code catalog | reviewer dispositions are structured |
| Customer-safe note separation | internal risk notes do not leak into customer messages |
| SLA and aging | prevents indefinite hold |
| Dual control for high-risk actions | account closure, SAR-sensitive disposition, large funding release |
| Override capture | model and policy improvement |
| QA sampling | consistency and fairness |
| Complaint linkage | recourse and harm monitoring |
8.3 Reviewer Disposition Codes
| Disposition | Meaning | Follow-up |
|---|---|---|
verified_continue | evidence sufficient | continue journey |
rfi_required | customer can supply missing info | send approved RFI |
alternate_proofing_required | digital route unsuitable | assisted path |
restrict_and_open | relationship allowed with limits | activation restriction |
decline_per_policy | policy says do not open | notice owner required |
refer_fraud | fraud owner must review | fraud case |
refer_aml | AML owner must review | restricted AML case |
close_after_failed_verification | opened account cannot remain | closure policy and funds handling |
customer_harm_review | process may have harmed customer | CX risk / remediation |
9. Customer Communication Ownership
Hold / decline / denial / adverse communication is a product-control artifact. It should not be generated ad hoc by the journey UI, chatbot, IDV vendor or analyst note.
9.1 Message Families
| Message family | Used when | Owner | Guardrail |
|---|---|---|---|
| Product eligibility decline | product/rule mismatch | Product + Legal/Compliance | no implication of suspicious activity |
| Additional information request | missing or inconsistent evidence | KYC/KYB Ops + CX | specific, minimal, actionable |
| Identity verification issue | digital proofing failed or inconclusive | Identity Platform + Legal/CX | include alternate path when appropriate |
| Application under review | manual review pending | Product + Ops | SLA/status without restricted details |
| Fraud-safe decline | fraud policy outcome | Fraud + Legal/Compliance | do not disclose detection logic |
| AML-safe hold / closure | AML/CDD/SAR-sensitive outcome | BSA/AML + Legal | SAR confidentiality boundary |
| Funding hold | initial deposit or payment risk | Deposit Ops / Fraud / Payments | explain funds/status as policy allows |
| Business ownership RFI | entity/authority/UBO evidence needed | KYB / BSA Ops | ask for exact evidence, not broad suspicion |
| Appeal / reconsideration | customer disputes outcome or supplies evidence | Customer Care + owning decision family | case id, SLA, evidence intake |
9.2 Reason Code Contract
reason_code: IDENTITY_EVIDENCE_INCONCLUSIVE
decision_family: identity_proofing
customer_safe_text: We need additional information to verify your identity.
allowed_next_actions:
- retry_capture
- upload_alternate_id
- assisted_verification
internal_notes_allowed: false
owner: identity_platform_policy
legal_review_status: approved_2026_q2
restricted_if:
- sar_sensitive_case
- active_fraud_investigation
9.3 Adverse / Denial Communication Boundary
Applicability of adverse action, deposit denial notice, credit denial notice, account closure notice, fraud notice, AML communication limits, FCRA-related disclosure, E-SIGN delivery, state-specific notice and complaint rights is Legal / Compliance-owned. Architecture still must support:
| Artifact | Purpose |
|---|---|
| decision reason source of truth | prevents AI-invented reasons |
| communication template version | proves what customer saw |
| delivery record | proves timing and channel |
| customer action path | RFI, appeal, assisted proofing, contact |
| restricted-info filter | prevents leakage of SAR/fraud rules |
| recourse linkage | connects message to case workflow |
10. Customer Harm / Abandonment Control
Onboarding can harm customers even when no account is opened.
10.1 Harm Taxonomy
| Harm | Example | Signal | Control |
|---|---|---|---|
| False reject | legitimate customer declined due to IDV mismatch | appeal upheld, manual overturn | calibration and alternate path |
| Evidence burden | customer repeatedly asked for same document | duplicate upload count | evidence reuse and max retry |
| Accessibility exclusion | liveness fails for disability, device quality or age-related factors | repeated IDV fail by segment | assisted proofing |
| Privacy overcollection | unnecessary documents collected | field purpose review | data minimization gate |
| Confusing hold | customer waits with no status | review aging and contacts | SLA-based messaging |
| Funding harm | deposit held without clear path | funding complaints | funding status transparency |
| Business disruption | small business cannot pay staff/vendors after delayed activation | business account escalation | urgency triage |
| Stigma / blame | message implies fraud without proof | complaint narrative | safe wording QA |
10.2 Abandonment Analytics
| Drop-off point | Product interpretation | Risk interpretation |
|---|---|---|
| before consent | product fit or trust issue | low risk signal |
| during IDV capture | UX/device/accessibility issue or attack | split by retries and device risk |
| after RFI | evidence burden or customer ineligibility | monitor repeat requests |
| during KYB/UBO | complexity and authority issues | may require assisted onboarding |
| at funding | payment trust / funding method friction | funding fraud signal possible |
| after hold message | status uncertainty | potential complaint and harm |
Balanced metrics:
eligible activation rate
+ verified completion rate
+ manual review overturn rate
+ false reject estimate
+ RFI burden index
+ onboarding abandonment by gate
+ segment friction disparity
+ exception aging
+ funding hold complaints
+ early-life fraud / AML quality
11. Model Risk and AI Governance
11.1 AI Inventory
| Asset | Intended use | Customer impact | Governance |
|---|---|---|---|
| Document classification / OCR | extract KYC/KYB fields | medium to high | field-level eval, source anchors |
| ID document validation | evidence validation | high | vendor validation, tamper eval |
| Face match / liveness / PAD | identity verification signal | high | bias, accessibility, injection eval |
| Attribute match model | match name/address/DOB/phone/email | high | thresholds, manual review |
| Synthetic identity graph | fraud risk signal | high | feature lineage, graph explainability |
| Device/session model | session risk | medium to high | drift and attack monitoring |
| CDD risk-tier model | profile routing | high | Compliance owner and scenario coverage |
| Business classifier | NAICS/MCC / risk categorization | medium | KYB review and false classification QA |
| LLM evidence assistant | reviewer summary | medium | grounded output, citation, prohibited conclusion guardrails |
| LLM customer assistant | answer onboarding questions | high if customer-facing | approved knowledge, no decision invention |
| Queue routing model | route exceptions | medium | SLA and misroute QA |
11.2 Eval Slices
| Eval slice | Why it matters |
|---|---|
| document type and issuing region | IDV performance varies |
| lighting, device quality, assistive technology | accessibility and false fail |
| age, language, name structure | match and CX disparity |
| thin-file / new-to-country customers | false reject and inclusion |
| small business entity types | KYB complexity |
| ownership structures | UBO conflicts |
| attack artifacts | forged media, digital injection, synthetic identity |
| channel | mobile, web, branch-assisted, contact center |
| vendor outage / degraded mode | continuity controls |
| customer-safe language | message consistency |
11.3 Release Gate
| Gate | Pass evidence |
|---|---|
| Intended use | model cannot be used for unsupported final decision |
| Data lineage | features and source systems documented |
| Eval coverage | representative onboarding and attack slices |
| Human oversight | queue owner, reviewer SOP, override reason |
| Communication control | reason codes and templates approved |
| Monitoring | drift, SLA, false reject, harm, early fraud |
| Vendor evidence | model/version, SLA, audit, data handling, exit path |
| Privacy/security | logging, access, retention, purpose tags |
| Audit replay | sample cases rebuilt end-to-end |
Use NIST AI RMF and ISO/IEC 42001 as lifecycle scaffolding:
Govern: inventory, roles, policies, risk appetite
Map: onboarding context, customer impact, source anchors
Measure: eval, calibration, QA, segment friction, drift
Manage: release gates, monitoring, incidents, CAPA
Management system: audit, management review, continual improvement
12. Consent, Privacy and Data Architecture
12.1 Data Classification
| Data class | Examples | Controls |
|---|---|---|
| Application PII | name, address, DOB, SSN/TIN, phone, email | encryption, access, masking |
| Identity evidence | ID image, selfie, liveness session, proofing video | restricted storage, retention, vendor controls |
| KYB / UBO | entity docs, owner IDs, ownership percentages, authority docs | role-based access, provenance |
| Financial crime signals | AML red flags, watchlist details, SAR-sensitive notes | restricted access and disclosure controls |
| Fraud graph | device clusters, mule links, risk scores | need-to-know and rule secrecy |
| AI artifacts | extracted fields, summaries, embeddings, prompts, logs | purpose tags, redaction, retention |
| Customer communications | RFI, decline, hold, appeal messages | template version and delivery proof |
12.2 Purpose-Bound Processing
| Purpose | Allowed use example | Risk |
|---|---|---|
| Identity proofing | validate ID and applicant association | over-retaining biometric artifacts |
| CIP/CDD | identify/verify and risk profile customer | using CDD data for unrelated marketing |
| Fraud prevention | detect synthetic identity and mule risk | opaque adverse treatment without owner |
| AML compliance | review red flags and suspicious activity | SAR-sensitive leakage |
| Funding activation | verify funding source and return risk | funds hold without clear policy |
| Customer support | explain status and next action | chatbot exposing restricted details |
Guardrail: every downstream use of onboarding evidence should carry source, purpose, retention class and access policy.
13. Audit Evidence Binder
13.1 Binder Structure
# Account Opening Evidence Binder
Application id:
Customer token:
Product:
Channel:
Decision outcome:
Current state:
Consent and disclosure:
Eligibility decision:
Identity proofing result:
CIP verification result:
CDD risk profile:
KYB / UBO package:
Fraud signal bundle:
AML referral status:
Funding and activation status:
Customer communications:
Human review / overrides:
Models / rules / vendor versions:
Exception / waiver references:
Complaint / appeal linkage:
Retention / legal hold / SAR-sensitive flags:
13.2 Evidence Completeness Checklist
| Question | Evidence |
|---|---|
| What did the customer submit? | application snapshot, document ids |
| What did the system verify? | proofing and CIP verification records |
| What did AI influence? | model signals, intended use, output hashes |
| Why was the decision made? | reason codes, policy/rule/model versions |
| Who reviewed exceptions? | reviewer id/role, disposition, notes |
| What did the customer see? | template id, rendered message, delivery |
| Was AML/SAR-sensitive information protected? | access log, restricted communication |
| Was the account funded/activated correctly? | activation record and restrictions |
| Can the case be replayed? | evidence refs and versioned artifacts |
14. RACI
| Capability | Product | Architecture | KYC/CIP | BSA/AML | Fraud | Privacy | Model Risk | Ops | Legal/Compliance |
|---|---|---|---|---|---|---|---|---|---|
| Journey design | A | C | C | C | C | C | C | C | C |
| Decision taxonomy | A | R | R | R | R | C | C | C | A |
| Identity proofing service | C | A/R | R | C | C | C | C | R | C |
| CIP policy mapping | C | C | R | A | C | C | C | R | A |
| CDD risk profile | C | C | C | A/R | C | C | C | R | A |
| KYB / UBO flow | C | C | R | A/R | C | C | C | R | A |
| Fraud model / review | C | C | C | C | A/R | C | C | R | C |
| AML referral / SAR-sensitive handling | C | C | C | A/R | C | C | C | R | A |
| Customer communication catalog | A | C | C | C | C | C | C | R | A |
| Model inventory / eval | C | C | C | C | C | C | A/R | C | C |
| Evidence binder | C | A/R | R | R | R | C | C | R | C |
| Exception queue operations | C | C | R | R | R | C | C | A/R | C |
A = accountable, R = responsible, C = consulted. Exact role names and delegated authorities should follow the institution operating model.
15. KRIs and Management Information
| Metric | Why it matters |
|---|---|
| Straight-through approval rate by risk tier | efficiency without hiding risk mix |
| Manual review rate by gate | queue capacity and control friction |
| Review SLA / aging | customer harm and operational bottleneck |
| RFI completion and repeat-RFI rate | evidence burden |
| IDV retry and fail rate by segment/device/channel | inclusion and accessibility |
| CIP discrepancy resolution rate | policy and data quality |
| KYB / UBO abandonment | small business friction |
| Fraud review overturn rate | model precision and analyst consistency |
| AML referral quality | red flag evidence usefulness |
| Decline / hold reason distribution | policy drift and customer impact |
| Appeal / reconsideration upheld rate | false reject signal |
| Early-life fraud loss / mule detection | onboarding effectiveness |
| Early-life AML case quality | CDD profile quality |
| Funding return / hold complaint rate | activation risk |
| Customer complaints linked to onboarding | harm signal |
| Evidence binder defect rate | audit readiness |
| Model drift / vendor degradation | production AI control |
Management dashboard should show conversion and risk together:
conversion + risk quality + customer harm + evidence readiness
If conversion improves while false rejects, appeals, early fraud or evidence defects worsen, the onboarding program is not healthier.
16. Implementation Roadmap
16.1 First 30 Days: Decision Inventory
| Workstream | Output |
|---|---|
| Journey mapping | end-to-end state machine and drop-off map |
| Decision inventory | all approve / hold / decline / restrict / activate decisions |
| Owner mapping | decision family owner and approval authority |
| Source anchor mapping | FFIEC / FinCEN / NIST / internal policy to control objectives |
| Evidence audit | what exists, what is missing, what cannot be replayed |
| Model inventory | IDV, fraud, CDD, routing, LLM assets and intended use |
16.2 Days 31-60: Control Architecture
| Workstream | Output |
|---|---|
| Reason taxonomy | controlled reason code catalog |
| Exception queue | queue taxonomy, SLA, reviewer SOP |
| Evidence ledger | application, proofing, CIP, CDD, KYB, fraud, AML, communication schema |
| Communication catalog | approved RFI / hold / decline / activation messages |
| Risk-tier matrix | tier definitions and activation restrictions |
| Eval plan | model and AI assistant eval slices |
16.3 Days 61-90: Production Governance
| Workstream | Output |
|---|---|
| Release gates | go/no-go checklist and evidence requirements |
| Monitoring | KRI dashboard and alert thresholds |
| QA program | reviewer calibration and sampling |
| Incident / harm playbook | false reject, vendor outage, SAR leakage, funding hold, privacy event |
| Management review | monthly onboarding decision pack |
| Portfolio pack | architecture memo, diagrams, evidence pack, interview answer |
17. Anti-Patterns
| Anti-pattern | Failure mode | Better design |
|---|---|---|
| Buy an IDV vendor and call it KYC | misses CIP/CDD owner, evidence, exception and activation controls | identity proofing as one gate inside broader decision architecture |
One KYC failed bucket | reason, owner, recourse and metrics collapse | decision family taxonomy |
| LLM writes customer decline reason | invented or inconsistent reasons | approved reason code + template |
| AML and fraud rules exposed through chatbot | rule leakage and SAR confidentiality risk | restricted-info filter and safe status messages |
| Manual review as unlimited safety net | queue aging and inconsistent decisions | queue design, SLA, QA, capacity model |
| Funding immediately after account id creation | mule / synthetic identity monetization | restricted activation and funding controls |
| UBO data flattened into customer table | source provenance and ownership history lost | KYB / UBO evidence graph |
| Conversion-only OKR | hidden false rejects and abandoned harmed customers | balanced risk, friction, harm and evidence metrics |
| Vendor score as final decision | no institutional accountability | policy decision service owns outcome |
| No replay evidence until audit asks | impossible to reconstruct decision | runtime evidence binder |
18. Interview Pack
Q1: 如何设计 AI 驱动的数字开户 / KYC 决策架构?
30 秒版本:
我会把开户设计成状态机和 decision gate，而不是单个 KYC 模型。核心 gate 包括 consent、product eligibility、identity proofing、CIP verification、CDD risk profile、small business KYB/UBO、fraud/synthetic identity、AML referral、funding activation 和 customer communication。每个 gate 都有 owner、reason code、evidence、review queue 和客户安全文案。AI 用于抽取、评分、路由、摘要和完整性检查，但不替代 Legal/Compliance 的适用性判断、SAR decision 或正式拒绝沟通。
2 分钟版本:
我会先定义 account opening state machine: application started、consent captured、identity proofing、CIP verification、CDD profile、KYB/UBO review、fraud/AML screening、decision pending、approved/restricted/RFI/declined、funding activation 和 early-life monitoring。 架构上用 journey orchestrator 协调流程，用 policy decision service 做 outcome，用 identity/CIP/CDD/KYB/fraud/AML/funding 服务输出结构化 decision signals，再把所有输入、模型版本、规则版本、人工复核和客户通知写入 evidence ledger。 对身份，我用 NIST 800-63-4 的 resolution、evidence validation、attribute validation、verification、enrollment。对 KYC/CIP/CDD，我把 FFIEC/FinCEN source anchors 转成机构政策、证据和 owner，不直接下法律结论。对小企业，我区分 entity exists、authority、beneficial owners/control person 和 business purpose。 成功指标不是单纯通过率，而是 eligible activation、false reject、RFI burden、review SLA、abandonment、segment friction、early-life fraud/AML quality、complaint/appeal outcome 和 audit replay。
Q2: IDV vendor pass 后为什么还不能直接开通全功能账户?
30 秒版本:
IDV pass 只是 identity proofing signal，通常不能替代 CIP/CDD、fraud、AML 和 funding activation 决策。开户全功能激活还要看 CIP reasonable belief、CDD risk profile、欺诈/合成身份、制裁/AML referral、首次入金风险和产品限制。
2 分钟版本:
我会把 IDV 输出当成 evidence validation / identity verification 的输入。CIP gate 需要按机构 written program 判断是否能形成对客户真实身份的合理信念；CDD gate 需要建立 relationship purpose、expected activity 和 risk profile；fraud gate 要看 device、graph、velocity、synthetic identity；funding gate 要看入金来源和 return risk。因此正确做法是 approve、approve restricted、hold、RFI、manual review、decline 等状态化处理，而不是 vendor green check 后直接 active。
Q3: 小企业开户中 UBO / KYB 最容易出什么架构问题?
30 秒版本:
最大问题是把实体、授权人、实益拥有人、控制人、BOI source 和 CDD profile 混成一个客户字段。正确设计应保留 source provenance、ownership/control graph、authority evidence、verification status、risk profile 和 update triggers。
2 分钟版本:
小企业开户我会拆成四个问题: entity exists、applicant has authority、beneficial owners/control person identified and verified where applicable、business nature and expected activity understood。AI 可以抽取文件、匹配注册信息、做 ownership graph consistency 和异常提示，但不能把隐藏所有权推断成事实。FinCEN BOI、客户 attestation、state registry、vendor KYB 和内部 CDD profile 都是不同来源，必须保留 provenance 和冲突处理。具体 CDD/BOI 适用性和阈值由 Legal/Compliance 判断。
19. Portfolio Lab
为 digital checking + small business checking 设计一个 2 周作品集:
Deliverable 1: Architecture Memo
内容:
- source anchor map
- onboarding state machine
- decision gate table
- risk-tiering matrix
- evidence binder schema
- customer communication owner map
Deliverable 2: C4 / Flow Diagram Description
Customer channels
-> journey orchestrator
-> consent service
-> decision services
-> exception queues
-> core banking
-> funding activation
-> evidence ledger
-> monitoring dashboard
Deliverable 3: Decision Table Pack
至少包含:
- identity proofing result to action
- CIP discrepancy to action
- CDD risk tier to review path
- KYB / UBO conflict to RFI / review
- fraud / AML referral boundary
- activation restriction release criteria
Deliverable 4: Evidence and Controls Checklist
交付:
- sample evidence binder
- model inventory
- eval slice list
- QA sampling plan
- management dashboard mock table
Deliverable 5: Interview Storyline
一句话定位:
我不是把 AI 放进 KYC，而是把开户设计成受治理的 decision-and-evidence fabric，让增长、风险、合规、运营和客户体验能在同一套状态、证据和 owner 语言里工作。