跳到主要內容

次級房貸

剛剛才剛看到的,我一直以為次級房貸就是二胎房貸。原來並不是,看完的心得是原來很多銀行的投資根本就是亂來,很多政策一改就泡沫化了。以後絕對不要投資銀行精心設計的投資商品,除非完全瞭解他的獲利來源。

次級房貸的對象一般都是信用分數在620分以下,信用記錄不良的窮人,少數民族,甚至很多是非法移民,這些人正常情況根本拿不到貸款,房貸公司幫著這些人偽造收入証明,new century 05,06年放出去的貸款三分之一的貸款一個payment都沒有收,這就是所謂的次級貸款,不是什麼二胎貸款,房貸公司把這些貸款賣給投資銀行,然後投資銀行把高風險房貸變成結構化債券,再賣給投資人,所以對房貸公司而言,他把大部分風險都轉嫁到了投資銀行,所以放貸的時候完全是亂來,不過他們手上留下的equity tranche,所謂的毒物垃圾,最後還是把這些房貸公司搞跨了,另外一方面,市場上出現的巨額損失並不是因為大家都在拼命賣掉次級房貸,現在根本就賣不出去,是所謂的有價無市,大部分的trader基本都hold住了,出現損失是因為評級公司把結構化債券降級。以前這些債券是mark-to-model(依模式計算),現在突然大家都要求mark-to-market(按市價調整),同樣的東西,一個月前用電腦算出來,還是賺錢的,現在突然mark-to-market之後,就是巨虧一旦出現這種情況,好多margin call(保證金追繳),collateral(擔保品) request 就來了,信貸緊縮,原來可以用AAA的結構性債券做repo*抵押,來獲得短期貸款的,現在根本就不行了。這個時候銀行的資金流動出現危機,各國央行開始印錢解決流動性危機。

*附條件交易(Repo Trade). 附條件交易係指交易一方,先行出售有價證券,並承諾於一定期間後按雙方預先約定之價格予以買回。

留言

Link寫道…
from ptt HYL
次級房貸的問題要從1980年的房地產債券開始講起了。

有興趣的人可以去看看Lair's Poker[1] 這本寫實小說,在1980年
前,房貸多是跟地區銀行貸款,該銀行手上就抱了一堆當地的房貸
,對銀行來說,風險集中,房貸的利息高(~20%) ,Lewie Ranieri
這位老兄遊說政府成功,予許銀行將房貸出售。

利用數學模型(!!),把幾個地區的房貸組合起來 (CMO),計算出系
統風險之後,包裝出售。對銀行來說,降低了手上房貸的持有成本
,對顧客來說,降低了房貸的利息,對投銀來說,賺到了手續費,
算是個三贏的狀況。

就這樣,在五年之內,一個三十兆美金的市場就創造出來了,直到
最近才發現問題。(容後再序)

在兩千年的股災後,整體市場的利息都下跌,對一般人來說,相同
的每月應繳金額,可以負擔更貴的房子,也因此整題的房市價格,
在五年能將近漲了一倍。

============================================================

2003年,interest only loan這隻怪物被創造了出來,前五年不用
還本金,只要交利息就好;04年 WSJ就已有專欄指出IO的問題。許
多人跟本就不打算持有超過五年,持有個一兩年等房價上揚就準備
出售謀利。

另一種有問題的房貸是 ARM,前五年的利息故定(3%),五年後隨市
場利率來變動,目前的房貸利息是(6.3%),算起來每月要多負擔 45% !!

某些金融從業人員,可能會告訴你這是短期信心問題,不會影響整
體市場,這是個大騙局。

interest only loan,2003年貸的要到2008年才會爆,現在繳不出
來房貸的是再之前貸 ARM的人。

=============================================================

照理說,美國的房貸市場爆了,為什麼全球會受害呢?

第一原因就是第一二段寫的 CMO,美國的房貸債券不是只賣給美國
本地的銀行,在全球化的狀況下,各國銀行都想降低自己的風險,
所以持有不同國家、組織發行的債券;沒想到時至今日,反而是沒
有人能算出來實際的風險了。

第二個原因,在房貸上揚的狀況下,在沒破產前( 而且美國宣告破
產,房貸是不能劃消的 ),只有減少其他方面的支出,能不買東西
就僅量不買,造成整體消費市場的減弱。美國這全球最大消費國減
少消費,其他的出口國自然是不會好受的。

=============================================================

後話

在2003年就跟 WSJ有同樣的人自然不在少數,投銀及投機客自然也
都清處,不過大家都想在市場崩潰前多賺一點,也不相信自己是最
後一個下車的人,就這樣,另一個泡沫就隨 Greenspan的低率政策
越吹越大。

目前大眾是ㄔㄨㄚ\ 著等,華爾街的人是想把自己跟買房子的人綁
在一起,跟央行哭窮哭可憐[2] ,壓迫央行降息。

剩下還有少部份的人如我,等著減便宜,等越來越多的人破產把房
子抵給銀行,房價至少該下跌 40%,到時就是進場的時機了。

--
1: http://www.amazon.com/Liars-Poker-Rising-Through-Wreckage/dp/0140143459
2: http://youtube.com/watch?v=cYPtCmdFCrc

這個網誌中的熱門文章

解決 CI Trust Issue:Target Must Be Enabled Before It Can Be Used

📱 iOS開發 | 🔧 CI/CD | 💻 Xcode | 🐛 除錯筆記 🔴 問題描述 這兩天在跑 CI 時突然出現錯誤訊息: Package@swift-6.0.swift:PACKAGE-TARGET:CasePathsMacros: error: Target 'CasePathsMacros' must be enabled before it can be used 🤔 嘗試過的解法 💬 Claude 的建議 首先詢問了 Claude,得到以下步驟: 先更新 swift-case-paths 到最新版本 確保使用 "Up to Next Major Version" 執行 File → Packages → Reset Package Caches Clean Build Folder (Cmd + Shift + K) 重新 Build 結果: 一看就知道沒用 😅 🤖 ChatGPT 的建議 接著試了 ChatGPT 的解法,主要是降低引用到的 package 版本。繞了一圈,還是沒用。 ✅ 最終解決方案 最後還是回到 Google,找到了真正有效的解法。針對這個 macro fingerprint validation 問題,有三種解決方式: 📌 方法一:本機開發用(Terminal 指令) defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES 📌 方法二:xcodebuild 參數 在執行 xcodebuild 指令時,加上 -skipMacroValidation 參數 📚 參考連結: https://vocus.cc/article/690779ebfd89780001859b14 📌 方法三:CI 正統做法 ⭐️(推薦) 步驟 1: 在專案根目錄建立資料夾 ci_scripts 步驟 2: 在此資料夾中建立腳本 ci_post_clone.sh ,內容如下: #!/bin/zsh mkdir -p ~/Library/org.swift.swiftpm/security/ cp macros.js...

用 AI Debug 的迷思:當建議越改越糟時

現在許多開發者習慣用 AI 來協助 debug,但在實務上常遇到一種情況: 依照 AI 建議改了兩三輪後,錯誤仍然存在,甚至越改越複雜。 這種狀況其實有幾個常見的盲點,值得特別注意。 1. 先回到「上一個正常版本」 當你已經按照 AI 的方向修了好幾次但問題仍未解決時,最有效的第一步是: 回到上一個正常工作的版本,縮小問題來源。 許多 bug 並不是你正在看的那段程式碼造成的,而可能是: 同事剛好修改了某個底層模組 某個 shared component 產生 side effect Auto Layout 層級重新 layout 時觸發 crash 如果只是盯著眼前的 function 修,反而容易被誤導。 2. AI 沒有看到你的整個專案 AI 通常只能根據你貼出的片段判斷問題,這代表它不知道: 你的 view hierarchy 裡是否有其他 constraint 影響 layout 某些 model 是否被 extension 修改過 父層或子層邏輯是否干擾目前的行為 整個專案採用的 concurrency 模型是什麼 因此,AI 可能會朝著完全錯誤的方向修,導致反覆修改卻無法解決。 3. Swift 6 例子:錯誤真正原因常不在你修改的那一行 例如開發者常遇到的錯誤: passing closure as a 'sending' parameter risks causing data races 許多人(包含 AI)會開始從 function 內部調整,但這類錯誤真正的關鍵通常是: 傳進去的物件沒有實作 Sendable。 也就是說,你不是要改 function,而是要回頭檢查: 傳入的 model / struct / class 裡面是否有 non-Sendable 成員 是否需要標註 @unchecked Sendable 如果 AI 沒看到相關檔案,自然很難找到正確方向。 結語:AI 是工具,不是預言機 AI 很適合用來: 解釋概念 協助產生測試程式 提供重構建議 釐清你已懷疑的方向 但在 debug 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...

借助 AI 除錯:解決登出時的解密錯誤

  前言 最近遇到一個有趣的 bug,趁這次機會試試看用 AI 來協助除錯。整個過程蠻有收穫的,分享給大家參考。 問題發現 Bug 描述 在測試登出功能時,發現 app 會發生 crash。追蹤後發現是在登出時,API 會呼叫底層的解密函式,但解密用的 key 明顯有問題,導致解密失敗而引發錯誤。 由於這段流程是另一位同事負責開發的,程式碼邏輯比較複雜,短時間內看不出根本原因。於是先採取防禦性做法: 如果 key 為空值,就將解密失敗的錯誤吃掉不處理 。判斷後認為這樣不會影響 UI 操作,因為登出後 key 會重新取得。測試後確認沒問題,就先把這個 bug 暫時壓下來了。 深入追查 第一回合:初步分析 趁著有空檔,決定詳細釐清這個問題。想試試 AI 的能耐,於是下了第一個 prompt: 分析 SessionManager 的 processEncryptedData 方法中,為何會發生 bytesToTrim > currentLength 的錯誤?從呼叫該方法的地方分析可能發生的原因。 AI 給出了幾個可能的原因: 加密數據損壞或截斷 網路傳輸過程中數據包丟失或損壞 API 回應中的加密字串不完整 解密後的最後一個字節值異常大 錯誤的加密算法或密鑰 使用了錯誤的解密密鑰或 IV Session key 交換失敗,但程式繼續使用無效密鑰解密 解密產生亂碼 Hex 字串轉換錯誤 包含非法字符、長度不是偶數、部分缺失等問題 AES CBC 解密失敗但沒有檢查錯誤 Whitebox 密鑰準備失敗 IV 不匹配 數據長度不符合 AES 塊大小要求 PKCS7 Padding 格式錯誤 加密時使用了錯誤的 padding 方式 最後字節不是有效的 padding 長度值 (1-16) 多重解密處理錯誤 數據被重複解密或解密順序錯誤 記憶體緩衝區問題 緩衝區大小分配錯誤或溢出 AI 也分析了呼叫鏈: API 回應 → DataTransformer → CryptoHandler → decryptSessionKey → processEncryptedData 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...