FIN · 金融科技

为每一项合规与信贷决策备齐证据的智能体

银行、支付机构、贷款机构和保险公司的风险与合规团队,大部分工时花在收集证据和撰写材料上。FreeSeek 构建的智能体从核心银行系统、反洗钱引擎、征信机构和公开披露中取数,把附带出处的完整档案交给负责决策的人员。每一步都留有日志,供模型风险审查和审计使用。

可对接的系统
Core bankingNICE ActimizeCase managementData warehouseCredit bureau APIsBloombergWind
行业现状

金融风险与合规工作的现状

过去十年,金融犯罪和信贷团队的规模增长快于收入增长。基于规则的交易监测仍在产生大量预警,其中绝大多数最终被认定为误报,但每一条都需要书面结案理由。对公客户开户可能耗时数周,因为分析师要在多个国家的登记系统中追溯股权,并逐一人工筛查每个关联方。

监管机构要求同样严谨,同时对积压的容忍度更低。监管检查会关注案件报告的质量、可疑交易报告的及时性以及信贷决策背后的依据。与此同时,欧盟《人工智能法》、SR 11-7 和各地数据保护法规要求这些流程中的任何模型都必须经过验证、可解释、可追溯。自动化从第一步起就必须可审计。

预警量超过人手

为追求覆盖面而调校的监测场景产生的预警远多于调查人员能按时处理的数量。积压会变成监管检查发现的问题。

股权结构越来越难看清

多层公司架构、代持董事和跨境持股拖慢了 KYB 审查。各国受益所有人登记的覆盖范围和格式各不相同。

监管变化持续不断

新的反洗钱规则、消费者保护要求和报送模板每个季度都在出台。把每项变化对应到内部制度和控制措施,目前主要靠人工。

模型必须可解释

任何影响信贷或合规结果的工具都属于模型风险管理范围。团队需要验证证据和清晰理由,不能只给一个不透明的分数。

智能体运行 · 示例

看智能体如何完成一项真实任务

每一步都是对业务系统的工具调用,全程留痕、可复核;结果交给指定负责人签字确认。

智能体运行 · 示例run_5d81f0
任务审查预警 88213:某零售账户 9 天内 14 笔低于报告门槛的现金存款
  1. actimize.alert()
    已载入预警、客户画像及预期月交易额 3,000 欧元
  2. corebanking.txn()
    发现在 6 个网点存入现金,当天即转给一名新增收款人
  3. case.history()
    关联到同一收款人的 2 条历史预警,均在未审查后续资金去向的情况下结案
结果 · 建议升级并附 STR 正文草稿;已提交调查人员决定,并待 MLRO 签批
应用场景

四个业务流程,逐步拆解。

每个场景都说明:现在怎么做、智能体接手哪些环节、在哪里由人签字,以及我们衡量哪些指标。

FIN-1

KYC/KYB 开户审查

智能体为审查分析师整理完整的开户档案,包括股权链条、筛查结果和风险评级建议。

集成深度 中等
典型试点周期6–8 周
现状

分析师收集注册文件,在各司法辖区的公司登记系统中检索,手工绘制股权图,并对每位董事和股东逐一进行制裁、PEP 和负面新闻筛查。负面新闻命中大多只是同名,排除起来很耗时。一个多层结构的对公客户可能要一到三周,质检后还常因缺少证据被退回补件。

调用的系统
Company registriesSanctions and PEP screeningAdverse-media searchCase managementCore banking
智能体做什么
  1. 从客户提交的文件和登记记录中提取实体、高管和持股信息,按 25% 门槛或银行更低的内部门槛构建股权树
  2. 对每个自然人和法人进行制裁及 PEP 名单筛查,并以相关语言检索负面新闻
  3. 对筛查命中进行聚类,排除明显误匹配并说明理由,标出需要分析师判断的命中
  4. 对照银行的 CDD 和 EDD 清单检查档案,列出需向客户补充索取的文件
  5. 起草风险评级理由,并为所用的每一个来源标注出处
人工把关点
KYC 分析师确认股权树,并对每一条未解决的筛查命中作出判断。被评为高风险的业务关系按银行 EDD 制度提交高级合规官审批。
衡量指标
  • 开户周期
  • 质检退回档案数
  • 附理由自动处置的筛查命中数
  • 每位客户的补件请求数
FIN-2

反洗钱预警分流与可疑交易报告起草

智能体调查交易监测预警,提出处置建议,并为调查人员起草 SAR 或 STR 报告正文。

集成深度 深度集成
典型试点周期8–12 周
现状

一线调查人员逐条打开预警,调取十二个月的交易记录,查询交易对手,翻阅历史案件,再写结案说明。大多数预警最终是误报,但每次结案都需要书面理由。一旦发现可疑,调查人员要在报送时限内从零撰写报告正文,不同人员写出的质量差异很大。

调用的系统
NICE ActimizeCore bankingCase managementData warehousegoAML
智能体做什么
  1. 从监测引擎和核心银行系统调取预警、客户画像、预期交易行为和交易流水
  2. 按拆分交易、资金快进快出、异常交易对手等类型分析资金流向,并关联相关预警和历史案件
  3. 提出处置建议,并列明支持该建议的具体事实
  4. 对需升级的案件,按金融情报机构要求的“谁、什么、何时、何地、为何”结构起草 SAR 或 STR 正文
  5. 将完整证据链和推理过程写入案件管理系统记录
人工把关点
调查人员接受或否决每一条处置建议。是否报送由反洗钱报告负责人(MLRO)或其授权人员决定,并由其签批最终报告正文。
衡量指标
  • 预警处理时长
  • 预警积压时长
  • 调查人员否决率
  • 质检报告正文质量评分
FIN-3

小微企业授信报告起草

智能体录入分析财务报表和银行流水,为客户经理和授信审批人员起草授信报告。

集成深度 中等
典型试点周期6–8 周
现状

客户经理或信贷分析师把财务报表重新录入分析模板,与银行流水和征信报告核对,再撰写报告正文。小微企业的材料多为扫描版 PDF、管理报表和格式各异的流水。一份报告往往要花掉大半个工作日,限制了团队能以合理成本承做的小额授信数量。

调用的系统
Credit bureau APIsCore bankingLoan origination systemData warehouse
智能体做什么
  1. 提取利润表、资产负债表和现金流量表科目,录入银行的分析模板
  2. 对银行流水交易分类,估算经常性收入、现金消耗和现有债务偿付
  3. 调取征信数据,检查偿债覆盖率、杠杆上限等契约和政策指标
  4. 起草授信报告,包括企业概况、财务分析、主要风险、缓释措施和政策例外清单
  5. 标出申报数据与实际流水之间的不一致
人工把关点
信贷分析师核对报表录入并修改报告。授信决定、定价和任何政策例外均由有权审批人或信贷委员会作出。
衡量指标
  • 报告准备时长
  • 每份档案的录入更正次数
  • 从申请到决策的时长
  • 上会前识别的政策例外数
FIN-4

监管变化影响分析

智能体跟踪新规和监管指引,把每项义务对应到内部制度和控制措施,并起草差距评估。

集成深度 快速见效
典型试点周期4–6 周
现状

合规团队阅读监管发布、征求意见稿和监管函件,再到制度库里查找受影响的内容。对应关系记在很快过时的表格里。遇到新的反洗钱规定或报送模板这样的大变化,要开几周研讨会,责任人才知道要改什么、何时完成。

调用的系统
Regulator websites and feedsPolicy management systemGRC platformBloomberg
智能体做什么
  1. 监测监管机构和标准制定机构的发布,逐条提取义务及生效日期
  2. 将每项义务与银行制度库中现有的制度、流程、控制措施和报表进行匹配
  3. 把每项匹配归为已覆盖、部分覆盖或存在差距,并并列引用相关条款
  4. 为合规团队起草影响评估,附建议责任人和完成期限
人工把关点
合规官确认每项差距分类并指定责任人。制度修订按银行常规审批流程和治理委员会程序进行。
衡量指标
  • 从发布到完成影响评估的时长
  • 已对应到控制措施的义务数
  • 生效前关闭的差距数
  • 审核人对建议对应关系的修改数
案例分析

这个领域里的项目是怎么落地的。

示意案例:综合多个典型项目整理而成,已隐去客户信息。数据代表我们设计试点时的目标区间。

在不降低标准的前提下清理交易监测积压

客户: 中型零售及对公银行,客户 240 万地区: 南欧
−41%平均预警处理时长
−63%5 个月后积压时长
+28%报告正文质检评分
挑战

监管检查要求扩大监测场景后,该行预警积压超过四个月。调查人员大部分时间花在收集数据而非分析上。结案理由标准不一,监管机构在抽查已报送的 STR 时也指出报告正文质量偏弱。

我们做了什么
  • 以只读方式将智能体接入监测引擎、核心银行系统和案件管理系统
  • 为一线预警生成附带事实出处的处置建议,并为升级案件起草 STR 正文
  • 设置并行期,调查人员分别在使用和不使用智能体的情况下处理预警并对比结果
  • 按模型风险验证要求编制智能体文档,包括否决跟踪和定期抽样测试
周期: 10 周试点,第 5 个月投产

为支付机构加快对公商户开户

客户: 服务跨境电商商户的持牌支付机构地区: 海湾地区
−35%开户周期
−30%质检退回档案
−22%每户补件请求数
挑战

商户开户平均耗时 12 个工作日,因为许多申请人在多个自由区和离岸辖区设有控股公司。分析师人工追溯股权,并要清理大量同名负面新闻命中。销售团队因此把商户流失给了速度更快的竞争对手。

我们做了什么
  • 针对最常用的登记系统建立股权提取和股权树构建步骤
  • 增加阿拉伯语和英语的负面新闻筛查,并对命中进行聚类
  • 根据 EDD 清单自动生成补件请求
周期: 8 周试点,第 4 个月投产
风险与合规

模型风险、合规与数据管控

模型风险管理

每个智能体都按 SR 11-7 及同类监管要求作为模型或工具登记在册并编制文档。验证内容包括概念合理性、与分析师决策的结果对比测试,以及对否决率的持续监测。

反洗钱标准与报告义务

工作流程遵循 FATF 建议中关于客户尽职调查、受益所有人和可疑交易报告的要求,并以当地法律的落地规定为准。智能体负责准备证据和报告正文,是否报送由 MLRO 或其授权人员决定。

欧盟《人工智能法》与自动化决策

根据欧盟《人工智能法》,对自然人的信用评估属于高风险用途,须具备风险管理、人工监督和日志记录。依照 GDPR 第 22 条,智能体不会对客户作出具有法律效力或类似重大影响的完全自动化决策。

数据保护与审计轨迹

部署遵守 GDPR、中国《个人信息保护法》(PIPL)及当地银行保密规定,数据保留在客户环境或经批准的区域内。每一次查询、每个来源和每份草稿都有日志,审计人员可以完整还原一项建议的形成过程。

常见问题
智能体会决定是否报送 SAR 或是否批准贷款吗?

不会。智能体负责收集证据、提出处置建议并起草报告正文或授信报告。每一项决定都由授权的调查人员、MLRO 或信贷审批人作出并签字,否决情况会被记录。

这如何与我们的模型风险管理框架衔接?

我们按贵行验证团队采用的格式提供模型文档、基于历史决策的测试结果和监测指标。多数客户会在试点转入投产前将智能体登记进模型清单。

需要接入哪些系统?

通常需要监测引擎、核心银行系统、案件管理系统和数据仓库的只读权限,以及筛查和征信接口。写入权限仅限于在案件管理系统中创建草稿和备注。

客户数据在哪里处理?

在贵机构自有环境内,或在贵机构批准的云区域内。部署方案与 GDPR、PIPL、银行保密规定及贵机构外包制度保持一致,客户数据不会用于训练共享模型。

你也有类似的业务流程?

简单描述一下现在的做法,我们会在两个工作日内回复。

开始沟通
其他行业