AI Deepfake / Synthetic Identity / Liveness / Authentication Fraud Architecture Playbook

定位: 面向高级 AI PM / Senior BA / Product Architect / Fraud Technology Architect / Identity Platform Architect / Financial Retail Transformation Lead, 把 deepfake、synthetic identity、liveness bypass、voice clone、account recovery takeover 和 authentication fraud 从零散风控功能升级为可运营的 identity fraud control architecture。 适用范围: digital account opening、KYC / CIP support、remote identity proofing、mobile banking login、call center、account recovery、beneficiary enrollment、RTP / wire / card high-risk action、loan origination、branch-assisted digital journey、fraud operations and model/vendor governance。 核心产出: threat taxonomy、identity proofing architecture、liveness / PAD control matrix、voice deepfake control map、device/network behavioral signal catalog、step-up authentication policy、human review escalation、customer friction design、evidence bundle、model/eval plan、red-team scenarios、operating model、KRI dashboard、30-day lab 和 portfolio pack。

---

0. Disclaimer

本文是学习、作品集、架构训练和内部治理讨论材料。

本文不是法律意见、合规结论、监管解释、模型验证报告、欺诈处置指令、身份核验合格结论、消费者通知建议或 vendor endorsement。

正式项目必须由 Legal、Compliance、Fraud Risk、Information Security、Privacy、Model Risk、Customer Experience、Operations、Accessibility、Business Owner、Vendor Management、Internal Audit 和管理层结合机构类型、司法辖区、产品风险、客户分层、渠道、认证方式、vendor performance 和内部政策确认。

关键边界:

• AI 可以辅助识别 forged media、deepfake artifacts、synthetic identity linkage、session risk、call risk、evidence gaps 和 escalation route。
• AI 不应单独决定客户身份真实、账户关闭、交易拒绝、客户责任归属或欺诈赔付。
• Liveness / PAD vendor pass 不应被解释为完整 identity proofing pass。
• Voice biometric pass 不应被解释为高风险交易授权。
• Controls depend on jurisdiction, channel, product risk, customer segment, authentication method, accessibility obligations, privacy constraints and vendor performance。
• 对客户造成实质影响的 decisioning、notice、appeal、exception 和 adverse action 流程必须由机构政策和适用规则确认。

---

1. Executive Framing

Deepfake fraud 的常见误区是把目标缩成:

buy better liveness
add face match
add MFA
detect voice clone
block suspicious devices

这些能力必要但不充分。高级架构目标应该是:

attack-chain coverage
  + identity assurance
  + media integrity
  + authenticator trust
  + transaction intent
  + risk-based friction
  + human review
  + evidence replay
  + model/vendor governance

一句话:

AI deepfake fraud defense is an identity assurance and evidence architecture before it is a biometric model selection problem.

1.1 Product Principles

1. Identity proofing 是 journey, 不是 selfie step。
2. Liveness 是 control, 不是 final decision。
3. Authentication proves control of an authenticator, not necessarily legitimate intent。
4. Transaction risk must be linked to authentication context。
5. Human review needs source evidence, not only risk scores。
6. Customer friction must be targeted, explainable and recoverable。
7. Vendor performance must be tested against realistic attack artifacts。
8. AI governance must cover fraud models, deepfake detectors, orchestration rules and LLM summaries。

2. Source Anchors

架构使用方式:

source anchor -> control objective -> journey requirement -> signal requirement
  -> decision boundary -> evidence artifact -> owner -> review cadence

不要把 source anchors 当成 checklist。更好的做法是把它们转成 product controls, test cases, evidence requirements and governance gates。

---

3. Threat Taxonomy

3.1 Threat Families

3.2 Attack Chain View

recon -> PII collection -> identity fabrication or theft
  -> remote proofing attack -> authenticator binding
  -> account aging or account recovery -> limit increase
  -> beneficiary enrollment -> payment initiation
  -> step-up bypass -> funds movement -> dispute and laundering

Control coverage should map to every attack step. A control that only catches fake selfies at onboarding does not cover account recovery, voice clone wire approval or scam-authenticated RTP。

3.3 Attacker Capability Levels

3.4 Control Coverage Matrix

---

4. Identity Proofing Architecture

4.1 Proofing Process Model

Identity proofing should be modeled as four steps:

identity resolution -> evidence validation -> identity verification -> enrollment

4.2 Reference Architecture

channel capture -> risk pre-screen -> document evidence capture
  -> document validation and live capture -> core attribute validation
  -> biometric comparison -> liveness / PAD / media integrity
  -> identity graph and synthetic detection -> proofing orchestration
  -> enrollment and authenticator binding -> evidence ledger and QA

4.3 Identity Proofing Types

4.4 Identity Claim Object

Minimum fields: identity_claim_id, channel, product, customer segment, proofing type, evidence type, source checks, validation result, face match result, PAD result, media integrity flags, graph score, decision route and reason codes。

5. Liveness / Presentation Attack Controls

5.1 Control Definitions

5.2 Face Match Boundary

Face match can answer:

Does this face look similar to the ID portrait?

It cannot fully answer:

Is this a live person?
Is the media produced by a genuine sensor?
Is the document physically present?
Is this the rightful owner?
Is the identity synthetic?
Is the customer acting voluntarily?

5.3 PAD Matrix

5.4 Liveness Decision Table

5.5 Accessibility and Inclusion

Liveness controls can fail for legitimate users because of device quality, disability, age-related variation, lighting, document wear, cultural constraints or limited digital literacy。

Design requirement:

Every high-friction biometric path needs an alternative proofing path,
documented exception handling and QA review of disparate friction.

5.6 Evidence Requirements

---

6. Voice Deepfake Controls

6.1 Voice Threat Patterns

6.2 Voice Biometric Boundary

Voice biometric can help identify a caller, but should not be sole authorization for high-risk actions。

voice biometric = one signal in call risk
call risk = voice + ANI + device + behavior + request type + account history
high-risk action = separate authorization and evidence

6.3 Call Center Control Stack

6.4 Agent Script Requirements

• Do not reveal which authentication factor failed。
• Do not coach attackers through recovery。
• Do not treat urgency as proof。
• Ask purpose and relationship questions for high-risk payments。
• Use verified callback route for suspicious high-risk requests。
• Record reason codes in structured fields。
• Escalate suspected deepfake or impersonation without accusing the customer。

6.5 Voice Evidence Bundle

Minimum evidence: call id, recording reference, voice match / anti-spoof result, ANI / carrier risk, transcript extracts, agent action, callback result and customer notification。

---

7. Device / Network / Behavioral Signals

7.1 Signal Catalog

Core signal families include device integrity, device identity, network reputation, SIM / phone age, email risk, behavioral patterns, session anomalies and linkage across shared devices, addresses, phones or IPs。

7.2 Device Binding Model

proofed identity -> trusted device enrollment -> authenticator binding
  -> device health monitoring -> risk-based re-verification

Device trust decays after OS compromise, SIM change, authenticator reset, geo jump, device sharing, malware indicators or customer report。

7.3 Signal Quality Rules

7.4 Behavioral Signal Boundary

Behavioral biometrics should be treated as risk signal, not identity proof by itself。

Better use cases: detect remote access scam patterns、bot applications、unfamiliar user sessions、step-up triggers and investigation evidence。

Risky use cases: hard decline solely on behavior score、customer conclusion without source explanation、using sensitive proxy variables without governance。

---

8. Step-Up Authentication

8.1 Step-Up Philosophy

Step-up should answer:

Given this customer, device, channel, action and transaction,
what additional assurance is proportional and effective?

Bad step-up: send OTP for everything。

Better step-up: select method based on attack, account state, action risk, customer capability and fraud evidence。

8.2 Trigger Matrix

8.3 Method Selection

8.4 Cooling-Off and Limits

For high-risk changes, authentication alone may not be enough。

Controls include delayed activation for new beneficiary、lower initial limits for new account/device、notification to old and new contact points、temporary hold after recovery、dual approval for business payment admin and enhanced monitoring after proofing exception。

8.5 Evidence Record

Minimum fields: step-up event id, trigger, channel, method selected, method result, friction message id, risk score before/after, policy version and final route。

---

9. Human Review Escalation

9.1 When Human Review Is Needed

Human review is not a dumping ground for low-confidence automation. It is a control with scope, authority and evidence。

Escalate when vendor signals conflict, media integrity warning appears on high-value product, synthetic identity graph score is high, customer is vulnerable, recovery affects contact points, high-risk transaction follows recovery, call center detects voice clone or model policy could materially harm legitimate access。

9.2 Reviewer Workbench

Reviewer screen should show:

• identity proofing timeline。
• document validation result。
• face match and PAD result with explanation codes。
• media integrity and injection flags。
• device/network/session telemetry。
• identity graph and linked entities。
• customer product / transaction risk。
• previous fraud / dispute / complaint history where permitted。
• recommended route with policy basis。
• source evidence, not only AI summary。
• required decision reason codes。

9.3 Escalation Queues

9.4 Human Decision Boundary

Reviewer may approve with monitoring、request alternative proofing、route to trusted referee、decline or restrict according to policy、place transaction hold according to authority、escalate to fraud investigation or escalate to AML / financial crime if typology suggests。

Reviewer should not rely only on model score、invent unsupported facts、bypass customer notice requirements、disclose sensitive fraud rules or treat AI confidence as legal conclusion。

---

10. Customer Friction Design

10.1 Friction Types

10.2 Friction Design Rules

1. Match friction to attack type。
2. Explain safe next step without revealing detection logic。
3. Preserve access for legitimate customers through alternatives。
4. Avoid repeated loops after vendor inconclusive result。
5. Use stronger friction for irreversible high-value actions。
6. Keep customer care and fraud investigation language distinct。
7. Measure abandonment, complaint, approval, fraud capture and disparate friction。

10.3 Scam-Sensitive UX

For impersonation scams and voice clone coercion, the customer may be authenticated and still at risk。

Good friction asks relationship and purpose, names scam pattern in plain language, encourages independent callback, avoids shaming, creates pause before irreversible payment and routes vulnerable customer concerns to trained support。

Bad friction is generic “Are you sure?”, technical MFA only, warning after funds movement or disclosure that “your transaction is suspicious” without actionable guidance。

10.4 Segment Considerations

---

11. Fraud Ops Evidence

11.1 Evidence-First Workflow

signal -> policy trigger -> evidence packet -> AI summary
  -> human review -> decision reason -> customer action
  -> case outcome -> QA -> model/vendor feedback

AI summary should be generated after evidence packet assembly, not before。

11.2 Evidence Bundle Schema

Minimum fields: case id, journey, threat candidates, source events, authentication evidence, device/network evidence, transaction context, AI assistance version, human decision and rationale codes。

11.3 Evidence Quality Levels

Target: automated step-up can start with E1/E2, manual review should receive E3, dispute / audit replay should target E4/E5。

11.4 Fraud Ops Case States

created -> evidence_ready -> reviewer_assigned -> customer_contact_needed
  -> hold_or_restrict -> decision_recorded -> customer_resolution
  -> outcome_confirmed -> QA_sampled -> closed

State transitions must log actor、timestamp、policy version、reason code、evidence references、customer communication and override flag。

---

12. Model / Eval Design

12.1 Model Types

12.2 Eval Set Composition

12.3 Eval Metrics

12.4 Release Gate

Release gate for model/vendor/rule changes:

1. Threat coverage reviewed。
2. Attack artifact eval passed。
3. Genuine customer false positive reviewed by segment。
4. Accessibility impact reviewed。
5. Evidence logging verified。
6. Human review route tested。
7. Rollback plan documented。
8. Monitoring dashboard configured。
9. Vendor SLA and incident path confirmed。
10. Business owner approval recorded。

12.5 LLM Evidence Assistant Controls

LLM can summarize identity proofing timeline、list evidence gaps、translate vendor codes、draft internal reviewer notes、propose escalation queue based on policy and generate QA checklist。

LLM must not decide identity is genuine or fraudulent、tell customer sensitive flag details、recommend adverse action without policy basis、invent signals、expose hidden fraud rules or replace reviewer rationale。

12.6 Monitoring

---

13. Red-Team Scenarios

13.1 Scenario Format

Each red-team case should include scenario id, threat family, target journey, attacker goal, attack steps, expected controls, evidence required, expected customer friction and pass/fail criteria。

13.2 Red-Team Library

13.3 Tabletop Questions

1. Which control detected the attack first?
2. Which signal was missing?
3. Did the customer see useful friction?
4. Did human review have enough evidence?
5. Could audit replay the case?
6. Did vendor response codes support root cause analysis?
7. Did the fallback path weaken control?
8. Did the scenario expose accessibility or fairness issues?
9. Which policy needs change?
10. Which eval case should be added?

---

14. Operating Model

14.1 RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed。

14.2 Governance Forums

15. Metrics / KRIs

15.1 Executive Metrics

15.2 Risk KRIs

---

16. Financial Retail Scenario Patterns

16.1 Digital Account Opening Synthetic Identity

Risk pattern: applicant has plausible PII, thin history, shared address / phone / device, weak uniqueness, early funding from unrelated parties。

Signals: new phone and email, address reused by many applications, device cluster, bureau thin file, authoritative source partial mismatch, early high-velocity funding。

Controls: identity graph, attribute validation, document and biometric proofing, initial limits, account aging monitoring, enhanced review for graph clusters。

16.2 Deepfake Remote Onboarding

Risk pattern: document appears valid, face match high, but media capture shows virtual camera, unusual artifacts or PAD warnings。

Controls: live document capture, passive and active PAD, device attestation, virtual camera / emulator detection, manual review for vendor disagreement, alternate proofing for genuine users。

16.3 Account Recovery Takeover

Risk pattern: attacker cannot login normally, uses recovery to replace contact point and enroll new authenticator。

Controls: recovery risk scoring, old-channel notice, cooling-off, stronger proofing after suspicious recovery, payment limits after recovery, human review for high-risk changes。

16.4 Voice Clone Wire Request

Risk pattern: caller sounds like customer, passes weak voice biometric, requests urgent beneficiary or wire action。

Controls: anti-spoofing, phrase replay detection, call origin risk, verified callback, in-app confirmation, separate authorization for wire。

16.5 Business Payment Impersonation

Risk pattern: executive or vendor impersonation pushes urgent payment, often off-hours or with changed beneficiary。

Controls: dual approval, callback to known contact, beneficiary change delay, business role-based access, employee education, payment anomaly monitoring。

16.6 Scam-Authenticated RTP

Risk pattern: customer passes MFA and initiates real-time payment under scam pressure。

Controls: beneficiary risk, scam warning, purpose / relationship question, pause / cooling-off, customer care escalation, post-event monitoring。

---

17. 30-Day Lab

目标: 30 天内完成一套可展示的 AI-era identity fraud architecture portfolio。推荐选择一个主线: retail digital onboarding、account recovery takeover、voice deepfake wire、synthetic identity loan application 或 scam-authenticated RTP。

Completion standard:

• Can explain why liveness is not identity proofing。
• Can map deepfake attack chain to controls。
• Can show source-linked evidence bundle。
• Can show step-up policy by risk tier。
• Can show human review route and reason codes。
• Can show red-team scenarios and model/vendor eval。
• Can explain customer friction trade-offs。
• Can show operating model and KRIs。

---

18. Interview Answers

Q1: 如何解释 identity proofing、liveness 和 authentication 的区别?

30 秒:

Identity proofing 建立某个 applicant 与真实身份之间的可信关系; liveness / PAD 只是验证采集样本是否来自现场活体或检测 presentation attack; authentication 证明某次访问控制了已绑定的 authenticator。三者相关但不能互相替代。

2 分钟:

我会按 NIST SP 800-63A 的 resolution、validation、verification 来解释 proofing。Resolution 关注 claimed identity 是否对应一个唯一真实人; validation 关注证件和属性是否真实有效; verification 关注申请人是否是证据对应的人。Liveness / PAD 只解决 biometric capture 是否被照片、回放、deepfake 或注入攻击欺骗。Authentication 是后续登录或高风险动作时验证 authenticator。一个人可能通过 MFA 但正在被骗, 也可能 face match 高但媒体是 deepfake, 所以架构要把 proofing、media integrity、authenticator binding 和 transaction risk 组合起来。

Q2: 为什么不能只买一个更强的 liveness vendor?

因为 deepfake fraud 是 attack chain。Liveness vendor 主要覆盖 biometric presentation attack, 但 synthetic identity、digital injection、device compromise、account recovery takeover、voice clone、push payment scam 和 insider override 仍可能绕过。正确做法是 layered defense: document validation、live capture、PAD、device attestation、identity graph、step-up、transaction risk、human review 和 evidence ledger。

Q3: Digital injection 与 presentation attack 有什么不同?

Presentation attack 是把攻击物呈现在 biometric capture subsystem 前, 例如照片、屏幕回放或面具。Digital injection 是把伪造或修改后的媒体插入 capture point 和 comparison component 之间, 例如虚拟摄像头、模拟器或被篡改 SDK。前者更多靠 PAD 和 liveness, 后者需要 sensor assurance、device attestation、SDK integrity、virtual camera detection 和 channel protection。

Q4: Synthetic identity fraud 如何设计控制?

我会从 identity resolution 开始, 不是只看证件。核心是验证身份是否唯一、真实、属性一致并与申请人相关。控制包括 authoritative / credible source checks、identity graph、phone/email/address/device linkage、death records where applicable、bureau and lifecycle signals、initial limits、account aging monitoring 和 manual review。Synthetic identity 可能有 credit file, 所以 credit score 不是充分证据。

Q5: Voice biometric 在 call center 中应该如何定位?

Voice biometric 是 call risk 的一个信号, 不是高风险动作授权。Voice clone、replay、ANI spoofing 和 social engineering 都可能绕过单一 voice match。我会把 voice anti-spoofing、call origin risk、intent analysis、recent account changes、verified callback、in-app confirmation、cooling-off 和 agent escalation 组合起来。

Q6: 如何设计 step-up authentication?

Step-up 要按 customer、device、channel、action、transaction 和 threat 动态选择。新设备登录可能用 passkey or app confirmation; phone change 要 old-channel notice and cooling-off; new beneficiary high-value wire 要 strong auth plus scam warning and possible manual review。目标不是更多 OTP, 而是用合适摩擦降低具体风险。

Q7: 如何平衡 fraud control 与 customer friction?

我会把 friction 分为 informational、verification、temporal、limit、channel、human 和 exit friction。低风险用轻摩擦, 高风险和不可逆资金流用强摩擦。对 legitimate users 要有 alternative proofing、exception handling 和 clear next step。指标上同时看 fraud capture、abandonment、complaints、approval rate、manual review overturn 和 segment-level friction。

Q8: 如何做 deepfake / liveness vendor eval?

Eval set 要同时包含 genuine users、accessibility cases、poor-quality genuine media、commodity attacks、advanced deepfake, digital injection simulation 和 vendor disagreement cases。指标不只看 pass rate, 还要看 attack accept rate、bona fide reject rate、inconclusive rate、segment false positive、drift、reason code usefulness、evidence logging 和 fallback behavior。

Q9: 如何把 NIST AI RMF 用到该系统?

Govern 定义 owner、policy、vendor accountability 和 human oversight; Map 定义 threats、channels、customers、data and impacts; Measure 用 eval set、red-team、KRI、drift 和 QA 测量风险; Manage 用 release gates、monitoring、incident response、fallback and remediation 控制风险。AI RMF 不替代金融业务规则, 但提供 AI risk governance skeleton。

Q10: 如何向高管解释投资价值?

这不是单纯提高 KYC 通过率, 而是降低 identity fraud loss、account recovery takeover、authorized scam loss、customer harm and audit weakness。投资点包括 attack-chain coverage、evidence replay、risk-based friction、vendor governance and fraud ops capacity。成熟系统可以在不对所有客户加重摩擦的情况下, 把强控制放到真正高风险的动作上。

---

19. Portfolio Deliverables

最终作品集建议包含: identity-fraud-threat-taxonomy.md, identity-proofing-architecture.md, liveness-pad-control-matrix.md, voice-deepfake-call-center-controls.md, device-network-signal-catalog.md, step-up-authentication-policy.md, customer-friction-design.md, fraud-ops-evidence-bundle.yaml, model-vendor-eval-plan.md, red-team-scenarios.md, operating-model-raci.md, kri-dashboard-spec.md and interview-pack.md。

Portfolio narrative:

I designed an AI-era identity fraud architecture for financial retail.
It maps deepfake, synthetic identity, liveness bypass, voice clone and recovery attacks
to identity proofing, media integrity, device assurance, authentication and transaction controls.
It uses risk-based friction instead of blanket friction,
keeps human review evidence-grounded,
tests vendors and models against realistic attack artifacts,
and preserves audit-replayable evidence from source signal to decision.

---

20. Common Pitfalls

---

21. Final Operating View

AI-era identity fraud architecture should answer ten questions:

1. Which threats are in scope?
2. Which source anchors define control expectations?
3. Which journeys expose identity proofing, authentication or transaction risk?
4. Which controls detect presentation attack, digital injection and forged media?
5. Which controls detect synthetic identity and attribute inconsistency?
6. Which authentication events are insufficient for high-risk actions?
7. Which step-up method is proportional to each risk?
8. Which customers need alternative proofing or assisted review?
9. Which evidence supports each approve, reject, step-up and override?
10. Which metrics show control effectiveness, customer harm and drift?

Final memory sentence:

A mature identity fraud system is not selfie-first or MFA-first. It is proofing-aware, media-integrity-aware, device-aware, transaction-aware, human-reviewed, customer-sensitive and evidence-replayable.