1

これはほとんど言語にとらわれない質問であり、宿題ではありません。理想的には、解決策として C# や SQL サーバーを使用します。

関数 があるとしますGetExchangeRate(buyCurrency, sellCurrency)。したがって、1 GBP が 1.6 USD の価値がある場合、GetExchangeRate('GBP', 'USD') = 1.6とGetExchangeRate('USD', 'GBP') = 0.625.

システム内の注文は、次のトリプレットとして表されます: (buyCurrency, SellCurrency, buyCurrencyAmount). したがって、('GBP', 'USD', 125.00) は、125 GBP を購入することを意味します。

私の目標は、取引コストを節約し、推移性を含めて注文をキャンセルすることです。同じ通貨ペア間の買いと売りをネッティングするのは簡単で、簡単に正当化できます。USD で GBP を購入し、GBP で EUR を購入するなどの注文を簡素化するビジネス上の理由があるとしましょう。

この一連の注文を推移的に単純化したい。データは SQL テーブルに格納されますが、グラフ データ構造 (ノードは通貨、エッジは buyCurrencyAmounts) を構築し、これに適切なアルゴリズムを適用することを考えていました。最初に単純なネッティングを行い、次に DAG でトポロジカル ソートを行い、次にトップから開始し、トポロジカルな順序で歩き、順序を「絞る」、たとえば単純化することを考えました。

問題は、必ずしも DAG があるとは限らないことです。しかし、アルゴリズムを実行するにつれて、グラフ構造を単純化する可能性が高くなります。

これに使用する必要がある正しいデータ構造/アルゴリズムは何ですか? 結果の精度について心配する必要がありますか? 私が行くときにセントを失わないための良いアプローチはありますか? これを処理できる優れた C# ライブラリをお勧めできますか? SQL Server 2008 のみを使用してこれを試みるのは、クレイジー/非効率的/多すぎる作業でしょうか?

編集:取引に支払われる手数料はすべて価格 (為替レート) に組み込まれています。固定の定額料金などはありません。

4

3 に答える 3

1

考えられる手法の 1 つは、最小コスト フローです。

  1. 売買する各通貨の量を決定します。

  2. ノードが通貨であり、アークが通貨間の可能な変換であり、アーク コストがスプレッドの影響を捉える有向グラフを作成します (記載されているレートは完全に効率的であり、変換のサイクルは 1 に乗算されると想定しています) .

  3. 説明されている多項式時間アルゴリズムのいずれかを使用して、最小コスト フローを計算します。

于 2011-07-25T20:34:29.397 に答える
1

マルチラテラル ペイメント ネッティングを実装する必要があります。「トリック」は、ネッティング センターと呼ばれる新しいエンティティを作成し、それを介してすべての支払いを再ルーティングすることです。このアプローチの利点については、こちらの同様の質問に対する私の回答を参照してください。

目標は、この状況から移行することです (ネッティング前):

ネッティング前

これに（ネッティング後）：

ネッティング後

各子会社は、グループ内の他のエンティティに対して負っているすべての個々の請求書の対価の合計である自国の通貨で、ネッティング センターから単一の金額 (支払うか受け取るかのいずれか) を受け取る必要があります。

基本的なアルゴリズムは次のとおりです。

  • Payer、Payee、Currency、およびAmount列を含む請求書のテーブルから始めます。これらは、「ネッティング前」シナリオのフローに対応します。
  • Entity、Currency、およびAmount列を持つサブペイメントの一時テーブルを作成します
  • 請求書テーブルの各支払人、通貨、金額の一時テーブルに行を追加して、各請求書を反復処理します。
  • 次に、領収書についても同じことを行い、受取人、通貨、および負の金額を追加します。
  • サブペイメントをエンティティごとの通貨の小計にロールアップします。
  • サブペイメントの合計を換算します (必要に応じてスプレッドを適用します)。
  • 一時テーブルは、「ネッティング後」のシナリオの状況に対応するようになりました

合計のみを変換するため、丸め誤差は最小限に抑えられます。丸め誤差の結果は、最終的にネッティング センターのアカウントに反映されます。ネッティング センターの口座には、通貨の小計が含まれており、これらを FX 銀行と取引して基本通貨 (USD など) に変換する必要があります。取引されるレートは、ネッティング計算で使用されるレートである必要があるため、FX 銀行と合意したら、計算をやり直す必要があります (合計はわずかに変化します)。

(二国間ネッティングの代わりに多国間ネッティングを使用する利点の 1 つは、そのような FX 要件がすべて同じ単一のエンティティ、つまりネッティング センターによって「必要とされる」ことです。販売レートが異なる場合、結果として得られる「利益」もネッティング センターの口座に入金されます)。

実際の計算の実行に関しては、SQL で直接実行するのは簡単ですが、より抽象化されたアプローチを保証するのに十分な法的および/または構成オプションがあることに気付くかもしれません。

(法的な問題の例: 国境を越えた取引での外貨の両替を許可しない政府、支払いと領収書の相殺を許可しない政府、中央銀行からの許可を必要とする政府があります。ブラジル、中国、マレーシア、ロシアなど）。

于 2012-01-10T12:04:59.290 に答える
0

一連のトランザクションをグラフとして考えるのは複雑すぎるように思えます。セット内のすべてのトランザクションを取り、通貨を追加するだけです (つまり、すべての GBP の売買、すべての USD の売買、EUR の売買を追加します)。

最終的には、各通貨で必要な正味の売買になります。次に、最も低いスプレッドに基づいてトランザクションの選択を開始します (つまり、EUR$ のスプレッドが最も低い場合は、EUR$ トランザクションを選択します - 一部の EUR または一部の $ が平準化される可能性があります)、続行します...

于 2011-07-25T20:14:18.367 に答える