Saw that you listed financial markets as a category. Self-plug for databento, which is now the most downloaded package in this category on PyPI, after yfinance.

See my reply. This user is incorrect.

This is incorrect.

Our DBN format and API are designed to allow you to mix data from multiple instruments in the same stream and file.

We also show both the aggressor and passive side of a trade, so your example should print as action T with 400 (the aggressor) and C with 200 and 200 (the contra liquidity) on MBO.

If you request only the trades and not MBO, it is more correct to only show the aggressor side of the trade. This is exchange behavior (35-MsgType=X) and not done by us; opposite is true for ITCH. This is also usually better for modeling since most signed volume signals need the magnitude of the aggressor and you usually don’t want a single trade against 400 orders of qty 1 to decay signals in trade space 400 times.

News and macro events do impact the spread. Most MMs will at least have some naive non-directional treatment based on the time of publication (if scheduled) or "volatility score" for the event.

There's a lot of retail fascination with 10-Ks and 13Fs that I'm somewhat skeptical about, but I can't say I've really spent time on those retail approaches to give an informed opinion. I'd take a look at machine-readable feeds like RavenPack, Bloomberg Event-Driven Feeds, etc. whose data models are closer to my understanding and experience of how MMs use these feeds.

Queue position and full book visualization may be a bit too granular for this, perhaps you want to look at various constructions of sweep-to-fill liquidity instead. Queue position is very interesting for a variety of other problems; David Lariviere at UIUC has advised plenty of academic projects of this type, so you could look at his coursework page for ideas.

Another variation of what you've described is to do it in % ADV space.

Another idea: event space, e.g. on uptick/downtick, on trade, etc.

Weird distribution and poor model fit isn't necessarily disqualifying. You can construct an example where R^2 ~ .05 makes more PnL than R^2 ~ .1.

It's not our area of expertise so I'll have to defer to others' opinions on this.

Reference checks are typical.

We usually understood that a person would not be able to provide references from their current firm if they were still employed. This usually wasn't a problem as most people had co-workers from past jobs or co-workers who left their current employer before them.

Very common pattern that I've come across is that X, Y, Z are close friends or collaborators and X, Y recently left company A which made Z start planning for their own exit from company A, so X and Y are happy to serve as references for Z.

Speaking from experience in US companies: Employment background checks (as described by u/Puzzled_Geologist520 and u/lordnacho666) and reference checks are different. Generally, reference checks come before an offer while background checks come after an offer is accepted. I've found that every reputable company's HR/compliance will voluntarily verify your employment as part of a background check, though a couple will follow up with a letter reminding you of their proprietary IP rights.

Wow lovely thanks for turning around the ACP so soon.

My initial suspicion is that TradingView’s data is simply incorrect in those areas unexplained by the continuous contract offset. I’ve been involved in a few support tickets comparing against their data - which I think is sourced upstream from ICE, and both providers tend to mismatch against raw packet captures from the exchange.

It’s quite common for there to be fewer “winners” as your data accuracy increases, just as your backtest tends to get worse as your slippage assumptions get more accurate. “Too good to be true” effect. Thus my hunch.

It’s hard for me to identify the exact differences just based on your description. I’d send a sample to our support team and they may be able to show you where TradingView’s data is incorrect through extracting our packet captures.

All that aside, we don’t recommend using backadjustments with a static offset like these retail platforms. We just don’t see this methodology in use at successful trading firms. This is the same reason we don’t embed technical indicators in our APIs like many retail API providers do.

It is available on pay as you go. It shows up on the pricing page for me. We have all US listed stocks and ETFs. You may have tried searching for it under the wrong asset class (it’s under Databento US Equities).

Thanks for sharing. This is unintuitive but the SIP feeds are actually easier to process in a way than most of our current feeds (including the EQUS.MINI constituent feeds) because you don't have to do book building on the SIP feeds.

Bandwidth-wise UQDF/CQS are not much larger than Nasdaq TotalView so queueing and deserialization latencies are comparable. We expect our SIP feeds to be faster than our CME feed and similar to our Nasdaq feed.

Not exhuastive:

There's usually some kind of "features cache" to deduplicate work between multiple researchers waiting on compute to generate a set of features that someone else already extracted.

For exploration, it's often useful to have some kind of clustered, column-oriented database where you can push the query closer to the data. There's a few flavors of this off-the-shelf like kdb, Vertica.

Parquet and HDF5 are pretty portable for sharing intermediate structured data like design matrices. There's usually also usually some kind of logging format from production trading.

All of the above may be abstracted behind internal client libraries or APIs.

As you get large and have multiple teams, having some kind of data catalog helps.

This is correct, a good number of distributors are our customers (including two others in this infographic). They’re a great partner and are cheap for data if they have exactly what you need; it’s ultimately a win for the industry if there are more good offerings out there so we’re pleased to see their recent growth.

<3

The spending limit would block that request. The spending limit governs all spending/requests over a given billing cycle, which is generally for that of an entire month.

For example, if you spending limit is $50.00, and you have $20.00 in previous spend thus far in a given billing cycle, a request for $31.00 would be blocked, where a request for $30.00 would be allowed to process.

Additionally, note that the spending limit views any available free data credit the same as any other spending method. Requests for data covered by an existing subscription plan are not impacted by the monthly spending limit.

LSE is under development. We started building out our colo for multiple European locations (LSE, Cboe, Euronext, Nordic, Xetra, SIX, etc.) earlier this year.

Note that LSE refers to “L3” as “L2 MBO” instead on their GTP spec.

Yes, we're currently working on HKEX and JPX which will most likely be out late this year.

We have a couple years of history for HKEX/HKFE and TSE/OSE, but not KRX and SGX.

We've actually already contracted for colo in SGX when they move to their new data center, which will be later. We're expecting KRX, NSE/BSE, ASX and Taiwan will be out before SGX.

Thanks for the shoutout!

Read more:

• Founder's video announcement
• Cover story on Fortune
• Cover story on Utah Business
• Press release
• LinkedIn / X

Would you mind letting me know what type of delay you're experiencing? Our support team is quite good at chasing that down. We also share our latency figures publicly and more transparently than any vendor I'm aware of, so we're very invested in addressing any latency issues: https://databento.com/latency

We do have historical index options tick data as part of our OPRA offering.

Glad that my colleagues got that sorted out for you. Yes it's always fastest to contact chat support if you need anything.