<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>保险 on 极限科技 | INFINI Labs</title><link>https://infinilabs.cn/tags/%E4%BF%9D%E9%99%A9/</link><description>Recent content in 保险 on 极限科技 | INFINI Labs</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Wed, 15 Apr 2026 22:30:00 +0800</lastBuildDate><atom:link href="https://infinilabs.cn/tags/%E4%BF%9D%E9%99%A9/index.xml" rel="self" type="application/rss+xml"/><item><title>银行和保险风控，怎样把规则真正跑进实时链路</title><link>https://infinilabs.cn/blog/2026/easysearch-rules-engine-banking-insurance-risk-control/</link><pubDate>Wed, 15 Apr 2026 22:30:00 +0800</pubDate><guid>https://infinilabs.cn/blog/2026/easysearch-rules-engine-banking-insurance-risk-control/</guid><description>在金融行业做风控，规则往往是最不缺的东西。多年的业务经验、合规要求和风险事件，早已沉淀出一套套判断逻辑。银行和保险团队真正缺的，是一套能让这些规则在实时链路里稳定运行的机制。
大额转账应该秒级拦截，结果还在等离线任务；改密后立即转账、暴力破解登录、同事故多人理赔，本来应该第一时间打标，结果要跨好几个系统补逻辑；规则改得频繁，但每次调整都得改代码、重新发版、重新联调，最后大家都不敢轻易动。
很多高价值风险本身并不复杂，判断逻辑用规则就能清楚表达：单笔大额转账、24 小时频繁小额分拆、1 小时内地理位置异常交易、30 分钟密码连续错误、30 天内多头借贷、投保后 90 天内理赔、同一事故 3 个以上关联理赔人。这些规则的要求不在于复杂，在于实时、稳定、可改、可解释。
我们整理了一套银行和保险风控样例，在 Easysearch 2.1.2 测试环境里走通了完整链路，记录下来，供参考。
先看结论 # 规则数：24 覆盖场景：银行交易、反洗钱、账户安全、信贷、保险理赔 规则编译耗时：415ms 单规则样本验证：24 / 24 命中 混合业务流样本：8 条，命中 6 条，未命中 2 条（正常事件） 写入后会直接输出结构化风险字段，包括是否命中、命中规则 ID 列表、命中条数和最高风险等级，下游系统可以直接用这些字段做决策，不需要再自己解析。
规则数量 24 编译耗时 415ms 混合样本命中 6 / 8 规则引擎在链路里承担什么 # 这套方案把整条链路分成三层：上游特征系统负责计算窗口聚合、账户画像、名单命中和关系特征；Easysearch 规则引擎负责实时命中和结构化输出；下游处置系统负责拦截、二次验证、人工复核和告警推送。
规则引擎不负责自己做历史聚合。类似 acct_txn_cnt_24h（24 小时内交易笔数）、loan_apply_org_cnt_30d（30 天内申请机构数）、txn_geo_distance_km_1h（1 小时内地理距离）这些字段，都由上游流式计算或特征服务预先算好，再作为扁平字段写进当前事件文档。规则引擎要做的，是把&amp;quot;当前事件 + 已计算特征&amp;quot;快速转成风险结果。
这个分工明确之后，规则本身的维护和规则引擎的边界就都清楚了。
把这套实时风控链路拆开看，核心就是五步：事件接入、特征补齐、规则编译、在线匹配、结果输出与处置。下面这张图把银行和保险场景里这条链路的分工关系完整串起来了。
规则覆盖的五类场景 # 场景 示例规则 银行交易 大额转账、深夜大额转账、新账户大额流出 反洗钱 小额分拆、资金归集后转出、休眠账户激活 账户安全 暴力破解、撞库、改密后立即转账 信贷风控 多头借贷、还款日前余额骤降、收入还款压力过高 保险理赔 投保后短期出险、频繁小额理赔、同事故多人理赔 规则文件的一部分如下：</description></item></channel></rss>