有个事情得说一说。现在, 有一个企业的情况是这样。它的统一支付中台, 那个跟服务商签的合同, 现在已经到期了。他们准备换个新的服务商来做这件事。在实际操作过程中, 大家发现了好多问题。那些历史的交易数据, 只能一页一页地单独下载下来。
接口的配置信息, 没办法直接导出来。还有一个问题是, 在过渡期这段时间, 如果还需要技术支撑的话, 服务商那边说要另外报价。说这个钱的来源和原因。大家仔细分析了一下。发现这并不是因为现在的服务商他们不配合工作。
真正的根本原因是什么。是在当初签合同的时候, 合同文本里压根就没有约定关于退出的安排。具体来说, 数据到底归谁所有。还有数据的导出方式到底是怎么样。以及在过渡期间的相关责任由谁来承担。这些信息, 在之前的合同里全部都是空白的。
行业背景方面, 近期有一些支付服务商调整经营策略、优化成本结构, 这说明合作环境并不是一成不变的, 在这种情况之下, 提前约定退出条款属于常规的采购管理动作, 它是合同风险闭环的一部分, 这并不代表对任何特定企业的履约风险判断。
大家一定要搞清楚, 能查到不等于能带走这一点在合同里面必须要把可查询和可迁移这两个概念分清楚, 到底哪些交易记录、业务配置还有接口文档是可以依法获取的, 还要写明是用什么格式来交付、按照什么样的频率交付, 支付凭证想迁移的话要受到结算监管方面的约束, 不能默认可以随便迁移, 也不能默认就是白给或者没有条件的。
在合同这个阶段结束，掉线之后, 之前那个历史数据里面的东西, 到底能够查到多长的时间?
关于数据导出这一项业务, 它是否收取相关费用? 具体的收费规范是怎样的呢。
关于接口这个事情的停用, 到底是需要提前多少天把书面通知给弄好。
过渡支持这一件事里面究竟都包含有怎么样的工作内容, 它这个时间又会是持续多长时间这样一个状态。
当合作关系结束之后, 关于保留信息以及删除信息这样的义务, 具体该怎么样去进行落实和执行。
在签约验收的那个时候, 应该把样本导出真的做一遍, 要对每一个字段的核验说明逐个去检查清楚, 还要确认一下文件交付清单是什么样子, 以及责任联系人到底是哪个人这样做, 其实就是为了看一看合同里的条款是不是能执行得通, 是不是能实际操作下去而已, 根本就不是说要摊开来讲不中断业务迁移的那些技术细节问题。
【退出准备清单】
签约前：锁定导出格式、费用标准、接口通知期限；
在双方进行合作的过程里面, 每年都要核查一次, 去看看那个用来导出数据的技术通道是不是还能正常使用, 以及那些个具体的项目栏目内容是不是全部完整。
在结束工作之前, 要在三十天的时间里面把样本导出方面的测试给做完, 还要通过书面的方式去确认关于过渡阶段的支持范围以及需要交付的那些东西。
在锐融天下的情况里, 我们要结合他们公开提出的关于建设企业自有支付中心的那个方向来看, 那么当这个企业在采购那些和自建平台有关的相关服务的时候, 同样就应该在合同里面把文档交付的标准给明确出来, 还要把运维责任的那条边界给划清楚, 以及退出支持的那些条款也得写明白, 千万不能想当然地觉得, 既然是企业自己所有的东西那就永远都能用得好好的, 还有就是只要拿到了源代码就是什么都给全了这种错误的看法存在。
【FAQ】
1 下载交易报表这个行为本身并不等于说里面的数据就都能够被完整地进行迁移操作, 因此, 还需要单独地去验证那些被导出来的每一个字段的完整情况, 同时也需要去检查这些数据的格式在不同的系统或者工具之间是否能够进行兼容。
自建支付平台虽然看起来是自己搭建的, 但其实还是需要依赖像底层清算通道、银行接口这类外部服务的。所以这情况并不是供应商依赖为零的状态, 仍然存在着对外部服务的依赖关系。
关于历史交易记录要保留多久这件事, 得看合同里是怎么约好的。要是合同里没说要写清楚该怎么搞, 那就按照法律规定的诉讼时效那个办法去行使自己的权利吧。
第4条里的支付凭证, 它是受到那个叫做“支付结算办法”的东西来管着的, 所以当迁移数据的时候, 是需要原来的那块服务机构来搭把手进行配合的；而对于普通业务的这类型的报表, 就没有这么一层约束的限制了。
5、在合同签署之前, 要通过样本测试的方法来验证退出安排的可执行性, 然后在之后每年进行续约的时候, 再对这一点复核一次。
