1)
你們說的「數位運算」是什麼？跟一般 IT 系統差在哪？
我們的「數位運算」是把氣候財務風險工作做成一套可持續運行的機制：資料能彙整、結果能回放、版本能封存、責任能追溯。這比較接近銀行監理長期強調的「風險資料彙整與風險報告能力」，而不是單一工具或單次專案。
2)
為什麼金融業需要把氣候風險做成「運算中心」？
因為監理與市場期待銀行把氣候風險納入治理與風險管理體系，並在資料與揭露能力上逐步成熟化；靠手工彙整與零散文件，通常無法穩定支撐季度/年度節奏。BCBS 的氣候風險原則就是在提供銀行與監理的共同底線（governance、risk management、data、disclosures）。
3)
你們一直強調「可追溯、可回放」，這是誰要求的？
這不是我們自己喊口號。永續資訊確信的國際準則 ISSA 5000 的目標就是提升投資人、監理等對永續資訊的信任與信心，作為可適用於各類永續主題的通用確信準則；因此資訊品質、可檢視性、可支撐性會越來越重要。
4)
數位運算一定要先把模型做得很深、很精準嗎？
不一定。第一優先通常是把「輸入—輸出—版本—責任」做清楚，讓工作可重現、可說明，然後再逐步提升資料與模型成熟度。這也符合 IFRS S2 的精神：要求揭露氣候風險與策略韌性評估，並使用氣候情境分析來支撐該評估。
5)
IFRS S2 真的需要情境分析嗎？數位運算跟它怎麼接？
IFRS S2 是 ISSB 在 2023 年發布的氣候揭露準則，並明確指出整合並建立在 TCFD 架構上；情境分析用來評估策略與商業模式的韌性，是關鍵工作之一。數位運算的價值就是把情境分析從「一次性報告」變成「可版本化、可更新、可回放」的運行節奏。
6)
我們到底要「運算」哪些東西？會不會變成黑盒子？
網站對外不需要承諾任何特定演算法；你只需要承諾「黑盒子會被治理」。我們建議用可被檢視的方式表達：Input（情境/假設/範圍/版本）、Output（主要差異點、敏感度方向、受影響面摘要）、Version freeze（本期封存版本）。這種表達方式能降低黑盒質疑，也更接近準則/監理對「可支持、可說明」的期待。
7)
你們說 near real-time（近即時）有價值，但又說要封存版本，會不會矛盾？
不矛盾。風險管理需要「及時性」與「頻率」，而且在壓力/危機期間通常需要提高報告頻率；但對外揭露與管理層審閱又需要一致口徑，所以要有「封存版本」。這正是 BCBS 239 在風險資料與報告原則中強調的方向（timeliness / frequency）。
8)
數位運算會不會變成「資料越收越多」導致風險更大？
正確做法是「資料最小化 + 權限分層 + 可追溯」。BCBS 的氣候風險管理原則與銀行資料治理的監理脈絡都在提醒：治理與資料能力要同步成熟，而不是無限制擴張。
9)
我們需要哪些部門一起參與？IT 做完就好了嗎？
IT 是必要但不充分。BCBS 的氣候風險原則談的是治理與風險管理體系，代表永續、風險、財會、稽核/內控與 IT 需要形成「責任鏈」，才會有可持續的交付節奏。
10)
數位運算的「成果」怎麼呈現，才符合國際投資人可用？
除了人看得懂，還要往「機器可讀、可比較」前進。ISSB 在 2024 年 4 月發布 IFRS Sustainability Disclosure Taxonomy，反映 IFRS S1/S2 的揭露要求，目的是讓投資人更容易搜尋、擷取、比較永續相關財務揭露。
11)
你們的證據路徑/目錄是國際準則的原文要求嗎？
「Evidence Pack / Index」不是 IFRS/BCCS 的官方名詞，而是我們把國際方向（可檢視、可支撐、可提升信任）做成更容易落地的交付形式；核心目標是讓永續資訊在面對確信時更可控。
12)
從 0 到 1，最快的開始方式是什麼？
用最小可交付啟動：先建立 I/O（輸入輸出）+ 封存版本 + 責任分工，讓季度節奏跑起來，再逐步擴充資料與情境深度。這會更貼近 IFRS S2 的揭露邏輯與銀行監理對資料/報告能力的成熟化方向。