Prakhar-Gupta76/FraudFlex

# FraudFlux **实时支付风险智能平台** ## 关于本项目 FraudFlux 是一个实时支付欺诈检测系统，旨在在做出支付决策之前评估 每一笔模拟交易。它结合了 可配置的欺诈规则和基于机器学习的异常检测，以 生成风险评分、风险类别、建议操作以及人类可读的 说明。 该项目展示了银行和支付应用程序如何在交易流速度下检测 可疑行为，同时减少对 合法客户不必要的拦截。 FraudFlux 是一个教育和作品集项目。它的第一个版本仅处理 模拟交易，不得将其视为生产级银行或 支付安全系统。 ## 项目目标 FraudFlux 旨在： - 模拟正常和欺诈性支付交易的连续流。 - 使用客户、设备、位置、商户、金额、 身份验证和交易频率信号评估交易。 - 将确定性的欺诈规则与异常检测模型相结合。 - 为每笔交易分配从 `0` 到 `100` 的风险评分。 - 将交易归类为低风险、中风险或高风险。 - 建议批准、要求额外验证或临时冻结。 - 解释促成可疑决策的信号。 - 为分析师提供一个监控和审查警报的 dashboard。 - 衡量检测质量、误报情况、吞吐量和评分延迟。 ## 首个 MVP 范围 首个 MVP 将包含： - 一个模拟交易流生成器。 - 一个用于交易事件的 Kafka broker。 - 一个 Python 欺诈评分 worker。 - 一个可配置的规则引擎。 - 一个机器学习异常检测器。 - 一个风险评分 API。 - 用于存储交易、警报和分析师决策的 PostgreSQL。 - 一个用于实时监控和警报调查的 Web dashboard。 Apache Flink、Feast、Redis 和高级基础设施监控计划 作为后续升级，在首个工作版本中不作要求。 ## 使用的交易信息 每笔模拟交易可能包括： - 交易 ID 和时间戳 - 客户和账户 ID - 金额和货币 - 商户和商户类别 - 支付渠道 - 设备 ID 和设备信任状态 - IP 地址和大概位置 - 身份验证结果 - 最近的失败尝试 - 最近的交易频率 - 客户的正常消费范围 - 客户的已知设备和常用位置 敏感或受保护的个人特征不得用于判定 风险。 ## 风险评分方法 FraudFlux 根据两个组成部分计算最终得分： ``` Final Risk Score = Rules Score + ML Anomaly Contribution ``` - 规则引擎最多可贡献 `70` 分。 - 异常模型最多可贡献 `30` 分。 - 最终得分上限为 `100`。 - 仅计算同一规则组中权重最高的规则。例如， 一笔金额不能同时受到 `3x` 和 `5x` 金额的处罚。 这些是初始的 MVP 设置。之后必须使用评估 结果以及漏报欺诈与误报之间的业务成本对其进行校准。 ## 初始欺诈规则 ### 金额规则 将交易金额与客户的正常消费 行为进行比较。 | 条件 | 得分 | | --- | ---: | | 金额至少是客户正常金额的 3 倍 | +10 | | 金额至少是客户正常金额的 5 倍 | +20 | | 金额至少是客户正常金额的 10 倍 | +30 | 仅应用满足条件的最高金额规则。 ### 交易频率规则 | 条件 | 得分 | | --- | ---: | | 2 分钟内发生 3 到 5 笔交易 | +10 | | 2 分钟内发生超过 5 笔交易 | +20 | | 在多个商户处重复进行小额支付 | +15 | 仅应用满足条件的最高一般频率规则。当 交易模式符合时，也可能适用单独的 测卡规则。 ### 设备规则 | 条件 | 得分 | | --- | ---: | | 交易使用新设备 | +15 | | 设备被多个不相关的客户账户共享 | +20 | | 设备已存在于内部拒绝列表中 | +40 | 仅应用满足条件的最高设备规则。 ### 位置规则 | 条件 | 得分 | | --- | ---: | | 交易发起于客户通常所在的区域之外 | +10 | | 交易发起于异常的国家/地区 | +15 | | 检测到与前一笔交易之间存在不可能的旅行 | +30 | 不可能的旅行是指两次相距甚远的交易之间的时间 太短，无法进行现实的物理旅行。仅应用满足条件的最高位置规则。 ### 身份验证规则 | 条件 | 得分 | | --- | ---: | | 3 次或更多最近的身份验证失败尝试 | +10 | | 5 次或更多失败尝试后紧接着支付成功 | +20 | | 已知身份验证或设备凭据已泄露 | +40 | 仅应用满足条件的最高身份验证规则。 ### 商户和行为规则 | 条件 | 得分 | | --- | ---: | | 商户类别对客户来说不常见 | +10 | | 对客户而言，支付发生在异常时段 | +5 | | 休眠账户突然进行高额支付 | +15 | | 商户近期的欺诈或争议率异常 | +15 | 当这些规则代表不同的信号时，可以将其结合使用。 ## ML 异常贡献 异常检测器评估完整交易是否偏离了 客户的正常行为。它可能会考虑： - 偏离客户平均水平的金额。 - 最近时间窗口内的交易数量。 - 与常用位置的距离。 - 距离上一笔交易的时间。 - 设备是否为新设备。 - 商户类别的罕见程度。 - 一天中时段的偏差。 - 最近的身份验证失败情况。 模型输出被标准化为介于 `0` 和 `30` 之间的贡献分。 异常得分不能证明存在欺诈；它是与 规则一起使用的辅助证据。 ## 风险类别和决策 | 最终得分 | 风险类别 | 建议的 MVP 决策 | | ---: | --- | --- | | 0-39 | 低 | 批准 | | 40-69 | 中 | 要求额外验证 | | 70-100 | 高 | 临时冻结并创建分析师警报 | 高风险类别不代表对欺诈的最终法律判定。 在 MVP 中，“冻结”和“拦截”仅为模拟状态。 ## 决策覆盖 某些高置信度信号可能会覆盖常规阈值： - 处于已确认拒绝列表中的设备或凭据会产生高风险警报。 - 已确认遭到泄露的账户会产生高风险警报。 - 缺失或无效的核心交易数据将阻止自动批准， 并将交易发送以供审查。 - 服务或模型故障不得悄无声息地将交易归类为安全； 它会产生明确的系统审查状态。 覆盖操作必须记录在说明和审计历史中。 ## 可解释的警报 每个中风险或高风险结果都应包含： - 最终风险评分和风险类别。 - 建议的决策。 - 触发的规则。 - 每条规则贡献的分数。 - ML 异常贡献。 - 重要的行为偏差。 - 模型和规则集版本。 - 交易处理时间。 示例： ``` Risk score: 82/100 Category: High Recommended action: Hold for review Reasons: - New device: +15 - Amount is 6.4 times the customer's normal amount: +20 - Impossible travel detected: +30 - ML anomaly contribution: +17 ``` ## 分析师审查 分析师可以将警报标记为： - 确认的欺诈 - 合法交易 - 需要进一步调查 分析师的标签、备注、身份和审查时间应作为 审计记录予以保留。分析师反馈稍后可能会成为带标签的训练数据，但 在重新训练模型之前必须对其进行验证。 ## 评估规则 项目不得仅将准确率作为成功的唯一指标，因为欺诈 交易非常罕见。MVP 应报告： - Precision - Recall - F1 score - Precision-recall AUC - False-positive rate - 检测到的欺诈金额 - 被错误冻结的合法金额 - 每秒处理的交易数 - 中位数和 p95 评分延迟 使用合成数据产生的结果必须清晰地标记为模拟 结果，且不得作为现实世界的银行业务性能呈现。 ## 项目原则 - 每一项风险决策都必须是可解释且可审计的。 - 规则和阈值必须是可配置和带有版本的。 - 同一事件不得创建重复的支付决策。 - 事件时间戳必须与处理时间戳区分开来。 - 缺失的数据和系统故障必须是可见的，不能被悄无声息地忽略。 - 不得将敏感数据写入普通的应用程序日志中。 - 受保护的个人属性绝不能用作欺诈信号。 - 分析师反馈未经验证不得用于训练。 - 必须长期监控模型性能和误报情况。 - 对于模棱两可和高影响的决策，仍可进行人工审查。 ## 免责声明 FraudFlux 旨在用于学习、演示和系统设计实践。 未经专业的安全审查、法律审查、 适当的数据治理、广泛验证和监管合规，其模拟的决策不得用于批准、拒绝或拦截真实的 金融交易。

标签：Apex, Kafka, SonarQube插件, 实时计算, 机器学习, 欺诈检测, 测试用例, 逆向工具, 金融科技, 风险控制