I’d posit that closer proximity to drinking establishments would mean increased foot traffic with a less discerning clientele.
Every kebob is a good kebob when you’re a few drinks in.
331 karma · joined April 9, 2015
Every kebob is a good kebob when you’re a few drinks in.
I always approached this as a difference between incident management vs problem management, the later being the “what actually happened” phase, with lots of bureaucracy and post-mortems.
I always taught people in my group to manage out during incidents if they understood what was happening. In the vast majority of failure modes you don’t need the most technical people working the keyboard performing, for example, a failover. Most of those processes are well documented and well understood. Very technical/operationally minded people tend to want to solve the problem as quickly as possible, but I always found them far more valuable discussing the issue with stakeholders, and playing a blocking move for the more junior guys/gals on the keyboards. This also helps the juniors get the experience necessary to eventually be able to help develop future staff.
Nasdaq and NYSE have significant volumes because people think they have significant volumes (as circular as that reasoning is). There are entire entities on the fund/investment management side of the industry that are content to do their entire risk adjustment (meaning, trading) in the closing auction, and the dominant closing auction is on the primary listing exchange (just because...well, as I highlighted above).
There was a brief period in the mid aughts when Nasdaq (through the INET and BRUT acquisitions) and BATS were able to compete with the more dominant NYSE due to monstrous discrepancies in system performance, but as all of the markets evolved over the last 15-20 years they are all (at least as far as the vast majority of market participants are concerned) effectively identical in pure technical performance.
This is especially true for datasets that don't have a single authoritative source, like corporate calendar actions, where you have to consume data from 3-4 vendors and reconcile for a 'shared consensus' on simple shit like..."When is a company going to release quarterly earnings?"
I'm ever grateful that I do not work in asset classes that are not centrally traded and centrally cleared. I recognize there's more money to be made in the uncertainty, but holy crap it drives me insane.
Of the many things I despise in the industry, market data and connectivity costs are near the top. It’s a fully captured market, and customers don’t have a choice when the producer decides to raise prices.
Yes, and no. Not in the sense that it's one uniform trading system, but there are various interlinkages (market data via the SIP for example; mostly dictated by RegNMS) and most of the exchanges operate a brokerage running an order routing business.
> Would there be any difference for me buying and selling stocks on “normal NYSE” vs “NYSE Texas”?
Assuming you have the ability to dictate to your broker where they perform the trade there would be absolutely no difference between trading on NYSE vs NYSE TX (minus maybe some currently undecided fee differences). Functionally they are identical (they even run on the same technology stack).
> What benefits would companies see from listing on NYSE Texas vs the other NYSE?
The cultural issue TXSE (and by extension this NYSE TX move) are trying to capture is the 'anti-DEI' / 'the exchange tells us what the composition of our board must be to meet listings standards' type things. There's a subset of the corporate world who see value in capitalizing on these issues. There's also the potential for different financial requirements or incorporation requirements, but those haven't been disclosed yet (and wouldn't be too divergent from the existing differences between listing on the various Nasdaq or NYSE exchanges).
LTSE is trying to be principled, but I see this similarly to the TXSE/NYSE TX thing where they're trying to capitalize on a cultural issue that is fleeting and the general public really doesn't care about.
Poor BZX has never really recovered from botching their own IPO. Similar to how Nasdaq lost a bunch of business to NYSE following the Facebook IPO fiasco. As a corporate board I imagine you'd really need to justify why you would take the extra risk of working with an unproven exchange when it comes to your first day of trading.
They were also making a play at trying to capture listings for companies looking to reincorporate in TX (think of it as a 'social issue' campaign; same as what the LTSE guys are shooting for).
That all said, I definitely do not disagree with you. While I think they at least have more justification to launch a venue than MEMX did, I am highly skeptical of their ability to pull listings business away from NY. The Big Board and Nasdaq have it on lock.
From a functional standpoint, absolutely no difference. There is an extremely high probability NYSE TX remains in Mahwah (where the current NYSE Chicago platform is; it’s really just a rebranding). TXSE has already said they’re going to put their systems in Secaucus with “everyone not NYSE or NASDAQ”.
I wish one of these venues would have the conviction to put their whole kit in Dallas, or somewhere else in TX, but the industry would throw a fit because of what it would mean for the cost to access the market.
People in my industry have a tendency to over-optimize (technical folks love nothing more than to tinker), and in doing so create very unique deployments per group that require a significant amount of infra and operational support, and drastically slow down the rate of progress/change (not to mention the cost). When you peel back all the requirements it turns out we really only need three unique deployment options. Makes it all significantly less cumbersome.
Ten or so years ago I remember going to a larger technical recruiting pitch at Facebook where they discussed their logging complex (I have only a vague recollection of the details). Honestly it was one of the most beefy implementations of system/application logging I remember having seen at the time.
Some firms will also capture market data (ITCH, PITCH, Pillar Integrated) at the edge of the network at a few different cross connects to help evaluate performance of the exchange’s edge switches or core network.
Most modern trading systems performing competitive high frequency or event trades have performance thesholds in the tens of nanos, and the only place to land at that sort of precision is running analysis on a stable hardware clock.
If any discrepancies are found that persist over some time horizon it can be cause to stop all activity.
When some component fails you absolutely do not want to spend time trying to figure out the underlying cause. Almost all the cases you hear in media of exchange outages are due to unnecessary complexity added to what is already a remarkably complex distributed (in most well designed cases) state machine.
You generally want things to be as simple and streamlined as possible so when something does pop (and it will) your mean time to resolution is inside of a minute.
The market mechanics trades tend to have no recoverability if you miss the opportunity, so you’re often trading out in error and it’s a matter of trying to stem the loss on a position that you do not have an opinionated value signal on.
And there’s definitely an angle to inbound processing speed for both styles of trading, with differing levels of sensitivity depending on the time horizons you are attempting to predict or execute against. Using the example above again, detecting the arb opportunity and firing quickly is obviously paramount, but if you’re running a strategy where you have a 1 minute predictive time horizon sure, there’s some loss that can be associated with inefficiency if you aren’t moving quickly and someone else is firing at a similar signal, but generally speaking there’s enough differentiation in underlying alpha between you and any competitors that the sensitivity to absolute speed isn’t as prevalent as most people expect.
Basically it boils down to going fast enough to beat the competition, and if there isn’t any you have all the time in the world to make decisions and act on them.
On one hand you have quantitatively driven strategies that try to predict either a price or direction based on various inputs. Here you’re mostly focused on predictive accuracy, and the challenge is in exiting the trade at the right time. This is where a lot of the speed comes into play (what is your predictive horizon, and can you act fast enough to take advantage of the current market prices?).
The other mode of trading tends to focus on structural mispricing in the market. An easy to understand example is an intermarket arbitrage trade where one market’s buyer or seller crosses prices with the opposite side of the market on another exchange. These events permit a trader to swoop in a capture the delta between the two order prices (provided they can get to both markets in time).
As easy opportunity has dried up (markets have grown more efficient as systems have gotten faster, and parties understanding of the market structure has improved) you see some blending of the two styles (this is where another commenter was talking about mixing a traditionally computed alpha with some hardware solution to generate the order), but both come with different technical challenges and performance requirements.
Not to mention the real-time data which is, quite simply, catastrophically expensive. And that’s assuming the least sophisticated (retail) implementation of this stuff.
Turns out in the two decades I’ve been in my industry everyone else has gone to ‘the cloud’, and the tooling has gone with it. Every product or project I looked at was skewed entirely toward physical host agnostic and/or single service reliability agnostic management.
So not only is in an issue with going back on prem, there’s entirely unserviced customers that cannot adopt the tooling given the direction it’s been developed.