Раньше я думал, что самая неловкая часть при покупке — это в основном решить, когда отправлять деньги. Потом заметил, что неудобная часть обычно наступает сразу после этого. Одна сторона уже сделала то, что должна была сделать, но другая сторона всё ещё где-то в процессе.

Этот разрыв невелик, когда вы покупаете что-то обычное. Игнорировать его становится сложнее, когда передаваемый объект — финансовый актив.

Именно здесь для меня начало обретать смысл решение Dusk с доставкой против платежа (DvP).

Dusk описывает проблему как необходимость согласовать «активную» часть операции с «платёжной» частью в рамках единого рыночного рабочего процесса. Dusk Trade находится на прикладном уровне для этих рабочих процессов, тогда как DuskDS предоставляет расчёт, окончательность и доступность данных «снизу».

Сначала я прочитал это как просто выполнение двух переводов одновременно. Но чем дальше я следовал этой логике, тем менее точным это казалось.

У актива могут быть свои требования к допустимости и условия перевода. Платёж всё равно должен быть учтён. Полезная часть, похоже, в том, что обе стороны (обе «ноги» операции) вводятся в один и тот же процесс расчёта, а не оставляются две отдельные системы, которые потом нужно сопоставлять и согласовывать.

Это не означает, что DuskDS определяет все правила сделки. Эти правила всё ещё могут находиться на прикладном уровне — в зависимости от рабочего процесса.

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

И, возможно, именно этого мне и не хватало. DvP на самом деле не про то, чтобы сделать актив и платёж идентичными. Это про то, чтобы уменьшить пространство между ними, где одна сторона может считаться завершённой, пока другая всё ещё не разрешена.

Я всё ещё пытаюсь понять, какая доля этого согласования обеспечивается самим расчётным уровнем Dusk, а какая — конкретным приложением, реализующим рабочий процесс.

#dusk $DUSK @Dusk $ACE $SNXXB