在对公业务流程中，OCR 不应仅仅作为“录入工具”，它必须升级为 “验真引擎”。 我们需要在 OCR 识别的前后，加装两道防火墙：前置的图像篡改检测 和 后置的联网数据比对。

1. 第一道防线：图像篡改检测 (Image Forensics)

在 OCR 引擎介入之前，先让“图像取证引擎”扫描一遍图片。 PS 过的图片，虽然肉眼看着完美，但在计算机眼里全是破绽。

  • ELA (Error Level Analysis) 检测：
    • 原理：JPEG 图片每次保存都会引入压缩噪点。如果有人在原图上贴了一张“1000万”的图层并再次保存，这个区域的压缩率（Error Level）会与背景不同。
    • 应用：系统自动分析“注册资本”、“法定代表人”等敏感区域的噪点分布。如果发现注册资本区域的像素噪点异常平滑，系统直接标记“高风险：疑似篡改”。
  • EXIF 元数据审查：
    • 检查图片的元数据。如果 Software 字段显示 Adobe Photoshop CS6，或者 ModifyDate 时间晚于 CreateDate，这都是明显的风险信号。

2. 核心环节：结构化 OCR 提取

这一步是基础，但要有针对性。银行场景下，我们关注的不是全文，而是 “核心四要素”：

  1. 统一社会信用代码（唯一主键）
  2. 企业名称
  3. 法定代表人
  4. 注册资本（风控重点）

工程细节：

  • 二维码辅助：现在的营业执照左下角都有二维码。OCR 引擎应优先解码二维码内容，因为二维码里的信息通常是未经过 PS 篡改的（黑产很难重新生成包含加密信息的二维码）。如果 OCR 文字识别结果 != 二维码解码结果，直接报警。

3. 第二道防线：GSXT 联网核查 (The Source of Truth)

OCR 告诉你“图片上写了什么”，联网核查告诉你“工商局备案了什么”。 这是击穿 PS 骗局的终极手段。

系统流程设计：

  1. 触发动作：OCR 成功提取出 统一社会信用代码。
  2. 实时调用：后台系统立即调用 国家企业信用信息公示系统 (GSXT) 或第三方权威数据源（如企查查/天眼查 API）。
  3. 字段级比对 (Field-level Matching)：
    • OCR_Name vs API_Name
    • OCR_Capital vs API_Capital
    • OCR_Person vs API_Person

风控逻辑判定：

  • 情况 A（绿灯）：所有字段完全一致 -> 自动通过。
  • 情况 B（黄灯）：企业名称一致，但“经营范围”不一致（可能是企业刚变更，执照未更新） -> 转人工复核，提示客户上传最新执照。
  • 情况 C（红灯）：OCR 识别为“1000万”，API 返回“100万” -> 致命风险。系统自动拒绝开户/授信申请，并将该客户列入黑名单，因为这涉嫌欺诈。

4. 落地场景：企业网银开户 (KYB)

传统流程： 客户上传执照 -> 客户经理肉眼看一眼 -> 录入系统 -> 后台复审人员登录工商网查询 -> 截图留底 -> 通过。 （耗时：2-3 天，且容易因搞“人情世故”放过问题执照。）

智能化流程：

  1. 客户上传：在企业网银 App 上传执照照片。
  2. 毫秒级验真：
    • 系统后台并发执行：OCR 识别 + 篡改检测 + 工商 API 查询。
  3. 实时反馈：
    • 如果比对一致，系统自动回填表单，客户只需确认。
    • 如果比对不一致，前端直接报错：“您上传的执照信息与工商登记不符，请核实后重新上传。”

5. 总结

在银行对公业务中，营业执照 OCR 绝对不能只做一个“录入工具”。 它必须是 风控体系的入口。

通过 “OCR + 联网核查” 的双重验证机制，我们解决的不仅仅是“效率”问题（少打几个字），更是解决了银行最核心的“安全”问题（防止骗贷）。

对于银行来说，拦截一张虚假注册资本的营业执照，挽回的可能就是一笔数百万的坏账。这才是技术的真正价值。