离岸快车编辑部｜2026年10月28日

一家同时经营美元与欧元账户的跨境设计公司，规定“付款都由两个人看过”。实际操作却是财务经理在网银创建指令，再用其持有的管理员权限临时提高额度，另一名同事只在聊天软件回复“可以”。当日银行系统仍显示财务经理本人能够批准自己创建的交易。纸面上有两个人，控制上却只有一个人。这正是权限矩阵需要解决的问题：谁可以看到什么、创建什么、修改什么、批准什么，哪些动作必须由不同自然人完成，以及系统记录能否证明这种分离真的发生。

先盘点“账户”和“动作”两个维度。账户维度包括不同法人、不同银行、币种子账户、定期存款或贸易融资账户；动作维度至少包括查看余额、下载结单、创建付款、维护收款人、上传批量文件、核验文件、批准付款、释放交易、调整限额、增删用户和修改通知渠道。只写“财务部可操作账户”没有办法发现危险组合。矩阵每一行是一类动作，每一列是岗位或具体用户，格子里标可执行、只读、不可执行及额度。另标银行端实际生效日期，不能把内部任命当成系统授权。

以这家公司为例，业务主管可以查看与项目相关的应付申请和合同，不必获得银行登录；应付会计可以在指定账户制单，但不能批准自己的付款；财务负责人可批准日常供应商款，但不应单独增加新收款人并立即支付；董事或另一名有权人员参与超出内部阈值的例外审批；系统管理员负责用户配置，不因“懂网银”就自动取得所有账户的付款批准权。矩阵应依公司规模和银行可配置功能调整，不把这组岗位分工说成任何银行的强制规则。

“双人”也不等于同一人在两个身份之间切换。银行提供的电子渠道可能支持制单人与审批人分离，也可能允许经特别申请启用单人自批。DBS公开说明将双人控制描述为一人发起、另一人批准，并指出其系统可配置单人控制；这只是该产品的示例，不是所有银行的界面或默认设置。企业应通过银行用户报告核实每个登录身份的角色，检查是否存在同一自然人持两个账号、共享设备或令牌、借用同事动态口令的情况。任何共享凭证都会让审批日志失去证明力。

矩阵的第一道防线是付款依据。制单人应从内部批准的付款申请取数据，核对合同相对方、发票、收款人法定名称、账号、币种、金额和到期日。若是首次付款或收款账户变更，先走独立验证渠道，不能直接按来信修改收款人。付款申请的批准和银行交易的批准可以由不同岗位完成，但不能互相替代：业务同意采购，不代表银行指令数据正确；银行审批人点了“批准”，也不能证明底层合同已经有效。两种审查最好在同一交易编号下关联。

第二道防线是收款人维护。许多事故不发生在金额审批本身，而发生在收款人主档被改之后。矩阵应明确谁能新增或修改收款人、谁独立核验账户变更、谁批准主档生效、谁可以调用已保存模板。若银行产品允许新增收款人后立即付款，企业可通过内部流程要求新收款人在首次付款前由另一人核对；若系统有独立审批功能，则设置与内部要求一致。不要因为对方是老供应商就省去改户验证，老关系正容易让冒名邮件得手。

第三道防线是批量文件。工资、供应商结算或平台退款可能以文件上传，屏幕只显示汇总金额。复核人应能看到文件批次号、笔数、币种、总额、收款人变动清单、被拒绝和被改动的单笔明细；审批银行批次前，抽样或按风险全量核对来源文件与银行待批准队列。若文件上传后有一笔被系统修改或删除，旧的内部批准不能自动覆盖新批次。矩阵要区分上传人、文件核验人、交易审批人和最终释放人，若银行只提供部分角色，也应通过内部记录补足必要的独立复核。

第四道防线是限额与例外。内部可以设置单笔、每日、按供应商或项目的审批阈值，但具体金额应由企业依据交易规模和风险确定；文章不提供通用阈值。超过阈值时，可要求第二位更高级别授权人或额外业务证明。关键是限制谁能改变阈值：若付款审批人自己能临时调高限额，并在同一天批准原本超限的付款，所谓阈值只是装饰。提高限额要有事前依据、有效期限、独立批准及事后恢复记录。银行端和企业内部限额若不一致，以两者同时满足为执行前提。

第五道防线是管理员权限。管理员可能增删用户、改变角色、开通账户访问、重置设备或调整审批组；这些能力未必直接转钱，却能改写转钱的条件。为管理员设双人复核或至少独立审批与定期回看，建立变更单，列申请人、理由、影响账户、变更前后截图或报告、银行生效回执。尤其应核查离职者和外包会计的访问、备用管理员、已经停用但仍在系统里的账号。DBS的公开企业网银资料也将管理员、制单、审批、核验与释放描述为可区分的角色，说明“网银用户”不是单一权限。

举一个实际决策情境：公司要向首次合作的葡萄牙印刷商支付欧元三万，业务负责人已经批准采购。应付会计录入新收款人和付款指令；另一名财务人员通过合同及已核实的旧联系方式独立确认收款资料；具有该欧元账户权限的审批人查看银行待批详情，对照付款申请、发票、账户信息和金额；若系统还有释放步骤，释放人核对最终批次未被替换。四个动作可以由两人以上完成，但同一个人不能用两个账号自我证明。若印刷商临时要求改户，交易应回到收款人验证环节，不能沿用此前对旧账号的确认。

矩阵还要处理缺席。审批人出差或休假时，指定备用授权人的账户范围、额度和生效期间；备用人应预先完成银行要求的开通，不靠共享口令临时顶班。若只剩一位合格审批人，企业可以延后付款、与银行确认是否存在合规替代安排，或启用经正式授权的备用人。商业紧急性不自动允许绕过双人控制。事后补签聊天记录不能改变银行系统里实际上由谁批准了款。紧急权限若确需开通，应有明确开始、结束和复核时间。

如何验收矩阵？用银行导出的用户与权限报告逐项核对内部表，抽查不同金额、不同币种和新旧收款人的真实待处理交易，确认系统要求的审批人和内部设计一致；不要为测试制造没有业务背景的假付款。再查日志：制单、收款人维护、批准、释放是否由预期人员完成，是否有自批、越权、限额临时提高或夜间异常变更。对不支持细分角色的银行产品，企业应明确记录系统限制和补偿控制，而不是在制度里写一个系统做不到的功能。

权限矩阵不是一次性文件。新增法人或币种账户、岗位调动、人员离职、银行升级产品、批量付款占比上升，都可能改变实际风险。每次变更后由非管理员人员复核银行端设置；每月或每季按企业风险水平回看高权限账号、备用审批人、长期未使用用户和临时额度。周期由企业自行制定并遵守适用规则，不应冒充银行统一规定。留痕要足以回答“谁在何时依据什么批准哪一笔”，同时避免将个人密码和动态口令存进审计档案。

尤其别遗漏“只读”账号的边界。能够下载完整结单和收款人资料的人虽不能付款，仍接触客户与供应商的敏感信息；只读应按岗位限制账户范围，离职时与交易权限一起关闭。通知权限也需要单独检查：谁会收到新收款人、限额变更、交易批准与设备重置提示。若所有通知都送到同一名管理员控制的邮箱，独立审批人的事后发现能力会被削弱。可让另一名有权负责人定期从银行系统或正式通知渠道核对高风险变更，而不是仅依赖管理员转发截图。

制度上还应明确拒绝权。复核人若发现合同收款方与网银收款人不一致、发票金额被人工改写、付款目的说明过于笼统或审批时间异常，应能把指令退回并要求重新提交，不因已经接近截止时间而被迫点击批准。退回记录写明具体字段、所需补充证据和重新发起的交易编号。修改后的指令是新版本，必须再次经过适用的审批链；原审批不能自动迁移。这样双人复核才是一项真实判断，而非第二个人替第一人完成最后一次点击。

矩阵验收时可选一张已经真实支付的普通供应商款，从银行日志倒查到内部申请，再倒查到供应商原始账单；另选一张被退回的指令，看退回原因是否在重提后解决。前者检验正常路径是否完整，后者检验控制能否真正阻止错误。若只抽查成功付款，团队容易误把“顺利执行”当成“复核有效”。抽查结论应写明样本、发现和改进负责人，而不必把客户完整账户资料复制进报告。

资料清单：银行账户与币种清册；当前用户及角色导出；内部岗位授权及签字文件；按动作和账户划分的权限矩阵；单笔与批量付款流程；收款人变更验证记录；限额和临时授权记录；样本交易审批日志；离职及备用人员清单；定期复核与例外整改台账。矩阵经过董事或有权管理者批准后，再按开户行实际支持的设置实施。未能在银行端生效的格子必须标“待实施”或“补偿控制”，不能标“已完成”。

最终检查用一个反向问题：若掌握某个账号的人想独自把钱付给新收款人，他能否先添加收款人、再提高限额、再批准付款，还能删掉通知？若答案是“能”，即使制度写着双人审批，也应重新拆分权限。若答案是“不能”，仍须定期检查是否有人共享设备或审批人只看金额。双人复核的目标不是制造更多点击，而是在每个可改变资金去向的关键节点留下独立、可追溯的判断。

资料核验：DBS关于单双人控制的公开说明；DBS企业网银用户管理指南。