日付の用語と概念とそれらにまつわる話（１）
前回ＤＤＤについて触れたがその流れを進める前に基礎的概念やルール、習慣についておさらいをしておきたい。
例えばこういう説明を読んでどう思うだろうか。
『valueDate（受渡日）は取引が成立(executed)するまでの命で、いったん取引が成立（約定）してしまうとそれはsettleDate（受渡日）に成り代わる』
『frontDate（フロントデート、取引日）は常に“状態”として持っているものであり、取引日(tradeDate)は受渡日を計算するために必要な日付の概念定義である』
『取引が成立した瞬間のfrontDateがtradeDate(取引日)として記録される』
『frontDateを参照して個々の通貨ペアは当日、今現在における直物受渡日(spotDate)を定義している』
『tradeDate（取引日）は、受渡日(settleDate)を確定させるために必要であるが、いったん取引が成立してしまえばバックオフィスとしては無用な情報である』
これらを、あたりまえだと思う方は以下読む必要はないかもしれない。
■全体
外為証拠金取引においてはいろいろな「日付」の名前が飛び交う。それらを下図のように整理してみた。
まず大きな概念のグループ分けとして、（1）契約（contract）と（2）受渡（settlement）がある。つまり、取引は常に2つの面を持つ。一つは「契約」であり、もう一つは「受渡」である。一つの商行為がこれら二つに分かれることは珍しいことではない。たしか以前にも説明したことがあると思うが、わかりやすい例を挙げると、ネットでものを買うことを考えればいい。ネットで物を買う、注文をすることが「契約」であり、実際にその物が配達されることが「受渡」である。
ここに「決済」という、これまたほぼ「受渡」と同義ともとれる用語があるが、この例でいえば、決済とは、ネット注文してクレジットカード会社での契約承認が完了した行為を指すといえる。注文と取引は私から見ればほぼ同義である。注文も取引の一部である。つまり、「注文/取引」(order/contract)⇒「決済」(clearing/validation/ authorization)⇒「受渡」(settlement/delivery)となる。外為の場合は、実際にモノが動くわけでもなく、この「決済」と「受渡」がほとんど同じ意味にとらえうるため、実際の使われ方としてはあまり違いを求めていない。ただし、それらが違う意味を持つ場合があることは認識しておいた方がよい。モノが取引される場合、一方は銀行等の金融機関同士の電子的取引なので一瞬だが、モノの移動には時間がかかる。為替の場合は、両方とも“お金”なので一瞬にして事が済む。ここから、モノの取引には決済⇒受渡の順序が明確に認識できるが、為替においては、決済はほぼ受渡と同義（同時）になると考えられ、そのように区別なく使われる用語となっていると考える。あえてこまかいことを言えば、契約に基づいた受渡の手前までの作業がすべて終わることが「決済」で、その結果「取引・契約」をした相手とモノとお金を“交換”する行為を「受渡」と概念上分類することができる。
まず図左上を見る。ここにあるのは、systemDateとfrontDate
■systemDate(time)
コンピュータシステムが管理している時間。日本のシステムなら普通はJSTで管理されている。グローバルなシステムでは、UTF（協定世界時, Coordinated Universal Time）で管理しているものもある。その場合は、systemDateはsystemDatetime(UTC)となり、localDatetime(London), localDatetime(Tokyo), localDatetime(NYK)という感じで複数の時間のインスタンス(instance)を持つことがありうる。インスタンスとは、一つのオブジェクトをコピーしたものと考えてもられればいい。
■executionDate
図には書いていないが、取引が成立したときにsystemDateが持っている日付。これはtradeDateではない。日本のシステムなら日本時間で管理されるのが普通。systemDatetimeというvalueObjectからコピーされた時間（instance）がsystemDatetimeとして注文データや約定データに記録される。システムによってはexecutionDate(execDate)がtradeDateと同じ意味で使われているものもある。ここでは私はそれを禁止している。tradeDateはそれ自体とても大事なvalueObjectになる。例外、言葉、用語の揺らぎを許さない前提で臨む。exectutionDateはシステムが管理するローカル時間上の約定した時のsystemDatetimeからDateだけを取り出したものとして考えている。systemDatetimeをexecutuionDatetimeとしてコピーするインスタンスを用意する。
■frontDate
FXシステムが常に状態として持っているインターバンクルールに基づいた現在の日付、valueObjectであり、その中でも本も重要なものである。一般には、NYの午後5時に日付を進めることになるので、systemDate(JST)とfrontDateでは、日本時間の午前0時から午前7時まではsystemDate(JST)>frontDateになっている。また週末は翌週の月曜日の日付に進んでいるのがfrontDateである。frontDateに週末（非営業日）は存在しえないが、平日の祝日は存在する。ただし元旦だけは世界的に祝日なので週末と同様に扱う。今現在の通貨ペアごとのspotDateを計算（指定）するために使うのもこの日付になる。今現在クォートしている“直物”のレートが前提とする受渡日(spotDate)を決めるために必要な世界共通ルールである。注文が約定したときに取引日tradeDateを約定データとして書き込むときに見るのはこのfrontDateということになる。その時の受渡日は、取引するレートがvalueDateとして持っているものである。それを取引の履歴としてはvalueDateとして書きこむ。その結果顧客の場合は先物差金決取引なのでそれが決済であれば決済額が確定する。その時のその業者のルーるがリアルタイム決済であれば、settleDate=frontDateとなり、T+2であれば、settleDate=valueDateになる。という具合にほとんど同じ日付でわずかな違いしかない概念を上手にオブジェクトとして分けて制御する。
■次にcontractの中を見てみよう。
ここでは、大別して、tradeDateグループ（図右上）とvalueDateグループ（左下）に分けてある。tradeDateグループは、上述の例でいえば、契約する日、注文する日、約定する日である。取引の交渉をする対象となる価格は前提とする受渡日が宣言されて初めて決定する。受け渡す日を宣言しないでレートを提示することはだれもできない。金利のない通貨同士なら可能だがそんな通貨はない。ここでの受渡日はvalueDateでありsettleDateではない。valueDateは図右下が示すようなテナー（tenor, 期限）がインターバンクの慣習上あるが、それに限らない。原則valueDate=settleDateであることは間違いない。ならば同じでいいではないかという人もいるだろう。その通りである。リアルタイム決済でなければそうである。しかしそれはここで説明する全体の概念を意識したうえでその結論として一つにまとめるという判断であることを期待する。
契約contractは取引transactionと同義である。注文orderも取引である。したがってorder とtransactionの境界はあいまいである。どちらにも結果としての「成立」と「不成立」が存在し得る。表現として「取引が成立しなかった」、「注文が成立しなかった」と言えるからである。よって取引transactionにはstatusがあり、そこには成立、不成立のどちらかが書き込まれる。
注文とは取引が成立するための諸条件を持っている。その条件の項目は多岐にわたることがある。ただしそれらがすべて満たされ発注されたときに生まれる注文はすでに取引になっている。そこでその取引は“一意”となる。つまり、発注した時間、銘柄、額、価格がすべて決定しており、それに対する結果が与えられている。したがって、取引と同じであるといえる注文は実は取引としての十分条件を持っている。注文テーブルと約定テーブルを分けるのが普通だろうがこの辺の概念をうまく整理すると注文と約定のテーブルを一つにすることも可能である。
■tradeDate
上述の通り、取引が成立した時にfrontDateが持つ日付がコピーされたもの(instance)。システム的には取引が成立した時にfrontDateをコピーしてtradeDateとして記録する。システムっぽく言い換えると、valueObject frontDateからコピーして生まれたinstanceにtradeDateという名前を付けるという意味でもある。
次に、テナー(Tenor)(図左下)を見る。これは、上記契約でうたわれる対象となるAとBを交換する（受け渡す）“予定日”を指す。あくまでも予定する日である。視点を変えると（もっともこっちが本来の視点だと思うが
）、『交換する価格に含むべき時間的価値を計算する基準となる日』である。だから”Value(価値) date”と呼ぶのである。これを「受渡日」と日本語で訳すから誤解を招くことになる。本当なら「価値基準日」「価格基準日」「受渡予定日」とかにして本来のsettleDate(受渡日)と区別してほしかった。
Tenorにはインターバンクの慣習から定型化された複数の将来の日がある。これらはその日を計算するルールが決められている。今日からみた1M（ワンマンス）と、明日から見たそれがどういうルールで決められるかということがインターバンクの中で決められている。それ以外、要するに将来の土日と当該通貨の祝日を除く日ならいつでも“valueは立つ”（業界ではその日で受渡可能のことをvalueが立つという）。
たとえば、今日が1月29日で直物受渡が31日の時、1Mと言うと2月は28日で終わる。その場合は、翌月にまたがないというルールがあるので、28日が1Mとなる，といったルールがある。
■spotDate
インターバンクで通常「直物（じきもの）」と呼ばれる、金利分の価値を含まないレートを定義する受渡日がspotDateである。通常通貨ごとに決まっている。USD(*), TRY, CADはT＋1で、それ以外は大体T＋2である。金利の取引をするときは当然単独通貨でやり取りされるので「通貨」ごとに決まっている。つまりT＋1の通貨においては、今、直物で受け渡す日は明日になるし、T＋2では明後日になる。ただし、通貨ペアの取引の場合は、AとBの2つを同時に交換するので、AがT＋1でBがT＋2の場合は遅いほうに合わせることが決まっている。よってUSDCADはどちらもT+1なので、結果T＋1となる。ほかに、USDTRY,USD/PHP（フィリピンペソ）, USD/RUB（ロシアンルーブル）なども同様である。
(*)USDがT＋1というのには違和感のある人も多いだろう。“USDはT＋2だ”という反論が聞こえてくる。実際ウェブで検索するとUSDはT＋2であると書いてあるものが多い。ただし、私がここでT＋1であるとする理由は、ここで語っている世界は為替だけで債券や金利市場のことは考えていないということと、あくまで通貨ペアとしてのspotDateを計算するシステムロジック的に正しい受渡日を返すにはUSDはT＋1であると考えた方が合理性がある（プログラムが作りやすい）と考えられるからである。例えば上述の「一方の通貨がT＋1でもう一方がT＋2の時はT＋2に合わせる」という考えと、USDはT+2であるという考えを適用すると、USD/CADはT＋2になってしまう。そのため“ただし相手がCADの時はT+1とする”というような例外を作らなくてはならなくなる。そういう無駄を省くため、為替取引だけのルールとしてはUSDはT+1と考えることに“私は”している。
SpotDateを決めるルールとしてはあとひとつ、USDを含まない取引でも、受渡日がUSD祝日の場合はさらに一日繰り延べる、つまりUSDの祝日はいかなる通貨同士の受渡でも避けるというルールがある。実際、たとえば銀行が法人顧客と行うZAR/JPYのような流動性の低い取引については、多くの場合彼らはそれをUSD/ZARとUSD/JPYに分解してポジションを管理する。これをtradeSplitting (splitTrade)と呼ぶとする。これにより出来る限り流動性の高いメジャー通貨とのペアに分解して管理する。そのため当該通貨ペアにおいてUSDがなくともUSDの祝日に為替の受渡をするのは不都合なことが起きる可能性が高いので避けるのである。
■tradeSplitの例
まず通貨ペアを分数で考え分解する通貨を認識する。
?ZARJPYの取引を?USDJPYと?USDZARのメジャー通貨ペアに分解する結論として、?＋?が?と同じZAR long 1,000,000 とJPY short 10,195,000になればいい。
まず、JPY-10,195,000を対ドルで交換するとしたらUSDはいくらになるかを見る、USDとZARでは明らかにUSDのほうが流動性が高いのでそちらを優先する。ここで、JPYはショートなのでUSDはロングになる。したがって、その瞬間、ZARJPYが約定した瞬間もしくはそれに近いUSDJPYのオファーレートを見る。ここでは、121.555なので、それをベースにUSDの額を計算する。結果、USD83,871.50が出てくる。これは本来ないものなのでそれを消すための取引を対ZARで行うという理屈になり、USDZARはUSD売り、ZAR買いになる。したがってUSDは-83,871.50でZARは1,000,000となるので、?とは逆に?では11.923というレートが計算結果として出てくる。
検算として、?の代わりに生まれた?と?を通貨ごとに足したら?と同じになればよい。
以上のような計算でtradeSplittingを行う。?の代わりに?と?を約定データとして入れる。ただし?をまったく入れないというのはコンプラ的におかしい。実際の契約は?なのだから。よって以下のような入れ方をする。
一番上は実際に顧客とやった取引であることを示す。それ以下は、すべてダミーとして入っている。
黄色の部分を見てわかる通り、本物のZARとJPYと同額が見える。そしてそれらの反対側のUSDは打ち消し合っている。
スプリットの方法はこれでないといけないわけではない。裁定の理論が働けば何ら問題ない。なんならドル円のレートは今日はずっとスプリットに使うときは120円ちょうどでやるというルールでも構いはしないが、そうする意図に整合性があればいい。
さらにべつの視点の余談だが、なぜUSD, CAD, TRYのようなT＋1グループが存在するのか。USDとCADについては、お隣同士の国なのでもともと為替取引が始まった時は時差を考える必要がなかったという理屈はわかりやすいが、ではなぜ後発のフィリピンペソやルーブルやトルコリラがT＋1なのか。イスラム教の国は、金利は取れないので本来T＋0なのだろうが、オフショアではそういう縛りはない（オンショアではT+0でやっているが午前中に取引は終了するのが通例）。現実的にトルコリラはT＋0でもT＋1でもロイターはサポートする。やはりカントリーリスクが高い国に対する受渡リスク（ヘルシュタットリスク）は少ないほうがよいということだろうと私は理解している。
■forwardDate
上記の直渡日（じきわたしび）以外はすべて、T＋0，T＋1を含めて先渡日（さきわたしび）となる。ドル円の場合の直物はT＋2になる。この日をvalueDate=spotDateとするレートには金利の考慮がされていない。つまり円金利もドル金利も0％である。よってforwardを「先渡」と訳するが、“先”という言葉に惑わされず、これは直物以外全部であり、today（今日）, tom（明日）取引もforwardになる。today, tomのフォワードレートは、直物(spotDate)を手前に引っ張るので直物の日付以降がディスカウントであれば、プレミアムとなり逆になる。
▼尾関高のFXダイアリーをご覧のみなさまへ
このFXダイアリーで取り上げて欲しい話題、また尾関さんに書いてもらいたいテーマなどあれば業界内外問いませんので、「件名：FXダイアリーへの要望」として info＠forexpress.com までご連絡ください（コラムへの感想でも勿論結構です）。
