AI 底层逻辑 / 经典论文
AI AML Alert Triage：调查工作台架构
以下来源只作为架构和控制设计锚点。具体适用性、监管口径、阈值、保存期限、SAR filing decision 和客户处置由 Legal / BSA-AML Compliance / Sanctions / Model Risk / Internal Audit / Business Owner 确认。
557 行ai-foundations/papers/144-ai-aml-alert-triage-investigation-workbench-architecture.md
AI AML Alert Triage / Investigation Workbench Architecture 解读
面向对象: Senior AI PM / Senior BA / Product Architect / AML Technology Architect / Model Risk Partner / Financial Crime Operations Lead。 核心问题: 如何把 AML alert operations 从“规则告警 + 人工翻系统 + 个案经验”升级为 evidence-first、graph/context-aware、human-owned、model-risk-controlled 的 AI investigation workbench。 学习目标: 能设计队列优先级、实体解析、图谱上下文、证据工作区、analyst copilot、处置建议、QA、SAR 草稿护栏、调参反馈、审计轨迹、职责隔离和采用度量, 同时不把 AI 误设计成 SAR 自动决策器。
Source Anchors
以下来源只作为架构和控制设计锚点。具体适用性、监管口径、阈值、保存期限、SAR filing decision 和客户处置由 Legal / BSA-AML Compliance / Sanctions / Model Risk / Internal Audit / Business Owner 确认。
| Source | Official link | 在本文中的架构用法 |
|---|---|---|
| FFIEC BSA/AML Manual - Suspicious Activity Reporting | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/04 | 把 workbench 对齐到 unusual activity identification、managing alerts、SAR decision making、SAR completion、continuing activity monitoring 五段链路; 强调 alert management、staffing、manual/automated monitoring 和支持证据。 |
| FFIEC SAR Examination Procedures | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/04_ep | 用于设计 alert review timeliness、research evidence、CDD/EDD context、documented no-file decision、escalation、prepared/filed SAR quality 和 transaction testing 证据。 |
| FFIEC Customer Due Diligence | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/02 | 用 customer risk profile、expected activity、ongoing monitoring 支撑 context engine 和 false-positive explanation。 |
| FFIEC CDD Examination Procedures | https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/02_ep | 用于定义客户风险画像变更、信息不足、beneficial ownership、OFAC context 和调查时应暴露的 CDD 证据。 |
| FFIEC BSA/AML Independent Testing | https://bsaaml.ffiec.gov/manual/AssessingTheBSAAMLComplianceProgram/03 | 用于 QA、独立测试、系统/数据/报告完整准确性、SAR process review、整改闭环和审计工作底稿。 |
| FFIEC Appendix F - ML/TF Red Flags | https://bsaaml.ffiec.gov/manual/Appendices/07 | 仅作为 red flag 和 additional scrutiny 的 source anchor; 本文不复制 typology/SAR narrative coverage。 |
| FFIEC Appendix L - SAR Quality Guidance | https://bsaaml.ffiec.gov/manual/Appendices/13 | 用于 SAR draft pre-check、evidence completeness、key-term guardrail 和 narrative quality review。 |
| FinCEN SAR Resources | https://www.fincen.gov/suspicious-activity-reports-sars | 用于 SAR 资源和 BSA E-Filing handoff 边界; workbench 不自动提交 SAR。 |
| FinCEN BSA Filing Information | https://www.fincen.gov/resources/filing-information | 用于 filing workflow、E-Filing interface、submission acknowledgement、recordkeeping handoff 的系统边界。 |
| OFAC Sanctions List Service / Search | https://ofac.treasury.gov/sanctions-list-service 和 https://ofac.treasury.gov/sanctions-list-search-tool | 用于 sanctions hit context、hard-stop escalation 和 sanctions-screening evidence reference; AML workbench 不替代制裁筛查系统。 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI risk、eval、monitoring、human oversight 和 issue remediation。 |
| NIST AI RMF Core | https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ | 用四类 function 设计 continuous risk management, 避免把 AI governance 当一次性上线清单。 |
| NIST GenAI Profile | https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence | 用于 GenAI 特有风险: hallucination、data leakage、prompt injection、overreliance、third-party dependency、eval 和 red-team。 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 思路连接 policy、roles、operational control、performance evaluation、management review 和 continual improvement。 |
1. 一句话定位
AML Alert Triage / Investigation Workbench 不是“给告警系统加一个聊天框”。它是一个把告警、客户画像、交易时间线、实体网络、规则/模型信号、调查证据、人工判断、QA 发现、调参反馈和审计轨迹组织在一起的生产控制系统。
更准确的定义:
AML investigation workbench =
alert queue prioritization
+ entity resolution and graph context
+ evidence-first case assembly
+ analyst copilot
+ human-owned disposition
+ SAR draft guardrails
+ QA and tuning feedback
+ model risk controls
+ audit replay and segregation of duties
关键边界:
- AI 可以辅助排序、汇总、比对、检查缺口、提出 investigation next step、生成有引用的草稿和 QA pre-check。
- AI 不应自动决定 SAR filing / no filing。
- AI 不应自动提交 SAR、关闭高风险 case、解除 sanctions hit、通知客户、联系 law enforcement 或绕过 BSA/AML owner。
- AI 输出必须被当成可质疑的工作产品, 不是合规结论。
2. Architecture Mental Model
2.1 从 Alert Factory 到 Evidence Operating System
传统 AML 平台常见结构:
transaction monitoring rule/model
-> alert
-> analyst queue
-> manual research across systems
-> case note
-> close / escalate / SAR process
AI workbench 的目标结构:
alert signal
-> entity-resolved context
-> graph and timeline assembly
-> risk-prioritized queue
-> evidence workspace
-> copilot-supported investigation
-> human disposition and escalation
-> QA sample / case replay
-> tuning and coverage feedback
架构重心从“模型分数”转成“证据和流程”:
| Old center | New center |
|---|---|
| Alert count | Risk-adjusted queue value |
| Rule hit text | Evidence bundle |
| Analyst memory | Reusable investigation pattern |
| Individual case note | Traceable decision record |
| False-positive reduction only | Coverage, quality, timeliness, adoption, auditability |
| Model output | Human-owned decision with explainable support |
2.2 Workbench 的六个核心对象
| Object | 架构含义 | 不能省略的控制字段 |
|---|---|---|
| Alert | unusual activity signal, 来自规则、模型、referral、law-enforcement request 或 sanctions/fraud referral | source, scenario/model version, trigger facts, generated time, SLA, queue route |
| Subject / Entity | customer, account, beneficial owner, counterparty, device, address, business, merchant, wallet | entity confidence, source system, resolution method, conflict flag |
| Evidence | transaction, KYC/CDD, EDD, beneficial ownership, prior case, sanctions hit, document, analyst note | provenance, timestamp, permission class, citation id, freshness, completeness |
| Case | investigation container | assigned owner, status, escalation state, decision owner, QA state |
| Disposition | human-owned outcome such as close as no unusual activity, continue monitoring, escalate, SAR consideration | rationale, evidence references, reviewer identity, reason code, policy version |
| Feedback | QA finding, analyst disagreement, false-positive driver, scenario defect, data quality issue | feedback type, severity, owner, control route, retraining/tuning eligibility |
3. Reference Architecture
Source systems
Core banking, card, ACH/wire, RTP, digital channels, KYC/CDD, case management,
sanctions screening, fraud, CRM, documents, external lists, FinCEN/advisory registry
Data and identity layer
Data contracts, lineage, PII tagging, RBAC/ABAC, entity resolution, household/business graph,
counterparty graph, beneficial ownership graph, feature store, evidence ledger
Decision support layer
Alert scoring, queue prioritization, typology coverage link, case assembly,
retrieval, summarization, gap detection, disposition recommendation, QA pre-check
Workflow and controls layer
Case state machine, maker-checker, escalation, SAR draft handoff, tuning intake,
model risk gate, audit trail, retention class, access review
Experience layer
Queue console, investigation workspace, graph/timeline view, copilot panel,
evidence cards, disposition panel, QA console, management dashboard
3.1 Key Architectural Decisions
| Decision | Recommended position | Rationale | Risk if wrong |
|---|---|---|---|
| Copilot authority | Read-mostly, recommendation-only for AML decisions | Preserves human ownership and examiner replay | AI becomes hidden decision maker |
| Evidence model | Structured evidence ledger before free-text summary | Enables citation, QA, SAR draft guardrails and audit replay | Beautiful summary with unverifiable claims |
| Entity resolution | Confidence-banded, reversible, source-visible | AML graph errors can contaminate multiple cases | False linkage, privacy overexposure, bad escalation |
| Queue prioritization | Risk-adjusted routing, not pure likelihood score | Operations need timeliness and coverage, not only model rank | Low-volume high-risk typologies starve |
| SAR draft | Draft packet with explicit human gate | AI may assist wording, not filing conclusion | Auto-filing pressure or SAR confidentiality breach |
| Tuning feedback | Controlled feedback taxonomy and change gate | Analyst labels are useful but noisy and incentive-shaped | Model learns operational shortcuts |
| Audit | Append-only event stream with version hashes | Supports replay across model, prompt, evidence, user and decision | Cannot explain why an alert was closed |
4. Queue Prioritization Architecture
Alert queue prioritization should not be a single “risk score”。It is a routing policy combining risk, timeliness, evidence sufficiency, customer context, scenario coverage, operational capacity and escalation constraints.
4.1 Priority Inputs
| Signal family | Examples | Architecture guardrail |
|---|---|---|
| Scenario severity | structuring, rapid movement, mule network, high-risk geography, law-enforcement referral | Severity maintained by AML scenario owner, not model team alone |
| Customer context | CDD risk profile, EDD status, expected activity, account age, occupation/business type | Show source and freshness; do not infer missing CDD as suspicious by itself |
| Transaction pattern | amount, velocity, corridor, product, counterparty novelty, cash/ACH/wire mix | Explain which facts caused priority; avoid opaque score only |
| Network context | shared address/device, beneficial owner overlap, counterparty cluster, prior cases | Entity confidence must travel with graph edges |
| Time sensitivity | regulatory clock, continuing activity, aged alert, repeated alert on same subject | SLA and aging must override pure risk score when required by policy |
| Evidence readiness | enough data for review, missing source, stale data, broken feed | Route incomplete cases to data exception, not analyst guesswork |
| Operational routing | analyst skill, language, sanctions expertise, EDD specialization, queue capacity | Capacity is a constraint, not a reason to suppress alert volume |
4.2 Priority Output
| Output | Required explanation |
|---|---|
priority_band | P1/P2/P3/P4 with policy-based reason |
route_to_queue | general AML, EDD, sanctions referral, fraud-AML, senior investigator, QA sample |
SLA_due_at | policy-derived due date and clock source |
top_drivers | 3-7 cited drivers, each tied to evidence |
missing_context | CDD, transaction, counterparty or document gaps |
review_warning | low entity confidence, conflicting data, possible sanctions relation, repeat alert |
Good prioritization answer:
This alert is P1 because it combines repeated below-threshold cash deposits,
new outbound wires to unrelated counterparties, high-risk customer profile,
and prior alert escalation within 90 days. Entity link confidence is medium
because address match conflicts with phone/device evidence. Review CDD expected
cash activity before disposition.
Bad prioritization answer:
Risk score 0.91. Recommended SAR.
5. Entity Resolution and Graph Context
AML investigation quality depends heavily on whether the system can correctly connect customers, accounts, counterparties, beneficial owners, devices, addresses and prior cases.
5.1 Entity Resolution Bands
| Band | Meaning | Product behavior |
|---|---|---|
| Certain | same customer/account id from authoritative source | Auto-merge in graph, cite source |
| High | strong deterministic match, such as government id plus name/date | Show merged view with provenance |
| Medium | multiple corroborating soft signals | Show as probable link, require analyst confirmation for escalation |
| Low | weak shared attribute only | Show as lead, not as fact |
| Conflict | source disagreement or stale identity | Trigger evidence warning and data-quality route |
5.2 Graph Views That Matter
| Graph | AML investigation use | Failure mode |
|---|---|---|
| Customer-account graph | subject owns, controls, signs, benefits from accounts | missing beneficial owner hides exposure |
| Counterparty graph | funds flow, repeated beneficiaries, pass-through chains | graph clutter without time/amount context |
| Device/address graph | mule rings, synthetic identity, shared digital footprint | over-linking households or shared businesses |
| Case graph | prior alerts, SARs, QA findings, repeat suspicious activity | SAR-sensitive access breach |
| Product/channel graph | ACH, wire, card, crypto on/off ramp, branch, ATM | channel gaps create blind spots |
Architecture rule:
Every graph edge needs source, timestamp, confidence, reason and access class.
6. Evidence Workspace
Evidence workspace is the center of the product. The copilot should sit beside evidence, not replace evidence.
6.1 Evidence Card Schema
evidence_id: ev_tx_2026_000184
case_id: case_aml_7182
source_system: wire_platform
source_record_id: wire_983810
evidence_type: transaction
event_time: 2026-06-12T16:21:08Z
subject_entity_id: ent_customer_431
related_entities: [ent_counterparty_882, ent_account_901]
summary: outbound wire to newly observed counterparty
facts:
amount: 24750.00
currency: USD
corridor: US->HK
channel: online_wire
quality:
freshness: current
completeness: complete
entity_confidence: high
controls:
access_class: aml_restricted
retention_class: bsa_supporting_documentation
citation_required: true
6.2 Evidence Completeness
| Investigation question | Minimum evidence |
|---|---|
| Is activity unusual for the customer? | CDD profile, expected activity, historical baseline, transaction sequence |
| Are counterparties related or high risk? | counterparty history, entity resolution, geography, sanctions/fraud referrals |
| Is this a one-off or continuing activity? | prior alerts, prior cases, repeat pattern, lookback period |
| Can the analyst close with rationale? | trigger facts, benign explanation, CDD consistency, reviewer note |
| Is SAR consideration escalated? | fact chronology, amount aggregation, subject details, evidence citations, escalation approval |
7. Analyst Copilot Patterns
7.1 High-Value Capabilities
| Capability | Good output | Required guardrail |
|---|---|---|
| Alert explanation | explains trigger and evidence drivers | cite source fields and scenario/model version |
| Timeline assembly | chronological facts with amount, party, channel | no inferred motive without evidence |
| Graph summary | relevant relationships and confidence | distinguish confirmed link from lead |
| Evidence gap check | missing CDD, stale EDD, absent counterparty context | route to data/task, not fabricated answer |
| Investigation plan | suggested next questions and documents | analyst decides which tasks to execute |
| Disposition assist | options with evidence for/against | no final SAR/no-SAR decision |
| Case note draft | concise cited summary | unsupported sentence blocker |
| QA pre-check | missing rationale, stale source, bad citation | QA owner can override with reason |
7.2 Structured Copilot Contract
copilot_output:
answer_type: investigation_summary
case_id: case_aml_7182
scope_boundary: "assistant summary, not final disposition"
claims:
- claim: "Customer received three inbound ACH credits and sent two wires within 24 hours."
evidence_ids: [ev_tx_1, ev_tx_2, ev_tx_3, ev_tx_4, ev_tx_5]
confidence: high
- claim: "Counterparty relationship is not established in customer profile."
evidence_ids: [ev_cdd_1, ev_counterparty_2]
confidence: medium
missing_evidence:
- latest EDD review
- stated business purpose for Hong Kong wire counterparty
prohibited_actions:
- auto_file_sar
- final_no_sar_decision
8. Disposition Recommendation Without Auto-SAR
Disposition recommendation is useful only when it is explicitly framed as decision support.
| Disposition option | AI can do | Human must do |
|---|---|---|
| Close as no unusual activity | identify benign evidence and draft rationale | decide closure and sign case |
| Continue monitoring | identify repeat pattern, missing lookback or future trigger | approve monitoring action and period |
| Escalate to investigation | explain risk drivers and evidence gaps | accept escalation and assign owner |
| Refer to sanctions/fraud/EDD | show matched signals and source context | determine referral path and handling |
| SAR consideration | assemble evidence packet and narrative draft | determine whether to file and approve final filing workflow |
Hard line:
The system may recommend "escalate for SAR consideration".
The system must not present "file SAR" as an autonomous decision.
9. SAR Draft Guardrails
SAR draft support should be implemented as a guarded writing workflow, not an autonomous filing workflow.
9.1 Guardrail Rules
| Rule | Product behavior |
|---|---|
| No unsupported claim | Every factual sentence must link to evidence id or analyst-entered note |
| No criminal conclusion | Use observed facts and suspicious indicators, not accusation language |
| No auto-filing | Submit/export requires authorized human step outside copilot autonomy |
| SAR confidentiality | Access, retrieval, logging and sharing must enforce SAR-sensitive controls |
| Key term support | Suggest official/internal key terms only with source anchor and reviewer approval |
| Draft provenance | Store model, prompt, evidence set, analyst edits and approval chain |
| Missing evidence warning | Block finalization of draft packet when required fields are absent under internal policy |
9.2 Draft Packet Boundary
The workbench can produce:
- cited fact chronology。
- subject/account/counterparty table。
- suspicious indicators observed。
- transactions selected for review。
- missing evidence and analyst questions。
- draft narrative marked as AI-assisted。
- QA checklist and reviewer comments。
The workbench should not produce:
- final filing conclusion without BSA/AML owner。
- hidden filing submission。
- customer notification。
- law-enforcement disclosure decision。
- sanctions blocking/release decision。
10. QA, Feedback and Tuning Loop
AML AI improves only if feedback is separated by type. “Analyst clicked close” is not automatically a negative label.
10.1 Feedback Taxonomy
| Feedback type | Meaning | Eligible use |
|---|---|---|
| Case disposition | human outcome for the case | operations analytics; model training only after QA controls |
| QA defect | documented quality issue | control improvement and training |
| Scenario defect | rule threshold/logic issue | scenario tuning workflow |
| Data quality defect | missing, stale, duplicated or conflicting source | data remediation |
| Copilot defect | hallucination, bad citation, missing evidence, unsafe wording | prompt/model/RAG eval and remediation |
| Entity resolution defect | false merge, missed link, confidence error | entity model tuning |
| Analyst disagreement | reasoned challenge to AI output | eval set enrichment |
| Compliance override | BSA/AML owner changed recommendation | policy/control review |
10.2 Tuning Guardrails
| Risk | Guardrail |
|---|---|
| Learning from noisy closures | Require QA-reviewed labels for high-impact model updates |
| Optimizing only for fewer alerts | Include coverage, SAR quality, false-negative proxies and QA findings |
| Hidden threshold drift | Version thresholds, retain calibration report, run coverage regression |
| Analyst incentive bias | Separate productivity metrics from training labels |
| Typology erosion | Link tuning change to scenario/typology coverage matrix |
| Model shortcut | Slice eval by product, customer type, channel, geography and alert source |
11. Model Risk and Validation
AML workbench is an AI system, not one model. Validation scope should include rules, ranking model, entity resolution, graph features, retrieval, prompts, LLM, judge, workflow, human oversight and monitoring.
| Component | Validation question |
|---|---|
| Queue model | Does prioritization improve timeliness and risk focus without starving low-volume typologies? |
| Entity resolution | Are false merges and missed links measured by segment and source? |
| Graph features | Are graph edges explainable, current and access-controlled? |
| RAG/retrieval | Does the copilot retrieve correct evidence and respect SAR-sensitive permissions? |
| LLM summary | Are factual claims supported and uncertainty expressed? |
| Disposition assist | Are options balanced and clearly non-final? |
| SAR draft | Are facts cited, language controlled and filing boundary enforced? |
| QA judge | Does automated QA align with human QA and avoid self-grading bias? |
| Workflow | Are escalation, maker-checker, audit trail and fallback paths tested? |
Revalidation triggers:
- new source system or product/channel。
- model, prompt, embedding, reranker or graph algorithm change。
- scenario threshold change。
- SAR QA defect spike。
- sanctions/fraud referral workflow change。
- material queue backlog or staffing model change。
- regulatory, policy or advisory update。
- incident, privacy issue, prompt injection or evidence leakage。
12. Audit Trail and Segregation of Duties
12.1 Required Events
| Event | Minimum fields |
|---|---|
| alert_created | source, scenario/model version, trigger facts, timestamp |
| priority_assigned | priority model/rule version, drivers, route, SLA |
| entity_resolved | match method, confidence, source, user override |
| evidence_viewed | user/role, evidence id, access reason, timestamp |
| copilot_generated | model/prompt/RAG versions, evidence ids, output hash |
| disposition_selected | human actor, reason code, cited evidence, decision time |
| escalation_created | target queue, reason, approver, SLA |
| SAR_draft_created | draft version, evidence set, model version, human editor |
| QA_reviewed | reviewer, sample reason, defects, severity, remediation |
| tuning_feedback_submitted | feedback type, eligibility, owner, approval state |
| policy_or_threshold_changed | changer, approver, before/after, test evidence |
12.2 Incompatible Duties
| Incompatible combination | Control |
|---|---|
| Analyst creates AI-supported closure and approves own QA sample | Independent QA reviewer |
| Model owner changes queue ranking and certifies model effectiveness | Model risk / validation challenge |
| Scenario owner tunes threshold and closes coverage review alone | BSA/AML compliance approval plus regression evidence |
| Copilot drafts SAR packet and submits filing | Authorized human filing process outside copilot autonomy |
| System admin can edit evidence and audit log | Write-once log, dual control, privileged access monitoring |
| Vendor generates model output and validates its own production quality | Internal acceptance, independent sample and audit rights |
13. Metrics That Matter
| Metric family | Examples | Why it matters |
|---|---|---|
| Productivity | median investigation prep time, evidence assembly time, queue aging, analyst throughput | Measures whether workbench removes manual friction |
| Quality | QA defect rate, unsupported claim rate, citation accuracy, disposition consistency | Prevents speed from degrading investigations |
| Risk coverage | typology/scenario coverage, high-risk queue timeliness, repeat alert escalation | Prevents false-positive reduction from creating blind spots |
| Adoption | active analyst usage, accepted evidence cards, copilot edit distance, override reasons | Measures real workflow fit, not demo usage |
| Human oversight | recommendation acceptance by risk band, disagreement rate, escalation quality | Detects automation bias and low-value AI |
| Model health | drift, retrieval precision, entity false merge rate, eval pass rate | Manages AI system risk |
| Control health | audit event completeness, SoD violation rate, stale CDD rate, data quality exceptions | Makes examiner/audit replay possible |
Bad north star:
Reduce alerts by 70%.
Better north star:
Increase risk-adjusted investigation capacity while preserving evidence completeness,
timely escalation, SAR decision ownership and audit replay quality.
14. Anti-Patterns
| Anti-pattern | Why it fails | Better design |
|---|---|---|
| Chatbot over case management | No state, no evidence ledger, no approvals | Workbench with workflow and traceability |
| Score-only queue | Analysts cannot explain routing | Driver-based priority with cited evidence |
| Entity graph without confidence | False links contaminate investigations | Confidence-banded edges and source visibility |
| SAR writer first | Automates the most sensitive output before evidence controls | Evidence workspace and QA before narrative assist |
| Auto-close low-score alerts | Creates hidden false-negative risk | Human-owned closure, sampling and coverage review |
| Train on all analyst outcomes | Learns noise, staffing shortcuts and incentive bias | QA-reviewed feedback taxonomy |
| Model validation limited to AUC | Ignores workflow, retrieval, graph and human oversight | AI system validation |
| Productivity-only adoption | Encourages rubber-stamp behavior | Balanced productivity, quality, risk and control metrics |
| Audit log as afterthought | Cannot replay decisions under challenge | Event schema designed before launch |
15. PM / Architect Implications
15.1 PM Questions
| Question | Strong answer |
|---|---|
| What is the product outcome? | Risk-adjusted investigation capacity with evidence quality and human decision ownership |
| What is out of scope? | SAR filing decision, sanctions disposition, customer notification and law-enforcement disclosure |
| What does adoption mean? | Analysts use evidence cards, challenge AI, edit drafts, reduce search time and improve QA outcomes |
| How do we avoid automation bias? | Evidence-first UI, non-default recommendations, disagreement prompts, QA sampling and training |
| How do we prove value? | Time saved plus QA quality, timeliness, coverage and audit completeness |
15.2 Architect Questions
| Question | Strong answer |
|---|---|
| Where does truth live? | In source records and evidence ledger, not in LLM summaries |
| How is context assembled? | Entity-resolved graph, timeline, CDD profile and permission-filtered retrieval |
| How is SAR confidentiality protected? | Access classes, retrieval filters, event logs, need-to-know roles and controlled handoff |
| How are changes governed? | Versioned models/prompts/rules, release gates, regression eval and approval evidence |
| How can audit replay a case? | Reconstruct alert, evidence, model versions, copilot output, human actions and approvals |
16. Interview Expression
30 秒版本:
AML alert workbench 的核心不是让 AI 判断是否报 SAR, 而是把 alert queue、实体解析、交易图谱、CDD context、证据包、analyst copilot、处置建议、QA、调参反馈和审计轨迹做成一个 human-owned control system。AI 可以辅助排序、汇总、查缺口和起草, 但 SAR decision、filing、sanctions disposition 和客户动作必须保留在人类授权流程中。
2 分钟版本:
我会按 alert-to-evidence-to-case-to-disposition-to-feedback 设计。第一层是数据和 identity: 交易、CDD、EDD、case history、sanctions/fraud referral 进入带 lineage 和 access class 的 evidence ledger, entity resolution 输出带 confidence 的客户/账户/对手方图谱。第二层是 decision support: queue prioritization 不是单分数, 而是 risk band、SLA、route、top drivers、missing evidence。第三层是 analyst workspace: timeline、graph、evidence cards、copilot summary、gap checklist 和 disposition options, 每个事实都要引用证据。第四层是 controls: no auto-SAR, maker-checker, SAR-sensitive access, QA sampling, tuning change gate, model risk validation 和 audit replay。这样能同时提升产能、质量和监管可解释性, 不把 AI 变成隐藏的合规决策者。
可能追问:
| 追问 | 回答要点 |
|---|---|
| 如何降低误报? | 先分解 false-positive drivers, 用 CDD context、entity graph、scenario tuning 和 evidence completeness 改善精度; 不用简单 suppress alerts。 |
| 如何防止漏报? | 保留 typology/scenario coverage matrix、false-negative proxy、QA sample、repeat alert review 和 coverage regression。 |
| 如何处理 SAR draft? | AI 只生成有引用的 draft packet, 人类决定 filing; unsupported facts、criminal conclusion、SAR confidentiality 和 filing handoff 有硬护栏。 |
| 如何做模型验证? | 验证 full AI system: ranking、entity resolution、RAG、LLM、workflow、HITL、QA judge、monitoring 和 change management。 |
17. Related Repo Assets
| Asset | How to use |
|---|---|
docs/AI_FINANCIAL_CRIME_TYPOLOGY_SCENARIO_COVERAGE_PLAYBOOK.md | 本文只链接 typology coverage, 不重复类型学和 SAR narrative 设计。 |
docs/AML_COPILOT_PRD.md | 可作为 one-page product framing 和原型级 MVP 边界。 |
docs/AML_GOVERNANCE_MAP.md | 可作为当前 repo 中 AML copilot 控制映射的治理补充。 |
docs/AI_HUMAN_OVERSIGHT_HITL_PLAYBOOK.md | 用于深化 human-owned decision、override、escalation 和 stop path。 |
docs/AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md | 用于深化 AI system inventory、validation、monitoring 和 revalidation trigger。 |
docs/AI_SEGREGATION_OF_DUTIES_DUAL_CONTROL_PLAYBOOK.md | 用于深化 maker-checker、dual control 和 incompatible duty matrix。 |