Improve commission handling

[limx0]

Feature Request

This was raised on discord and warrants an issue. Currently we assume a flat maker/taker % rate of commission, but there are quite a few different types of ways a broker or exchange may charge commission.

A couple that come to mind:

• flat fee (possibly tiered based on turnover or similar)
• % of notional (possibly tiered based on turnover or similar)
• % of notional with a minimum per trade or period.

It looks like a CommissionModel used to exist here which would be a good place to start.

Ideally we would incorporate some sort of registration method where downstream users can easily register new models if desired.

[rsmb7z]

I was looking for some solution on commission handling as currently only percentage based model is supported. I found below, it is nicely done and covers most of the possibilities. Can we implement this please, specially IB from here.

https://www.quantconnect.com/docs/v2/writing-algorithms/reality-modeling/transaction-fees/supported-models
https://github.com/QuantConnect/Lean/blob/5611b5508ada70dda96cc2b917e9475400f781e3/Common/Orders/Fees/InteractiveBrokersFeeModel.cs

[limx0]

Perfect. @cjdsellers loves C#

[limx0]

On a serious note - great find @rsmb7z , that will serve as a great reference and agreed, we should basically just implement the same thing.

[limx0]

And just dumping some thoughts that I had the other day for this ticket.

We should likely have some sort of backtest module that handles commission adjustments on a portfolio level. Many venues have discounts or rebates for volume, and we will want to model this in our backtesting. For active traders, many strategies may rely on hitting these "commission targets" to be profitable, and may want to know the impact that certain parameterizations have on their commissions.

Individual trades should likely still "pay" the full commission, but we may want some model that adjusts or refunds commission at the portfolio level at the end of some period (say monthly or whatever is applicable) as a backtest is running.

[cjdsellers]

Modeling fee tiers could also be part of the commission model, especially since its likely to be a plug in component to a SimulatedExchange. So likely better to handle there than the Portfolio, even though I agree its a portfolio level concern.

[cjdsellers]

Perfect. @cjdsellers loves C#

Ah, the memories...

[dkharrat]

I just ran into this issue myself :)
Some brokers have a fixed commission, so supporting this model would be very helpful. Any plans to address this soon?

[cjdsellers]

We've made some headway on this now thanks to @rsmb7z with #1584.

So we have two of the three models @limx0 suggested, and everything we need to quite easily add additional model variations.

A next step will be separating the maker_fee and taker_fee fields from instruments, as the fees are more applicable at the venue listing level (and modelled separately), rather than on the instrument.

Closing this for now in favour of more specific tickets.