劳动仲裁记录这几年在招聘和业务风控里的分量越来越重。以前背调主要看学历、工作经历、是否有犯罪记录但实践下来会发现劳动仲裁信息往往是判断候选人职业稳定性、企业用工合规风险的重要信号。一个人跟老东家频繁打仲裁背后可能是公司管理问题也可能是个人职业倾向问题一家供应商、合作伙伴频繁出现在仲裁裁决里则直接影响合作信用评估。所以我一直想做一套系统把劳动仲裁信息的查询自动化并嵌入到已有的风控流程里。最近终于把“天远劳动仲裁信息查询API”完整对接进PHP项目跑通了智能背调与风控预警的完整链路这里把整个实战过程整理出来包括接口对接、代码实现、规则引擎设计以及一路踩过的坑希望能给正在做类似系统的开发者一些参考。1. 需求拆解与整体架构设计1.1 劳动仲裁查询在背调与风控中的真实价值先说个实际场景。某公司在招聘财务总监岗位时候选人的简历非常漂亮知名企业背景、多年管理经验。背景调查阶段常规项都通过了但当我接入劳动仲裁查询后发现这位候选人在过去五年内与两家前雇主发生过三次劳动仲裁记录其中两次为用人单位胜诉、一次调解结案。继续深挖后发现候选人在前公司涉嫌侵占公司财产这才在背调报告里亮起了红灯。这个案例说明劳动仲裁记录不是简单判断“对错”的标签而是一个风险信号需要结合行业、岗位、频次来综合判断。从企业风控角度看劳动仲裁信息对两类对象特别重要招聘候选人结合仲裁记录中的角色申请人/被申请人、案由追索劳动报酬、经济补偿、确认劳动关系等、处理结果裁决支持/驳回/调解判断候选人的维权倾向、职业稳定性、诚信风险合作企业/供应商如果一家合作企业的劳动仲裁案件长期高发、败诉率高说明其用工合规性存在问题可能面临行政处罚、诉讼连带甚至资金链风险直接影响合作决策。天远劳动仲裁信息查询API提供了按姓名身份证号或企业统一社会信用代码精确查询的接口返回该主体涉及的劳动仲裁案件列表、案由、处理机构、裁决结果等结构化数据。将这些数据转化为风险评分并驱动预警动作就是整套系统的核心价值。1.2 系统模块划分与技术方案选型整套系统划分为四个核心模块各模块边界清晰便于后续维护和扩展模块核心职责关键实现点对接层封装天远API的请求、签名、响应解析签名算法、超时重试、错误码映射数据层存储查询记录、裁判数据、风险事件唯一索引、缓存策略、数据脱敏规则引擎根据仲裁数据计算风险分、生成预警可配置规则、评分模型、阈值触发通知模块向背调专员、业务负责人发送预警邮件、IM机器人、站内信技术选型直接用PHP。这个项目是在已有的人力资源管理系统内扩展团队PHP技术栈成熟没必要为了一个模块引入新的语言体系。框架方面我用的是公司内部基于现代PHP规范搭建的轻量框架但下面的核心代码不依赖任何框架特性纯PHP也可以直接运行方便大家移植到自己的项目里。选择天远API而不是自己爬取裁判文书网原因很直接劳动仲裁数据分散在各个仲裁机构公开渠道不完整、不及时直接爬取不仅数据质量差还涉及合规风险。天远API做了数据整合一次查询可以汇聚多个来源的数据返回结构统一还有独立的鉴权加密机制更适合做系统化集成。2. 天远API对接的核心细节与接口设计2.1 鉴权机制签名、时间戳与随机数对接天远API第一个难点是鉴权。它的整体设计是典型的开放平台风格每个接入方分配一组唯一的应用凭证包括appKey和appSecret。请求时需要生成签名服务端通过签名校验请求的合法性。签名生成规则如下将所有请求参数appKey、timestamp、nonce、业务参数按字段名升序排列拼接为keyvaluekeyvalue格式的字符串在拼接字符串末尾附加appSecret对最终字符串做MD5散列得到32位小写签名。这个设计里appSecret是核心机密不能出现在请求参数中只能用来参与服务端签名计算。timestamp防止重放攻击nonce随机字符串防止签名被多次复用。我在实现时专门做了一层封装把签名和请求逻辑隔离避免在业务代码里散落着拼接参数字符串的操作。?php /** * 天远劳动仲裁API客户端封装 */ class TianYuanApiClient { private $appKey; private $appSecret; private $baseUrl; private $timeout; public function __construct(string $appKey, string $appSecret, string $baseUrl, int $timeout 10) { $this-appKey $appKey; $this-appSecret $appSecret; $this-baseUrl rtrim($baseUrl, /); $this-timeout $timeout; } /** * 生成签名 * 规则所有参数按key升序排列拼接为keyvaluekeyvalue * 末尾再拼接上appSecret整体做MD5。 */ private function makeSign(array $params): string { ksort($params); $stringToSign ; foreach ($params as $key $value) { if ($value || $value null) { continue; } $stringToSign . $key . . $value . ; } $stringToSign rtrim($stringToSign, ); $stringToSign . $this-appSecret; return strtolower(md5($stringToSign)); } /** * 执行HTTP请求 */ private function request(string $endpoint, array $params): array { $params[appKey] $this-appKey; $params[timestamp] time(); $params[nonce] md5(uniqid(mt_rand(), true)); $params[sign] $this-makeSign($params); $url $this-baseUrl . $endpoint; $json json_encode($params, JSON_UNESCAPED_UNICODE); $ch curl_init(); curl_setopt_array($ch, [ CURLOPT_URL $url, CURLOPT_RETURNTRANSFER true, CURLOPT_POST true, CURLOPT_POSTFIELDS $json, CURLOPT_HTTPHEADER [ Content-Type: application/json; charsetutf-8, Content-Length: . strlen($json), ], CURLOPT_TIMEOUT $this-timeout, CURLOPT_CONNECTTIMEOUT 5, CURLOPT_SSL_VERIFYPEER true, CURLOPT_SSL_VERIFYHOST 2, ]); $response curl_exec($ch); $error curl_error($ch); $httpCode curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($error) { throw new RuntimeException(天远API请求失败 . $error); } if ($httpCode ! 200) { throw new RuntimeException(天远API响应异常HTTP状态码 . $httpCode); } $data json_decode($response, true); if (json_last_error() ! JSON_ERROR_NONE) { throw new RuntimeException(天远API返回数据无法解析 . json_last_error_msg()); } return $data; } }这里的签名流程里有个容易被忽略的细节timestamp用的服务器当前时间但云服务器时间和标准时间偶尔会有偏差天远API的容差范围一般在5分钟以内。如果出现签名校验失败先排查服务器时间是否准确可以配置NTP自动校时。2.2 查询接口的参数设计与人员信息校验天远劳动仲裁查询接口的核心参数包括被查询人姓名必填身份证号码二选一身份证号或企业统一社会信用代码企业统一社会信用代码二选一查询类型个人仲裁 / 企业仲裁分页参数page、pageSize个人查询我这里必须强调一点身份证号属于敏感个人信息不是随便就能拿去调接口的。在实际业务里必须获得被查询人的明确授权并且查询行为应留存完整的授权凭证这是个人信息保护法合规的底线要求。我们在系统里增加了一道授权确认流程候选人在面试阶段签署背调授权书后系统才会调用查询API每次查询都记录操作人和授权文件编号。参数校验这块我也吃了亏。身份证号码传参时如果格式不统一比如有的传18位带X有的传15位API可能识别失败。建议在对接层统一做清洗和校验只传合法格式的参数同时在日志里打上掩码后的身份证号方便排查问题。?php /** * 身份证号脱敏工具 */ function maskIdCard(string $idCard): string { if (strlen($idCard) 18) { return substr_replace($idCard, **********, 6, 10); } if (strlen($idCard) 15) { return substr_replace($idCard, ********, 6, 8); } return 非法证件号; } /** * 身份证号基础合法性校验返回 bool */ function isValidIdCard(string $idCard): bool { // 这里做基础的正则校验不展开完整的18位校验码算法 // 完整算法写入实践中权重因子、模11校验等 return (bool) preg_match(/^\d{17}[\dXx]$/, $idCard); }2.3 响应数据解析与状态码语义天远API统一返回JSON结构核心字段包括code业务状态码200表示查询成功message状态描述data查询结果详情需要特别注意的是查询接口返回的数据虽然已经是结构化JSON但劳动仲裁的裁决过程往往会有多个阶段立案、开庭、调解、裁决、终局裁决、一审、二审。不同阶段返回的关联数据可能分散在多个子表中响应里每个案件还会带一个状态字段需要后端判断当前案件是否已经结案避免拿中间状态的数据做最终决策。示例响应结构脱敏后{ code: 200, message: success, data: { name: 张**, id_card: 110******************, total_count: 2, cases: [ { case_no: 京劳人仲字[2023]第01234号, case_type: 劳动仲裁, role: 申请人, cause: 追索劳动报酬, arbitral_authority: 北京市劳动人事争议仲裁委员会, filing_date: 2023-05-12, result: 裁决支持, result_detail: 裁决被申请人支付申请人工资差额共计人民币…… } ] } }这里的role字段特别关键同一案件中“申请人”是主动发起仲裁的一方“被申请人”是被动应诉的一方。在背调场景里频繁以申请人身份出现的候选人和频繁以被申请人身份出现的候选人解读方式完全不同。前者可能是主动维权意识强后者则更多反映劳动纠纷缠身。我的规则引擎里这两种情况分别设置了不同的权重和阈值。3. PHP核心代码实现与数据层设计3.1 查询服务封装把API调用和业务逻辑解耦为了不让背调业务代码直接依赖天远API的细节我在中间加了一个服务层。业务方只关心传入查询对象和场景类型返回统一的查询结果对象。这样即使后续替换数据源业务层可以做到零改动。?php class ArbitrationQueryService { private $apiClient; private $queryLogRepository; public function __construct(TianYuanApiClient $apiClient, ArbitrationQueryLogRepository $queryLogRepository) { $this-apiClient $apiClient; $this-queryLogRepository $queryLogRepository; } /** * 个人仲裁查询 */ public function queryPerson(PersonQueryRequest $request): ArbitrationQueryResult { $response $this-apiClient-request(/v1/arbitration/person, [ name $request-name, id_card $request-idCard, page $request-page, page_size $request-pageSize, ]); if ($response[code] ! 200) { $this-logFailure($request, $response); throw new BusinessException(劳动仲裁查询失败 . $response[message]); } $result $this-transformResult($response[data]); $this-logSuccess($request, $response); return $result; } /** * 企业仲裁查询 */ public function queryCompany(CompanyQueryRequest $request): ArbitrationQueryResult { $response $this-apiClient-request(/v1/arbitration/company, [ credit_code $request-creditCode, page $request-page, page_size $request-pageSize, ]); if ($response[code] ! 200) { $this-logFailure($request, $response); throw new BusinessException(企业劳动仲裁查询失败 . $response[message]); } $result $this-transformResult($response[data]); $this-logSuccess($request, $response); return $result; } private function logSuccess($request, array $response): void { // 入库记录成功日志包含掩码后的身份信息、返回条数、耗时等 } private function logFailure($request, array $response): void { // 入库记录失败日志便于后续计费核对和问题回溯 } private function transformResult(array $data): ArbitrationQueryResult { // 将API返回的数据转换为领域模型 $cases array_map(function (array $item) { return new ArbitrationCase( $item[case_no], $item[case_type], $item[role], $item[cause], $item[arbitral_authority], $item[filing_date], $item[result], $item[result_detail] ); }, $data[cases] ?? []); return new ArbitrationQueryResult( (int) $data[total_count], $cases ); } }服务层里我把查询日志单独抽了一个仓储类来记录这一点很重要。劳动仲裁查询是按次计费的日志不仅能用于内部成本核算一旦出现客户投诉或数据合规检查日志就是完整的凭证。实际操作中有一次计费对不上排查下来是某个旧版本接口重复提交导致的还好日志记录完整追踪到具体请求ID才解决了问题。3.2 数据库表结构设计与缓存策略数据存储直接决定后续规则引擎的查询性能。我设计了六张表核心三张表如下仲裁查询记录表arbitration_query_log字段类型说明idbigint自增主键query_novarchar(64)业务查询流水号每次查询唯一query_typetinyint1-个人 2-企业namevarchar(50)被查询人姓名个人查询id_card_maskedvarchar(30)脱敏身份证号credit_code_maskedvarchar(50)脱敏统一社会信用代码sourcetinyint场景来源1-招聘背调 2-供应商风控authorize_file_novarchar(64)授权文件编号api_statustinyint天远API返回状态码result_countint返回仲裁记录数response_snapshotjson全量响应快照operator_idbigint操作人IDcreated_atdatetime创建时间仲裁案件表arbitration_case字段类型说明idbigint自增主键case_novarchar(60)案号全局唯一subject_typetinyint主体类型1-个人 2-企业subject_namevarchar(100)主体名称roletinyint1-申请人 2-被申请人cause_typevarchar(100)案由authorityvarchar(200)仲裁机构filing_datedate立案日期result_typetinyint裁决结果分类result_detailtext裁决详情全文created_atdatetime入库时间案件关联主体表arbitration_case_subject字段类型说明idbigint自增主键case_idbigint关联案件IDperson_id_card_hashchar(64)身份证号哈希值person_namevarchar(50)姓名company_credit_code_hashchar(64)企业信用代码哈希值company_namevarchar(100)企业名称说明一下为什么case_no要加唯一索引。劳动仲裁数据在多个来源可能重复推送同一个案号如果入库两次会导致后面的统计、评分全部翻倍。我实际跑数据的时候发现由于查询时间跨度重叠同一案件出现在两次不同查询结果中。处理方案就是案号唯一采用INSERT ... ON DUPLICATE KEY UPDATE重复推送幂等处理。缓存方面劳动仲裁数据不会频繁变化同一主体在短时间内重复查询没有意义。我在查询服务里加了一层Redis缓存TTL设置为一周缓存key为查询类型脱敏主体标识的MD5值。这样同一候选人在背调周期内再次被复核时直接命中缓存节约API费用也提高系统响应速度。需要注意缓存过期时间不宜过长劳动仲裁案件审理周期一般三到六个月超过一个季度可能就会产生新案件一周的TTL在成本效率和时效性之间平衡得比较好。?php class ArbitrationCache { private $redis; private $ttl 604800; // 7天 public function __construct(\Redis $redis) { $this-redis $redis; } public function get(string $key): ?array { $data $this-redis-get($key); return $data ? json_decode($data, true) : null; } public function set(string $key, array $value): void { $this-redis-setex($key, $this-ttl, json_encode($value, JSON_UNESCAPED_UNICODE)); } public function buildKey(string $type, string $subjectHash): string { return arbitration: . $type . : . $subjectHash; } }3.3 数据脱敏与合规设计还有一部分很容易被忽略API返回的原始数据里包含了完整的身份证号、仲裁机构、具体案由等敏感信息。直接存原始快照一旦数据库泄露就是重大安全事故。我的做法是数据库主表中只存储掩码后的身份证号和名称完整数据的快照单独存储在受控的数据安全区并做加密处理系统内所有的日志输出、接口返回都要经过脱敏过滤器脱敏不是简单的隐藏几位不同角色看到的数据级别不同。背调专员可以查看完整裁决详情用于判断但普通HR只看风险等级和评分结果。这是通过系统的RBAC权限模型来控制的和数据的脱敏存储相辅相成。4. 智能背调与风控预警系统实现4.1 风险评分模型从原始数据到可决策信号数据接进来只是第一步真正有价值的部分是把仲裁数据转化为风险决策依据。我设计了一套风险评分模型综合多个维度的信号基础分100分根据风险因素扣减维度扣分规则说明案件数量每1起案件扣10分封顶40分案件数量直接反映劳资矛盾频度申请人角色以申请人身份主动仲裁每案加回3分主动维权不等同于劣迹适当回补被申请人角色以被申请人身份仲裁每案扣15分劳动纠纷缠身企业方风险高案由类型涉工资/欠薪扣15分涉社保扣10分其余扣5分欠薪类反映企业经营困难倾向裁决结果申请方胜诉扣10分双方调解扣5分驳回不加分裁决结果代表事实认定方向时间衰减近一年案件权重×1.0前两年×0.7更早×0.4近期行为更能反映当前状态评分逻辑里很多人容易犯一个错误把所有案件一视同仁。实操中我区分了主动维权的仲裁和企业方败诉的仲裁。比如某候选人离职后追索拖欠工资赢了仲裁这完全不能说明候选人有问题反而说明前东家不规范。但如果作为被申请人并败诉说明其个人在劳动关系中的守法意识存在明显问题。评分模型必须可解释这一点很重要。我在规则引擎里为每个扣分项记录了完整的原因链路生成背调报告时可以直接追溯到具体案件。比如扣15分原因是2023年6月在某劳动仲裁委的案号为XXX的案件中被申请人身份败诉涉及案由为解除劳动合同经济补偿争议。这样背调专员拿到报告后不需要自己再去翻原始查询记录一眼就能看出风险点在哪儿。4.2 预警规则引擎让系统主动发现风险风险评分算出来后下一步是触发预警。我配置了三层预警规则第一层黑名单级预警当命中以下条件时直接标记为高风险进入人工复核流程近三年作为被申请人出现3起以上败诉案件单案标的金额较大且案由涉及挪用、侵占这类案由在仲裁案中一般体现为赔偿金纠纷同一主体在多家不同企业频繁发起仲裁且每次金额都很小疑似职业碰瓷。第二层黄牌预警近一年仲裁案件超过2起特定岗位财务、法务、高管出现任何劳动仲裁记录供应商近一年劳动仲裁案件同比增长超过50%。第三层提示信息仅作为背景信息写入报告不触发预警比如三年前的调解结案记录。预警通知要避免骚扰。我只把黑名单级预警推送到业务负责人和风控负责人的IM机器人黄牌预警则每日汇总一次发送给背调专员提示级信息只显示在报告里。实际运行过程中预警准确率大约在80%左右确实过滤掉了不少潜在风险但也出现过将正常维权候选人误判为中风险的情况后来在规则里增加了申诉渠道候选人可以提交前雇主的结清证明、和解协议等材料进行人工复核。4.3 通知集成IM机器人推送消息通知模块是我最早完成的部分选用了企业IM机器人Webhook标准。这里对Webhook用做了封装避免预警引擎直接依赖某个具体的IM实现。?php class RiskNotifier { private $webhookUrl; private $channelMap; /** * param string $defaultWebhookUrl 默认机器人推送地址 * param array $channelMap 不同风险级别的推送地址映射 */ public function __construct(string $defaultWebhookUrl, array $channelMap []) { $this-webhookUrl $defaultWebhookUrl; $this-channelMap $channelMap; } public function sendRiskAlert(string $level, string $title, array $content): bool { $url $this-channelMap[$level] ?? $this-webhookUrl; $payload json_encode([ msgtype text, text [ content $title . \n . $this-formatContent($content), ], ], JSON_UNESCAPED_UNICODE); $ch curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS $payload, CURLOPT_HTTPHEADER [Content-Type: application/json; charsetutf-8], CURLOPT_RETURNTRANSFER true, CURLOPT_TIMEOUT 5, ]); $response curl_exec($ch); curl_close($ch); return $response ! false; } private function formatContent(array $content): string { $lines []; foreach ($content as $key $value) { $lines[] $key . . $value; } return implode(\n, $lines); } }预警消息的格式我做过几轮迭代。最初推送的是纯文本风控同事反馈责任人和案件号找半天。后来优化成结构化的文本块每条消息固定包含被查询主体、风险等级、风险原因摘要、关联案号、报告链接。这样收到消息后不用进系统就能做初步判断。4.4 定时任务与增量更新机制光有即时查询还不够风控系统需要对长期合作企业做定期复检。我写了一个定时任务每个月初自动刷新重点供应商和重点岗位在职员工的仲裁信息。这里的增量更新逻辑和首次查询完全不同首次查询全量拉取入库增量更新只查询上个月是否有新案件有新案件才更新缓存、触发评分重算和预警检查。这里有一个优化点不要对名单里所有主体都全量重查成本太高。我的做法是优先查询风险等级中等以上的主体低风险主体每季度复检一次即可。这个策略上线后API月成本下降了接近40%而风险发现率基本没有下降。5. 实战中的常见问题与排查技巧5.1 高频错误码速查签名失败、余额不足、频率超限上线半年多我把天远API的常见错误整理成了速查表遇到问题直接对照定位错误码含义常见原因排查方案1001参数缺失请求体字段名拼写错误核对接口文档字段名注意大小写1002签名校验失败appSecret配置错误、参数拼接顺序错误、服务器时间偏差按规则逐步打印中间签名字符串比对1003应用凭证无效appKey或appSecret错误、应用被禁用检查配置中心联系平台重新生成1004账号余额不足预付费账号欠费配置余额预警提前充值1005查询频率超限超过单日调用次数上限本地加限流合理安排缓存2001未查询到记录输入主体信息无误但无匹配案件该结果本身也是有效结果正常处理2002主体信息不匹配姓名与身份证号不匹配告知业务方提示用户核对信息签名失败是最常见的坑。排查签名时我建议封装一个调试用的方法把待签名字符串打印出来自己用同样的算法算一遍对比服务端返回的错误信息。大多数问题都出在空值参数处理上比如某个字段传了空字符串签名里包含进去或过滤掉两种处理方式会影响最终结果必须严格按照文档执行。频率超限这个问题也值得单独说。背调高峰期比如招聘季几十个候选人同时提交查询如果直接并发调天远API很容易触发限流。我在查询服务外面加了一层简单的限流器按应用维度每秒最多并发5个请求超出部分进入队列等待。?php class RateLimiter { private $redis; private $key tianyuan:rate_limit; private $maxQps 5; public function __construct(\Redis $redis) { $this-redis $redis; } public function tryAcquire(): bool { $current (int) $this-redis-get($this-key); if ($current $this-maxQps) { return false; } return (bool) $this-redis-incr($this-key); } public function resetWindow(): void { $this-redis-setex($this-key, 1, 0); } }实测这个滑动窗口限流方案在高并发场景下会有些许误差但对API调用场景来说完全够用更重要的是代码简单不会引入额外的中间件依赖。5.2 超时重试与服务降级外部API接口的稳定性不可控一定要处理超时和降级。我的策略是连接超时设为5秒读取超时设为10秒失败后最多重试2次间隔100ms、200ms递增重试仍然失败则记录错误并直接返回“查询暂不可用”状态不阻塞整个背调流程在系统层面设置熔断开关连续失败超过5次则进入降级模式所有查询直接走本地缓存数据。还有一个容易被忽略的问题curl在POST大JSON的时候如果Content-Length不准确服务端可能解析超时。我在封装时就遇到过后来把CURLOPT_POSTFIELDS统一用字符串而不是数组并手动计算了Content-Length问题解决。相关内容已经在上面代码里写好了。5.3 数据一致性幂等入库与去重接口可能因为超时重试导致同一条数据被提交两次后端收到重复请求后如果没有做幂等设计就会产生冗余记录。除了前面提到案号唯一索引我还在查询流水号上加了唯一约束。业务侧每次查询生成一个query_no天远API回包里也会回传该字段最终入库时以query_no和case_no做联合唯一判断保证同一案件不会重复入台账。实际数据里还有一种特殊情况同一个案件在仲裁阶段和企业方后续起诉到法院的一审、二审记录会被API分多次返回。这时需要用原始案号做关联我在案件表里增加了一个parent_case_no字段用来标识同源案件评分时只计算底层仲裁案件避免因为两审记录导致重复扣分。5.4 避坑清单从真实项目中提炼的经验最后整理几条踩出来的经验写给打算做同类项目的人签约前先确认API服务商的日配额和单价。劳动仲裁查询是按次计费的高峰期额度不够临时充值不仅贵还可能影响背调流程。我做的余额预警是在账号余额低于某阈值时通过IM机器人通知管理员身份证号、信用代码这类主体标识在进入查询前一定要做格式校验和哈希处理。哈希值用于系统内部关联明文只用于API请求减少泄露面不要过度依赖单家API服务商。我在对接层做了接口抽象后续接入第二家数据源时只需要新增一个适配器代码改动量很小生产环境的日志级别一定要区分开查询成功、失败、异常要单独统计。调取单据核对API消费明细时一份清晰的日志能帮你省下大量沟通成本如果背调流程涉及候选人自主提交仲裁文书设置一个与API查询相应的文件上传入口。系统可以自动比对文件中的案号和API返回的案号大幅提高人工复核效率。这套系统还有一个开发方向是可以把我提到的风险评分模型继续完善。目前的评分规则是靠人工配置的专家规则后续可以引入机器学习模型把历史仲裁案件的最终结果作为训练样本自动学习不同案由、角色、金额组合的风险权重。数据沉淀到一定规模后这个方向确实值得做。不过在那之前先把当前的规则引擎和API对接稳定性维护好已经是很多企业基础风控能力的关键一环了。