Lee Ling Yuan李凌缘
MOVAFLOW →
Case File · Applied AI · Fintech项目档案 · 应用 AI · 金融科技

An AI that investigates fraud — and never invents a thing一个会做反欺诈调查、却从不编造的 AI

The design isn't the interesting part. The interesting part is what I noticed at each step that would have quietly broken it.架构不是有意思的地方。有意思的是——我在每一步都注意到了那个会悄悄搞垮它的坑。

Scope
Solution design · with AI eng team方案设计 · 配合 AI 工程团队
Domain领域
Bank & e-wallet fraud ops银行与电子钱包反欺诈
Year年份
2025

A bank's fraud team was drowning in alerts. They wanted an AI agent to help. The build was straightforward — the judgement calls were everything.一家银行的反欺诈团队被告警淹没了。他们想要一个 AI 智能体来帮忙。搭建本身不难——难的全在那些判断上。

Background背景

When I came in, the bank's fraud platform was already working fine — transactions streamed in, the engine scored them, rules fired, alerts became cases in a queue. The problem wasn't the tech. It was that cases arrived faster than analysts could work them. They wanted an AI agent built on top of the platform they already trusted — and my job was to design how it should work, without breaking a system they'd already proven.我接手的时候,这家银行的反欺诈平台本身运转正常——交易流进来、引擎打分、规则触发、告警变成队列里的案子。问题不在技术,而在于案子来的速度比分析师处理的速度快。他们想要一个建在自己已经信任的平台之上的 AI 智能体——我的活儿,是设计它该怎么运作,同时不搞坏一个他们已经验证过的系统

The pain I had to design around我必须绕着设计的那些痛

Three pressures were feeding each other. The alert volume was drowning the team. It was growing faster than they could hire — every new person fell further behind. And the cost of investigating each case kept climbing, with no ceiling in sight.三股压力在互相喂养。告警的数量快把团队淹没了。它的增长比招人还快——每多招一个人,都更落后一步。而每个案子的调查成本一直在涨,看不到头。

What I was actually aiming for我真正想达到的

Cut the time per case and lighten the load without adding people — while keeping the human firmly in charge. The AI recommends; the analyst decides. And the one line I wouldn't cross: every claim the AI makes has to trace back to a real record. In a bank, a confident lie is worse than no answer.在不加人的前提下缩短每案时间、减轻负担——同时让人始终牢牢掌握决定权。AI 给建议,分析师做决定。还有一条我不肯越的线:AI 说的每一句话,都必须能追溯回一条真实记录。在银行里,一个自信的谎言比没有答案更糟。

I mapped one case's journey — before and after我把一个案子的旅程画了下来——之前和之后

As-Is · by hand, todayAs-Is · 今天,手工
Alert lands告警落地
Pull context by hand手动拉上下文
Read & cross-reference阅读 & 交叉比对
Hours per case每案数小时
Write it up from scratch从零写结论
Analyst decides分析师决定
The middle three steps are where analysts' hours disappear.中间这三步,就是分析师的工时消失的地方。
To-Be · with the agentTo-Be · 有了智能体
Same queue, untouched同一队列,不动
Agent retrieves, in-scope智能体检索,在权限内
5-stage pipeline drafts五阶段流水线起草
~40k tokens · 3–4 min约 40k token · 3–4 分钟
Grounded summary, cited接地摘要,带引用
Analyst still decides分析师依然决定
Same start, same ending — I only changed the exhausting middle.起点一样,终点一样——我只改了中间那段最累的。
The real thing真实原稿

My original design canvas我的原始设计草稿

Not a diagram made for this page — the actual working canvas I designed this on. Tap to open, drag and zoom to explore.不是为这个页面画的示意图——是我当时真正在上面做设计的画布。点击打开,可拖拽、缩放查看。

TransactionStream DecisionEngine Alert Raised(Rule hit) Case Created(onlyconfigured rule) Case Queue(no AI runyet) Analyst open "AI ANALYSIS"token spents Review(human) ApplicationInteraction Token BudgetGate Quota NoticeWait Until nextreset time kafka Engine Facts(rules,score,Decision Result) Decision Result ES+HBASE(full trx data,alerts) MY SQL(Cases,Audit,system config) Hive(historical data,unstructure Existing platform storage design Existing Platform New modules- AI Analysis Working Memory(assembled per run) Redis/Apexdb(indicator,dfp) Episodic memory Semantic memory Procedural memory Client KB(disposition standards、internal typology notes、pastcase rationale) Client SOP, SKill.md Fine-tuned LLM — LoRA(Fixed five stagesno free-running loop) MCP tools AI Summaryreport 3-4min 3 options to setup:1. Pre-running on every alert gives instant results but burns tokens on cases nobodyopens — most alerts close by bulk action. 2. Running on click saves the cost but the analyst waits.3. Pre-running only for high-score alerts where the open rate is already high. Retry Once(then fail visibly) Case openanyway enoughtoken ? Schemachecks(Evidencesourcerequired) Yes Fail vendor domain knowledge bakedinto weights — 90k features,150k rules Data andknowledge LLM OPS (offline) Trace(one per case) Existing platform storage MySQL Hive (offline,Unstructured,90-180days) Was it kept?(Accept, Edit ,Reject) Diagnose(Retrieval/reasoning) Rule MiningAI Agent Generate andEvaluateCondidate Rule approval andcontrolled deployment(Human) Reduce Noise Model evaldisposition vs AIrecommendation Also worth watching · the AIrecommendation,influences the dispositionthat trains the rules retrieve data Later phase, ideal design only Send back to harness? Enhance theKnowledge Base? Who incharge enhance theknowledge base? Client or Vendor? 1. Analysis Component(Scope thecase,client SOP) 2. Indicatorcalculation(defined features,) 3. Risk Points(rules,models,client&vendor KB) 4. Risk Summary(Anomaly Evidence,Timeline) 5.Judgement(recommendedaction,resolution) Real-time Scoped lookup · Phase2 Scoped SQLretrieval Harness — . one analysis run · everything inside is ephemeral · 40k tokens, 3-4 min Bounded pipeline BackgroundThe bank's fraud team needed an AI agent module built on topof their existing platform to cut analyst workload. Pain points1. Analyst team overwhelmed by alert volume2. Volume growing faster than headcount3. Rising opex per case investigated Goals1. Cut time per case investigation2. Reduce workload without adding headcount3. Every AI claim cites a source record — unsupported statements are suppressed4. AI recommends, the analyst decides Problem — the client KB1. No existing knowledge base. Disposition standards live in analysts' heads.2. What exists is one spreadsheet of user stories — a starting point, not a KB.3. Case history is their most sensitive asset. Access is negotiated, not deployed. Solution — sequence it, don't wait for itPhase 1: ship on vendor KB + engine outputs.Useful, but weaker than the sandbox demo.Phase 2: build the client KB from realdispositions. Client owns it, we give the UI.Phase 3: case history, if trust allows.Set this expectation before signing, not after. Problem — procedural memory goes stale1. SOPs and skills are not stable. Typologies shift,thresholds get retuned, regulations change.2. If every update needs a vendor ticket, thesystem is out of date within a quarter.3. Version drift: which SOP was live when this casewas investigated? Solution — hand them the update path1. UI to author and edit SOP / skill files. Clientowns the content, we own the tooling.2. Version each change and pin it to the case,so an old case replays against its own SOP.3. Review gate before a change goes live — samepattern as rule adoption. Why a quota, not just monitoring1. Bounded stages = predictable spend. ~40k tokensper case, so cost per case is knowable before signing.2. A free-running loop could be 5 calls or 50. You'donly find out at month end.3. Lazy trigger: most alerts close by bulk action andnever spend a token. Access control Row-level scope · PIImasking on retrieved records· every read logged Without this, retrieval surfacescases the analyst has no rightto see — a data leak with afriendly interface. Data i can get from here : 1. Transaction data, 2. KYC 3. rule config 4. Decision Result 5. Historical transaction 6. Relationship Analysis (schema first mapping) Scoped load
↕ open · drag · zoom↕ 打开 · 拖拽 · 缩放
Six things I caught我抓到的六个坑

Each step hid a way to quietly break it每一步都藏着一个会悄悄搞垮它的坑

Wait —等等——
If we pre-run the AI on every alert, we're burning tokens on cases nobody will ever open.如果我们对每一个告警都预跑 AI,那就是在为永远没人会打开的案子烧 token。
So I designed →于是我设计了 →

Lazy trigger惰性触发

The AI stays asleep until an analyst actually opens a case. Most alerts close in bulk and never get opened — so we never pay for work nobody does.在分析师真正打开案子之前,AI 一直睡着。多数告警被批量关掉、从没被打开——所以我们从不为没人做的工作买单。

Wait —等等——
A free-running loop could make 5 calls or 50. We'd only find out at month end, when the bill lands.一个自由循环可能调 5 次,也可能 50 次。我们要到月底账单来了才知道。
So I designed →于是我设计了 →

A token budget gate — a quota, not just monitoringToken 预算闸门——是配额,不只是监控

Bounded stages mean predictable spend: ~40k tokens per case, knowable before the contract is even signed. Not discovered afterward.有边界的阶段意味着可预测的开销:每案约 40k token,签合同之前就能算清。而不是事后才发现。

Wait —等等——
If retrieval ignores permissions, the AI will surface cases the analyst has no right to see.如果检索不管权限,AI 就会翻出分析师无权看到的案子。
So I designed →于是我设计了 →

Access control as a first-class requirement把访问控制当成头等需求

Row-level scope, PII masking, every read logged. Without it, this is just a data leak with a friendly interface.行级权限、PII 脱敏、每次读取留日志。没有它,这就只是一个带友好界面的数据泄露。

Wait —等等——
There is no knowledge base. The disposition standards live in analysts' heads — all that exists on paper is one spreadsheet.这里根本没有知识库。处置标准都在分析师脑子里——纸面上只有一张电子表格。
So I designed →于是我设计了 →

Sequence it — don't wait for it分期上线——别等它齐了

Phase 1 ships on vendor knowledge. Phase 2 builds the client KB from real dispositions. Phase 3 adds case history, if trust allows. Set that expectation before signing, not after.第一期用厂商知识先上。第二期用真实处置构建客户知识库。第三期加案件历史,如果信任允许。这个预期要在签约前设定,而不是之后。

Wait —等等——
Rules and SOPs keep changing. If every update needs a vendor ticket, the system is stale within a quarter.规则和 SOP 一直在变。如果每次更新都要开厂商工单,系统一个季度内就过时了
So I designed →于是我设计了 →

Hand them the update path把更新的路交到他们手里

The client edits their own SOP and skill files through a UI. Each change is versioned and pinned to the case — so an old case replays against its own SOP — and passes a review gate before going live.客户通过 UI 自己编辑 SOP 和技能文件。每次改动有版本、绑定到案子——所以旧案子能对着它当时的 SOP 重放——上线前过一道审核闸门。

And the subtle one —还有个微妙的——
The AI's recommendation influences the analyst's disposition — and those dispositions train the next rules. A confident hallucination could poison the loop.AI 的建议会影响分析师的处置——而这些处置会训练下一批规则。一次自信的幻觉,可能污染整个闭环。
So the whole thing bends around →于是整个设计都围着 →

Grounding — every fact cites a source, or it's suppressed接地——每条事实都引用来源,否则被抑制

In a bank, a confident lie is worse than no answer. Grounding isn't just ethics here — it's what keeps the training loop honest. AI recommends; the human decides.在银行里,一个自信的谎言比没有答案更糟。接地在这里不只是伦理——它是让训练闭环保持诚实的东西。AI 建议,人来决定。

Now the whole thing, in one run现在,一次运行里的全貌
↓ tap any block — watch the data flow↓ 点任意模块 — 看数据流动
Case opened trigger Budget Gate quota, not monitor 5-stage pipeline LoRA · fixed Analyst decides Working Memory ephemeral / run Access Control row-level · PII Grounding · schema checks no source → suppressed
Tap a block ↑点一个模块 ↑
Each was one of the calls above — here's the short version.每一个都是上面那些判断之一——这里是简版。

The pattern规律

None of these were prompt-engineering problems. Each was something I noticed by sitting with how the fraud team actually worked, and asking what would break once it was real. That's the job — catching the quiet failures before they ship. A good AI system in a regulated setting is mostly a set of constraints, held carefully.这些都不是提示词工程的问题。每一个,都是我通过观察反欺诈团队真实怎么干活、然后追问"这东西一旦上真的会在哪崩"发现的。这就是这份工作——在那些悄无声息的故障上线之前把它们抓住。在受监管的场景里,一个好的 AI 系统,大部分是一组被小心守住的约束。

All projects所有项目 Talk to me about this →找我聊聊这个 →
Original design canvas · drag to pan · +/− to zoom原始设计画布 · 拖拽平移 · +/− 缩放
×
TransactionStream DecisionEngine Alert Raised(Rule hit) Case Created(onlyconfigured rule) Case Queue(no AI runyet) Analyst open "AI ANALYSIS"token spents Review(human) ApplicationInteraction Token BudgetGate Quota NoticeWait Until nextreset time kafka Engine Facts(rules,score,Decision Result) Decision Result ES+HBASE(full trx data,alerts) MY SQL(Cases,Audit,system config) Hive(historical data,unstructure Existing platform storage design Existing Platform New modules- AI Analysis Working Memory(assembled per run) Redis/Apexdb(indicator,dfp) Episodic memory Semantic memory Procedural memory Client KB(disposition standards、internal typology notes、pastcase rationale) Client SOP, SKill.md Fine-tuned LLM — LoRA(Fixed five stagesno free-running loop) MCP tools AI Summaryreport 3-4min 3 options to setup:1. Pre-running on every alert gives instant results but burns tokens on cases nobodyopens — most alerts close by bulk action. 2. Running on click saves the cost but the analyst waits.3. Pre-running only for high-score alerts where the open rate is already high. Retry Once(then fail visibly) Case openanyway enoughtoken ? Schemachecks(Evidencesourcerequired) Yes Fail vendor domain knowledge bakedinto weights — 90k features,150k rules Data andknowledge LLM OPS (offline) Trace(one per case) Existing platform storage MySQL Hive (offline,Unstructured,90-180days) Was it kept?(Accept, Edit ,Reject) Diagnose(Retrieval/reasoning) Rule MiningAI Agent Generate andEvaluateCondidate Rule approval andcontrolled deployment(Human) Reduce Noise Model evaldisposition vs AIrecommendation Also worth watching · the AIrecommendation,influences the dispositionthat trains the rules retrieve data Later phase, ideal design only Send back to harness? Enhance theKnowledge Base? Who incharge enhance theknowledge base? Client or Vendor? 1. Analysis Component(Scope thecase,client SOP) 2. Indicatorcalculation(defined features,) 3. Risk Points(rules,models,client&vendor KB) 4. Risk Summary(Anomaly Evidence,Timeline) 5.Judgement(recommendedaction,resolution) Real-time Scoped lookup · Phase2 Scoped SQLretrieval Harness — . one analysis run · everything inside is ephemeral · 40k tokens, 3-4 min Bounded pipeline BackgroundThe bank's fraud team needed an AI agent module built on topof their existing platform to cut analyst workload. Pain points1. Analyst team overwhelmed by alert volume2. Volume growing faster than headcount3. Rising opex per case investigated Goals1. Cut time per case investigation2. Reduce workload without adding headcount3. Every AI claim cites a source record — unsupported statements are suppressed4. AI recommends, the analyst decides Problem — the client KB1. No existing knowledge base. Disposition standards live in analysts' heads.2. What exists is one spreadsheet of user stories — a starting point, not a KB.3. Case history is their most sensitive asset. Access is negotiated, not deployed. Solution — sequence it, don't wait for itPhase 1: ship on vendor KB + engine outputs.Useful, but weaker than the sandbox demo.Phase 2: build the client KB from realdispositions. Client owns it, we give the UI.Phase 3: case history, if trust allows.Set this expectation before signing, not after. Problem — procedural memory goes stale1. SOPs and skills are not stable. Typologies shift,thresholds get retuned, regulations change.2. If every update needs a vendor ticket, thesystem is out of date within a quarter.3. Version drift: which SOP was live when this casewas investigated? Solution — hand them the update path1. UI to author and edit SOP / skill files. Clientowns the content, we own the tooling.2. Version each change and pin it to the case,so an old case replays against its own SOP.3. Review gate before a change goes live — samepattern as rule adoption. Why a quota, not just monitoring1. Bounded stages = predictable spend. ~40k tokensper case, so cost per case is knowable before signing.2. A free-running loop could be 5 calls or 50. You'donly find out at month end.3. Lazy trigger: most alerts close by bulk action andnever spend a token. Access control Row-level scope · PIImasking on retrieved records· every read logged Without this, retrieval surfacescases the analyst has no rightto see — a data leak with afriendly interface. Data i can get from here : 1. Transaction data, 2. KYC 3. rule config 4. Decision Result 5. Historical transaction 6. Relationship Analysis (schema first mapping) Scoped load