不让未签署的付款指令发送到银行。
付款文件通过旧的签名应用进行审批。存在未签署文件被发送至银行的风险；付款依据的记录也可能分散保存在不同位置。
借助 Butterfly 付款文件被拆分为两部分。签署人只能看到包含总金额的封面文件；明细文件保持保密。双重电子签名完成之前，付款文件不会发送至银行。每项指令的依据也会附加到内部记录中。
阻止未签署的发送；付款指令的依据及其审批历史均留有记录。
双重电子签名完成 → 已发送至银行
双重电子签名审批完成之前，指令不会发送至银行。示例数据。
信赖 Butterfly 的机构
每一项控制，都是金融信任的一部分。
在银行与金融业务中，一笔交易经过了哪些控制、由谁审批，与交易的完成同样重要。Butterfly 将付款指令、客户核查、交易更正和管理层审批等不同步骤相互连接，实现安全且可追溯的运作。
一项付款指令
在到达银行之前
要经过五道关口。
Butterfly 在每道关口执行规则。缺少签名的文件会在发往银行的途中被拦下。
指令已准备基于工资和 ERP 数据
合规筛查制裁名单核查
第 1 个电子签名财务经理
第 2 个电子签名副总经理
已发送至银行已签署的文件，有记录的发送
缺少第 2 个签名 · 已停止双重签名的文件送达银行缺少签名的文件在第 4 道关口被拦下
在交易发生时即进行合规检查。
每笔客户交易都需要人工查询制裁名单。这既造成运营负担，也可能导致核查延迟。
借助 Butterfly 自动获取最新的制裁名单，并在客户查询时于后台进行匹配。可能的匹配项会在交易界面上以警告形式显示。
人工查询需求减少，合规检查成为交易流程的一部分。
可能匹配 → 交易已暂停
每笔交易都会实时与制裁名单进行比对；可能的匹配项连同理由进入审核。示例数据。
让每一项交易变更都有记录、有依据。
交易更正和取消的历史无法得到充分跟踪。按名称进行账户匹配，存在将交易发送到错误账户的风险。
借助 Butterfly 的流程
- 更正和取消操作按用户记录；取消时必须填写理由。
- 账户匹配依据身份证号/税号和 IBAN，而不是名称。
- 跟踪每项变更由谁进行以及依据何种理由；降低账户匹配错误的风险。
在同一流程中管理付款审批。
付款申请通过电子邮件在业务部门、财务部门和高级管理层之间流转。待处理付款和逾期应付款越来越难以跟踪。
借助 Butterfly 的流程
- 付款申请根据金额阈值依次经过部门审批、财务核查，必要时还需高级管理层审批。
- 驳回和修订时记录理由；待付款项和账龄在管理仪表板上跟踪。
- 审批流程变得可衡量；待处理的付款和决策节点清晰可见。
安全、智能地管理客户请求。
支持请求和理赔表单来自不同渠道。重复记录、分类工作量和表单安全都可能带来问题。
借助 Butterfly 的流程
- 应用 AI 辅助的请求分类和重复记录检测。
- 通过移动端和短信发送的数字表单经验证步骤加以保护。
- 请求被转至正确的流程，重复记录减少，一线支持的工作量减轻。
端到端管理的流程
Butterfly银行付款指令、双重电子签名及安全发送至银行
外汇与贵金属交易业务
客户账户卡、交易更正与取消管理
制裁名单筛查与合规检查
基于阈值规则的付款审批与财务管理仪表板
退税文件流程跟踪
AI 辅助的会议纪要、请求分类与分派
Butterfly 编排层
银行付款指令、双重电子签名及安全发送至银行
外汇与贵金属交易业务
客户账户卡、交易更正与取消管理
制裁名单筛查与合规检查
基于阈值规则的付款审批与财务管理仪表板
退税文件流程跟踪
AI 辅助的会议纪要、请求分类与分派
法规与企业要求
- MASAK
- BDDK 法规和《银行法》规定的系统与数据驻留要求
- KVKK
- 使用合格电子证书的电子签名
- 含/不含 BSMV 的价格显示
来自实践，经过测量出于保密原因，不公开客户名称。
上线应用6,000 名员工
工资付款指令经过双重电子签名核验后发送至银行。该应用已在生产环境中使用。
常见问题
关于银行与金融，简要解答。
关于 Butterfly 在银行与金融流程中应用的常见问题。
使用 Butterfly 时，数据会离开机构吗？
Butterfly 可以部署在机构自有基础设施上，也可以部署在机构专属的私有云环境中。AI 组件也可以配置为使用本地模型运行。由此可以构建数据和系统均处于机构控制之下的架构。
能否阻止未签署的付款文件发送至银行？
可以。付款文件发送至银行以双重电子签名步骤完成为前提。签名完成之前，不会启动文件的发送流程。
是否有银行在生产环境中使用 Butterfly？
已有在银行与金融业务中使用的上线应用。例如，6,000 名员工的工资付款指令经过双重电子签名核验后发送至银行。