问题
Q1: Is it possible to create a script/algorithm that will purely place a BUY or SELL order of a selected currency pair, depending on whether e.g. an interest rate announcement is higher ( or lower ) than the forecast figure?
I know many other technical and fundamental factors must be taken in to account before buying and selling financial instruments, but purely as an experiment I'd like to determine if this method is possible.
If this can be achieved,Q2: how can an interest rate announcement be embedded straight in to a script, so that once the figure has been released the BUY or SELL order is immediately executed?
Note: This will only be used on a demo trading account.
Previous alternative attempts to execute positions based on a fundamental data price reaction:
- Setting up an automatic BUY and SELL orders, just before an interest rate announcement, and allowing a significant up or down price movement in one direction to automatically open a position ( the disadvantage with this is that the position is usually opened too late ).
回答1:
A1: IF ... Yes, it is:
The idea is doable, however several externalities make it very sensitive to factors out of the scope your code can control.
Network transport latencies are not your worst enemy. These account for some 0.1 - 200 ms, depending from which location ( over which connectivity / services ) you try to source some remote / distant information and process them locally. For colocated hosting, this would be on the shorter end of this interval, for COTS office equipment this would be on the longer end.
Application-based transaction processing latencies are the next, more dangerous ones. Every XTO transaction is not happening in zero-time. The respective delays ( latencies ) are typically regularly recorded / monitored so as to have a in-vivo latency envelope for respective Market Access Agent / Broker Office.
Figures vary,
so does their over-relaxation
in the order of several orders of magnitude during Black-Swan event periods
or under high transactional load periods / XTO-traffic-storms.
Spurious spread explosions
are your worst,
while still hidden
from many views,
enemy.
On Fundamental News announcement, as you have reported above, you feel the time, but the hidden danger is not the linear time ticks, but the explosion of spread, i.e. the PriceDOMAIN area, where no-one can place / execute a trade ( an XTO ) to be filled, or a an explosed Trader's Margin Attack anybody has to carry, if there is an Equity exposed to a market risk during such period of time.
Translated into a plain english - no-one is principally able to click a button "in-time" after a US NFP and similarly seismic News announcement.
A2: HOW ... The algorithm will communicate with the news provider
The embedding is not the right expression, your algo-trading will have to become a part of a distributed-processing system, that altogether will form the trading-infrastructure.
Market Data Feed -- which delivers quote-stream updates to your local processing
Market Access -- where you place / cancel your XTO instructions
News Feed -- where you source macro-econ news from
Technical means used for sourcing News Feed's data are typically based / dependent on the agency commercial offerings / API specifications. While one of common FOREX trading platforms, the MetaTrader Terminal does offer a News service, mediated from Broker, one shall sooner or later realise that waiting for a Broker to re-publish the news is a dual-edged sword, because if your Broker / their Risk Management Control trades "against" one's positions, they have an unfair advantage of delayed announcement without any associated risk, which is not balanced into an equally fair, decision-making position for traders, who have their equity exposed to market risk. Next, your algorithmic tools have no News-reading API/interface to handle these events fully agorithmically once delivered into your localhost realm of MetaTrader Terminal so you will in either case remain dependent on external news-stream processor, that communicates with your code, in case of MetaTrader Terminal the MQL4-code in a distributed-system manner.
Having this said, your algo-trading strategy can cooperate with News Feed and execute decisions based on the content, published automatically ( typically faster than after the same announcement got fetched / evaluated / ( delayed ) / re-processed / re-published via other tertiary processors ).
The key in this is a viable XTO & failure-remedies strategy, to escape both the time-trap and the exploded spread-trap.
The Market does not wait a single [ms] see the
FIX-Protocol APIdetails on how many millions ofEURdenominated value has been removed fromL2-DoMjust some47 msright before a nominal time of a News announcement: so this is a look into a microscope, how such gigantic holes appear in the PriceDOMAIN map ( painted by a Bid-pencil, whereas the Ask-side edge of the gap is not so easily visible, unless an extraordinary case happens as illustrated above )
14:29:59,953 <121402 MarketDataIncrementalRefresh (8=FIX.4.29=31135=X34=12140249=***52=20131206-13:29:51.55156=*****************62=20131206-12:37:09.000268=4279=0269=0278=264655=EUR/USD270=1.3654115=EUR271=2000000346=1279=2269=0278=265055=EUR/USD15=EUR279=0269=1278=265555=EUR/USD270=1.365615=EUR271=2000000346=1279=2269=1278=267755=EUR/USD15=EUR10=217)
|-------------------------------------------------(
8=FIX.4.2 ________FIX.8.BeginString .aMessageHeaderBEGIN________________________________________<<HEADER>>
9=311 FIX.9.BodyLength .aMessageBodyLENGTH
35=X FIX.35.MsgType .aTypeOfMESSAGE
34=121402 FIX.34.MsgSeqNum .aMessageSeqNUMBER 121402
49=*** FIX.49.SenderCompID .aSenderHostID
52=20131206-13:29:51.551 FIX.52.SendingTime .aSenderTimeSTAMP 20131206-13:29:51.551
56=************* FIX.56.TargetCompID .aTargetHOST
________________________________________________________________________________________________<<HEADER>>
262=20131206-12:37:09.000 FIX.262.MDReqID .aMarketDataRqstUUID 20131206-12:37:09.000 asString .aMarketDataRqstUUID
-----------------------------------------------------------------[*]----------------------------------------------
268=4 FIX.268.NoMDEntries .aMarketDataEntriesNUMBER 4
-----------------------------------------------------------------[1]----------------------------------------------
279=0 FIX.279.MDUpdateAction .aMarketDataUpdateACTION 0 { 0: New, 1: Change, 2: Delete }
269=0 FIX.269.MDEntryType .aMarketDataEntryTYPE 0 { 0: Bid, 1: Offer, 2: Trade, 3: IndexVALUE, 4: aPriceOPEN, 5: aPriceCLOSE, 6: aPriceOfSETTLEMENT, 7: aTradingSessionPriceHIGH, 8: aTradingSessionPriceLOW, 9: aTradingSessionPriceVWAP }
278=2646 FIX.278.MDEntryID .aMarketDataEntryUUID 2646
55=EUR/USD FIX.55.Symbol .aSYMBOL EUR/USD
270=1.36541 FIX.270.MDEntryPx .aMarketDataEntryPRICE 1.36541
15=EUR FIX.15.Currency .anExplicitlyStatedCURRENCY EUR
271=2000000 FIX.271.MDEntrySize .aMarketDataEntrySIZE 2.000.000 UoM/pieces
346=1 FIX.346.NumberOfOrders .aMarketDataEntryNumberOfORDERs 1
-----------------------------------------------------------------[2]----------------------------------------------
279=2 FIX.279.MDUpdateAction .aMarketDataUpdateACTION 2 {} 2: Delete
269=0 FIX.269 . 0 {} 0: Bid
278=2650 FIX.278 . 2650
55=EUR/USD FIX.55 . EUR/USD
15=EUR FIX.15 . EUR
-----------------------------------------------------------------[3]----------------------------------------------
279=0 FIX.279 . 0 {} 0: New
269=1 FIX.269 . 1 {} 1: Ask/Offer
278=2655 FIX.278 . 2655
55=EUR/USD FIX.55 . EUR/USD
270=1.3656 FIX.270 . 1.36560
15=EUR FIX.15 . EUR
271=2000000 FIX.271 . 2.000.000 UoM/pieces
346=1 FIX.346 . 1
-----------------------------------------------------------------[4]----------------------------------------------
279=2 FIX.279 . 2 {} 2: Delete
269=1 FIX.269 . 1 {} 1: Ask/Offer
278=2677 FIX.278 . 2677
55=EUR/USD FIX.55 . EUR/USD
15=EUR FIX.15 . EUR
10=217 ________FIX.10.CheckSum______________________________________<<TRAILER>> aTripleBYTE, asChar, ALGO ref. below
)
This illustrative sample was still quite exceptional for having just
4items that have changed theEUR/USDpre-NFPannouncement battle-field. Having done some quantitative empirical observations on "density of changes", enclosed you have a collection ofLDF()data about how manyFIX-messages contain between10..380aMarketDataUpdateACTIONunits:
max. value in FIX.268 ...== FIX.268.NoMDEntries .aMarketDataEntriesNUMBER
|
1: 38774 x, i.e. ~< 10 .. 19 > FIX.268.NoMDEntries per one FIX-Message delivered
2: 64764 x, i.e. ~< 20 .. 29 >
3: 27805 x, i.e. ~< 30 .. 39 >
4: 41307 x, i.e. ~< 40 .. 49 >
5: 17182 x, i.e. ~< 50 .. 59 >
6: 13640 x, i.e. ~< 60 .. 69 >
7: 5914 x, i.e. ~< 70 .. 79 >
8: 6544 x, i.e. ~< 80 .. 89 >
9: 3205 x, i.e. ~< 90 .. 99 >
10: 3150 x, i.e. ~< 100 .. 109 >
11: 1767 x, i.e. ~< 110 .. 119 >
12: 1432 x, i.e. ~< 120 .. 129 >
13: 1120 x, i.e. ~< 130 .. 139 >
14: 794 x, i.e. ~< 140 .. 149 >
15: 792 x, i.e. ~< 150 .. 159 >
16: 748 x, i.e. ~< 160 .. 169 >
17: 636 x, i.e. ~< 170 .. 179 >
18: 589 x, i.e. ~< 180 .. 189 >
19: 545 x, i.e. ~< 190 .. 199 >
20: 503 x, i.e. ~< 200 .. 209 >
21: 453 x, i.e. ~< 210 .. 219 >
22: 422 x, i.e. ~< 220 .. 229 >
23: 400 x, i.e. ~< 230 .. 239 >
24: 354 x, i.e. ~< 240 .. 249 >
25: 231 x, i.e. ~< 250 .. 259 >
26: 489 x, i.e. ~< 260 .. 269 >
27: 168 x, i.e. ~< 270 .. 279 >
28: 144 x i.e. ~< 280 .. 289 >
29: 48 x, i.e. ~< 290 .. 299 >
30: 42 x, i.e. ~< 300 .. 309 >
31: 16 x, i.e. ~< 310 .. 319 >
32: 6 x, i.e. ~< 320 .. 329 >
33: 8 x, i.e. ~< 330 .. 339 >
34: 5 x, i.e. ~< 340 .. 349 >
35: 2 x, i.e. ~< 350 .. 359 >
36: 4 x, i.e. ~< 360 .. 369 >
37: 1 x i.e. ~< 370 .. 379 >
Good luck & aim well
on this
ultimately thrilling hunt!
来源：https://stackoverflow.com/questions/37551664/fundamental-data-based-trading-algorithms