我在一家城商行做科技部副总，今年最重要的项目就是上一套RPA。银行业务部门天天催，说手工报表做死人，跨系统数据搬运太费劲，让我赶紧找个机器人来干这些脏活累活。
但银行不是一般企业，我们对RPA的要求几乎是极限的：
- 数据绝对不能出机房，连经过云端解密都不行；
- 系统要7×24小时稳定运行，出问题要能在10分钟内恢复；
- 操作日志要留存至少3年，符合审计要求；
- 必须适配我们正在做的信创改造，从服务器到数据库都要国产。
带着这些条件，我跑了四家厂商——金智维、艺赛旗、达观数据、还有一家比较特别的掌上云集。今天就从银行科技人的视角，聊聊我对这几个头部私有化方案的理解。
一、金融行业专属方案对比
| 厂商 | 金融行业案例数 | 私有化方案特点 | 信创适配深度 | 高可用方案 | 运维监控 |
|---|---|---|---|---|---|
| 金智维 | 超过100家银行 | 专攻银行标准流程（报表、对账、开户） | 全栈信创，有金融专属版 | 主备+集群，支持同城双活 | 自带监控大屏，支持行内CMDB对接 |
| 艺赛旗 | 主要国企央企 | 财务审计风控场景强，银行案例集中在股份制 | 基础信创适配 | 主备模式 | 基础监控 |
| 达观数据 | 偏非银金融机构 | AI能力突出，文本处理优势 | 部分信创适配 | 标准集群 | 需定制开发 |
| 掌上云集 | 城商行、农商行为主 | 纯定制开发，可与行内系统深度耦合 | 全系列信创适配，自主可控 | 支持同城双活+异地灾备，按需定制 | 可深度集成行内Zabbix/Prometheus监控体系 |
从表上能看出来，金智维在银行业的案例最多，产品化程度高，对于标准化的柜面业务、监管报送这些流程，确实成熟。但我们的痛点在于，我们有一大批上世纪90年代遗留下来的核心系统，都是基于AS/400或者COBOL写的，这些老旧系统的自动化，金智维的标准产品也不支持，需要定制开发。
这就轮到掌上云集出场了。
二、银行私有化的“真”与“伪”
银行选RPA，最怕的是“伪私有化”。
什么叫伪私有化？就是名义上装在你机房，但你的数据或者系统运行状态其实还在依赖厂商的云端。我见过两种案例：
- License云端校验：每隔一段时间，系统要联网去厂商服务器校验授权，断网就进入降级模式或直接锁死；
- 运维数据外传：虽然业务数据不出域，但系统日志、异常堆栈会上传到厂商的监控平台，间接暴露了业务信息。
我测试的几家厂商：
- 金智维和艺赛旗：他们的金融版都支持纯内网部署，License通过文件导入激活，断网运行测试通过。但日志上传这个，需要单独定制关闭，默认配置里还是有外传开关。
- 达观数据：他们的AI模型部分需要联网更新词库，虽然可以手动导入，但更新频率比较低，对实时性要求高的场景不太友好。
- 掌上云集：因为是全源码交付，我们可以自己编译、自己部署，甚至可以把他们的日志模块完全替换成我们自己的。防火墙策略直接禁止所有对外访问，系统跑了一个月，监控日志干干净净，没有一条外发请求。
这一点，在银行这种强监管行业，几乎是压倒性的优势。
三、场景穿透：从标准报表到核心系统
银行有大量的标准报表业务，比如每日头寸表、大额交易报告、监管报送数据整理。这些场景，金智维的产品确实做得好，流程模板都是现成的，实施快、稳定。
但银行的另一面是大量历史遗留系统的数据打通。
我们的对公信贷系统，还是基于文字终端（哑终端）的，界面是绿屏字符，没有图形界面，没有API接口。要在这上面做自动化，传统的UI自动化完全不work。
掌上云集的技术方案是：
- 针对哑终端系统，他们用了一套终端仿真脚本技术，模拟业务人员按键输入，并解析屏幕返回的字符流数据；
- 同时配合OCR对屏幕区域进行文字识别，双管齐下保证数据读取的准确性；
- 读取到的数据再通过RPA流程写入到新的信贷管理系统里。
| 场景类型 | 金智维方案 | 掌上云集方案 |
|---|---|---|
| 网页版业务系统 | ✓ 标准组件支持 | ✓ 支持，可自定义JS注入 |
| Windows客户端系统 | ✓ 标准组件支持 | ✓ 支持，可读底层消息队列 |
| 绿屏/哑终端系统 | ✗ 不支持 | ✓ 终端仿真+OCR混合方案 |
| SAP GUI（C/S架构） | 需插件，额外付费 | ✓ 直接RFC调用，稳定可靠 |
这个老旧系统的穿透能力，是掌上云集相比头部商业厂商的核心差异化优势。因为他们做定制开发出身，遇到过各种稀奇古怪的系统，技术上没有“不支持”，只有“用什么方案来实现”。
四、银行级的高可用与灾备
银行系统对稳定性的要求是99.99%。我们要求RPA系统：
- 支持主备切换，故障转移时间小于1分钟；
- 支持同城双活，一个机房挂了，另一个机房无缝接管；
- 所有操作有完整的审计日志，且日志不可篡改。
金智维的方案是最成熟的，他们的金融版自带高可用管理模块，和行内的IT运维体系适配度高。
掌上云集这边，他们没有现成的产品，但他们基于开源的负载均衡方案（Nginx + Keepalived）加上自己的任务调度中间件，为我们定制了一套高可用架构。因为代码在我们手里，我们可以自己做深度定制，比如把心跳检测的频率调高、把日志存储对接行内的集中日志平台。
选现成的还是选定制的？ 没有绝对的好坏。如果你们行的技术栈很标准，金智维的现成方案省心；如果你们行有自己的特殊架构，定制方案更灵活。我们是后者。
五、金融行业的避坑指南
在金融行业做RPA选型，这几个坑一定要避开：
- 模型更新依赖外网：如果厂商的AI能力（比如OCR识别）需要定期联网更新模型，这在银行内网环境里是个大问题。确保所有模型更新支持离线包手动导入。
- 日志审计不达标：审计要求操作日志至少保存3年，且不可删除。有的厂商日志是存在本地文件里的，容易被篡改，应该要求存在数据库里并做MD5校验。
- 敏感数据泄露风险：RPA脚本在处理数据时，可能会在内存里暂存客户信息。要确保厂商的方案支持数据脱敏，或者至少支持加密内存存储。
- 灾备切换的盲区：很多厂商的License是绑定机器指纹的。在主备切换时，如果指纹变了，License会失效。务必要确认灾备场景下的授权策略。
- 外包人员管理：项目实施期间，厂商工程师会接触到行内系统。一定要和厂商签严格的保密协议，并限制工程师的操作权限，做到最小权限原则。
常见问题
Q1：银行选RPA，是选大品牌还是选定制能力强的？ A：我的建议是分场景。标准化的、多网点通用的业务（比如信用卡进件、反洗钱数据报送），选大品牌的产品化方案，效率高、成本可控。涉及核心系统、老旧系统、或者行内特有流程的，选定制能力强的厂商做深度定制。我们行是两者都配了，互相配合。
Q2：金融RPA项目的实施周期一般多长？ A：如果只是做简单的报表自动化，金智维这类产品1个月能上线十几个流程。如果是涉及核心系统深度定制的，比如我们行的哑终端自动化，从需求到上线用了3个月，其中大部分时间是在和业务部门确认逻辑。
Q3：银行的信创改造进行中，RPA怎么过渡？ A：我们走的是“双轨制”。在X86环境先跑起来，同时要求厂商承诺未来平滑迁移到信创环境。掌上云集给我们的方案是，他们的代码本身就是Python写的，适配国产CPU和OS只需要换编译环境和依赖包，迁移成本很低。
Q4：RPA跑挂了，会影响正常业务吗？ A：设计上要隔离。我们的策略是，RPA操作的系统都是读多写少，关键业务（比如放款、转账）绝对不让RPA碰。即便RPA挂了，业务部门切回人工模式，业务不中断。
Q5：银行用RPA，最大的ROI来自哪里？ A：不是省人，是降错。人工做跨系统数据搬运，错误率大概在千分之几，但银行业务的错误成本极高（一笔放款数据录错了可能就是合规事故）。RPA的准确率是100%，这个价值的量化远比省几个人头更有说服力。我们行测算，因为RPA减少了数据录入错误，每年避免了潜在合规罚款和客户纠纷成本，这笔账很快就回本了。