タグ別アーカイブ: ウィルモット

私の列はウィルモットマガジンに掲載さ – 量的金融の専門家を対象とした、よく知られた出版物.

ここから先の?

私たちは、私の本のためのピッチでこの長いシリーズを開始しました, 定量的発展の原則. このシリーズ, および関連する電子ブック, 本の非技術的な入門の章の拡張バージョンです — 取引プラットフォームを設計しながら、私たちは心に留めておく必要があるものが何であるか? なぜそれが金融や銀行業務の全体像を知ることが重要である? うまくいけば, これらの投稿は、ここであなたにそれの味を与えている. あなたは便利な一連のコピーを保持たい場合, あなたが購入し、ダウンロードすることができます 美しく細工された電子ブック バージョン.

Further steps

私たちは、エキゾチックで構造化された取引の観点から、銀行の構造を通って行きました. 私たちは、さまざまなオフィスの話 (フロントオフィス, ミドルオフィスとバックオフィス) そして内の定量的な専門家のためのキャリアの機会を指摘した. 銀行の組織構造は、取引の動的なライフサイクルを処理する装置であり、.

銀行の構造は空間的な組織に似ている場合には, 貿易のライフサイクルは時間的変化である; 彼らの関係は、レールと列車のそれに似ている. 私たちは、フロントオフィスとミドルオフィスチーム間の取引の流れにかなりの時間を費やし, 取引は、承認を得る方法, 処理された, 監視対象, 定住して管理. これらのチームはそれぞれ、それらを効率的にタスクを実行するのに役立ち、独自の視点や仕事パラダイムを持って.

展覧会の視点は、私たちが触れた最後の主要な話題だった. 私たちは見てきたように, これらの視点は、銀行のさまざまなチームがタスクを実行する方法に基づいている. 彼らは専門用語の背景を形成する, そして私たちは道の銀行作品の全体像の理解を開発するのであれば重要であり、. ほとんどの少数, 特にジュニアレベルで, 全体像を軽蔑. 彼らは、Cに確率的計算法と結婚の彼らの本当の仕事から気晴らしと考える . しかし、トレーダーに, それは展開できない限り、世界で最高のモデルは価値がない. 私たちは、狭いを変更した場合, 効果的ではあるが, 組織内の私たちの役割と価値を理解するために手元の仕事に集中する, 私たちは違いを確認するシステムやプロセスの失敗だけでなく、機会の可能性のあるポイントが表示されます. 私たちは、その後、より良いその能力を最大限に私たちのキャリアを取るために配置されます.

その他の貿易の展望

前回の記事では、, 私たちは、さまざまなチームが自分の仕事パラダイムにおける取引活動を表示する方法を説明しました. 銀行の中で最も一般的である視点は、まだトレード中心である. このビューでは、, 取引はプライマリ·オブジェクトを形成する, 全ての従来の取引システムは、それらを追跡する理由である. 一緒に取引の束を入れて, あなたは、ポートフォリオを取得. 一緒にいくつかのポートフォリオを置く, あなたが本を持っている. 全体·グローバル·マーケッツは、単に本のコレクションである. このパラダイムはうまく働いており、異なる可能なビューの間の最良の妥協と考えられる. トレード中心の視点, しかしながら, 唯一の妥協である. トレーディングフロアの活動は、さまざまな角度から見ることができる. 各視点は、銀行がどのように機能するかにおけるその役割を持ってい.

Other perspectives

トレーダーの観点から, 取引活動は、資産クラスの中心に見える. 一般的に資産クラスに基づいて特定のトレーディングデスクに関連付けられている, 自分の好きなビューには、モデルや製品を横断. トレーダーへ, すべての製品およびモデルは、単に利益を上げるためのツールである.

IT部門は、全く別の視点から、取引の世界を見て. 彼らのシステムを中心とした図である, ここで、2つの異なるシステムに登場する同じモデルを使用して、同じ製品は基本的に2つの完全に異なる獣です. このビューは、特にトレーダーには理解されていません, またはどのように多くの開発者.

全体銀行が高く評価していることを一つのビューには、上級管理職である, 狭義に一番下の行に焦点を当てされている. 大きなボスは、物事に優先順位を付けることができます (製品かどうか, 資産クラスまたはシステム) お金の面で彼らは株主にもたらす. モデルと取引が上から彼らの見解から一般的には見えない — ない限り、, もちろん, ならず者トレーダーが特定の製品や特定のモデルを使用することにより多くのお金を失う.

貿易は市場リスク管理に達すると, ポートフォリオやブックレベルのビューへの貿易·レベル·ビューからの視点に微妙な変化がある. 数学的に些細なものの (結局, 違いは、集約の問題だ), この変更は、システム設計における意味を有する. 取引ライフサイクルの後の段階で必要に応じて各種のダイシングとスライス天然容易に取り扱うことができるように、取引プラットフォームは、堅牢な階層ポートフォリオ構造を維持しなければならない.

それが資金調達のために来て、コストセンターの彼らの概念れると, 貿易は予約システムのうちほとんどです. まだ, 彼らはトレーディングデスクと資産クラスのコストセンターを管理する. 任意の取引プラットフォームを、私たちのデザインは、同様に彼らの特定の要件に対応するために、システムに十分なフックを提供しなければならない. このビューに密接に関連人事の視点で, 誰がコストセンターまたはチームレベルでボトムラインの観点で測定された性能に基づいてインセンティブを決める.

ミドルオフィス

ミドルオフィスチームが採用視点が興味深いものです. 彼らの作品のパラダイムは、ファーストインで実行されているキューのことです。, 先入れ先出しモード. 下図に示すように、, 彼らは妥当性確認及び検証のキューの一部であるとの取引を考える. 新たな貿易が計上されている場合, それは一方の端部からの検証キューにプッシュされます. ミドルオフィスのスタッフは、もう一方の端からのキューを攻撃, 各エントリを受け入れるか、拒否. 良いと考えられるものは、第2の検証キューに入る. 悪いものは、商品のエントリまたは可能なキャンセルでの修正のためにトレーディングデスクに戻ります.

Middle Office perspective

類似したパラダイムはこのような定着率などの市場操作に対処する上で採用されている, キャッシュフローなどを生成. 市場操作は、独自の二段階のキューを有している. 全体の流れは、取引プラットフォームによって促進されるべきであることに注意してください, 異なるビューをレンダリングする能力を持つべきである. これは、ミドルオフィスのスタッフへのデータのキューベースのビューを提示し, および市場リスク管理チームへの報告ベースのビュー, 例えば, または他のチームのほとんどにトレード中心の視点. 両者が効率的に通信できるように、他の作業パラダイムのための基本的な把握と健全な敬意を持つように、各チームにとって重要である. これは、銀行の残りの貿易の視点を無視して無意味です. 結局, 例えば、商品の視点は、試行錯誤の何年も何年から自然に進化した.

開発者について

クオンツとは異なり、, 定量的な開発者は、より多くの製品中心である. 彼らの仕事は、価格モデルを取ることです (定量的な努力の出力) やトレーダーに彼らが展開可能とアクセスできるようにする, 営業チームとミドルおよびバックオフィス. 仕事の彼らの主な単位は、製品である場合に、製品定義の変更理由, 関係なく、新規または既存の価格決定モデルを使用するかどうかの, 彼らはシステムに統合する必要があります. 単に製品のバリアントであっても, 彼らはすべてのインフラストラクチャを実装し、その下流の処理のために承認プロセスの世話をする必要があり. このため, 定量的な開発者に最も理にかなって作業パラダイムは製品中心である.

Quant developer perspective

クオンツと比較すると, 定量的な開発者は、フロントオフィスとミドルオフィスでの日常的な活動に近い. 彼らは取引を表示する (一意のIDによって識別される) 製品のインスタンス化など. 一度予約した, 彼らは取引プラットフォームデータベース内貿易の入力で定義された属性を持つように異なるオブジェクトに終わる. 入力を取引するほか、, 彼らは市場データを使用し、貿易の形で製品の価格をフィード. 取引プラットフォームは、取引情報および市場データを組み合わせた価格設定のインターフェイスが付属しています. それはまた、バッ​​チモードと呼んで実行され — 定期的に、一日の特定の時点ですべての取引の価格と感度を計算する. それはバッチジョブを実行する取引プラットフォームであるため、, 定量的な開発者は、グリッド·コンピューティング·プラットフォームのように関連付けられたリソースの世話をすることが, 市場データフィード, 貿易データベースなど. この点において, 彼らの製品中心の視点は、貿易中心のビュー内に拡散されるかもしれ.

方法

あなたは定量的である場合, あなたは数学や物理学の高度な学位を持つ数学者である. あなたの仕事は、学術研究やプロの両方に基づいています, ピアレビュー出版物. あなたはそれらからの入力を取る, あなたが製品のクラスに非常にうまく動作すると思い確率的価格モデルを思い付くためにあなた自身の恐るべき知性を適用. また、製品の詳細が必要になります. あなたが出力され, もちろん, 独自の価格決定モデル, または文献からの価格設定モデルの実装. これはあなたの主要な作業単位である.

Quant perspective

この価格設定モデルを利用するために, それが検証されなければならないでしょう. その後、価格決定モデルを使用した製品のセットが定義され、承認のために提出される. 一度承認​​された, 取引入力および市場データの助けを借りて、, 各製品は、取引プラットフォームに価格設定して予約することができます. しかし、そのような活動は、定量の関心と影響範囲外にある. 彼らに, 製品が貿易にインスタンス化されるかはかなり無関係と簡単です. それは単に価格モデルに貿易と市場インプットを指定する質問です. 機械的であってもどのようにさまざまな製品が派生する, およびすべての “リアル” 作業は、価格決定モデルで行われます.

このパースペクティブ, 定量のために正確かつ機能的なも, かなり遠い銀行の残りのビューから削除され, クオンツは時に業界とタッチの外にあることの怪しげな評判を持っている理由である. ポイントは彼らの視点を変更する必要があることをそんなにはありません, 彼らは、彼らが相互作用する他のビジネスユニットによって保持され、他の等しく有効な視点があることを理解するべきである, それらを知るための努力をする.

貿易の展望

この記事シリーズの最後のセクションでは、貿易の視点である. 実際には, 銀行の静的構造と貿易の時間的進化に関するわれわれの以前のセクションでは、この最後のセクションに準備されてきた. ポストの次のカップルで, 私たちはどのようにクオンツが表示されます, 定量的な開発者およびミドルオフィスの専門家 (残り) 取引や取引活動を参照してください. 自分の意見は重要であり、任意の取引プラットフォームの設計思想に収容される必要がある.

どこでこのような観点から来るのか、なぜ私たちはそれらについて知っておく必要があります? 貿易の視点は、各ビジネスユニットに固有の作業パラダイムに基づいています. そのためグループが焦点を当てて取引活動のどのような局面の, 彼らはパラダイムを進化させる, あるいはメンタルモデル, それが彼らのために最高の作品.

理解するために, それでは私たちは現代のパソコンでどのように機能するかを見てみましょう. 私たちがされていパラダイムが机の一つとファイリング·キャビネットです. だから私たちは、デスクトップを持っている, フォルダとファイル. 彼らは今、私たちはすべてでコンピュータと対話する別の方法を想像することはできませんことを私たちのためにとても自然になっている. インターネット, 他方では, 私たちの上に置いた何かのパラダイムに基づいて構築されて, なぜこれは “ダウン”-それからの負荷のものと “アップ”-そこに負荷のもの. しかし、そのようなパラダイムを開発するプログラマーや建築家は、多くの場合、同様に異なると少ない既知のパラダイムで動作しない; 例えば、私たちはとても上のポートとソケットとストリームとを持っている.

私たちは仕事のパラダイムを理解していない場合は, 私たちは神秘的で不可解なことが付属して専門用語を検索します. 私たちは、異なるパラダイムを持つ複数の事業部門を横断するプロジェクトで作業する場合、これは特にそうです.

Trade perspectives

当社のトレーディングの世界からの例でさらにそれを説明するために、, 私たちは、貿易を識別する方法を見てみましょう. クオンツは本当にトレード識別番号を気にしない; 彼らのために, それは彼らと仕事の基本的な単位である価格設定モデルである. 定量的な開発者, 他方では, 識別子がトレードごとに一意なものにしたいと思います. ストラクチャラーは、構造を構成する個別のサブ取引のための可能なサブIDを持つ貿易のための1の識別の基準を持っていると思います. この要件を実装するのは簡単ですが、, ソフトウェアアーキテクチャはまた、フロントオフィスとミドルオフィスからのキャンセルや修正案の要件を取引する応える必要があります. 構造が変更またはキャンセルされた場合はどうなりますか? 関連の取引をどのように見つけるのですかとwithall対処? この問題は、ほとんど常に、データベース内のリンクIDを必要としてしまうであろう. ライブ取引での取引番号の改正は、同様に文書化と運用スタッフのための問題を作成する, 各取引に接続された別の不変の外部参照番号を要求するかもしれない人. 監査は、あらゆる完全性とindelibilityが必要になります, 厳しいデータベースレコードの複製. 私たちは見ることができるように, 各ビジネスユニットの視点と仕事パラダイムは、多くの場合、基本的なレベルでのプログラムの設計上の要件に矛盾するように変換する. 私たちは、このシリーズの次のポストでは、貿易の視点でクローズ見てみましょう。この理由のためである.

要約 — 貿易·ライフ

それによって私達は貿易のライフサイクル上の議論の終わりになってきた. 私たちは、そのような価格決定モデルの定量的作品として取引前の活動について話しました, 独立したチームによるその検証. ごとの貿易に基づき, 私達は販売および信用調査活動を持っている. 取引が開始されると, それはミドルオフィスによる初期検証作業を経て, チームの多数による定期処理が続く, そのような限界の監視と報告のための市場リスク管理など, 評価性チェックと準備金の計算のためのプロダクトコントロール, ヘッジのリバランスとリスク管理およびトレーディングデスク. 貿易の生活の終了段階の間, それは集落で活躍しているバックオフィスのチームであるとレポート.

Trade lifecycle summary

私たちは見てきたように, 活動の中で最も, 特に創業時の貿易の終了まで, 取引プラットフォームは、プロセスを仲介し、次の1つのビジネスユニットから商品を運ぶに重要な役割を果たしている. しかし、これらの異なるビジネスユニットは、独自の根強い作業パラダイムと連携, 取引があるか、どのような自分の仕事が関与すると互いに根本的に異なるものとすることができるかについてとその展望. 複数のチーム間での取引プラットフォームカット以来, それはこれらの異なる視点に応えるためにあります, 次の投稿を開始し、このシリーズの最後のセクションには、これは.

終端

貿易の最後のライフサイクルイベントです, もちろん, その終了. これは、さまざまな理由でトリガすることができ. 理由はあるかもしれないものは何でも, 取引が終了すると, それは、バックオフィスによって集落とドキュメントのアーカイブを要求. 加えて, それは公共の開示をトリガすることができる (集計形式で) ファイナンスによる, 人事によるインセンティブの調整.

貿易の終了と、それがトリガーワークフローの一般的な理由を次の図に描かれている.

Trade termination

  • 貿易成熟度: 貿易やオプションが満期に達したとき, それが終了されます, 貿易終了の最も平穏モードがある.
  • オプションの行使: 銀行またはその相手方がオプションを行使した場合, それが終了されます. 演習は貿易の存続期間中にいつでも行うことができる, または、特定日に, 関連する製品のtermsheetの説明に応じて.
  • バリア違反: バリアオプション (またはオプションを-ノックインおよびノックアウト) 事前に定義された障壁を破ることができ、生成する集落や新しい取引を終了されるかもしれ.
  • ターゲットトリガ: 目標に向かって蓄積​​·インスツルメンツ (このような範囲引当金またはターゲット償還を前方として) 目標に達したときに終了れるかもしれ.
  • 展覧ノベーション: ノベーションは、特別なプロセスであることで、貿易取引相手の変更. 実際には, オリジナルの相手方は別のものに取引やオプションを販売している. 更改が発生した場合, 元の取引が終了し、新しいものが特別な特性を用いて開始.

検証と処理

取引は取引プラットフォームデータベースに計上されると, それは検証と日次処理の全体のコーラスをトリガ. 検証プロセスは、ミドルオフィスにおけるフロントオフィスにおけるトレーディングデスクと制御ユニット間の往復ダンスです, すべての取引プラットフォームにより媒介される. トレーダーは、実験的に貿易を挿入することができる. 彼らはそれが実行可能な取引であると確信していたら、, 彼らが確認された状態にプッシュ, 自己制御装置によってピックアップされる. トレーダーは取引を破棄することを決定した場合, 貿易はゴミの山で終わる (しかし完全に削除されません). 制御ユニットは、典型的には4つ目で動作, ダブル検証モード. 彼らは貿易の入力を検証する, そのような特定の製品に許可取引の数などと管理限界. 貿易は彼らのテストに合格した場合, 彼らは、検証の状態に、そのステータスを設定する, そのチェックの第二のレベルをトリガ. 貿易はどちらかのレベルに合格しなかった場合, それらはトレーダーがそれを変更し、又はそれを破棄するかを可能な状態に押し戻されている.

Trade validation

貿易が完全に検証されると, 処理部が始まる. これは、複数のチームと複数の視点を伴う, 貿易が識別されるべき基本的な情報単位に識別されるべきかから始まる.

Daily Processing

上図のように, 定期的な処理は、さまざまなビジネスユニットで行われます.

  • トレーディングデスクは、ヘッジやリバランスのための取引を監視する, 監視損益 ((P / L)), およびリスク限度内に留まる. シニアトレーダーは、この正規処理によりジュニアのものから蒸留の情報を取得し、適切な行動をとる.
  • ミドルオフィスは、通常のプロセスで重要な役割を果たしている. それらは標的およびバリア違反を監視する, レート固定具及びオプション行使, キャッシュフローの生成, 及びその他の現金取引を産卵. 彼らは、生成 (取引プラットフォームの助けを借りて、) バックオフィスがオンに行動するための適切な会計が引き金, 決済を行うために, 取引確認, ドキュメントのアーカイブなど.
  • 商品管理には積極的に日常的にP / Lを監視するミドルオフィス内に埋め込まれた別のビジネスユニットであり、, 感度と市場動向に基づいて彼らの動きを説明する目的で, 取引活動の収益性とは独立して計算を提供する. 準備金の彼らの計算は、財務および人事部門に供給し、トレーダーのインセンティブと報酬に影響を与える.
  • 市場リスク管理はまた、取引の制限の毎日の監視を実行するために採用職員の大群を持って (そのような想定元本として, デルタ同等物等) だけでなく、VaRの計算, ストレスVaRのテスト. ほとんどの銀行では、, 彼らはまた、規制当局への報告、コンプライアンスを処理し、取引戦略を決める上層部に簡潔で実用的な情報を提供.

私たちはすぐに見るように, 各ビジネスユニットの異なる、特定の焦点は、ユニークな投影を要求 (私たちは視点を呼ぶであろう) 取引プラットフォームから取引情報の. この要件は、その設計と実装はとても難しくするものの一つです.

貿易インセプション

取引の開始事象は、2つのカテゴリに分類することができる。. 取引前の活動は最初の取引が計上される前であっても場所を取る有するものである. ごとの貿易創業活動は各取引に固有のものです.

Pre-trade activities

取引前の活動は、オンボーディングと承認、新製品に関連している. 私たちは見てきたように, 社内での取引プラットフォームは、軽快かつ応答するように設計されています. 原則として, 新製品は、オン乗り込みであるためにはそれは少し時間がかかるはずです. 私が働いた最後のシステム, 例えば, 数分で新製品のアイデアを展開するように設計されました. しかし、このようなシステムのアーキテクトは、人間を忘れがち, それに関与するプロセス関連及び制御要素. 上記のスライドが示すように, 新製品のアイデアや新しい価格モデルは、モデルクオンツの仕事やフロントオフィスにおけるストラクチャラーから発信. しかし、それは生産システムの近くにどこにでも取得する前に, 価格モデルは検証する必要がある, 一般的にバイ 分析チーム ミドルオフィス、リスク管理グループ内. 確認が終了, 製品は、数週間または数ヶ月かかる場合が曲がりくねった承認プロセスを通過します, その後正式な展開プロセス, 再び数週間または数ヶ月かかる可能性がある. その処理が終了すると, 製品は、取引プラットフォームで取引可能です.

一度利用可能, 製品は貿易としてインスタンス化することができます. 各取引インスタンスには、独自の検証と承認プロセスを通過. トレード要求は、フロントオフィスでの販売、ま​​たは構造化チームから生じ得る. 彼らはまた、タームシートやその他の法的書類を準備します. これらのタスクが完了したら, 取引は取引プラットフォームに計上されている.

Per-trade process

これらの当初のイベントが第二スライド上記に示されている. 承認プロセスにおける重要なステップの一つは、クレジット制御である. 我々は、先に述べたように, インクルード 信用リスク管理 チームが伴うリスクを評価するためにさまざまなツールを使用しています. 彼らの承認を得て, そして、製品の市場価格のトレーダー理解と, 取引プラットフォームで利用可能な製品は、データベース内の貿易になる. そしてlifecyclingの楽しみが始まります.