逸薯云（YiShuIT）实名认证协议
【重要提示与导读】
本协议说明您在申请实名认证时与平台之间的相关权利义务。请结合申请页面展示的认证方式、服务费用及个人信息处理告知一并阅读本协议；涉及具体认证方式的说明，仅在该方式实际提供时适用。
请在提交认证信息前阅读完整文本，特别留意涉及个人信息处理、敏感个人信息、责任、账户处置及争议解决等重大利害关系事项的条款。平台应依法以合理方式提示，并根据要求说明相关格式条款。您可以选择是否提出认证申请；依法必须核验真实身份的服务，未完成适用的核验可能无法使用。您依法享有的个人信息权益和救济权利不因选择是否申请认证而受限制。
文中法律名称和链接供查阅；如法律法规调整，以现行有效的规定及其适用范围为准。
第一章 前言、定义与协议构成
一、前言
本协议适用于您通过平台实际开放的入口申请实名认证的事项。具体认证类型、可使用的服务与处理方式，以申请时的页面说明、依法适用的规则和实际操作为准。
平台依据《中华人民共和国网络安全法》第二十六条、《中华人民共和国个人信息保护法》、《互联网用户账号信息管理规定》第九条及其他适用法律法规开展实名认证，用户理解并配合平台履行前述法定义务。
二、协议构成与效力
重点提示： 本协议应与适用的《逸薯云（YiShuIT）用户服务协议》《逸薯云（YiShuIT）隐私政策》共同阅读。各文件的适用关系应结合具体事项、实际展示及法律规定判断；本协议不排除用户法定权利，也不因概括表述扩大个人信息处理范围。对本协议的接受及其法律效果，应依据《中华人民共和国网络安全法》及相关法律和实际操作记录判断；仅浏览或下载本协议不表示已提出认证申请或作出特定个人信息处理同意。
三、定义
- 用户：指申请或已完成届时开放的实名认证的自然人；法人及非法人组织仅在相应认证入口实际开放并适用相关规则时纳入本协议所述范围。
- 平台：指届时实际提供实名认证服务的逸薯云运营主体及其实际开放的认证入口。
- 实名认证：指依据实际开放的流程核对用户身份信息并形成认证结果的过程。当前个人认证入口与未来可能开放的企业、商户或分级认证应分别以实际页面和适用规则确认；术语列举不表示相关类型或等级现已开放。
- 身份信息：指实际认证流程依法告知并处理的身份资料。当前个人入口涉及姓名、证件号码等信息；证件影像、人脸、活体数据或组织资料仅在相应方式实际开放、确有必要且依法履行告知和同意等条件时适用。
- 敏感个人信息：指一旦泄露或非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息，本协议中主要指身份证件号码、人脸等生物识别信息，其处理适用《个人信息保护法》第二十八条至第三十条关于敏感个人信息的特别规则。
- 认证服务提供方（受托方）：指实际参与身份核验的第三方。其与平台之间是受托处理、独立处理还是其他关系，应以真实合同、数据流和适用法律确定，不能仅由本协议使用的名称推定。
- 账号：指用户用于访问平台服务的账户。认证通过后，认证结果与对应账户建立关联；具体账户数量和关联方式以届时实际规则为准。
补充说明：怎样核对适用的文本
同一用户可能在不同时间看到不同的协议页面。判断某次申请适用哪一份文本，应先确定申请发生的时间、当时展示的版本、认证入口和实际进行的确认操作，再核对是否有依法需要另行展示的个人信息告知。页面上的链接、标题和版本号可以帮助定位文本，却不能单独证明用户已经看到全部重大条款，也不能替代对展示过程的核实。
例如，用户先在资料页面阅读旧版说明，数日后才从移动端发起申请，后来又在第三方页面完成核验。这三个节点涉及的平台协议、敏感信息同意和第三方告知可能各有独立的展示记录。复核争议时，应按节点分别确认文本与处理者，而不是把最后一次认证成功概括为对之前所有页面、所有用途的追认。
如果本协议与用户服务协议、隐私政策对同一事项的表述看似不同，需要辨认它们分别处理的是账户服务、一般信息处理还是本次身份核验，并结合实际展示和有效约定解释。未向用户实际展示的其他文件、内部操作手册及文中例子，不能自行扩大用户已经接受的具体条款。这个核对方法用于理解证据和文本关系，不预设任何争议的法律结论。
用户在一个页面阅读条款、在另一个页面提交资料时，应以提出申请时实际展示并适用的文本和操作记录判断约定内容。页面目录、条款摘要与问答帮助查找，但不能替代完整条款；对重大利害关系条款，平台仍须依法作合理提示并按要求说明。若不同页面对同一身份资料的用途表述不同，平台应先查明真实处理流程并及时纠正不一致的告知，不能选择对平台最有利的片段要求用户承担额外义务。
本章情境释义（不新增权利义务）
以下情境围绕协议的适用与解释说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
仅浏览协议
适用事实。以“仅浏览协议”为例，应先明确没有提交认证申请，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“仅浏览协议”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“没有提交认证申请”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对仅浏览协议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“仅浏览协议”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“没有提交认证申请”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解没有提交认证申请时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
登录后再读
适用事实。以“登录后再读”为例，应先明确登录行为与认证同意分开，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“登录后再读”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“登录行为与认证同意分开”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对登录后再读，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“登录后再读”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“登录行为与认证同意分开”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解登录行为与认证同意分开时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
从订单页跳转
适用事实。以“从订单页跳转”为例，应先明确订单规则与实名规则各有范围，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“从订单页跳转”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“订单规则与实名规则各有范围”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对从订单页跳转，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“从订单页跳转”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“订单规则与实名规则各有范围”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解订单规则与实名规则各有范围时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
同一词语不同文件
适用事实。以“同一词语不同文件”为例，应先明确结合具体事项和用户法定权利解释，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“同一词语不同文件”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“结合具体事项和用户法定权利解释”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对同一词语不同文件，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“同一词语不同文件”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“结合具体事项和用户法定权利解释”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解结合具体事项和用户法定权利解释时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
历史版本差异
适用事实。以“历史版本差异”为例，应先明确以当时有效文本与实际同意为线索，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“历史版本差异”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“以当时有效文本与实际同意为线索”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对历史版本差异，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“历史版本差异”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“以当时有效文本与实际同意为线索”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以当时有效文本与实际同意为线索时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
他人代为阅读
适用事实。以“他人代为阅读”为例，应先明确阅读者不当然有权替本人同意，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“他人代为阅读”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“阅读者不当然有权替本人同意”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对他人代为阅读，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“他人代为阅读”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“阅读者不当然有权替本人同意”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解阅读者不当然有权替本人同意时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
理解条款有疑问
适用事实。以“理解条款有疑问”为例，应先明确先通过官方渠道寻求说明，再从现行实名认证条款与用户服务协议、隐私政策共同阅读这一原则出发理解本章关于协议的适用与解释的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“理解条款有疑问”这一情境中，需要分辨的是用户实际看到的协议版本、认证入口与操作时间，并核对“先通过官方渠道寻求说明”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕用户实际看到的协议版本、认证入口与操作时间说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对理解条款有疑问，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合是否存在有效的明确同意及相应身份核验这一相关事项，决定是否核对适用版本并请求条款说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“理解条款有疑问”时，应以现行实名认证条款与用户服务协议、隐私政策共同阅读为出发点，核对用户实际看到的协议版本、认证入口与操作时间及其他可核实的记录，再结合“先通过官方渠道寻求说明”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先通过官方渠道寻求说明时，应同时守住本章边界：仅浏览或登录不表示已提出认证申请。
第二章 适用范围与认证目的
一、适用范围
重点提示： 本协议适用于用户通过实际开放的入口申请、办理、变更或注销实名认证及与之直接相关的活动。对于依法律法规或已公示业务规则要求先完成实名认证的具体功能，平台可在相应范围内设置认证条件；未完成认证可能影响该功能的使用。注册账户及使用无需实名的功能，不因本章的概括列举而当然被设为实名认证前置事项。
二、认证目的与法律依据
平台开展实名认证，目的在于：核验用户身份真实性，履行网络运营者的法定实名管理义务；防范虚假注册、身份冒用、欺诈交易、电信网络诈骗及违法违规内容传播，保护平台、商户及其他用户的合法权益；在发生纠纷、投诉或依法配合监管、司法机关调查时，为责任认定与主体追溯提供必要依据。上述目的具有正当性，法律依据包括《网络安全法》第二十六条、《反电信网络诈骗法》第二十一条及《互联网用户账号信息管理规定》第九条。平台遵循"最小必要"与"目的限定"原则，仅在实现上述目的之必要范围内处理用户信息，符合《个人信息保护法》第五条、第六条确立的处理原则。
补充说明：确认具体功能是否需要认证
“使用平台”包含浏览、管理账户、购买或转让资源等不同活动。某项功能需要实名认证，应能对应到适用法律、实际业务风险或已经公示的规则，并在使用该功能前向用户说明。不能从某个交易环节需要核验，直接推出所有浏览、咨询或其他无需实名的基础活动都须先完成同等程度的核验。
在同一笔交易中，账号持有人、下单人、付款人和最终使用人可能不是同一主体。身份核验回答的是某个申请人与某份身份资料是否匹配，不当然解决付款授权、资源权属、合同履行或第三人行为的所有问题。出现主体不一致时，应先查明该功能实际要求核验哪一方、依据何种已展示规则，以及相关异常是否真实影响当前交易，再讨论可采取的处理措施。
如果某个认证入口后来增加了新的方式或认证等级，旧申请的结果能否继续用于新功能，应结合新增功能的目的、原告知范围和实际技术能力分别判断。认证结果也不是永久有效的资格证明；信息变更、证件失效或有合理疑点时可以依法依规则复核，但复核范围仍应与当前问题相称。本节只提供功能范围的阅读方法，不承诺已开放额外等级。
认证是否为某项功能的必要条件，应先确定该功能实际提供什么服务、适用哪一项法律要求，以及能否通过已取得的可靠身份资料完成核验。平台如果因未认证而限制具体功能，应说明受影响的功能和完成核验的实际路径。用户先前使用过其他功能，不意味着所有后续功能都可以免于身份核验；同样，一次认证成功也不意味着平台可以把身份资料用于与该次核验无关的业务目的。
本章情境释义（不新增权利义务）
以下情境围绕认证适用范围与目的说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
注册与使用不同
适用事实。以“注册与使用不同”为例，应先明确注册不等于所有功能均需实名，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“注册与使用不同”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“注册不等于所有功能均需实名”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对注册与使用不同，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“注册与使用不同”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“注册不等于所有功能均需实名”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解注册不等于所有功能均需实名时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
购买前核验
适用事实。以“购买前核验”为例，应先明确只有适用规则要求时才成为前置条件，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“购买前核验”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“只有适用规则要求时才成为前置条件”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对购买前核验，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“购买前核验”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“只有适用规则要求时才成为前置条件”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解只有适用规则要求时才成为前置条件时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
已经认证
适用事实。以“已经认证”为例，应先明确再次核验应有具体合理原因，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“已经认证”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“再次核验应有具体合理原因”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对已经认证，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“已经认证”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“再次核验应有具体合理原因”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解再次核验应有具体合理原因时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
功能后来变化
适用事实。以“功能后来变化”为例，应先明确新要求应依规则提示，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“功能后来变化”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“新要求应依规则提示”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对功能后来变化，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“功能后来变化”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“新要求应依规则提示”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解新要求应依规则提示时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
认证未完成
适用事实。以“认证未完成”为例，应先明确只影响依赖实名结果的功能，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“认证未完成”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“只影响依赖实名结果的功能”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对认证未完成，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“认证未完成”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“只影响依赖实名结果的功能”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解只影响依赖实名结果的功能时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
交易发生争议
适用事实。以“交易发生争议”为例，应先明确身份记录只作责任核查线索，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“交易发生争议”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“身份记录只作责任核查线索”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对交易发生争议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“交易发生争议”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“身份记录只作责任核查线索”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解身份记录只作责任核查线索时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
监管要求变化
适用事实。以“监管要求变化”为例，应先明确以有效要求和实际通知为准，再从身份核验服务只为真实身份确认及直接相关的合规安全目的这一原则出发理解本章关于认证适用范围与目的的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“监管要求变化”这一情境中，需要分辨的是具体功能是否依法或按已公示规则以实名为前提，并核对“以有效要求和实际通知为准”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能是否依法或按已公示规则以实名为前提说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对监管要求变化，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在对应功能中提供必要信息或选择不申请这一相关事项，决定是否确认对应功能的实名认证条件。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“监管要求变化”时，应以身份核验服务只为真实身份确认及直接相关的合规安全目的为出发点，核对具体功能是否依法或按已公示规则以实名为前提及其他可核实的记录，再结合“以有效要求和实际通知为准”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以有效要求和实际通知为准时，应同时守住本章边界：不需实名的基础功能不因拒绝本项申请当然关闭。
第三章 用户主体资格与义务
一、用户资格
重点提示： 申请人应符合实际认证入口公示的主体资格条件。当前个人认证的默认最低年龄由系统设置确定，现有默认值为十八周岁；本章有关未成年人保护的说明不表示已开放未成年人认证。若平台正式开放企业、个体工商户或其他组织认证，经办人的身份、授权范围和提交方式应由实际流程说明，并依法核对。未经开放的组织认证不得以个人入口替代；经办行为的法律后果须结合真实授权及适用法律判断。
二、账户绑定与唯一性
个人认证通过后，认证结果与申请账户关联。当前同一证件的默认可认证账户数为一个，但该数值受实际系统设置和适用规则约束，不表示对未来业务方式作永久承诺。若出现虚构、冒用等疑点，平台应先核对具体账户与行为的关联及证据，再依据适用法律和已公示规则决定是否处理有关账户；不能仅凭同一身份资料推定其他账户违规或自动连带处置。
三、真实性义务
申请人应如实提交实际页面要求且与认证目的有关的信息。当前个人入口以姓名、证件号码等实际字段为准；证件影像、组织资料、人脸识别或活体检测不因本章列举而成为当前个人入口的必交材料。确需补充核验的，应说明具体疑点、必要范围、适用的处理规则及可行的申诉方式，并以实际开放的核验能力为限。
四、禁止行为及后果
重点提示： 您不得实施下列行为：使用虚假、伪造、变造的身份信息；冒用、借用、盗用他人身份信息完成认证；拒绝、拖延或规避平台合理的核验要求；以任何技术手段干扰、破坏认证流程或伪造核验结果。上述行为同时违反《互联网用户账号信息管理规定》第九条与《反电信网络诈骗法》第二十一条。若您存在前述任一情形，或经核验发现认证信息与实际不符，平台有权立即中止或终止向您提供服务，并视情节采取拒绝认证、暂停功能、依法限制交易或处置账户等措施。因上述行为给平台、其他用户或任何第三方造成损失的，您应依法承担赔偿责任；涉嫌违法犯罪的，平台有权依法向有关部门报告并提供相关记录。对于借用、盗用身份或越权认证造成的损失，平台在已尽合理审核义务且不存在依法应承担责任的自身过错时，不承担超出法律规定范围的责任。
五、信息更新义务
当您的认证信息发生变更（包括证件有效期届满、企业名称或法定代表人变更、授权关系终止等）时，您应在变更之日起及时通过平台指定方式办理更新，确保绑定信息持续真实、有效。若您未及时更新致使认证信息失效、不符或产生歧义，平台有权暂停相关账户功能直至信息更新完成。平台可根据法律法规要求或风险控制需要，定期或不定期要求您重新核验或更新认证信息。
申请未成功时先确认是哪一步
未能完成实名认证，并不总是同一个原因。用户和平台都可以按实际出现的页面信息定位环节，再决定是修正输入、等待结果、核对已有账号，还是提出身份被冒用的异议。下列顺序解释现有流程中可能遇到的问题，不保证每一类情况都有自动重试按钮。
- 提交前校验：姓名为空、身份证号码格式不符或服务商尚未选定，属于输入与页面条件问题。用户可以核对本人资料和当前可选服务；平台不能把这类错误写成第三方已经拒绝认证，也不应引导用户填报不真实的号码以绕过校验。
- 年龄或账号数条件：后台按实际设置检查最低年龄和同一证件可关联账号数。提示可能反映本人既有账号，也可能需要调查错误关联；仅凭达到默认阈值不能证明用户故意批量注册。若设置后来调整，应以本次申请发生时的规则和记录核对。
- 订单或会话阶段：已形成订单但未取得核验会话、已打开服务商页面但未提交资料、服务商结果尚未返回，是三个不同状态。用户应避免把同一次申请反复付费；平台核查时应对应订单与会话记录，而不是以页面暂时没有结果作最终结论。
- 已有认证与身份争议：系统显示同一证件已有认证时，应先确认是否属于用户本人控制的账户。若有冒用线索，应通过现有申诉渠道核实并保护相关资料，不能要求用户直接取得他人账户的敏感信息来证明自己身份。
- 结果形成以后：拒绝、技术失败和通过后又遭账户限制，分别需要核对服务商结果、系统异常或其他规则。用户可围绕具体申请提出异议；平台应避免把所有后续服务问题都解释为证件号码不正确。
补充说明：同一证件关联与信息更正
当前系统对最低认证年龄和同一证件可关联账号数设有可调整的配置，默认值分别为十八周岁和一个账号。默认值说明当前实现的起点，并不表示所有用户、所有时期都适用固定不变的数量，也不表示达到年龄条件即可自动通过核验。申请是否被接受，还取决于证件格式、身份匹配、服务商状态以及该次申请的实际结果。
用户遇到“证件已被使用”之类提示时，可能涉及本人既有账号、资料填写错误、此前申请尚未处理完毕，或存在身份被冒用的疑点。单靠报错文字不能判断原因，更不能把关联账号一概视为违规。核对时应分别看当前申请、已有认证记录与账户控制情况，并采取与疑点相称的核验和纠错方式；不应要求用户为了绕过限制而借用他人证件或重复注册。
姓名或证件号码确需更正时，重点是区分录入错误、合法更名、证件更新与账户归属变更。前几种情况可能需要核实同一自然人的连续性，后一种情况则可能涉及完全不同主体，不能用简单修改字段的方式推定完成。现有页面是否支持自助修改，应以实际功能为准；对无法自行处理的情形，用户可按现有客服和申诉渠道说明问题，处理时间与结果应依据实际情况和适用法律确定。
申请人发现姓名、证件号码或账户归属与本人不符时，应停止使用错误资料继续申请，并通过实际公示的渠道说明是录入错误、证件更新还是疑似冒用。平台核对时应尽量利用已有的申请记录和必要线索，避免要求无关的亲属、同事或经办人提供其完整证件信息。核对过程中若涉及另一个账户持有人，平台还应注意分别保护两人的资料，不宜把对方的姓名、证件号码或联系方式直接披露给投诉人。
本章情境释义（不新增权利义务）
以下情境围绕主体资格与真实身份说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
证件姓名变更
适用事实。以“证件姓名变更”为例，应先明确旧记录与新证明需要核对，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“证件姓名变更”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“旧记录与新证明需要核对”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对证件姓名变更，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“证件姓名变更”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“旧记录与新证明需要核对”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解旧记录与新证明需要核对时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
身份证号录错
适用事实。以“身份证号录错”为例，应先明确不能以简单修改替代重新核验，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“身份证号录错”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“不能以简单修改替代重新核验”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对身份证号录错，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“身份证号录错”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“不能以简单修改替代重新核验”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能以简单修改替代重新核验时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
同一身份多账号
适用事实。以“同一身份多账号”为例，应先明确须结合已公示限额与例外，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“同一身份多账号”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“须结合已公示限额与例外”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对同一身份多账号，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“同一身份多账号”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“须结合已公示限额与例外”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解须结合已公示限额与例外时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
朋友借用账号
适用事实。以“朋友借用账号”为例，应先明确实名信息不能证明朋友有使用权，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“朋友借用账号”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“实名信息不能证明朋友有使用权”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对朋友借用账号，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“朋友借用账号”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“实名信息不能证明朋友有使用权”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解实名信息不能证明朋友有使用权时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
企业员工操作
适用事实。以“企业员工操作”为例，应先明确经办权限需要组织授权，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“企业员工操作”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“经办权限需要组织授权”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对企业员工操作，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“企业员工操作”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“经办权限需要组织授权”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解经办权限需要组织授权时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
证件届满
适用事实。以“证件届满”为例，应先明确应核实有效证明与更新路径，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“证件届满”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“应核实有效证明与更新路径”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对证件届满，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“证件届满”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“应核实有效证明与更新路径”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应核实有效证明与更新路径时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
发现冒用
适用事实。以“发现冒用”为例，应先明确本人可提交证据请求核查，再从认证主体、账号持有人和实际操作人应有真实对应关系这一原则出发理解本章关于主体资格与真实身份的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“发现冒用”这一情境中，需要分辨的是姓名、证件与账号关系及届时开放的认证资格，并核对“本人可提交证据请求核查”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕姓名、证件与账号关系及届时开放的认证资格说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对发现冒用，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合本人提交真实资料，组织经办人另须有合法授权这一相关事项，决定是否核查本人或授权主体的认证资格。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“发现冒用”时，应以认证主体、账号持有人和实际操作人应有真实对应关系为出发点，核对姓名、证件与账号关系及届时开放的认证资格及其他可核实的记录，再结合“本人可提交证据请求核查”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解本人可提交证据请求核查时，应同时守住本章边界：监护或代表关系不能由普通账号登录自动推定。
第四章 个人信息收集与处理授权
一、授权说明与适用范围
重点提示： 用户对本协议作出的明确接受，以及其对相关个人信息处理另行作出的有效同意，须分别依实际展示、操作记录和适用法律判断；单纯勾选或提交不当然证明用户已充分理解全部条款，也不替代敏感个人信息依法要求的单独同意。平台仅在已告知的实名认证目的及与之直接相关的必要范围内处理信息；超出原处理目的或范围时，须另行满足适用的告知、同意或其他合法处理条件。
二、收集的个人信息范围
重点提示：当前个人入口实际收集的字段，应以页面及隐私告知为准。下列其他类别仅用于说明相应认证方式将来实际开放时可能涉及的范围，不构成现行收集清单或新增授权：
- 个人用户：当前个人入口主要核对姓名和实际支持的证件号码；其他证件类型或手机号码是否作为认证字段，应以实际页面、数据流与适用告知为准。
- 人脸核身场景：人脸图像及活体检测数据，用于比对确认操作人为本人。
- 特定资质核验场景：相关证书、执业资质或授权文件。
- 企业及组织用户：营业执照、统一社会信用代码、法定代表人身份信息、经办人身份信息及授权证明文件。
我们仅收集实现认证目的所必需的最少信息，符合《个人信息保护法》第六条的最小必要原则。
三、收集目的与必要性
实际收集的必要信息用于核对申请人身份、维护认证及账户安全，并在适用法律要求下配合有关机关的合法核查。列举的条件性类别不能一概视为每次认证的必需项；是否缺少某一项即无法核验，应按该次实际开放的认证方式判断。我们依据《个人信息保护法》第十七条向您告知处理者身份、处理目的、方式、信息种类、保存期限及您行使权利的方式。
四、敏感个人信息的单独同意
重点提示： 您的证件号码以及认证流程中可能涉及的人脸图像、活体检测数据属于敏感个人信息。依据《个人信息保护法》第二十八条、第二十九条、第三十条，处理此类信息时，相应个人信息处理者须依法告知处理目的、方式、必要性及对个人权益的影响，并在依法需要时取得单独同意。本平台当前认证页面不采集人脸或活体信息；如认证流程跳转至第三方核验服务页面，实际处理者、告知及同意方式须按该页面和真实数据流另行核对。本协议的接受不能代替依法需要取得的单独同意。
五、拒绝授权的后果与信息准确性
重点提示： 实名认证信息为提供本服务所必需。若您拒绝提供必要信息或撤回相关授权，我们将无法为您完成实名核验，您可能无法使用依赖实名结果的功能或服务，但这不影响您使用无需实名的其他基础功能。撤回同意不影响撤回前基于您同意已进行处理的效力。请您确保所提交信息真实、准确、完整、有效；因您提供的信息不实、过期或错误导致认证失败或产生的相应后果，由您自行承担。
办理过程中的信息边界示例
为了避免把整个流程写成一次不加区分的“收集”，理解本次认证时可以按下列节点核对。每一项都要以实际页面、接口和服务商约定为准；节点说明只帮助理解本章既有处理范围，不额外授权采集或保存。
- 填写前：用户应能看到当前入口要求的资料和用途。若页面仅要求姓名、证件号码与服务商选择，协议中关于证件影像、银行卡或人脸的举例不能让用户误以为这些资料已经由平台直接收取；未来增加字段时，也应重新核对必要性和对应告知。
- 提交时：输入格式错误、年龄配置限制及同一证件账号数限制，可能在取得第三方核验结果之前就影响申请。此类校验反映的是该次申请能否进入流程，不等于服务商已确认身份不实，更不说明平台已经对用户作出违规处罚。
- 跳转后：服务商页面若要求扫描证件或拍摄人脸，应另看其真实收集者和处理规则。平台传出的字段、服务商返回的结果、用户在第三方页面主动提交的素材，不能混写为一个无边界的数据包；尤其不能从“页面可跳转”推定平台有权查看全部原始资料。
- 返回结果后：认证通过、失败、拒绝和仍在等待，可能对应不同后续操作。业务功能需要的通常是经过确认的身份状态或必要关联，是否继续使用原始输入和会话记录，应分别有处理目的与保存基础；本节不保证某种资料在结果形成后立即删除。
- 再次核验时：用户换设备、资料变化或出现合理疑点，可能需要新的核对。应先识别旧结果是否仍可用、变化是否涉及同一自然人以及追加处理所需的最少资料，避免把历史申请中取得的同意直接扩展到新目的或新服务商。
补充说明：按实际数据流阅读收集清单
当前个人申请表单要求填写姓名、证件号码并选择认证服务商；这些输入字段与认证过程中可能由第三方页面采集的影像、生物识别信息，属于不同页面和不同处理环节。阅读收集条款时，应辨认信息是由平台直接接收、仅传给服务商核验、由第三方独立收集，还是仅在结果中返回。不能因为协议列举了某类资料，就推定平台目前已经取得该类资料的原件或可以用于其他目的。
对于同一字段，还要区分提交、校验、展示和留存四种动作。例如证件号码可能用于格式校验与身份匹配，页面再次展示时可以按实际安全设计进行遮掩；核验结论可能只需要记录状态，而不必把第三方原始材料复制到每个业务模块。上述区分有助于审查必要性，并不宣称当前系统已经采用了某一种特定脱敏或删除方案。
个人信息处理范围应与申请页面、隐私政策及实际数据流一致；如有差异，平台应及时核查并依法完善告知。敏感个人信息的单独同意需要针对真实处理者、目的和方式判断；一份笼统的协议接受记录不能自动替代所有后续页面的同意。拒绝某项额外处理后的功能影响，也只能根据该项处理对具体认证方式是否必要来说明。
在现有个人认证入口，申请页面提交的姓名、居民身份证号码和所选服务商，是判断本次申请资料范围的起点。订单标识、核验会话和最终状态分别服务于支付、流程衔接和结果记录；某个系统字段存在，不代表每次申请都需要将其传给所有第三方。平台应使告知与实际传输范围一致。若核验方式改变并需要新增证件影像、生物识别或其他敏感资料，应先明确必要性、实际处理者及对权益的影响，再依法律完成相应告知与同意。
本章情境释义（不新增权利义务）
以下情境围绕个人信息与敏感信息说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
填写姓名
适用事实。以“填写姓名”为例，应先明确仅用于核验对应身份，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“填写姓名”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“仅用于核验对应身份”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对填写姓名，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“填写姓名”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“仅用于核验对应身份”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅用于核验对应身份时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
提交证件号码
适用事实。以“提交证件号码”为例，应先明确应说明敏感性与必要性，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“提交证件号码”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“应说明敏感性与必要性”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对提交证件号码，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“提交证件号码”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“应说明敏感性与必要性”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应说明敏感性与必要性时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
页面没有相机
适用事实。以“页面没有相机”为例，应先明确不能推定平台采集了人脸，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“页面没有相机”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“不能推定平台采集了人脸”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对页面没有相机，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“页面没有相机”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“不能推定平台采集了人脸”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能推定平台采集了人脸时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
跳转服务商页面
适用事实。以“跳转服务商页面”为例，应先明确由实际处理者完成适用告知，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“跳转服务商页面”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“由实际处理者完成适用告知”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对跳转服务商页面，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“跳转服务商页面”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“由实际处理者完成适用告知”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解由实际处理者完成适用告知时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
要求额外文件
适用事实。以“要求额外文件”为例，应先明确需核实目的与必要性，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“要求额外文件”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“需核实目的与必要性”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对要求额外文件，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“要求额外文件”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“需核实目的与必要性”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需核实目的与必要性时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
拒绝非必要信息
适用事实。以“拒绝非必要信息”为例，应先明确不应扩大拒绝后果，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“拒绝非必要信息”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“不应扩大拒绝后果”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对拒绝非必要信息，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“拒绝非必要信息”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“不应扩大拒绝后果”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不应扩大拒绝后果时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
申请更正数据
适用事实。以“申请更正数据”为例，应先明确核心身份字段需重新核验，再从个人信息仅在认证及直接相关合规、风控、安全范围内处理这一原则出发理解本章关于个人信息与敏感信息的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“申请更正数据”这一情境中，需要分辨的是当前申请实际要求的姓名、证件号码及服务商选择，并核对“核心身份字段需重新核验”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕当前申请实际要求的姓名、证件号码及服务商选择说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对申请更正数据，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在处理敏感信息前获得独立、明确的告知与同意这一相关事项，决定是否提交当前确有必要的信息。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“申请更正数据”时，应以个人信息仅在认证及直接相关合规、风控、安全范围内处理为出发点，核对当前申请实际要求的姓名、证件号码及服务商选择及其他可核实的记录，再结合“核心身份字段需重新核验”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核心身份字段需重新核验时，应同时守住本章边界：列举可能方式不表示当前页面正在收集人脸或银行卡资料。
第五章 第三方核验服务与委托处理
一、第三方认证服务的接入
平台在实际开放的实名认证流程中可能使用第三方身份核验服务。当前个人入口的申请资料以页面要求为准；平台向服务商传输的字段、服务商直接向用户取得的资料和返回平台的结果，应按实际数据流分别说明。运营商、银行卡、电子签名、企业登记或人脸核验等方式，仅在相应入口实际提供并完成依法适用的告知与同意后涉及本协议相关条款。服务商是否受平台委托或独立决定处理目的和方式，应依据真实合同与处理活动判断，不能一概认定为独立处理者。
二、数据共享与委托处理
重点提示： 在向第三方认证服务机构传输信息时，本平台将采取加密传输、最小必要、字段脱敏等措施，仅共享完成核验所必需的信息字段。对于受本平台委托、代为处理认证数据的处理者，本平台将依据《个人信息保护法》关于委托处理的规定，与其签订书面协议，明确处理目的、期限、方式、信息类型及安全保护义务，要求其不得超出约定范围处理，并在委托关系结束后按约定删除或返还相关数据。本平台将对受托方的数据处理活动进行监督。
三、您的授权与免责说明
重点提示： 平台仅可依实际认证目的、必要范围和合法处理基础向第三方提供信息；向其他独立个人信息处理者提供资料时，应依法告知接收方、用途、方式和信息类别，并取得依法需要的单独同意。本协议不能概括授权传输用户未提交的手机号码、人像、银行卡或企业资料。核验结果可能因数据源延迟、录入错误或服务中断而异常；平台应结合具体事实提供适用的核查与纠错途径，并依法承担自身责任。对认证申请采取补正、重新核验或拒绝等措施，须依据实际疑点、有效规则和适用法律判断。
服务商会话、订单与结果的关系
当前认证流程可能先选择服务商，再按实际配置形成免费申请或付费订单，随后取得会话与核验结果。各环节的状态应分开看，尤其不能因为出现一个订单编号或跳转地址，就推定认证已经完成。用户遇到页面不一致时，可以围绕以下事实请求核对，而无需公开完整证件号码。
- 服务商可用性：页面展示了某个服务商，并不保证其在每一时刻都能接收请求。发起前后服务商配置若发生变化，应确认本次申请绑定的是哪个可用服务，而不是把后续新展示的选项追溯适用于旧订单。
- 订单状态：实际金额及支付要求以页面和订单为准；订单创建、支付完成与认证通过是不同事实。若申请未继续，应核对支付和退款所依赖的真实规则，不把“认证失败”概括为一律退款或一律不退。
- 核验会话：跳转链接、二维码或会话令牌服务于特定申请，失效或关闭后可能需要查询当前状态。用户不应把含有会话信息的完整链接张贴到公开求助页面；平台也不应将一次会话超时解释为永久禁止重新申请。
- 返回结果：服务商可能返回待处理、通过、拒绝或技术失败等状态。平台记录何时更新、用户页面何时刷新和服务商形成结论的时间可能不同；处理争议时应把时间线对齐，避免对同一申请出现前后矛盾的解释。
- 复核与纠错：如果服务商结果和用户提供的事实冲突，应先核实结果属于哪次申请、是否被重复或延迟返回，再决定能否按实际渠道复核。平台不能以合同中的概括免责文字，预先排除自己对展示、传输或后续账户决定依法应承担的责任。
补充说明：区分平台与核验服务商的角色
用户从平台页面跳转到核验服务商页面，看到的仍可能是一项连续的认证流程，但不同页面的个人信息处理者未必相同。判断平台与服务商的关系，应查看谁决定收集目的和方式、谁保存原始资料、谁仅按指令处理以及谁向用户提供告知和权利行使入口。页面上写有“第三方”或“受托方”字样，并不能代替合同和实际数据流的判断。
如服务商只返回通过、拒绝或待处理等结果，平台对这些结果的使用仍须限于已告知且与认证直接相关的范围。若服务商另行要求拍摄证件或人脸，相关页面应依法说明采集者、用途、必要性、保存与退出方式；平台不能以本协议概括确认服务商已履行全部义务。用户在第三方页面遇到错误时，可保留页面时间、订单或会话线索以便核对，但不宜在公开渠道张贴完整证件信息。
第三方超时、页面关闭、核验拒绝和平台账户受限不是同一事件。前者可能只意味着本次会话未形成有效结果，后者涉及后续服务使用，不能一概自动串联为处罚。平台若依据服务商结果作出对用户有重要影响的决定，仍需要结合结果来源、有效性、用户说明和适用规则判断，并在必要范围内提供纠错路径。
用户从平台页面跳转至核验服务商页面时，应能区分由平台填写并传输的信息、用户直接向服务商提交的信息，以及服务商返回给平台的结论。若服务商只按平台指令处理，双方应依法约定处理目的、期限、方式和安全措施；若服务商自行决定处理目的或方式，平台向其提供个人信息时还须依法履行相应告知和单独同意要求。服务商是否属于哪一种角色，取决于实际合同与数据流，不能仅凭页面上出现同一品牌或“合作”字样推断。
本章情境释义（不新增权利义务）
以下情境围绕第三方身份核验说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
服务商无法连接
适用事实。以“服务商无法连接”为例，应先明确不等同于用户身份不真实，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务商无法连接”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“不等同于用户身份不真实”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务商无法连接，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务商无法连接”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“不等同于用户身份不真实”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不等同于用户身份不真实时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。服务商无法连接可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
权威记录更新慢
适用事实。以“权威记录更新慢”为例，应先明确可等待更新或提交可核实材料，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“权威记录更新慢”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“可等待更新或提交可核实材料”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对权威记录更新慢，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“权威记录更新慢”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“可等待更新或提交可核实材料”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解可等待更新或提交可核实材料时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。权威记录更新慢的名称只是阅读辅助，真正需要判断的是可等待更新或提交可核实材料如何影响用户在明确告知后选择可用方式并依法作出授权。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
姓名一致号码不符
适用事实。以“姓名一致号码不符”为例，应先明确应先检查录入与数据来源，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“姓名一致号码不符”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“应先检查录入与数据来源”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对姓名一致号码不符，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“姓名一致号码不符”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“应先检查录入与数据来源”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应先检查录入与数据来源时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。第三方身份核验关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。姓名一致号码不符如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
一个服务商拒绝
适用事实。以“一个服务商拒绝”为例，应先明确不自动证明其他方式也失败，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“一个服务商拒绝”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“不自动证明其他方式也失败”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对一个服务商拒绝，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“一个服务商拒绝”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“不自动证明其他方式也失败”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不自动证明其他方式也失败时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。一个服务商拒绝可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第三方转委托
适用事实。以“第三方转委托”为例，应先明确必须分清处理角色与实际范围，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“第三方转委托”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“必须分清处理角色与实际范围”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对第三方转委托，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“第三方转委托”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“必须分清处理角色与实际范围”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解必须分清处理角色与实际范围时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。第三方转委托的名称只是阅读辅助，真正需要判断的是必须分清处理角色与实际范围如何影响用户在明确告知后选择可用方式并依法作出授权。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
页面跳转前
适用事实。以“页面跳转前”为例，应先明确用户应能识别目的和接收方，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“页面跳转前”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“用户应能识别目的和接收方”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对页面跳转前，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“页面跳转前”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“用户应能识别目的和接收方”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解用户应能识别目的和接收方时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。第三方身份核验关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。页面跳转前如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
人工复核申请
适用事实。以“人工复核申请”为例，应先明确以具体矛盾和证据为基础，再从第三方核验结果是认证判断的重要参考而非绝对保证这一原则出发理解本章关于第三方身份核验的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“人工复核申请”这一情境中，需要分辨的是实际启用的服务商、共享字段、处理角色与核验结果，并核对“以具体矛盾和证据为基础”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际启用的服务商、共享字段、处理角色与核验结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对人工复核申请，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户在明确告知后选择可用方式并依法作出授权这一相关事项，决定是否核对实际启用的核验服务。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“人工复核申请”时，应以第三方核验结果是认证判断的重要参考而非绝对保证为出发点，核对实际启用的服务商、共享字段、处理角色与核验结果及其他可核实的记录，再结合“以具体矛盾和证据为基础”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以具体矛盾和证据为基础时，应同时守住本章边界：条款列举的银行卡、运营商或电子签名方案不当然已经开放。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。人工复核申请可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第六章 企业/商户/组织实名认证
本章说明相应认证类型依法开放后的适用原则；当前个人实名认证入口仅提交姓名、证件号码及服务商选择，不应视为已经开放企业、商户或其他组织的认证流程。
一、认证适用对象
重点提示： 本章仅在平台实际开放相应组织认证入口时适用于企业、个体工商户、社会组织及其他依法设立的主体。当前个人实名入口不等于组织认证。平台对实际入驻的平台内经营者的核验与登记，应在适用范围内遵守《中华人民共和国电子商务法》第二十七条的要求；本章不因组织类型列举而承诺已提供商户入驻、结算或组织认证服务。
二、实际开放时可能需要核对的资料
资料类别应按真实入口、主体类型和最少必要原则确定；下列类别不构成当前个人认证入口的提交要求，也不表示平台已开设组织认证服务。
- 营业执照：清晰、完整、在有效期内的营业执照正本或副本影像，信息与实际经营情况一致。依法无需办理营业执照的社会组织或事业单位，可提交登记证书、批准文件等等效证明。
- 统一社会信用代码：有效且与营业执照记载一致，作为主体唯一性核验的主要依据。
- 法定代表人或负责人身份信息：仅在核对代表资格或授权确有必要时，按实际页面及适用法律说明所需的身份资料；不能仅为推定实际控制人或全部责任而概括收集完整证件影像。
- 授权委托书：经办人非法定代表人或负责人本人的，应提交加盖公章或由负责人签署的授权委托书，写明经办人身份及授权范围。
- 受益所有人信息（按需）：行业、业务类型或适用法律法规要求识别受益所有人时，平台可要求补充提供，且不会超出合理范围索取无关资料。
三、材料真实性、持续有效与变更通知
若相应组织认证入口实际开放，申请人应按该入口要求提供真实、准确且与认证目的有关的资料。组织登记信息或经办授权发生影响认证结果的变化时，平台应通过实际页面或公示渠道说明更正方式。未更新资料是否导致认证受限、结算异常或其他损害，应结合具体规则、双方行为与因果关系依法判断，不能概括免除平台自身责任。
四、平台审核裁量与商户便利
如将来正式开放商户认证，审核应以实际开放的材料、必要性和已公示标准为限，并提供依法适用的异议渠道。加速认证、认证标识或交易限额均须依据实际业务能力和有效规则核对；本协议不设商户保证金，也不作为收取、扣留或处置保证金的依据。
补充说明：组织身份与经办人身份不能混同
企业或其他组织的资料、法定代表人的自然人身份、具体经办人的操作权限，是三个需要分别核对的事项。即使某个自然人已经完成个人实名认证，也不能仅据此推定其可以代表某家组织申请、修改或终止组织服务；反过来，组织材料真实也不当然证明提交者得到有效授权。只有在相应组织认证入口实际开放时，具体材料与授权形式才应以正式展示的规则为准。
组织名称、统一社会信用代码或代表人发生变更时，重要的是区分登记信息更新、经办人员替换和账户控制权争议。每类变化影响的对象不同，可能需要采用不同核对资料；平台应按实际认证目的和必要范围说明需要的组织资料。若当前页面只支持自然人证件，用户不应把企业名称填入姓名栏，也不应把经办人个人认证当作已完成组织认证。
发生代表权争议时，平台需要核对实际收到的申请、账户操作历史和适用的公示规则，并避免在事实未清楚前向无权人员披露其他人的敏感资料。是否调整账户权限或暂停特定操作，应结合真实风险、可用技术和法律要求确定。本节仅在相应组织认证入口实际开放时适用，不表示现有产品已提供企业入口、商户绿色通道或专属材料清单。
组织认证同时涉及经营主体和自然人。营业执照说明主体登记，法定代表人或经办人的证件说明个人身份，授权文件说明办理权限；任一材料都不能单独证明其他两个问题。若未来实际开设入口，平台应按具体情形决定是否需要各项资料，并说明材料将由谁处理、用于何种核验和如何提出更正。个人账户下完成过的实名认证，不自动使该账户变成组织账户或使经办人有权处分组织的交易与资金。
本章情境释义（不新增权利义务）
以下情境围绕企业及组织认证说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
企业仅有个人账号
适用事实。以“企业仅有个人账号”为例，应先明确不当然形成企业实名关系，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“企业仅有个人账号”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“不当然形成企业实名关系”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对企业仅有个人账号，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“企业仅有个人账号”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“不当然形成企业实名关系”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不当然形成企业实名关系时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。企业仅有个人账号可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
经办人离职
适用事实。以“经办人离职”为例，应先明确应核实权限是否仍有效，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“经办人离职”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“应核实权限是否仍有效”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对经办人离职，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“经办人离职”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“应核实权限是否仍有效”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应核实权限是否仍有效时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。经办人离职的名称只是阅读辅助，真正需要判断的是应核实权限是否仍有效如何影响组织应由有权代表人或经授权经办人办理。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
执照换发
适用事实。以“执照换发”为例，应先明确更新材料不改变主体历史事实，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“执照换发”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“更新材料不改变主体历史事实”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对执照换发，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“执照换发”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“更新材料不改变主体历史事实”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解更新材料不改变主体历史事实时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。企业及组织认证关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。执照换发如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
法定代表人变更
适用事实。以“法定代表人变更”为例，应先明确需区分主体存续和代表变化，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“法定代表人变更”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“需区分主体存续和代表变化”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对法定代表人变更，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“法定代表人变更”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“需区分主体存续和代表变化”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需区分主体存续和代表变化时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。法定代表人变更可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
个体工商户申请
适用事实。以“个体工商户申请”为例，应先明确以届时实际支持的方式为准，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“个体工商户申请”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“以届时实际支持的方式为准”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对个体工商户申请，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“个体工商户申请”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“以届时实际支持的方式为准”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以届时实际支持的方式为准时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。个体工商户申请的名称只是阅读辅助，真正需要判断的是以届时实际支持的方式为准如何影响组织应由有权代表人或经授权经办人办理。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
授权书存在争议
适用事实。以“授权书存在争议”为例，应先明确不能只凭提交人声明定案，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“授权书存在争议”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“不能只凭提交人声明定案”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对授权书存在争议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“授权书存在争议”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“不能只凭提交人声明定案”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能只凭提交人声明定案时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。企业及组织认证关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。授权书存在争议如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
多员工账户
适用事实。以“多员工账户”为例，应先明确须依正式开放的子账号规则，再从企业与组织规则仅在相应认证能力正式开放并告知时适用这一原则出发理解本章关于企业及组织认证的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“多员工账户”这一情境中，需要分辨的是主体登记文件、经办授权与实际页面可提交的材料，并核对“须依正式开放的子账号规则”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕主体登记文件、经办授权与实际页面可提交的材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对多员工账户，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合组织应由有权代表人或经授权经办人办理这一相关事项，决定是否确认组织认证是否正式开放。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“多员工账户”时，应以企业与组织规则仅在相应认证能力正式开放并告知时适用为出发点，核对主体登记文件、经办授权与实际页面可提交的材料及其他可核实的记录，再结合“须依正式开放的子账号规则”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解须依正式开放的子账号规则时，应同时守住本章边界：当前个人姓名加身份证入口不等于企业认证入口。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。多员工账户可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第七章 平台交易场景中的实名认证
一、交易主体核验与资金安全
在实际开放的交易功能中，实名认证结果可以作为核对账户主体的一项线索；具体订单、支付和结算记录是否与该结果关联，应按真实系统及合同关系判断。出现交易异常时，平台应核对事实并依法采取其权限内的相称措施；本协议不使平台取得当然冻结资金的权力，也不表示已提供资金托管、银行卡一致性校验或完整交易链路追踪。
二、关联合规场景
- 反洗钱与反欺诈：若实际交易场景出现涉诈或其他违法线索，身份核验结果可作为核查账户主体的一项线索。交易特征、设备信息或行为数据是否处理，应以真实功能、合法基础和依法告知的范围为准。
- 税务与发票：经营主体的真实身份，是开具发票、履行代扣代缴或信息报送义务的前提；税务责任的最终归属仍取决于经营者自身。
- 物流与履约：涉及实物商品时，收发货人信息、寄递实名等要求会与交易实名相互衔接。
上述场景的具体规则会随业务形态和适用规定而不同，平台在落地时以实际合作方与主管部门的要求为准。
补充说明：在交易环节定位身份核验的作用
交易开始前的实名认证可以帮助确认参与者身份，但不能单独证明商品或资源的权属、订单价格是否正确、付款是否获得授权，或交易对方是否履行合同。因此，在支付、转让、退款等环节使用认证结果时，应把身份结论与订单、账户权限和实际交易记录分开核对。即使同一账户曾经通过认证，也需要看争议操作是否由有权人员作出。
对于因风险提示而暂时无法继续的交易，应先辨认限制针对的是新订单、某一支付动作、资料修改，还是整个账户。不同范围对用户的影响并不相同，不能把“待核验”直接等同于已经违法，或把身份未确认当然推导为资金可被扣留。资金处理涉及支付规则、订单状态与法律依据，需要单独审查；本章不新设扣划、没收或无条件拒绝退款的权利。
用户发现交易记录与本人行为不一致时，应尽可能按实际页面保存订单、时间和状态线索，并通过官方渠道说明是否存在账户失控、身份被冒用或误操作。平台核对时，也应区分交易系统错误和身份核验错误的来源，不应因两个系统均关联同一账户就将责任简单归于某一方。需要进一步身份确认时，追加处理的范围以解决当前争议所需为限。
交易场景中使用认证结论，应明确它究竟用于确认账户主体、满足某项依法适用的实名要求，还是辅助排查具体风险。认证通过不能保证商品或服务质量、付款能力与交易安全；认证未完成也不当然证明申请人存在欺诈。订单争议、退款和资金处理应依据各自适用的合同与法律处理。平台若因身份信息矛盾暂停某项操作，应说明具体受影响的操作和恢复路径，避免将一个环节的疑点无差别扩展到全部已购买服务。
本章情境释义（不新增权利义务）
以下情境围绕交易与实名关系说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
订单生成前
适用事实。以“订单生成前”为例，应先明确核验是否属于该服务前置条件，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“订单生成前”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“核验是否属于该服务前置条件”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对订单生成前，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“订单生成前”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“核验是否属于该服务前置条件”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核验是否属于该服务前置条件时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。订单生成前可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
认证服务收费
适用事实。以“认证服务收费”为例，应先明确以实际展示价格和订单为准，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“认证服务收费”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“以实际展示价格和订单为准”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对认证服务收费，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“认证服务收费”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“以实际展示价格和订单为准”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以实际展示价格和订单为准时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。认证服务收费的名称只是阅读辅助，真正需要判断的是以实际展示价格和订单为准如何影响按真实交易页面确认适用的条件和费用。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
他人代付
适用事实。以“他人代付”为例，应先明确付款记录不替代身份关系证明，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“他人代付”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“付款记录不替代身份关系证明”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对他人代付，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“他人代付”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“付款记录不替代身份关系证明”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解付款记录不替代身份关系证明时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。交易与实名关系关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。他人代付如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
退款处理中
适用事实。以“退款处理中”为例，应先明确实名结果不决定退款权利，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“退款处理中”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“实名结果不决定退款权利”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对退款处理中，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“退款处理中”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“实名结果不决定退款权利”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解实名结果不决定退款权利时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。退款处理中可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
异常付款
适用事实。以“异常付款”为例，应先明确应核对交易而非直接认定欺诈，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“异常付款”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“应核对交易而非直接认定欺诈”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对异常付款，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“异常付款”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“应核对交易而非直接认定欺诈”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应核对交易而非直接认定欺诈时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。异常付款的名称只是阅读辅助，真正需要判断的是应核对交易而非直接认定欺诈如何影响按真实交易页面确认适用的条件和费用。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
服务已履行
适用事实。以“服务已履行”为例，应先明确争议按具体合同和证据处理，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务已履行”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“争议按具体合同和证据处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务已履行，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务已履行”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“争议按具体合同和证据处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解争议按具体合同和证据处理时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。交易与实名关系关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。服务已履行如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
账户与订单不一致
适用事实。以“账户与订单不一致”为例，应先明确需要分别查明账号与交易，再从实名核验可帮助确认交易主体并保护账户及资金安全这一原则出发理解本章关于交易与实名关系的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账户与订单不一致”这一情境中，需要分辨的是订单类型、认证状态、付款人和实际使用人的关系，并核对“需要分别查明账号与交易”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕订单类型、认证状态、付款人和实际使用人的关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账户与订单不一致，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按真实交易页面确认适用的条件和费用这一相关事项，决定是否核对订单与认证各自适用的规则。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账户与订单不一致”时，应以实名核验可帮助确认交易主体并保护账户及资金安全为出发点，核对订单类型、认证状态、付款人和实际使用人的关系及其他可核实的记录，再结合“需要分别查明账号与交易”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需要分别查明账号与交易时，应同时守住本章边界：认证通过不等于对所有交易或资金来源作保证。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。账户与订单不一致可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第八章 未成年人保护与监护人条款
一、适用对象与年龄界定
重点提示： 本章说明未成年人保护原则；是否开放未成年人实名认证，仍以实际年龄门槛、页面与公示规则为准。本章不构成对未成年人可通过认证的承诺。未满十八周岁的自然人用户以下称"未成年人"。平台可根据实名认证信息中的出生日期、用户主动声明、监护人提交材料及平台实际识别能力，对用户年龄状态进行必要识别与区分管理；不满十四周岁的儿童适用法律法规规定的特别保护规则；若平台依法开放相应年龄段服务，已满十四周岁未满十八周岁的未成年人可在监护人知情并同意的前提下使用与其年龄相适应的服务功能；未开放时，监护人同意不替代实际认证资格。具体功能范围以平台实际开通能力、页面提示及另行公示的业务规则为准。
二、监护人同意与协助
未成年人在注册、实名认证或使用本平台服务前，应取得其父母或其他监护人（以下称"监护人"）的明确同意。依据《个人信息保护法》关于不满十四周岁未成年人个人信息的特别规则，对于不满十四周岁的儿童，如依法提供相关认证，其个人信息处理须先满足监护人单独同意等适用条件；相关认证操作应符合实际开放的流程与法律要求。监护人同意的范围和效力应以实际告知、有效同意及适用法律为准；监护人责任亦须结合其法定职责和具体事实判断。
三、平台核验、使用限制与特殊保护
为核实未成年人身份及监护关系的真实性，平台有权要求用户提交能够证明监护资格的相关材料。平台可根据法律法规要求、产品类型、实际技术能力、交易风险及业务规则，对未成年人账号采取与其年龄相适应的管理措施，该等措施可能包括但不限于要求监护人确认、限制部分高风险功能、设置消费额度提示或限制、屏蔽明显不适宜未成年人的功能或内容等；具体措施以平台届时实际提供的功能、页面提示及另行公示规则为准。平台将未成年人特别是儿童的个人信息作为敏感信息予以特殊保护，遵循最小必要原则收集和使用，并在合理可行范围内采取相应保护措施。除法律法规要求、平台安全运营所必需或取得监护人单独同意外，平台不会向任何第三方共享、转让或公开未成年人的个人信息。
四、监护人权利行使
监护人有权查询、复制未成年人的个人信息，发现信息有误的有权要求更正，并有权要求删除未成年人的个人信息。收到上述请求后，平台将在合理期限内核实身份并依法予以处理；因法律法规规定须保留相关信息的，平台将在完成必要保存义务后予以处理，并向请求人说明情况。
补充说明：年龄门槛与监护协助的先后关系
当前后台的最低实名认证年龄默认设为十八周岁，且该数值可以由实际设置调整。监护人阅读协议、陪同操作或表示同意，并不会自动使低于当前门槛的申请获得通过；是否存在适用未成年人的认证流程，应以实际开放入口和当时设置为准。协议关于未成年人保护的文字，主要说明在涉及未成年人资料或权益时应如何谨慎核对，不能被理解为承诺已开放儿童或青少年认证。
同一家庭成员共用设备时，设备、网络或付款方式相同不等于账号属于同一人。判断是谁提出申请，需要结合填报资料、实际操作、账户控制及可核实的记录，避免将家长的身份信息直接绑定到未成年人的个人账户。若监护人认为其证件被未经许可使用，应将身份冒用、未成年人操作与账户归属问题分别说明，以便采用对应的核对路径。
在处理监护人提出的查询、更正或删除请求时，应核实其与未成年人的关系、所请求信息的范围及法定留存基础，同时避免向无法证明权限的人披露完整证件号码。必要的身份核验不意味着可要求其反复提交与请求无关的材料。本节不改变用户及监护人依法享有的权利，也不设固定响应时间或保证某种处理结果。
年龄门槛与监护人同意解决不同问题。当前个人入口以居民身份证号码校验申请人年龄，实际最低年龄还受系统设置约束；监护人愿意协助，并不当然使未达到入口条件的申请获得通过。若未来开放面向未成年人的身份核验，平台应先确定该服务是否适合相应年龄、所需信息是否最少，以及监护关系如何核实；处理不满十四周岁未成年人个人信息时，还须依法律取得监护人同意并制定专门规则。不得把本章的保护性说明当成现已开放未成年人认证的证明。
本章情境释义（不新增权利义务）
以下情境围绕未成年人保护说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
不足十四周岁
适用事实。以“不足十四周岁”为例，应先明确信息处理需适用儿童特别规则，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“不足十四周岁”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“信息处理需适用儿童特别规则”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对不足十四周岁，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“不足十四周岁”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“信息处理需适用儿童特别规则”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解信息处理需适用儿童特别规则时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。不足十四周岁可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
十四至十八周岁
适用事实。以“十四至十八周岁”为例，应先明确先确认服务是否实际开放，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“十四至十八周岁”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“先确认服务是否实际开放”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对十四至十八周岁，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“十四至十八周岁”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“先确认服务是否实际开放”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先确认服务是否实际开放时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。十四至十八周岁的名称只是阅读辅助，真正需要判断的是先确认服务是否实际开放如何影响监护人通过正式渠道了解是否存在可用服务。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
身份证生日录错
适用事实。以“身份证生日录错”为例，应先明确应核验原始证件与录入，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“身份证生日录错”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“应核验原始证件与录入”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对身份证生日录错，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“身份证生日录错”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“应核验原始证件与录入”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应核验原始证件与录入时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。未成年人保护关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。身份证生日录错如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
父母代持账号
适用事实。以“父母代持账号”为例，应先明确不等于未成年人本人通过认证，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“父母代持账号”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“不等于未成年人本人通过认证”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对父母代持账号，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“父母代持账号”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“不等于未成年人本人通过认证”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不等于未成年人本人通过认证时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。父母代持账号可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
监护关系有争议
适用事实。以“监护关系有争议”为例，应先明确核验申请人身份和权限，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“监护关系有争议”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“核验申请人身份和权限”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对监护关系有争议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“监护关系有争议”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“核验申请人身份和权限”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核验申请人身份和权限时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。监护关系有争议的名称只是阅读辅助，真正需要判断的是核验申请人身份和权限如何影响监护人通过正式渠道了解是否存在可用服务。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
年龄达到门槛
适用事实。以“年龄达到门槛”为例，应先明确仍需满足其他正式条件，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“年龄达到门槛”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“仍需满足其他正式条件”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对年龄达到门槛，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“年龄达到门槛”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“仍需满足其他正式条件”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仍需满足其他正式条件时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。未成年人保护关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。年龄达到门槛如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
误收儿童信息
适用事实。以“误收儿童信息”为例，应先明确应按适用法律评估后续处理，再从未成年人个人信息需特别保护且认证资格受实际开放规则约束这一原则出发理解本章关于未成年人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“误收儿童信息”这一情境中，需要分辨的是真实年龄、当前最低年龄要求和监护关系，并核对“应按适用法律评估后续处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实年龄、当前最低年龄要求和监护关系说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对误收儿童信息，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合监护人通过正式渠道了解是否存在可用服务这一相关事项，决定是否核实年龄门槛和监护关系。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“误收儿童信息”时，应以未成年人个人信息需特别保护且认证资格受实际开放规则约束为出发点，核对真实年龄、当前最低年龄要求和监护关系及其他可核实的记录，再结合“应按适用法律评估后续处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应按适用法律评估后续处理时，应同时守住本章边界：监护人同意不自动绕过当前年龄限制。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。误收儿童信息可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第九章 风险控制、审核与账户处置
一、风险识别与再次认证
为保障平台运营安全及全体用户合法权益，平台有权基于合理的风险管理需要，对用户的实名认证信息进行持续核验。当平台通过风控系统、人工排查或第三方核验渠道发现下列情形之一时，可要求用户在指定期限内重新完成实名认证：认证信息与权威数据源存在不一致；账户登录环境、设备指纹或行为特征出现异常；同一身份信息被多个账户重复使用；或平台有合理理由怀疑账户存在被盗用、冒用、转让风险。逾期未完成再次认证的，平台可采取相应处置措施。
二、人工审核与高风险提交的拒绝
平台在自动化核验之外保留人工审核的权利。对于系统判定为高风险的认证申请，包括但不限于疑似伪造证件、使用他人身份信息、批量注册、涉嫌洗钱或电信网络诈骗特征的提交，平台有权直接拒绝，并可不逐一说明具体判定细节，以避免风控规则被规避。用户对审核结果有异议的，可通过平台公示的申诉渠道提出，并提交足以证明其身份真实性的有效材料。
三、账户限制、冻结与服务终止
重点提示： 用户身份资料与实际情况不符或出现具体违规线索时，平台应先核对事实、风险和适用规则，再决定是否在必要范围内限制有关认证或账户功能；紧急风险可依法先行采取相称的保护措施，并在允许时及时说明和提供异议途径。涉及资金的事项须另依实际业务关系、有效合同与法律由有权主体处理，本章不授予平台当然延迟结算或暂扣款项的权力。
四、反欺诈、证据留存与配合监管
平台建立并持续完善反欺诈机制。为履行法定义务及主张、行使、维护合法权利，平台将依据《网络安全法》、《个人信息保护法》等法律法规，在必要范围内、以合法方式记录并保存与认证及风控相关的日志、操作记录、设备信息、核验凭证等证据材料，并按照法律规定的期限予以留存。当收到监管机构、司法机关或公安机关依照法定程序提出的协查、调取或处置要求时，平台有权且有义务在法律规定的范围内提供相关用户的实名认证信息及风控记录，并配合采取账户处置、数据封存等措施。此类配合行为不视为平台违反对用户的保密承诺。平台采取的各项措施均遵循必要、合理、与风险程度相适应的原则。
容易混淆的异常状态
相同的“未通过”提示可能来自不同环节。正式页面和人工复核若能区分原因，用户才便于更正资料或提出异议；无法确认原因时，应说明仍待核查，而不是替服务商或用户编造确定的责任。以下区分不增加对任何一方的固定处置期限。
- 格式不符合要求：证件号码长度、校验位或必填项问题通常应先回到输入核对。需要修正的字段应与实际错误相对应；不能因为出现格式错误，就将证件持有人列为冒用者或要求其提交与错误无关的全部资料。
- 会话未完成：扫码后页面关闭、网络中断或服务商会话过期，可能尚未形成可靠的身份结论。若用户重新发起申请，应确认旧订单、会话和费用状态，避免将技术中断等同于真实身份拒绝；具体费用处理应依实际订单与已公示规则判断。
- 第三方返回拒绝：需要查明返回状态的含义及其关联的申请。用户能否补正、重试或要求复核，取决于实际服务能力和拒绝原因；平台不能仅凭一个代码概括宣称证件伪造，也不能对用户请求作出与服务商记录不符的解释。
- 疑似冒用或异常控制：这类疑点可能涉及其他账户或被冒用人，保护措施应考虑继续损害风险，但仍须核实行为与账户的联系。必要的暂时限制应与风险相称，后续核查发现误判时应调整对应措施，而不是仅修改认证状态文字。
- 账户已受限制：账户措施可能源于交易或服务使用规则，与当前实名申请并非同一个决定。复核时应分别说明认证结果和限制原因，避免要求用户重复完成无关核验作为解除所有限制的统一前提。
补充说明：风险线索、事实认定与措施范围
认证失败、设备变化、短时间多次提交以及服务商返回异常，都可能触发复核，但各自能够证明的事实有限。一次格式校验失败通常只说明输入不符合要求，不能证明证件伪造；共享网络造成的相似登录环境，也不能独立证明多个账号由同一人控制。风险判断应结合与该申请直接相关的记录、用户解释及误报可能性，避免把模型分数或单一技术信号写成已经确定的违法事实。
如果风险涉及尚未完成的新申请，暂停该次核验与限制已经取得的其他服务，影响范围明显不同。需要采取措施时，应辨认紧急程度、可能损害和措施可逆性，优先说明实际影响的功能和复核渠道；是否能先行告知，应依具体风险和法律要求判断。对账户余额、在用资源或第三方权益有影响的处理，还须分别核对对应规则，不能只靠实名认证章节作概括授权。
复核结果可能显示资料错误、服务商故障、用户本人变更，或确有冒用风险。不同原因对应不同纠正方式：修正资料、重新取得结果、恢复功能或按现行规则处理违规行为，不能机械地采用同一种处罚。保留与决定直接相关的证据有助于解释处理理由，但留存内容和期限仍受最小必要及法定要求约束。
本章情境释义（不新增权利义务）
以下情境围绕风险识别与审核说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
异地登录
适用事实。以“异地登录”为例，应先明确先排查正常旅行和共享网络，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“异地登录”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“先排查正常旅行和共享网络”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对异地登录，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“异地登录”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“先排查正常旅行和共享网络”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先排查正常旅行和共享网络时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。异地登录可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
证件重复出现
适用事实。以“证件重复出现”为例，应先明确核对账户关联及可能冒用，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“证件重复出现”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“核对账户关联及可能冒用”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对证件重复出现，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“证件重复出现”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“核对账户关联及可能冒用”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对账户关联及可能冒用时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。证件重复出现的名称只是阅读辅助，真正需要判断的是核对账户关联及可能冒用如何影响通过正式渠道补充材料或请求人工核查。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
信息过期
适用事实。以“信息过期”为例，应先明确提供更新而非先作欺诈结论，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“信息过期”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“提供更新而非先作欺诈结论”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对信息过期，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“信息过期”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“提供更新而非先作欺诈结论”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提供更新而非先作欺诈结论时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。风险识别与审核关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。信息过期如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
系统高风险标记
适用事实。以“系统高风险标记”为例，应先明确可要求说明主要因素，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“系统高风险标记”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“可要求说明主要因素”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对系统高风险标记，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“系统高风险标记”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“可要求说明主要因素”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解可要求说明主要因素时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。系统高风险标记可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
紧急冻结
适用事实。以“紧急冻结”为例，应先明确事后按法律允许范围说明理由，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“紧急冻结”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“事后按法律允许范围说明理由”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对紧急冻结，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“紧急冻结”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“事后按法律允许范围说明理由”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解事后按法律允许范围说明理由时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。紧急冻结的名称只是阅读辅助，真正需要判断的是事后按法律允许范围说明理由如何影响通过正式渠道补充材料或请求人工核查。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
人工拒绝
适用事实。以“人工拒绝”为例，应先明确留存可供复核的主要依据，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“人工拒绝”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“留存可供复核的主要依据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对人工拒绝，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“人工拒绝”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“留存可供复核的主要依据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解留存可供复核的主要依据时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。风险识别与审核关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。人工拒绝如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
核验渠道故障
适用事实。以“核验渠道故障”为例，应先明确不能把服务中断归咎用户，再从风险信号只用于审慎核验和与风险程度相称的处理这一原则出发理解本章关于风险识别与审核的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“核验渠道故障”这一情境中，需要分辨的是身份矛盾、登录异常、关联线索及其可靠性，并核对“不能把服务中断归咎用户”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份矛盾、登录异常、关联线索及其可靠性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对核验渠道故障，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道补充材料或请求人工核查这一相关事项，决定是否提交情况说明或请求复核。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“核验渠道故障”时，应以风险信号只用于审慎核验和与风险程度相称的处理为出发点，核对身份矛盾、登录异常、关联线索及其可靠性及其他可核实的记录，再结合“不能把服务中断归咎用户”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能把服务中断归咎用户时，应同时守住本章边界：单一设备或网络信号不当然证明本人违法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。核验渠道故障可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十章 声明与保证、违约责任及责任限制
一、用户的声明与保证
用户郑重声明并保证：其向平台提交的所有实名认证信息均为真实、准确、完整且合法有效的信息，不存在任何伪造、变造、冒用、盗用或以其他不正当方式取得的情形；其为所提交身份信息的合法权利人，或已获得权利人的充分授权；不将本人账户及认证结果出借、出租、出售或以其他方式提供给第三方使用；在其认证信息发生变更时及时更新。
二、平台的声明与保证
平台保证按照法律法规及相关国家标准，采取合理的技术措施与管理措施，对用户提交的实名认证信息予以处理和保护，并在合理注意义务范围内审核认证信息的一致性。用户理解，实名认证的核验结果部分依赖于第三方认证机构及相关数据源，平台在勤勉尽责、履行合理审查义务的前提下，对第三方核验服务的准确性、及时性及可用性不作绝对保证，但不因此免除其自身应尽的合理注意义务。平台不会超出实名认证及法律法规要求的目的范围擅自使用、披露用户的身份信息。
三、违约责任
重点提示： 如有证据表明用户提交虚假资料、欺诈或冒用身份，平台可依据有效规则和适用法律采取与风险相称的措施，并提供依法适用的告知与异议途径。第三方提出投诉、诉讼或行政调查本身不证明用户有过错，也不当然使用户承担平台的全部责任、行政罚款或费用。赔偿范围应依据实际损害、因果关系、各方过错及法律确定。
四、责任限制与分配
重点提示： 发生服务中断、核验偏差、资料泄露或其他损害时，应查明实际原因、各方应尽义务及是否已履行、损害与行为间的关系。第三方服务故障、黑客攻击或用户操作错误并不当然免除平台依法应承担的责任；损失类型和赔偿范围也不得以概括性格式条款预先全部排除。各方责任以有效约定和适用法律为准。
合规底线：本章和其他章节均不排除或限制平台依法不得免除的责任，也不减损用户依法享有的权利。与用户有重大利害关系的格式条款须依法提示并按请求说明；是否已履行相关义务应以实际展示和记录判断。相关规定见《中华人民共和国消费者权益保护法》第二十六条及《民法典》关于格式条款的规定。
核对责任时不宜跳过的事实
对同一件认证争议，各方可能只看到其中一段过程。为避免把结果直接等同于责任，审查时可把事实拆为以下四组；这些问题是理解本章的辅助，不改变适用法律规定的举证与责任规则。
- 发生了什么：记录申请、订单、第三方会话、最终显示和后续账户措施的先后顺序。技术失败、服务商拒绝、用户输入错误及平台展示错误可能产生近似页面提示，只有定位环节，才能讨论由谁控制相关风险。
- 谁掌握什么：用户能提供自己看到的页面和操作，平台掌握系统状态与传输记录，服务商可能掌握核验过程。任何一方都不应被要求凭空证明对方独占的内部事实；需要披露的信息仍应限于争议处理的必要范围，兼顾其他人的个人信息安全。
- 损害如何产生：认证迟延、错误限制、信息泄露与交易损失，涉及的损害类别不同。应核对损害是否实际发生、是否与特定行为有关，以及是否存在其他原因；不能仅凭损失发生在认证期间就推定全部由平台或用户承担。
- 是否已经补救：重新核验、更正状态、解除错误限制、通知风险及恢复服务，可能减少继续损害，但不能自动消除已经发生的法定责任。相反，尚无证据证明某项补救可行时，也不能在协议里承诺它一定能够完全恢复。
补充说明：损失与责任需要逐项核对
认证争议中的损失可能来自资料填写错误、服务商核验偏差、账户安全事件或后续交易行为。责任判断需要先确认具体损害，再看相关主体在该环节应履行的义务、实际采取的措施、行为与损害之间是否存在因果关系，以及是否存在可以依法减轻或免除责任的事实。不能从认证未通过直接推出用户有过错，也不能因为涉及第三方就当然免除平台依法应承担的部分。
例如用户提交了正确资料但页面显示核验失败，首先需要区分网络中断、订单未完成、第三方返回拒绝和平台记录错误；各情形都可能导致相同的页面结果，却需要不同证据。若损害还涉及账户被盗用，应进一步核对登录控制、通知、异常操作和采取补救措施的时间顺序。仅凭最终状态或某一方的概括说明，难以得出所有损失均由另一方承担的结论。
任何赔偿或免责主张都应放在适用法律和有效约定下审查。格式条款中的显著提示有助于用户注意重大利害关系事项，但呈现为红色加粗并不自动证明说明充分，也不使依法无效的免责或责任转移条款有效。本节用于说明核对路径，不预设赔偿金额、上限、举证结果或免除平台安全保障义务。
条款中关于用户提交真实资料、妥善保管账户和配合核验的要求，应结合其能够实际控制的行为理解。身份资料遭第三人盗用、平台系统处理错误或服务商核验失误时，责任不能只因申请记录显示在某个账号下便全部归于账号持有人。平台与用户之间的责任，应依各自实际行为、已履行的义务、损害与因果关系依法确定；涉及平台自身故意或重大过失、消费者法定权利的事项，不得用笼统提示或概括免责排除。
本章情境释义（不新增权利义务）
以下情境围绕责任与损失说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
用户填错信息
适用事实。以“用户填错信息”为例，应先明确先区分可更正错误与故意欺诈，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“用户填错信息”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“先区分可更正错误与故意欺诈”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对用户填错信息，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“用户填错信息”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“先区分可更正错误与故意欺诈”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先区分可更正错误与故意欺诈时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。用户填错信息可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第三方数据错误
适用事实。以“第三方数据错误”为例，应先明确核对平台是否尽审慎义务，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“第三方数据错误”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“核对平台是否尽审慎义务”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对第三方数据错误，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“第三方数据错误”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“核对平台是否尽审慎义务”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对平台是否尽审慎义务时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。第三方数据错误的名称只是阅读辅助，真正需要判断的是核对平台是否尽审慎义务如何影响如实说明事实并保存必要交易与沟通记录。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
账户被盗
适用事实。以“账户被盗”为例，应先明确查明原因和双方措施，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账户被盗”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“查明原因和双方措施”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账户被盗，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账户被盗”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“查明原因和双方措施”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明原因和双方措施时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。责任与损失关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。账户被盗如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
服务中断
适用事实。以“服务中断”为例，应先明确区分不可抗力与可归责故障，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务中断”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“区分不可抗力与可归责故障”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务中断，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务中断”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“区分不可抗力与可归责故障”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分不可抗力与可归责故障时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。服务中断可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
间接损失主张
适用事实。以“间接损失主张”为例，应先明确依有效法律和具体证据判断，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“间接损失主张”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“依有效法律和具体证据判断”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对间接损失主张，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“间接损失主张”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“依有效法律和具体证据判断”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解依有效法律和具体证据判断时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。间接损失主张的名称只是阅读辅助，真正需要判断的是依有效法律和具体证据判断如何影响如实说明事实并保存必要交易与沟通记录。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
格式条款争议
适用事实。以“格式条款争议”为例，应先明确注意显著提示和说明义务，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“格式条款争议”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“注意显著提示和说明义务”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对格式条款争议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“格式条款争议”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“注意显著提示和说明义务”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解注意显著提示和说明义务时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。责任与损失关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。格式条款争议如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
他人损害
适用事实。以“他人损害”为例，应先明确应查明实际实施者和因果关系，再从违约与赔偿须结合有效条款、实际过错、因果关系及法律判断这一原则出发理解本章关于责任与损失的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“他人损害”这一情境中，需要分辨的是行为事实、损失证据与平台已履行的合理义务，并核对“应查明实际实施者和因果关系”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕行为事实、损失证据与平台已履行的合理义务说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对他人损害，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合如实说明事实并保存必要交易与沟通记录这一相关事项，决定是否就具体损失和过错提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“他人损害”时，应以违约与赔偿须结合有效条款、实际过错、因果关系及法律判断为出发点，核对行为事实、损失证据与平台已履行的合理义务及其他可核实的记录，再结合“应查明实际实施者和因果关系”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应查明实际实施者和因果关系时，应同时守住本章边界：免责声明不能排除依法不得免除的责任。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。他人损害可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十一章 个人信息主体权利及行使方式
一、您对个人信息享有的权利
重点提示：在法律法规规定的范围内，您对自己的个人信息享有以下权利，我们将提供相应途径协助您行使：
- 查阅与复制：您有权向我们查阅、复制您的个人信息，了解处理目的和方式；符合法律规定情形的，我们会按照约定的方式和范围向指定的第三方转移相关信息（可携带权）。
- 更正与补充：发现信息不准确或不完整时，您有权请求更正或补充。涉及证件号码、姓名等实名核心字段的，更正需以您提供的有效证件重新核验为准。
- 删除：依据《个人信息保护法》第四十七条，在处理目的已实现或无法实现、我们停止提供服务、您撤回同意、我们违规处理等情形下，您可以请求删除。删除在技术上难以实现的，我们将停止除存储和采取必要安全保护措施之外的处理。
- 解释说明：您有权要求我们对个人信息处理规则作出解释说明。
二、权利行使的方式、响应与限制
您可以通过本协议载明的客户服务渠道或在线功能入口提交上述请求。为保护您的信息安全，我们会先行核验您的身份，必要时要求您提供能够证明身份的材料，并在合理期限内予以答复。对不合理重复的请求，我们可能酌情收取合理成本费用或予以拒绝。在下列情形下，我们可能无法完全满足您的请求：与我们履行法定义务相关的；与国家安全、公共安全直接相关的；为履行风险控制、反欺诈、防范交易安全风险等所必需的；有充分证据表明您存在主观恶意或滥用权利的；满足请求将导致他人合法权益受到严重损害的；涉及商业秘密的。对于依法应当留存的实名认证信息，在法定或约定的保存期限内，即使您提出删除请求，我们仍需按规定继续保存，但会限制对该等信息的其他处理。
三、投诉与救济
如果您认为我们的个人信息处理行为损害了您的合法权益，或您对我们处理请求的结果不满意，您可以通过本协议提供的联系方式向我们投诉。我们会及时受理并核实相关情况，尽快向您反馈处理意见。如仍无法解决，您还可以向有关监管部门反映，或依法通过其他途径寻求救济。
补充说明：权利请求与身份核对
同一份请求可能同时包含多个问题：用户既想知道认证为什么失败，也想更正错误的证件显示，并担心第三方继续保存资料。受理时宜将事实查询、资料更正与第三方处理分别识别，避免只回复其中一个问题就视为全部解决。若需要转由不同负责环节处理，应在实际可行范围内保持问题之间的关联，防止用户反复提交相同的敏感信息。
查询认证记录、更正姓名、了解处理规则和请求删除资料，涉及的对象与结果并不相同。用户提出请求时，可以描述所使用的账户、希望核对的认证事项以及目前看到的问题；平台识别请求类别后，应按适用法律和实际系统能力判断处理范围。没有必要把所有请求统一转为重新认证，也不能以尚未完成某种未开放的认证方式为由，概括拒绝用户依法享有的个人信息权利。
平台核实申请人身份，是为了避免把完整证件资料交给无权人员，核实手段应与所请求信息的敏感程度相称。已登录账户的状态、历史联系方式或既有工单记录，可能为核对提供线索，但任何单一线索是否足够仍需看具体风险。用户如果已经失去原账户控制权，处理重点应转向账户恢复和防冒用；不宜要求其先在失控账户内完成无法操作的步骤。
删除请求还需要区分仍为履行法定义务或处理争议而必要的资料、可以立即停止使用的资料，以及已在备份中等待正常清理的数据。若依法不能立即删除全部信息，应说明可解释的处理依据和范围，并避免继续为无关目的使用。请求是否获支持、如何反馈及所需时间，以届时有效法律和实际渠道为准；平台应按适用法律和实际请求情形处理并反馈。
本章情境释义（不新增权利义务）
以下情境围绕个人信息权利说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
查看认证状态
适用事实。以“查看认证状态”为例，应先明确页面可见范围与完整记录不同，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“查看认证状态”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“页面可见范围与完整记录不同”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对查看认证状态，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“查看认证状态”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“页面可见范围与完整记录不同”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解页面可见范围与完整记录不同时，应同时守住本章边界：权利行使不应要求无关或过量材料。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。查看认证状态可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
要求复制
适用事实。以“要求复制”为例，应先明确核对可提供资料与他人权益，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“要求复制”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“核对可提供资料与他人权益”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对要求复制，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“要求复制”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“核对可提供资料与他人权益”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对可提供资料与他人权益时，应同时守住本章边界：权利行使不应要求无关或过量材料。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。要求复制的名称只是阅读辅助，真正需要判断的是核对可提供资料与他人权益如何影响通过公示渠道提出明确请求并提供必要验证。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
修改姓名
适用事实。以“修改姓名”为例，应先明确核心字段需凭有效证件复核，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“修改姓名”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“核心字段需凭有效证件复核”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对修改姓名，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“修改姓名”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“核心字段需凭有效证件复核”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核心字段需凭有效证件复核时，应同时守住本章边界：权利行使不应要求无关或过量材料。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。个人信息权利关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。修改姓名如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
要求删除
适用事实。以“要求删除”为例，应先明确区分不再必要与法定留存，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“要求删除”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“区分不再必要与法定留存”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对要求删除，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“要求删除”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“区分不再必要与法定留存”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分不再必要与法定留存时，应同时守住本章边界：权利行使不应要求无关或过量材料。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。要求删除可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
授权代理查询
适用事实。以“授权代理查询”为例，应先明确需核对代理权限，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“授权代理查询”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“需核对代理权限”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对授权代理查询，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“授权代理查询”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“需核对代理权限”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需核对代理权限时，应同时守住本章边界：权利行使不应要求无关或过量材料。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。授权代理查询的名称只是阅读辅助，真正需要判断的是需核对代理权限如何影响通过公示渠道提出明确请求并提供必要验证。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
多次重复请求
适用事实。以“多次重复请求”为例，应先明确仍须依法判断是否合理，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“多次重复请求”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“仍须依法判断是否合理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对多次重复请求，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“多次重复请求”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“仍须依法判断是否合理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仍须依法判断是否合理时，应同时守住本章边界：权利行使不应要求无关或过量材料。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。个人信息权利关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。多次重复请求如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
发现记录错误
适用事实。以“发现记录错误”为例，应先明确应核对来源并纠正，再从查阅、复制、更正、删除与解释请求依法分别处理这一原则出发理解本章关于个人信息权利的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“发现记录错误”这一情境中，需要分辨的是请求人身份、目标资料和可适用的法定条件，并核对“应核对来源并纠正”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕请求人身份、目标资料和可适用的法定条件说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对发现记录错误，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过公示渠道提出明确请求并提供必要验证这一相关事项，决定是否提出相应个人信息权利请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“发现记录错误”时，应以查阅、复制、更正、删除与解释请求依法分别处理为出发点，核对请求人身份、目标资料和可适用的法定条件及其他可核实的记录，再结合“应核对来源并纠正”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应核对来源并纠正时，应同时守住本章边界：权利行使不应要求无关或过量材料。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。发现记录错误可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十二章 数据存储、保留与安全
一、数据留存期限
重点提示： 本平台仅在实现认证目的所必需的期限内保存您的个人信息，符合《个人信息保护法》第十九条关于保存期限为实现处理目的所必要的最短时间的要求。但存在下列情形之一的，本平台有权在相应法定或合理期限内继续留存：法律法规、部门规章或监管要求承担留存义务的（如依据《网络安全法》、《反电信网络诈骗法》对用户实名信息及日志的留存要求）；为处理争议、投诉、纠纷或潜在诉讼需保留证据的；为防范、发现、调查欺诈、盗用、洗钱、电信网络诈骗等违法违规或风险行为需保存必要凭证的；配合有权机关依法开展调查、取证、协查工作需保留并提供相关记录的。本平台不会进行无明确目的、无期限的留存。
二、存储安全
本平台依据《个人信息保护法》第五十一条及《数据安全法》第二十七条，在合理可行范围内采取符合行业通行标准的技术与管理措施保护您的信息安全，包括但不限于传输与存储保护、权限控制、日志记录、异常监测及必要的安全排查等。具体安全措施将根据业务规模、系统条件、技术发展及风险状况持续调整，平台不在本协议中对某一具体技术、设备、系统架构或内部管理方案作固定承诺。尽管本平台已尽合理努力，但受限于技术水平与现实条件，任何存储方式都无法保证绝对安全；因不可归责于本平台的原因导致的信息泄露，本平台在依法尽到安全保障义务的前提下，不承担超出法律规定范围的责任。
三、删除、匿名化与备份
当认证目的已经实现，且不存在本章所列法定或合理留存基础时，本平台将对您的个人信息予以删除或进行匿名化处理。匿名化处理后的信息无法识别到特定个人且不可复原，不属于个人信息。若您请求删除个人信息，而本平台仍负有法定留存义务或存在争议处理、风险防范之正当需要，本平台可暂缓删除，转为限制处理，待留存基础消灭后再行删除或匿名化。为保障服务连续性与数据可恢复性，本平台会对相关数据进行备份，备份数据同样受本章安全措施保护；执行删除或匿名化时，若备份介质因技术原因无法即时清除，本平台将使目标数据处于不可访问、不可调用状态，并在下一备份周期或技术条件允许时完成清除。
保存与清理需要分别判断的记录
用户询问“我的实名认证资料保存多久”时，只有先确认具体资料，回答才可能准确。下列类别按产生原因区分，不能被理解为平台已持有全部类别或已采用统一保留期限；正式答复应以实际系统、合同和法律依据为准。
- 申请输入：姓名和证件号码可能用于发起本次核验、确认账户与认证结果的关联。其完整值、遮掩后的显示值和校验过程中的临时数据，并非完全相同的保存对象；各自是否仍有必要，应随用途变化评估。
- 服务商会话：会话标识、跳转地址和轮询状态用于识别某一次申请。会话完成或失效后，是否保留其审计记录应看真实追溯需要；不能把可恢复页面的短期技术状态写成永久认证凭据。
- 认证结论：通过、拒绝或失败的状态可能与后续功能资格直接相关。若结论有误，除了更正当前展示，还要核对由错误结论触发的功能限制；更正不意味着可以销毁依法需要保存的全部历史线索。
- 订单和付款：若申请对应付费订单，支付、退款和争议记录有独立的交易处理目的。认证资料的删除请求不能自动决定订单记录的法律留存安排；同样，存在订单记录也不当然使所有原始身份素材得以继续保存。
- 申诉证据：被冒用报告、客服沟通和必要附件可帮助解决具体争议。争议结束后仍要核对是否存在法定保存基础，并控制访问范围；不能为了便于将来查询而无限期保留与已查明事实无关的额外敏感材料。
补充说明：不同记录的保存目的不同
一次认证可能产生申请字段、订单或支付记录、服务商会话标识、核验结论、异常排查记录以及用户与客服的沟通。它们形成的原因不同，不宜在协议中一律写为“认证资料”并套用同一个固定保存年限。平台应按各类信息的实际持有方、必要用途、法定要求与清理触发条件，分别告知保存期限或其确定方法。
用户注销账户后，某些个人信息的处理目的可能已经消失；另一些与法定留存、未结交易或正在处理的争议有关的信息，可能仍有独立的留存基础。需要留存时，应限制继续使用的范围，并在基础消失后依适用规则删除或匿名化。不能将“账户不可登录”直接等同于所有副本已经删除，也不能把技术备份的存在概括成无限期保存依据。
安全措施的描述同样要与现状一致。传输保护、权限控制、日志审计和备份清理分别解决不同风险；列举这些措施不意味着每一项都已在所有供应商、所有系统中实现。发生具体问题时，应依据真实系统和服务商记录核查，而不能只凭本章的原则性文字断定资料一定安全或一定泄露。本节也不预设原始人脸、证件影像已由平台保存。
保存期限应按信息类别和目的分别判断。认证申请原始资料、账户认证结论、交易订单与争议处理记录的必要期间可能不同，不能把其中一类的法定保存要求无差别套到全部资料。处理目的已经实现、保存期限届满或个人依法撤回同意时，应依《个人信息保护法》审查删除条件；如法定保存期限未满或删除在技术上难以实现，应停止除存储和采取必要安全保护措施之外的处理。用户请求删除时，平台应说明仍需保留的类别及其理由。
本章情境释义（不新增权利义务）
以下情境围绕存储期限与安全说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
核验刚完成
适用事实。以“核验刚完成”为例，应先明确区分原始资料与结果记录，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“核验刚完成”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“区分原始资料与结果记录”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对核验刚完成，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“核验刚完成”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“区分原始资料与结果记录”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分原始资料与结果记录时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。核验刚完成可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
账户长期未用
适用事实。以“账户长期未用”为例，应先明确重新评估保存目的，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账户长期未用”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“重新评估保存目的”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账户长期未用，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账户长期未用”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“重新评估保存目的”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解重新评估保存目的时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。账户长期未用的名称只是阅读辅助，真正需要判断的是重新评估保存目的如何影响通过正式渠道查询留存和申请依法删除。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
发生未结争议
适用事实。以“发生未结争议”为例，应先明确仅保留相关必要证据，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“发生未结争议”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“仅保留相关必要证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对发生未结争议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“发生未结争议”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“仅保留相关必要证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅保留相关必要证据时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。存储期限与安全关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。发生未结争议如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
备份尚未轮换
适用事实。以“备份尚未轮换”为例，应先明确先限制访问并按周期清理，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“备份尚未轮换”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“先限制访问并按周期清理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对备份尚未轮换，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“备份尚未轮换”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“先限制访问并按周期清理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先限制访问并按周期清理时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。备份尚未轮换可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
请求删除影像
适用事实。以“请求删除影像”为例，应先明确核对有无法定保存基础，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“请求删除影像”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“核对有无法定保存基础”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对请求删除影像，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“请求删除影像”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“核对有无法定保存基础”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对有无法定保存基础时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。请求删除影像的名称只是阅读辅助，真正需要判断的是核对有无法定保存基础如何影响通过正式渠道查询留存和申请依法删除。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
内部查询记录
适用事实。以“内部查询记录”为例，应先明确仅供有权限人员按需使用，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“内部查询记录”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“仅供有权限人员按需使用”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对内部查询记录，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“内部查询记录”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“仅供有权限人员按需使用”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅供有权限人员按需使用时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。存储期限与安全关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。内部查询记录如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
匿名化研究
适用事实。以“匿名化研究”为例，应先明确确保不能复原识别个人，再从仅在必要期限及有合法留存基础时保存认证信息这一原则出发理解本章关于存储期限与安全的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“匿名化研究”这一情境中，需要分辨的是处理目的、争议状态、法定保存义务与备份位置，并核对“确保不能复原识别个人”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕处理目的、争议状态、法定保存义务与备份位置说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对匿名化研究，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式渠道查询留存和申请依法删除这一相关事项，决定是否询问留存依据或依法申请删除。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“匿名化研究”时，应以仅在必要期限及有合法留存基础时保存认证信息为出发点，核对处理目的、争议状态、法定保存义务与备份位置及其他可核实的记录，再结合“确保不能复原识别个人”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解确保不能复原识别个人时，应同时守住本章边界：不能把无明确目的的无限期留存写成默认安排。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。匿名化研究可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十三章 同意、单独同意、拒绝与撤回
一、同意的取得方式
重点提示： 平台应在申请实名认证前以清晰、易懂的方式展示适用文本，并通过可核对的积极操作取得依法需要的同意。协议接受、认证申请和敏感个人信息单独同意各有不同作用；任何一项操作都不自动替代其他依法必要的告知与同意。
二、敏感个人信息的单独同意
重点提示： 实际认证方式可能处理身份证件号码等敏感个人信息；当前平台个人认证页面不采集人脸或活体信息。根据《中华人民共和国个人信息保护法》第二十九条、第三十条，在依法需要单独同意时，相应处理者须另行告知处理必要性及对个人权益的影响并取得有效的单独同意。用户可在提供信息前查看相应告知和同意操作；如页面缺少依法需要的说明或选择，可暂停申请并通过平台公示渠道询问。
三、拒绝授权的后果
您有权拒绝提供实名认证所需的个人信息或拒绝相关处理活动。若您选择拒绝，我们不会强制要求您继续，也不会因此限制您使用与实名认证无关的其他功能。需要说明的是，实名认证是特定服务依法开展的前提条件。若您拒绝提供必要信息或拒绝敏感个人信息的单独授权，我们将无法为您完成身份核验，您可能因此无法使用依赖实名认证的相关功能或服务。
四、撤回同意及其效力
重点提示： 您有权依法撤回此前基于同意作出的授权，包括依法取得的敏感个人信息单独同意。可通过实际开放的账户功能或公示联系渠道提出请求；平台应按请求范围、其他合法处理基础和适用法律停止依该同意进行的后续处理，并说明仍需保存或处理的法定事项。撤回不影响撤回前基于有效同意已经进行的合法处理，撤回途径应依法便于行使。
五、处理目的或方式变更时的重新授权
若实名认证的处理目的、处理方式或所涉个人信息的种类发生实质性变更，我们会在变更生效前重新向您告知变更内容，并再次征求您的同意。在您就变更事项作出新的授权之前，我们不会依据变更后的目的或方式处理您的个人信息。对于涉及敏感个人信息的变更，我们仍将履行单独同意的告知与授权程序。
一次申请中可能存在的不同确认
审查一次申请是否具有适当的信息处理基础时，不能只查看最终按钮是否被点击。下列事项对应不同问题，均应结合当时实际开放的功能与页面核实，不能因本节列举就推定所有确认目前已经独立实现。
- 协议接受：用户是否愿意依据本协议申请该项服务，应看其实际看到的版本、按钮文案与操作记录。浏览文本、系统自动跳转或勾选一个与本次认证无关的服务选项，不能概括替代对本协议的有效接受。
- 一般个人信息告知：姓名等资料由谁处理、用于何种认证目的，应在提交前说明。实际必要的处理可以依据适用法律确定基础，但不能把所有未来可能的业务需求都塞入一次认证告知中。
- 敏感个人信息处理：证件号码及实际发生的生物识别处理，应核对特别告知和依法需要的单独同意。相应处理者应通过实际页面及操作记录证明依法需要的单独同意；红色提示文字本身不能代替同意操作。
- 第三方页面：若用户随后进入服务商页面，该页面的收集者、用途及退出路径需要独立辨认。平台同意记录不能自动证明服务商已完成所有告知；服务商的同意记录也不自动授权平台进行其他用途的画像或共享。
- 后续变更：增加资料类别、改变处理目的或换用不同角色的服务商时，应重新评估原基础是否仍适用。旧版本的明确接受可以作为历史事实保存，但不应被解释为对未知变动无限期、无边界的授权。
补充说明：把协议接受与信息处理同意分开看
点击接受实名认证协议，主要对应用户是否愿意依本协议提出相应申请；敏感个人信息的单独同意则针对具体处理者、信息种类、用途与影响。两种操作的法律作用并不完全重合。平台应结合各端实际页面和记录，分别核对协议接受与敏感个人信息单独同意；本协议文字不能补足实际交互中缺少的法定告知或同意。
若核验服务商自己的页面要求采集人脸，其告知和同意还要看服务商实际处理角色及页面操作记录。用户在平台页面接受协议，不等于已经同意未知的第三方用于其他目的处理人脸信息；在第三方页面表示同意，也不意味着平台可以超出已告知范围使用返回结果。分析某次申请时，应按发生顺序核对不同主体各自取得了什么基础。
用户拒绝或撤回某项同意后，可能影响依赖该项处理才能完成的认证方式，但不应笼统解释为放弃全部账户权利。撤回前基于有效同意已经进行的处理，其效力应按法律判断；撤回后能否继续留存个别记录，还须查明是否存在独立法定基础。任何重新授权也应针对新的目的或方式明确展示，不能只用一次登录或继续浏览推定。
同意应与具体处理活动对应。用户接受本协议，表明愿意按适用条款申请认证，但不能据此推定其同意未知服务商收集人脸、用于营销或向新的独立处理者提供证件资料。处理敏感个人信息时，相应处理者应依法告知必要性和对权益的影响，并取得单独同意；因处理目的或方式变化而需要重新同意的，应重新提供清楚的选择。用户拒绝非必要处理，不应被解释为放弃所有与该处理无关的账户权益。
本章情境释义（不新增权利义务）
以下情境围绕同意与撤回说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
未勾选协议
适用事实。以“未勾选协议”为例，应先明确不能开始依赖该同意的认证，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“未勾选协议”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“不能开始依赖该同意的认证”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对未勾选协议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“未勾选协议”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“不能开始依赖该同意的认证”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能开始依赖该同意的认证时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。未勾选协议可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
只同意协议
适用事实。以“只同意协议”为例，应先明确不等于同意处理全部敏感信息，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“只同意协议”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“不等于同意处理全部敏感信息”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对只同意协议，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“只同意协议”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“不等于同意处理全部敏感信息”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不等于同意处理全部敏感信息时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。只同意协议的名称只是阅读辅助，真正需要判断的是不等于同意处理全部敏感信息如何影响在独立提示后作出明确选择或依法撤回。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
单独同意人脸
适用事实。以“单独同意人脸”为例，应先明确仅适用于告知的核验目的，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“单独同意人脸”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“仅适用于告知的核验目的”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对单独同意人脸，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“单独同意人脸”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“仅适用于告知的核验目的”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅适用于告知的核验目的时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。同意与撤回关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。单独同意人脸如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
改变处理目的
适用事实。以“改变处理目的”为例，应先明确应重新告知并取得所需同意，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“改变处理目的”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“应重新告知并取得所需同意”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对改变处理目的，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“改变处理目的”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“应重新告知并取得所需同意”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应重新告知并取得所需同意时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。改变处理目的可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
撤回后申请
适用事实。以“撤回后申请”为例，应先明确不追溯否定此前合法处理，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“撤回后申请”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“不追溯否定此前合法处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对撤回后申请，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“撤回后申请”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“不追溯否定此前合法处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不追溯否定此前合法处理时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。撤回后申请的名称只是阅读辅助，真正需要判断的是不追溯否定此前合法处理如何影响在独立提示后作出明确选择或依法撤回。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
服务商另行告知
适用事实。以“服务商另行告知”为例，应先明确需看具体处理者责任，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务商另行告知”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“需看具体处理者责任”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务商另行告知，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务商另行告知”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“需看具体处理者责任”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需看具体处理者责任时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。同意与撤回关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。服务商另行告知如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
勾选记录丢失
适用事实。以“勾选记录丢失”为例，应先明确不能推定用户已经授权，再从一般协议接受与敏感个人信息单独同意应可区分这一原则出发理解本章关于同意与撤回的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“勾选记录丢失”这一情境中，需要分辨的是实际告知文字、同意动作、处理目的及其变化，并核对“不能推定用户已经授权”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际告知文字、同意动作、处理目的及其变化说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对勾选记录丢失，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在独立提示后作出明确选择或依法撤回这一相关事项，决定是否作出或撤回相应处理同意。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“勾选记录丢失”时，应以一般协议接受与敏感个人信息单独同意应可区分为出发点，核对实际告知文字、同意动作、处理目的及其变化及其他可核实的记录，再结合“不能推定用户已经授权”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能推定用户已经授权时，应同时守住本章边界：拒绝非必要处理不应被扩张为放弃所有服务。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。勾选记录丢失可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十四章 通知、协议变更、争议解决与法律适用
一、通知与送达
平台可通过实际开放的站内消息、短信、电子邮件或页面公告等方式发送与实名认证有关的通知。通知是否有效到达，应结合实际渠道、发送与接收记录、通知性质、用户可获得性及适用法律判断；仅有发送记录或公告发布记录不当然证明用户已经知悉涉及重大权益的内容。双方可通过公示的正式联系渠道核对通知与联系方式的变化。
二、协议的变更与版本更新
重点提示： 因法律法规、业务规则或安全合规需要修订本协议时，平台应发布可查阅的新文本、版本号和生效日期，并对涉及用户重大利害关系的内容依法履行提示、说明及必要的重新同意程序。用户继续使用服务的事实，须结合真实展示和具体行为判断其法律效果，不能当然替代依法要求的明确或单独同意。未依法满足生效条件的变更，不以本章概括表述对用户发生效力。历史版本的留存与查阅方式应在正式发布时核实。
三、点击同意与电子签名效力
用户对已展示的本协议作出明确积极操作时，其意思表示和法律效果须结合页面内容、记录、实际身份核验及适用法律判断。电子形式本身不妨碍依法成立有效的协议；但普通点击、身份信息提交与符合法律规定的可靠电子签名不能未经核对便视为同一种行为。涉及格式条款的提示说明和敏感个人信息的单独同意，仍应分别履行。
四、法律适用
本协议的订立、效力、解释、履行及争议解决，均适用中华人民共和国大陆地区现行有效的法律法规（为本协议之目的，不含香港特别行政区、澳门特别行政区及台湾地区法律）。
五、争议解决
重点提示： 因本协议引起或与本协议有关的任何争议，双方应首先本着诚实信用原则友好协商解决。协商不成的，可依法向有管辖权的人民法院提起诉讼；如双方另行达成有效仲裁协议，则依该协议及适用法律办理。如您作为消费者依据法律享有向特定管辖法院起诉的权利，本条约定不排除、不限制该等法定权利；依据《消费者权益保护法》及相关强制性管辖规定优先适用，前述约定在此范围内不适用。
六、条款可分性与协议生效
某一条款的效力受到质疑时，应按适用法律和具体事实判断其效力，以及是否影响其他条款；双方不能仅凭本章预先指定替代条款。本协议的生效须以实际发布、适用范围和依法有效的接受为前提；仅浏览本协议不表示接受；具体适用应结合实际展示和有效接受记录判断。终止后的权利义务依法分别判断。
变更文本时核对其实际影响
版本管理的重点不是给文本换一个编号，而是让用户能够辨认哪些内容影响其认证选择。平台应按实际变动分类处理；下列情形须结合真实页面、业务流程和适用法律确定告知、提示及同意方式。
- 文字澄清：修正错别字、补充不改变原含义的例子，通常与新增信息处理目的不同。仍应保留可核对的文本差异，避免用户后来无法判断自己当时看到的关键条款是什么。
- 认证入口变化：新增组织认证、特殊证件或另一家服务商，可能改变适用人群、可选方式和实际数据流。尚未上线的入口不应提前写成现有服务；上线后也需要使对应用户看到与其方式相符的正式说明。
- 信息处理变化：新增人脸、证件影像或独立第三方用途，可能涉及新的告知、评估或同意。原协议的红色提示不能自行覆盖未知的信息种类，旧版勾选记录也不能无边界地延伸到新用途。
- 用户权益变化：账户限制范围、申诉方式、费用规则或责任分配若发生实质变化，应审查是否属于重大利害关系内容，如何显著提示及何时对特定申请适用。不能通过后台替换文件而抹去旧版本及其对应的接受记录。
- 争议发生时：应能对应用户实际申请时间、版本展示、同意操作与后续变更。版本号、日志、通知送达和页面截图各自证明不同事实，不能只凭其中一项推定双方对所有后续修改都无异议。
补充说明：版本通知与争议路径
本协议若发生变化，首先要明确变更了哪些认证步骤、哪些信息处理事项以及是否影响用户已有的重要权益。纯文字校正与扩大处理范围、增加重大限制的变动，不能只靠同一条“继续使用即同意”概括处理。是否需要再次取得同意、何时生效、如何告知，应依据变更性质、适用法律和真实页面安排判断，并保存可核对的版本与展示记录。
发生争议时，用户可能先向客服询问，再通过投诉或诉讼解决；不同渠道的作用和可提供的救济并不完全相同。双方协商可以帮助澄清事实，但不能剥夺依法向主管部门投诉或向有管辖权法院起诉的权利。仲裁需要符合其自身的有效约定要求，不能仅因本协议提到“争议解决”就推定双方已作出仲裁选择。
电子记录可用于说明某个文本何时展示、用户进行了何种操作及平台作出何种反馈，但记录的完整性、关联性和证明力需要结合具体系统核查。仅有一个勾选结果，不当然证明重大条款已经以足以引起注意的方式提示，也不能证明用户对未展示的其他文件已作出接受。本节不把某种通知方式、推送成功状态或保存年限写成已经实现的事实。
修改条款的生效方式，应与变更对用户的实际影响相称。仅修正排版错误，与增加敏感信息类别、扩大账户限制或改变费用规则并不相同；后者可能影响用户的选择，需要适用的提示、说明或重新同意。平台应留存能够对应申请时间的文本和展示记录，以便用户核对争议发生时适用的版本。协商和平台投诉是可选择的解决渠道；是否存在有效仲裁约定应独立判断，用户依法向主管部门投诉或向有管辖权法院寻求救济的权利不因概括表述而消失。
本章情境释义（不新增权利义务）
以下情境围绕通知、变更与争议说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
手机号已更换
适用事实。以“手机号已更换”为例，应先明确检查通知是否实际有效，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“手机号已更换”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“检查通知是否实际有效”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对手机号已更换，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“手机号已更换”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“检查通知是否实际有效”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解检查通知是否实际有效时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
站内公告
适用事实。以“站内公告”为例，应先明确注意重大变更的额外提示要求，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“站内公告”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“注意重大变更的额外提示要求”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对站内公告，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“站内公告”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“注意重大变更的额外提示要求”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解注意重大变更的额外提示要求时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
版本新增数据类型
适用事实。以“版本新增数据类型”为例，应先明确依法再次告知并取得同意，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“版本新增数据类型”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“依法再次告知并取得同意”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对版本新增数据类型，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“版本新增数据类型”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“依法再次告知并取得同意”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解依法再次告知并取得同意时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
电子确认
适用事实。以“电子确认”为例，应先明确记录证明操作而非当然证明理解，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“电子确认”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“记录证明操作而非当然证明理解”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对电子确认，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“电子确认”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“记录证明操作而非当然证明理解”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解记录证明操作而非当然证明理解时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
仲裁未单独约定
适用事实。以“仲裁未单独约定”为例，应先明确争议走适用法律途径，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“仲裁未单独约定”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“争议走适用法律途径”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对仲裁未单独约定，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“仲裁未单独约定”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“争议走适用法律途径”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解争议走适用法律途径时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
部分条款无效
适用事实。以“部分条款无效”为例，应先明确其余条款效力依法判断，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“部分条款无效”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“其余条款效力依法判断”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对部分条款无效，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“部分条款无效”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“其余条款效力依法判断”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解其余条款效力依法判断时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
语言版本不同
适用事实。以“语言版本不同”为例，应先明确以正式发布的中文文本核对，再从通知和协议修订应依法结合有效送达与必要的重新同意这一原则出发理解本章关于通知、变更与争议的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“语言版本不同”这一情境中，需要分辨的是通知渠道、版本内容、用户权益影响与签署记录，并核对“以正式发布的中文文本核对”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕通知渠道、版本内容、用户权益影响与签署记录说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对语言版本不同，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读正式通知并通过官方渠道提出异议这一相关事项，决定是否就通知、版本或争议途径提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“语言版本不同”时，应以通知和协议修订应依法结合有效送达与必要的重新同意为出发点，核对通知渠道、版本内容、用户权益影响与签署记录及其他可核实的记录，再结合“以正式发布的中文文本核对”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以正式发布的中文文本核对时，应同时守住本章边界：未经有效仲裁约定，不能推定双方已选择仲裁；有效仲裁约定也可能依法载于合同条款。
第十五章 冒用、盗用与借用身份的防范与处置
实名认证的价值，取决于"人证一致、账号归真"这一底线。逸薯云明确：接入本平台并完成实名认证的自然人，必须是身份信息所对应的本人，且认证行为必须出于本人的真实意愿。任何冒用、盗用、借用、出借、买卖他人身份的行为，都将破坏平台信任基础，并直接损害被冒用人的合法权益。本专章对上述行为的具体表现、平台的核验义务、认定标准、分级处置以及责任划分作出尽可能全面的约定（包括但不限于所列情形，未列明的同类或变种行为同样适用），正式文本发布后的明确同意是否构成有效接受，应结合实际提示、说明和适用法律判断。
一、被绝对禁止的行为情形
下列行为一经发生，无论是否造成实际损害，均构成对本协议的严重违约，平台有权即时处置。用户理解，这些情形既可能违反平台规则，也可能同时触犯《中华人民共和国网络安全法》、《中华人民共和国反电信网络诈骗法》及刑事法律：
- 冒用他人居民身份证、护照、港澳台居民往来通行证、外国人永久居留身份证等法定证件进行认证，包括使用拾得、盗取、骗取、伪造、变造的证件，或使用他人证件的复印件、翻拍件、电子影像完成核验。
- 盗用他人姓名、公民身份号码、手机号、银行卡号等身份要素，在本人不知情的情况下注册账号或通过认证。
- 盗用、截取、合成他人人脸图像、声纹、指纹等生物识别信息，用于活体检测、人脸比对或其他生物核验环节。
- 使用深度合成、AI换脸、三维建模、注入攻击、屏幕翻拍、视频回放等技术手段，伪造或篡改活体检测过程，企图绕过人证一致核验。
- 买卖、出租、出借、赠与本人或他人的身份信息、认证账号、已实名账号，或以"实名代过""秒过认证""人脸代刷"等名义提供、接受此类服务。
- 组织、招募、诱导他人提供身份信息或人脸配合，实施规模化"人头"代认证、批量养号、账号租赁等黑灰产行为。
- 借用他人身份完成认证以规避平台对同一主体的数量限制、风控限制、处罚记录或黑名单，或用于隐匿真实身份从事违法活动。
- 伪造授权委托书、代理关系、监护关系或单位授权文件，谎称已获得身份权利人同意而代为认证。
- 出借本人已实名账号或身份信息给他人使用，导致该账号被用于电信网络诈骗、洗钱、赌博、传销、发布违法信息等活动。
特别说明：出借者与冒用者、借用者同属违规主体。即便出借行为出于"帮忙""信任"等善意动机，只要账号或身份被用于违法违规活动，出借者仍需承担相应责任，不得以"并非本人操作"为由免责。
二、平台的核验义务与技术措施
平台依照《中华人民共和国网络安全法》第二十六条要求用户提供真实身份信息，并采取与业务风险相匹配的合理核验手段。平台的核验义务是"尽合理审慎之责"，而非对一切伪造、盗用行为的绝对担保。平台可根据实际开放的核验能力、业务风险与法律要求采用相称的措施；下列技术仅为可能方式，不表示均已部署：
- 对接权威身份核验渠道，对姓名与公民身份号码进行一致性校验，并核验证件的有效期与真伪特征。
- 引入活体检测与人脸比对技术，识别静态照片、视频回放、面具、屏幕翻拍及深度合成等常见攻击手段。
- 建立设备指纹、行为特征、IP、地理位置等多维风控模型，识别批量注册、异地异常、高频代认证等可疑信号。
- 对高风险场景实施二次核验、人工审核或提高认证等级，必要时要求用户补充证明材料。
- 依据《中华人民共和国反电信网络诈骗法》第二十一条，对涉诈风险账号采取延迟入账、限制功能、重新核验身份等措施。
用户理解，任何技术手段都存在被新型攻击突破的可能。只要平台已按前述标准履行合理核验义务，因用户或第三方采取伪造、盗用、合成等欺骗手段导致核验被绕过的，相关后果由实施欺骗行为的主体承担，平台在法律允许的范围内不承担赔偿责任。本条不免除平台因故意或重大过失所应承担的法定责任。
三、身份权利与被冒用人的保护
自然人对其姓名、肖像、身份信息享有受法律保护的人格权益。依据《中华人民共和国民法典》第一千零三十四条，自然人的个人信息受法律保护；冒用、盗用他人身份的行为，同时侵害被冒用人的姓名权、肖像权及个人信息权益。平台在处理身份信息时遵循《中华人民共和国个人信息保护法》确立的合法、正当、必要与诚信原则，仅在实名认证目的范围内收集与使用生物识别等敏感个人信息，并采取加密存储、访问控制、最小化留存等保护措施。
任何人发现自己的身份被他人冒用或盗用注册、认证的，可通过平台公示渠道提交异议与申诉。平台在收到有效证据后，将及时核查并对被确认为冒用、盗用的账号采取更正、解绑、冻结或注销等措施，配合被冒用人维护其合法权益，并在必要时向其提供与维权相关的记录。
四、发现后的分级处置
平台依据行为性质、危害程度、是否重复及是否配合调查，对冒用、盗用、借用、出借身份的行为采取分级处置。处置措施可单独或合并适用：
- 拒绝认证与核验拦截：对未通过一致性校验、活体检测异常或存在明显欺骗特征的申请，直接拒绝认证，并可要求重新核验。
- 功能限制：对疑似违规账号限制发布、交易、提现、转账等敏感功能，并可要求补充身份证明。
- 账号冻结：对经初步核实存在冒用、盗用嫌疑的账号予以临时冻结，冻结期间暂停全部或部分服务。
- 账号注销与信息清退：对确认冒用、盗用、买卖、出借身份的账号予以注销或收回，并依《互联网用户账号信息管理规定》第九条清理违规账号信息。
- 纳入风控名单：对实施或参与相关黑灰产行为的主体、设备、身份要素纳入平台风控名单，限制其再次注册与认证。
- 移送与配合司法：对涉嫌伪造证件、侵犯公民个人信息、诈骗、帮助信息网络犯罪活动等违法犯罪线索，平台依法向公安机关、网信及其他主管部门报告、移送，并配合调查取证。
用户理解并同意，出于风险防控与反诈需要，平台在合理必要范围内先行采取限制或冻结措施，不以违法事实的最终认定为前提；用户对处置有异议的，可按平台申诉流程举证申诉，平台核实后予以恢复或维持。
五、证据留存与调查配合
为固定违规事实、保护被冒用人并配合监管，平台在法律允许的范围内留存与认证及处置相关的必要记录，包括认证提交记录、核验结果、活体检测日志、设备与网络环境信息、操作日志及处置流水等，留存期限符合法律法规要求。用户对平台依据前述记录作出的认定予以配合，不得删除、篡改、伪造相关证据或妨碍调查。相关记录可作为平台处置、被冒用人维权及有关部门调查的依据。
六、对被冒用人的救济与保护
重点提示：当自然人发现自己的身份信息被他人冒用于平台实名认证时，平台为被冒用人提供以下救济渠道：
- 快速举报通道：被冒用人可通过平台客服、在线表单或专用邮箱提交身份被冒用的举报，平台收到举报后应根据风险紧急程度及时核查；具体处理时限应以正式公示且可履行的规则及适用法律为准。
- 身份核实与处置：平台应按实际疑点和风险，在最小必要范围内核实举报人身份，并依据核实结果依法更正错误关联或采取相称账户措施。手持证件照片、报案回执以及立即注销均不应作为所有举报的统一要求或必然结果。
- 信息清除与恢复：被冒用人有权要求平台清除因冒用行为产生的关联记录（如交易记录、信用记录等），恢复其身份信息的清白状态。平台核实后将依法纠正错误关联；依法必须保存的交易或审计记录不得作为普通资料直接清除。
- 损失追偿协助：被冒用人因冒用行为遭受实际损失的，平台将在法律允许的范围内配合被冒用人向冒用行为人追偿，包括提供必要的证据材料与技术支持。
- 防止再次冒用：被冒用人可申请将其身份信息纳入平台重点保护名单，平台将对该身份信息的后续认证请求实施更严格的核验措施。
平台对被冒用人承担信息保护与及时处置的义务，不因冒用行为系第三方实施而免除对被冒用人的救济责任。被冒用人通过上述渠道获得救济后，平台将对相关处置记录进行归档，作为后续防范与改进的参考依据。平台定期汇总分析冒用行为的类型、手段与趋势，持续优化身份核验技术与风控策略，从源头降低身份冒用风险。平台将根据技术发展持续优化防范措施，努力保障用户身份安全与合法权益。
七、责任承担
重点提示： 冒用、盗用、借用、出借或买卖身份信息的责任，应依据实际行为、损害、因果关系、各方过错和适用法律分别确定。用户就其行为向平台作出如下承诺与责任约定：
- 用户因虚假、冒用或盗用身份造成损失的，责任范围须根据其实际行为、损害、因果关系、过错及适用法律确定；赔偿范围应依法按具体事实确定。
- 用户以他人名义认证或出借账号造成损害的，不得以"账号并非本人实际使用"为由免除或减轻责任。
- 因用户实际违法或违约行为给平台造成损失的，是否承担赔偿及其范围，应结合有效约定、损害、因果关系、各方过错和适用法律确定；投诉、诉讼或行政调查本身不当然证明用户应承担全部损失。
- 第三方采取欺骗手段绕过核验时，应查明平台、用户和第三方各自的行为与义务是否相关；平台是否承担责任以及责任范围依具体事实和适用法律判断。本协议不排除用户依法享有的权利。
平台依据《网络安全法》第二十六条、《反电信网络诈骗法》第二十一条、《互联网用户账号信息管理规定》第九条及《民法典》第一千零三十四条等规定行使本章所列权利。本协议依法展示后，用户的明确接受可作为接受意思表示的证据；是否已充分提示和说明相关条款仍须依法结合实际情况判断。
补充说明：被冒用人的救济顺序
当用户发现他人可能使用自己的证件申请认证时，首要问题是确认其本人控制的账户、可疑账户及争议资料之间的关系。证件号码相同、姓名相同或接到异常通知，都可能是线索，但需要排除录入错误、历史记录和合法账号关联等情况。为减少继续损害，可先按已有渠道报告问题并保护本人账户，再由平台依实际权限核对相关申请；不应要求被冒用人自行获取他人账户中的完整资料。
核查时，可分别查看申请时间、结果状态、用户实际控制的联系方式及其可提供的证据。第三方核验结果可能帮助判断身份匹配，却不必然证明某次账户操作得到本人授权。若存在多个相关账户，应逐个区分控制人和行为，不可仅凭同一证件线索对全部账户作永久处罚。涉及其他用户隐私时，反馈也应在保护被冒用人权益与避免过度披露之间取得平衡。
纠正方式可能包括修正错误认证结果、恢复被误限的功能、阻止可疑申请继续使用，或依法协助有关机关调查；具体措施取决于已查明的事实和可用能力。被冒用人不因提出异议而当然承担冒用账户的交易损失，相关责任仍需结合实际行为、平台义务和法律判断。本节不承诺自动解除所有关联，也不要求被冒用人支付额外核验费用。
身份证件被盗用后，真实权利人可能并未接触被冒用账户，也无法提供该账户的订单或登录凭据。平台受理此类线索时，应允许其通过实际公示渠道说明所知事实，并在必要范围内核验请求人身份；不应要求其先登录被冒用账户或承认该账户属于自己。若调查同时涉及现有账户持有人，平台应分别核对两方的资料与陈述，避免为处理一方请求而泄露另一方的完整证件、订单或联系方式。
本章情境释义（不新增权利义务）
以下情境围绕身份冒用与被冒用人保护说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
捡到证件后认证
适用事实。以“捡到证件后认证”为例，应先明确不因持有证件而有本人授权，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“捡到证件后认证”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“不因持有证件而有本人授权”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对捡到证件后认证，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“捡到证件后认证”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“不因持有证件而有本人授权”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不因持有证件而有本人授权时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。捡到证件后认证可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
亲属代刷人脸
适用事实。以“亲属代刷人脸”为例，应先明确亲属关系不替代本人意愿，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“亲属代刷人脸”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“亲属关系不替代本人意愿”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对亲属代刷人脸，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“亲属代刷人脸”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“亲属关系不替代本人意愿”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解亲属关系不替代本人意愿时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。亲属代刷人脸的名称只是阅读辅助，真正需要判断的是亲属关系不替代本人意愿如何影响发现冒用应尽快通过正式渠道报告并保护账户。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
身份证影像泄露
适用事实。以“身份证影像泄露”为例，应先明确核对是否出现未经授权申请，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“身份证影像泄露”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“核对是否出现未经授权申请”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对身份证影像泄露，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“身份证影像泄露”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“核对是否出现未经授权申请”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对是否出现未经授权申请时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。身份冒用与被冒用人保护关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。身份证影像泄露如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
实名人主动出借
适用事实。以“实名人主动出借”为例，应先明确与被窃取情形应分开，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“实名人主动出借”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“与被窃取情形应分开”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对实名人主动出借，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“实名人主动出借”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“与被窃取情形应分开”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解与被窃取情形应分开时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。实名人主动出借可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
误认冒用
适用事实。以“误认冒用”为例，应先明确允许提交本人证明材料，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“误认冒用”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“允许提交本人证明材料”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对误认冒用，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“误认冒用”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“允许提交本人证明材料”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解允许提交本人证明材料时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。误认冒用的名称只是阅读辅助，真正需要判断的是允许提交本人证明材料如何影响发现冒用应尽快通过正式渠道报告并保护账户。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
冒用账号已交易
适用事实。以“冒用账号已交易”为例，应先明确核查交易责任与个人信息，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“冒用账号已交易”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“核查交易责任与个人信息”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对冒用账号已交易，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“冒用账号已交易”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“核查交易责任与个人信息”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核查交易责任与个人信息时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。身份冒用与被冒用人保护关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。冒用账号已交易如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
受害人希望再认证
适用事实。以“受害人希望再认证”为例，应先明确先清理错误绑定关系，再从人证一致和本人真实意愿是认证的基础这一原则出发理解本章关于身份冒用与被冒用人保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“受害人希望再认证”这一情境中，需要分辨的是证件来源、操作人、控制人和举报人的证据，并核对“先清理错误绑定关系”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕证件来源、操作人、控制人和举报人的证据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对受害人希望再认证，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合发现冒用应尽快通过正式渠道报告并保护账户这一相关事项，决定是否报告身份冒用并请求核查。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“受害人希望再认证”时，应以人证一致和本人真实意愿是认证的基础为出发点，核对证件来源、操作人、控制人和举报人的证据及其他可核实的记录，再结合“先清理错误绑定关系”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先清理错误绑定关系时，应同时守住本章边界：疑似冒用与最终责任认定须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。受害人希望再认证可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十六章 批量注册、账号买卖与黑灰产滥用的防范
实名认证体系的核心价值在于"一人一实名、一实名一真人"，让每个逸薯云账号都对应到确定的自然人或依法登记的组织。任何绕开这一对应关系、把实名身份工具化、规模化、可交易化的行为，都会瓦解实名制的根基，也会把平台推向为电信网络诈骗、网络赌博、非法引流等黑灰产输送"干净通道"的风险中。为守住这条底线，逸薯云依据《网络安全法》、《反电信网络诈骗法》、《互联网用户账号信息管理规定》等规定，对批量注册、机器注册、养号、账号租售转让以及团伙化滥用实名体系的行为作出全面禁止、认定与处置安排。
一、被明确禁止的滥用情形
你在使用逸薯云及其实名认证功能时，不得实施、参与、协助、教唆或以任何方式便利下列行为。下列列举力求穷尽，未列明的同类或变种行为同样在禁止之列：
- 使用自动化脚本、注册机、接码平台、验证码识别工具、模拟器、无头浏览器等技术手段，绕过人机校验批量创建账号；
- 借助群控系统、云控平台、改机工具、多开软件、虚拟设备农场、IP 代理池或"猫池"设备，规模化操控多个账号或伪造设备与网络环境；
- 使用他人身份信息、冒用、盗用、租用、买入的实名信息完成认证，或组织、招募他人"人脸过验""刷脸解封"以突破活体检测；
- 以牟利为目的囤积、批量持有大量账号，或对新注册账号进行"养号"，通过模拟正常活跃、积累信用与权限后再行出售、出租或交付他人使用；
- 出售、出租、出借、赠与、转让、质押账号，或买入、承租、代持账号及其绑定的实名额度、认证资格、信用等级、功能权限；
- 将本人实名身份出租、出借或出售给他人用于开立、认证、解封账号，充当"实名中介""卡农""号商""料主"或提供"实名代过"服务；
- 在账号被限制、冻结、封禁或纳入风险名单后，通过更换设备、更换手机号、更换实名信息、注销后重注册、借用他人身份等方式规避处置、重建账号；
- 组织、参与团伙化协作，分工完成信息采集、注册开号、养号交付、渠道分销等环节，形成产业链条；
- 为电信网络诈骗、网络赌博、洗钱跑分、非法引流导流、刷单炒信、色情低俗、传销等违法犯罪活动提供账号、实名通道、身份掩护或技术支持；
- 批量采集、倒卖、非法提供公民个人信息或人脸等生物识别信息，为上述注册、认证、养号行为提供"料"源。
二、关联线索的核查
批量注册、账号买卖或规避处置的线索，应以实际合法取得的申请记录、账户操作和具体行为核对。相同设备、网络地址、联系方式或付款方式可能出现在家庭、企业办公室等正常场景，不能单独证明多个账户均受同一人控制或均存在违规。平台如需采取措施，应分别确认受影响账户、事实依据和风险范围，并允许用户通过公示渠道提出说明或异议。
本协议不新增设备指纹、地理位置、鼠标轨迹、资金流水或跨平台资料的采集授权。若平台实际采用自动化关联分析，应根据处理目的、数据类别、对用户权益的影响和适用法律完成必要的告知与评估；系统给出的关联分数仅为核查线索，不能机械替代对实际行为的判断。
三、分级处置与影响范围
重点提示：平台对经核实的滥用行为可依据有效规则和适用法律采取与风险相称的措施。关联关系本身不使其他账号当然受限；涉及账号关闭、拒绝重新注册或资金处理时，应分别核对具体依据、权限和可行的异议途径。
- 资料或操作异常但尚无充分证据时，可在必要范围内核查、请求解释或暂缓与疑点直接相关的申请。
- 对经核实的违规账号，可依据实际开放的功能和已公示规则采取相称限制，并说明原因、影响范围及纠错方式。
- 对依法依约关闭的账号重新注册，应采取必要措施；不能仅凭相同身份或共享网络环境永久排除任何新申请。
- 交易款项、退款和结算应由有权主体依有效合同与法律处理，本协议不授予平台概括冻结、扣留或没收资金的权限。
- 发生损失时，赔偿应结合实际损害、行为与因果关系及适用法律确定，不把全部监管成本或第三方索赔预先转移给用户。
四、必要记录与依法协查
平台对实际存在的滥用线索，应在合法、必要范围内保存与核查、申诉或依法协查直接相关的记录；不同类别的记录应分别确定保存基础和期限。不得仅因本章提及风险分析而概括收集设备硬件信息、完整资金流水或其他与本次核查无关的资料。
依据《反电信网络诈骗法》第二十二条，互联网服务提供者对监测识别的涉诈异常账号应依法重新核验，并根据国家有关规定采取相应处置。具体账号是否存在涉诈异常，仍须结合可核实事实与有权机关要求判断。发现涉嫌违法犯罪线索或收到合法协查要求时，平台在法定范围内报告或配合；向其他主体提供个人信息仍须满足相应的合法性要求。
《互联网用户账号信息管理规定》第十七条列明对违反该规定的账号可依法依约采取分类措施并保存相关记录。采取措施时，应让用户知道可公开的原因和救济渠道；行政或刑事责任由有权机关依法认定，不能由平台风险标签直接决定。
五、个人信息处理边界与用户权利保留
平台在开展关联识别与风险处置时处理个人信息，严格限定于反滥用与网络安全这一特定目的，遵循合法、正当、必要与诚信原则，并采取相应安全措施，具体处理规则见《个人信息保护法》相关条款。风险数据的留存期限不超过实现目的所必需的最短时间，法律法规另有规定的从其规定。
本章所设各项禁止、认定与处置安排，旨在保护逸薯云及广大合法用户的正当权益，不排除、不限制你依法享有的申诉、更正、投诉、举报及请求救济等权利，也不构成对平台因自身故意或重大过失所致责任的免除。你正常、真实、以个人使用为目的持有和使用账号的行为，不受本章限制。
六、黑灰产产业链的全链条打击
逸薯云对黑灰产产业链采取"全链条打击"策略，不仅追究直接实施者的责任，还追溯产业链上下游各环节的参与者。以下环节均属打击范围：
- "料"源环节：非法获取、收集、买卖公民个人信息（包括身份证号码、手机号、人脸照片、银行卡信息等）的个人或团伙，为批量注册与代认证提供原始数据。平台将配合公安机关追溯信息泄露源头，追究信息窃取者与贩卖者的法律责任。依据《民法典》第一千零三十四条，自然人的个人信息受法律保护，非法获取、出售个人信息的行为同时构成对个人信息权益的侵害。对于大规模贩卖公民个人信息的行为，平台将依法向公安机关报案并配合刑事追诉。
- "号"源环节：注册、囤积、养护大量账号，并将其出售、出租给下游使用者的个人或团伙。平台对养号行为的认定不限于最终出售环节，包括以出售为目的的注册、养护、积累信用等准备行为。认定标准包括但不限于：短时间内注册大量账号、账号间存在关联性（相同设备、IP、支付方式）、账号活动模式呈现典型的"养号"特征（先小额交易积累信用后大量出售）。
- "技术"环节：开发、销售或传播专用于规避核验的工具的行为主体。工具名称和设备环境只能作为核查线索，不能据此直接推定使用者违法或对其他账户实施连带处置；是否使用检测模型及其处理范围，以实际部署、合法处理依据和具体证据为准。
- "通道"环节：提供接码服务、IP代理、虚拟设备、验证码识别等基础设施服务的提供商或个人。平台可依法将经核实的恶意通道线索纳入风险分析；通过同一通道注册的账号仍须分别核实具体风险。通道提供者是否承担责任，应根据其实际行为、主观状态和适用法律判断，不能仅凭通道曾被使用作当然推定。
- "分销"环节：在社交平台、论坛、暗网等渠道发布买卖广告、撮合交易的中介与分销商。平台有权配合执法机关追溯分销链条，追究分销者的法律责任。分销行为的认定包括：发布买卖广告、建立买卖群组、提供担保交易服务、为买卖双方提供技术支持等。
- "使用"环节：最终购买、租用、借用账号并将其用于违法活动的使用者。使用环节的责任不因账号来源的"合法性"（如声称通过正规渠道购买）而减轻。实际使用者应对其实施的行为依法承担相应责任；交易纠纷和侵权责任仍须结合具体事实判断。
平台对实际存在的账号买卖或信息倒卖线索，应区分不同参与者的行为和证据，对平台内相关账号采取有依据、与风险相称的措施。涉嫌违法犯罪且满足法定条件的线索，依法向有权机关报告或移送；是否构成犯罪及刑事责任由有权机关依法认定。向外提供个人信息或协查材料，应限于合法要求和必要范围。
七、正常用户的权益保护
对正常使用账号的个人或组织，不应仅因其他账户的违规行为、共享设备或相近网络环境而采取连带措施。用户认为关联判断有误时，可通过实际公示渠道提交已有的说明；平台应按具体事实复核并纠正错误关联。若涉及商户服务，应以该服务实际开放的规则确定处理方式，本章不承诺专属客服、优先复核、认证标识或其他未提供的增值能力。
八、技术分析与用户解释
平台若实际使用模型、规则或人工结合的方式识别批量滥用，应以真实系统能力和合法处理基础为准，并对可能显著影响用户权益的结果提供依法适用的解释与异议途径。本协议不表示已经建立设备指纹、网络图谱或模型审计系统，也不以技术指标替代对具体事实的核查。保护必要的安全细节，与说明用户所受措施的依据和纠错方式，应分别实现。
补充说明：识别批量滥用时排除正常共用环境
短时间出现多个注册或认证申请、多个账号使用同一网络或设备，可能值得进一步查看，但共用办公室、家庭网络、公共出口以及设备维修等正常情况也可能产生相似记录。分析关联性时，需要把时间、账户控制、申请资料、操作目的和可核实的交易行为放在一起，不宜仅凭一个技术指标认定“黑灰产”。如果依据技术判断采取限制，后续复核还应允许用户说明正常原因。
账号买卖、代为认证和普通员工经授权操作企业账号之间存在事实差异。区分的关键不只是操作设备由谁持有，还包括身份资料提供者是否知情、账户实际由谁控制、利益归属及是否存在违反已展示规则的行为。对于尚未开放的企业认证入口，不能用本节示例给现有个人认证增加新的授权经营安排，也不能把所有多人接触账户一概归入身份倒卖。
需要阻断疑似滥用时，应按影响范围选择与风险相称的措施，分别确认新申请、相关功能和既有资源的处理依据。可疑线索涉及其他用户时，应避免过度共享或公开关联图谱。向监管或司法机关提供信息，应以实际合法要求为前提；本协议的概括措辞不能代替法定程序，也不授予平台无限期建立跨业务黑名单的权利。
出现同一身份证件对应多个申请时，应先核对这些申请属于同一账户的重试、不同账户的历史绑定，还是未经本人允许的使用。系统限制同证件可认证账户数量，解决的是当前申请能否继续的问题，不能单独证明已有账户非法或申请人参与批量注册。平台作出影响用户权益的决定时，应保存能对应具体申请的时间、结果和原因；用户指出记录错误或被冒用时，应分别检查正在申请的账户与已认证账户，避免一次误判连带影响所有相关服务。
本章情境释义（不新增权利义务）
以下情境围绕批量注册与关联风险说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
家庭共用网络
适用事实。以“家庭共用网络”为例，应先明确需要区别独立自然人，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“家庭共用网络”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“需要区别独立自然人”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对家庭共用网络，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“家庭共用网络”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“需要区别独立自然人”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需要区别独立自然人时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。家庭共用网络可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
公司共用设备
适用事实。以“公司共用设备”为例，应先明确核对是否为授权业务，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“公司共用设备”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“核对是否为授权业务”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对公司共用设备，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“公司共用设备”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“核对是否为授权业务”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对是否为授权业务时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。公司共用设备的名称只是阅读辅助，真正需要判断的是核对是否为授权业务如何影响正常用户可就误判提交相反证据。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
短时多次注册
适用事实。以“短时多次注册”为例，应先明确可能含失败重试，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“短时多次注册”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“可能含失败重试”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对短时多次注册，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“短时多次注册”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“可能含失败重试”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解可能含失败重试时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。批量注册与关联风险关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。短时多次注册如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
账号被转卖
适用事实。以“账号被转卖”为例，应先明确查明实际控制转移，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账号被转卖”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“查明实际控制转移”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账号被转卖，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账号被转卖”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“查明实际控制转移”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明实际控制转移时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。账号被转卖可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
号商集中操作
适用事实。以“号商集中操作”为例，应先明确综合多项异常线索，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“号商集中操作”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“综合多项异常线索”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对号商集中操作，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“号商集中操作”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“综合多项异常线索”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解综合多项异常线索时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。号商集中操作的名称只是阅读辅助，真正需要判断的是综合多项异常线索如何影响正常用户可就误判提交相反证据。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
关联账号未违规
适用事实。以“关联账号未违规”为例，应先明确预防措施也须相称，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“关联账号未违规”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“预防措施也须相称”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对关联账号未违规，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“关联账号未违规”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“预防措施也须相称”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解预防措施也须相称时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。批量注册与关联风险关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。关联账号未违规如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
商户被误关联
适用事实。以“商户被误关联”为例，应先明确提供可核实的经营证据，再从反滥用判断应基于合法必要的信息和多项合理证据这一原则出发理解本章关于批量注册与关联风险的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“商户被误关联”这一情境中，需要分辨的是账号关联、设备环境、注册频率和实际控制情况，并核对“提供可核实的经营证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账号关联、设备环境、注册频率和实际控制情况说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对商户被误关联，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合正常用户可就误判提交相反证据这一相关事项，决定是否解释独立使用情况并提交反证。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“商户被误关联”时，应以反滥用判断应基于合法必要的信息和多项合理证据为出发点，核对账号关联、设备环境、注册频率和实际控制情况及其他可核实的记录，再结合“提供可核实的经营证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提供可核实的经营证据时，应同时守住本章边界：共用网络或设备本身不自动证明团伙滥用。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。商户被误关联可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十七章 证件伪造变造与深度伪造对抗
一、总则
实名认证的可信度建立在"证件真实、人证一致"的前提之上。随着图像处理、深度学习与视频合成技术的普及，伪造、变造身份证件影像以及利用AI换脸、深度伪造等技术绕过活体检测的手段日趋复杂。逸薯云对上述技术性作弊行为采取零容忍态度，依据《网络安全法》第二十六条、《个人信息保护法》第二十八条、第二十九条及《反电信网络诈骗法》第二十一条的规定，建立涵盖技术反制、行为认定、分级处置与责任追究的全链条防范体系。
二、禁止伪造与绕过核验
用户不得伪造、变造或冒用身份证件、组织登记资料及其他实际核验所需材料，也不得通过伪造图像、篡改请求、干扰核验流程等方式使认证结果失真。是否构成违法犯罪，由有权机关依据法律和事实判断；平台发现异常提示时，应先区分资料质量、系统故障与有证据支持的故意行为。
三、适用的技术核查
平台或实际核验服务商可在合法、必要范围内采取与已开放认证方式相适应的真实性校验、安全监测和异常复核。具体技术由实际处理者按真实系统和依法告知的范围实施；本协议不授权额外采集设备硬件特征、人脸、活体数据或其他敏感信息，也不表示已经部署任何特定模型、设备指纹或多模态检测能力。自动提示应作为核查线索，不能仅凭单一技术分数认定用户故意造假。
四、发现异常后的处理
如有资料伪造或绕过核验的合理疑点，平台可依据有效规则和适用法律暂停本次认证、要求对相关资料作必要说明或核对已有记录。影响既有认证结果、账户功能或交易的处置，应结合证据充分程度、影响范围与实际风险作相称判断，并提供依法适用的告知、异议与纠错途径。涉嫌违法犯罪且满足法定条件的线索，依法交由有权机关处理。
五、技术变化与持续保护
伪造方法和核验技术可能变化，平台应按实际运营需要及适用法律持续评估风险和必要的保护措施。任何新增的人脸、生物识别或设备信息处理，都应先核实处理目的、实际处理者和最少必要范围，并完成依法需要的告知、评估及同意。技术更新不使已取得的旧授权自动覆盖新数据类别，也不能作为扩大用户责任或概括免除平台责任的依据。
六、证据固定与责任承担
对实际出现且有证据支持的伪造或冒用疑点，平台应在合法、必要范围内保存相关记录，并区分平台实际持有的数据与服务商自行保存的数据。当前平台个人入口不直接采集人脸或活体资料，不能凭本章技术举例推定已留存原始影像、活体日志或设备指纹。发生损害时，各方责任应依实际行为、损害、因果关系、过错与适用法律确定；使用了风险检测措施不当然免除平台依法应承担的责任。
相关法律依据：《网络安全法》第二十六条、《个人信息保护法》第二十八条、第二十九条、《反电信网络诈骗法》第二十一条、《互联网用户账号信息管理规定》第九条。
补充说明：资料异常与恶意伪造要分辨
证件照片模糊、光线反射、信息输入有误或文件损坏，都可能使核验无法完成；这些问题与故意变造证件、伪造他人身份的性质不同。页面或服务商只返回失败结果时，不宜直接使用“伪造”标签。若需要作出影响账户的重要处置，应尽可能核对异常类型、原始提交记录和用户可提出的解释，并区分能够补正的技术问题与有证据支持的恶意行为。
深度伪造风险可能出现在人脸、视频或证件影像核验环节，但本平台当前页面并不直接采集人脸或活体资料。因此，涉及技术反制的说明仅在对应服务商或实际开放的核验方式中按事实适用，不能将技术举例解释为每次申请均会运行某种模型。即使使用了自动检测，算法提示也只是需要进一步核查的线索；误报、素材质量和服务商差异，都可能影响其解释力。
如出现明显冒用疑点，保护受影响人的身份和控制账户的安全，与保留必要证据同样重要。证据固定应围绕实际争议和依法适用的程序进行，避免复制无关的生物识别原件或向普通客服人员开放全部资料。是否向有关机关移送线索应看法定条件和具体事实；本节并不改变各方依法承担责任的判断标准。
资料真实性核查不等于对申请人的动机判断。证件影像失焦、姓名中存在异体字、数据源暂时未更新或服务商返回格式错误，都可能使技术校验失败。若平台拟将“伪造”作为影响账户或后续申请的重要理由，应有能够解释的具体依据，并区分可以补正的质量问题、第三方数据错误与有证据支持的故意篡改。对错误结论作更正时，还应检查依该结论作出的限制是否需要相应调整。
本章情境释义（不新增权利义务）
以下情境围绕伪造证件与深度伪造说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
截图冒充原件
适用事实。以“截图冒充原件”为例，应先明确需要核对原件和来源，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“截图冒充原件”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“需要核对原件和来源”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对截图冒充原件，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“截图冒充原件”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“需要核对原件和来源”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需要核对原件和来源时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。截图冒充原件可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
视频回放攻击
适用事实。以“视频回放攻击”为例，应先明确检查核验过程的合理证据，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“视频回放攻击”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“检查核验过程的合理证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对视频回放攻击，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“视频回放攻击”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“检查核验过程的合理证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解检查核验过程的合理证据时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。视频回放攻击的名称只是阅读辅助，真正需要判断的是检查核验过程的合理证据如何影响使用本人真实证件并配合必要复核。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
摄像头故障
适用事实。以“摄像头故障”为例，应先明确不能直接等同于恶意注入，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“摄像头故障”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“不能直接等同于恶意注入”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对摄像头故障，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“摄像头故障”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“不能直接等同于恶意注入”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能直接等同于恶意注入时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。伪造证件与深度伪造关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。摄像头故障如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
系统误识别
适用事实。以“系统误识别”为例，应先明确提供合适的复核路径，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“系统误识别”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“提供合适的复核路径”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对系统误识别，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“系统误识别”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“提供合适的复核路径”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提供合适的复核路径时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。系统误识别可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
新型合成内容
适用事实。以“新型合成内容”为例，应先明确判断仍须结合事实，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“新型合成内容”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“判断仍须结合事实”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对新型合成内容，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“新型合成内容”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“判断仍须结合事实”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解判断仍须结合事实时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。新型合成内容的名称只是阅读辅助，真正需要判断的是判断仍须结合事实如何影响使用本人真实证件并配合必要复核。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
未经授权照片
适用事实。以“未经授权照片”为例，应先明确受害人可要求核查，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“未经授权照片”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“受害人可要求核查”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对未经授权照片，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“未经授权照片”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“受害人可要求核查”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解受害人可要求核查时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。伪造证件与深度伪造关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。未经授权照片如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
工具传播线索
适用事实。以“工具传播线索”为例，应先明确移送与处置应符合法律，再从证件真实性和活体结果是可核验线索但非无限保证这一原则出发理解本章关于伪造证件与深度伪造的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“工具传播线索”这一情境中，需要分辨的是提交影像、设备信号、核验链路与异常原因，并核对“移送与处置应符合法律”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕提交影像、设备信号、核验链路与异常原因说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对工具传播线索，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合使用本人真实证件并配合必要复核这一相关事项，决定是否请求核对核验异常的原因。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“工具传播线索”时，应以证件真实性和活体结果是可核验线索但非无限保证为出发点，核对提交影像、设备信号、核验链路与异常原因及其他可核实的记录，再结合“移送与处置应符合法律”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解移送与处置应符合法律时，应同时守住本章边界：技术措施举例不代表每一种能力已实际部署。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。工具传播线索可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十八章 代认证、实名信息倒卖与"实名不实人"滥用
一、总则
实名认证制度的根基在于"实名即实人"——认证信息与实际使用者之间必须存在真实的、可追溯的对应关系。任何将这种对应关系商品化、中介化或脱钩的行为，都将使实名制度沦为形式，并为电信网络诈骗、网络赌博、洗钱等违法犯罪提供可乘之机。本章对代认证、实名信息倒卖及"实名不实人"等滥用行为作出全面禁止、认定与处置安排。
二、被明确禁止的行为
下列行为均属严重违反本协议，一经发现即触发处置：
- 代认证：代替他人完成人脸识别、活体检测、证件提交等认证环节，无论是否收取报酬；包括但不限于"人脸代过""刷脸代认证""远程代认证"等服务形式。
- 组织化代认证：以团队、工作室、群组等形式组织他人提供代认证服务，形成规模化、产业链化的运作模式；招募、培训、管理代认证"枪手"或"刷手"。
- 实名信息买卖：出售、购买、交换、赠与他人的姓名、身份证号码、人脸照片、手机号等实名信息，无论用于认证还是其他目的；包括在社交平台、暗网、加密通讯群组中发布买卖广告或达成交易。
- 实名信息出租出借：将自己的身份信息、人脸照片、已实名账号出租、出借给他人使用；明知他人用于认证、注册、解封等目的仍提供上述信息。
- "实名不实人"：实名认证信息所指向的自然人与账号的实际控制人、操作人不一致，且无法提供合理解释与有效证明；包括已实名账号被他人实际控制、使用的情形。
- 规避处置：在原账号被限制、冻结或注销后，通过代认证、购买实名信息等方式获取新的认证身份，实质上由同一主体继续使用平台服务。
- 明知而协助：明知他人实施上述行为，仍提供场地、设备、网络、资金、技术、信息等支持或便利。
三、"实名人对账户行为负责"原则
依据《网络安全法》第二十六条确立的实名原则，实名记录是核查账号行为的一项线索；各主体的法律责任须依据实际行为、授权、过错、因果关系及适用法律判断，相关行为可能包括：账号发布的内容、实施的交易、产生的资金往来、对他人的侵权行为。实名人提出账号被盗或失去控制时，平台应结合证据核查；不能仅凭实名登记推定其对他人全部行为负责。平台有权要求实名人本人配合完成活体复核、回访确认等验证程序，实名人应予配合。
四、双向处置机制
平台对代认证、实名信息倒卖行为实行"卖方与买方双向追责"：
- 卖方/出租方/出借方：出售、出租、出借本人身份信息或已实名账号的主体，平台可对经核实存在风险的账号采取必要、相称的措施；是否限制再次认证及追偿，应结合具体事实和适用法律判断。
- 买方/租入方/借用方：购买、租入或借用他人身份信息及账号的行为，应按查明的事实、有效规则和适用法律处理。是否限制或关闭相关账号，须考虑行为主体、证据和实际风险；设备或网络标识不能单独作为永久限制其他用户的依据。
- 组织者与中介：对组织、介绍或撮合代认证及信息买卖的线索，平台应先核查事实；涉嫌违法犯罪且符合法定条件的，依法向有权机关报告或移送。
五、实名人配合复核义务
当平台发现有证据支持的身份不符疑点时，可通过实际开放且与风险相称的方式请求必要核验，并说明疑点、可提交的材料及可能影响。当前个人入口不因本条新增实时活体、视频回访、手持证件照或生活照等提交义务。用户未能立即补正时，平台应区分无法联系、客观不能完成核验和有证据证明的冒用；账户措施须依法依约并与风险相称。
六、证据留存、配合监管与责任承担
对已发生的代认证或信息倒卖疑点，平台仅在实际持有、依法取得且为核查所必要的范围内保留相关线索。涉嫌违法犯罪的，平台依据《反电信网络诈骗法》第三十一条及《互联网用户账号信息管理规定》第十七条及其他适用规定，在法定条件下向有权机关报告或配合调查。各方责任和赔偿范围须结合真实行为、损害、因果关系、过错及适用法律分别判断。
七、代认证线索的核查
平台可以依据合法取得、与本次认证风险直接相关的记录，核查疑似代认证行为。单一设备、共享网络、输入速度或登录地点相近，均不能独立证明用户出借身份或参与账号买卖；若需要进一步核查，应结合身份资料、账户控制和可核实的操作记录。是否使用行为模型、设备指纹或跨账号关联技术，应以实际系统和依法履行的告知为准，本协议不新增这些信息的采集授权。
八、举报与依法协查
用户发现身份资料被冒用或有人组织代认证，可以通过平台实际公示渠道提供已有线索。平台应保护举报人信息并核实具体事实；本协议不设举报奖励承诺。收到有权机关依法提出的协查要求时，平台在合法、必要范围内提供实际持有的资料。与其他平台共享身份信息、设备标识或行为模式，不能仅以“行业协作”为依据，须另行满足适用的合法性、必要性、告知与同意等要求。
相关法律依据：《网络安全法》第二十六条、《反电信网络诈骗法》第二十一条、《互联网用户账号信息管理规定》第九条、第十四条。
补充说明：实名信息持有人与实际操作者
同一账户的实名信息持有人、登录设备使用人、付款人和资源使用人可能在某些业务情形下不同。身份资料能够说明核验时被比对的是谁，却不能单凭这一点证明此人实施了之后的每一笔操作。发现“实名不实人”疑点时，应核对账户控制的变化、授权关系、操作记录与收益去向，避免把实名人对账户全部行为承担无条件责任写成当然结论。
有偿出借证件、出售已认证账号与被盗取资料后遭他人冒用，表面上都可能表现为“本人信息在他人控制的账户上”，但主观状态和救济路径明显不同。用户提出自己并未参与申请时，平台应按实际能力和法律要求核对，而不是先要求其承认交易或支付费用才受理。对于确有授权的代操作，也要看授权范围是否包括身份核验及后续账户使用。
需要解除错误绑定或恢复账户控制时，应同时考虑防止再次冒用和避免披露其他人的资料。当前产品是否支持自助解绑、换绑或迁移认证结果，应以实际功能为准；本节不承诺一经申诉即可自动完成，也不允许通过直接替换实名字段转移账户上的既有债务或权利。平台与实名人各自的责任仍取决于证据、有效约定和适用法律。
同一姓名或证件号码出现在多个申请记录中，可能涉及合法更正、重复申请、历史资料迁移，也可能涉及冒用；结论必须结合申请时间、账户控制和具体授权判断。平台如发现异常，应先限制与疑点直接相关的处理范围，避免仅凭关联关系停用所有账户。被冒用人、实际操作人和账号登记人之间的权益可能冲突，平台应分别保护其可依法享有的查阅、更正与申诉机会，不以概括的“实名人负责”代替事实核查。
本章情境释义（不新增权利义务）
以下情境围绕代认证与实际控制说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
朋友帮填表
适用事实。以“朋友帮填表”为例，应先明确应区分机械协助与代替确认，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“朋友帮填表”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“应区分机械协助与代替确认”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对朋友帮填表，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“朋友帮填表”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“应区分机械协助与代替确认”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应区分机械协助与代替确认时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。朋友帮填表可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
付费代刷
适用事实。以“付费代刷”为例，应先明确不能使认证结果成为真实本人操作，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“付费代刷”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“不能使认证结果成为真实本人操作”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对付费代刷，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“付费代刷”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“不能使认证结果成为真实本人操作”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能使认证结果成为真实本人操作时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。付费代刷的名称只是阅读辅助，真正需要判断的是不能使认证结果成为真实本人操作如何影响不得将本人实名能力出租或交付他人控制。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
账号卖出后
适用事实。以“账号卖出后”为例，应先明确原实名关系仍需依法核查，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账号卖出后”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“原实名关系仍需依法核查”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账号卖出后，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账号卖出后”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“原实名关系仍需依法核查”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解原实名关系仍需依法核查时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。代认证与实际控制关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。账号卖出后如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
被诱骗提供人脸
适用事实。以“被诱骗提供人脸”为例，应先明确核对真实意愿与控制过程，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“被诱骗提供人脸”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“核对真实意愿与控制过程”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对被诱骗提供人脸，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“被诱骗提供人脸”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“核对真实意愿与控制过程”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对真实意愿与控制过程时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。被诱骗提供人脸可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
远程操控设备
适用事实。以“远程操控设备”为例，应先明确查明谁完成关键授权，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“远程操控设备”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“查明谁完成关键授权”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对远程操控设备，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“远程操控设备”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“查明谁完成关键授权”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明谁完成关键授权时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。远程操控设备的名称只是阅读辅助，真正需要判断的是查明谁完成关键授权如何影响不得将本人实名能力出租或交付他人控制。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
失去账号控制
适用事实。以“失去账号控制”为例，应先明确及时申请保护性处置，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“失去账号控制”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“及时申请保护性处置”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对失去账号控制，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“失去账号控制”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“及时申请保护性处置”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解及时申请保护性处置时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。代认证与实际控制关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。失去账号控制如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
中介招募他人
适用事实。以“中介招募他人”为例，应先明确依法保存线索并处理，再从认证信息应对应本人或依法授权的主体这一原则出发理解本章关于代认证与实际控制的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“中介招募他人”这一情境中，需要分辨的是身份要素来源、实际操作者和账户控制方式，并核对“依法保存线索并处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕身份要素来源、实际操作者和账户控制方式说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对中介招募他人，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合不得将本人实名能力出租或交付他人控制这一相关事项，决定是否说明账户实际控制情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“中介招募他人”时，应以认证信息应对应本人或依法授权的主体为出发点，核对身份要素来源、实际操作者和账户控制方式及其他可核实的记录，再结合“依法保存线索并处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解依法保存线索并处理时，应同时守住本章边界：技术协助与替别人作出本人认证必须区分。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。中介招募他人可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第十九章 平台功能滥用与实名关联处置
一、总则
实名认证的最终目的是为平台安全运营与合法用户提供可信的身份基础。部分用户利用已完成实名认证的账号实施虚假交易、刷单炒信、洗钱、资金归集、为违法犯罪提供交易通道等功能滥用行为，严重损害平台生态与其他用户的合法权益。本章对上述功能滥用行为的认定、处置与追责作出全面规定。
二、被明确禁止的功能滥用行为
- 虚假交易与刷单炒信：通过自买自卖、互买互卖、雇佣他人虚假下单等方式制造虚假交易记录；通过刷好评、删差评、虚假销量等手段误导其他用户；利用平台评价、信用体系进行不正当竞争。
- 洗钱与资金归集：利用平台交易通道进行资金的分散转入、集中转出或集中转入、分散转出，掩饰、隐瞒资金来源与性质；设立多个账号进行资金归集、中转、拆分，规避反洗钱监测；为他人洗钱活动提供账户、通道或技术支持。
- 为违法犯罪提供交易通道：利用平台为电信网络诈骗、网络赌博、传销、非法集资等违法犯罪活动提供商品或服务交易通道；明知交易对手从事违法犯罪活动仍继续提供服务或配合完成交易。
- 异常资金行为：频繁发生与正常经营规模明显不符的大额或高频交易；短期内多次发生刚好低于监测阈值的交易金额；交易对手高度集中或高度分散且无合理商业解释。
- 其他功能滥用：利用平台物流、发票、营销、推广等功能为违法活动提供便利；利用平台规则漏洞获取不当利益；恶意利用退款、售后等机制进行欺诈。
三、关联风险核查与处置
重点提示：平台发现功能滥用线索时，应核对实名关联与实际行为，并在证据、有效规则和适用法律支持的范围内采取相称措施：
- 依据依法取得的实名线索核查相关账号，并对存在具体风险的账号分别评估必要、相称的措施。
- 如实际涉及结算或交易款项，应由有权主体依有效合同、已公示规则及法律处理风险；本协议不创设冻结、暂扣资金的权限。
- 确有必要限制相关功能时，应区分实际已提供的交易、支付、发布等功能及其影响范围，并提供依法适用的告知与异议途径。
- 确有必要终止涉事账号时，应依法分别核对该账号的事实依据；风险记录的范围、期限和纠错方式须另行核实。
- 涉嫌违法犯罪且依法需要报告或协查的，在法定范围内向有权机关报告或配合调查；不能将实名核验义务直接扩张为一般性交易报送授权。
资金事项须先确认实际控制款项的主体及其法定、合同权限，再判断是否需要采取与风险相称的措施，并依法告知原因和救济方式。实名认证结果本身不构成资金冻结依据。
四、商户特别义务
如将来开放商户认证，与商户经营、交易凭证及资金往来有关的义务和措施，应由实际适用的商户规则、支付合同和法律分别确定。本协议不另增商户保证金、凭证留存义务或扣款权；账户、经营权限和资金事项须各依相应事实与权限处理。
五、证据留存与责任承担
与功能滥用有关的记录，只有在实际存在、依法取得且为核查所必要时才可使用或保存；本协议不新增资金流水、物流或设备数据的采集授权。各方对实际损害的责任，依有效约定、具体行为、因果关系、过错及法律判断，不作全部赔偿或平台概括免责的预先推定。
六、交易监测与可疑行为报告
平台有权根据业务规模、风险状况及法律法规要求，建立与平台实际能力相适应的交易风险识别与处置机制，相关措施可能包括：
- 交易风险识别：对平台上的交易行为进行必要的风险观察或排查，并可通过规则、人工审核、模型分析或其他方式识别异常交易模式，包括但不限于大额异常交易、高频小额交易、关联交易网络、非常规时间交易等。
- 行为风险分析：平台可结合用户历史交易数据、认证信息及其他合法取得的信息，对明显偏离正常交易习惯的行为进行标记与审查，并根据业务变化与新型滥用手段调整相关规则。
- 可疑交易报告：如平台依据适用法律负有特定报告义务，应在法定范围内向有权机关报告；本条不表示平台属于金融机构或非银行支付机构，也不新增交易信息收集范围。
- 用户问询与配合：平台有权就可疑交易向用户发出问询，要求用户提供交易背景、合同、发票、物流凭证等证明材料。用户可在正式通知载明的合理期限内说明情况；具体时限应符合实际规则和适用法律。逾期未回复或回复内容无法合理解释可疑交易的，平台有权采取限制措施。
七、合规培训与风险教育
平台重视用户的合规意识培养，将通过以下方式帮助用户了解功能滥用的风险与防范：
- 在用户注册与商户入驻环节，提供功能滥用风险提示与合规指引；
- 定期发布平台安全公告与典型案例警示，提升用户的风险识别能力；
- 为商户用户提供专门的合规培训材料与在线课程，帮助其了解反洗钱、反欺诈等合规要求；
- 建立便捷的举报渠道，鼓励用户主动报告可疑交易行为。
相关法律依据：《网络安全法》第二十六条、《反电信网络诈骗法》第二十一条、《电子商务法》第二十七条。
补充说明：服务使用问题与身份问题分别判断
资源被用于发送违法信息、异常流量或其他涉嫌违反规则的活动时，平台可能需要先保护系统及相关人员安全，但实名认证记录只说明与账户相关的身份线索，并不自动认定实名人实施了全部行为。事件核查应区分资源归属、实际控制、授权操作、漏洞利用和账号失控等原因；不同原因对后续解除限制、恢复服务及责任认定有不同影响。
如果一项功能遭到滥用，措施应尽量定位到受影响的资源或操作。是否扩大至账户、关联账号或其他服务，需要另行确认风险关联、合同基础和必要程度。仅因两个账户使用过相同证件或设备，不应自动连带停用与争议无关的服务。涉及资金和在用数据的措施尤其需要单独审查，以免功能处置扩大为未约定的扣款、资料删除或交易结算结果。
对外提供信息或进行可疑行为报告，必须符合实际适用的法定条件，不能以本章示例视为普遍授权。用户解释服务用途时，可以围绕自己控制的资源和实际操作提供线索，不应被要求提供与争议无关的其他用户资料。本节描述的是核对顺序，不把平台在所有业务上已经部署持续监测系统作为事实。
实名认证结果可帮助定位申请时被核验的主体，但不能单独证明某笔交易的付款人、收款人、资源控制人或真实受益人。涉及疑似洗钱、诈骗或赌博的线索时，平台应保护相关记录并依法配合有权机关，同时注意自身是否实际持有相应资料及是否有权限采取资金措施。交易异常的技术信号、第三方投诉与违法犯罪事实之间有不同证明力；对账户限制、合同责任和行政或刑事问题，应分别依适用程序处理。
本章情境释义（不新增权利义务）
以下情境围绕平台功能滥用关联说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
云实例被入侵
适用事实。以“云实例被入侵”为例，应先明确查明实际操作和被盗证据，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“云实例被入侵”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“查明实际操作和被盗证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对云实例被入侵，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“云实例被入侵”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“查明实际操作和被盗证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明实际操作和被盗证据时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。云实例被入侵可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
用户自行发布内容
适用事实。以“用户自行发布内容”为例，应先明确核对所属功能和时间，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“用户自行发布内容”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“核对所属功能和时间”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对用户自行发布内容，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“用户自行发布内容”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“核对所属功能和时间”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对所属功能和时间时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。用户自行发布内容的名称只是阅读辅助，真正需要判断的是核对所属功能和时间如何影响按服务规则合法使用已开放功能。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
可疑付款流转
适用事实。以“可疑付款流转”为例，应先明确交易线索不能单独定性，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“可疑付款流转”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“交易线索不能单独定性”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对可疑付款流转，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“可疑付款流转”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“交易线索不能单独定性”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解交易线索不能单独定性时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。平台功能滥用关联关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。可疑付款流转如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
同一实名多服务
适用事实。以“同一实名多服务”为例，应先明确处置范围应与风险对应，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“同一实名多服务”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“处置范围应与风险对应”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对同一实名多服务，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“同一实名多服务”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“处置范围应与风险对应”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解处置范围应与风险对应时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。同一实名多服务可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
企业员工越权
适用事实。以“企业员工越权”为例，应先明确查明授权与实际控制，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“企业员工越权”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“查明授权与实际控制”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对企业员工越权，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“企业员工越权”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“查明授权与实际控制”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明授权与实际控制时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。企业员工越权的名称只是阅读辅助，真正需要判断的是查明授权与实际控制如何影响按服务规则合法使用已开放功能。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
误报违法内容
适用事实。以“误报违法内容”为例，应先明确结合原文和上下文复核，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“误报违法内容”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“结合原文和上下文复核”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对误报违法内容，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“误报违法内容”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“结合原文和上下文复核”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解结合原文和上下文复核时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。平台功能滥用关联关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。误报违法内容如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
监管协查请求
适用事实。以“监管协查请求”为例，应先明确核对权限和法定范围，再从实名记录是违法违规行为调查的一项线索这一原则出发理解本章关于平台功能滥用关联的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“监管协查请求”这一情境中，需要分辨的是具体功能、实际控制人、行为记录和损害结果，并核对“核对权限和法定范围”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕具体功能、实际控制人、行为记录和损害结果说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对监管协查请求，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合按服务规则合法使用已开放功能这一相关事项，决定是否针对具体行为和关联认定提出异议。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“监管协查请求”时，应以实名记录是违法违规行为调查的一项线索为出发点，核对具体功能、实际控制人、行为记录和损害结果及其他可核实的记录，再结合“核对权限和法定范围”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对权限和法定范围时，应同时守住本章边界：关联处置应防止无关用户被机械牵连。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。监管协查请求可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十章 滥用行为的认定、分级、处置与追责总则
一、滥用行为的定义与范围
本章所称滥用行为，应以实际行为违反有效协议或适用法律，并有相应证据为前提。第十五章至第十九章的类型仅提供核查线索；概括性表述不能使平台单方扩大禁止范围，也不能因同一事实涉及多项描述就当然从重处置。平台应区分误填、正常共用网络环境与有证据的规避行为，并依据风险和损害作相称处理。
二、滥用行为的分级标准
平台依据行为的性质、主观恶意、危害后果、重复次数及配合程度，将滥用行为分为以下四级：
- 轻度滥用：初次实施、未造成实际损害、行为人积极配合整改的情形。例如：首次使用他人证件影像但未通过核验、首次尝试代认证但被系统拦截、单次异常交易被及时发现。
- 中度滥用：已造成一定损害或风险、行为人态度消极但尚未构成违法犯罪的情形。例如：多次尝试绕过核验、购买少量实名信息用于注册、参与小规模刷单、账户存在持续异常交易模式。
- 重度滥用：已造成较大损害、具有明显组织化特征或涉嫌违法的情形。例如：组织化代认证、批量倒卖实名信息、利用实名账户为电诈/赌博提供通道、实施大规模洗钱。
- 特别严重滥用：已造成重大损害或社会危害、涉嫌刑事犯罪的情形。例如：伪造国家机关证件、大规模侵犯公民个人信息、参与电信网络诈骗犯罪、造成重大经济损失或恶劣社会影响。
三、阶梯式处置措施清单
重点提示：下列事项说明本协议涉及的处置类型。具体措施须有法律依据、有效合同或已公示规则支持，并与已经核实的事实、权限及风险相称；列举不表示各功能已开放或平台可当然采取全部措施：
- 警示与整改：向用户发送警示通知，要求在指定期限内整改违规行为。
- 二次核验：要求用户重新完成身份核验，包括但不限于人脸识别、证件提交、活体检测。
- 功能限制：限制或关闭账号的部分功能，包括发布、交易、提现、转账、评论、私信等。
- 暂停服务：在必要范围内暂时限制相关功能，明确复核条件并在风险消除后及时调整。
- 资金事项：如实际涉及结算，延迟或限制资金处理须由有权主体依据有效规则、合同和法律办理；本协议不授予平台当然冻结或暂扣资金的权力。
- 账户终止：确需终止有关账户时，应依法处理既有交易、个人信息和救济请求；终止不等于永久禁止再次注册。
- 列入风险名单：如实际建立风险记录，须有合法处理依据、必要范围、适用期限及纠错机制；不得凭设备或网络共同特征自动限制无关用户。
- 再次注册：应按届时有效的注册、身份核验和风险管理规则判断，不设概括性的永久拒绝。
- 移送监管与司法：将涉嫌违法犯罪的线索、证据依法移送公安机关、网信部门或其他主管部门。
四、比例原则与事先/事后告知
平台采取的处置措施应与滥用行为的性质和严重程度相适应，遵循比例原则。除涉及重大安全风险、涉嫌违法犯罪或依据主管部门要求的紧急情形外，平台将在采取措施前或措施采取后合理期限内，通过站内通知、短信或其他合理方式告知用户处置原因、依据与救济途径。
五、误判纠错与解除机制
平台建立误判纠错机制。用户对处置有异议的，可通过平台公示的申诉渠道提交相反证据。平台将在合理期限内复核，核实确属误判的，将及时解除相应措施、恢复账号状态，并对因误判给用户造成的合理损失予以适当补偿。本条不构成平台对正常风控判断承担赔偿责任的承诺。
六、追责总则
因滥用行为发生争议或损失时，各方责任须依据有效约定、实际行为、损害、因果关系、过错及适用法律分别判断；不能预先把全部成本、行政责任或第三方主张转由某一方承担。涉嫌违法犯罪的线索依法移送有权机关。平台是否承担自身责任，也须依其实际履行的义务与适用法律判断，本协议不设概括免责。
相关法律依据：《网络安全法》第二十六条、第六十四条、《个人信息保护法》第五条、第六条、第四十七条、第五十一条、《反电信网络诈骗法》第二十一条、《互联网用户账号信息管理规定》第九条、第十四条、《民法典》第一千零三十四条、第一千零三十五条。
七、典型滥用场景示例（非穷尽列举）
为帮助你更好地理解本章及第十五章至第十九章所列滥用行为的认定标准，以下列举部分典型场景。以下列举仅为示例，不构成对滥用行为范围的穷尽定义，平台有权根据具体情况合理认定其他滥用行为：
- 场景一：注册信息与使用人分离。甲使用自己的身份证完成实名认证后，将账号转让给乙经营使用。乙在使用过程中产生了大量交易纠纷和投诉。此情形下，甲构成"出借实名信息"（第十五章），乙构成"使用他人实名账号"（第十五章），双方均需承担相应责任。甲、乙的责任应分别结合实际行为、知情状态、损害和法律判断。
- 场景二：利用自动化工具批量注册。某团队使用群控设备与自动化脚本，在短时间内注册了大量账号用于刷量、引流。此情形构成批量注册（第十六章），平台应逐一核对相关账号与设备的风险，再依法采取与事实相称的处置；不因同一网络环境自动注销全部账号。参与技术开发、设备提供与资金支持的人员均可能被追究责任。
- 场景三：使用AI换脸通过活体核验。丙购买了某深度伪造服务，将自己的人脸替换为丁的人脸，通过了活体检测。此情形构成证件伪造与深度伪造对抗（第十七章），属于重度滥用。平台可在核实后采取相称的账号措施；涉嫌违法犯罪的线索依法律移送有权机关。
- 场景四：组织化代认证服务。某团伙招募人员提供身份证件，由团伙统一完成认证后批量出售。此情形构成代认证与实名信息倒卖（第十八章），属于特别严重滥用。组织者及参与者的处置应根据可核实事实、具体作用和适用法律分别判断；涉嫌犯罪的线索依法移送。
- 场景五：利用实名账户进行洗钱。戊通过购买多个实名账号，将非法资金分散转入各账号进行归集、拆分、转移。此情形构成平台功能滥用（第十九章），涉嫌洗钱犯罪。平台可依法采取必要的账号风险措施；资金处理须有合法依据和权限，涉嫌犯罪线索依法移送。
- 场景六：伪造企业资质认证。己使用伪造的营业执照完成企业认证，冒充正规商家收取货款后消失。此情形同时涉及证件伪造（第十七章）与企业商户认证违规（第六章），属于特别严重滥用。平台可根据核实结果依法处理账号；资金措施须有合法依据，涉嫌犯罪线索依法移送。
- 场景七：为规避处罚而重复注册。庚因违规被处置后，使用不同手机号和新的身份证件重新注册账号继续违规。此情形构成规避处置的滥用行为（第十六章/第二十章），应分别核查关联账号与实际行为，在必要且相称的范围内依法采取限制或纠错措施。
- 场景八：利用实名账户为赌博平台引流。辛利用其已认证的商家账号发布赌博网站链接或二维码，为赌博平台引流。此情形构成平台功能滥用（第十九章），涉嫌开设赌场罪的共犯。平台可依法采取与事实相称的账号措施；涉嫌犯罪的线索依法向有权机关报告。
- 场景九：大规模倒卖人脸识别数据。某技术人员利用职务便利获取大量用户人脸数据后出售。此情形构成侵犯公民个人信息罪，属于特别严重滥用。平台应依法开展安全事件处置、必要告知及调查配合；账号措施须针对实际责任主体。
- 场景十：跨平台账号关联滥用。壬在A平台违规后，使用相同身份信息在逸薯云注册并继续违规活动。只有在依法获得相关信息且具备实际共享机制时，平台方可将跨平台线索纳入核验；单凭其他平台记录不当然限制新账号。
八、滥用行为的举证与认定规则
平台在认定滥用行为时，应依据合法取得且可以核对的具体证据，并依法保障用户的说明与异议机会：
- 平台侧举证：平台应保留认定滥用行为的合理证据，包括但不限于系统日志、核验记录、交易记录、设备信息、行为模式分析结果等。保存期限应以适用法律、处理目的和最短必要原则确定；保存期限依适用法律及处理目的分别确定。
- 用户侧举证：用户可提交与具体处置有关的说明或已有证据；平台不能仅因用户未能自证不存在滥用，便免除自身对处置事实与依据的说明责任。
- 举证责任转移：不同程序中的举证责任依适用法律和具体争议确定；风险线索可触发必要核查，但不能由本协议概括转移法定举证责任或直接确定最终责任。
- 证据形式：电子记录的真实性、完整性和证明力应依法判断；鉴定或核查费用由谁承担，也须依据实际程序和适用法律确定。
补充说明：从事实到处置的分层判断
面对疑似滥用，应先区分事实是否已经查明、是否存在继续损害风险，以及现行规则是否覆盖该行为。提醒补正、暂缓新申请、限制特定功能、冻结账户与终止服务，影响程度逐级增加，不能因为目录中列有某项措施就视为平台对所有情形均可直接采用。紧急防护可能需要先行，但后续仍要复核事实、期限和范围，避免临时措施长期持续而无独立依据。
证据之间也有层次：用户主动提交的资料、服务商返回的结论、系统日志、第三方投诉与自动风险分数，并非相同的证明材料。作出重要决定前应看其来源、完整性、是否相互印证及是否有合理的相反解释。用户能够提供的材料应围绕争议事实，不能以难以取得内部日志作为当然不利推定；平台自身掌握的关键记录也不能只作概括结论而拒绝必要说明。
纠错机制应覆盖误判、事实变化和措施已经完成目的等不同情形。解除某一功能限制，不代表其他独立争议已经解决；维持某项风险限制，也不能当然否定用户对个人信息提出查询、更正等法定请求。是否需要赔偿、恢复资源或更正记录，应分别依据实际损害和法律判断。本节不新设永久禁入、自动没收或概括转移举证责任的规则。
处置前应先分辨技术异常、资料错误、未经授权操作与有证据支持的故意滥用。一次失败、同一网络地址或设备被多人使用，只能作为需要进一步核对的线索，不能自动证明身份买卖或欺诈。措施应与核实程度和实际风险相称，并区分暂缓认证、限制特定功能和关闭账户的影响；用户依法应获得的说明、复核与救济路径不能因风险标签而被概括排除。涉及支付或交易资金的处理，还须由有权限的主体依据适用合同和法律分别判断。
本章情境释义（不新增权利义务）
以下情境围绕滥用分级处置说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
首次资料矛盾
适用事实。以“首次资料矛盾”为例，应先明确优先确认是否误填，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“首次资料矛盾”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“优先确认是否误填”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对首次资料矛盾，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“首次资料矛盾”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“优先确认是否误填”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解优先确认是否误填时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。首次资料矛盾可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
多次规避核验
适用事实。以“多次规避核验”为例，应先明确结合历史记录分析，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“多次规避核验”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“结合历史记录分析”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对多次规避核验，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“多次规避核验”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“结合历史记录分析”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解结合历史记录分析时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。多次规避核验的名称只是阅读辅助，真正需要判断的是结合历史记录分析如何影响用户可提交针对具体认定的说明与证据。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
重大安全威胁
适用事实。以“重大安全威胁”为例，应先明确可按条件先行保护，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“重大安全威胁”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“可按条件先行保护”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对重大安全威胁，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“重大安全威胁”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“可按条件先行保护”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解可按条件先行保护时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。滥用分级处置关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。重大安全威胁如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
关联账号被限制
适用事实。以“关联账号被限制”为例，应先明确核查是否独立使用，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“关联账号被限制”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“核查是否独立使用”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对关联账号被限制，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“关联账号被限制”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“核查是否独立使用”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核查是否独立使用时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。关联账号被限制可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
风险已排除
适用事实。以“风险已排除”为例，应先明确及时调整或解除措施，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“风险已排除”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“及时调整或解除措施”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对风险已排除，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“风险已排除”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“及时调整或解除措施”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解及时调整或解除措施时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。风险已排除的名称只是阅读辅助，真正需要判断的是及时调整或解除措施如何影响用户可提交针对具体认定的说明与证据。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
恶意申诉怀疑
适用事实。以“恶意申诉怀疑”为例，应先明确也需合理证据，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“恶意申诉怀疑”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“也需合理证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对恶意申诉怀疑，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“恶意申诉怀疑”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“也需合理证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解也需合理证据时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。滥用分级处置关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。恶意申诉怀疑如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
司法机关介入
适用事实。以“司法机关介入”为例，应先明确按法定权限和期限处理，再从处置程度应与证据、风险和损害相适应这一原则出发理解本章关于滥用分级处置的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“司法机关介入”这一情境中，需要分辨的是事实基础、风险级别、紧急性及是否重复，并核对“按法定权限和期限处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕事实基础、风险级别、紧急性及是否重复说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对司法机关介入，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合用户可提交针对具体认定的说明与证据这一相关事项，决定是否申请调整与风险相称的处置。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“司法机关介入”时，应以处置程度应与证据、风险和损害相适应为出发点，核对事实基础、风险级别、紧急性及是否重复及其他可核实的记录，再结合“按法定权限和期限处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解按法定权限和期限处理时，应同时守住本章边界：轻微疑点不自动等于严重违法结论。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。司法机关介入可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十一章 账户生命周期管理：限制、冻结、解冻与注销
一、总则
实名认证账户的生命周期管理是平台安全运营的重要组成部分。本章对账户从功能限制、冻结到解冻、注销及实名信息解绑的完整生命周期规则与程序作出系统规定，旨在平衡平台安全管控需要与用户合法权益保护。平台依据《网络安全法》第二十六条、《个人信息保护法》第十九条、第四十七条及《互联网用户账号信息管理规定》第九条的规定行使账户管理权。
二、功能限制
当出现以下情形时，平台有权对账户实施功能限制，限制范围与程度应与风险程度相适应：
- 认证信息存在疑问或不一致，需进一步核验的；
- 账户行为触发风控规则，存在异常交易、异常登录或可疑操作的；
- 用户未按要求及时更新认证信息的；
- 用户涉嫌违反本协议或平台规则，需进一步调查核实的；
- 监管部门或司法机关要求采取限制措施的。
功能限制应针对实际开放且与具体风险有关的功能，并说明可公开的原因、影响范围和解除或复核条件。本协议不表示平台已提供提现、转账、信用等级或分级认证等能力，也不授权仅凭身份疑点处理用户资金。
三、账户冻结与解冻
重点提示：在以下情形下，平台有权对账户实施冻结，暂停全部或部分服务：
- 经初步核实，存在冒用身份、代认证、账号买卖等严重违规嫌疑的；
- 账户涉嫌参与洗钱、诈骗、赌博等违法犯罪活动的；
- 监管部门或司法机关要求冻结的；
- 用户申请冻结账户以保护自身权益的（如账户被盗）。
冻结期限根据具体情形确定，一般不超过调查所需的合理期限。平台应在法律允许范围内以合理方式说明冻结原因、预计期限或复核条件及申诉途径。用户可通过平台申诉渠道申请解冻，需提交身份证明及相关证据。平台核实后，符合解冻条件的将在合理期限内予以解冻；不符合条件的，将告知用户原因并说明后续处理方案。在涉及违法犯罪或监管要求的情形下，冻结期限以有关部门的要求为准。
四、账户注销
重点提示：用户有权申请注销其实名认证账户。注销前，平台将以显著方式提示以下事项：
- 注销后的账户恢复、实名绑定与必要记录保存，应依实际系统能力、依法有效的规则及法定留存要求处理；
- 注销前应处理完毕账户内的待结算资金、未完成交易、未使用权益等事项；
- 注销不影响注销前已产生的权利义务及应继续履行的条款效力；
- 法律法规规定应继续保存的信息，将在法定期限届满后予以删除或匿名化。
平台收到注销申请后，应核验申请人身份并依法处理。存在未完成交易、依法应保存的记录或有权机关提出的合法要求时，应区分账户停止使用、个人信息删除与必要资料继续保存，向用户说明仍需处理的事项；不宜仅因存在投诉或诉讼而概括拒绝注销。涉及交易款项的处理应依据实际合同、支付规则和有权主体的权限办理。
五、实名信息解绑与换绑
实名认证信息与账户的绑定关系一经建立，原则上不支持随意解绑或换绑。在以下特殊情形下，用户可申请解绑或换绑：
- 原认证证件已更换（如身份证到期换发、姓名合法变更等），需更新绑定信息的；
- 企业主体发生合并、分立、转让等法律事实，需变更认证主体的；
- 经平台核实确认原认证存在错误的。
解绑或换绑需提交有效证明材料，经平台审核通过后方可执行。平台对解绑或换绑设置合理限制，防止被滥用于规避处置或转移违规记录。
六、实名信息的法定留存
账户注销或解绑后，依据《个人信息保护法》第十九条关于保存期限的规定，平台对法律法规要求留存的实名认证信息（包括认证记录、核验日志、风控记录等）将在法定期限届满后予以删除或匿名化处理。在此期间，该等信息仅用于履行法定义务，不会用于其他目的。
相关法律依据：《网络安全法》第二十六条、《个人信息保护法》第十九条、第四十七条、《互联网用户账号信息管理规定》第九条。
七、账户处置的详细程序与时限
为保障用户知情权与救济权，平台将根据风险程度、法律法规、监管要求、材料完整性及实际处理能力，按照以下一般程序处理账户处置事项；法律法规、监管要求或紧急风险处置另有要求的，从其规定：
- 功能限制：平台可在法律及监管允许的范围内，通过合理方式告知限制的原因、范围和救济渠道；用户可提交异议材料，平台将在合理期限内处理。
- 账户限制：对具体紧急风险，平台可依法先行采取必要的暂时措施，并在允许时及时说明依据、复核条件及救济渠道；其他情形应按风险与用户权益确定适当通知方式。账户限制的持续时间须与实际风险相称，不能仅因资料仍处于法定保存期限而继续限制账户。
- 解冻申请：用户可按平台公示渠道提交身份验证与相关证明材料；平台在收到完整材料后，将结合核验结果、风险状态及外部限制情况，在合理期限内决定是否解除或调整措施。
- 账户注销：用户申请注销的，平台可进行身份验证、未完成交易处理、未结清款项结算及法定留存核查。满足法定及平台公示条件的，平台将在合理期限内完成相应处理；注销不影响依法应留存的信息及已产生的权利义务。
- 平台主动终止与关联账户：对严重违规账户，应依据可核实事实、有效规则和适用法律判断是否终止服务。相同身份、设备或网络环境仅为核查线索，不当然证明其他账户违规；对其他账户采取措施须分别说明具体风险与依据，并提供适用的异议途径。
八、特殊情形下的账户处置
以下特殊情形适用专门的处置规则：
- 司法冻结与执行：收到人民法院、公安机关、检察机关等有权机关依照法定程序提出的冻结、执行或协查要求时，平台将依法配合执行；法律、监管要求或案件性质不允许事前告知的，平台无需事前通知，并将在法律及监管允许的范围内适时向用户说明。
- 监管指令处置：收到网信、市场监管、税务等主管部门的处置指令时，平台将在指令要求的期限内完成处置，并保留处置依据以备审计。
- 安全事件应急处置：在发生重大安全事件（如系统入侵、数据泄露）时，平台有权对可能受影响的账户实施必要、适度的临时保护性限制，并在风险消除或处置条件具备后根据实际情况调整或解除。
- 用户死亡或丧失行为能力：用户死亡或被宣告为无民事行为能力人/限制民事行为能力人的，其近亲属或法定代理人可凭有效证明材料申请依法办理账户信息查询、数据导出或账户注销。平台将在核验申请人身份、关系及法定条件后，于合理期限内处理。
账户状态变化的阅读顺序
用户在页面看到“待认证”“已认证”“受限”或“注销申请中”，应先确定这些字样分别对应身份结果、账户使用权限还是注销进度。不同状态可能同时存在；把它们放在一条单向流程中，容易误解用户当前可以做什么。以下例子只解释核对顺序，不新增产品页面或自动处理机制。
- 申请待处理：核验结果尚未形成时，应确认本次会话是否仍有效、是否已有付费订单以及用户可否安全地继续原申请。重复发起可能形成多个记录，不能凭数量增加直接推定恶意申请。
- 认证通过但功能受限：身份匹配成功不等于其他业务风险已经解除。需要说明限制来自哪项服务规则、影响哪些操作，不能让用户误以为再提交同一证件即可解决无关的交易或安全问题。
- 认证记录存在错误：若姓名、状态或账户关联有误，应先确认更正的是显示内容、认证结论还是账户控制权。更正错误不必然要求注销账户；注销账户也不当然更正先前错误的认证记录。
- 限制解除：解除一项措施后，用户应能依据实际页面核对受影响功能是否恢复；若仍有其他独立限制，平台应避免将其隐藏在原先的实名原因之下。历史审计记录的必要留存与当前功能恢复可以并存。
- 注销及再次申请：注销生效、数据清理、订单结算和同一证件再次注册各有独立条件。需要查明当时设置、法定留存及争议事实，既不承诺立即全部消除，也不预先规定永久不得再申请。
补充说明：限制、冻结与注销的不同效果
限制某项功能、冻结账户登录以及注销账户，所改变的权益不同。某次认证待复核，未必需要中断用户已购买的全部服务；某个账户暂时无法登录，也不意味着交易争议、余额处理或个人信息留存已经结束。确定措施时，应分别说明受影响的对象、原因、开始状态和可复核路径，并将身份核验结论与其他服务合同的履行分开判断。
用户申请注销时，应核对是否由有权人提出、是否存在尚未处理的订单或法定留存事项，以及当前产品是否提供对应的自助入口。注销后重新注册能否再次使用相同实名信息，受当时设置、合法运营规则和具体风险事实影响；不能预先写成永久禁止，也不能保证一旦注销就立即解除全部关联。对旧账户的合法债权债务或证据保存需求，应依有效依据处理。
解除冻结也不是注销的反向操作。复核确认疑点已消除时，可以讨论恢复受限能力；如账户控制仍有争议，可能需要先确认本人身份与安全状态。恢复功能不应自动修改认证历史，而保留历史也不应妨碍更正错误记录。涉及未结资金、运行资源或第三方权益的事项，要另外依对应规则处理；本章不新增统一冻结期限或资金处置权限。
账户被限制、认证结果失效和账户注销，处理的是不同对象。暂时限制部分功能不意味着身份资料必须立即销毁；注销账户也不当然抹去依法需保存的交易和争议记录。用户完成补正或复核后，平台应根据限制原因是否仍存在判断是否恢复相关功能。对依法依约关闭的账号重新注册，应依《互联网用户账号信息管理规定》采取必要措施；不能仅凭姓名相同或证件号码曾出现就将任何后续申请永久排除，具体处置还须结合真实规则与事实。
注销申请可能与尚未完成的支付订单、仍在运行的云资源或用户提出的数据删除请求同时存在。平台应分别说明这些事项的处理路径：订单和资源依其合同处理，账户使用资格依注销规则处理，个人信息依法按类别判断是否删除或保留。用户请求注销，不表示放弃退款、申诉或其他已经产生的权利；需要保存少量争议证据，也不意味着可以继续为认证之外的目的使用全部身份资料。
本章情境释义（不新增权利义务）
以下情境围绕账户生命周期说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
风险提示期
适用事实。以“风险提示期”为例，应先明确功能限制不等于永久封禁，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“风险提示期”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“功能限制不等于永久封禁”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对风险提示期，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“风险提示期”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“功能限制不等于永久封禁”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解功能限制不等于永久封禁时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。风险提示期可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
账户冻结
适用事实。以“账户冻结”为例，应先明确核实范围和持续依据，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账户冻结”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“核实范围和持续依据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账户冻结，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账户冻结”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“核实范围和持续依据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核实范围和持续依据时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。账户冻结的名称只是阅读辅助，真正需要判断的是核实范围和持续依据如何影响通过正式入口提出相应申请并核对身份。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
请求解冻
适用事实。以“请求解冻”为例，应先明确提交能够说明风险已排除的证据，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“请求解冻”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“提交能够说明风险已排除的证据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对请求解冻，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“请求解冻”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“提交能够说明风险已排除的证据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提交能够说明风险已排除的证据时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。账户生命周期关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。请求解冻如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
申请注销
适用事实。以“申请注销”为例，应先明确先处理未完成订单与权益，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“申请注销”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“先处理未完成订单与权益”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对申请注销，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“申请注销”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“先处理未完成订单与权益”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先处理未完成订单与权益时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。申请注销可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
证件换发
适用事实。以“证件换发”为例，应先明确区分信息更新与身份换绑，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“证件换发”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“区分信息更新与身份换绑”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对证件换发，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“证件换发”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“区分信息更新与身份换绑”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分信息更新与身份换绑时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。证件换发的名称只是阅读辅助，真正需要判断的是区分信息更新与身份换绑如何影响通过正式入口提出相应申请并核对身份。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
解除错误绑定
适用事实。以“解除错误绑定”为例，应先明确保留必要调查记录，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“解除错误绑定”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“保留必要调查记录”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对解除错误绑定，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“解除错误绑定”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“保留必要调查记录”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解保留必要调查记录时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。账户生命周期关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。解除错误绑定如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
司法冻结
适用事实。以“司法冻结”为例，应先明确以有权机关有效要求为准，再从限制、冻结、解冻、注销和实名换绑具有不同法律效果这一原则出发理解本章关于账户生命周期的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“司法冻结”这一情境中，需要分辨的是账户状态、未完成交易、资金与法定留存依据，并核对“以有权机关有效要求为准”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕账户状态、未完成交易、资金与法定留存依据说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对司法冻结，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过正式入口提出相应申请并核对身份这一相关事项，决定是否申请限制解除、信息更正或账户注销。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“司法冻结”时，应以限制、冻结、解冻、注销和实名换绑具有不同法律效果为出发点，核对账户状态、未完成交易、资金与法定留存依据及其他可核实的记录，再结合“以有权机关有效要求为准”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以有权机关有效要求为准时，应同时守住本章边界：注销不自动消灭既有债权债务也不等于永久禁注册。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。司法冻结可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十二章 特殊主体认证：个体工商户、外籍人士、港澳台居民及其他组织
一、总则
重点提示： 当前个人认证入口并不证明平台已为个体工商户、外籍自然人、港澳台居民、事业单位或社会组织开放相应认证渠道。本章仅供这些类型将来实际开放时核对适用的材料、核验方式与法律条件；未开放前不得据此要求用户提交额外资料或推定已获得相关服务。平台依据《网络安全法》第二十六条、《电子商务法》第二十七条及《互联网用户账号信息管理规定》第九条的规定，对各类特殊主体实施与其风险等级相匹配的核验措施。
二、个体工商户
当前个人入口不构成个体工商户认证。若以后开放对应入口，平台应区分经营者本人身份与经营主体登记状态，并在申请页面说明实际需要的登记资料、经办授权及核验依据。经营者个人完成实名，不当然使其经营主体获得商户资格或适用未展示的交易规则。
三、外籍自然人
当前居民身份证号码校验不能证明已支持护照、外国人永久居留身份证或其他证件。若开放外籍自然人认证，平台应先确认服务商支持的证件类型、字段格式和处理目的，再按最少必要原则说明所需资料；不得让用户把护照号码填入居民身份证专用字段，或为满足未开放的流程提交完整证件影像。
四、港澳台居民
港澳台居民可使用的证件类型应以实际开放的核验入口为准。居住证、通行证等证件的号码格式、签发信息与适用数据源可能不同，平台应在提供相应方式前核实可用性并清楚说明；本协议不预设某类证件优先受理，也不以证件种类本身推定申请人的交易风险。
五、事业单位与社会组织
事业单位、社会团体、基金会等组织若需认证，平台应按实际入口和适用法律核对组织登记状态、经办权限及必要的代表信息。自然人的个人实名认证不能替代组织认证；组织资料中包含经办人或代表人的个人信息时，仍应按合法、正当、必要原则处理，并向相关个人履行适用的告知义务。
六、军人及武装警察
本协议不表示平台已开设军人或武装警察专用认证渠道，也不要求用户通过普通个人入口提交军人证件、部队证明或岗位资料。若相关身份核验以后依法开放，应以实际服务需要、信息安全要求和可用核验方式确定最少资料；不应因为用户职业身份而概括收集与本次认证无关的信息。
七、临时来华人员
临时来华人员的证件与联系方法可能与居民身份证入口不同。是否可以申请、需要何种证件及有效期，应在实际开放的流程中说明。短期停留不当然造成既有认证失效；平台不以本协议要求用户提供未经核实必要性的公证地址、紧急联系人或其他人的个人信息。
八、组织授权代办
组织如允许经办人代为提出申请，应核实组织本身、经办人的身份及其授权范围。法定代表人本人办理、受权员工办理与无权第三人冒用组织名义，法律后果可能不同；平台不能仅因上传一份授权文件就免除合理核查义务。具体材料由实际开放的组织入口说明，不以本节设立统一的证照影像或视频核验要求。
九、特殊主体的共同边界
任何实际开放的特殊主体入口均应与相应证件类型、用户资格和服务商能力相匹配。平台可依法核查资料真实性及申请权限，但应说明所需信息与核验目的之间的关系；不得将未开放的技术方式、未提供的组织服务或未经说明的差异化限制解释为用户已经接受的义务。
相关法律依据：《网络安全法》第二十六条、《电子商务法》第二十七条、《互联网用户账号信息管理规定》第九条。
补充说明：特殊主体适用以前先确认入口
现有个人认证接口校验中国居民身份证号码，申请字段是姓名、证件号码与服务商选择。外籍人士、港澳台居民、军人、个体工商户或组织的资料类型虽在本章讨论，但不能据此推定当前入口接受其证件或营业执照。正式提供任何特殊主体认证前，应先有相应页面、技术校验、必要告知和经过核实的处理流程，而不是要求用户把其他证件号码填进现有身份证栏。
同一人兼具多个身份时，也须区分自然人本人、经营者和组织经办人的不同角色。例如个体工商户经营者以个人名义完成认证，并不自动使经营主体资料获得核验；组织法定代表人通过个人核验，也不替代对代表权限和组织存续状态的确认。是否能在账户之间转用结果，应看实际业务规则和原处理目的，不能因为姓名一致就无条件复用所有材料。
特殊证件可能在姓名顺序、字符、有效期和签发机关上与居民身份证不同。如果以后开放相应方式，平台需要核对服务商能力及所需最少字段，避免让无法满足格式检查的用户反复提交同一资料。当前无法使用现有入口的用户可咨询已公示渠道；具体可用方式和受理安排以实际开放的入口为准。
申请人使用非居民身份证件时，页面的字段格式本身可能阻止其进入核验流程。这样的失败仅说明当前入口无法处理该证件，不应记录成证件虚假或申请人违规。平台如果以后增加其他证件类型，应先核对服务商对姓名字符、证件号码、有效期和签发地的处理能力，并设计对应的纠错方式。由经办人代组织申请时，还需区分经办人的个人身份核验与组织对其授权是否有效，不能让一项通过自动替代另一项。
本章情境释义（不新增权利义务）
以下情境围绕特殊主体的条件性规则说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
外籍人士护照
适用事实。以“外籍人士护照”为例，应先明确先确认该证件是否被支持，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“外籍人士护照”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“先确认该证件是否被支持”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对外籍人士护照，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“外籍人士护照”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“先确认该证件是否被支持”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先确认该证件是否被支持时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。外籍人士护照可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
港澳台居民证件
适用事实。以“港澳台居民证件”为例，应先明确区分证件种类及适用场景，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“港澳台居民证件”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“区分证件种类及适用场景”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对港澳台居民证件，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“港澳台居民证件”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“区分证件种类及适用场景”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分证件种类及适用场景时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。港澳台居民证件的名称只是阅读辅助，真正需要判断的是区分证件种类及适用场景如何影响申请前先确认实际可用入口与材料要求。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
个体工商户
适用事实。以“个体工商户”为例，应先明确区分经营主体和经营者本人，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“个体工商户”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“区分经营主体和经营者本人”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对个体工商户，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“个体工商户”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“区分经营主体和经营者本人”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分经营主体和经营者本人时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。特殊主体的条件性规则关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。个体工商户如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
事业单位申请
适用事实。以“事业单位申请”为例，应先明确核实组织认证是否开放，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“事业单位申请”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“核实组织认证是否开放”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对事业单位申请，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“事业单位申请”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“核实组织认证是否开放”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核实组织认证是否开放时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。事业单位申请可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
军人证件
适用事实。以“军人证件”为例，应先明确仅在相应通道支持时使用，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“军人证件”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“仅在相应通道支持时使用”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对军人证件，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“军人证件”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“仅在相应通道支持时使用”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅在相应通道支持时使用时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。军人证件的名称只是阅读辅助，真正需要判断的是仅在相应通道支持时使用如何影响申请前先确认实际可用入口与材料要求。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
临时来华人员
适用事实。以“临时来华人员”为例，应先明确不能以短期停留替代资格，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“临时来华人员”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“不能以短期停留替代资格”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对临时来华人员，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“临时来华人员”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“不能以短期停留替代资格”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能以短期停留替代资格时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。特殊主体的条件性规则关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。临时来华人员如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
法定代表人代办
适用事实。以“法定代表人代办”为例，应先明确核对组织授权与本人身份，再从特殊证件或组织类型只有在实际认证渠道开放时才可使用这一原则出发理解本章关于特殊主体的条件性规则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“法定代表人代办”这一情境中，需要分辨的是届时支持的证件类型、主体文件与授权材料，并核对“核对组织授权与本人身份”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕届时支持的证件类型、主体文件与授权材料说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对法定代表人代办，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合申请前先确认实际可用入口与材料要求这一相关事项，决定是否确认实际支持的证件及主体类型。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“法定代表人代办”时，应以特殊证件或组织类型只有在实际认证渠道开放时才可使用为出发点，核对届时支持的证件类型、主体文件与授权材料及其他可核实的记录，再结合“核对组织授权与本人身份”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对组织授权与本人身份时，应同时守住本章边界：列举外籍或港澳台方式不表示当前个人入口支持。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。法定代表人代办可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十三章 生物识别信息（人脸与活体检测）专项规则
一、总则
人脸图像、活体检测数据等生物识别信息属于敏感个人信息，具有唯一性、不可更改性与高度敏感性。如平台基于特定认证类型接入人脸或活体核验，本章适用于该等处理活动，旨在落实《个人信息保护法》第二十八条、第二十九条、第三十条关于敏感个人信息处理的特别规则，以及《民法典》第一千零三十四条对生物识别信息的保护规定。
二、采集前的告知与单独同意
重点提示： 在平台或认证核验服务商采集人脸图像或活体检测数据前，相应处理者将以清晰、易懂的方式向用户单独告知以下事项：
- 采集目的：仅用于实名认证中的人证一致核验，确认操作人为本人；
- 采集方式：以届时认证页面实际展示的摄像头采集、活体检测或其他核验方式为准；
- 必要性说明：人脸核验仅在相应认证类型确有必要时用于防止身份冒用、保障账户安全；
- 对个人权益的影响：人脸信息一旦泄露可能被用于身份冒用或深度伪造，处理者将依法采取与风险相适应的保护措施；
- 用户的权利：用户有权拒绝提供人脸信息，但将无法完成需要人脸核验的认证类型。
如依法需要单独同意，相应处理者须通过与一般协议接受相区分的方式取得，不应使用默认勾选；未经依法取得的单独同意，不得仅凭本协议采集人脸等生物识别信息。本平台当前认证页面不采集人脸或活体信息。如跳转至第三方核验页面，应核对该页面实际处理者、告知内容和单独同意记录，不能预设第三方已经履行全部义务。
三、使用范围与目的限制
如处理人脸信息，其仅用于以下与核验直接相关的目的：
- 实时比对核验：将采集的人脸图像与身份证件照片进行1:1比对，确认操作人为证件持有人本人；
- 活体检测验证：确认采集到的人脸来自真实活体，而非照片、视频或深度伪造内容；
- 二次核验与风控复核：在账户存在风险疑点时，要求用户重新完成人脸核验以确认本人操作。
除法律法规另有规定或依法取得相应同意外，不将人脸信息用于商业化画像、广告推送、信用评分或其他与身份核验无关的目的。
四、存储、安全与删除
如平台或受托方存储人脸信息，相关存储与安全措施遵循以下原则：
- 最短必要留存：是否保留原始图像、比对结果和审计记录，以及各自的保存期限，须以实际处理方式、必要性、依法告知的期限及法定留存要求确定；不能将技术示例当作已经实施的删除承诺。
- 安全保护：根据法律法规、技术条件与风险状况采取相适应的存储保护、访问控制和必要的审计措施。
- 删除与匿名化：实际持有人应在处理目的已实现、保存期限届满或其他法定删除条件成立且无继续留存依据时，依法删除或匿名化其持有的人脸信息。平台不能承诺删除独立第三方自行控制的原始素材。
五、替代核验方案
重点提示： 用户无法或不愿提供人脸信息时，可查看届时实际认证入口是否提供其他可用方式，并可通过公示渠道询问。是否存在替代核验方式、适用的认证类型及所需信息，须以已开放的实际流程和依法告知的规则为准；本协议不承诺提供银行卡、运营商、人工视频或线下核验，也不授权据此新增信息收集。
六、人脸信息的特别保护承诺
平台及认证核验服务的受托方将仅在核验目的及法律允许的范围内处理人脸信息，不将人脸信息出售给第三方；如需用于训练人工智能模型、学术研究、非核验关联分析或其他超出核验目的的处理，将依法另行取得相应同意或具备其他合法处理基础。平台对人脸信息的处理依法承担相应责任；本协议中的任何责任限制均不排除、限制或免除依法不得限制或免除的责任。
七、生物识别信息的专项用户权利
鉴于生物识别信息的特殊敏感性，用户就人脸信息等生物识别数据享有以下专项权利：
- 知情与查询权：用户有权依法查询是否存储其人脸信息、存储用途、期限及必要的受托方信息；平台将在核验身份后依法律法规于合理期限内答复。
- 更正与补充权：人脸比对结果因拍摄条件、设备限制等原因可能不准确；用户可通过实际公示渠道提出异议。是否可以重新采集或改用其他方式，取决于实际开放的核验流程和必要性。
- 删除权：在法定留存期限届满或不存在其他合法留存基础时，用户可依法请求删除人脸原始图像；平台将在核验身份后依法律法规于合理期限内处理并反馈。
- 撤回同意权：用户有权依法撤回此前作出的同意。实际处理者应根据撤回范围停止继续依该同意进行的处理，并说明其他合法处理基础下仍需保存的资料；撤回不影响撤回前基于有效同意已进行的合法处理。若该方式必须使用人脸，撤回可能影响尚未完成的申请。
- 解释说明权：用户有权要求平台就人脸信息的处理规则、算法逻辑、安全措施等进行解释说明。平台在不泄露可被规避的风控细节的前提下，应以通俗易懂的方式进行说明。
八、算法准确性与公平性保障
如平台实际使用自动化人脸核验能力，平台可根据法律法规、业务规模、技术条件和风险状况采取适当措施评估其准确性与公平性，措施可能包括：
- 根据需要评估算法在不同用户群体中的识别表现，识别并合理处置可能的偏差；
- 在模型或服务能力调整时，根据需要开展相应测试或评估；
- 为符合条件的异议提供公示的复核渠道；
- 根据认证场景、风险评估和技术条件决定是否采用替代核验方式。
相关法律依据：《个人信息保护法》第二十八条、第二十九条、第三十条、第十九条、第四十七条、《民法典》第一千零三十四条、《网络安全法》第二十六条。
第三方人脸页面需要核对的问题
如用户实际进入包含人脸或活体步骤的第三方页面，平台和服务商应分别对自己控制的处理环节承担相应义务。理解相应流程时可按下列问题核对；这些问题并不表示当前平台直接采集了影像，也不承诺已经提供替代通道。
- 谁采集：摄像头权限由哪个页面请求、图像流向哪里、原始影像是否经过平台服务器，需要以实际技术链路确认。仅凭页面上显示平台品牌，不能推定平台可以读取或删除服务商持有的原始素材。
- 为何必要：人脸步骤是法律、服务商方式还是某项高风险业务所必需，应与具体认证目标相连。若只是技术选项之一，用户应从真实页面了解可选择的方式；若没有替代方式，也不应虚构线下人工通道作为拒绝人脸后的当然出路。
- 怎样同意：应看实际处理者是否清楚说明个人权益影响、是否依法取得单独同意，以及用户拒绝后该次申请如何结束。平台协议的统一勾选、服务商页面的继续按钮与摄像头权限请求，不应未经核查就被当作同一个有效同意。
- 返回什么：平台收到的是通过状态、相似度、影像，还是其他资料，应按接口和合同分别核实。只需要结果的业务，不应在协议中概括声称还会保留原始图像；若确实接收更多信息，应另外审查必要性、访问控制与留存。
- 失败如何解释：光线、设备、容貌变化或服务商故障都可能影响核验。单次失败不应自动被解释为故意伪造；用户能否重试或请求复核，应按实际开放渠道和安全要求说明。
补充说明：人脸核验只在真实流程中适用
当前平台认证页面不直接拍摄人脸或进行活体检测。若第三方核验页面在实际申请中要求拍摄，应先确定该页面由谁运营、采集的究竟是即时影像、特征信息还是核验结果，以及平台能够取得其中哪些内容。用户在平台输入姓名和证件号码的操作，并不能被解释为已对所有可能的生物识别处理作出单独同意。
人脸核验的必要性应就对应认证方式具体说明。仅列出“防止冒用”目的，不足以证明每种用户、每项服务都必须使用人脸；是否存在其他可行路径，还要以服务商能力、法律要求和实际开放入口核实。协议可以说明用户拒绝必要处理可能导致该方式无法完成，但不能把尚未提供的线下、人工或银行卡核验方案描述为已经可选择的替代途径。
如实际处理生物识别信息，原始影像、提取特征、比对分数和最终认证状态应分别看其用途及保存基础。平台若只收到结论，不应在用户说明中声称持有或可删除服务商的全部原始素材；服务商若独立决定其他用途，则需对其处理负责。错误比对、设备环境问题或用户容貌变化也可能影响结果，复核时应避免以单次失败推定用户身份不实。
生物识别资料一旦被泄露，风险通常难以像密码一样通过更换消除。因此，只有相应核验方式实际需要并满足敏感个人信息处理的法定条件时，才应收集相关资料；应明确实际处理者、必要性、保存方式以及用户如何行使权利。当前平台个人入口不直接收集人脸或活体信息；若用户被引导至第三方页面，应查看该页面的真实告知和选择。某一方式没有可用替代路径时，平台不应在协议中承诺已提供人工、线下或银行卡核验。
本章情境释义（不新增权利义务）
以下情境围绕生物识别专项保护说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
页面无相机权限
适用事实。以“页面无相机权限”为例，应先明确不能推定平台取得人脸，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“页面无相机权限”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“不能推定平台取得人脸”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对页面无相机权限，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“页面无相机权限”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“不能推定平台取得人脸”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能推定平台取得人脸时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
服务商要求活体
适用事实。以“服务商要求活体”为例，应先明确先阅读其独立告知，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务商要求活体”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“先阅读其独立告知”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务商要求活体，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务商要求活体”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“先阅读其独立告知”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先阅读其独立告知时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
拒绝刷脸
适用事实。以“拒绝刷脸”为例，应先明确核对是否存在可用替代路径，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“拒绝刷脸”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“核对是否存在可用替代路径”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对拒绝刷脸，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“拒绝刷脸”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“核对是否存在可用替代路径”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对是否存在可用替代路径时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
原始图像保存
适用事实。以“原始图像保存”为例，应先明确应确认实际处理者及期限，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“原始图像保存”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“应确认实际处理者及期限”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对原始图像保存，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“原始图像保存”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“应确认实际处理者及期限”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应确认实际处理者及期限时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
误识别
适用事实。以“误识别”为例，应先明确可提出复核与材料补充，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“误识别”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“可提出复核与材料补充”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对误识别，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“误识别”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“可提出复核与材料补充”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解可提出复核与材料补充时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
撤回人脸同意
适用事实。以“撤回人脸同意”为例，应先明确后续处理应按法律判断，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“撤回人脸同意”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“后续处理应按法律判断”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对撤回人脸同意，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“撤回人脸同意”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“后续处理应按法律判断”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解后续处理应按法律判断时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
人脸泄露疑虑
适用事实。以“人脸泄露疑虑”为例，应先明确向实际处理者请求说明，再从当前平台认证页面不采集人脸或活体信息这一原则出发理解本章关于生物识别专项保护的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“人脸泄露疑虑”这一情境中，需要分辨的是如跳转实际服务商页面时其告知、同意及处理范围，并核对“向实际处理者请求说明”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕如跳转实际服务商页面时其告知、同意及处理范围说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对人脸泄露疑虑，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在单独告知后自主决定是否接受相应核验这一相关事项，决定是否确认是否接受实际开放的核验方式。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“人脸泄露疑虑”时，应以当前平台认证页面不采集人脸或活体信息为出发点，核对如跳转实际服务商页面时其告知、同意及处理范围及其他可核实的记录，再结合“向实际处理者请求说明”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解向实际处理者请求说明时，应同时守住本章边界：替代方式是否存在取决于实际提供，不作普遍保证。
第二十四章 平台安全保障义务与技术管理措施
一、总则
平台在实名认证信息全生命周期承担安全保障义务，依据《个人信息保护法》第五十一条、《数据安全法》第二十七条及《网络安全法》第二十六条的规定，采取合理的技术措施与管理措施，保护用户实名认证信息的安全。
二、传输与存储安全
平台将在合理可行范围内采取符合行业通行标准的传输、存储与展示保护措施。具体措施可能包括加密传输、加密存储、去标识化或脱敏展示等，平台将根据业务规模、技术条件与风险状况选择适用的保护方式，并不在本协议中固定承诺采用某一特定算法、密钥管理方式或技术架构。
三、访问控制与审计
平台将在合理可行范围内建立与实名认证信息处理活动相适应的内部权限管理机制，努力控制可接触实名信息的人员范围，并根据业务需要留存必要的访问、查询或导出记录。员工离职或岗位变更时，平台将根据内部管理流程调整相应权限。
四、网络安全与漏洞管理
平台将在合理可行范围内采取与业务规模和风险状况相匹配的网络安全与漏洞管理措施。相关措施可能包括网络访问控制、异常监测、漏洞排查、风险缓解或修复等；具体措施的种类、强度和实施方式由平台根据实际技术条件、第三方组件状态、基础设施环境及风险评估结果确定。
五、等级保护与合规评估
平台将按照国家网络安全等级保护制度及个人信息保护相关规则，结合自身业务情况开展相应的定级、备案、建设整改、测评或个人信息保护合规评估等工作。相关工作是否开展、开展范围及开展方式，以法律法规要求、监管要求、业务规模、系统重要程度及平台实际情况为准。
六、内部人员管理
平台对能够接触实名认证信息的内部人员实施必要的管理措施，可能包括签署保密文件、开展数据安全与隐私保护培训、对违规访问或泄露实名信息的行为进行内部追责等。具体管理方式由平台根据岗位职责、业务规模及风险状况确定。
七、供应商安全管理
平台对涉及实名认证信息处理的第三方供应商（包括认证核验服务商、云服务提供商、IT运维服务商等）实施必要的安全管理，可能包括签订数据处理协议、约定安全义务与责任、根据需要评估供应商安全能力与合规状态、要求供应商不得超出约定范围处理实名信息等。
八、安全措施的性质与免责
重点提示： 平台应根据所处理信息的性质、风险和适用法律履行相应安全保障义务。发生信息泄露或安全事件时，应结合实际防护、管理措施、事件原因和损害判断责任；黑客攻击、第三方中断或用户账户问题不因列举而当然免除平台责任。本章不预先限制依法不得免除的责任。
九、安全技术架构详述
平台将结合实名认证信息处理活动的风险程度、业务规模、系统条件及技术发展，采取符合行业通行标准的安全技术与管理措施。相关措施可能覆盖网络访问控制、接口传输保护、数据存储保护、权限校验、日志记录、异常监测、敏感字段脱敏展示等方面。平台不在本协议中固定承诺采用某一具体安全产品、算法版本、网络架构、密钥管理工具、监控体系或终端检测方案；具体安全措施以平台实际部署、法律法规要求及风险评估结果为准。
十、等级保护与安全评估
平台将按照国家网络安全等级保护制度的相关要求，结合自身业务情况开展相应的定级、备案、建设整改与测评等工作，并根据系统的重要程度确定相应的安全保护等级。平台有权根据业务规模、法律法规要求及风险状况，自行决定是否开展以及如何开展安全评估与渗透测试。对于发现的安全漏洞，平台将在合理可行的范围内，根据漏洞的等级与影响范围采取相应的缓解或修复措施；用户理解，部分漏洞可能涉及第三方组件、操作系统、基础设施等平台无法单方控制的因素，其修复时间取决于多方配合，平台不对具体修复时限作出绝对承诺。
十一、内部安全管理
平台应建立与实际处理规模、信息敏感程度和风险相适应的内部安全管理制度。下列事项须核对实际执行情况，不因列举而视为已经部署：
- 对接触实名认证信息的员工实施背景调查、安全培训与保密协议签署。
- 实施最小权限原则，员工仅能访问其工作职责所必需的信息。
- 对敏感操作实施双人复核、操作留痕与定期审计。
- 员工离职时及时回收权限，确保其无法继续访问系统与数据。
- 定期开展安全意识培训与考核，提升全员安全素养。
十二、第三方安全评估
平台有权根据业务规模、法律法规要求及风险状况，自行决定是否引入第三方机构开展安全评估或审计，以及评估或审计的范围、方式与频次。在开展此类评估或审计时，内容可能包括但不限于系统架构安全性、渗透测试与漏洞扫描、数据处理合规性、安全管理制度执行情况等方面。相关评估或审计结果由平台作为内部安全改进的参考，除法律法规明确要求外，平台没有义务向用户提供或披露评估、审计的过程材料或报告。
十三、业务连续性与灾备
平台将采取合理的技术与管理措施，努力提升实名认证服务的稳定性与可用性。平台有权根据自身业务需要与技术条件，自行决定是否采用以及如何采用具体的高可用与灾备措施（例如多可用区部署、数据备份、异地容灾、灾难恢复演练、服务降级预案等）。用户理解，受技术水平、成本及现实条件的限制，任何服务均无法保证不间断、无故障或绝对可用，平台在尽到合理注意义务的前提下，不对服务的持续可用性作出绝对保证。
相关法律依据：《个人信息保护法》第五十一条、《数据安全法》第二十七条、《网络安全法》第二十六条。
补充说明：安全承诺需要对应已实施的措施
加密传输、访问权限、员工培训、漏洞修复和供应商管理分别控制不同环节的风险。本协议若写明具体技术措施，应能对应实际部署、适用系统和持续维护安排；不能把行业常见做法、待建设计划或第三方自行采取的措施写成平台对所有认证数据已完成的保护。原则性的安全义务也不能被解释为对任何攻击结果作出绝对保证。
认证资料从用户设备进入平台，再转交服务商或进入后台审核时，每一次访问都有不同的权限需求。审查安全边界时，应关注是否存在过度可见、误发给客服、导出范围过宽或测试环境复制真实资料等风险，并以实际系统核对。发现问题后的纠正也要落到具体数据流，不能仅凭协议中写有“采取措施”即认为风险已经消除。
用户自身应保护账号与设备，但安全事件的发生不应自动归因于用户。平台是否履行相应安全保障义务，需要看其控制范围、已知风险和实际措施；服务商问题亦须按真实角色与合同、法律确定责任。认证等级、审计频率和灾备能力只有在实际存在且与相应系统有关时才可作为具体安全安排说明，技术术语本身不证明资料已获得相应保护。
安全措施应与实际处理范围相匹配。若平台只接收核验结果，其访问控制重点与服务商保存原始影像的风险不同；若平台确实保存完整证件号码，应对相关访问、导出和更正操作设置与敏感程度相称的保护。合同或协议中列举某种技术，不能证明其已经覆盖全部历史系统和外部服务商。出现安全疑点时，应依真实日志、接口与供应商责任边界开展排查，并在适用法律要求的范围内采取补救与告知。
当核验服务商、平台后台和客服系统分别接触不同资料时，应以实际访问权限确定安全责任。平台能控制自己的传输接口和内部账号权限，但不能仅因与服务商合作就声称已经审计对方每一次原始影像访问。发现错误授权或过量导出时，应及时限制相应权限、核对受影响资料并按适用法律处理事件通知。用户就其资料提出查询或更正请求时，平台应说明自己持有的部分和由独立处理者控制的部分，避免给出超出控制能力的删除承诺。
本章情境释义（不新增权利义务）
以下情境围绕安全保障与管理说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
异常管理员访问
适用事实。以“异常管理员访问”为例，应先明确核对权限及审计记录，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“异常管理员访问”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“核对权限及审计记录”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对异常管理员访问，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“异常管理员访问”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“核对权限及审计记录”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对权限及审计记录时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。异常管理员访问可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
供应商接触资料
适用事实。以“供应商接触资料”为例，应先明确明确目的与访问范围，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“供应商接触资料”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“明确目的与访问范围”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对供应商接触资料，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“供应商接触资料”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“明确目的与访问范围”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解明确目的与访问范围时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。供应商接触资料的名称只是阅读辅助，真正需要判断的是明确目的与访问范围如何影响谨慎保管账号并通过正式渠道报告异常。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
传输故障
适用事实。以“传输故障”为例，应先明确区别可用性与保密性问题，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“传输故障”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“区别可用性与保密性问题”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对传输故障，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“传输故障”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“区别可用性与保密性问题”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区别可用性与保密性问题时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。安全保障与管理关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。传输故障如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
备份恢复
适用事实。以“备份恢复”为例，应先明确确认必要留存与权限，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“备份恢复”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“确认必要留存与权限”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对备份恢复，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“备份恢复”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“确认必要留存与权限”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解确认必要留存与权限时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。备份恢复可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
配置变更
适用事实。以“配置变更”为例，应先明确安全措施应随风险调整，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“配置变更”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“安全措施应随风险调整”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对配置变更，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“配置变更”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“安全措施应随风险调整”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解安全措施应随风险调整时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。配置变更的名称只是阅读辅助，真正需要判断的是安全措施应随风险调整如何影响谨慎保管账号并通过正式渠道报告异常。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
外部漏洞报告
适用事实。以“外部漏洞报告”为例，应先明确依法评估和补救，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“外部漏洞报告”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“依法评估和补救”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对外部漏洞报告，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“外部漏洞报告”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“依法评估和补救”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解依法评估和补救时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。安全保障与管理关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。外部漏洞报告如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
第三方攻击
适用事实。以“第三方攻击”为例，应先明确平台自身义务仍需审查，再从平台须按风险采取与业务规模相适应的安全措施这一原则出发理解本章关于安全保障与管理的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“第三方攻击”这一情境中，需要分辨的是实际系统边界、人员权限、供应商角色与风险，并核对“平台自身义务仍需审查”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际系统边界、人员权限、供应商角色与风险说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对第三方攻击，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合谨慎保管账号并通过正式渠道报告异常这一相关事项，决定是否报告安全疑点并请求说明。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“第三方攻击”时，应以平台须按风险采取与业务规模相适应的安全措施为出发点，核对实际系统边界、人员权限、供应商角色与风险及其他可核实的记录，再结合“平台自身义务仍需审查”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解平台自身义务仍需审查时，应同时守住本章边界：列举算法、设备或架构不等于固定技术承诺。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。第三方攻击可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十五章 个人信息安全事件应急响应与告知
一、总则
尽管平台已采取合理的技术与管理措施保护用户实名认证信息的安全，但受限于当前技术水平与外部威胁态势，安全事件仍可能发生。本章对实名认证信息发生泄露、篡改、丢失等安全事件时的应急响应、补救措施、告知义务与配合监管流程作出规定，旨在落实《个人信息保护法》第五十一条及《数据安全法》第二十七条规定的安全事件应对义务。
二、安全事件的定义与分级
本章所称"个人信息安全事件"，是指因人为攻击、技术故障、管理疏漏或不可抗力等原因，导致实名认证信息被泄露、篡改、丢失、毁损或被非法获取、利用的事件。平台根据事件的影响范围、涉及信息类型与严重程度，将安全事件分为以下级别：
- 一般事件：影响范围较小，涉及非敏感信息或少量用户，可通过常规手段快速处置的。
- 重大事件：影响范围较大，涉及敏感个人信息（如身份证件号码、人脸信息）或较多用户的。
- 特别重大事件：影响范围极大，涉及大量敏感信息或造成严重社会影响的。
三、应急处置与补救措施
发生实际安全事件时，平台应按事件性质、影响范围及适用法律及时启动相应处置，选择必要且可执行的措施，包括：
- 技术处置：隔离受影响系统，阻断攻击路径，修复安全漏洞，恢复系统正常运行。
- 影响评估：评估事件的范围、涉及的信息类型与数量、可能造成的损害。
- 证据保全：保全日志、系统状态、攻击痕迹等证据，为后续调查与追责提供依据。
- 补救措施：根据事件性质采取密码重置、会话失效、账户临时冻结等补救措施，降低用户受损风险。
四、告知义务
重点提示： 依据《个人信息保护法》关于个人信息安全事件告知的规定，平台在安全事件发生后将及时履行以下告知义务：
- 向受影响的个人告知：事件的种类与原因；泄露的信息类型与可能影响；已采取的补救措施；用户可采取的自我保护措施（如修改密码、警惕可疑联系等）；平台的联系方式与投诉渠道。
- 向监管部门报告：按照法律法规的要求，及时向网信部门、公安机关及相关主管部门报告安全事件。
告知的方式包括但不限于：站内通知、短信、邮件、电话或平台公告。告知的时间以法律法规规定的时限为准，法律法规未规定的，在事件确认后合理期限内完成。
五、用户侧配合义务
安全事件发生后，用户应配合平台采取的补救措施，包括但不限于：及时修改密码与安全设置；警惕可疑的电话、短信或邮件；发现异常情况及时向平台报告。
六、事后复盘与改进
安全事件处置完毕后，平台将开展事后复盘，分析事件原因、评估处置效果、总结经验教训，并据此完善安全措施与应急预案。平台将留存事件处置记录，作为合规审计与监管检查的依据。
七、安全事件分级标准
平台可根据影响范围、严重程度、紧急程度、法律法规及监管要求对个人信息安全事件进行分级，并据此确定与实际风险相适应的处置优先级：
- 特别重大事件：涉及大量敏感个人信息、造成重大社会影响或依法需紧急处置的安全事件，平台将优先组织处置、评估和依法报告。
- 重大事件：影响范围较大、涉及敏感个人信息或可能造成较高风险的安全事件，平台将根据风险状况组织相应处置并依法履行告知、报告义务。
- 较大事件：影响范围或风险程度处于中等水平的安全事件，平台将采取与风险相适应的处置、补救和跟进措施。
- 一般事件：影响范围较小且风险可控的安全事件，平台将根据具体情况采取必要处理措施。
八、用户通知的具体内容
平台向受影响用户发送的安全事件通知应包含以下内容：
- 事件发生的时间、涉及的信息类型与大致范围。
- 事件可能对用户造成的影响与风险。
- 平台已采取及拟采取的补救措施。
- 用户可采取的自我保护措施（如修改密码、警惕可疑联系等）。
- 平台的联系方式与用户咨询渠道。
- 用户向监管部门投诉举报的权利与渠道。
九、安全事件的证据保全
发生实际安全事件后，平台应在必要范围内保存依法取得的相关处置证据。证据种类和保存期限须依处理目的、适用法律及有权机关的合法要求确定；保存期限应依法按资料类别及处理目的确定，也不授权为证据保全无差别收集网络流量或其他个人信息。平台依法配合有权机关调查。
十、事后复盘与持续改进
每次安全事件处置完毕后，平台将组织专项复盘，形成事件报告，内容包括：
- 事件的根本原因分析，识别技术、流程或管理层面的薄弱环节；
- 应急响应过程的评估，总结有效做法与待改进之处；
- 针对根本原因制定具体的整改措施与时间表；
- 对安全策略、技术方案、应急预案进行针对性更新；
- 将事件教训纳入安全培训内容，提升全员安全意识。
平台将持续投入安全能力建设，通过技术升级、流程优化、人员培训等综合手段，不断提升安全事件的预防、检测与响应能力。
十一、用户通知渠道与响应
平台将根据安全事件的性质、影响范围、用户联系方式有效性及法律法规要求，选择适当渠道向受影响用户发送通知：
- 站内消息通知；
- 短信通知（发送至用户注册手机号）；
- 电子邮件通知（发送至用户注册邮箱）；
- APP推送通知（如用户已安装APP且开启推送权限）；
- 在平台官网发布安全公告（适用于影响范围较广的事件）。
用户应确保其联系方式的有效性与可送达性。因用户联系方式无效导致通知无法送达的，平台以最后一次成功发送的通知为准。用户在收到安全事件通知后，应按照通知建议采取相应的自我保护措施。
相关法律依据：《个人信息保护法》第五十一条、《数据安全法》第二十七条、《网络安全法》第二十六条。
补充说明：安全事件告知与具体影响
异常登录、服务商故障、资料被未授权读取和公开泄露，其影响和处置方式不同。出现疑似事件后，应先查明受影响的信息类别、用户范围、泄露或误用的可能性，以及哪些措施已经实际采取，再按适用法律判断是否需要向个人或主管部门告知。不能把每一次系统故障都说成个人信息泄露，也不能在风险尚未查清时承诺完全没有影响。
对用户的有效告知应帮助其理解实际风险和可采取的合理防护措施。例如证件号码可能被误用时，关注异常认证或账户活动比笼统提示“注意安全”更有帮助；如仅部分认证结果显示错误，则应说明更正和申诉方法。告知内容应避免再通过不安全渠道泄露完整证件号码，也不应让用户点击未经核实的外部链接提交更多敏感资料。
事件调查记录可用于复盘原因、补救和依法配合调查，但保留范围应与调查需要相称。用户是否遭受损失、平台是否承担责任，仍须结合实际事实判断；及时发出通知不当然免除其他法定义务。具体通知时间、渠道和内容必须依据届时有效法律及真实运营能力确定，平台应按适用法律和实际事件情况履行通知义务。
信息安全事件的调查与用户通知应围绕实际受到影响的信息类别、可能后果和已经采取的补救措施展开。仅因系统出现异常流量，不代表身份资料已经泄露；同样，没有发现外部下载记录，也不当然证明不存在未经授权访问。平台应依据可核实证据判断影响范围，及时履行适用的报告与通知义务。对用户提出的更正、删除或申诉请求，应分别处理，不能以事件调查尚未结束为由无期限搁置依法应回应的权利请求。
本章情境释义（不新增权利义务）
以下情境围绕个人信息安全事件说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
发现异常下载
适用事实。以“发现异常下载”为例，应先明确先确认数据与范围，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“发现异常下载”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“先确认数据与范围”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对发现异常下载，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“发现异常下载”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“先确认数据与范围”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先确认数据与范围时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。发现异常下载可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
服务商发生事故
适用事实。以“服务商发生事故”为例，应先明确查明共享关系和平台职责，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“服务商发生事故”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“查明共享关系和平台职责”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对服务商发生事故，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“服务商发生事故”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“查明共享关系和平台职责”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明共享关系和平台职责时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。服务商发生事故的名称只是阅读辅助，真正需要判断的是查明共享关系和平台职责如何影响收到通知后核对官方来源并采取必要自护。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
用户收到钓鱼通知
适用事实。以“用户收到钓鱼通知”为例，应先明确核对官方渠道，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“用户收到钓鱼通知”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“核对官方渠道”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对用户收到钓鱼通知，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“用户收到钓鱼通知”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“核对官方渠道”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对官方渠道时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。个人信息安全事件关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。用户收到钓鱼通知如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
证件号可能外泄
适用事实。以“证件号可能外泄”为例，应先明确评估身份冒用风险，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“证件号可能外泄”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“评估身份冒用风险”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对证件号可能外泄，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“证件号可能外泄”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“评估身份冒用风险”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解评估身份冒用风险时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。证件号可能外泄可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
误发通知
适用事实。以“误发通知”为例，应先明确及时澄清并保留记录，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“误发通知”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“及时澄清并保留记录”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对误发通知，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“误发通知”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“及时澄清并保留记录”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解及时澄清并保留记录时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。误发通知的名称只是阅读辅助，真正需要判断的是及时澄清并保留记录如何影响收到通知后核对官方来源并采取必要自护。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
事件范围扩大
适用事实。以“事件范围扩大”为例，应先明确持续更新告知内容，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“事件范围扩大”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“持续更新告知内容”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对事件范围扩大，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“事件范围扩大”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“持续更新告知内容”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解持续更新告知内容时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。个人信息安全事件关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。事件范围扩大如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
处置结束后
适用事实。以“处置结束后”为例，应先明确复盘并纠正已发现缺陷，再从安全事件应按事实、影响和法律要求处置与告知这一原则出发理解本章关于个人信息安全事件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“处置结束后”这一情境中，需要分辨的是受影响资料、用户范围、风险程度和补救状态，并核对“复盘并纠正已发现缺陷”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕受影响资料、用户范围、风险程度和补救状态说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对处置结束后，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合收到通知后核对官方来源并采取必要自护这一相关事项，决定是否核对事件通知并提出相应请求。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“处置结束后”时，应以安全事件应按事实、影响和法律要求处置与告知为出发点，核对受影响资料、用户范围、风险程度和补救状态及其他可核实的记录，再结合“复盘并纠正已发现缺陷”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解复盘并纠正已发现缺陷时，应同时守住本章边界：事件疑似信号不等于已确认泄露或用户有过错。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。处置结束后可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十六章 跨境提供的合规规则
一、适用原则
平台将根据适用法律法规、监管要求、业务需要及实际处理安排确定实名认证信息的存储与处理地点；如涉及向境外提供个人信息，平台将依法完成相应合规程序。本章不构成对特定数据存储地点、基础设施部署方式或不发生跨境提供的承诺。
二、跨境提供的合规前提
重点提示：如未来因业务发展确需向境外提供实名认证信息的，平台将严格遵守以下合规前提：
- 法定基础：依据《个人信息保护法》的规定，完成以下任一法定基础：通过国家网信部门组织的安全评估；按照国家网信部门的规定经专业机构进行个人信息保护认证；与境外接收方订立国家网信部门制定的标准合同；法律、行政法规或者国家网信部门规定的其他条件。
- 单独告知与同意：在跨境提供前，向用户单独告知境外接收方的名称或姓名、联系方式、处理目的、处理方式、个人信息的种类以及用户向境外接收方行使权利的方式等事项，并取得用户的单独同意。
- 安全评估：对境外接收方的数据保护能力进行评估，确保其个人信息保护标准不低于本法规定的标准。
三、用户的知情与权利
在跨境提供实名认证信息的情形下，用户有权：了解境外接收方的基本信息与数据保护能力；撤回对跨境提供的同意（撤回不影响撤回前已进行的合法处理）；向境外接收方行使查阅、复制、更正、删除等权利。
四、本章承诺
本章关于跨境提供的规定旨在确保平台在确需向境外提供实名认证信息时，严格遵循法定合规程序。平台将依法完成安全评估、个人信息保护认证或订立标准合同等法定基础，并依法向用户单独告知、取得单独同意后，方可实施跨境提供。跨境提供的具体合规安排以平台届时依法公示的政策为准。
五、存储与传输管理
平台将根据适用法律法规、业务需要、技术条件及风险状况，对实名认证信息的存储与传输采取相应管理措施：
- 根据需要选择适当的数据存储、备份与灾备安排，并依法管理相关处理活动。
- 如发生跨境传输或跨境访问，依法完成适用的合规程序并履行相应告知、同意或其他法定义务。
- 采取与风险相适应的访问控制、权限管理或其他合理措施，防范未经授权的信息处理。
- 对相关处理安排进行必要的内部管理，并根据法律法规、监管要求及实际情况调整。
- 与适用的云服务提供商、认证核验服务商或其他受托方依法约定其处理范围及相应义务。
六、跨境提供的合规评估
如未来因业务发展确需向境外提供实名认证信息，平台将按照以下流程进行合规评估：
- 评估境外接收方所在国家或地区的个人信息保护政策和法规环境。
- 开展个人信息保护影响评估，评估跨境提供对用户权益的影响。
- 确定合规路径：通过国家网信部门组织的安全评估、经专业机构进行个人信息保护认证、或与境外接收方订立国家网信部门制定的标准合同。
- 向用户充分告知境外接收方的名称、联系方式、处理目的、方式、信息种类以及用户向境外接收方行使权利的方式等事项。
- 取得用户的单独同意，确保同意是自愿、明确且知情的。
相关法律依据：《个人信息保护法》（跨境提供相关条款）、《数据安全法》第二十七条。
补充说明：先查明是否发生跨境提供
用户在境外访问平台、服务商位于境外、海外客服远程查看资料以及数据实际存储在境外，是不同事实；是否构成需要履行特定规则的个人信息出境，应结合信息从何处传向何处、谁可访问和实际处理角色判断。仅因协议设置了跨境章节，不表示当前实名认证数据已经向境外提供，也不构成对未来任何跨境用途的预先授权。
如果某项业务确实需要向境外接收方提供个人信息，应先确定目的、必要性、信息范围、接收方和个人权益影响，再依据届时适用的法律履行所需程序与告知。同一服务商可能同时提供境内外能力，但合同名称或注册地址并不足以证明每次请求的数据路径相同。正式文本应以实际系统、供应商安排和有效法律要求为依据，不能填入猜测的接收方名单。
用户提出对跨境处理的疑问时，能够回答的范围取决于平台真实掌握的数据流；对独立第三方自行决定的处理，应明确其角色和相应权利渠道。若未来安排发生变化，原有认证同意能否覆盖新路径应重新评估，尤其不能把一次普通协议勾选解释为对不特定国家、用途和接收方的概括同意。本节不作“所有数据永久留在境内”的未经核实保证。
用户在境外访问页面、服务商使用境外品牌，以及个人信息实际向境外接收方提供，属于不同事实。判断是否发生跨境提供，需要核查数据传输路径、境外接收方及其能否访问资料，而不能仅依据域名、合同抬头或用户所在地。若以后确需向境外提供认证资料，平台应先评估目的、必要性和个人权益影响，再按适用法律完成相应程序、告知与单独同意；不能用本协议的一般接受记录替代未知接收方的具体告知。
本章情境释义（不新增权利义务）
以下情境围绕跨境提供的条件说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
访问境外网页
适用事实。以“访问境外网页”为例，应先明确不当然等于实名数据出境，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“访问境外网页”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“不当然等于实名数据出境”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对访问境外网页，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“访问境外网页”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“不当然等于实名数据出境”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不当然等于实名数据出境时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。访问境外网页可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
境外服务商参与
适用事实。以“境外服务商参与”为例，应先明确先核实具体传输关系，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“境外服务商参与”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“先核实具体传输关系”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对境外服务商参与，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“境外服务商参与”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“先核实具体传输关系”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先核实具体传输关系时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。境外服务商参与的名称只是阅读辅助，真正需要判断的是先核实具体传输关系如何影响在适用情形获得明确告知并行使法定权利。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
技术支持远程访问
适用事实。以“技术支持远程访问”为例，应先明确查明是否涉及提供信息，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“技术支持远程访问”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“查明是否涉及提供信息”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对技术支持远程访问，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“技术支持远程访问”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“查明是否涉及提供信息”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解查明是否涉及提供信息时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。跨境提供的条件关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。技术支持远程访问如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
新增境外接收方
适用事实。以“新增境外接收方”为例，应先明确应依法履行必要程序，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“新增境外接收方”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“应依法履行必要程序”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对新增境外接收方，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“新增境外接收方”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“应依法履行必要程序”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解应依法履行必要程序时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。新增境外接收方可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
目的发生变化
适用事实。以“目的发生变化”为例，应先明确重新核对合法基础，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“目的发生变化”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“重新核对合法基础”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对目的发生变化，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“目的发生变化”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“重新核对合法基础”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解重新核对合法基础时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。目的发生变化的名称只是阅读辅助，真正需要判断的是重新核对合法基础如何影响在适用情形获得明确告知并行使法定权利。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
用户要求删除
适用事实。以“用户要求删除”为例，应先明确区分平台与接收方责任，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“用户要求删除”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“区分平台与接收方责任”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对用户要求删除，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“用户要求删除”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“区分平台与接收方责任”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分平台与接收方责任时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。跨境提供的条件关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。用户要求删除如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
未发生跨境提供
适用事实。以“未发生跨境提供”为例，应先明确不需要虚构接收方名单，再从本章只说明未来如发生跨境提供时的法定前提这一原则出发理解本章关于跨境提供的条件的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“未发生跨境提供”这一情境中，需要分辨的是实际境外接收方、目的、数据类别及合法基础，并核对“不需要虚构接收方名单”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕实际境外接收方、目的、数据类别及合法基础说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对未发生跨境提供，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在适用情形获得明确告知并行使法定权利这一相关事项，决定是否询问是否实际发生跨境提供。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“未发生跨境提供”时，应以本章只说明未来如发生跨境提供时的法定前提为出发点，核对实际境外接收方、目的、数据类别及合法基础及其他可核实的记录，再结合“不需要虚构接收方名单”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不需要虚构接收方名单时，应同时守住本章边界：本章不能推定当前已经跨境传输或固定本地存储。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。未发生跨境提供可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十七章 自动化决策与风控画像的告知与异议
一、总则
为保障平台安全运营与用户合法权益，平台在实名认证与风控管理中可能使用自动化决策技术。本章对自动化决策的使用范围、告知义务、透明度与用户的异议权作出规定，旨在落实《个人信息保护法》关于自动化决策的相关规定。
二、自动化决策的使用场景
平台在以下场景中可能使用自动化决策：
- 实名认证核验：通过自动化系统对用户提交的证件信息、人脸图像进行一致性校验与活体检测。
- 风险评估与画像：基于用户行为、设备特征、交易模式等数据，建立风险评分模型，识别异常行为与潜在风险。
- 反欺诈与反滥用：通过自动化规则与机器学习模型，识别批量注册、代认证、洗钱等滥用行为。
- 功能限制与处置：基于自动化判断，对高风险账号实施功能限制、冻结等处置措施。
三、告知义务
平台就自动化决策向用户告知以下事项：
- 自动化决策的存在及其大致逻辑（不泄露可被规避的风控细节）；
- 自动化决策对用户可能产生的影响，包括但不限于认证结果、功能限制、风险评级等；
- 用户就自动化决策享有的权利，包括要求说明、提出异议、申请人工复核的权利。
四、用户的异议与人工复核权
重点提示：用户对自动化决策结果有异议的，享有以下权利：
- 要求说明：用户有权要求平台对自动化决策的结果与主要因素作出解释说明。平台将在合理范围内提供解释，但为防止风控规则被规避，可能不披露具体算法细节。
- 提出异议：用户有权对自动化决策结果提出异议，并提交相反证据或补充材料。平台将对用户的异议进行审核。
- 申请人工复核：对可能产生重大影响的自动化决策（如拒绝认证、冻结账户、列入黑名单等），用户有权申请人工复核。平台将安排工作人员对决策结果进行复核，并在合理期限内反馈复核结论。
五、平台义务与限制
平台将努力做到：不将自动化决策作为对用户权益产生重大影响的唯一依据，在合理可行的范围内保留人工审核与干预的机制；根据需要评估自动化决策系统的公平性、准确性与合规性；不对用户进行不合理的差别对待。平台在保障用户权利的同时，有权基于安全需要对风控规则与算法细节予以保密，以防止被恶意规避。
六、自动化决策的具体应用场景
以下仅为本协议提及的技术情境，不能推定平台已部署相关系统。某项技术如实际启用，须先核对处理目的、数据种类、具体影响、合法依据、用户告知和异议渠道；未经核实的能力不作为现行服务承诺：
- 实名认证初审：如实际通过系统比对身份信息，须确认所用数据源、准确性与复核方式；本协议所举例子不表示当前个人入口会采集证件影像或提供人工初审。
- 活体检测判定：当前平台个人认证页面不采集人脸或活体信息。若第三方页面将来实际采用此类技术，应由相应处理者依法告知，并核对结果纠错方式。
- 风险评估与分级：是否存在设备、行为或交易风险评分，以及评分是否影响认证结果，须以实际系统和合法处理依据核实；风险信号本身不等于违规结论。
- 反欺诈检测：如依法开展反欺诈核查，须区分交易服务的实际运营范围与实名认证范围；不能由本章创设额外数据收集或资金处置权。
- 内容安全审核：内容审核不因实名认证协议而自动纳入认证数据处理。相关能力及申诉方式应依据实际提供的服务和另行适用的规则判断。
七、算法公平性保障
如平台实际采用依法构成自动化决策的技术，应按适用法律评估公平性、透明度和对用户权益的影响。下列措施仅供核对，不能视为已设置专门机构或已完成审计：
- 依据实际技术和风险，核对是否需要开展公平性与准确性评估，并保存必要结论。
- 当处理目的、数据种类或对用户权益的影响变化时，依法重新评估并履行必要告知。
- 涉及对个人权益有重大影响的决定时，依法提供说明、异议和拒绝仅通过自动化方式作出决定的途径。
- 平台应通过实际公示的渠道说明投诉方式、负责主体及可提供的复核途径。
相关法律依据：《个人信息保护法》（自动化决策相关条款）、《网络安全法》第二十六条。
补充说明：系统提示与自动决定的界线
输入格式校验、第三方身份匹配、风险提示和由系统直接作出最终限制，虽然都可能借助自动化，但对用户权益的影响不同。讨论自动化决策时，应先查明哪个环节由程序完成、是否有人复核以及结果是否对用户产生重大影响。不能仅因为后台显示风险分数，就推定平台已经建立完整画像系统；也不能因为后来有人工查看，就当然认为原先的自动决定无需解释。
若某个自动化结论导致认证被拒绝或重要功能受限，用户需要知道可以就具体结果提出异议的实际渠道，而不是被要求理解算法的全部商业秘密。复核可以关注输入是否准确、服务商结果是否有效、规则适用范围是否正确，以及是否存在共享设备或姓名变更等合理解释。平台可保护必要的安全细节，同时仍应提供足以使用户理解争议事项的说明。
统计特征可能在正常家庭、企业办公室或弱网络环境中产生误差，因此同一技术信号不应对所有用户作机械相同的推断。对结果进行更正，应同时检查依赖该结果形成的限制是否需要调整。平台应按真实处理流程说明是否实际使用个人画像、哪些系统作出最终决定；本节不新增算法采集字段或自动评分用途。
如果自动化处理仅生成供人工核查的提示，与系统不经实质复核直接作出对用户权益有重大影响的决定，应分别评价。后一种情形下，个人依法有权要求处理者予以说明，并有权拒绝仅通过自动化决策的方式作出决定。即使存在人工复核，也应核对人员是否能够接触必要事实并改变错误结果，而不能只看系统中是否设置了一个“人工处理”按钮。平台解释结果时可以保护必要的安全细节，但应让用户知道争议对象、可提交的更正线索和实际救济渠道。
本章情境释义（不新增权利义务）
以下情境围绕自动化决策与风控说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
规则拒绝申请
适用事实。以“规则拒绝申请”为例，应先明确区分硬性资格与风险评分，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“规则拒绝申请”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“区分硬性资格与风险评分”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对规则拒绝申请，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“规则拒绝申请”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“区分硬性资格与风险评分”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解区分硬性资格与风险评分时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。规则拒绝申请可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
设备指纹异常
适用事实。以“设备指纹异常”为例，应先明确考虑共享设备的正常原因，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“设备指纹异常”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“考虑共享设备的正常原因”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对设备指纹异常，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“设备指纹异常”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“考虑共享设备的正常原因”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解考虑共享设备的正常原因时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。设备指纹异常的名称只是阅读辅助，真正需要判断的是考虑共享设备的正常原因如何影响对重大影响结果可按公示渠道请求解释与复核。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
交易模式变化
适用事实。以“交易模式变化”为例，应先明确不能忽略用户真实业务，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“交易模式变化”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“不能忽略用户真实业务”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对交易模式变化，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“交易模式变化”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“不能忽略用户真实业务”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能忽略用户真实业务时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。自动化决策与风控关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。交易模式变化如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
重大权益限制
适用事实。以“重大权益限制”为例，应先明确提供人工复核路径，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“重大权益限制”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“提供人工复核路径”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对重大权益限制，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“重大权益限制”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“提供人工复核路径”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提供人工复核路径时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。重大权益限制可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
模型偏差
适用事实。以“模型偏差”为例，应先明确核查是否对特定群体不公平，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“模型偏差”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“核查是否对特定群体不公平”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对模型偏差，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“模型偏差”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“核查是否对特定群体不公平”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核查是否对特定群体不公平时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。模型偏差的名称只是阅读辅助，真正需要判断的是核查是否对特定群体不公平如何影响对重大影响结果可按公示渠道请求解释与复核。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
解释要求
适用事实。以“解释要求”为例，应先明确说明主要因素而非泄露规则参数，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“解释要求”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“说明主要因素而非泄露规则参数”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对解释要求，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“解释要求”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“说明主要因素而非泄露规则参数”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解说明主要因素而非泄露规则参数时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。自动化决策与风控关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。解释要求如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
人工改判
适用事实。以“人工改判”为例，应先明确同步修正受影响状态，再从自动化结果是风险判断线索且须保障适用的异议权这一原则出发理解本章关于自动化决策与风控的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“人工改判”这一情境中，需要分辨的是所用数据类别、主要影响与人工复核可能性，并核对“同步修正受影响状态”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕所用数据类别、主要影响与人工复核可能性说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对人工改判，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合对重大影响结果可按公示渠道请求解释与复核这一相关事项，决定是否请求解释或人工复核重大结果。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“人工改判”时，应以自动化结果是风险判断线索且须保障适用的异议权为出发点，核对所用数据类别、主要影响与人工复核可能性及其他可核实的记录，再结合“同步修正受影响状态”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解同步修正受影响状态时，应同时守住本章边界：列举模型能力不代表当前系统部署特定算法。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。人工改判可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十八章 申诉、复核、投诉与救济
一、总则
平台尊重并保障用户依法享有的申诉、复核、投诉与救济权利。本章对用户对认证失败、账户处置、信息处理等不满时的申诉、复核、投诉渠道与时限作出规定。平台对善意用户与商户提供便利与快速通道，不设不合理门槛。
二、申诉入口与方式
重点提示：用户可通过以下渠道提交申诉：
- 在线申诉：如实际开放帮助中心或申诉中心入口，可从该入口提交；
- 客服热线：拨打平台公示的客服电话；
- 邮件申诉：发送至平台公示的客服邮箱；
- 书面申诉：如平台公示可收件的地址，可按该地址提交。
三、申诉材料与身份核验
用户提交申诉时，应提供以下材料：申诉人身份证明（如身份证件影像、账号绑定手机号等）；申诉事项的具体描述；支持申诉主张的证据材料（如证件原件照片、授权文件、交易凭证等）。平台在收到申诉后，将核验申诉人身份，确认其与涉事账号的关联关系。
四、受理与反馈时限
平台应在合理期限内反馈；具体流程应与实际开放的申诉渠道、处理能力和适用法律相一致：
- 收到申诉后应及时确认受理情况；如有编号或预计时间，应通过实际渠道告知；
- 一般事项应在合理期限内处理并反馈；
- 复杂事项如需更长时间，应说明原因并依法及时反馈；
- 涉及冻结资金或重大权益的紧急申诉，平台将优先处理。
五、复核机制
用户对平台处理结果不满意的，可通过公示渠道申请复核；申请期限应以依法有效且已充分提示的规则为准。复核由平台指定的独立于原处理团队的人员进行。复核期间，原处理措施原则上维持不变，但平台可根据具体情况决定暂缓执行。复核结论为平台内部终审决定，用户仍不满意的，可通过外部渠道寻求救济。
六、误判纠错与解除
经复核确认为误判的，平台将及时采取以下措施：解除对账户的限制、冻结或其他处置措施；恢复账户的正常状态与功能；对因误判给用户造成的合理损失（如冻结期间的利息损失、合理的维权费用等）予以适当补偿。补偿方案由平台根据具体情况确定。
七、外部救济途径
用户对平台处理结果仍不满意的，可通过以下外部途径寻求救济：
- 向网信部门、市场监管部门、消费者协会等监管部门投诉；
- 依据《消费者权益保护法》向消费者权益保护组织请求调解；
- 依法向有管辖权的人民法院提起诉讼；
- 在另有有效仲裁协议时依该协议申请仲裁。
八、申诉材料与证据要求
为提高申诉处理效率，建议用户在申诉时提供以下材料：
- 身份证明：申诉人本人的身份证件影像（可遮挡非必要字段），用于核实申诉人身份。
- 事实说明：对申诉事项的详细说明，包括事件经过、时间线、涉及的账号与操作等。
- 证据材料：能够证明申诉主张的证据，包括但不限于截图、交易记录、聊天记录、第三方证明等。证据应真实、完整、未经篡改。
- 诉求说明：明确的申诉请求，如解除限制、恢复功能、更正信息、赔偿损失等。
- 联系方式：有效的联系方式（手机号、邮箱等），便于平台联系沟通。
平台对申诉材料的要求遵循必要性原则，不要求用户提供超出申诉事项所需的材料。对于因客观原因无法提供部分材料的用户，平台将根据具体情况灵活处理。
九、恶意申诉的防范
为维护申诉机制的正常运行，平台对以下恶意申诉行为予以防范：
- 反复提交相同或实质相同的申诉，经复核后仍无新证据的。
- 提供虚假证据或伪造材料的申诉行为。
- 以申诉为手段干扰平台正常运营秩序的行为。
- 利用申诉机制为违规行为开脱或拖延处置的行为。
对恶意申诉行为，平台有权简化处理流程、限制申诉频次或将相关情况纳入用户信用评估。恶意申诉不影响用户依法享有的外部救济权利。
十、商户用户的优先通道
考虑到商户用户的经营需要，如企业或商户认证及其专属服务在未来正式开放，平台应在实际页面说明适用条件；下列服务仅在相应入口实际提供时适用：
- 如正式开放优先通道，其处理顺序与时限应以实际公示、可履行的规则为准。
- 是否设有专属客服通道，应以实际开放入口为准；本协议不承诺提供一对一服务。
- 涉及商户经营核心功能的处置，平台将结合紧急程度及时处理申诉；具体时限以正式公示且可履行的规则和适用法律为准。
- 商户对复核结果仍有异议的，可以依法寻求外部救济；仲裁以有效仲裁协议为前提。
相关法律依据：《个人信息保护法》（个人权利行使相关条款）、《消费者权益保护法》第二十九条、《网络安全法》第二十六条。
申诉定位的五种常见情形
申诉渠道的价值在于定位真正发生问题的环节，而非要求用户先猜中内部规则名称。下列分类可以帮助阅读本章，具体提交方式、可提供的信息和反馈时间仍以届时公示的渠道、实际能力及适用法律为准。
- 资料无法提交：先查输入格式、证件类型和当前入口支持范围。用户若持有特殊证件，应确认是否存在正式开放的相应入口；不能因页面不支持而建议其填写虚假资料或借用他人证件。
- 已提交但没有结论：查看订单、会话和页面状态是否对应同一次申请。若第三方尚未返回可靠结果，平台不应凭猜测给出通过或拒绝结论；用户也不应被要求为了查询状态重复支付。
- 显示拒绝或失败：区分身份不匹配、技术中断和平台后续审核决定。可核实的原因应尽量说明，涉及防冒用细节时可以采用与安全相称的方式反馈，但不宜只给无法纠错的空泛结论。
- 认证已通过但账户受限：这可能是其他交易、安全或使用规则在起作用。申诉应分别核对认证结论和功能限制，不能让用户在一个已经正确的身份结果上反复提交资料。
- 怀疑被冒用：优先确认本人账户安全、可疑申请与证件关联，必要时保护相关账户和证据。反馈给被冒用人的内容应足以支持救济，同时避免泄露其他人的完整身份信息。
补充说明：让申诉对应具体决定
“认证失败”可能指证件格式不合格、服务商会话超时、核验结果拒绝或平台后续审核未通过。用户申诉时，描述自己看到的状态、发生时间与相关账户，有助于定位具体环节；平台反馈时也应尽可能区分能否重新提交、是否需要更正资料、是否仍在等待结果。没有明确原因时，不宜要求用户反复购买认证订单或连续提交相同的敏感资料。
对账户限制提出异议，与要求更正认证资料或行使个人信息权利，可能需要分别处理。一个渠道可以协助分流，但不能因为用户最初选错问题分类就当然丧失救济。需要核实申诉人身份时，应防止冒用者借申诉读取他人资料；核实强度和收集字段应与请求风险相称，不宜把完整证件影像作为所有普通状态咨询的统一门槛。
复核结论可以是维持、变更或撤销原处理，也可能提示需要补充可核实的事实。说明应与实际证据和可公开范围相符，不应编造固定时限、专属人工通道或百分之百成功率。用户对结果仍有争议时，可依适用法律使用投诉、诉讼等外部途径；平台内部复核不构成这些法定途径的前置放弃。
用户提出认证异议时，平台应先识别其争议的是资料输入、服务商会话、支付订单、认证结论还是账户限制，再由有权限的人员按实际记录处理。要求补充证据应围绕具体疑点，避免重复收集与争议无关的完整证件或生物识别原件。若某项限制依赖错误的认证结论，复核不能只更正页面上的文字，还应检查由该结论触发的功能状态。用户的投诉、个人信息权利请求和司法救济分别适用相应法律及渠道，不应被统一写成只能先经平台内部复核。
本章情境释义（不新增权利义务）
以下情境围绕申诉、复核与救济说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
认证被拒
适用事实。以“认证被拒”为例，应先明确说明争议字段与正确资料，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“认证被拒”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“说明争议字段与正确资料”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对认证被拒，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“认证被拒”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“说明争议字段与正确资料”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解说明争议字段与正确资料时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。认证被拒可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
账户被冻结
适用事实。以“账户被冻结”为例，应先明确指出实际使用人与时间，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“账户被冻结”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“指出实际使用人与时间”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对账户被冻结，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“账户被冻结”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“指出实际使用人与时间”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解指出实际使用人与时间时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。账户被冻结的名称只是阅读辅助，真正需要判断的是指出实际使用人与时间如何影响通过已公示渠道提交必要事实和材料。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
被冒用投诉
适用事实。以“被冒用投诉”为例，应先明确先保护信息与相关账号，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“被冒用投诉”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“先保护信息与相关账号”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对被冒用投诉，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“被冒用投诉”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“先保护信息与相关账号”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解先保护信息与相关账号时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。申诉、复核与救济关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。被冒用投诉如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
平台迟未回复
适用事实。以“平台迟未回复”为例，应先明确保存提交和收悉记录，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“平台迟未回复”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“保存提交和收悉记录”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对平台迟未回复，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“平台迟未回复”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“保存提交和收悉记录”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解保存提交和收悉记录时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。平台迟未回复可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
复核后仍不服
适用事实。以“复核后仍不服”为例，应先明确依法向外部渠道求助，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“复核后仍不服”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“依法向外部渠道求助”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对复核后仍不服，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“复核后仍不服”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“依法向外部渠道求助”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解依法向外部渠道求助时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
对这一情况的解释，应同时考虑用户合理预期和平台能够证明的事实。复核后仍不服的名称只是阅读辅助，真正需要判断的是依法向外部渠道求助如何影响通过已公示渠道提交必要事实和材料。规则未写明、页面未开放或资料尚未核实的部分，不能用推测补足为新的用户义务；若现行文字之间不一致，应按适用法律和保护用户法定权利的方式审慎解释。
资料不完整
适用事实。以“资料不完整”为例，应先明确明确需要补充的必要项，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“资料不完整”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“明确需要补充的必要项”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对资料不完整，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“资料不完整”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“明确需要补充的必要项”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解明确需要补充的必要项时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
该例与本协议其他章节相衔接，但不能取代其他章节的具体条件。申诉、复核与救济关系到认证本身；费用、交易、个人信息及申诉各有独立的事实基础。资料不完整如果同时触及数项规则，应分别说明每一项决定依赖什么事实，并让用户能够识别可更正之处，而不是用一个概括标签覆盖全部问题。
紧急资金问题
适用事实。以“紧急资金问题”为例，应先明确按实际规则申请优先处理，再从用户可就认证失败、账号处置与信息处理提出异议这一原则出发理解本章关于申诉、复核与救济的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“紧急资金问题”这一情境中，需要分辨的是申诉事项、身份关系、证据完整性与紧急程度，并核对“按实际规则申请优先处理”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕申诉事项、身份关系、证据完整性与紧急程度说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对紧急资金问题，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合通过已公示渠道提交必要事实和材料这一相关事项，决定是否提交具体申诉或依法寻求救济。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“紧急资金问题”时，应以用户可就认证失败、账号处置与信息处理提出异议为出发点，核对申诉事项、身份关系、证据完整性与紧急程度及其他可核实的记录，再结合“按实际规则申请优先处理”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解按实际规则申请优先处理时，应同时守住本章边界：申诉流程不剥夺消费者及个人信息主体法定权利。
这一场景还应放在完整的认证过程里理解：申请、核验、结果展示、后续更正和争议处理是不同环节。紧急资金问题可能只影响其中一个环节，不能由此推断所有历史记录失效、其他服务必然受限，或平台已获得新的个人信息处理授权。出现时间先后不清的情况，应先还原每一步的实际发生时间，再对应当时有效的规则。
第二十九章 委托处理、共享清单与第三方合规管理
一、总则
实名认证服务的完成需要借助第三方核验机构的技术支持。本章对平台向第三方核验机构、受托方共享实名信息的合规要求、委托处理关系、共享信息清单与透明度作出规定，旨在落实《个人信息保护法》关于委托处理与信息共享的规定。
二、委托处理的合规要求
平台向受托方委托处理实名认证信息时，遵循以下合规要求：
- 书面协议：与受托方签订书面委托处理协议，明确处理目的、期限、方式、信息类型、双方权利义务及安全保护措施。
- 目的限定：受托方仅能在约定的目的范围内处理实名信息，不得超出约定范围使用。
- 安全义务：要求受托方采取与平台相当的安全保护措施，包括加密存储、访问控制、审计日志等。
- 监督义务：平台对受托方的数据处理活动进行监督，定期评估其安全能力与合规状态。
- 终止处理：委托关系终止后，受托方应按约定删除或返还相关数据，平台将进行确认。
三、共享信息清单
重点提示： 平台在实名认证过程中可能向以下类别的第三方共享信息，共享的范围严格限定于完成核验所必需的最小字段：
- 身份核验服务方：共享姓名、身份证件号码，用于公安权威数据的一致性校验。
- 人脸核验服务方：共享人脸图像，用于人证比对与活体检测。
- 运营商核验服务方：共享姓名、身份证件号码、手机号码，用于三要素一致性校验。
- 银行卡核验服务方：共享姓名、身份证件号码、银行卡号、预留手机号，用于四要素一致性校验。
- 企业工商核验服务方：共享企业名称、统一社会信用代码、法定代表人信息，用于企业主体核验。
- 电子签名服务方：共享身份信息，用于数字证书签发与电子签名服务。
平台不会向上述类别以外的第三方共享用户的实名认证信息，但法律法规另有规定、用户另行同意、或为保障平台安全运营及防范欺诈等违法行为所必需的除外。
四、受托方的安全义务
受托方应承担以下安全义务：按照约定的目的与方式处理实名信息；采取加密存储、访问控制等安全措施；不得将受托处理的信息转委托给其他方；在委托关系终止后按约定删除或返还数据；接受平台的监督与检查。
五、平台对第三方核验结果的信赖
平台有权合理信赖第三方核验机构提供的核验结果，但不因此免除自身应尽的审慎义务。平台对第三方核验结果的使用遵循以下原则：核验结果作为认证决策的重要参考，但不作为唯一依据；平台保留对高风险场景进行人工审核的权利；因第三方核验服务的错误、延迟或不可用导致的核验偏差，平台在已尽合理审查义务的前提下，对由此产生的后果不承担超出法律规定范围的责任。
六、第三方信息共享清单
为保障用户的知情权，平台定期更新并公示第三方信息共享清单。清单内容包括：
- 第三方名称与类型：接收信息的第三方机构名称及其业务类型（如认证核验、风控服务、数据分析等）。
- 共享信息范围：与第三方共享的具体信息类型（如姓名、身份证号、人脸影像等）。
- 共享目的：信息共享的具体业务目的（如身份核验、反欺诈检测等）。
- 处理方式：第三方对信息的处理方式（如存储、比对、分析等）。
- 安全保障措施：第三方采取的安全保护措施。
- 用户权利行使：用户向第三方行使查阅、更正、删除等权利的途径。
平台在增加新的第三方共享关系或扩大共享信息范围时，将提前通知用户并取得同意。用户有权拒绝非必要的信息共享，但可能影响部分功能的使用。
七、第三方合规审计
平台对第三方合作伙伴实施持续的合规审计，包括：
- 定期审查第三方的数据处理活动，确保其符合协议约定与法律法规要求。
- 对第三方的安全措施进行评估，包括技术措施与管理措施。
- 对第三方的数据泄露事件进行跟踪，评估对用户信息的潜在影响。
- 对不合规的第三方采取整改措施，情节严重的终止合作关系。
八、第三方违约的责任承担
因第三方合作伙伴的原因导致用户信息泄露、滥用或其他损害的，平台将协助用户向第三方追究责任。平台已尽合理审查与监督义务的，对第三方的违约行为在法律允许范围内不承担连带责任，但不免除平台因选任或监督过失所应承担的责任。用户可选择向平台或直接向第三方主张权利。
相关法律依据：《个人信息保护法》（委托处理相关条款）、《数据安全法》第二十七条、《网络安全法》第二十六条。
第三方信息处理的核对要点
“与第三方合作”无法回答用户的核心问题：其资料被谁取得、用于什么、在何处行使权利。平台应按实际处理关系和数据流说明第三方信息处理，不能以笼统的“合作伙伴”替代具体接收方。核对第三方说明时，可逐项查看下列事项。
- 接收方身份：确认实际提供核验、支付或技术服务的法律主体及其公开名称。集团品牌、产品名与签约主体可能不同，不能只列商标而使用户无法知道真实处理者。
- 处理角色：看接收方是否仅按平台指令处理，还是独立决定目的和方式。角色不同，合同约束、告知内容及用户应向谁提出权利请求也不同，不能用“受托方”作为所有第三方的统一标签。
- 信息边界：区分平台主动提供的姓名、证件号码，用户在服务商页面直接提交的素材，以及服务商最终返回的状态。某项接口能够传输字段，不等于每次申请都会传输，第三方说明须与实际启用的流程一致。
- 用途与保存：说明每类接收方为什么需要资料、哪些操作与核验直接相关、何时应停止处理。平台能够控制的留存和独立第三方自行决定的留存应分别描述，不宜向用户承诺平台无法验证的统一删除期限。
- 变更记录：服务商切换、处理角色改变或新增信息类别，可能影响原告知及同意的适用。第三方说明应与实际数据流保持一致；仅更新网页名称，不能自动补足此前未完成的必要告知。
补充说明：共享清单必须能对应真实接收方
实名认证可能涉及核验服务商、支付机构、云基础设施提供者或依法有权获取资料的机关，但它们取得信息的原因与权限不相同。第三方说明应逐项写明实际主体、处理角色、目的、信息类别和适用条件；不能用“合作伙伴”一词覆盖所有接收方，也不能从技术接入推定每一家供应商都获得用户的完整证件信息。
委托处理与独立处理的区别会影响告知、指令、权利请求和责任分配。即使平台与服务商签有合同，也要看服务商是否仅按平台指令处理、是否可自行决定其他用途以及最终资料保存在哪里。若尚未取得服务商合同或数据流记录，平台应依法核实处理角色，并向用户如实说明实际接收方、信息类别和处理目的。
共享安排发生变化时，应先判断新接收方是否改变原处理目的、是否增加信息类别，以及是否需要新的告知或同意。用户要求了解或更正资料时，平台应区分自己持有的数据与独立第三方控制的数据，并协助定位可行的权利渠道。未向用户展示的文件名称不能替代对实际第三方及信息处理活动的真实披露。
第三方说明的核心是让用户知道谁会取得什么信息、为什么取得以及如何行使权利。平台应区分服务商作为受托处理者、独立个人信息处理者，或仅提供不接触身份内容的技术基础设施。向其他独立处理者提供个人信息时，应依法说明其名称或姓名、联系方式、处理目的、方式和信息种类，并取得适用的单独同意；委托处理则应依法约定并监督受托方。实际接收方和数据流变化后，原有告知是否仍充分，应重新核对。
本章情境释义（不新增权利义务）
以下情境围绕第三方共享与委托说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
仅做技术委托
适用事实。以“仅做技术委托”为例，应先明确受托方不得自行扩展目的，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“仅做技术委托”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“受托方不得自行扩展目的”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对仅做技术委托，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“仅做技术委托”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“受托方不得自行扩展目的”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解受托方不得自行扩展目的时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
独立服务商核验
适用事实。以“独立服务商核验”为例，应先明确核对是否需单独告知同意，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“独立服务商核验”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“核对是否需单独告知同意”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对独立服务商核验，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“独立服务商核验”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“核对是否需单独告知同意”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对是否需单独告知同意时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
新增接收方
适用事实。以“新增接收方”为例，应先明确更新清单并依法通知，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“新增接收方”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“更新清单并依法通知”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对新增接收方，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“新增接收方”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“更新清单并依法通知”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解更新清单并依法通知时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
核验结束
适用事实。以“核验结束”为例，应先明确按实际约定处理剩余资料，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“核验结束”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“按实际约定处理剩余资料”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对核验结束，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“核验结束”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“按实际约定处理剩余资料”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解按实际约定处理剩余资料时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
供应商发生泄露
适用事实。以“供应商发生泄露”为例，应先明确平台仍须审查自身义务，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“供应商发生泄露”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“平台仍须审查自身义务”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对供应商发生泄露，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“供应商发生泄露”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“平台仍须审查自身义务”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解平台仍须审查自身义务时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
用户查询接收者
适用事实。以“用户查询接收者”为例，应先明确提供依法可披露的信息，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“用户查询接收者”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“提供依法可披露的信息”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对用户查询接收者，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“用户查询接收者”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“提供依法可披露的信息”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解提供依法可披露的信息时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
合作终止
适用事实。以“合作终止”为例，应先明确监督删除或返还必要数据，再从对外提供和委托处理应区分角色及必要信息范围这一原则出发理解本章关于第三方共享与委托的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“合作终止”这一情境中，需要分辨的是真实接收方、共享字段、目的、保存期限与用户权利，并核对“监督删除或返还必要数据”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕真实接收方、共享字段、目的、保存期限与用户权利说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对合作终止，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合在具体提供前阅读适用告知并作出所需选择这一相关事项，决定是否查询实际接收方和共享范围。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“合作终止”时，应以对外提供和委托处理应区分角色及必要信息范围为出发点，核对真实接收方、共享字段、目的、保存期限与用户权利及其他可核实的记录，再结合“监督删除或返还必要数据”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解监督删除或返还必要数据时，应同时守住本章边界：服务商类别清单不能代替实际接收方披露。
第三十章 术语定义、解释、附则与版本管理
一、扩展术语表
除第一章已定义的术语外，以下术语在本协议中具有特定含义：
- 强实名：用于说明可能采用更严格核验方式的术语；该术语不表示平台已开放分级认证、人脸或活体核验。
- 敏感个人信息：指一旦泄露或非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息，包括身份证件号码、人脸等生物识别信息、银行账户信息等。
- 生物识别信息：指与自然人的身体、生理或行为特征相关的信息，本协议中主要指人脸图像、活体检测数据等，用于识别特定自然人。
- 受托方：指受平台委托、代为处理实名认证信息的第三方机构，包括但不限于身份核验服务商、人脸核验服务商、云服务提供商等。
- 滥用行为：指用户违反本协议约定或适用法律法规，利用实名认证信息、平台账号或平台功能，实施损害平台、其他用户或社会公共利益的行为，具体范围见第十五章至第二十章。
- 风险名单：仅指如平台依法实际建立相应风险记录时，对与认证安全有关线索的概括称呼。是否存在该机制、处理哪些数据及对账户的影响，应以实际业务事实、已公示规则和适用法律核对；本协议不表示平台已建立此类数据库。
- 账号信息：指用户在平台注册与使用过程中形成的信息，包括账号ID、昵称、头像、绑定手机号、实名认证状态等。
- 自动化决策：指通过计算机程序自动分析、评估用户行为与特征，并作出对用户权益产生影响的决定的行为。
- 安全事件：指因人为攻击、技术故障、管理疏漏或不可抗力等原因，导致实名认证信息被泄露、篡改、丢失、毁损或被非法获取、利用的事件。
二、协议解释原则
重点提示：本协议的解释遵循以下原则：
- 格式条款提示：平台提供本协议时，应对与用户有重大利害关系的格式条款依法以合理方式提示，并根据用户要求予以说明；是否已经充分履行相关义务，应结合实际页面展示和记录判断，不因本协议使用红色或加粗字体当然成立。相关规定见《消费者权益保护法》第二十六条及《民法典》第四百九十六条关于格式条款的规定。
- 有利于消费者的解释：对格式条款的理解发生争议的，按照通常理解予以解释；对格式条款有两种以上解释的，应当作出不利于提供格式条款一方的解释。
- 标题仅为便利：本协议各章节的标题仅为阅读便利而设，不影响条款内容的解释。
- 多语言以中文为准：本协议以中文版本为准。如提供其他语言版本，仅作参考，与中文版本存在差异的，以中文版本为准。
三、条款可分性
条款无效、不合法或不可执行时，对其他条款的影响须依据适用法律和具体内容判断；其他条款的效力仍应依法分别判断。
四、生效日期与版本管理
重点提示： 平台应在实际展示本协议时标明适用版本及生效时间，并以合理方式提示与用户有重大利害关系的变更。用户某次认证申请适用的文本，应结合该次申请的展示内容、时间和有效接受记录判断；版本更新不当然追溯改变此前已经发生的认证事项，也不免除依法需要重新告知或取得同意的义务。
五、其他文件的适用
重点提示：个人信息单独告知、第三方处理说明或其他专项规则，只有在实际向您提供、符合适用法律并与相应事项有关时，才按其自身内容和有效接受情况适用。仅有文件名称、内部记录或未提供的材料，不构成本协议的组成部分，也不产生额外授权。
六、运营主体与联系方式
本协议的运营主体为辽宁逸薯云信息科技有限公司。用户可通过以下方式联系平台：
- 客服电话：0427-8550868
- 客服邮箱：gongkai@yishuit.cn
七、常见问题解答（FAQ）
为帮助你更好地理解本协议的内容与适用，以下列出部分常见问题及解答：
-
问：为什么我需要完成实名认证？
答：根据《网络安全法》第二十六条及《反电信网络诈骗法》第二十一条的规定，网络运营者在与用户签订协议或者确认提供服务时，应当要求用户提供真实身份信息。实名认证是保障交易安全、防范欺诈、保护用户权益的重要措施。 -
问：我的身份证信息是否安全？
答：平台将在合理可行范围内采取符合行业通行标准的技术与管理措施保护你的身份信息，详见第二十四章。你的身份信息仅用于实名认证核验及法律法规允许的相关目的，不会用于其他未经授权的目的。平台将按照《个人信息保护法》关于个人信息处理的相关要求处理你的个人信息。 -
问：如果我不想进行人脸识别怎么办？
答：人脸核验属于敏感个人信息处理，平台是否提供替代核验方案，以届时实际开放的认证方式为准（详见第二十三章）。如有可用的其他核验方式，你可以按页面提示选择，但不同核验方式的认证级别与可用功能可能存在差异。 -
问：我的认证信息被拒绝了怎么办？
答：认证未通过时，可查看实际页面提供的结果说明，通过已公示渠道申请核查或依法提出异议；原因披露的范围须兼顾可解释性、个人信息和安全要求，不能预先承诺展示所有审核细节。 -
问：我可以注销我的实名认证吗？
答：你可以申请账户注销（详见第二十一章）。注销后，平台将在法定留存期限届满后删除或匿名化你的实名认证信息。再次注册及认证须符合届时实际适用的注册、身份核验和风险管理规则；注销本身不产生当然的永久禁止。 -
问：如果我的身份信息被盗用注册了怎么办？
答：如发现身份信息可能被他人冒用，可通过公示渠道提出异议并提供已有线索。平台应核查实际情况，并依法选择更正、解除错误关联或对相关账户采取必要措施；是否注销账户须按事实和适用规则判断。你也可依法向有关机关反映。 -
问：商户认证和个人认证有什么区别？
答：如正式开放商户认证，将按实际页面要求核对企业资质及经办授权；当前个人认证入口不能代替商户认证，也不保证商家专属功能。个人认证所需信息以当时页面说明为准。具体区别详见第六章。 -
问：平台会把我的信息共享给第三方吗？
答：第三方参与核验时，应按实际处理关系、数据流和适用法律告知相应信息处理规则。平台应在依法需要的范围内如实说明实际接收方、信息类别、处理目的和用户权利行使方式；未告知的其他处理不能仅凭本协议概括授权。 -
问：如果平台被黑客攻击导致信息泄露怎么办？
答：发生涉及个人信息的安全事件时，平台应依据事件事实、风险和适用法律采取补救措施并履行依法适用的告知义务；责任按具体过错、损害及法律规定判断。第二十四章所列措施仍须与实际部署情况核对。 -
问：我对平台的处置有异议怎么办？
答：你可以通过实际公示的渠道提出异议，平台应依法受理并在适用期限内反馈。依法享有的投诉、诉讼等救济途径不受本协议影响。
八、协议的完整性与可分割性
本协议及依法实际向用户展示、适用于具体事项的其他文件，共同构成相关约定。不同版本的适用应结合展示与有效接受记录判断；章节标题用于阅读，不单独创设权利义务。
如有条款被认定无效或不可执行，对其他条款的影响和后续处理应依法判断；本协议不赋予任何一方单方指定替代条款的权利。
九、协议的转让与继承
与实名认证有关的身份结果通常具有特定主体属性，是否可转移账户或合同权利义务，应分别依有效协议、真实业务安排及适用法律判断。平台主体或业务发生变更时，不得仅凭通知推定个人信息处理或合同权利义务已合法转移；依法需要另行告知或取得同意的，应履行相应程序。
用户死亡或丧失民事行为能力后，继承人、近亲属或法定代理人依法提出与个人信息或财产权益有关的请求时，平台应核对申请资格、请求范围和适用法律。账户使用资格、身份认证结果和数据导出能力不因亲属关系当然继受或已经开放。
十、不可抗力
如发生影响认证服务的事件，是否构成不可抗力以及责任范围，应结合事件是否不能预见、不能避免且不能克服、双方实际履行情况和适用法律判断。网络攻击、故障或法规变化不因被列举而当然免除任何一方责任；平台仍须依法采取合理措施减少损失，并按适用规则履行告知义务。终止事宜依实际服务及适用法律处理。
十一、通知与送达
通知渠道以实际开放和公示的方式为准。通知是否有效到达、对方是否有合理机会知悉、何时发生相应法律效果，须结合发送与接收记录、通知内容及适用法律判断；重大权益变更不能仅凭发送动作推定完成必要提示。
用户可通过实际开放的渠道更新联系方式；平台发现既有渠道无法联系用户时，应结合事项性质选择合法、合理的补充通知方式，并记录有关情况。概括公告不能替代法律要求的特定告知或同意。
十二、协议的解释
本协议的解释应遵循以下原则：以条款文字的通常含义为准；结合协议目的与上下文进行整体解释；在条款含义不明确时，应作有利于消费者的解释（依据《消费者权益保护法》第二十六条）；中文文本与其他语言文本不一致的，以中文文本为准。
相关法律依据：《消费者权益保护法》第二十六条、第二十九条、《民法典》第四百九十六条。
补充说明：怎样判断适用的版本
同一用户可能在不同时间提出多次认证申请。核对某次申请应适用的文本时，应分别查看该次申请的时间、入口、页面展示的版本、重大条款提示和用户作出的操作。后一次展示的新版本不当然替代前一次申请时的有效约定；如果后续处理目的、个人信息种类或用户权益发生变化，还应按适用法律判断是否需要重新告知或取得同意。
个人信息处理说明、第三方页面及本协议处理的事项可能不同。平台协议的接受记录不自动证明用户已在第三方页面对独立处理者作出同意；第三方页面的操作也不能使平台取得超出已告知范围的处理权限。用户可以通过平台公示渠道询问自己申请时所适用的文本及相关告知，平台应依法说明或提供可查阅的记录。
标题、术语和常见问答用于帮助理解正文，不得被解释为扩大信息收集范围、增加未明示的收费或限制法定救济。某项附加服务或认证方式只有在页面实际提供并完成适用的告知与确认后才涉及相应规则。对文字含义有争议时，应结合上下文、交易过程及格式条款解释规则判断，不能只凭单独摘录的一句话排除用户的法定权利。
本章情境释义（不新增权利义务）
以下情境围绕术语、版本与附则说明不同事实下的核对重点，只解释本章既有规则，不增设认证渠道、材料清单、收费标准、保存期限、处理时限或免责约定。凡涉及尚未开放或未经核实的能力，应以条件性方式理解；用户法定权利与平台法定义务不因举例减少。
强实名一词
适用事实。以“强实名一词”为例，应先明确不自动意味着当前开放分级，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“强实名一词”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“不自动意味着当前开放分级”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对强实名一词，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“强实名一词”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“不自动意味着当前开放分级”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不自动意味着当前开放分级时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
认证通过一词
适用事实。以“认证通过一词”为例，应先明确须看具体结果与有效期，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“认证通过一词”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“须看具体结果与有效期”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对认证通过一词，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“认证通过一词”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“须看具体结果与有效期”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解须看具体结果与有效期时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
不同语言译文
适用事实。以“不同语言译文”为例，应先明确以正式中文文本核对，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“不同语言译文”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“以正式中文文本核对”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对不同语言译文，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“不同语言译文”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“以正式中文文本核对”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解以正式中文文本核对时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
历史协议版本
适用事实。以“历史协议版本”为例，应先明确需要区分当时生效时间，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“历史协议版本”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“需要区分当时生效时间”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对历史协议版本，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“历史协议版本”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“需要区分当时生效时间”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解需要区分当时生效时间时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
其他文件名称
适用事实。以“其他文件名称”为例，应先明确仅列文件名称不产生约束力，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“其他文件名称”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“仅列文件名称不产生约束力”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对其他文件名称，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“其他文件名称”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“仅列文件名称不产生约束力”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解仅列文件名称不产生约束力时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
常见问答
适用事实。以“常见问答”为例，应先明确不能覆盖正文或法定权利，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“常见问答”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“不能覆盖正文或法定权利”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对常见问答，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“常见问答”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“不能覆盖正文或法定权利”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解不能覆盖正文或法定权利时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。
继承人请求
适用事实。以“继承人请求”为例，应先明确核对身份和法定申请资格，再从本协议术语只用于理解已述认证规则这一原则出发理解本章关于术语、版本与附则的既有约定。如果同一叙述涉及其他业务或其他人，应把不同主体、不同时间和不同服务分开核对；只有确认事实落在本章已有规则的适用范围内，才能讨论相应的认证结果或处理路径。
所需信息。在“继承人请求”这一情境中，需要分辨的是适用版本、中文文本及其他文件是否已实际提供，并核对“核对身份和法定申请资格”这一判断所依据的具体事实。举例文字只是说明应核对什么，不要求用户额外提交未在实际页面或依法适用的规则中说明的材料。平台若需要补充信息，应围绕适用版本、中文文本及其他文件是否已实际提供说明具体疑点、用途和必要范围；用户也可以先询问为什么已有资料不足。不能因为材料名称相近，就把不同用途的个人信息混为同一份授权。
用户判断。面对继承人请求，用户可以先查看当前页面、已公示规则以及自己保存的申请记录，再结合阅读实际展示的协议文本并保存需要的版本线索这一相关事项，决定是否核对适用版本及其他文件适用情况。如果实际入口没有相应选项，不应为了配合示例而选择错误身份类型、借用他人资料或重复提交。用户说明情况时，应区分亲身知晓的事实、从页面看到的提示和对原因的推测；这样的区分有助于后续核对，也不对任何争议事实作预先推定。
平台判断。平台处理“继承人请求”时，应以本协议术语只用于理解已述认证规则为出发点，核对适用版本、中文文本及其他文件是否已实际提供及其他可核实的记录，再结合“核对身份和法定申请资格”判断具体影响。页面提示、技术信号与用户材料的证据价值各不相同，需要放在同一事实脉络中理解。若结论影响已取得的服务或个人信息权益，应按现有条款和适用法律处理告知、复核与纠错；本例不预设一定得到何种处理结论。
边界与例外。理解核对身份和法定申请资格时，应同时守住本章边界：未向用户提供的其他文件不构成本协议内容。