基于基本数据的交易算法 [英] Fundamental data based trading algorithms
问题描述
Q1:是否有可能创建一个脚本/算法，该脚本/算法将纯粹放置所选货币对的买入或卖出顺序，取决于是否利率公告是否高于(或低于)预测数字?
我知道在买卖金融工具之前必须考虑许多其他技术和基本因素，但纯粹是作为实验，我想确定这种方法是否可行.
如果可以实现，
Q2:如何将利率公告直接嵌入到脚本中，以便一旦发布该数字，买入 或 卖出命令是否立即执行?
注意:这只会在模拟交易账户上使用.
先前基于基本数据价格反应执行头寸的替代尝试:
- 在宣布利率之前，自动设置买入 和 卖出订单，并允许价格大幅上下波动自动打开头寸的一个方向(此缺点是头寸通常开得太晚).
A1: IF ...是的，它是:
这个想法是可行的，但是由于一些外部因素，它对代码无法控制的因素非常敏感.
网络传输延迟不是您的最大敌人.这些占一些 0.1 - 200 ms ，具体取决于您尝试从哪个位置(通过哪些连接/服务)来获取一些远程/远程信息并在本地进行处理.对于主机托管，这将在此间隔的较短端，对于COTS办公设备，则将在较长的一端.
基于应用程序的事务处理等待时间是下一个更危险的等待时间.每个XTO事务都不会在零时间发生.通常，定期地记录/监视各自的延迟(等待时间)，以便为各自的市场准入代理/经纪人办公室提供体内等待时间包络.
数字各不相同，
在黑天鹅事件期间
或在高交易负载期间/XTO-，它们的过度放松
也以几个数量级的顺序变化交通风暴.
虚假蔓延爆炸
是最糟糕的，
在很多情况下仍被隐藏
，
敌人.
如前所述，在基本面新闻公告中，您会感觉到时间，但隐藏的危险不是线性时间滴答，而是价差的爆炸式增长，即PriceDOMAIN区域，没有人可以进行/执行交易( XTO )，或者如果在这段时间内有股票暴露于市场风险，则任何人都必须进行爆炸的交易者保证金攻击.
翻译成普通的英语-基本上没有人可以在美国NFP和类似的地震新闻公告之后点击及时"按钮. >
嵌入不是正确的表达方式，您的算法交易将必须成为分布式处理系统的一部分，而该系统将完全构成交易基础结构. 市场数据馈送-将报价流更新传递到您的本地处理程序 用于获取News Feed数据的技术手段通常基于/取决于代理商的商业产品/API规范.虽然是常见的外汇交易平台之一， MetaTrader终端确实提供了由经纪人提供的新闻服务，但人们迟早会意识到，等待经纪人重新发布新闻是双刃剑一把剑，因为如果您的经纪人/他们的风险管理控制部门以相对"仓位进行交易，那么他们就具有延迟发布的不公平优势，而没有任何相关风险，而对于拥有交易员的交易者而言，这并不能平衡为同样公平的决策位置股票所承受的市场风险.接下来，您的算法工具没有新闻阅读API/接口，一旦将其传递到 MetaTrader Terminal 的本地主机域中，就可以完全完全地处理这些事件，因此无论哪种情况，您都将依赖于外部新闻流处理器，如果是 MetaTrader终端 话虽如此，您的交易策略可以与News Feed配合并根据自动发布的内容执行决策(通常比获取/评估/(延迟)/重新处理/重新发布同一公告后要快通过其他三级处理器发布). 关键是可行的 市场不会等待单个[ms] ，请参阅
此示例性示例仍然非常出色，因为仅更改了
祝你好运&
A2: HOW ...该算法将与新闻提供者通信
市场准入-您放置/取消XTO说明的位置
新闻摘要-您从中获取宏观经济新闻的地方MQL4-代码以分布式系统的方式，则与您的代码进行通信.XTO&故障补救策略，可以逃避时间陷阱和爆炸式传播陷阱.
FIX-Protocol API 详细信息，以了解多少百万个EUR 计价价值已在新闻公告的标称时间正好之前从L2-DoM中删除了 47 ms:出价铅笔，而间隙的Ask侧边缘很难被看到，除非发生了如上所述的特殊情况)
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
)
EUR/USD 到NFP之前的公告战场的 4 项.对变化密度" 进行了定量的实证观察后，随函附上LDF()数据的集合，该数据有关之间的 FIX 消息数量10..380 aMarketDataUpdateACTION 单位:
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 >
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 ).
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!
这篇关于基于基本数据的交易算法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
