Google Cloud 瑞士法郎試點結合即時轉賬與延後結算

Google Cloud 詳述一項瑞士銀行業試點計劃，將客戶即時轉賬與銀行間延後結算結合。Google Cloud 瑞士法郎試點採用代幣化存款，即商業銀行貨幣的數碼化表述，而非要求客戶採用公開穩定幣。其核心取捨在於付款速度止於何處，以及金融責任仍然存續於何處。

穩定幣是旨在追蹤國家貨幣等參考資產的代幣，為數碼支付提供另一種途徑。Tether 的 USDT 和 Circle 的 USDC 等產品，均在用戶之間加入由發行方發行的代幣。瑞士項目則是在既有銀行關係背後部署共享分類賬。

這項差異對銀行技術團隊及企業支付採購方相當重要。該項目提出一條加快轉賬的路徑，毋須圍繞外部貨幣發行方重建客戶關係。然而，現有證據所支持的是一項範圍受限的銀行業實驗，包括據報已完成的真實交易，而非廣泛可用的支付網絡。

Google Cloud 瑞士法郎試點建基於較早前的真實交易

最新進展是對既有試點的技術說明，而非宣布推出一種全新的瑞士貨幣。

Google 於 2026 年 10 月 26 日發表其瑞士法郎架構。文章介紹 Crypto Finance 如何透過 Google Cloud Universal Ledger（GCUL）協調兩家銀行之間的轉賬；GCUL 是一個共享交易記錄平台。

該說明指出，整合工作歷時不足三個月。文中亦承認，部分後端步驟需要人工介入。這些細節確立了一個整合案例，但完整營運自動化的問題仍有待解答。

事件脈絡可追溯至更早之前。Crypto Finance 在其 2026 年 4 月 9 日公布的支付基建試點中，確認 AMINA Bank 和 Incore Bank 為參與者。公告描述，項目已由 2025 年 11 月的概念驗證，推進至生產環境驗證。

根據該公告，參與銀行已處理真實客戶交易。Crypto Finance 亦表示，偵測潛在非法金融活動的反洗錢監控，以及制裁篩查，均構成交易流程的一部分。

這些說法來自參與項目的機構。它們證明的是合作夥伴所報告的情況，而不是獨立的效能審計結果。

真實試點與商業服務之間的分野值得注意。真實客戶交易令證據價值高於實驗室示範，但並不能證明服務可不受限制地使用、能持續可靠運作，或可在更大規模會員群中以具經濟效益的方式營運。

因此，買方應把這些公告視為特定整合路徑的證據，不應把「生產」一詞視作已滿足成熟支付服務所有要求的簡稱。

生產驗證可涉及範圍嚴格受限的參與者、交易類型及營運條件。一般服務則必須支援更廣泛的例外情況、客戶需求及故障情境。

發布時序亦改變新聞角度。10 月的說明為一項早已據報完成真實驗證的計劃提供更多架構細節。若將事件描述為 10 月新推出的服務，便會掩蓋這段歷史。

對企業讀者而言，真正有意義的改變，是能更清楚了解這項安排如何運作。該項目為評估由銀行主導的數碼支付提供具體基礎，而不僅是關於更快區塊鏈的承諾。

它亦要求比較整個支付流程。一項有用的評估應由客戶可用性開始，並以已完成的責任履行、已對賬的紀錄及已有文件記載的責任為終點。

這比記錄一次成功轉賬的標準更嚴格。這亦正是該項目與考慮類似基建的機構相關的原因。

銀行不僅是在捍衛存款，也是在捍衛支付關係

這場策略競爭關乎誰掌握客戶關係，以及誰承擔相關的基礎金融責任。

考慮採用代幣化支付的銀行，除了技術決定外，亦面對商業決定。它可以讓客戶接入其他發行方的貨幣、將自身存款現代化，或針對不同需要同時支援兩種做法。

這些選擇會形成不同依賴關係。外部代幣可提供進入成熟數碼網絡的渠道。由銀行控制的存款安排則可保留較多現有帳戶關係。

McKinsey 對代幣化銀行存款的分析，將此視為資產負債表及分銷問題。該分析認為，代幣化存款可令銀行資金來源現代化，而第三方穩定幣則可能把資金和客戶活動轉移至外部發行方。

該分析亦指出銀行主導路線的弱點：碎片化。專有網絡即使能讓每個平台內部的轉賬順利進行，資金仍可能難以在機構之間流動。

這令銀行面對相反方向的壓力。客戶希望支付服務能觸及其交易對手。銀行則希望保留具有經濟價值的帳戶關係。

一個可保護存款但只有少數收款方可接入的封閉網絡，實際價值有限。一個讓客戶離開其銀行的可接入網絡，雖可解決支付問題，卻可能削弱該銀行的角色。

瑞士項目透過機構間合作來處理這種張力。其意義在於跨行運作，而非只是在單一銀行的帳戶背後加入另一個資料庫。

試想一個示例：企業財資團隊在參與機構之間調動資金。其首要關注是收款方能否在需要時使用資金。財資團隊亦需要可靠的帳戶紀錄及清晰的例外處理流程。

該團隊未必需要持有一種獨立品牌的代幣。保留熟悉的銀行介面，可減少採用所需的行為改變。

然而，熟悉的呈現方式不能代替覆蓋範圍。若供應商在參與網絡以外的銀行開戶，企業仍須為該筆付款尋找另一條途徑。

穩定幣在此仍保有具意義的競爭地位。其吸引力部分取決於能否接觸特定銀行安排以外的交易對手及服務。

比較應保持中立。公開可用不保證適合每項企業工作流程。機構會員資格亦不保證每筆交易都能獲得更佳執行。

對銀行買方而言，有用的問題是：哪一條路徑能在可接受的控制措施下，滿足可明確界定的支付需要。這要求具體說明交易對手、營運時間、資金要求及失敗付款的處理方式。

對基建供應商而言，壓力同樣具體。他們必須證明，加入共享分類賬可充分改善整體服務，以合理化另一項營運依賴。

因此，Google Cloud 代幣化存款應放在更廣泛的銀行服務設計討論中。相關基準應包括現有支付基建，而不僅是公開區塊鏈替代方案。

銀行不會單靠採用更新的技術標籤贏得這場競爭。當客戶能以更清晰的可用性、可靠的紀錄及可接受的金融風險完成必要付款時，它才算勝出。

即時轉賬與延後結算解決不同問題

面向客戶的速度與已完成的銀行間結算是兩項不同特性，買方需要兩者的證據。

結算是指履行交易所產生的金融責任。客戶看見資金到賬，本身並不能解釋參與銀行如何彼此完成結算。

Google 表示，該試點選擇延後結算，讓銀行定期結算累積責任。Crypto Finance 擔任貨幣營運方，即負責網絡營運規則的實體。

其底層技術為淨額結算，即抵銷責任，讓參與者只需結算餘下結餘。其潛在吸引力直接明確：相反方向的付款可減少其後需要調動的金額。

這是項目資本效率論點背後的核心機制。更快的客戶轉賬毋須為每項指令分別進行底層結算調動。

然而，減少結算資金需求與降低金融風險是兩項不同主張。若負責付款的機構無法履行責任，較小的淨額責任仍然可能十分重要。

一個例子可更清楚說明這項區別。參與銀行的客戶在一段營運時間內，持續向相反方向付款。銀行記錄這些轉賬，然後根據協定規則確定其餘下責任。

抵銷資金流可減少所需結算的餘額。若資金流主要朝同一方向流動，抵銷便會較少。

這意味着，經濟結果部分取決於支付模式。活動平衡的網絡，其表現可與長期持續匯出或收取資金的機構主導之網絡有所不同。

單靠展示該機制，不能得出普遍節省流動資金的結論。買方需要與其相關的交易模式及營運條件的證據。

流動性，即在責任到期時取得資金的能力，仍然是一項營運要求。延後結算改變的是其時間安排及分布，而非將其移除。

這亦涉及客戶服務問題。在相應銀行間責任尚未履行前，機構應就資金可用性作出甚麼承諾？

這項承諾需要合約依據。當參與者達到限額、未能履行責任或無法運作時，亦需要相應的營運處理方式。

因此，「GCUL 結算解釋」應由分類賬活動與金融完成之間的區別開始。將兩者視為可互換，會令架構看來比買方實際責任更簡單。

分類賬可以協調已協定的指令。它不能自行補足陷入困境機構所欠缺的資金，亦不能決定損失應如何分配。

這些問題需要一套規則手冊，在例外情況發生前分配權力和責任。軟件可執行該協議的部分內容，但正是協議賦予這些行動金融意義。

評估亦應把一般營運與壓力情況分開。合作測試期間成功完成付款，所回答的是另一個問題，與參與者出現分歧或無法付款時系統能否持續運作並不相同。

對開發人員而言，這項區別影響系統邊界。付款應用程式需要準確呈現各種狀態，包括已接受的指示、可用客戶餘額，以及已完成的結算。

將這些狀態合併為單一成功訊息，可能掩蓋財資、合規及客戶支援團隊所需的資訊。清晰的狀態定義有助這些團隊以一致方式處理同一宗交易。

對企業買家而言，箇中教訓同樣實際。應詢問哪一事件令付款可用、哪一事件令付款最終完成，以及兩者之間由誰承擔風險敞口。

從這些問題來看，Google Cloud 瑞士法郎試點最具參考價值。其公布的架構提供了一條協調付款速度與資金效率的途徑，而管治機制決定可接受的取捨。

合規取決於可執行的責任

受控網絡可以支援合規，但其技術設計本身並不能獨立確立監管批准。

「設計上合規」描述的是一種架構意圖。讀者應把這種意圖，與監管機構就特定服務、機構或交易所作的決定區分開來。

Google 的說法提及持牌參與、由營運商訂定的規則，以及發行限額。發行限額會限制參與者在該安排下可創建的數量，有助為風險敞口設下界限。

這些控制措施十分重要，因為單憑成員資格並不能決定行為是否安全。參與者仍需要明確責任、有效監察，以及在情況改變時作出回應的程序。

瑞士金融監管機構透過其穩定幣風險指引提供了相關背景。FINMA 強調與穩定幣安排相關的洗錢、恐怖主義融資、制裁及聲譽風險。

該指引亦討論銀行為穩定幣發行人提供違約保證時所產生的風險。不應把它解讀為對此 GCUL 試點的結論。

其相關性較為狹窄：金融風險取決於圍繞某項工具的結構及責任。一個令人安心的標籤，不能取代對誰向誰負有何種責任的分析。

同樣的嚴謹態度亦適用於「銀行貨幣」一詞。買家需要清楚了解法律申索權、適用條款，以及參與者違約時的後果。

共享交易紀錄可以改善協調，卻不能解決與這些申索權相關的所有法律問題。紀錄與可執行的責任必須一致。

國際結算銀行提供了另一個有用視角。在 2026 年 8 月一場關於代幣化存款挑戰的演講中，總經理 Pablo Hernández de Cos 指出，互操作性、管治、法律清晰度、韌性及遷移仍是業界尚未解決的工作。

互操作性是指系統可跨越彼此邊界交換及使用價值或資訊。機構之間的連接只是朝此目標邁進一步，並非普遍相容性的證明。

該演講支持對代幣化存款進行實驗，同時警告孤立網絡及流動性被困的風險。這為純粹以宣傳角度解讀瑞士項目提供了有用的制衡。

它亦將焦點引向故障處理。付款系統需要就錯誤指示、參與者不可用、憑證遭入侵及紀錄爭議作出回應。

這些是評估情境，並非試點已報告的故障。它們的重要性源於正式服務將承擔的責任。

例如，將存取權限限制於獲批准機構可降低某些進入風險。但這並未說明，如某家獲批准機構其後違反其責任，營運商應如何行動。

同樣地，篩查付款可支援金融犯罪管控。但這並不能說明可疑交易會多快獲得審查，或客戶如何獲得處理結果。

已公布的自動化亦需要審慎看待。Crypto Finance 描述了自動化的本地轉賬，而 Google 其後承認仍有人工後端工作。

這些描述可能指涉不同組件或階段。它們不足以支持「每項營運流程均已自動化」的說法。

潛在參與者應詢問哪些步驟需要人工處理，以及這些步驟在正常辦公時間以外如何運作。亦應詢問人工介入屬常規、例外還是暫時性安排。

這項區別影響全天候可用服務的可信度。客戶指示可以持續到達，而未解決的例外情況卻可能等待人員處理。

因此，最有用的合規證據應把規則與可觀察行為連結起來。買家應尋求有文件記錄的責任、審查程序、升級處理權限，以及顯示這些流程按預期運作的紀錄。

Google Cloud 代幣化存款應受到與其他影響客戶資金的基礎設施同等程度的審視。熟悉的機構及受控存取提供背景，而服務的實際責任決定所需的保證程度。

整合速度需要營運層面的比較

短暫的實施期回答的是交付問題；它並不能確立營運服務的完整成本或可靠性。

已公布的整合時間表為技術團隊提供了有用參考點。但它未有揭示其他銀行的系統、人手配置或審批流程，與試點參與者的情況有多相似。

擁有合適介面及既有數碼資產營運能力的銀行，面對的項目可能與正在替換較舊內部流程的機構截然不同。買家應避免把一次部署經驗轉化為普遍適用的時程表。

該架構亦引入了超越連接應用程式介面的責任；應用程式介面是軟件系統交換請求的既定方式。團隊必須確保交易紀錄與客戶賬戶及內部報告保持一致。

對賬，即核對不同紀錄的過程，當系統以不同方式呈現相關事件時尤其重要。一個組件可接受某項指示，而另一個組件可能仍在等待確認。

這並非共享分類賬獨有的批評。這是評估完整工作流程而非最容易整合步驟的理由。

有意義的營運比較應包括如何處理被拒絕的指示、重複提交、延遲回應及未完成更新。買家需要知道服務如何識別各種情況，以及如何恢復一致性。

同一原則亦適用於效能。一宗快速成功的交易，對買家了解中斷後的復原能力幫助不大。

有用的證據應區分一般完成時間與例外情況處理時間，亦應指出延誤出現在哪裏，以及哪個機構控制回應。

成本比較亦需要同樣審慎。較低的結算資金需求並不自動代表整體營運成本較低。

買家必須考慮整合維護、監察、支援、合規營運及例外情況的處理。現有公告未有提供足夠資訊來計算這種完整比較。

新分類賬亦不應因其他付款升級同樣可帶來的改善而獲得評價。合適的基準應是目標工作流程中最切實可行的替代方案。

瑞士國家銀行的Helvetia 項目提供了一個相關的參照。在其 2025 年 6 月公告中，瑞士國家銀行描述了使用數碼央行貨幣及連接既有基礎設施，測試代幣化資產結算。

央行貨幣是對中央銀行的申索權，與商業銀行所欠的存款不同。比較結算安排時，這個差異十分重要。

Helvetia 涵蓋的範圍與瑞士商業銀行轉賬試點不同。它的相關性在於可供選擇的架構方案，而非證明任何一個項目可以取代另一個。

對買家而言，比較應從所轉移的資產及責任開始。圍繞商業銀行存款設計的系統，不能只透過央行貨幣實驗的特性來評估。

該項目亦值得企業軟件開發人員關注。付款基礎設施塑造了應用程式可觀察到的交易狀態，以及可安全自動化的行動。

然而，可編程付款軌道並不能確立一套完整的自主採購系統。授權、支出限額、爭議及問責仍是獨立要求。

因此，Google 對未來由 AI 驅動付款的討論應被視為一個可能方向。已報告的本地試點並不能證明自主付款代理正透過此安排運作。

短期內與企業更相關的層面則更具體。團隊可以檢視共享紀錄及協調規則，是否可減少特定銀行工作流程的阻力。

這項檢視應產生一份可辯護、與現有方案比較的分析。它應識別效益、額外依賴項，以及在更廣泛採用前仍需取得的證據。

留意網絡擴展、結算證據及完整自動化

下一輪有用更新應顯示更廣泛的參與、可量度的結算行為，以及更少尚未解決的營運步驟。

第一個訊號是在共同營運框架下，有更多獨立銀行參與。僅公布有興趣的證據，會比完成上線及已報告客戶活動所提供的證據薄弱。

新參與者將測試該架構能否延伸至原有關係以外，亦會揭示每家機構必須重複進行多少技術及合約工作。

擴展將加強其作為可重用網絡的論點。若持續依賴度身訂造的安排，則表示協調仍是重大障礙。

擴展的質素與其是否存在同樣重要。當參與者服務於客戶實際需要付款的對手方時，網絡才會變得更有用。

加入客戶資金流幾乎相同的機構，實際覆蓋範圍可能不及加入一間連接服務不足付款路徑的銀行。買家應從交易需要評估實用性。

第二個訊號是在正常及壓力情況下，有關結算及風險敞口的已公布證據。一項可信更新應說明責任如何累積，以及系統如何處理限額或未完成結算。

有關資金效率的證據將加強該項目的經濟論據。證據亦應清楚說明得出該結果所依據的假設及付款模式。

相反，如客戶付款經常受到限制，便會令速度主張變得複雜。若參與者必須暫停活動以管理風險敞口，可用性便取決於這些控制措施。

這並不會自動令該安排不合適。它表示客戶及企業應用程式需要對資金何時能夠轉移抱持準確預期。

第三個訊號是有關完整營運自動化的更清晰證據。未來披露應區分已自動化的客戶轉賬，與仍然存在的結算、對賬及例外情況處理工作。

減少例行人工作業，將有助於更有力地證明其可重複性。公開復原程序亦會令潛在機構更容易評估這套營運模式。

如仍依賴人手處理，買方應檢視其對服務可用性的影響。關鍵問題是，當交易在正常辦公時間以外到達時，員工介入會否改變使用體驗。

這些訊號均不需要對下一季度作出進取預測。未來數月，應按公告是否能減少某項具體不確定性來判斷其價值。

例如，跨幣種示範需要提供的不只是支援另一種貨幣標籤的證據，還必須說明相關責任，以及如何處理未完成的交易。

同樣地，如額外使用案例披露了營運界限，其重要性會更高。擴展至更多工作流程，既可能增加複雜性，也可能提升實用性。

Google Cloud 瑞士法郎試點為由銀行主導的支付現代化提供了一個具體例子。其重要性在於，能否在既定框架內協調機構、客戶可用性及結算責任。

請按貴機構實際需要完成的支付來評估下一項公告。識別收款銀行、所需的可用性、結算條件，以及指令失敗時負責處理的團隊。然後詢問每項要求有何已公開的證據支持。應將公司聲稱與量度結果分開，並區分正在運行的試點活動與已普遍提供的服務。對於 Google Cloud 瑞士法郎試點而言，最具參考價值的進展，將是把更廣泛的參與與有文件記錄的財務及營運表現連繫起來。在把整合速度視為網絡準備就緒的證據前，應先留意這些披露。還有哪項不確定性，會阻止貴機構使用這項服務完成一筆真實支付？