|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
Broker
Fees – CTRM Considerations
Some thoughts and
considerations regarding broker fees for CTRM systems.
Outline
3) Allocating
4) Reconciling
5) Margining
CTRM systems
would ideally have functionality to set default broker rates. E.g., $2 to be paid for
each commodity futures contracts.
1.1) Rates should
be able to be set to different default values based on the:
1.1.1) broker. I.e., there may be several
brokers that a firm deals with, each charging a different rate.
1.1.2) Trade type. E.g., options may be at
one rate that might be higher than for futures.
1.1.3) Commodity. E.g., Natural Gas might be
a different rate than for Crude Oil.
1.2) In
addition, might want functionality where users can override the defaults on a
trade by trade basis. i.e.,
either the per unit amount e.g., $2/futures contract or the overall total,
e.g., $1000.
1.3) There might also be several different calculations formulas
needed. For example:
1.3.1) Per
Futures contract, e.g., $2/contract, so buy 100
December Crude futures and pay $200.
1.3.2) Some amount per the notional of the trade.
1.3.3) A fixed amount per trade, regardless of the size.
1.3.4) Some min or max based on the volume.
2.1) One of
the things about Broker Fees is that you may accrue them daily, i.e., as trades
are done, but they are paid monthly.
i.e., you would get a monthly invoice from your broker for certain
trades that are covered by that invoice period, typically the calendar month.
2.2) One
question firms have is if they want the PnL (profit/loss, though in this case a
loss or fee) to accrue each day, i.e., as trades are done, or to just count as
a fee as of the payment date.
This wouldn’t
be too difficult a question except that often the amount on the broker fee
invoice is different than what you might have calculated during the month.
Brokers may
charge a special discounted rate based on a ‘round trip’ trade, where you buy
and sell the same futures contract on a given day. This is not practical to track in real time
(meaning each day), meaning both that it is really hard to do and that it isn’t
worth it as the amounts are typically small.
2.3) Other examples of potential variations in the actual broker
invoice versus accrued amounts based on per trade defaults:
2.3.1) Some sort of volume discount based on total monthly volume. E.g., so on day 1 of the month, you don’t
know if you’ll get that discount or not.
2.3.1) Some discount or credit because maybe there was a ‘bad fill’
and so the broker feels bad and will reduce their monthly fee by a bit in the
hopes of gaining some goodwill.
2.4) So even
if you do accrue the fees during the month, i.e., a hit to the PnL, you’ll most
likely need an adjustment up or down based on the broker fee invoice. i.e., in general, you’ll just pay the amount
they invoice you for.
3.1) A firm
may have several trading desks that all do trades with the same brokers/using
the same broker. E.g., if you have 3
trading desks and the broker fee is $2000, how should you allocate the $2000?
3.1.1) Should you simply divide the bill by the number of trading
desks, so divide by 3? That wouldn’t be
fair if one of the trading desks was far more active, i.e., more trades than
the other one.
3.1.2) Users
may try to prorate the invoice based on volumes during the month. This may not be a perfect method in practice,
but it may be better than simply splitting the cost.
4.1) Often firms may want some way within the CTRM system to
support an easy reconciliation of their trades, i.e., the ones booked in the
CTRM system, to the invoice they get from their broker.
4.2) For
example, if the CTRM system had the theoretically correct default values for
broker fee rates, and calculated an estimated value for the month of $2000 and
if the invoice from the broker is for $10000, then what would a user like to
see to be able to help them reconcile?
Maybe a screen that pulls up all of the trades for the time period,
i.e., typically the calendar month, that is covered by the broker’s invoice.
4.3) This also brings up the concept of marking a set of accrued
broker fees in the system as ‘reconciled’ or paid. i.e., give them some sort of indicator such
that they are explicitly shown to have been tied out against a specific invoice
from the broker. And so won’t be double counted and/or included in any future reconciliation
of a future invoice from the broker versus other trades.
Just a note here the Broker Fees is a different topic than margining. i.e., ‘initial margin’ and ‘variation margin’, which happens for futures contracts.
Introduction to
CTRM
Click on this
link for a great introduction to CTRM software: Introduction to CTRM Software