【C3_03案例編號】BB_111-A402 補償信用狀：授權鏈、付款鏈與指示錯誤風險

【案例情境】
台灣出口商接到一筆需由指定銀行議付的信用狀，結構中另安排補償銀行，表示只要指定銀行依授權提示請款，補償銀行就會代付資金。業務部看到「補償」兩個字，直覺認為付款多了一層保障；但在實際操作時，授權內容、索償方式、請款訊息格式與期限都很細，一旦指定銀行依錯誤指示請款，或補償授權和原信用狀內容不完全對應，資金流就可能卡在銀行之間。

【核心爭議】

補償銀行是否等於最終付款保證人？簡易解答：不當然，它通常依補償授權處理資金補償。

補償信用狀最大的風險在哪裡？簡易解答：在授權鏈與付款鏈不一致，或請款指示錯誤。

受益人是否能直接依補償安排向補償銀行主張？簡易解答：通常要看補償機制設計，並非一律可直接請求。

【判斷關鍵】

補償信用狀要分清開狀銀行、指定銀行、補償銀行與受益人的角色。

補償安排處理的是銀行間資金流，不是自動增加一個對受益人的獨立付款人。

指示格式、提示時效與授權內容若不精準，風險會集中在操作細節。

企業看到補償結構時，不應只看「多一層銀行」，而要看責任鏈是否真的閉合。

【教學提醒】

學生最常把補償信用狀理解成多一層保證。

學生常忽略銀行間授權文字與請款格式的重要性。

架構愈細緻，愈不能用一般信用狀直覺處理。

【延伸思考】

若指定銀行未依補償授權格式請款，後果會怎樣？簡易解答：可能導致補償銀行拒絕補償，資金流卡住。

若開狀銀行與補償銀行授權內容不一致，誰風險最大？簡易解答：往往是第一線依賴該補償安排辦理議付的銀行與受益人。

【一句話結論】
補償信用狀不是單純多一層保障，而是多一條授權鏈；鏈條一旦沒扣緊，資金就可能卡在銀行之間。

7.【主題總結】
這個主題真正要教學生的，不是信用狀能不能開，而是信用狀要怎麼架，才不會把風險藏進設計裡。
從可轉讓、背對背、換單到補償，真正要看的都是權利、資金與文件三條線是否一致。
企業最常犯的錯，是以為工具名稱相近、功能就差不多；其實工具愈多，責任鏈愈容易斷。
所以判斷邏輯一定是：先看交易目的，再看誰收款、誰控貨、誰承擔追索，最後才決定架構。