Fully automated futures trading

Hmmm, that is strange. I have a software tool to get an overview of the available contracts. I use this tool when selecting the next contract to rollover into. I ran it for all three versions of DAX (multiplier 1, 5, and 25) futures. In all cases I only get the contracts that expire each quarter (March, June, September, December). When requesting available contract details I provide exchange (EUREX), symbol (DAX), currency (EUR), security type (FUT) and local class (FDAX, FDXM, FDXS). I get none of the weekly expiring contracts with this.

So looks like some(most?) instruments (like Dax40) have different Local Class property for monthly and weekly that allows to filter out weekly contracts without providing LocalName. Then the problem is only to find all EUREX contracts (in addition to M1MS) which have the same local class for weekly and monthly\quarterly expirations. I'm pretty sure that my system would already be screaming about missing EOD prices if there were problems with any other contracts, I'm only trading these from EUREX: ESTX50, V2TX, BTP, OAT, GBM, GBL, SMI, BTS, FBON, M1MS, DJSD, SX3P, SXEP, SXTP, SXDP, SX8P, SXPP, SXAP, SXRP, SX7E, DAX, GBX
 
So looks like some(most?) instruments (like Dax40) have different Local Class property for monthly and weekly that allows to filter out weekly contracts without providing LocalName. Then the problem is only to find all EUREX contracts (in addition to M1MS) which have the same local class for weekly and monthly\quarterly expirations. I'm pretty sure that my system would already be screaming about missing EOD prices if there were problems with any other contracts, I'm only trading these from EUREX: ESTX50, V2TX, BTP, OAT, GBM, GBL, SMI, BTS, FBON, M1MS, DJSD, SX3P, SXEP, SXTP, SXDP, SX8P, SXPP, SXAP, SXRP, SX7E, DAX, GBX

Always check with every contract what type of naming system it uses for local name. I had to change code a few months ago just for FDXS monthly contract, so that it now uses "Symbol + Third friday of expiration month + M".
 
So looks like some(most?) instruments (like Dax40) have different Local Class property for monthly and weekly that allows to filter out weekly contracts without providing LocalName. Then the problem is only to find all EUREX contracts (in addition to M1MS) which have the same local class for weekly and monthly\quarterly expirations. I'm pretty sure that my system would already be screaming about missing EOD prices if there were problems with any other contracts, I'm only trading these from EUREX: ESTX50, V2TX, BTP, OAT, GBM, GBL, SMI, BTS, FBON, M1MS, DJSD, SX3P, SXEP, SXTP, SXDP, SX8P, SXPP, SXAP, SXRP, SX7E, DAX, GBX
So apparently I got lucky: I don't use Local Name at all, but only use Local Class when searching for an appropriate contract. The EUREX instruments I use all seem to have a different local class name for monthly/quarterly expirations than for the weekly ones. No mix-up between quarterly and weekly contracts is happening. Once an appropriate contract has been found its conid gets recorded in a file and from then on only this conid is being used in my software. The EUREX instruments from your list which I use are: ESTX50 (2x), V2TX, GBM, GBL, DAX (3x), GBX, plus additionally GBS and DJ600.
 
Let's say there are all essentially the same contract size. Would it be a good idea, then?
As a first shot: yes. And then let your system run for a couple of days/weeks and see how your position sizes develop. And thus how much you would actually need in cash to fulfill margin requirements.
 
Looks like this old potential problem has just materialized: I noticed that my system hasn't been able to retrieve EOD prices for 'M1MS' exp: Jun 2023 (a EUREX Emerging markets contract) since May 25, I'm getting "The contract description specified for M1MS is ambiguous; you must specify the multiplier or trading class." and upon checking we now have 6! contracts expiring in June, and they all have the same Trading Class 'FMEA'. The multiplier is also the same.
The only "usable" difference I can see between the normal monthly contract and all these other (daily?) ones is in the "Local Name" property, which is "FMEA JUN 23" for the monthly and something like "FMEA 20230605 D" for the other ones. I really don't want to provide the exact expiration date in 'LastTradeDateOrContractMonth' because I don't always know it precisely, e.g. for this contract according to the spec it's 3-rd Friday, which is June 16, but this time it's "19/06/2023", maybe because it goes my settlement day, which is the next exchange day.. In any case, it's a pain trying to figure out the exact exp days..

I Just tried temporary hardcoding contract.LocalSymbol = "FMEA JUN 23"; for the current contract and it worked, so looks like I can get away with knowing the exp month only not the day..
Now I need to figure out how to modify my system to populate it... Ohh.. why??!! :)

I wander what other EUREX contracts have this issue now.. Well, I guess I'll wait and see until something else breaks in the system :)

Users of psystemtrade - this problem now fixed for the two contracts where it has affected me (local names MSCIWORLD, MSCIASIA).

Rob
 
Automated trading is no less time intensive than discretionary trading, the only difference is you sit in front of a computer coding instead of in front of a screen monitoring, if you think it's set and forget it doesn't go well.

That's why we have automated arbitrage that produces much better results which people layer their bots over (hedge funds and students being mentored), the results are more stable and quite spectacular like this.

Screenshot 2023-05-26 at 08.59.08.png


I can already tell you that your any other solution results will be losses equal profits hoping for a large profitable trade, except you will have a large loss trade, your loss trades must be 10x smaller than your profit trades which is what our arb does.
 
Last edited:
Automated trading is no less time intensive than discretionary trading, the only difference is you sit in front of a computer coding instead of in front of a screen monitoring, if you think it's set and forget it doesn't go well.

That's why we have automated arbitrage that produces much better results which people layer their bots over (hedge funds and being mentored), the results are more stable and quite spectacular.

Piss off and type your nonsense on another thread.

Please.

Rob
 
As a first shot: yes. And then let your system run for a couple of days/weeks and see how your position sizes develop. And thus how much you would actually need in cash to fulfill margin requirements.

Okay, will do, thanks all.

By the way I just noticed this on the IB page where they brag about paying interest on your excess cash: "Please note that interest is earned on positive settled cash balances held in the securities segment of an account but not on cash held in the commodities segment."
(https://www.interactivebrokers.com/en/accounts/fees/pricing-interest-rates.php)

Does this mean that my excess cash in my futures account will lose out on this 4% interest?
 
By the way I just noticed this on the IB page where they brag about paying interest on your excess cash: "Please note that interest is earned on positive settled cash balances held in the securities segment of an account but not on cash held in the commodities segment."
(https://www.interactivebrokers.com/en/accounts/fees/pricing-interest-rates.php)

Does this mean that my excess cash in my futures account will lose out on this 4% interest?
If that question is directed to me: I might be insufficiently qualified to answer that. Your IB account consists, under the hood, of two segments: securities and commodities. IB has some mechanism in place to daily sweep cash balances from one to the other. This has to do with your margin requirements in each of those segments. I do not know in detail how this sweeping works, and what the impact is on the debit/credit interest on the cash positions. It is one of the things I don't calculate myself, but simply accept what IB prints on the monthly overviews they send me.
 
Back
Top