Rebate-aware routing и стоимость исполнения

Исполняемая заявка как выбор тарифной сетки

Редакция: определите, является ли рабочий интерес providing-liquidity или taking-liquidity, затем выстройте последовательность площадок так, чтобы ребейт или комиссия были заложены в стоимость реализации на всём жизненном цикле заявки, а не воспринимались как остаток бэк-офиса.

Providing-liquidity означало выставить лимит и ждать, пока другая сторона ударит по биду или снимет оффер. Площадки исторически платили ребейт за этот выставленный объём. Taking-liquidity означало агрессировать отображаемый или скрытый объём, ударяя по биду или снимая оффер.

Inverse-fee-venues и меняющиеся тарифные сетки

Некоторые электронные площадки использовали инвертированные тарифные сетки. Inverse-fee-venue платила участникам за taking-liquidity, а не за providing-liquidity.

Размеры ребейта и комиссий не были статичными. Они менялись в зависимости от общего объёма акций и других факторов.

Как smart-order-router выстраивал последовательность площадок

Smart-order-router мог сначала опрашивать площадки, платящие ребейт, включая выбранные дарк-пулы, затем переходить на следующую доступную площадку.

Площадка dark-pool-improvement могла исполнить внутри введённого лимита на заявленный инкремент или оставить заявку неисполненной, чтобы она перешла на следующую площадку.

Та же акция могла быть направлена на площадку, которая платила небольшую сумму за исполнение, или на площадку, которая брала более высокую take fee. Выбор площадки менял стоимость реализации даже когда отображаемая цена не менялась.

Устойчивый паттерн маршрутизации состоял в том, чтобы размещать providing-liquidity на площадках, которые платили за выставленную ликвидность, и использовать taking-liquidity на площадках, которые платили или брали меньше за её снятие. Inverse-fee-venues относились к этому пути снятия, потому что они платили снимающему ликвидность, а не выставляющему.

Pass-through и payment-for-order-flow

Розничная обработка этих денежных потоков различалась по фирмам. Многие интернализировали поток, сводили клиентов друг с другом или продавали поток заявок без pass-through выплат площадки на исходный счёт.

Такая обработка — это payment-for-order-flow: брокер удерживает связанный денежный поток. Pass-through вместо этого зачислял бы биржевые или сетевые выплаты на исходный счёт.