e1 John Hull 風險管理與金融機構 v5

25.1 監管要求

2011年4月,美國聯邦儲備系統理事會發布了SR 11-7,為銀行提供了有效的模型風險管理指導。[1]事實證明,這份文件的影響力非常大,因此美國銀行將確保其行為與文件中概述的原則一致。其他地方的銀行監管機構表示,它們希望有類似的系統性方法來理解和管理模型風險。如果銀行監管機構認為銀行的模型風險管理系統不完善,則可能會要求銀行持有更多的資本金。

SR 11-7將模型風險定義為“基於不正確或誤用的模型輸出和報告的決策可能產生的不良後果”。產生模型風險主要有以下兩個原因。

(1)從其目標的角度來看,該模型可能存在根本性錯誤。這些錯誤可能與它使用的數據、計算方式、數值過程、假設等有關。

(2)模型可能被不正確或不恰當地使用。瞭解模型的侷限性是很重要的。一個模型可能是基於一組特定的市場條件或一種特定類型的客戶行為而開發的。當條件改變時,模型可能不再適用。

金融機構應確定模型風險的來源及其嚴重程度。與簡單模型相比,複雜模型通常會導致更大的模型風險。當模型是相互聯繫的,或者多個模型基於相同的基本假設集時,模型風險的程度就會更大。監控模型性能很重要,以便儘早確定模型是由於何種原因而沒有實現預期的效果。

25.1.1 模型創建

在開發模型時要做好存檔工作,這麼做有幾個原因。如果模型開發人員離開了開發小組,並且沒有做好存檔,其他人可能很難承擔繼續完成模型的責任,開發人員可能會因此丟失工作。其次,監管機構在評估金融機構使用的程序時,經常會要求查看模型文檔。此外,如果模型有良好的文檔記錄,那麼模型驗證和定期評審也會變得更加方便。

模型文檔的一個重要方面是闡述模型的目的、基礎理論、行業實踐的評估和已發表的研究的回顧。重要的是,文檔中必須清楚地解釋基本的數學、使用的數值計算過程和做出的假設等。文件應該足夠詳細,以便新手能夠理解已經完成的工作。如前所述,整理模型文檔對於模型開發人員來說常常被視為無聊的工作。但是在實踐中,這一個有用的規程,迫使模型開發人員後退一步,以前所未有的方式來思考他們的工作。有時還會改變模型的結果。

模型應該儘可能徹底地進行測試。這應該包括仔細測試計算機代碼的所有部分,並評估模型在輸入一系列數據時的表現。測試應該確定模型運行良好和運行不良時的情況。這可以通過逐漸輸入極值並觀察模型的性能來實現。在某些情況下,將所提出的模型的輸出結果與更精細的模型的輸出結果進行比較是合適的,因為後者的計算速度太慢,無法在實踐中使用。

測試模型性能的方法取決於模型的性質。根據歷史數據開發的模型應該在樣本外進行測試。例如,如果制定貸款決策的模型是從特定時期收集的特定數據集開發的,那麼顯然不適合再使用這些數據對其進行測試。同樣,如果消費者的投資組合管理策略是通過分析某個特定時期的資產價格行為而開發的,那麼應該使用另一個時期的數據對其進行測試。

我們在前面的章節中已經討論瞭如何回測VaR模型,它也可以用於其他情況。假設一個基於特定假設集的模型被用來為障礙期權定價。這可能可以確定它在過去的運行情況,但使用該模型的用戶會平均獲利嗎?如果能獲利,利潤是否足以補償所承擔的風險?

在實踐中使用模型時,金融機構應收集信息,以確定其是否反映了經濟和商業現實,是否按照預期的方式運行。模型的存在可能會帶來行為改變的危險。例如,用於管理客戶關係的模型可能導致客戶行為的不同;潛在的洗錢者在瞭解(也許通過反覆試驗)這種模型是如何運作的並相應地調整自己的行為之前,用於檢測洗錢的模型可能會很有效。甚至使用模型的用戶也可能找到調整模型輸入或模型使用方式的方法,以使自己使用的模型結果看起來更好。

25.1.2 模型驗證

人們越來越關注模型風險管理,由此組成了模型驗證小組,這些小組負責驗證組織使用的所有模型是否按預期執行。他們檢查模型開發人員的工作,並嚴格審查了所生成的模型以及模型是如何執行的。

負責驗證模型的人員應該獨立於模型開發者和模型用戶。確保驗證的獨立性對於模型風險管理功能的成功至關重要。應選擇採用報告的方式和激勵措施來促進獨立性。模型驗證功能的成功與否,應該通過模型評審的客觀性、提出的問題以及管理層為解決問題而採取的行動來評判。企業文化很重要。如果不鼓勵客觀思考和決策的挑戰性,那麼模型驗證過程很可能是無效的。監管機構可能會要求查看模型,以及經過模型驗證並適當修改後的模型的應用實例。

在進行初始驗證之前,模型有時會在小範圍內被非正式地使用。然而,在金融機構正式運行模型之前,進行第一次驗證非常重要。驗證的範圍和嚴格程度應取決於模型提出的風險。考慮已經開發出一個使數十億美元的貸款決策自動化的模型的情況。此時,模型的驗證非常必要。即使模型運行良好且符合其目標,模型驗證小組也應該分階段實施對模型的密切監控,以減少模型風險。

在模型被批准使用後,模型驗證也應該持續進行,以監控市場和商業慣例的變化對模型性能的影響。SR 11-7建議驗證組至少每年審查一次模型。模型的用戶(特別是與開發人員不同的用戶)可以輸入參數,驗證組可以使用最近的數據來檢驗模型的性能是否與首次使用可用數據驗證的模型性能一樣好。模型的應用結果(如信用決策的制定、使用該模型的投資回報、防止的欺詐企圖)都應該記錄在案,並將其與預期結果進行比較。

業界事例25-1描述了倫敦鯨事件,這是模型驗證組在壓力下批准模型的一個例子。這是因為,當一種產品的巨大頭寸與一種類似產品的相反頭寸對衝時,該模型為降低在險價值,進而降低監管資本金提供了理由。如果模型驗證組有更多的時間,他們就會對模型進行更仔細的檢查。可能有人會認為這兩種產品的相關性過大,還可能會有人指出,對小頭寸有效的對衝策略,並不總是對大頭寸有效。銀行對規模大的頭寸使用該模型,有可能導致掠奪性交易,從而降低對交易產品價格的歷史比較的相關性。

業界事例25-1

倫敦鯨事件

這裡所說的“倫敦鯨”是指摩根大通(JP Morgan Chase,JPM)首席投資辦公室(Chief Investment Office,CIO)的一名交易員布魯諾·伊克希爾(Bruno Iksil)。伊克希爾因為在CDX和iTraxx指數上的信用違約互換的巨大頭寸而得到了這個綽號(如第19.4節解釋的,這些信用違約互換產品提供了對一組公司的違約事件的保護)。

CIO的職責是將銀行的富餘現金進行投資。截至2011年年末,CIO在信用指數上的頭寸雖然比較大,但還算合理,而且是淨多頭(也就是說CIO買進的違約保護多於賣出的違約保護)。這一淨多頭為CIO在固定收益產品上的頭寸提供了對衝。JPM希望降低其風險加權資產,以滿足新的《巴塞爾協議》的監管要求,同時在經濟狀況改善的展望下,也希望將自己在信用指數上的頭寸變得更加中性。但是如果將手中的信用指數產品平倉,就會導致損失。這主要是因為這些產品的盯市計價結果是負的,另外還因為JPM在這些產品上的頭寸太大,如果平倉,市場就會朝不利於自己的方向移動。出於這些考慮,CIO採取的對策是賣空與手中持有的指數不同的信用指數來進行對衝。

CIO的如意算盤是自己持有的多頭和空頭能夠彼此抵消。但實際上,這種情況沒有發生。其他市場參與者意識到,有人持有巨大的頭寸(像其他機構一樣,JPM當然竭力為自己的頭寸保密。但是其他市場參與者意識到市場上潛伏著一條“鯨魚”,隨著事態逐漸明朗,大家發現這條鯨魚正是來自JPM的交易員)。意識到這些頭寸將來必將被平倉,並且將引發市場較大的調整,部分市場參與者實施了掠奪性交易策略,即建立與JPM相反的頭寸。其結果是,市場朝不利於JPM的方向發展,JPM預想的多頭和空頭價格會緊密相關的情況沒有出現。

CIO進一步加大了頭寸。這樣做一方面是出於技術對衝的原因,另一方面也是為保護自己避免成為掠奪性交易的受害者。理論上,CIO的巨大頭寸平衡得很好(也就是說,模型顯示頭寸價值不會因信用價差變動而受到任何較大的影響)。CIO持有CDX投資級(investment grade,IG)和CDX高收益(high yield,HY,即非投資級)指數的多頭與空頭。舉例來說,CIO賣出了大量10年期CDX IG9指數,買入了大量5年期CDX IG9指數(這是2007年9月生成的包含125個參照實體的信用指數。儘管不是現在市場上最新的CDX IG指數,但其交易還算活躍。125個參照實體中的121個尚未違約)。不幸的是,指數價格的走向沒有按照CIO所預期的那樣發生。2012年4月和5月,JPM承認蒙受了60億美元的損失。CIO僱員的延遲分紅被收回,JPM主席兼CEO吉米·戴蒙(Jamie Dimon)當年也被減薪。美國政府部門還對CIO交易組合價值誤報的指控進行了調查,其結果是JPM又被罰款10億美元。

為什麼CIO會被允許持有這麼大的風險?2012年1月,CIO超出了自己的VaR限額,而且因為CIO的巨大交易頭寸,整個銀行的VaR限額也被超出,但是一個新的VaR模型被開發出來。這個模型是在2012年1月的下半月完成的,並被模型檢驗部門匆匆批准。該模型將CIO的VaR降低了50%。因此,在1月前報告的VaR值又回到了限額以內。2013年1月,JPM關於倫敦鯨事件的內部報告顯示,在這一過程中存在多處錯誤。開發模型的量化人員以及模型檢驗部門都面臨很大的壓力,必須完成模型的開發和審批。CIO交易員手下的量化人員以及模型檢驗部門僅對模型進行了非常有限的回望測試。2012年5月,這個模型又被重新檢驗,發現其中存在多個嚴重錯誤,並就此停止使用。

這個事件強調了模型驗證功能的重要性,以及模型驗證為什麼需要獨立進行。

SR 11-7認為全面的驗證應該包括三個核心要素:

(1)對概念合理性的評估,包括文檔記錄;

(2)持續監控,包括過程驗證和基準測試;

(3)結果分析,包括回溯測試。

一個良好的模型開發過程應該產生有據可查的記錄文檔來支持所有的模型假設。有一種危險是,模型開發人員偏向於特定類型的模型,或者甚至會通過開發一個不必要的複雜模型來展示其量化技能。驗證工作應該確保這種情況不會發生。穩定性是模型的一個重要屬性。如果輸入參數時的一個微小變化會導致輸出的較大變化,那麼該模型可能不穩定且不適用於其預定用途。模型驗證應包括模型應力測試,即對模型輸入極端參數以測試其適用性範圍。

如前所述,持續監測是模型驗證的核心部分。這包括確保對模型所做的所有更改都經過了驗證並存檔記錄。如果模型用戶和模型開發人員是同一個人(有時是這樣的情況),那麼模型用戶就有可能調整代碼以提高模型性能。這不能令人滿意,並可能導致模型只不過是一組沒有統一理論的調整而已。如果一個模型沒有達到它所能達到的效果,就應該對其進行審查,並開發出一個基礎更好的新模型。對於模型驗證功能來說,重要的是調查不使用模型的情況,因為經理認為輸出與他們的經驗和判斷不一致。這可能表明改進模型或使用新方法是必要的。

結果分析(如回測)對於監控模型的性能非常重要。其中的一些工作應該由模型開發人員進行,並形成記錄文檔。這項工作應該由模型驗證小組持續進行檢查,並分析預期結果與實際結果之間存在差異的原因。例如,一個特定的流動性管理模型可能在低利率環境下運行良好,但在利率上升時表現不佳,經過這種類型的分析可以改進模型。

25.1.3 供應商模型

並非所有的模型都是內部開發的,有些模型是從供應商那裡購買的。有時,購買模型的目的是對內部開發的類似模型進行基準測試。此時,供應商模型可能是一個有用的驗證工具。在實踐中,金融機構也可以使用供應商模型,因為它比內部開發類似模型便宜。在這種情況下,供應商模型應該與內部模型受到相同的驗證。然而,這對模型驗證組提出了特殊的挑戰,因為建模專家是組織的外部人員,模型的某些方面可能是專有的。

金融機構應該有選擇供應商模型的流程,應要求供應商提供說明模型設計、測試結果和模型侷限的文檔。金融機構應堅持要求供應商進行持續的績效監控和結果分析,並將結果提供給客戶。

驗證組應負責批准金融機構使用供應商模型。他們可能無法訪問計算機代碼,但仍可以針對模型對各種輸入參數產生的結果進行廣泛的分析。驗證小組應該要求供應商提供關於用於開發模型的數據的完整信息。對於供應商停業或決定停止提供模型的情況,應該有一個應急計劃。這裡的一個辦法是將計算機代碼和所有其他專有資料置於託管狀態,並在供應商不再能夠提供支持的情況下提供給客戶。

[1] 參見聯邦儲備系統理事會,貨幣監理署,“Supervisory Guidance on Model Risk Management”,SR 11-7,2011年4月。