Jump to content

Welcome to the new Traders Laboratory! Please bear with us as we finish the migration over the next few days. If you find any issues, want to leave feedback, get in touch with us, or offer suggestions please post to the Support forum here.

  • Welcome Guests

    Welcome. You are currently viewing the forum as a guest which does not give you access to all the great features at Traders Laboratory such as interacting with members, access to all forums, downloading attachments, and eligibility to win free giveaways. Registration is fast, simple and absolutely free. Create a FREE Traders Laboratory account here.

O66

Zenfire and DTN Feed Different?

Recommended Posts

Whilst UB contributed some valuable thoughts and insights some of the stuff he wrote, particularly about data feeds, was complete hyperbole. I pulled him on a couple of occasions but did not press the matter as the good stuff far out weighed the more. I always thought it a shame that some one that clearly was well informed with much to contribute on certain topics could talks such nonsense about others.

 

I guess you are talking about things like CQG when you talk of higher end feeds? Probably another good option.

 

From the last few posts it would seem safe to conclude that the problem issue is potentially with any live data feed and infrastructure/capacity limitations. However the original poster suggests that this is not the case and that IQ.Feed matches live and historically. This is odd as Zenfire is fairly highly compressed, it seems to get more ticks in fewer packets so you would expect it to suffer less from data loss. Also your tests would suggest that it matches. Strange.

 

My comments about UB were in relation to the higher end feeds, and their costs, that are available these days.

 

Just to be clear, the Zenfire/Rithmic feed is NOT always matching my DTN.IQ feed since the CME data granularity increase. Some of this imo will not be resolved until Zenfire/Rithmic add a ticker plant type capability.....even when Zenfire/Rithmic send data to a sophisticated user with more than adequate infrastructure, there is still at times data loss so that is not optimal. Backfill with DTN.IQ feed is a must at this point imo for Zenfire/Rithmic feed users who need clean bid/ask data.

Share this post


Link to post
Share on other sites
What is DTN.IQ? Data fee only? Which chart software can use their data?

 

And how is CQG compare to zenfire and DTN.IQ's data completeness/accuracy during real time?

 

CQG has always been known for very robust data feed so their feed should be as good as DTN.IQ feed for bid/ask data work.....also, they provide TFlow volume studies that rely on a proper bid/ask data stream so their feed should be good.

 

CQG TFlow Charts and Studies

Share this post


Link to post
Share on other sites

Just to be clear, the Zenfire/Rithmic feed is NOT always matching my DTN.IQ feed since the CME data granularity increase. Some of this imo will not be resolved until Zenfire/Rithmic add a ticker plant type capability.....even when Zenfire/Rithmic send data to a sophisticated user with more than adequate infrastructure, there is still at times data loss so that is not optimal. Backfill with DTN.IQ feed is a must at this point imo for Zenfire/Rithmic feed users who need clean bid/ask data.

 

Thanks.

I was afraid for this.

Imo Zenfire isnt usable for trading where bidxask info is needed.

(you dont want to backfill every few minutes)

DTN Iq.feed is for now the solution for feeding my IRT charts.

Share this post


Link to post
Share on other sites

after 4.5 hour live feed with Zenfire, chart looks like this:

image 1

 

 

after backfill with DTN:

image2

 

Cumulative delta on image 1 is about 33000

Image 2 is showing 28000 cumulative delta which is less

 

but since im plotting delta here more is not always better.

I assume the backfilled image2 is correct

somewhere during the last 4.5 hours i lost 5000 negative cumulative delta with Zenfire feed

 

I have a dual internet connection (adsl and cable) and am using a dual wan router with fail over.

Of course it is possible that i lost connection for a second but that doesnt explain that other traders at the other end of the world have the same chart (before backfill) in Ninja feeded with zenfire.

 

My conclusion is that it is not my charting package, its not my connection. It must be the feed.

The backfill option for zenfire as mentioned in multicharts forum is interesting

Hopefully it will be available soon so that we can test and compare.

Edited by O66

Share this post


Link to post
Share on other sites

066 -

 

It does seem the only verified and simplistic route to go at this time for Investor RT or Ninjatrader users, that do bid/ask Delta Volume work, is to use DTN.IQ feed. I can see how having to do DTN.IQ feed "backfill" during the day while using Zenfire/Rithmic or TT Fix Adapter feed would be a pain in the butt.

Share this post


Link to post
Share on other sites

Hi,

 

I may not be understanding this issue correctly but will the DTN.IQ feed, real-time feed, not suffer the same issues i.e the problem is the way that continuously changing data is transmitted (UDP). Is it the actual 'backfill' that is resolving the problem.

Share this post


Link to post
Share on other sites
Hi,

 

I may not be understanding this issue correctly but will the DTN.IQ feed, real-time feed, not suffer the same issues i.e the problem is the way that continuously changing data is transmitted (UDP). Is it the actual 'backfill' that is resolving the problem.

 

Correct....DTN.IQ puts out feed in a different way than a typical broker feed and uses built in mechanisms to verify the data flow. My DTN.IQ feed always matches a CME daily run of data....I do not ever have problems with DTN.IQ feed for bid/ask work.

Edited by FulcrumTrader

Share this post


Link to post
Share on other sites
Hi,

 

I may not be understanding this issue correctly but will the DTN.IQ feed, real-time feed, not suffer the same issues i.e the problem is the way that continuously changing data is transmitted (UDP). Is it the actual 'backfill' that is resolving the problem.

 

Correct....DTN.IQ puts out feed in a different way than a typical broker feed and uses built in mechanisms to verify the data flow. My DTN.IQ feed always matches a CME daily run of data....I do not ever have problems with DTN.IQ feed for bid/ask work.

 

Fulcrumtrader, which feed do you use for realtime data?

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
Yes.....I have mentioned before that I have verified DTN.IQ feed.....it is the ONLY regular feed that I use and have been able to verify.

 

I do think that CQG probably has exceptional feed too....Esignal does not have clean bid/ask data last I checked and I am not sure why. Tradestations feed is a mess so I will not even go into that one.....LOL!

 

Anyone trying to use OEC or Transact feed will definitely have to "backfill" imo with DTN.IQ to make sure they have clean bid/ask data runs each day. If you use Investor RT or Marketdelta with DTN.IQ feed you are set up perfect for bid/ask data work.

 

Hi Fulcrum if you have access to CME data could you find out which one is correct/wrong

It have different bid/ask inside bid flag between the two and different total volume.

Left side is Esignal, right side is Zen-Fire both using Ninja trader T&S

 

EsignalvsZenFire09122803am4.PNG

 

Thank you

 

Tony

Share this post


Link to post
Share on other sites

Tony,

 

Sending you a PM....I will just say that it is very odd to me that these data feeds can't get there data output straight. I know DTN.IQ feed spent a bunch of money upgrading their data infrastructure this year, so maybe that is why they are getting it right and others like Esignal have some errors.

Share this post


Link to post
Share on other sites
If I check my DTN.IQ bid/ask run at the end of day it will match an uncoalesced CME run from a more direct source (I will leave it at that).

 

Just out of interest why are you so reticent to mention the data source? The sceptic in me immediately thinks that it may not stand up to scrutiny :). In any case It makes it impossible for anyone to judge the veracity of your claims. I can't help wondering whether the data you used and/or your testing methodology might be flawed (I am not saying it is). For example I have observed inconsistencies with Zen/Gom both pre and post CME changes. From a pretty recent post of yours in the OFA thread you where advising pretty much the same thing about Ninja/Zen as you have with DTN.IQ. "NinjaTrader w/Zenfire is good for CD work"

 

Anyway forgive me for banging on about this but I have often seen damn smart traders show a bit less rigour when it comes to the technical side of things.

Share this post


Link to post
Share on other sites
Just out of interest why are you so reticent to mention the data source? The sceptic in me immediately thinks that it may not stand up to scrutiny :). In any case It makes it impossible for anyone to judge the veracity of your claims. I can't help wondering whether the data you used and/or your testing methodology might be flawed (I am not saying it is). For example I have observed inconsistencies with Zen/Gom both pre and post CME changes. From a pretty recent post of yours in the OFA thread you where advising pretty much the same thing about Ninja/Zen as you have with DTN.IQ. "NinjaTrader w/Zenfire is good for CD work"

 

Anyway forgive me for banging on about this but I have often seen damn smart traders show a bit less rigour when it comes to the technical side of things.

 

Real simple.....DTN.IQ is matching CME data runs and I have NOW FOUND Zenfire/Rithmic feed runs that are NOT matching and that is a problem. I have ALSO since had verified what is causing the Rithmic/Zenfire feed data drops since I was myself using Zenfire feed with my NT charting (for back up and remote trading work). Now I also can't use NT/Zenfire for any CD work which is disappointing to me (hopeful that will get resolved soon with feed enhancements through Zenfire and platform enhancements with NT7...we will see). New FACTS have shown me for the time being I can no longer use NT/Zenfire for any CD work....I will be very happy if this set up can be used again in the future.

 

In the end, do your own due diligence and go through what it takes to verify a feed and find one that you trust. I am not expecting anyone to rely on my info....just putting out the info to make sure everyone is aware of potential problems with the various feeds for those who need CLEAN bid/ask data. :)

Share this post


Link to post
Share on other sites
Real simple.....DTN.IQ is matching CME data runs and I have NOW FOUND Zenfire/Rithmic feed runs that are NOT matching and that is a problem. I have ALSO since had verified what is causing the Rithmic/Zenfire feed data drops since I was myself using Zenfire feed with my NT charting (for back up and remote trading work).

 

You mention you have verified what is causing the issue? Can you share that information?

 

Any chance it's related to something I discovered while using the API... there are cases happening regularly where the data events are coming out of order. I grab the exchange timestamp to store data and since I use a counter just in case I get multiple items with the same timestamp, I discovered the out of order data right away and had to compensate for it. I haven't investigated to see what "damage" it might do to analysis, though.

Share this post


Link to post
Share on other sites
You mention you have verified what is causing the issue? Can you share that information?

 

Any chance it's related to something I discovered while using the API... there are cases happening regularly where the data events are coming out of order. I grab the exchange timestamp to store data and since I use a counter just in case I get multiple items with the same timestamp, I discovered the out of order data right away and had to compensate for it. I haven't investigated to see what "damage" it might do to analysis, though.

Yes you are seeing some of the issues first hand.....what we verified was several issues with both the platform and at times the feed causing data drops. We also detected some data drops with Rithmic connected to Investor RT charting, so there are multiple problems that at anytime can cause these data drops of bid/ask data intraday (with the various broker supplied feeds).

Share this post


Link to post
Share on other sites

Taotree,

I have actually noticed that frequently, the date event time stamps are arriving out of order. I think this is probably related to Zenfire's distribution mechanism. Each packet can take a different path through the internet and since they are only separated by milliseconds during fast action, they could easily arrive out of order. For historical data, I sort everything first.

 

FulcrumTrader, are you still seeing an issue with Zenfire (guess it's only been 10 days)? Below is a capture of the YM on Feb. 2 from Zenfire. Does anyone see what is missing from this data:

 

1265099523474,682000,ASK, 1,10109.0

1265099523845,376000,ASK, 2,10109.0

1265099524369,371000,ASK, 4,10109.0

1265099524577,589000,ASK, 3,10109.0

1265099525936,762000,BID, 3,10108.0

1265099526054,823000,TRADE,1,10109.0

1265099526054,823000,VOLUME,5787,0.0

1265099526054,911000,TRADE,1,10109.0

1265099526054,911000,VOLUME,5788,0.0

1265099526055,410000,TRADE,1,10109.0

1265099526055,410000,VOLUME,5789,0.0

1265099526058,675000,BID, 33,10101.0

1265099526060,252000,ASK, 21,10111.0

1265099526062,987000,TRADE,2,10109.0

1265099526062,987000,VOLUME,5791,0.0

1265099526063,878000,ASK, 18,10110.0

1265099526066,547000,BID, 17,10106.0

1265099526072,51000,BID,2 0,10105.0

1265099526081,717000,ASK, 2,10109.0

 

I can understand how the first 3 trades were executed at 10109.0, but I don't understand how the last 2 trade order was executed at that same level. We know there was an ask of 3 contracts 10109.0 at 1265099524577,589000. The 3 trades would have consumed those asks so it seems that there would be no bid/asks at 10109.0 after the group of 3 trades. There were no updates to 10109.0 so I don't understand how the last trade of 2 contracts could have executed. Here's another example that I posted on:

 

Here's a more concise example:

 

Time(ms),Time(ns),Type,Volume,Price

1265102922624,821000,TRADE,1,10134.0

1265102922624,821000,VOLUME,6744,0.0

1265102922624,821000,BID,0,10134.0

1265102922630,620000,TRADE,1,10134.0

1265102922630,620000,VOLUME,6745,0.0

1265102922631,30000,BID,25,10131.0

 

How did that second trade happen? The line immediately before shows 0 offers at 10134.

 

I spent about two hours looking for a description on Zenfire data reporting format and the closest description I could find was this:

 

Data Directly from the Market Data Platform

 

So I assume that CME sends out updates to bid/ask if they have been affected by new order, trades, or cancellations. Can someone explain the data above to me or has Zenfire started dropping data?

Share this post


Link to post
Share on other sites

Yes.....Rithmic/Zenfire feed is NOT working for proper BID/ASK volume studies. If you do your research and see how thorough DTN.IQ manages and time stamps their feed, you will then see why many of these broker supplied feeds can't touch the capability/reliability of DTN.IQ feed.

 

I do have an update on this feed situation from some recent testing. If you have a very good newer PC with very good internet (cable modem at a minimum) we have a client who is working with NT connected to DTN.IQ feed and he is NOT getting any data drops now. So a trader can then track the GomCD with NT connected to DTN.IQ feed.......the only capability you would not have is historical lookback (like you would have with DTN.IQ feed connected to Investor RT Pro for up to a 4 week backfill). If you wanted historical lookback in NT with DTN.IQ you would need to save your own data which can be done with the GomCD Recorder function. So this was good to see that one of my clients has been able to get NT to work now with DTN.IQ feed for Cumulative Delta tracking......cool!

Share this post


Link to post
Share on other sites

I have not noticed any data drops from zenfire. I have a 20MB connection with a decent ISP not sure if that is considered good nowadays, toying with the idea of upgrading to 50mb can't really justify it beyond bragging rights.

 

A market sell getting matched to a market buy would explain what you observed Snyp.

 

Incidentally looks like Ninja are really dropping the ball on there handling of historic bid ask information. In a nutshell they are not preserving the correct sequence when storing the ifo for historic retrieval. A major blow for this type of analysis. There is a thread here here about it BidAsk Historical... - Page 4 - NinjaTrader Support Forum maybe if enough people 'vote' they may prioritise fixing this issue.

Share this post


Link to post
Share on other sites

I didn't think a market buy could be matched to a market sell. I am a newbie, but are you sure that can happen? I thought market buy order are ALWAYS matched to the best ask price and market sells are always matched to the best bid price. I think this would be the fairest transaction price. Otherwise, if you have a 1 tick spread, one party has to pay the spread and the other does not. For that reason, I don't think market orders are ever matched directly, but let me know if I am wrong. I have been looking for over 5 hours from some documentation from the CME which describes in detail their order matching algorithms. If anyone has this please point me to it.

Share this post


Link to post
Share on other sites
I didn't think a market buy could be matched to a market sell. I am a newbie, but are you sure that can happen? I thought market buy order are ALWAYS matched to the best ask price and market sells are always matched to the best bid price. I think this would be the fairest transaction price. Otherwise, if you have a 1 tick spread, one party has to pay the spread and the other does not. For that reason, I don't think market orders are ever matched directly, but let me know if I am wrong. I have been looking for over 5 hours from some documentation from the CME which describes in detail their order matching algorithms. If anyone has this please point me to it.

 

Now you mention it you might well be correct! As you say what price would they be matched at? I guess a trawl through the CME site might reveal the answer. You do sometimes get ticks between the best bid and best ask. How about a limit sell and a limit buy arriving at the same time and at the same price. It would not be unreasonable to expect them to be matched and filled without being displayed in the order book?

Share this post


Link to post
Share on other sites
Incidentally looks like Ninja are really dropping the ball on there handling of historic bid ask information. In a nutshell they are not preserving the correct sequence when storing the ifo for historic retrieval. A major blow for this type of analysis. There is a thread here here about it BidAsk Historical... - Page 4 - NinjaTrader Support Forum maybe if enough people 'vote' they may prioritise fixing this issue.

I myself just stay away from NT for now for any BID/ASK volume work until I see them enhance their platforms capabilities. Investor RT Pro for only $60 a month is a bargain to me and I can always have solid historical lookback capabilities with DTN feed.

Share this post


Link to post
Share on other sites
Now you mention it you might well be correct! As you say what price would they be matched at? I guess a trawl through the CME site might reveal the answer. You do sometimes get ticks between the best bid and best ask. How about a limit sell and a limit buy arriving at the same time and at the same price. It would not be unreasonable to expect them to be matched and filled without being displayed in the order book?

 

As I mentioned, I spent over 5 hours looking over the CME site and the closest link I could find describing their data messaging format is the one I posted last night. Some of the time was productively spent, I learned more about the futures market, but I am very surprised that a specification describing how market activity (book and trades) is not linked somewhere on the front page of CME and especially Zen-Fire.

 

Can someone send me yesterday's market history (trades, bid/ask, volume) for any of FDAX, ES, YM, or NQ? I can format that datalog in the same format as mine, sort both by timestamp, and then compare to see what's different between the two. It would be great to compare against the DTN feed which is supposed to be superb.

 

Another note, I am not using NinjaTrader. I connect to Zen-Fire and log the data directly using their API. Although I am only monitoring 9 instruments, I have the bandwidth and CPU power to record at least the entire equities futures market. The CPU usage even during peak is negligible, something less than 5%. I am not sure if Zen-Fire uses UDP or TCP for their packet transmission protocol. Again, would be nice to have this someplace on their website. For those who don't have a background in data networks, UDP requires much less bandwidth compared to TCP. However, UDP can drop packets. I don't know if that's what's happening which is why I would like to compare against another feed. If someone can send me another datafeed history, even 1 hour of data during peak should be sufficient, I promise to post my findings here. I would also be happy to post a diff of the two datalogs.

 

How about a limit sell and a limit buy arriving at the same time and at the same price. It would not be unreasonable to expect them to be matched and filled without being displayed in the order book?

 

I believe these limit orders will still show up on the books. They may or may not get executed against one another depending on their price levels. The market is fair and will give each order the best available execution price. For a buy order, this will be the best current ASK price and for a sell order, this will be the best current bid price. Let's say the sell order comes in with the limit price set at the current ASK price. Then that sell order will go to the back of the best ask queue and will not get executed unless the other buy limit order is large enough to consume the entire best ask queue. The buy order obeys the same rules. However, if the buy order limit price is better than the current best bid, then it will get at least partially executed (may not get fully executed if it's the case that there are not enough orders on the ask at prices less than or equal to the limit price on the buy order). Obviously, if the new limit buy and new limit sell orders did not have overlapping or equal prices, then they would not get executed against each other. So I am pretty sure that all limit orders cause an update to the market books, but please correct me if I am wrong.

 

Another interesting case that could happen (but I don't think it does) would be if 2 market orders came into the market at the same time and the order quantity happened to be both equal and also an even number. In this case, the exchange could execute half of the transaction at the best bid price and half of the transaction at the best ask price. The execution price would average to directly in the middle between the best bid and best ask price and would be the fairest price to both parties. I don't think they do this because CME claims to match orders in less than 7 ms. Timestamp resolution must be somewhere in the microsecond range and it's probably very rare that two matching orders hit the market at exactly the same time. Seems like an interesting tradeoff between execution time and execution price.

Share this post


Link to post
Share on other sites

I believe these limit orders will still show up on the books. They may or may not get executed against one another depending on their price levels.

 

I think they probably will if they are at the same price. For example 17 1/4 bid 17 3/4 asked if a limit order to buy 1 @ 17 1/2 and a limit order to sell 1 @ 17 1/2 came in at the same time they would be matched and filled. In the early days of electronic exchanges surprisingly few supported more than a couple of basic order types. Often a market order would be converted to a limit order well inside the market. I guess things are more sophisticated nowadays.

 

In your example if a limit buy and a limit sell both at 10109 both arriving simultaneously they would simply be matched and reported as trade @ 10109? If they where put on the book it would essentially be crossed with best bid 10109 and best ask 10109? Thats my guess anyway.

 

FT you are probably right about NT, currently it is a square peg and we have a round hole. I am getting some promising results with Zen and Multicharts though I need to do some further tests (purposely overloading MC) to be sure.With MC DTN.IQ is an option too.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Topics

  • Posts

    • Date: 22nd November 2024.   BTC flirts with $100K, Stocks higher, Eurozone PMI signals recession risk.   Asia & European Sessions:   Geopolitical risks are back in the spotlight on fears of escalation in the Ukraine-Russia after Russia reportedly used a new ICBM to retaliate against Ukraine’s use of US and UK made missiles to attack inside Russia. The markets continue to assess the election results as President-elect Trump fills in his cabinet choices, with the key Treasury Secretary spot still open. The Fed’s rate path continues to be debated with a -25 bp December cut seen as 50-50. Earnings season is coming to an end after mixed reports, though AI remains a major driver. Profit taking and rebalancing into year-end are adding to gyrations too. Wall Street rallied, led by the Dow’s 1.06% broadbased pop. The S&P500 advanced 0.53% and the NASDAQ inched up 0.03%. Asian stocks rose after  Nvidia’s rally. Nikkei added 1% to 38,415.32 after the Tokyo inflation data slowed to 2.3% in October from 2.5% in the prior month, reaching its lowest level since January. The rally was also supported by chip-related stocks tracked Nvidia. Overnight-indexed swaps indicate that it’s certain the Reserve Bank of New Zealand will cut its policy rate by 50 basis points on Nov. 27, with a 22% chance of a 75 basis points reduction. European stocks futures climbed even though German Q3 GDP growth revised down to 0.1% q/q from the 0.2% q/q reported initially. Cryptocurrency market has gained approximately $1 trillion since Trump’s victory in the Nov. 5 election. Recent announcement for the SEC boosted cryptos. Chair Gary Gensler will step down on January 20, the day Trump is set to be inaugurated. Gensler has pushed for more protections for crypto investors. MicroStrategy Inc.’s plans to accelerate purchases of the token, and the debut of options on US Bitcoin ETFs also support this rally. Trump’s transition team has begun discussions on the possibility of creating a new White House position focused on digital asset policy.     Financial Markets Performance: The US Dollar recovered overnight and closed at 107.00. Bitcoin currently at 99,300,  flirting with a run toward the 100,000 level. The EURUSD drifts below 1.05, the GBPUSD dips to June’s bottom at 1.2570, while USDJPY rebounded to 154.94. The AUDNZD spiked to 2-year highs amid speculation the RBNZ will cut the official cash rate by more than 50 bps next week. Oil surged 2.12% to $70.46. Gold spiked to 2,697 after escalation alerts between Russia and Ukraine. Heightened geopolitical tensions drove investors toward safe-haven assets. Gold has surged by 30% this year. Haven demand balanced out the pressure from a strong USD following mixed US labor data. Silver rose 0.9% to 31.38, while palladium increased by 0.9% to 1,040.85 per ounce. Platinum remained unchanged. Always trade with strict risk management. Your capital is the single most important aspect of your trading business.   Please note that times displayed based on local time zone and are from time of writing this report.   Click HERE to access the full HFM Economic calendar.   Want to learn to trade and analyse the markets? Join our webinars and get analysis and trading ideas combined with better understanding of how markets work. Click HERE to register for FREE!   Click HERE to READ more Market news. Andria Pichidi HFMarkets Disclaimer: This material is provided as a general marketing communication for information purposes only and does not constitute an independent investment research. Nothing in this communication contains, or should be considered as containing, an investment advice or an investment recommendation or a solicitation for the purpose of buying or selling of any financial instrument. All information provided is gathered from reputable sources and any information containing an indication of past performance is not a guarantee or reliable indicator of future performance. Users acknowledge that any investment in FX and CFDs products is characterized by a certain degree of uncertainty and that any investment of this nature involves a high level of risk for which the users are solely responsible and liable. We assume no liability for any loss arising from any investment made based on the information provided in this communication. This communication must not be reproduced or further distributed without our prior written permission.
    • A few trending stocks at support BAM MNKD RBBN at https://stockconsultant.com/?MNKD
    • BMBL Bumble stock watch, pull back to 7.94 support area with high trade quality at https://stockconsultant.com/?BMBL
    • LUMN Lumen Technologies stock watch, pull back to 7.43 support area with bullish indicators at https://stockconsultant.com/?LUMN
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.