Алгоритм упрощения валютных ордеров

Question

Это почти не зависящий от языка вопрос, а не домашняя работа. В идеале я бы использовал C # и / или SQL-сервер для решения.

Предположим, у меня есть функция GetExchangeRate(buyCurrency, sellCurrency). Так, если 1 фунт стоит 1,6 доллара, то GetExchangeRate('GBP', 'USD') = 1.6 и GetExchangeRate('USD', 'GBP') = 0.625.

Заказы в системе будут представлены следующими триплетами: (buyCurrency, SellCurrency, buyCurrencyAmount). Таким образом, ('GBP', 'USD', 125.00) означает купить 125 фунтов стерлингов, сколько бы долларов это ни стоило.

Моя цель - сэкономить на транзакционных издержках и отменить заказы, включая транзитивность. Учет покупок и продаж между одной и той же парой валют легко сделать и легко обосновать. Скажем так, у меня может быть бизнес-причина упростить заказ, когда я покупаю GBP за USD, а также покупаю EUR за GBP и так далее ...

Я хочу транзитивно упростить этот набор заказов. Я думал о построении структуры данных графа (узлы - это валюты, а ребра - buyCurrencyAmounts), хотя данные будут храниться в таблицах SQL, и применяя для этого правильный алгоритм. Я подумал о том, чтобы сначала сделать простую сетку, затем выполнить топологическую сортировку в группе обеспечения доступности баз данных, затем начать сверху, затем идти в топологическом порядке и «сжимать» порядки вниз, например, упрощая их.

Проблема в том, что у меня не обязательно будет DAG. Но тогда я, вероятно, буду упрощать структуру графа при выполнении алгоритма, какой бы он ни был.

Какую структуру данных / алгоритм мне следует использовать для этого? Должен ли я беспокоиться о точности? Есть ли хорошие подходы, чтобы не терять центы на ходу? Можете ли вы порекомендовать хорошую библиотеку C #, которая справится с этим? Было бы сумасшедшим / неэффективным / слишком много работы, чтобы попытаться сделать это, используя только SQL Server 2008?

РЕДАКТИРОВАТЬ: Все сборы, уплачиваемые за транзакции, включены в цену (обменный курс). Там нет фиксированной фиксированной платы или что-то в этом роде.

Answer 1

Один из возможных методов - потоки с минимальными затратами .

1. Определите, сколько каждой валюты покупайте и продавайте.

2. Создайте ориентированный график, где узлы являются валютами, дуги - это возможные преобразования между валютами, а затраты на дуги отражают влияние спредов (я предполагаю, что перечисленные курсы являются абсолютно эффективными и, таким образом, любой цикл преобразований умножается1).

3. Используйте один из описанных алгоритмов полиномиального времени для расчета потока с минимальными затратами.

Answer 2

Вам необходимо внедрить многосторонний платежный неттинг .«Хитрость» заключается в том, чтобы создать новый объект под названием центр взаимозачета и перенаправить все платежи через него.См. Мой ответ на аналогичный вопрос здесь о преимуществах этого подхода.

Цель состоит в том, чтобы выйти из этой ситуации ( до неттинга ):

к этому ( после взаимозачета ):

Каждая дочерняя компания должна иметь одну сумму (либоплатить или получать) из центра взаимозачета в их национальной валюте, которая является суммой встречных значений всех индивидуальных счетов, которые они должны любому другому субъекту в группе.

Основной алгоритм:

• Начните с таблицы счетов с Плательщиком , Получателем , Валюта и Сумма столбцы.Они соответствуют потокам в сценарии «до неттинга»
• Создать временную таблицу подплатежей, которая имеет столбцы Entity , Валюта и Сумма
• Итерация по каждому счету, добавление строки во временную таблицу для каждого Плательщика, Валюты, Суммы в таблице счетов.
• Затем сделать то же самое для квитанций, добавив Получатель, Валюта и Отрицательный Сумма.
• Сверните подплатежи в промежуточные итоги по валютам для каждой организации.
• Преобразуйте итоги подплатежей (при необходимости применив спред)
• Временная таблица теперь соответствует ситуации в 'afterсценарий неттинга

Ошибки округления будут сведены к минимуму, поскольку вы будете конвертировать только итоги.Любые результаты ошибок округления будут в конечном итоге на счетах центра неттинга.Счета центра неттинга будут содержать промежуточные итоги валют, которые должны быть проданы валютным банком, чтобы конвертировать их в базовую валюту, например, в доллары США.Применяемые ставки должны быть теми, которые использовались при расчете неттинга, поэтому после согласования с банком FX расчет следует переделать (и итоги будут очень незначительно меняться).

(Одно из преимуществ использования многосторонняя вместо двусторонняя взаимозачет состоит в том, что все такие валютные требования все "требуются" одной и той же организации, т.е. , центру неттинга. Также, если вы выберетедля взимания спреда , т. е. , курс покупки и продажи различается, тогда любая полученная «прибыль» также попадет на счет центра неттинга).

Что касается фактического выполнениявычисления - это достаточно просто выполнить непосредственно в SQL, но вы можете обнаружить, что есть достаточно юридических и / или конфигурационных опций, чтобы оправдать более абстрагированный подход.

(Для примеров юридических вопросов: некоторые правительства не разрешают конвертировать иностранную валюту в трансграничных операциях; другие не позволяют компенсировать платежи и поступления; некоторые требуют разрешения от центрального банка. Некоторые страны с особымитребования включают в себя Бразилию, Китай, Малайзию, Россию и т. д.).

Answer 3

Мне кажется, что думать о наборе транзакций как о графике слишком сложно. Просто возьмите каждую транзакцию в вашем наборе и добавьте валюты (то есть добавьте все покупки / продажи в фунтах стерлингов, все покупки / продажи в долларах США, покупки / продажи в евро).

В результате вы получаете чистую покупку / продажу в каждой валюте. Затем просто начните выбирать транзакции на основе наименьшего спреда (т. Е. Если у вас самый низкий спред на евро, затем выберите транзакцию в евро, которая может составлять несколько евро или несколько долларов), продолжайте ...