+1 888 340 6572
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
bug_report_small.png
Open Bug report MC-1872

bid/ask miss-interpretation, making volume-delta charts unreliable

action_vote_minus_faded.png
1
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

It seems the tick chart distinguishes bid sales vs ask sales from the price alone. Price ticks down, it's a bid sale, price ticks up, it's an ask sale. One use-case has not been foreseen though:
Scenario 1:
ASK
Time T: Sale_at_Price_A BID

In this case it Sale_at_Price_A is an order hitting the BID. We know this from the order-flow. However, Multicharts disregards the order-flow (that might be available in the data-feed) and it knows this transaction is a BID only from the previous Trade price, which happened to be above Price_A.
Let's assume for some reason, the data-feed skips a trade that happened at Time: T+1, and now we're at T+2:

Scenario 2:
Time T+2: Sale_at_Price_A ASK
BID

What happened at T+1 (which Multicharts did not see) was price ticked down & came up again to Price_A. Multicharts did not see it, and it treats this trade as an order hitting the BID (as trade-price remained the same for Multicharts) although it is clear, this was an order hitting the ASK.

This should not happen if Multicharts would take into consideration the BID/ASK prices, or process the AtBidOrAsk column.

Steps to reproduce this issue

steps to reproduce:
1) Load into an tick symbol (@EU#C - symbol loaded first from IQFeed) the attached sample data-file, which was obtained from IQFeed through QCollector.
2) Look into the file, and verify that bar number 29 shown in the attached picture is a trade hitting the BID, not the ASK, as seen from the 15th Column, called AtBidOrAsk.
3) Check the MC graph, picture (cumulative-delta.png - attached), bar 29 will be taken into consideration as by Multichart's Cumulative Delta's function as a sale hitting the ask - which is completely false. This WILL create a completely false view of the Cumulative Delta.

I think the Application needs to use a custom method of differenciating between bid and ask price. Possible solution would be to read the Bid/Ask prices, or read the AtBidOrAsk column, as taking only PRICE alone into consideration for this, is plain unreliable.

thanks

Comments (1)
#1
user-offline.png  Alex MultiCharts (Alex MultiCharts)
Jun 12, 2017 - 06:25
  1. Firstly, IQFeed as a data provider marks the prices as Ask or Bid and sends this data through the API to MC. When IQFeed is used as a data provider in MultiCharts, then nothing is calculated in MC.
  2. Not IQFeed, but ASCII Mapping is used in MultiCharts in the reported case.
  3. To calculate the price status from another data feed, it is required to use 3 data series: Ask, Bid, Trade.
  4. If in ASCII file you have only Trade data, then it is not possible to get correct Ask/Bid Traded calculation, but Up/Down Tick algorithm will be used, and that could be seen from the provided screenshot Cumulative-Delta.PNG. No matter what is selected in the chart settings, Up Ticks vs Down Ticks or Ask Traded vs Bid Traded, if you have only 1 series, it will always be calculated using Up Ticks vs Down Ticks.
  5. To have Ask Traded vs Bid Traded algorithms used, it is necessary to have Ask and Bid data for the instrument, according to sample-tick-data-file.txt.
History
Issue basics
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (2)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Reproducability
    Not determined
  • Severity
    Critical
Attachments (1)
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates