若決定不執行該營業日的相關交易，可能需要沖正、對帳、再以調整後的營業日重新處理。但不是每筆交易都要沖正——若交易本身合法，只是營業日因颱風延後，保留原交易、依銀行核准的 Value Date、Posting Date 或清算日調整程序處理即可。前述中國信託對證券交割款的回沖交易，就是這類補償機制的實際案例（中國信託）。
值得注意的是，成熟的核心系統本來就假設「分行不開門」是常態。FLEXCUBE 對分行不可用（Branch Not Available）的狀態有原生支援：交易以 Tanked 狀態暫存、帳務先記錄，待分行恢復可用後由 BOD 批次釋放（Un-tanked）（Oracle FLEXCUBE Universal Banking）。換言之，颱風停班不必然觸發回復——若系統與營業日曆設計得當，「暫存、順延、次一營業日釋放」原本就是選項之一。
四、Rollback Matrix：資訊與營運單位的考量
作業階段
停班決策
技術處理
EOD 尚未開始
停止當日 EOD
保留原營業日，暫停後續批次
EOD 執行中
評估是否中止
依 Job 狀態執行 Restart／Resume
EOD 已完成
延後 BOD
保留前一營業日的完成狀態
BOD 尚未開始
不啟動新營業日
暫停 Business Date Roll
BOD 執行中
停止後續批次
檢查已完成批次、帳務及介面狀態
BOD 部分完成
依批次設計處理
Restart／Resume 或正式沖正
BOD 已完成
評估是否維持新營業日
進行帳務、清算、通路及交易對帳
新營業日交易已發生
不直接回復整個系統
依核准程序執行交易沖正或營業日調整
重要前提：颱風停班不代表 Business Date 必須維持不變。銀行可能有不同的營運安排：
分行停止營業，但電子金融服務維持運作（金管會鼓勵的方向）
部分清算服務仍依既定時程運作（ATM 跨行、央行國際金融）
營業日延後，但電子通路仍接受交易
維持原定營業日，只是分行不對外營業
這些情境直接決定哪些 BOD／SOD 作業應停止、哪些照常、哪些交易延後處理。
五、風險考驗
重複入帳（Duplicate Posting）。若 BOD 已完成部分定存到期或自動轉帳，重新執行時必須避免再次產生相同交易。Restart 點的設計品質，決定了颱風夜是加班兩小時還是通宵對帳。
營業日與價值日不一致（Business Date／Value Date Mismatch）。若系統已切換營業日，但銀行決定延後營業日，必須逐一確認 Business Date、Posting Date、Value Date、Transaction Date、Clearing Date 是否符合銀行核准的處理規則。不能把系統日期往回改，就以為問題解決了。
交換票存入時通常己計入帳戶餘額
交換票存入時通常己計入帳戶餘額（實際可用餘頟並未包括交換票金額），次營業日退票交換后帳戶餘額=實際可用餘額，如果次營業日臨時改變成非營業日，當天的取款金額仍然不可以>實際可用餘額十交換票金額，所有諸如此頰-營業日前就計入帳戶的預先交易，碰到臨時假日，都要考慮這個問題。
至於BOD,SOD代表的字義是什麼，恕在下才疏學淺，倒要請教。
由於接到站長來信，希望我幫忙回答，不得已只好硬著頭皮，勉強為之。
中心處理遇臨時假日宣布
站長告訴我他認為是begin of day/start of day,我想他是對的。中心處理的交易通常換日即入帳戶，換日后臨時宣布假日，己經資金化的交易應該取消，但是此時可能金額己被客戶領走導致取消交易無法完成，此時則應臨櫃交易中提醒櫃員注意（有些縣市未放假）。
颱風天的 BOD／SOD 作業與不能輕言回復的營業日
以台灣銀行業的資訊作業環境來看，BOD（Beginning of Day，日初作業）與 SOD（Start of Day，營業日啟動作業）是核心銀行系統（Core Banking System）每日批次與營業日切換的門檻。
政府宣布停班，但批次作業已經啟動，甚至部分已經完成，此時真正要回答的問題是：
此處以傳統核心銀行主機、批次處理、日終／日初流程為背景說明。各銀行的實際作業名稱及順序可能不同，BOD 與 SOD 也不一定是同一個流程。
一、BOD 與 SOD：日初到底在跑什麼
BOD 通常指核心系統進入新營業日的日初批次；SOD 則可能是 BOD 的同義詞，也可能是涵蓋更多系統、通路與營運準備工作的「營業日啟動流程」。不同核心系統的定義不一致，這一點值得先說清楚。
以 Oracle FLEXCUBE 為例，官方文件明確定義：BOD 開啟銀行的新交易日，且 BOD 依賴前一營業日的 EOD——前一日 EOD 未完成，系統不允許啟動 BOD（Oracle FLEXCUBE System Operations User Manual）。這道閘門，正是颱風情境下最常見的決策點。
1.1 核心系統的 BOD 作業
FLEXCUBE 的日初作業處理定存利息與到期、未領存款、常設指示（Standing Instruction）執行、支票價值日（Value Date）處理、薪資處理及透支額度到期等項目（Oracle FLEXCUBE System Operations User Manual）。擴充到一般核心銀行系統，常見作業如下：
以上是常見的作業類型，不代表每一項都放在 BOD。部分銀行在 EOD 執行利息計算、手續費計算及總帳（GL）更新，BOD 則負責到期處理、交易日期切換及新營業日啟動。FLEXCUBE 甚至允許透過 Automatic Process Definition 設定每個批次在 EOD、BOD 或兩者觸發（Oracle FLEXCUBE Universal Banking）——從架構角度來看，「BOD 做什麼」本身就是銀行設計出來的，而非系統天生的固定邊界。
1.2 SOD 涵蓋的周邊作業
若 SOD 指整個銀行資訊環境的營業日啟動流程，通常還包括：
SOD 不應視為單一 Job。它很可能是由多個系統的依賴關係串接而成的 Job Chain——核心系統 BOD 完成，不代表所有周邊系統都已完成營業日啟動。
二、停班日的真實邊界：系統其實是「半開半關」
談 Rollback 之前，得先知道停班日銀行的哪些環節還在動。這在台灣有明確的法規與實務脈絡。
依金管會「金融機構營業時間及遇天然災害發生時停止營業作業」規定，直轄市、縣市政府宣布全日停止上班時，當地金融機構全日停止對外營業；票據交換及退票紀錄作業依中央銀行規定辦理（金管會法規）。但「停止對外營業」不等於「系統停止運作」：
銀行實際怎麼做？以中國信託公開說明為例：自動扣款（含基金定期定額、房貸自動扣繳）照常執行入帳；但證券交割款扣款會作回沖交易，遞延至次一營業日扣款；跨行匯款對停班縣市暫停受理，若台北市停班，預約當日匯款順延至次一營業日執行（中國信託）。
同一個停班日，同一家銀行：自動扣款照跑、證券款回沖、匯款順延。這反映出真正的主題——停班日銀行系統是「半開半關」的，哪些作業該停、哪些照常，是營運決策逐項裁定的結果，不存在單一的技術開關。央行對退票的處理也印證同一套邏輯：存款不足退票只要在次一營業日完成重提付訖、贖回或提存備付註記，就不列入退票紀錄（經濟日報）——制度設計本身就是「順延至次一營業日、事後補救」，而非「回復原狀」。
三、Rollback 不是資料庫問題：先問狀態，再談回復
假設銀行原訂 11 月 9 日（星期一）為營業日，因颱風宣布停止上班，而系統在前一晚已完成 EOD，甚至啟動了 11 月 9 日的 BOD。此時會出現三種情況：
Rollback 的範圍應由營業日狀態、批次執行狀態及交易的外部影響決定，而不是單純依照政府是否宣布停班。
3.1 三種情境的處理原則
3.2 Rollback 不等於 Database Rollback
對銀行而言，交易一旦 Commit、產生正式帳務或送交外部系統，就已超出資料庫 Transaction 的可回復範圍：
客戶已收到簡訊通知 GL 已完成過帳
此時即使核心系統能把某個批次的資料回復，外部系統、客戶帳務及總帳也不會自動回復一致。對已完成的金融交易，通常要走正式的沖正（Reversal）或補償交易（Compensating Transaction），而不是直接刪除或回復資料庫紀錄；批次重新執行也必須避免重複產生帳務。
3.3 三種技術手段，對應三種狀態
Rollback：回復尚未完成的資料庫交易。適用於 Batch Job 尚未 Commit、可依 Transaction Log 回復的異動：
BOD_JOB_001
但若 BOD 採每個帳戶或每個批次區段分別 Commit，就不能假設整個 BOD 可一次回復。
Restart／Resume：從失敗的批次階段繼續。適用於已完成部分處理、有明確執行紀錄、具備 Restart Point 或 Checkpoint、且重跑不會重複入帳的設計：
BOD
此時應先確認 Job 03 的失敗原因及是否已產生部分帳務。若具備安全的 Restart 機制，可能只需從 Job 03 重跑，而不是把 Job 01、02 全部回復。FLEXCUBE 等核心系統就是依各批次的前後依賴關係及執行狀態管理 BOD／EOD（Oracle FLEXCUBE System Operations User Manual）。
Reverse／Compensating Transaction：沖正已完成的金融交易。適用於已 Commit、已送交外部系統、已產生客戶或清算影響的交易：
Original Transaction
若決定不執行該營業日的相關交易，可能需要沖正、對帳、再以調整後的營業日重新處理。但不是每筆交易都要沖正——若交易本身合法，只是營業日因颱風延後，保留原交易、依銀行核准的 Value Date、Posting Date 或清算日調整程序處理即可。前述中國信託對證券交割款的回沖交易，就是這類補償機制的實際案例（中國信託）。
值得注意的是，成熟的核心系統本來就假設「分行不開門」是常態。FLEXCUBE 對分行不可用（Branch Not Available）的狀態有原生支援：交易以 Tanked 狀態暫存、帳務先記錄，待分行恢復可用後由 BOD 批次釋放（Un-tanked）（Oracle FLEXCUBE Universal Banking）。換言之，颱風停班不必然觸發回復——若系統與營業日曆設計得當，「暫存、順延、次一營業日釋放」原本就是選項之一。
四、Rollback Matrix：資訊與營運單位的考量
重要前提：颱風停班不代表 Business Date 必須維持不變。銀行可能有不同的營運安排：
這些情境直接決定哪些 BOD／SOD 作業應停止、哪些照常、哪些交易延後處理。
五、風險考驗
重複入帳（Duplicate Posting）。若 BOD 已完成部分定存到期或自動轉帳，重新執行時必須避免再次產生相同交易。Restart 點的設計品質，決定了颱風夜是加班兩小時還是通宵對帳。
營業日與價值日不一致（Business Date／Value Date Mismatch）。若系統已切換營業日，但銀行決定延後營業日，必須逐一確認 Business Date、Posting Date、Value Date、Transaction Date、Clearing Date 是否符合銀行核准的處理規則。不能把系統日期往回改，就以為問題解決了。
核心系統與外部系統不一致（Cross-System Inconsistency）。核心已扣款但清算未完成、交易已送出但回應未收到——先確認交易實際狀態，再決定重送、沖正或等待，而不是盲目重跑。
因此：
所以, 決策者是否知道系統此刻站在哪一天。