2012issue C0862
Rebate-aware routing and execution cost
An executable order is a fee-schedule choice as well as a price choice. Decide whether the working interest is providing-liquidity or taking-liquidity, then sequence destinations so rebate and charge sit inside implementation cost over the life of the order.
- Providing-liquidity meant resting a limit so another participant had to hit the bid or lift the offer, and venues historically paid a rebate for that posted size.
- Destination choice changed implementation cost even when the displayed price did not, because the same share could fill where a rebate was paid or where a larger take fee was charged.
- A smart-order-router could ping rebate-paying destinations first, including selected dark-pool-improvement sites that might fill inside the entered limit by a stated increment, then send any unfilled remainder to the next site.
- A consistent pattern parked providing-liquidity on venues that paid for posted size and used taking-liquidity on inverse-fee-venues or on venues that charged less for the take. Retail pass-through of those payments was not automatic.
The executable order as a fee-schedule choice
Editorial: decide whether the working interest is providing-liquidity or taking-liquidity, then sequence destinations so the rebate or charge is priced into implementation cost over the life of the order rather than treated as a back-office leftover.
Providing-liquidity meant posting a limit and waiting for another party to hit the bid or lift the offer. Venues historically paid a rebate for that posted size. Taking-liquidity meant aggressing displayed or hidden size by hitting a bid or lifting an offer.
Inverse-fee-venues and changing schedules
Some electronic venues used inverted fee schedules. An inverse-fee-venue paid participants for taking-liquidity rather than for providing-liquidity.
Rebate and fee amounts were not static. They varied with overall share volume and other factors.
How a smart-order-router sequenced destinations
A smart-order-router could ping rebate-paying destinations first, including selected dark pools, then continue to the next available site.
A dark-pool-improvement site could fill inside the entered limit by a stated increment or leave the order unexecuted so it moved to the next destination.
The same share could be routed to a destination that paid a small amount for the fill or to one that charged a larger take fee. Destination choice changed implementation cost even when the displayed price did not.
A consistent routing pattern was to park providing-liquidity on venues that paid for posted liquidity and to use taking-liquidity on venues that paid, or charged less, for taking it. Inverse-fee-venues belonged on that take path because they paid the remover of liquidity instead of the poster.
Pass-through and payment-for-order-flow
Retail treatment of these cash flows varied by firm. Many internalized flow, matched customers against one another, or sold order flow without pass-through of venue payments to the originating account.
That handling is payment-for-order-flow: the broker keeps the related cash flow. Pass-through would instead credit exchange or network payments to the originating account.
All readings on this track · 30 readings
- 1988Why instant basket routing overwhelms specialist liquidity
- 2004Retail forex tickets as implementation-cost contracts
- 2005A two-gate liquidity filter for futures order routing
- 2006Manual after-hours routing and open-outcry fill risk
- 2010A futures brokerage quote is an execution specification
- 2011Smart order routing, maker-taker, and midpoint execution costs
- 2012Compare equivalent listings before routing
- 2012Rebate-aware routing and execution cost
- 2012Platform routing, fees, and server-side stops
- 2013Compare equivalent listings, then route the order
- 2013Confirm routing, margin, and fill cost before a live forex order
- 2013Brokerage choice as an execution-cost and routing filter
- 2014Order routing, pass-through rebates, and liquidity choice
- 2014Comparing exchange venues before routing the order
- 2014Selecting a futures broker as an execution-architecture problem
- 2014Commission shopping is the wrong first filter for a futures order
- 2015Routing orders when equivalent products trade on multiple venues
- 2015Forex venue checks for speed, margin, and implementation cost
- 2015Backup venues and symbol splits in futures routing
- 2016Route orders across competing exchange venues
- 2016Filter exchange venues before routing orders
- 2017Venue choice as an order-routing filter
- 2017Venue routing for equivalent listed contracts
- 2017Forex broker checks for fill speed, quote honor, and margin
- 2017Brokerage choice as an execution-speed and commission filter
- 2018Routing equivalent contracts across competing venues
- 2018Forex venue selection by fill speed, margin terms, and price honor
- 2019Forex execution filters for routing, cost, and liquidity
- 2020Routing equivalent listings across competing exchanges
- 2020Brokerage filters for routing, commissions, and liquidity