第403章 来函！ (第2/2页)
　　
　　安全合规方面要求国密算法、数据不出境、全链路审计。
　　
　　性能指标要求高并发场景下单笔交易确认时间不超过500毫秒，系统可用率99.99%。
　　
　　这些要求对四家来说都不算难。
　　
　　工行建行中行的IT团队规模比微光大得多，基础架构和安全合规是他们的强项。
　　
　　他翻到第四板块，生态覆盖要求。
　　
　　第一条："具备C端用户触达能力，能够在消费场景中实现数字人民币的推广和使用引导。"
　　
　　C端用户触达能力。
　　
　　三大行有几亿的银行卡用户，但银行卡用户不等于数字货币用户。
　　
　　开通数字人民币需要下载App、实名认证、绑定账户，这一套流程的转化率很低。
　　
　　上辈子各大行在试点期间疯狂推广数字人民币钱包，柜台办业务的时候顺带问一句"您要不要开通数字人民币"，大部分人说不用。
　　
　　银行的C端触达能力本质上是网点触达，柜台触达，不是场景触达。
　　
　　你站在银行大厅里跟客户说"请下载数字人民币App"，跟你站在便利店收银台旁边说"扫这个码就行"，是两件完全不同的事。
　　
　　微光不一样。
　　
　　微光协同6000万企业用户，微光惠民247城80%社区覆盖，8.2万团长，日均87万单。
　　
　　每一单都是一个支付场景。
　　
　　每一个团长的店面都是一个C端触达点。
　　
　　不需要在银行大厅里推销，不需要柜台话术，用户在买菜的时候自然接触到数字人民币支付。
　　
　　这条要求是写给微光的。
　　
　　或者说，这条要求是央行写给自己的，他们需要一个能把数字人民币铺到社区毛细血管里的机构。
　　
　　三大行做不到这一点。
　　
　　他继续往下看。
　　
　　第二条到第七条都是常规要求，商户接入能力、跨境兑换支持、无障碍设计。
　　
　　第八条："技术方案须接受研究所指定团队的代码级审查。"
　　
　　代码级审查。
　　
　　他看了这八个字两遍。
　　
　　翻回第一页，确认了函件的编号，又翻到最后一页，看了一遍提交要求和联系方式。
　　
　　把清单放在函件上面，对齐，放在桌面的正中间。
　　
　　…………
　　
　　下午三点，沈南来了。
　　
　　她没有端茶杯，手里拿着一个文件夹，深蓝色的，角上贴了个标签写着"DCEP风险评估·初稿"。
　　
　　"函件我看过了，"沈南说，坐下来之前先把文件夹放在桌上，"四家候选里我们是唯一民企，这个您知道了。"
　　
　　"嗯。"
　　
　　"C端触达那条对我们有利，但代码审查那条要注意。"
　　
　　林彻看着她。
　　
　　沈南打开文件夹，里面是她自己做的风险评估，打印出来的，三页纸，手写批注密密麻麻。
　　
　　"代码级审查意味着央行的技术团队会进到我们的代码仓库里看，"沈南说，"看什么看到什么深度由他们决定。常规情况下他们会重点看支付模块、清算模块和安全模块，这些我们没问题。但是……"
　　
　　她停了一下。
　　
　　"微光支付模块的底层调用链里有AbySS的接口。"
　　
　　办公室安静了一秒。
　　
　　"AbySS-CreditSCOre-v3.2，"沈南说，"信用购的风控评分模块，支付的时候会调用AbySS的信用数据做实时风控判断，这个调用在正常的支付流程里是透明的，用户感知不到，但在代码层面是可见的，审查人员如果顺着调用链往下追，会看到这个接口。"
　　
　　林彻没说话。
　　
　　"AbySS本身不是问题，"沈南说，语速比平时慢了一点，"它的功能是合规的，数据来源是合规的，使用方式也是合规的，问题是它的数据聚合能力太强了，审查人员看到一个能做跨平台信用评分的数据引擎挂在支付模块下面，他们会好奇，好奇不等于有问题，但好奇会带来追问，追问会带来更多审查。"
　　
　　她合上文件夹，看着林彻。
　　
　　"如果他们在审查过程中注意到AbySS的数据接口……"