具有不可變收益的全球定價庫的架構
我所說的全球定價圖書館是指圖書館
- 處理股權、利率等、混合產品
- 有多種型號（BS、LV、SV、LSV）
- 具有多種數值方法（解析公式、MC、PDE FD/FE）
我從來不需要設計一個全域定價庫，只需要在純粹的前台環境中編寫獨立的 MC 或 PDE FD 定價庫，主要有 BS、LV 和 SV，所以我可以自由地進行建模和設計。在這些情況下，我總是使用以下架構（在玩具 MC 的情況下）：
- a
Product有一個（參考）aPayOff- a
PayOff有一個Model和一個ComputePayOff計算模型生成的路徑上的收益的方法- a
Model有一個RandomNumberGenerator和一個GenerateMCPath方法，使用給定的隨機生成器在給定日期生成 MC 路徑
PayOff是抽象的，以及ModelandRandomNumberGenerator，即使我總是遇到避免由於橫向功能而導致子類呈指數增長的問題，因為我不是設計模式（橋？）專家。所以這
PayOff有很多“非不變”的資訊。例如，如果 myRandomNumberGenerator是 Sobol，它可能有一個成員在生成隨機數後發生變化，因此在定價後，PayOff 有一個資訊發生了變化。我從來不在乎這個。現在，我的任務是為全球定價庫設計一個 poc，約束條件是
Product並且PayOff不能更改（它們將被（反）序列化）。我當然可以，通過很多扭曲，繼續像前面的玩具範例那樣做，但這是錯誤的。儘管如此，經過思考，有些事情並沒有改變：我確實希望擁有三類“對象”：
- 產品（或簡單的回報）
- 楷模
- 數值方法
並且這些類別可能相交，例如：
- 歐洲收益、BS 模型和封閉公式（一種特殊的數值方法）的交集得出 BS 公式
- 歐洲收益和赫斯頓模型的交集作為數值方法產生為封閉公式、PDE FD2D 或 MC
等等。事實上，圖書館需要在給定的模型下處理給定的收益，使用給定的數值方法，跟踪它不能在任何模型和任何數值方法中為所有東西定價的事實……
有沒有經典的設計方法？由於我並不打算重新發明輪子，所以到目前為止我查看了 QuantLib 和 Strata，但它們都有“非不變的”“收益”。
這是幾乎沒有人問的最好的問題。我和你一起在 Quantlib 和 Strata 上，還沒有真正看到一個非常好的設計，但我已經看到了很多糟糕的設計。它絕對是可行的，並且在測試、維護、可擴展性方面具有很大的優勢。黃金法則是您的對象必須與概念相對應。
The core problem (in bad designs) is that the Payoff has a Model or pricing engine etc. Conceptually the payoff is simply a translation of the calculation part of a termsheet. Anything you add on top of that will be simply too much and will not be a clean design. The functionality of Payoff is resumed to calculating cashflow amounts given prices of underlyings. You can have get functions for dates, types of events (barriers), key levels (strike) etc. of course.
A Pricing Engine knows about Payoffs, not the other way around. On top of Payoffs you needs one or more Markets and some model parameters. Internally the Pricing engine creates a Model from Market objects (to get drift, vol etc) and model parameters. The pricing engine can be Analytic or Numeric. Analytic is straightforward. A numeric pricing engine needs to produce the date schedule for calculation based on what set of Payoffs it has to price. It also needs to collect a representation of all the calculations needed. IF you want efficiency then you want to decompose each payoff into smaller components describing the basic calculations like averages, digitals etc. You can have PDE(FD) or MC based engines.
An FD-based pricing engine will combine Model and NumericMethod(FD) to solve a PDE with boundary conditions. The PricingPDE class models the usual Backward pricing PDE plus a postStep() method to perform Payoff calculations. The FD engine itself doesn’t know about pricing. It is simply solving a PDE with boundary conditions. All reference to “pricing” is in the PricingPDE class. Same FD engine can be used for calibration or, why not, solving the basic heat equation.
Same goes for a MonteCarlo engine.
Payoffs can be broken down into actual cashflows driven by underlying variables (calculated from simulated assets/rates etc). On top of that there would be a list of features e.g. barriers, callability, early exercise and so on. The engine has to deal with all these characteristics of the payoff, and if it can’t, it means that payoff cannot be priced. Re models, if a model can simulate all the underlying variables and feature triggers, then it can be used to price that payoff. If it’s the right model in the sense that it covers or not all the factors that can impact the price, that’s to be decided upfront. E.g. pricing a cliquet with local vol would be possible but not the way to go when trading them.