第1645篇：金融风控AI实践——大模型在反欺诈检测中的应用与合规考量
2026/4/30大约 10 分钟
第1645篇：金融风控AI实践——大模型在反欺诈检测中的应用与合规考量
金融风控这个领域，我接触了大概三年。最近一年跟着一个中型消费金融公司做大模型接入，说实话，这个场景的挑战跟其他行业完全不是一个级别。
为什么？因为金融风控有个独特属性：错一次代价极高。漏掉一个欺诈案件，损失可能是几十万；误判一个好客户，不只是损失这一单，还可能造成客诉和舆情。而且在金融领域，你的每一个决策都要留痕，要能向监管解释。这些约束让大模型的落地比想象中难得多。
金融风控的现有体系
在聊大模型之前，先说说金融风控现有体系长啥样，不然不好理解大模型插在哪个位置。
这是一套经过多年打磨的体系，核心是规则引擎（经验规则，比如"命中黑名单直接拒绝"）+ 评分卡（逻辑回归或梯度提升树）。
这套体系的优点是可解释、可审计、低延迟。缺点是：
- 规则是手工的，维护成本高，对新型欺诈手法反应慢
- 评分模型学的是历史模式，对没见过的欺诈手法无效
- 人工审核靠经验，难以标准化，效率低
大模型能做什么？不是替换这套体系，而是在特定环节增强它。
大模型适合介入的三个场景
在金融风控里，我们尝试了三个大模型落地场景，效果差异很大。
场景一：欺诈行为模式的文本分析
金融欺诈有大量文本信号，比如：
- 申请人的工作单位描述和联系电话不匹配
- 紧急联系人信息高度相似（团伙欺诈的特征）
- 申请人提供的收入证明文本有异常（可能是伪造的）
传统的方式是做特征工程，抽字段做规则。但欺诈团伙会不断更新话术，规则总是落后于欺诈手法。
大模型可以做文本层面的语义异常检测：
@Service
public class TextAnomalyDetectionService {
@Autowired
private ChatClient chatClient;
/**
* 检测申请材料中的文本异常
* 注意：此方法只做"异常提示"，不做最终决策
*/
public TextAnomalyResult detectAnomalies(LoanApplication application) {
String prompt = """
你是一位资深信贷风险分析师，请分析以下贷款申请材料中的文本异常。
【申请人信息】
工作单位：%s
职位：%s
月收入（自述）：%s元
工作年限：%s年
工作地址：%s
【联系信息】
手机：%s（尾号）
紧急联系人1：%s，关系：%s
紧急联系人2：%s，关系：%s
【银行流水摘要】
%s
请从以下维度检测异常：
1. 收入与职位/工作年限的匹配性
2. 工作信息的内在一致性
3. 联系人信息的合理性
4. 银行流水与自述收入的匹配性
5. 是否有明显的信息矛盾或异常
返回JSON格式：
{
"anomalyScore": 0-100（越高越异常）,
"anomalyItems": [{"dimension": "维度", "finding": "发现", "riskLevel": "HIGH/MEDIUM/LOW"}],
"summary": "整体分析摘要（50字以内）",
"requiresManualReview": true/false
}
重要：只分析可见信息，不要推断申请人的主观意图，不要给出"欺诈"这样的定性判断。
""".formatted(
application.getEmployerName(),
application.getPosition(),
application.getSelfReportedIncome(),
application.getWorkingYears(),
application.getWorkAddress(),
maskPhone(application.getPhone()),
application.getEmergencyContact1Name(), application.getEmergencyContact1Relation(),
application.getEmergencyContact2Name(), application.getEmergencyContact2Relation(),
buildBankStatementSummary(application.getBankStatements())
);
String response = chatClient.prompt()
.user(prompt)
.call()
.content();
return parseAnomalyResult(response);
}
}这里我特意加了一句"不要推断主观意图，不要给出欺诈定性判断"。这是合规要求：AI系统不能对申请人给出定性评价，否则一旦引发纠纷，这个定性会成为很麻烦的法律问题。
场景二：团伙关联分析
金融欺诈很多是团伙作案，单看一个申请人是好客户，但如果能发现他和已知欺诈人员有关联，风险就完全不一样了。
传统的做法是做图分析，但要把图分析的结果转化成审核员能理解的"说明"很难。大模型在这里的作用是将图分析结果转化为可读的风险描述：
@Service
public class GroupFraudAnalysisService {
@Autowired
private GraphAnalysisEngine graphEngine;
@Autowired
private ChatClient chatClient;
public GroupFraudReport analyze(String applicantId) {
// 先用图分析引擎做关联分析
GraphAnalysisResult graphResult = graphEngine.analyzeConnections(
applicantId, 3 // 3度关联
);
if (graphResult.getHighRiskConnections().isEmpty()) {
return GroupFraudReport.clean(applicantId);
}
// 将图分析结果转化为可读报告
String prompt = """
请根据以下关联分析数据，生成一份清晰的风险关联报告：
【申请人】%s
【关联分析结果】
直接关联人（1度）：%s
间接关联人（2度）：%s
高风险关联：%s
【关联类型说明】
- 共同设备：使用过同一手机或电脑
- 地址重叠：住址/工作地址相似
- 联系人交叉：互为紧急联系人
- 同IP申请：来自相同IP地址
请生成：
1. 关联风险摘要（80字以内，描述关联情况）
2. 最值得关注的关联点（Top3）
3. 关联风险等级：高/中/低
注意：只描述客观关联事实，不要推断是否存在主观勾连。
""".formatted(
applicantId,
formatConnections(graphResult.getFirstDegreeConnections()),
formatConnections(graphResult.getSecondDegreeConnections()),
formatHighRiskConnections(graphResult.getHighRiskConnections())
);
String response = chatClient.prompt()
.user(prompt)
.call()
.content();
return parseGroupFraudReport(response, graphResult);
}
}场景三：人工审核辅助
这是投入产出比最高的场景。人工审核员每天要处理大量案件，靠记忆和经验。大模型可以帮他们做"案件摘要"和"历史相似案件参考"：
@Service
public class AuditAssistantService {
@Autowired
private ChatClient chatClient;
@Autowired
private SimilarCaseSearchService similarCaseService;
/**
* 生成审核辅助报告
* 在审核员打开案件时实时生成
*/
public AuditAssistReport generateAuditReport(
LoanApplication application,
RiskScores scores) {
// 搜索历史相似案件
List<HistoricalCase> similarCases = similarCaseService.findSimilar(
application, 5
);
String similarCasesStr = similarCases.stream()
.map(c -> String.format(
"案件%s：%s，结果：%s，关键特征：%s",
c.getCaseId(), c.getApplicantProfile(),
c.getDecision(), c.getKeyFeatures()
))
.collect(Collectors.joining("\n"));
String prompt = """
请为以下贷款申请案件生成审核辅助报告，帮助审核员快速了解关键信息。
【申请基本信息】
申请金额：%s元，申请期限：%s个月
申请人年龄：%s，职业：%s
申请渠道：%s
【风险评分】
综合风险分：%s（满分1000，越高越好）
信用分：%s
欺诈风险分：%s（越低越好）
【异常点汇总】
%s
【历史相似案件】
%s
请生成：
1. 案件风险摘要（100字以内，说清楚这个案件的核心风险点）
2. 需要重点核查的问题（3-5个具体问题，给审核员查）
3. 参考历史案件的启示
4. 审核建议：通过/拒绝/补充材料后再审
注意：建议只是参考，最终决策权在审核员。建议要有充分理由，不要模糊说"需综合考量"。
""".formatted(
application.getLoanAmount(),
application.getLoanTerm(),
application.getAge(),
application.getOccupation(),
application.getApplyChannel(),
scores.getComprehensiveScore(),
scores.getCreditScore(),
scores.getFraudScore(),
summarizeAnomalies(scores.getAnomalyItems()),
similarCasesStr
);
String response = chatClient.prompt()
.user(prompt)
.call()
.content();
return parseAuditReport(response);
}
}这个功能上线后，审核员平均处理时间从12分钟降到了8分钟，但更重要的是：审核质量提升了。以前漏看历史关联案件是常有的事，现在AI帮着找出来，审核员的决策有了更好的参考。
合规性是最大的工程约束
在金融行业做AI，监管合规不是"以后再说"的问题，是从第一天就要考虑的设计约束。
1. 可解释性要求
监管要求金融机构对信贷决策能够向申请人解释。大模型的决策过程本身不可解释，所以大模型的输出只能作为辅助参考，最终决策必须来自可解释的规则或传统模型。
我们的做法：建立"决策溯源"机制，每个决策都记录了它依据的规则、评分和人工审核记录，大模型的分析结果只作为"参考依据"显示，不作为"决策依据"。
@Entity
public class DecisionRecord {
private Long applicationId;
private DecisionResult result; // 最终决策
private String decisionBasis; // 决策依据（规则/模型/人工）
// 可解释的规则命中记录
private List<String> triggeredRules;
// 评分模型的特征贡献
private Map<String, Double> featureContributions;
// 人工审核记录
private String auditorId;
private String auditorNote;
// AI辅助分析（仅作参考，不作为法律决策依据）
@Column(name = "ai_analysis_reference")
private String aiAnalysisReference; // 明确标注"参考"
private Instant decidedAt;
private String decidedBy;
}2. 数据脱敏
传递给大模型的数据，必须做脱敏处理。身份证号、银行卡号、手机号等敏感信息不能以明文传给外部API。
@Component
public class FinancialDataMasker {
public LoanApplication mask(LoanApplication application) {
LoanApplication masked = application.copy();
masked.setIdCardNo(maskIdCard(application.getIdCardNo()));
masked.setPhone(maskPhone(application.getPhone()));
masked.setBankCardNo(maskBankCard(application.getBankCardNo()));
masked.setEmployerPhone(maskPhone(application.getEmployerPhone()));
// 银行流水只传摘要，不传明细
masked.setBankStatements(summarizeBankStatements(
application.getBankStatements()
));
return masked;
}
private String maskIdCard(String idCard) {
if (idCard == null || idCard.length() < 10) return "***";
return idCard.substring(0, 4) + "**********" + idCard.substring(14);
}
private String summarizeBankStatements(List<BankStatement> statements) {
// 只传：月均收入、月均支出、大额异常交易数量、工资性收入比例
// 不传：具体每笔交易
double avgIncome = statements.stream()
.mapToDouble(BankStatement::getMonthlyIncome)
.average().orElse(0);
// ... 其他统计
return String.format(
"月均收入%.0f元，月均支出%.0f元，大额异常交易%d笔",
avgIncome, avgExpense, largeAnomalyCount
);
}
}3. 模型使用记录和审计
每次大模型调用都要记录：输入（脱敏后）、输出、调用时间、用途。这个审计日志要保存至少5年（根据监管要求）。
@Aspect
@Component
public class AiCallAuditAspect {
@Autowired
private AiCallAuditRepository auditRepo;
@Around("@annotation(AiAudit)")
public Object auditAiCall(ProceedingJoinPoint pjp) throws Throwable {
String callId = UUID.randomUUID().toString();
Instant startTime = Instant.now();
AiCallAuditRecord record = AiCallAuditRecord.builder()
.callId(callId)
.methodName(pjp.getSignature().getName())
.callerUserId(SecurityContextHolder.getContext()
.getAuthentication().getName())
.startTime(startTime)
.build();
try {
Object result = pjp.proceed();
record.setStatus("SUCCESS");
record.setResponseSummary(truncateSummary(result.toString()));
return result;
} catch (Exception e) {
record.setStatus("ERROR");
record.setErrorMessage(e.getMessage());
throw e;
} finally {
record.setEndTime(Instant.now());
record.setDurationMs(
Duration.between(startTime, record.getEndTime()).toMillis()
);
auditRepo.save(record);
}
}
}4. 反歧视检查
这是很多团队忽视的点。如果大模型训练数据有偏差，可能对某些群体产生系统性歧视（比如对特定地区或年龄段的申请人更容易给出负面评价）。
我们做了一个定期的公平性检验：对不同群体（按年龄、地区等人口学特征分组）的AI评分分布做统计，如果某个群体的评分显著低于整体，就要人工审查这批案件，排查是否有系统性偏差。
性能与成本控制
金融风控对延迟要求很高。在线风控必须在500ms内完成。大模型调用通常需要1-3秒，完全不能放在实时风控链路里。
我们的方案：
- 实时链路（<500ms）：纯规则 + 传统评分模型，不调用大模型
- 准实时辅助（30秒内）：大模型文本分析、关联分析，结果推送给审核员
- 离线增强（天级）：用大模型丰富用户画像、生成规则优化建议
成本方面，对于审核辅助场景，每个案件调用一次大模型，按当前API定价，平均每个案件成本约0.05元。对于消费金融，这个成本完全可以接受（坏账损失的千分之一都不到）。
实际落地效果
上线6个月的数据：
- 欺诈案件发现率提升14%（主要来自文本异常检测和关联分析）
- 审核员满意度从6.2/10提升到8.1/10（审核辅助报告帮助很大）
- 漏审率（本应标记却被漏过的风险点）下降28%
- 误判率基本持平（大模型没有引入新的误判）
这几个数字放在金融风控行业，是相当不错的改进。但更重要的是：这套方案通过了内部合规审查，这在金融行业才是真正的门槛。