支付清算网络运营商PCH SO授权

NPS法第1条将PCH SO界定为代表两家或以上SARB结算系统参与者清算的人，但排除指定结算系统运营商。这里的清算指支付指令的交换；相关业务可以涉及核对、轧差以及代表参与者形成结算指令，最终结算的法律效力仍依结算系统和参与者安排确定。申请书应明确委托方是谁、接入哪个PCH、哪些指令进入运营商系统以及结算义务由谁履行，不能只写提供支付科技平台。

普通SO主要向两个或以上客户提供与支付指令有关的服务，可将指令送达银行或PCH SO；PCH SO则处于参与机构之间的清算基础设施层。单为商户提供收款接口、批量代付文件传输或支付网关，不能据此直接称为PCH SO。反过来，取得普通SO授权也不当然允许运营参与机构间的PCH清算网络。

PCH SO授权不会自动把运营商变为NPS法第6条下以自身身份清算的参与者，也不自动授予SAMOS结算账户或第4A条指定结算系统身份。公开名录中Strate的PCH SO项目包括债券、货币市场和股票支付流，但这不等于单凭PCH SO授权即可开展证券中央存管或中央对手方业务。产品说明应把支付清算运营、参与者资格和其他金融业务权限分开。

该授权适合由参与机构共同使用、需要在多家机构之间持续处理同类支付指令的清算平台，而不是只服务一个企业自身付款的内部系统。业务论证应从目标支付流和参与机构的共同需要出发，例如电子贷记、电子借记、实时清算或卡交易，解释新网络与现有结算设施如何衔接，以及出现迟到、重复或错误指令时如何处理。技术降低成本只是商业优势，不能替代参与者正式委托和准入审查。

SARB公布的2026年7月名录提供了具体的权限定位例子：PayInc列有EFT Credit、EFT Debit、RTC和Rapid Payments等清算流；Mastercard和Visa列有卡及ATM相关清算流；Strate列有债券、货币市场和股票PCH。这说明同一运营商可以覆盖多个已列明支付流，但某运营商具备某项能力并不证明新申请人可自动取得同样范围。拟增加支付流应单独说明规则、参与者、连接和风险控制。

2026年移交后，业务协调和法定授权须找不同的责任方。SARB现行移交页面把卡、高价值及证券相关PCH协调列在SARB一侧，把EFT、PayShap、Registered Mandate和RTC等协调列在PayInc一侧，同时明确支付机构许可、授权和登记由SARB负责。申请人可就相应业务流开展协调，但与PayInc或现有参与机构签约不等于已取得监管授权。

准入首先要有符合PCH SO法定定位的参与机构关系。SARB的2024年参与指南第D节要求由两家或以上清算参与者委任运营商，并就相关PCH及服务安排进行确认；NPS法的PCH SO定义则具体指向代表两家或以上SARB结算系统参与者清算。实务上须识别每家拟委托机构的清算及结算身份，提供委托或拟签服务协议，不能把两家普通商户或集团内两个无相应资格的公司当作满足条件。

2026年8月11日移交通告是现行申请入口的重要依据：第3.2.2段保留在途案件适用的PASA PCH SO准入标准，第3.2.3段要求其后新申请在本类替代标准公布前按该标准提出。由于本次未取得该专属标准的完整公开文本，不能声称所有公司组织形式、境外分支或外资结构均有资格，也不能凭普通SO的交易量触发标准判断PCH SO是否需要申请。应先向PCHSO@resbank.co.za取得适用于本申请日期的标准和清单。

技术接入与法定授权相互关联但不是同一动作。2024年指南第D节列有与NPSD及其技术部门启动项目、确认SAMOS基础设施要求、SWIFT接入与系统测试、签订包括业务连续性及灾难恢复内容的服务水平协议。该指南涉及PASA理事会的旧审批节点已被2026年移交安排改变，不能原样照办；尚适用的接口、测试和上线条件应由SARB项目团队针对拟议架构确认。

• 先确认至少两家委托机构的法定参与身份及对应PCH。
• 向SARB取得PCH SO专属现行标准、申请文件清单和提交方式。
• 分别取得监管审查结论、技术测试结果与参与机构的正式上线同意。

PCH SO的治理不能只列名义董事。Directive No. 01 of 2024明确将PCH SO包括在运营商范围内，并要求董事会或高级管理层批准网络安全政策、战略和韧性框架，确定风险容忍度，保证框架与运营风险、业务连续性安排衔接，且至少每年审阅。申请材料应说明由谁对清算运营、结算接口和网络风险负责，以及董事会通过什么报告获知重大风险；这类责任不会因技术外包而消失。

该指令第5.1.1段要求任命具有相关技能、专业知识及经验、对网络安全和网络韧性负责的高级主管及技术专家，并持续培训有关员工。实务人员文件宜包括组织架构、履历、授权范围、事件升级及代岗机制，解释系统操作、权限授予和事件处置的职责如何划分。公开材料未证明PCH SO普遍必须配置某个固定人数、指定头衔的FAIS关键个人或FSCA认可合规官，不应借用其他牌照的人员配置。

股东和控制链应在申请及收购尽调中明确展示，以便SARB识别谁实际控制运营商、谁提供资金以及委托参与机构是否兼任股东。这是针对多边清算基础设施的审查准备建议，不表示已核实到统一的本地持股比例、独立董事比例或居住年限。本次未取得PCH SO专属股东及董事适当性细则，控制人批准、任职变动和关联机构冲突的具体要求应向SARB书面确认，不能把参与银行委托运营商等同于其必须持有运营商股份。

自有资本方面，本次已读的NPS法、2026年移交通告及SARB参与指南未提供适用于所有新PCH SO的统一兰特最低资本额，因此不能据此得出零资本要求，也不能套用银行资本或普通SO财务标准。SARB的PFMI立场文件要求系统重要支付基础设施遵循相关原则，并可对其他基础设施采用适当要求。申请时应先确认拟议网络的重要性分类、适用的财务资源和恢复安排，再取得针对本项目的资金条件。

营运现金与资本须分开核算。PCH SO的预算应覆盖参与机构接入、消息网络与测试、主备系统、网络安全人员、独立技术验证以及发生事故后的持续运营和退出成本；这些是准备财务模型的实务项目，不是本次已核实的统一监管收费或现金储备倍数。可提交现有财务报表、资金来源说明、现金流预测及股东资金支持安排供审查，不能用注册股本数字替代实际可支配的营运现金证明。

参与机构的结算资金、担保或潜在客户资金不应混作运营商自有资本。PCH SO的核心身份是代表参与者处理清算指令，不当然享有收存公众款项或任意调配参与者结算资产的权利。若方案要求运营商控制资金，应画明账户名义、持有人、资金流向和破产时归属，并另行取得业务定性意见；不能因为系统处理很大的支付金额，就把该金额作为运营商可用流动性。

顾问费、技术供应商费、连接费用与向监管机关缴付的申请费应分别列示。当前未核实到公开可读且适用于2026年PCH SO新申请的完整申请费、年费或续授权收费表，报价应把官方费用标为待SARB确认，第三方费用以合同约定列明。任何顾问服务付款均不能换取保证授权、保证接入或保证银行开户。

本项的地址实务重点是运营控制及系统韧性，而不仅是登记一个公司收件地址。SARB参与指南第D节规定灾难恢复设施须处于与主要设施不同的地点，并要求具备冗余安排、定期测试及报告测试日期和结果。资料中应分别标示法律送达或登记地址、实际运营团队所在地址、主要系统地点和灾备地点，说明在主站点完全不可用时由谁在何处接管清算服务。

网络安全指令第6部分允许SARB对支付机构或运营商进行现场及非现场检查，对营业场所、私人住宅和持令进入的程序作区分。因此只提供虚拟办公室而无法指出实际承担运营、保存资料和配合检查的场所，不能证明满足本项的运营能力。可用场地和服务协议、系统资产清单及主备责任分工支撑事实，但本次没有核实到统一面积、租期、主备站点最小距离或全部员工须驻南非的数值门槛。

如拟使用云服务或境外数据中心，不能把云厂商地址当作监管责任的替代。指令第5.1.5.1(j)段要求遵守SARB对云及数据离岸的适用要求，识别跨司法辖区风险，并由机构继续对数据和方案安全负责。本次未取得可证明所有PCH SO必须境内存储或可无条件境外处理的本类完整规则，应在签约前把处理、存储、备份地点和监管访问机制交SARB确认。授权事务现行联系点为PCHSO@resbank.co.za，不再将旧PASA办公地点当作默认受理地址。

已能从官方指南确认的核心资料围绕参与者委托和清算安排：应识别至少两家委托机构、相关PCH及计划提供的服务，并准备参与者与运营商之间的服务协议。为让SARB判断是否确属PCH SO，申请说明宜附支付指令交换、轧差、结算报文、最终结算及异常处理流程图，逐一标出责任主体。业务流清单应与申请范围一致，避免以某项EFT测试结果支撑所有卡和证券支付流的经营主张。

技术文件应能支撑SARB项目启动、接口确认和测试验收，重点包括系统及通信架构、连接依赖、SWIFT适用安排、测试记录，以及含业务连续性和灾难恢复要求的服务水平协议。网络安全指令还直接要求书面网络治理、资产和依赖识别、访问控制、恢复测试及第三方风险安排，因此可将这些正式政策、演练结果和外包协议中的安全责任条款组合成证据包，而不是只提交供应商宣传册。

为配合实体及财务核验，建议同时备妥登记资料、股权控制链、董事及负责主管资料、资金说明和经营预测；这里的建议清单并非已取得的PCH SO现行表格附件。须先向SARB索取专属申请表及文件版本，确认签字、认证、格式和资料更新要求。对2026年8月11日前已向PASA递交的案件，通告第3.3段明确历史资料随案移交，原则上无须重复提交，只有SARB要求补充或更新时才重报相应内容。

• 参与者身份、委托文件、相关PCH和服务协议。
• 支付与资金流图、结算责任矩阵、申请业务流清单。
• 接口和系统测试材料、服务水平协议、主备及灾备演练证据。
• 网络安全治理、第三方风险及事故报告程序；实体和财务资料按SARB现行清单补齐。

第一步是角色预核验：将拟服务的参与机构、目标PCH、处理流程、结算路径和资金控制情况发至PCHSO@resbank.co.za，说明是全新申请还是PASA移交的在途案件，并索取当前PCH SO专属标准及提交清单。主管团队为SARB NPSD的PRLD。现行移交页面另列一般授权咨询邮箱nps-licensingauthorisations@resbank.co.za；与2026年8月通告所列旧格式一般咨询邮箱不完全相同，故本项宜优先使用两处一致的PCH SO专用邮箱。

第二步是把参与机构的商业委任、相应业务流规则协调及技术接入计划落实为文件。2024年指南列有NPSD与技术部门项目会议、SAMOS要求确认、适用的SWIFT接入、连接和系统测试，以及服务水平协议。2026年后应由SARB确认现行项目责任人和审批顺序；PCH协调如由PayInc承接，应就该业务流取得协调结果，但不能将其替代SARB的授权决定。

第三步是完成监管问询和技术验证，关闭系统测试及网络韧性问题，取得书面授权及适用条件，再安排参与机构上线。公开名录核验可作为后续尽调的一部分，但不能只以名录列名推定所有新业务流均获许可。在途申请无需因移交另起一套新案：2026年通告规定原案件由SARB接续处理，申请人应沿用可识别案卷的资料，并按新联系渠道提交后续文件。

• 业务角色及范围确认，取得现行标准和申请材料清单。
• 落实参与者委托、PCH规则协调、技术方案及相应协议。
• 完成审查问询和技术验证，确认书面授权条件及上线节点。

已经核实的制度时间点必须区分：2026年8月11日是授权和登记职能开始移交SARB以及过渡安排生效日；2026年9月2日才是PASA作为PSMB的认可撤回生效日。移交网页下部仍有提及9月1日完成的工作材料，但正式通告第2.2及3.1段明确为9月2日，应以此解释法律生效，不把两个日期混写为同一天。

项目排期应分成材料准备、参与机构及业务流协调、技术接入测试、SARB监管问询和最终生效上线。准备阶段是否顺利，取决于能否取得正式委托、系统架构是否可测及主备方案是否成熟；这不等于官方受理后有统一审结天数。本次未核实到PCH SO现行法定或公布服务标准，2024年指南中的SWIFT旧处理估计也不是SARB审批承诺，不应据此销售固定月数包批。

获授权后的运营时限则有明确规则，不应与申请周期混淆。网络安全指令要求重大网络事故24小时内向SARB通报，并在攻击后48小时内提供报告；对支付、清算及结算系统和支付系统FMI，关键运营恢复目标为两小时，延长须事先获SARB批准，不能把一般支付机构的八小时上限当成本项系统的默认恢复目标。恢复计划须按季度测试，网络政策及框架须年度审阅。

有效期和续授权节奏应以个别授权书及SARB通知核对。2026年通告确认既有PCH SO授权继续有效，亦覆盖过渡期面临续期或重新授权的情形，但没有由此建立所有PCH SO永久有效或统一每年续期的规则。不能把过渡连续性解释为到期无需联系监管机关，亦不能在没有通知的情况下自行设定续期截止日。

收购PCH SO时应先核对获授权的具体法律实体、登记编号、既有业务流及授权书条件，而不是只购买品牌、软件或一张名录截图。SARB的2026年7月名录把实体登记和交易名称对应列出，例如PayInc对应South African Bankers Services Company (Pty) Ltd。股权收购与把业务转入另一个新实体是不同交易，2026年对既有授权的保留也不意味着授权可随资产合同自动转让。

控制人审查、董事或负责主管变更、公司层面登记及支付参与者合同须分开处理。本次未核实到PCH SO统一持股变动触发比例、统一控制人预批准表格或固定通知天数，因此交易文件不应假定低于某个比例就无须接触SARB。可在交割前将交易前后股权链、控制安排、资金来源及拟任治理团队交PCHSO专用邮箱，要求监管机关书面确认本案所需批准、通知或重新授权步骤，并核验原服务协议是否要求参与者同意。

新增PCH或支付流、重大系统升级、外包及云迁移也不能只当作内部管理事项。名录中的业务流分列说明范围核验的重要性；网络安全指令要求重大系统变更后开展测试，并要求持续识别第三方与跨境云风险。具体是否需要事先同意应看本实体授权条件及SARB答复；在取得确认前，不宜用原有测试或授权范围对外承诺新网络已经可上线。

NPS法第13条直接把PCH SO列为记录保留主体，支付系统运营及管理中取得的有关记录须自各份记录日期起保留五年；第10条要求依SARB指定形式和时间提供所需信息。实务上应让支付指令、清算结果、结算报文、异常处理和变更记录能够按参与机构与业务日追溯，并确保外包终止或系统迁移后仍可检索。五年规则不是只保留年度报表，监管机关可以要求与具体支付系统相关的信息。

网络治理须持续执行。董事会或高级管理层年度审阅网络政策和韧性框架，第三方服务商须在引入前及按年度进行风险评估，响应和恢复计划须季度测试；重大系统变更后还须进行安全测试。关键系统访问须采用适当多因素认证等防护，云和外包方案不能转移运营商责任。发生重大网络事故时要履行24小时通报及48小时报告，并持续更新处置情况，报告内容包括影响、预期恢复、改进措施和潜在系统性影响。

经营维护还包括参与者准入、业务流规则和服务水平安排。NPS法第6A条要求系统接入标准公平、透明和公正，对已符合所设标准的人不得拒绝其接入或参与，不能利用运营商身份随意阻挡符合标准的机构。SARB的PFMI立场文件对系统重要支付基础设施提出更高风险管理期待，但具体适用范围须按系统认定确认；所有运营商都应按授权条件和监管通知维护项目，而非把既有名录资格当作一劳永逸。

截至2026年11月11日的资料基准，官方过渡安排明确保留PCH SO新申请路径，应归类为受条件限制，而不是封闭新设。新申请自2026年8月11日起按过渡规则向SARB提出，原PASA不再作为当下法定授权受理主体。需要监管接触并不等于申请仅限现有四家运营商，也没有证据表明名录上的四家数量构成法定配额。

在途案件和既有运营商的处理不同。2026年8月11日前提交的PCH SO申请由SARB继续办理，历史申请资料随移交转入；既有授权则保持有效，除非SARB另作决定，过渡期续授权情形亦有连续性安排。申请人应保留原案卷和通信证据，向PCHSO@resbank.co.za确认案件状态，不应因旧PASA入口关闭便推断案件失效或重新购买所谓新牌照。

现行入口仍要求核实本类文件版本。本次读取的2026年10月普通SO标准第2.1段说明其取代PASA的SO标准，不能据此把PCH SO改套同一门槛；本次未取得PCH SO专属替代标准全文。正式提交前须确认当前PCH SO标准、表格、费用和适用的系统接入条件。本档案实际复核日为2026年11月12日，引用的制度文件均早于资料基准日，不据较晚访问日推定基准日后发生了新政策变化。