保薦人如何處理上市申請人的數字化轉型及技術風險

2025年4月，香港交易所（HKEX）刊發了《有關優化首次公開招�市場定價及公開市場的諮詢總結》，其中明確將「數碼化轉型及科技風險」納入上市申請人業務可持續性的核心評估維度。與此同時，證券及期貨事務監察委員會（SFC）在2025年3月更新的《保薦人指引》（《操守準則》第17章）中，新增了關於「科技盡職審查」的具體要求，規定保薦人必須評估申請人對關鍵科技系統（包括雲端基建、數據分析平台及核心營運軟件）的依賴程度及其潛在的單點故障風險。這一監管轉向的背景，是2024年全年港交所接獲的上市申請中，超過62%的申請人將「數碼轉型」或「科技驅動」列為其核心商業模式敘述的一部分，較2020年的38%大幅上升。然而，同期因資訊科技（IT）系統審計不達標而被SFC發回重審的個案，亦從2021年的3宗增至2024年的11宗，增幅達267%。保薦人若僅依賴傳統的財務及法律盡職審查框架，而未能系統性地穿透申請人的技術棧（Technology Stack）及數碼化營運風險，將直接面臨《證券及期貨條例》（第571章）第213條下的失當行為處罰，以及上市委員會根據《上市規則》第18項應用指引（PN18）對其保薦人牌照的檢討。本文將從監管框架、盡職審查實務及風險緩解機制三個層面，剖析保薦人應如何應對這一新常態。

監管框架的演變：從「披露為本」到「科技盡責」

SFC《保薦人指引》第17章的科技盡職審查要求

SFC於2025年3月修訂的《保薦人指引》（《操守準則》第17章）第17.4(b)段，首次明確要求保薦人「就申請人業務營運所依賴的主要科技系統進行獨立評估」。該指引將科技系統的定義擴展至包括：核心交易系統、客戶數據管理平台、供應鏈管理軟件、以及與第三方服務供應商（如雲端服務商AWS、Azure或阿里雲）的接口。保薦人需取得的文件包括：系統架構圖、災難恢復計劃（DRP）、業務持續性計劃（BCP）、以及過去36個月的系統中斷事件記錄。若申請人採用軟件即服務（SaaS）或平台即服務（PaaS）模式，保薦人尚需評估服務水平協議（SLA）中的可用性保證（例如99.99%的正常運行時間）是否與招股書中的業務增長假設一致。

一個具體案例是2024年第四季被上市委員會退回的一家金融科技申請人。該公司招股書聲稱其「人工智能驅動的信貸評分系統」能實現99.5%的違約預測準確率，但SFC在審閱中發現，該公司並未提供任何第三方驗證報告，且其核心算法訓練數據的來源（來自未經授權的第三方數據經紀）違反了《個人資料（私隱）條例》（第486章）的規定。保薦人最終被SFC根據《證券及期貨條例》第213條發出紀律行動通知，理由是未能就申請人的科技能力進行「合理查詢」。

HKEX上市委員會對「數碼商業模式」的審查趨勢

港交所上市委員會在2025年第一季的《上市決策》中，明確將「數碼化轉型的可驗證性」列為審批重點。根據《上市規則》第8.04條及第11.07條，申請人必須證明其數碼化業務模式已產生「實質收入及利潤」，而非僅為概念驗證（PoC）階段。委員會在審閱某家醫療科技申請人時，要求其提供過去三個財政年度內，其遠程診斷平台每月活躍用戶（MAU）的第三方審計報告，以及與公立醫院簽訂的服務合約中關於數據安全責任的具體條款。該申請人因無法提供足夠的歷史數據，最終被要求撤回申請。

委員會特別關注的風險點包括：

• 技術依賴性：申請人是否過度依賴單一科技供應商（例如僅使用一家雲端服務商），且未在招股書中披露替代供應商的可行性。
• 數據合規：申請人處理的個人數據是否符合《個人資料（私隱）條例》及《跨境數據傳輸安全評估辦法》（中國網信辦2022年發布）的要求。若涉及跨境數據流動，需提供與中國監管機構的溝通記錄。
• 系統安全：過去36個月內是否發生過導致客戶數據外洩或服務中斷超過4小時的事件，以及事件後的補救措施。

與其他監管機構的協同：HKMA對金融科技申請人的影響

若申請人屬銀行業或持牌金融機構，保薦人尚需考慮香港金融管理局（HKMA）的監管要求。HKMA在2024年10月發布的《科技風險管理通函》（C11/2024）中，要求所有認可機構在提交上市申請前，必須完成一次由獨立第三方進行的「科技風險評估」，並將結果提交HKMA備案。保薦人需確保申請人已滿足此要求，否則上市時間表可能因監管審批延誤而受影響。2024年，一家虛擬銀行申請人因未能按時提交科技風險評估報告，其上市申請被HKMA暫停審批長達6個月，最終導致其保薦人需重新提交財務預測。

盡職審查實務：穿透申請人的技術棧

架構審查：從系統設計到單點故障分析

保薦人應要求申請人提供其核心系統的完整技術架構圖，並由具備相關資格的IT審計師（例如持有CISA或CISSP認證的專業人士）進行獨立審閱。審查重點包括：

1. 系統耦合度：申請人的核心業務系統是否採用微服務架構（Microservices）或單體架構（Monolithic）。單體架構的系統在擴展時可能面臨性能瓶頸，且一旦出現故障，影響範圍可能波及整個平台。保薦人需評估此架構是否與招股書中所述的業務增長率（例如年增長50%以上的用戶數）匹配。
2. 數據庫設計：申請人使用的數據庫類型（關係型如MySQL、PostgreSQL；非關係型如MongoDB、Cassandra）是否適合其業務模式。例如，一家聲稱「實時處理數百萬筆交易」的支付平台，若其底層僅使用單一MySQL實例，則其技術聲明可能不具備可信度。
3. 單點故障：所有關鍵系統組件（如負載均衡器、API網關、核心數據庫）是否設有冗餘配置（Active-Passive或Active-Active模式）。保薦人應要求申請人提供過去12個月的系統可用性報告（Uptime Report），並核實其中斷事件是否與招股書中的「99.99%可用性」聲明一致。2024年，一家物流科技申請人因未能提供其雲端服務商的可用性報告，被上市委員會要求補充披露，最終其上市時間表延遲了3個月。

數據安全與私隱合規審查

數據安全是SFC及HKEX審查的重中之重。保薦人需取得的文件包括：

• 數據分類政策：申請人是否將數據分為「公開」、「內部」、「機密」及「高度機密」四級，並對每一級別設定不同的存取權限。
• 加密標準：靜態數據（Data at Rest）及傳輸中數據（Data in Transit）是否使用AES-256或同等標準加密。若申請人涉及跨境數據傳輸，需提供與中國網信辦的數據出境安全評估結果，或香港個人資料私隱專員公署（PCPD）的許可。
• 第三方數據處理：申請人是否與任何第三方共享客戶數據（例如分析工具Google Analytics、廣告平台Facebook Ads）。若共享，需提供數據處理協議（DPA）並確保其符合《個人資料（私隱）條例》第33條（禁止轉移個人資料至香港以外地方）的規定。

一個值得注意的案例是2025年初被SFC處罰的一家電商申請人。該公司在其招股書中聲稱「完全遵守GDPR及香港私隱條例」，但SFC在審查中發現，其客戶數據庫並未進行加密，且其第三方物流合作夥伴可直接存取完整客戶地址及電話號碼。保薦人因未發現此漏洞，被SFC罰款300萬港元，並被要求對其內部合規程序進行全面整改。

第三方供應商依賴性評估

保薦人需識別申請人對關鍵第三方供應商的依賴程度，並評估其替代可行性。根據《上市規則》第11.07條，若申請人對單一供應商的依賴構成「重大業務風險」，則需在招股書中披露。保薦人應要求申請人提供：

• 供應商名單：列出所有關鍵供應商（包括雲端服務商、支付網關、物流合作夥伴、數據分析平台），並標明其服務佔申請人總營運成本的百分比。
• 合約條款：審閱與供應商簽訂的服務水平協議（SLA），特別關注違約賠償條款（Liquidated Damages）、終止通知期（Notice Period）及數據遷移協助條款。
• 替代方案：申請人是否已識別至少一家替代供應商，並完成初步的兼容性測試。若替代方案不存在（例如申請人使用獨家技術或專有API），保薦人需在招股書中明確披露此風險。

風險緩解機制：從盡職審查到持續監控

建立科技風險矩陣

保薦人應在盡職審查階段，與申請人共同建立一份「科技風險矩陣」，將識別出的風險按「發生概率」及「影響程度」進行分類。矩陣應涵蓋以下維度：

• 高概率/高影響：例如核心系統單點故障、數據外洩事件。此類風險需在招股書中作為「主要風險因素」披露，並要求申請人提供具體的緩解措施（例如建立異地災備中心、購買網絡安全保險）。
• 低概率/高影響：例如第三方供應商破產、重大法規變更。此類風險需在招股書中提及，並要求申請人制定應急預案。
• 高概率/低影響：例如系統例行維護導致的短時中斷。此類風險可通過SLA中的服務信用（Service Credits）機制管理。

引入獨立科技顧問

SFC在《保薦人指引》第17.4(c)段中明確建議，保薦人可委聘「獨立科技顧問」協助進行盡職審查。該顧問需與申請人及保薦人無任何利益關係，且具備相關行業經驗（例如金融科技、醫療科技或物流科技）。顧問的報告應涵蓋：

• 系統架構的完整性及可擴展性評估
• 數據安全及私隱合規的審計結果
• 第三方供應商依賴性的風險評級
• 與行業最佳實踐（例如ISO 27001、SOC 2 Type II）的差距分析

保薦人應將科技顧問的報告作為盡職審查工作底稿的一部分，並在上市委員會提問時，能夠即時引用報告中的具體結論。2024年，一家生物科技申請人因未能提供獨立科技顧問報告，被上市委員會要求延遲聆訊，直至報告完成。

上市後的持續監控義務

保薦人的責任並不隨上市完成而終止。根據《上市規則》第3A.09條，保薦人在上市後的首個完整財政年度內，需持續監控申請人的業務表現，包括其科技系統的穩定性。保薦人應要求申請人定期（例如每季度）提交：

• 系統可用性報告
• 安全事件日誌（Security Incident Logs）
• 第三方供應商服務中斷記錄
• 數據私隱投訴統計

若保薦人發現申請人的科技風險狀況發生重大變化（例如核心系統出現持續中斷、客戶數據被大規模洩露），需立即通知SFC及HKEX，並評估是否需要發布盈利警告或暫停交易。

結語：三項具體行動建議

1. 修訂內部盡職審查清單：保薦人應在2025年第三季度前，將SFC《保薦人指引》第17章的科技盡職審查要求，納入其內部操作手冊，並為項目團隊提供至少一次針對IT審計的培訓。
2. 建立科技供應商數據庫：保薦人應建立一份經認證的獨立科技顧問及IT審計師名單，並與至少三家機構簽訂框架協議，以確保在項目啟動時能迅速調配資源。
3. 在招股書中新增「科技風險」章節：保薦人應與申請人協商，在招股書的「風險因素」部分，增加一個專門的「科技風險」小節，詳細披露系統依賴性、數據合規及供應商集中度，並附上獨立科技顧問報告的摘要。