首富从入职阿里开始薅羊毛 第403章 来函！

第403章来函！(第1/2页)

十月的第一个工作日，林彻桌上多了一份文件。

不是邮件，是纸质件，牛皮纸信封，A4大小，左上角印着红色的国徽，下面一行字：“人民银行数字货币研究所“。

信封右下角贴了一张编号条，手写的收件人：“微光科技（杭州）有限公司·林彻先生“。

沈南送过来的。

她早上九点到办公室的时候信封已经在前台了，前台签收的时间是八点四十七分，快递单上的发件地是北京西城区金融街。

林彻拆开信封。

里面两份文件。

第一份是正式函件，A4纸，两页，抬头是人民银行数字货币研究所，编号DCEP-2021-TF-0047。

第二份是附件，技术要求清单，八页。

他先看函件。

…………

函件的内容很正式，措辞是标准的公函体。核心信息在第一段的后半部分：

“……经研究所技术评审委员会初步遴选，现邀请以下四家机构参与数字人民币（DCEP）技术服务商选拔流程：工商银行股份有限公司、建设银行股份有限公司、人民银行股份有限公司、微光科技（杭州）有限公司。“

四家，三家国有大行，一家民企。

工行、建行、中行，加上微光。

函件第二段说明了选拔流程：第一阶段为技术方案提交与远程沟通会，第二阶段为现场答辩与技术评审，第三阶段为实战测试（具体方案另行通知）。

时间节点写得很清楚，第一阶段的截止日期是十一月十五日，第二阶段预计在十二月上旬，第三阶段预计在2022年一月。

2022年一月。

他的目光在这个日期上停了一下。

2022年二月，北京冬奥会开幕。

数字人民币是冬奥会的重点推广项目，这件事上辈子是公开信息，不需要先知能力也知道。

但具体的技术选型时间线，四家候选的名单，以及“实战测试“这个说法，都是这辈子才有的信息。

冬奥是决战场。

不是PPT选型，不是会议室答辩，是实战。

在冬奥的真实场景里跑，跑出来的数据说了算。

上辈子冬奥的数字人民币试点覆盖了北京和张家口两个赛区，核心支付场景包括交通、餐饮、购物、住宿。

冬奥村里的便利店、食堂、纪念品商店全部接入了数字人民币支付。

张家口赛区的崇礼，那个小镇上的餐馆和超市也接了。

外国运动员和记者用数字人民币买东西的画面上了全球新闻。

试点的参与机构以国有大行为主，但技术方案的底层实现一直是个模糊地带，官方从来没有公开过技术服务商的名单。

上辈子他只是旁观者，在新闻里看到数字人民币的推广画面，不知道底层是谁在做。

这辈子不一样了。

微光拿到了函件。

四家之一。

唯一的民企。

他看了一眼函件上“实战测试“四个字。

央行不打算在会议室里选。

他们要在冬奥的真实场景里看到东西跑起来。

这对大行来说是主场，对微光来说也不是客场。

247城的物流网络，8.2万个终端节点，微光的C端触达能力不是PPT上的数字，是每天在跑的87万单。

区别在于：大行知道冬奥重要，但他们不知道冬奥有多重要。

他们把这当成一个项目，他知道这是一个窗口。

窗口错过了就关了。

函件最后一段是标准的保密条款和联系方式。

他合上了函件。

…………

翻开技术要求清单。

八页，分四个板块：基础架构要求、安全合规要求、性能指标要求、生态覆盖要求。

前三个板块他快速扫了一遍，内容不意外。

基础架构要求的核心是央行数字货币的双层运营体系，第一层是央行发行和回笼，第二层是运营机构面向公众提供兑换和流通服务。

（本章未完，请点击下一页继续阅读）第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的数据接口……“