(Disclaimer that I'm working on an open source FIX engine in Lisp.)
This is a really cool project! But alas I couldn't use it as I'm not in the US, and I don't trade with Alpaca. And I feel like this plays into a negative trend I'm seeing.
The retail brokerage market right now is treading on similar 'mistakes' in institutional markets 15ish years ago. Proprietary APIs were prolific, and therefore increased switching costs and lock-in (looking at you, Reuters and Bloomberg).
On the one hand, retail brokers need to support popular programming languages and paradigms to gain traction. So, they are releasing http-based APIs, or popular language-specific libraries/bindings for their proprietary APIs. But, they are doing this instead of pushing well-publicised battle-tested standards such as FIX[1], that would normalise the playing field across brokers. So my gut feel is that they are banking on users coding against their APIs and having some lock-in effects. Notable exception is that any broker that supports cTrader will have a FIX API, because cTrader provides that for them.
The problem is: if I write a bunch of code to work against Alpaca, TD Ameritrade, or whoever, that code will likely need to be revisited for some other broker like Robinhood. Granted, market connectivity code _should_ be well abstracted from my model if I'm following good design principles. But at least with FIX, the core concepts, fields, and messages remain the same across most FIX endpoints (NOS, ExecRpt, etc), allowing for a more uniform code holistically.
I have implemented FIX for a living for a few years. It’s fragmented beyond belief. You can have different standards for different parts of the same brokerage. You have to do separate conformance tests for different asset classes at the same (big, well known, reputable) broker. The proprietary APIs like Bloomberg’s provide additional value rather than being alternatives to FIX. Make no mistake: you cannot interchange a FIX endpoint for another without making changes. The core problem is that you can impose arbitrary semantics on top of FIX messages. For example, a broker might require you to send timestamps in UTC for equities, and local time for FX, on the same FIX connection. Another might have a limit on the number of characters you can put in a ClOrdId - so GUIDs as ClOrdIds go out the window. Another big screw up is extensive use of non-ISO currency codes and the ambiguity of major and minor denomination. Is “GBp” pence? Sometimes yes! Sometimes not. Then - the most colossal screw up of them all - the reverse proxy people. They are companies that will convince management that they have a “network” and “access to liquidity”. It’s actually just a reverse proxy server that _manipulates messages in flight_! It sounds ideal, as if they will standardize your message flow so you don’t have to worry about broker specifics. In practice, it never works, and they opaquely mess with things you don’t want them to. Imagine sending an order denominated in cents, and the reverse proxy forwards it having changed the denomination to dollars. This really happened to me.
BTW, I love working on this stuff and swapping notes with other people. Drop me a line (email in profile) if you want to talk anything related to FIX!
I can confirm. When I was implementing FIX to communicate with some big banks, it was common practice to put everything specific for the interface as XML in a single FIX field.
FIX was only used because many banks had existing infrastructure built around it, such as reverse proxies on application level that would scan the FIX messages for some standard fields and route the incoming message to the appropriate server.
Of course, and in practice you basically always need to tweak your FIX layer when connecting to multiple brokers.
Whilst there will be differences, you can rely on a surprising amount being uniform. The general session/authentication flow and serialisation mechanisms will be largely the same. Or the use of standard fields ClOrdID, or OrderQty. Or the "general" meaning of the messages NewOrderSingle or ExecutionReport.
It's somewhat predictable where the differences are going to be: identifying securities (different codes, etc), expressing order types and algo parameters, and subtle differences to order lifecycles.
Again this is a gut feel, but I doubt that if you take 2 proprietary APIs, you'll get that level of uniformity.
I have direct experience building the fix layers for integrating a variety of exchanges. I think FIX is a net negative. The standardization provides so little, there are so many murky edge cases in each implementation and the protocol encoding is so bad, I’d rather just program against the proprietary API. On the exchanges at least the binary APIs make so much more sense.
I think both you and nurettin raise a very good point, in that FIX had some great aspirations, but the wiggle-room in the standards was too wide, and has resulted in, well, not a very a meaningful standard. The existence of certain companies that do nothing but aggregate and normalise broker and LP APIs is further proof of this.
Nonetheless, it'd be great to see brokers in the retail space normalise toward a uniform API. Even if that is a standardised HTTP interface with good WS support for streaming data, or a standardised binary interface. My feel is that FIX is the closest thing we have now that would get us most of the way there, even for all its warts. But of course, I'd be equally keen on anything standardised.
Execution report is another thing that is different between the two. You can't even list your running orders without resorting to custom tags. You can't send multiple orders without providing their custom delimiters. You have to modify login messages and insert custom tags before a message is sent. The only uniformity I am left with is the fix template of key=value\0x01 repeating N times. Nobody conforms to fix 4.2 or 5.0xxx they say they derive from it, then you go through their conformance test of 100 messages and see for yourself what changes they made.
I hear your pain... There's definitely brokers doing some strange things out there, or being overly sensitive to the order of fields. Let's not even talk about repeating groups.
> custom delimiters
Surely you mean custom _message_ delimiters, not field delimiters?
In any case I think it's a foolish endeavour to think that if a broker says "we conform to FIX4.4" to ever take that at face value. Agree that the conformance test always reveals the true extent of conformity.
But zooming out a little, despite these challenges, I'd say you're still in a better position than having N endpoints where 1 gives you a Java library with its own ridiculous threading model, another gives you a Python library that calls a HTTP endpoint (that you need to provide an OAuth token for), and yet another that only has a hosted C# interface. That's where we're headed towards.
Yes I meant repeating group delimiters. What I do like about fix clients (not fix protocol) is the extra value they provide by keeping your sessions alive, tolerating hot restarts, logging in and out on schedule and managing multiple sessions. Things you have to craft when building rest clients. Other than that, I see absolutely no difference between going through a conformance test and reading rest APIs. It is basically the broker's custom designed API under the guise of a so-called industry standard fix protocol.
> What I do like about fix clients (not fix protocol) is the extra value they provide by keeping your sessions alive, tolerating hot restarts, logging in and out on schedule and managing multiple sessions.
I agree somewhat, but I think the protocol needed to come first. Can you honestly say that in its absence, multiple clients would be able to implement these behaviours in a uniform manner?
The fact that there's a concept of a "session" demarcated with LOGON/LOGOUT, sequence numbering, resend semantics, heartbeating - all this had to come from... somewhere.
Put another way: if you get 10 brokers developing their own REST/HTTP API's, what is the chance they'll normalise on a similar set of core concepts?
One earthly concern is that, because of this unified interface myth, management will think that once you integrated with one broker, the others come free because FIX.
Oh, you need another week or two with the other broker? Why? We spent so much just to get the industry standard API.
Sorry I'm too jaded to appreciate sequence numbering and the industry standard logout message format that fix provides at the given time.
About your point on rest, I do acknowledge the difficulties you're mentioning, of every broker requiring different rest messages to do the same thing. I've come across brokers which accept single orders and grouping in different messages. The delay and errors it causes is insufferable.
The problem is, there has not been a body enforcing unity across brokers. Fix is a nice try, but it is left alone in the woods without any restrictions as to what brokers can or cannot alter. I would like this pointed out and heard of more and that's it.
Is there a open source framework/application in go or rust based on FIX protocol?
In forex quite a lot broker offer FIX apis(because MT4 is using FIX).
The use case would be to have only one application to watch/place orders simultanously on 2-3(...multiple) broker accounts. To spread risk of losing funds in case a broker goes bankrupt (or whatever reason).
I wrote a FIX engine in Common Lisp once, working for a Norwegian retail broker. Worked like a charm for many years, connected to multiple market places and brokerages. Adapting to new counterparties was certainly a bit of work, but generally far less than implementing their binary protocols. (We tried that too from time to time, usually if FIX was not an option from the exchange. Admittedly rare i later years.)
Unfortunately I wasn’t allowed to open source it, and it’s now lost in the void after a takeover. :(
Good luck to you. It’s not an impossible project. :)
Thanks! Until your reply, I was pretty sure the intersection of lispers and markets devs was close to nil. It's been mainly Java/C++ from what I've seen.
It's a shame that you couldn't open source it. If you're open to it, I'd appreciate any feedback, thoughts or code review you could offer. You can get to it (and my email) with the second link in my profile.
Since you’re not from US, what trading platforms do you use? I haven’t found any with free commissions and public APIs in the EU. Well, except for Interactive Brokers.
You probably won't ever see an EU broker offer free trades. The EU market is more regulated to avoid anything that smells of front running. There was a somewhat revealing interview by the people behind Flatex, a big discount broker from Germany [0].
"Is it easier for a pan European company to keep big US competition like Robin Hood and Ameritrade out?
Niehage: 'The companies you name are very badly positioned for Europe. Their economic model is based on two pillars. Firstly, they want to offer everything for free. But if you offer all services for free, you have to earn money with the capital in the investors' accounts. That is possible in the US, where you can still get 2% of interest. In Europe, with zero interest rates, that's very different.'
And the second pillar of their economic model?
Niehage: 'That's the high frequency traders. As far as I know, Robin Hood sells its customer orders to this kind of parties. They are prepared to pay good money for that. According to the European MiFID II-regulation, that is illegal. Those two examples show that the US and EU markets are totally different. That's why American brokers have difficulties breaking into the EU market.' "
And then fintech startups like Trade Republic or Just Trade came along and...offered basically free trades (the 1€ at TR can be considered almost non-existent when comparing to the 5-10€ even at discount brokers like Flatex).
They found a third way of financing themselves: just support one marketplace which kicks back some money to them on each trade, which they in turn earn from the spread between buy and sell prices.
I thought the US predecessors of this kind of broker (Robin Hood comes to my mind first) which is still pretty new in Europe would have basically the same business model - earning some money with each trade by scraping off a few cents (or a good bunch of cents for stocks with low liquidity) from the spread?
> You probably won't ever see an EU broker offer free trades.
Freetrade, Trading212, both registered in the UK. (And I don't think 'transition period' would make a difference, but they're both years older than that.)
I had a quick look at Trading212 without properly investigating their business model. They seem to route all of their stock market orders through Interactive Brokers [0].
I'm in Australia, so the choices here are also a bit limited. Also, I'm less interested in equities. In the CFD space, my shortlisting technique now is basically "do you offer cTrader", because as mentioned above, this means they have a FIX endpoint.
Broker offerings here seem a few "paradigm shifts" behind the US. Zero commissions are unheard of last I checked. Also, if you approach some brokers here and ask for an API or a FIX endpoint, you're either told to go away, or you're effectively ushered into a luxurious room, poured some exquisite scotch, and asked about how many millions of AUD you're looking to trade per month. And _then_ told to go away.
> Broker offerings here seem a few "paradigm shifts"
> behind the US. Zero commissions are unheard of last
> I checked.
A US-style zero-commission model is not viable in the Australian landscape. The root of this is due to regulatory differences, rather than actions by the brokers.
A key to understanding the US system is something
called Regulation National Market System (RegNMS). Loosely, if you are filling an order for someone, it must be at a price that is at least as good as the best price available on any US market at that time. [Anecdotally, if the NYSE receives an order, and there is a better price available for the same stock on Nasdaq at the same time, NYSE can't fill it at their inferior price.]
This creates a hyper-competitive single market. At any one time, you can know the bid/ask spread for any stock, nationally. And, it's a tight spread.
Market makers compete here. But a market maker would prefer to interact with retail orders. Because what a typical retail participant cares about is getting an immediate execution at the best price currently in the market, in order to make a long-term investment.
So a market sprung up: market-makers pay brokers to send these benign orders to them directly, without going through the public market. The market maker fills these order at a price that satisfies RegNMS. [Some of them might even distinguish themselves by giving the consumer a better price than they would have got on the public market. Your broker might send you a report with your trade saying how much "price improvement" you got compared to what you would have got at the same time on the public market.]
The reason the trade is "zero commission" is because the market maker is paying your broker for the privilege of interacting with you directly, because you don't have a view on where the market is going to be in five seconds' time.
Australia has not developed anything equivalent to RegNMS. Without that, there is no foundation for the zero-commission trades (there is no national best price to protect consumers with). In Australia, the typical situation is retail orders being sent directly to the book on the ASX (a pseudo-monopoly exchange), where they are directly interacting with the most sophisticated houses.
If you google, you can find an ASIC paper trumpeting that Payment for Order Flow has been banned. In my view, the real story is a lack of innovation by Australia's regulators.
Is IB "Interative Brokers"? I'm trying to figure out if Aus is Australia or Austria. I'm in Australia, and have been looking at who to go with. Almost signed up with CBA last week, but definitely more expensive to what I'm used to in North America.
I lived on the JVM for quite some time (and still do), and I wanted to explore other ecosystems out of sheer curiosity. Got to playing with Lisp/SBCL, some initial tests showed it was pretty quick, and was impressed that I could disassemble functions in the REPL and iterate rapidly. Then a while later... I noticed there wasn't a FIX library at around the same time I was exploring creating my own trading models.
So I can't say there was a lot of analysis across the different Lisps, etc. Had the coin flipped a little differently a while back this might have been in Racket. Also the choice of language in the book Professional Automated Trading[1] did influence me somewhat.
I read it quite a while back, so memory is a little hazy.
It's one of the few books (perhaps the only one I've found) that approaches this subject matter from the perspective of an engineer wanting to architect their own system from the ground up, and potentially work for themselves or in a firm. But, going in, you should know that it focusses less on trading techniques and more on software architecture. What data structures you might use, and one potential approach that's laid out in the book.
Whilst some areas in the book are light (for example, the performance section), I'd recommend it if you're interested in ground-up building a trading system. If you work in the space already, you'll know the parts that are misaligned with majority of systems out there (choice of language being one). If you don't, and are looking to enter the space, it'll increase familiarity with core concepts (for instance, before I read this book, I had no distinction between "model" and "algo").
It's also refreshing that it stands out from the pack of books that aim to make you zillions of dollars just by using "these 10 key trading secrets!".
Excellent. That sounds like something I'd really enjoy. I don't work in the space, but I'm more interested in the trading systems than the algos, primarily. After all, I'm a little skeptical about my ability to beat the PhDs with their institutional nukes while I'm over here sharpening a dagger.
How is it similar; the whole point of the parent comment is independence from that walled-garden approach - it sounds like precisely the opposite to me?
Has the FIX spec been free and open for a long time? I was going to create my own FIX engine a couple years back but for some reason I remember having to pay for the spec and it wasn't cheap.
The proprietary API is guaranteed to be slower. The brokers must send order flow as FIX to the exchange. This adds latency of however long it takes the broker's software to translate to FIX. I don't think there are any successful quant strategies that don't rely on speed, so basically anything with a proprietary API is solely for amateurs.
> I don't think there are any successful quant strategies that don't rely on speed
There are plenty of successful quantitative algorithms that are in use by non HFT firms
> so basically anything with a proprietary API
If you’re not a direct market participant, colocated in the exchange, you’re not in a position to be talking about speed at all. Also most exchanges optimising for speed are not using FIX.
> is solely for amateurs
You’re not necessarily an amateur, you’re just leaving money on the table for someone else as you’ve not optimised that area of your trading infra yet.
I don't think you understand what quant finance is about. Almost all quant strategies don't rely on speed. In fact, HFT is usually considered a totally different space than investing (and therefore quant investing).
> The proprietary API is guaranteed to be slower.
Yeah, most of the time that's not the case. Binary encoding/decoding is often much faster than FIX. Look at ITCH/OUCH, SBE and FastFix.
Beginner question on a related topic for those of you more knowledgeable than me:
Is there a way to get access to the order books on Nasdaq or other exchanges?
I'm working on a script that can run stock trading algorithms (and hopefully see some profit).
My first trading experience was with crypto on GDAX (now Coinbase Pro). The order book on GDAX is basically available via their API. I've been looking at various stock trading APIs (Alpaca looks interesting as well) and it seems like the only thing that's available are broker APIs that don't share the order book.
Is the order book on Nasdaq and other exchanges unavailable to regular folks like me? Is it hidden, available to institutions only, or to some sort of registered brokers?
Having first dealt with GDAX and now looking at stocks, it all seems so ambiguous and hidden behind 3rd parties, unclear order execution, etc. (not that gdax was perfect - it has its issues), so I'm just generally confused as to how things work.
You have to buy the feed, the market data isn’t free. Depending on your usage the fees can get fairly steep [0]. And that’s just the market data, you need to pay for colocation, cross connects, and order entry sessions. Of course Nasdaq is only one US equity market - there are 14+ with more coming online in recent years.
Check out interactive brokers. You have to pay for the market feeds but it’s all available via API. It’s a completely horrible, painful API, but it’s the only way I found to get the data as a hobbyist.
There’s a process where you certify that you are a non-professional trader and they give you access to the data feeds for a reasonable price.
I’m working on a similar project, in case you’re interested in swapping notes (contact info in profile)
I could have sworn yahoo finance or some other stock/finance site had order book available ( though it may have been a delayed version ). But I can't find it, maybe they shut it down or maybe I'm imagining things. If you have a brokerage account, it might have it depending on your account level/type. Else you would have to pay for it.
as everyone has said in the child comments the best way to do it is by buying feed access. on the other hand i am working through IEX data on a historical basis to backtest strategies
Thanks, I looked briefly at IEX. Seems like a good source of historical data (maybe real-time as well). One thing that caught my attention was their use of SSE - I typically see WebSockets-based APIs. I also noticed the free account gets 50K messages, which sounded like a lot, but it turned out it was just enough to set up one alert on the account - somewhat underwhelming, but I understand they'd like to convert the free accounts to paid users as fast as possible.
the best part about iex is that they give you milisecond historical data but on the other hand the data is only limited to their exchange so it clearly doesn't represent every exchange.
Heard about alpaca a while back, so I made this as a small fun side project. The main features are buying, selling, and viewing stocks. In the future I may add additional features if I find something I want to add (or others want to add).
Alpaca is great! As far as brokerage APIs go, theirs is top notch and a breeze to code for. The founders are also really responsive and helpful.
I know this because I wrote an app that connects to Alpaca accounts (as well as other brokerages) to help people build their own custom index funds [0]. It only took a few weeks to build our Alpaca integration, whereas other brokerages often take months/years just to get access to their APIs.
I love M1! But I have come to hate their "tech". Obscure URL's (what was that stock you looked at two days ago? good luck finding it in your history!), broken watchlist, can't explore adjustments to a pie (such as two windows to submit/revert a pie change), have to contact support to pause trading, backtesting breaks if stocks are listed <5 years ago... they recently added dark mode to their app with terrible contrast of red/green (the green looks black in white mode so you have to use dark)
I feel like their UX priorities are screwed up big time. But as a platform, they're my favorite as far as concept/functionality.
Selling order flow isn't "selling the poor out". Reg NMS literally requires brokerages to route your orders to where they will get the best execution price. In general you as a retail investor get better execution prices because of how this works (why? because retail investors generally don't have new information that will move the price so they are "safe" trades for liquidity providers).
Now robin hood _did_ get fined for "not perform[ing] systematic best execution reviews of several order types". If that's what you were referring to then fine. But if your complaint is just about selling order flow you should better understand what that means. Maybe start with patio11's How Brokerages Make Money[0].
FYI: "With no commission" is a bug, not a feature. Typically, when you pay commission, you get better prices. Let's say you buy 100 shares of SPY at Interactive Brokers. You pay $1 commission and get it for 268.28. At a free-of-commissions broker, you might get your 100 shares for 268.30. That's $1 more than the trade at IB. TNSTAAFL.
It's exactly like how duck typing took over programming in the last decade or so with, "Whee, see, less typing!!", and we lost the value of having static types ("strong typing"). Why are we tempted so easily? Now we have the horror of Javascript everywhere. Even the Node.js founders recoil from their own creation and are going a step in the right direction with Deno.
Free brokerages generally don’t execute orders as quickly in order to sell order flow which allows HFT firms to front-run your trade. If you’re a buy and hold investor, the fractions of a cent you’re losing don’t matter much over the long run but the issue is still there. Generally when you pay for something, it means that somebody is beholden to you if there’s issues. Robinhood et. al. are free because they suck.
No, they sell order flow because market makers know discount brokerage users are uninformed and thus less risky to buy and sell from. However, they actually give you better prices than the public market offers and they have to or else the SEC would fine them [0]. Your link is just about robinhoods shitty infra that couldn't handle their user load and has nothing to do with order flow.
I'm going to have to jump in here and say, no, HFT can and does not front-run your trade. There are reasons why your execution on RH is not as good as professionals, but it's not because of front-running.
Do you have any sources that retail trades are being front run? When I looked into it a while back it seemed they would sell your order flow but you had to be guaranteed best execution prices.
My main FUD with alpaca.markets is the ability to transfer assets in/out. It doesn't look like they offer ACATS transfers (although there's not much info on this!).
Using them for anything beyond entertainment budget is very scary - you may incur substantial tax liability if e.g. they ever go out of business or you choose to use a different brokerage.
Any insight here? Am I missing something? Is there any way to transfer holdings out without incurring the cap gains?
as far as i know the "actual" backend data is standardized, ie same instrument names and dates etc. Adding to that, by playing in the US markets the SEC and FINRA, have that stipulation of being able to move between institutions in a standardized and regulated way.
long story short, they all have to implement a system to move out and in (well they all want your assets so this part is obvious).
What's really cool about Alpaca is the integration with zipline via pylivetrader. This means that you can take your backtested factor models and easily convert them to live trading. Also, they have pretty lax margin requirements. You can borrow 2x the cash you have, 4x for intraday if you're a pattern day trader, and the maintenance requirement is only 25%. And with zero commissions, suddenly it's possible for the average joe retail investor to actually run a legit factor strat. If you're only trading highly liquid securities, it could even make sense to run a intraday only strat at 4x leverage. Lets say you're trading stuff that has spreads around 4 bips, your lost returns are going to be around 10% per year from trading costs. That's certainly a lot and you'll need a kick-ass strategy, but that 4x leverage might let you get there.
Do you have any reference on `legit factor stats`? I do not understand how leverage will be beneficial. Leverage will also multiply the potential downside risk after all? I would like to understand more how the trading cost would make up for it on average.
> I do not understand how leverage will be beneficial.
Same here, if I understood the grandparent they were saying you lose 0.04% on every trade (from spread) and "in a year" that is 10% (250 trades?).
If you have a strategy that has expected returns of x bips per trade then you make an expected x-4 and with leverage 4 * (x - 4). Both have the same "sign", so if x-4 is expected positive, leverage just makes it higher risk-reward.
In fact with leverage you also have to pay interest on the loan, which seems to be at least ~18 bips (or 3/4 of that since the returns are on 4 * cash and interest is on 3 * cash) for a single day loan (far exceeding the "spread cost"):
https://www.schwab.com/public/schwab/investing/accounts_prod...
It seems the only way leverage would help is if there were fixed costs to trading (which I assume there are but the GP does not mention).
Well you have 504 trades approx, but you're buying in and selling out, so you're paying the cost of spread once per day (252 trading days in a year).
Let's say you have have a strategy that has 7% return and 3% volatility. That's a pretty fucking amazing strategy. So you lever up to 4x and now you have 28% return and 12% vol. With your spread tax, you now have 18% return and 12% vol. Using their 2x leverage, you'll have a 14% and a 6% vol. So while your Sharpe ratio will be lower, your max return will be higher. And since you can't eat risk-adjusted returns, the tradeoff could very well be worth it.
I was just reading their docs [1], and I got two things wrong above:
- Schwab's overnight interest rate is actually ~1.8 bips. Alpaca's is even lower at 3.75% annual which translates into ~1 bip / day
- If you liquidate stock the same day, you pay no interest
Not seen anything with both free trades and an API in the UK. I would like to do this to implement simple strategies - for instance mirror indices but with user defined filters (S&P500 minus hospitality, airlines and oil, as an example).
Freetrade, 212 Trading and soon Robinhood offer commission free traedes in the UK but no API
Does anyone know why they are US only? Is it because the market is different abroad, because there are no European/Worldwide legal framework or simply because it's easier to start with?
These "free" stock trading companies cut deals with high-frequency trading firms that buy order flow. The more order flow they buy the more money they make (essentially risk free to them), which is why they are willing to send boatloads of money to companies like Alpaca/Robinhood.
High-frequency trading firms aren't in the business of stocks, they are in the business of building the fastest tech on the planet to connect buyers with sellers, therefore making markets more efficient.
What are you folks using this kind of stuff for? The best I can come up with is carefully studying issuers' financial reports and reaching some not very good but close enough conclusion about the state of businesses. At which point paying a few $$ or even $100 in commissions is really irrelevant given how much effort I had to put in ...
You should know in general, though, that no one trades "for free" despite what brokerages say.
Your order gets routed, delayed, placed differently, and while you may not immediately see it, your trades are getting a different result than if you explicitly paid a brokerage who charges a commission on it.
I don't know why others downvoted you, I didn't. But as general feedback: "learn about X" without linking to some resource about X is really lazy soapboxing.
I downvoted it because it’s mostly factually wrong.
First paying a commission is not correlated with participation in order flow payment. Commissioned brokers also get paid for order flow.
Second if you interact with an internalizer your order will execute faster not slower. And you will usually be getting better price execution than if you try to route manually.
Third all brokerages have routing tiers that involve self matching/dark pools/contractual discounts etc. Most of them will let you pay for the privilege of using the same router the non-premium orders go through.
At the end of the day if your trade is that sensitive to execution you are not a retail customer and should not be using a retail brokerage.
Maybe, and it'd be nice if people cited all their knowledge with sources, otherwise it's possible to simply ask - or do a quick Google search to research yourself; of course if someone's explanation and understanding sounds good, though out, then they are more likely have access to good sources to save you a bit of time not having to research..
> your trades are getting a different result than if you explicitly paid a brokerage who charges a commission on it.
Yes...the average retail customer submitting a market order will generally get a better fill with PFOF. This is what most people don't usually mention when talking about those terrible high-frequency trading firms.
E.g. if a stock is trading at 10.00x10.10 and I submit a market buy via Robinhood. Citadel or someone else is going to pick that up and sell it to me for, probably, 10.08 or 10.09. Not the 10.10 I would've paid on the open market hitting the offer. It's in fact illegal for me to get a worse (higher) fill than 10.10.
Which to me begs the question: do you actually own the shares when you buy them with those brokers? What happens if supply is limited and the loaned shares actually have to be sold?
Ownership doesn't really matter that much so long as you meet the tax criteria for it. As for the rest, everyone else playing in this space is likely to have assets that are in the range of SIPC insurance so just make sure your stuff is insured and don't sweat the small stuff.
One reason people invest in stocks at the moment is hedging against a falling dollar. In a great market turn, it could be that those $500,000 are the price for a cup of coffee. If you lose access to your shares at that moment, it doesn't help if you are rewarded with money.
*edit: Apart from that: is that actually an event covered by SIPC? Essentially it is a bad investment decision. You agreed to lend out those shares so you have to bear the consequences.
which is fine for retail traders, often resulting in execution improvements in dark pools etc. its amazing to me no one questions no commissions but trading equities is decentralized garbage anyway
Alpaca is very interesting, I've been following them since the beginning. The sad thing is that I'm not from the US and it's still not available for residents of my country (Paraguay in South America).
go install doesn't work @anegri
# github.com/keybase/go-keychain
cgo-gcc-prolog:203:11: warning: 'SecTrustedApplicationCreateFromPath' is deprecated: first deprecated in macOS 10.15 - No longer supported [-Wdeprecated-declarations]
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/SecTrustedApplication.h:59:10: note: 'SecTrustedApplicationCreateFromPath' has been explicitly marked deprecated here
A problem I've bumped into with Alpaca compared to other services is my bot needs 1 second bars, and I believe Alpaca goes down to 1min bars and nothing smaller.
Yeah there are definitely a number of limitations if you are using just alpaca (which I limited myself to for this), which is why this project is intended for just a few basic use cases.
Did you try the Alpaca Market Data (streaming) they just released? You should be able to get real-time data now that is aggregated from multiple exchanges.
Cool! Know of any cheap 1 sec bar or less historical data sources?
IBS does live tick data for around $10 a month, smaller than 1sec. I hate IBS, but I hate paying $200 a month more, especially when I'm backtesting most months.
I came across https://tradier.com/products/brokerage-api which seems to provide historical data for free. I'm taking a look currently, so I'm unsure how good the data is.
Shameless plug: I started a YouTube channel on this topic that covers a lot of commission free trading API's, including Alpaca (got featured in their docs), Robinhood Private API, TD Ameritrade, Tradier, and more. I'm seeing a huge growth in interest in developing automated trading bots and algos. With commissions dropping to zero, there is a huge wave of day/swing traders that want to learn Python, so am creating as many tutorials as possible.
NZ doesnt have much going for it in terms of access to international equities. If you have over $10k USD, you can get an interactive brokers account, their API is a bit rubbish and commissions are normally around $6.00 USD flat. Otherwise Direct Broking via Jardens, commissions are c. $30 NZD per trade. Sharesies are apparently launching international equities later in the year, but they dont offer API access.
Thanks for the response. I was hoping for API access. It is a pity that companies don't expand here when they open an AU branch. That said, I don't blame them as our regulators are very inflexible, I used to love ipredict until it was shutdown.
Sorry for the delayed reply, I wanted to get confirmation from our brokerage team before posting.
Tradier Brokerage (https://brokerage.tradier.com) can open individual accounts for New Zealand residents and API access comes standard with every account (including market data). You can place orders for US-based equities and options and we offer competitive pricing models for all traders.
If you have any questions, you can email service@tradierbrokerage.com or call 980-272-3880.
This is a really cool project! But alas I couldn't use it as I'm not in the US, and I don't trade with Alpaca. And I feel like this plays into a negative trend I'm seeing.
The retail brokerage market right now is treading on similar 'mistakes' in institutional markets 15ish years ago. Proprietary APIs were prolific, and therefore increased switching costs and lock-in (looking at you, Reuters and Bloomberg).
On the one hand, retail brokers need to support popular programming languages and paradigms to gain traction. So, they are releasing http-based APIs, or popular language-specific libraries/bindings for their proprietary APIs. But, they are doing this instead of pushing well-publicised battle-tested standards such as FIX[1], that would normalise the playing field across brokers. So my gut feel is that they are banking on users coding against their APIs and having some lock-in effects. Notable exception is that any broker that supports cTrader will have a FIX API, because cTrader provides that for them.
The problem is: if I write a bunch of code to work against Alpaca, TD Ameritrade, or whoever, that code will likely need to be revisited for some other broker like Robinhood. Granted, market connectivity code _should_ be well abstracted from my model if I'm following good design principles. But at least with FIX, the core concepts, fields, and messages remain the same across most FIX endpoints (NOS, ExecRpt, etc), allowing for a more uniform code holistically.
[1] https://www.fixtrading.org