Lol, we had literally this exact startup: TradeIt (https://web.archive.org/web/20200817053226/https://www.trade...). Launched about 7 years ago, had official OAuth integrations with most major brokers, an API, and native mobile SDKs that had customizable UI for portfolio/order management/trading/market data. We had some really big customers like Yahoo Finance. Sold to another company about 3 years ago. The buyers had no idea what they were buying and let it rot and eventually shut it all down. Fun times. If we could have held on until WSB went viral a few years back I think we could have been very big. Oh well. Maybe you guys can succeed where we left off. Good luck!

Thanks!

I've dealt with a lot of these over the last decade, here is my wishlist:

- Multi-legged options trading

- Portfolio Margining (and SPAN) system

- Cross asset and cross portfolio margin management, inherited by Portfolio Margining regulations

most API trading services don't allow access to options contracts, or if they do (such as Tradier), they only have the inferior plebeian Reg-T margin which barely makes any sense. Although most of retail doesn't know the difference so its probably fine for your service.

PM and SPAN margining are similar, but I think PM is easier to calculate one way: just take Reg-T margin requirements and calculate the loss in a +/-15% move (6% for indices), and make that loss the margin requirement. Reg-T margin assumes something closer to a +/-100% move in the underlying asset, which winds up taking up too much capital.

You're right that most retail investors don't pay attention to the specifics of how margin requirements are calculated. To my knowledge, the only brokerage that's readily accessible to retail investors that provides SPAN margining is IB, and relatively few (US) retail investors use them compared to the more mainstream brokerages.

In terms of cross-asset-and-portfolio margin management, it definitely makes more sense to base risk calculations on a broad view of positions rather than the composition of a single portfolio.

I'm slightly out of my depth here; this is an interesting perspective I haven't seen yet, so I'll definitely be doing some more research into the problems you described.

None of the retail brokers (including ibkr) do this correctly, although ibkr is probably the best for retail. Their cross-margining for futures options doesn't work (since the options are treated as "securities" and the futures are treated as "commodities", they treat them as segregated accounts).

They do handle multi-legged options trading, and implement SPAN correctly within the futures space. Portfolio Margining is not always correct (they don't implement customer portfolio margin baskets right), and be aware that margin can *and does* change drastically, particularly during financial crisis.

https://www.federalreserve.gov/econres/feds/an-empirical-ana... (p38-45).

Is there any brokerage who’s terms of service or fraud liability protections aren’t entirely waived by using a service like this? Do end users provide the credentials for their brokerage accounts?

I can’t imagine any infosec officer or general counsel at a brokerage agreeing to screen scraped data collection. They already get enough legal threats for bad pricing / bad execution, this would be an entirely new can of worms.

We do sanctioned integrations with brokerages wherever OAuth integrations are available such that we don't have to collect credentials, but for the ones without public APIs we do need to collect credentials (though we never store them). Unfortunately, the industry is in a mode where brokerages will develop anti-screen-scraping technology and data aggregators will develop new and creative solutions to evade detection - the demand for access to retail accounts is too great for screen scrapers to stop what they're doing, and the regulatory and technical risks are too great for brokerages to lean back and allow screen scrapers to do what they do.

Many of the major brokerages are realizing that this isn't ideal and are starting to build out public APIs. We're working to develop relationships with the holdouts and convince them that exposing a public API is the only sustainable long-term solution to their screen scraping problem.

Can you explain how you collect credentials but don’t store them?

We collect a user's credentials (usernames + passwords) and exchange them immediately for access and refresh tokens. We use the term "credentials" as we've seen it used colloquially - access and refresh tokens certainly fall under the formal definition of credentials, but we usually call them "sensitive tokens" or something similar.

Additionally, in the case of an API like Webull's which accepts a salted MD5 hash of the user's password, the user's plaintext password will never touch our servers.

I used to do this exact thing as a job, and it's crazy how little US brokers do to protect their APIs (at least back when I was doing it around 2015), given the security implications. I'm not even a hacker and I was able to reverse engineer 90% of the US brokerages without a problem.

Compare that to Singapore. I spent about an hour toying with the Lim & Tan API before our account got shut down. Apparently the fucking CTO was woken up in the middle of the night by all the alarm bells I set off lol.

edit: when I say "without a problem", I mean that in relative terms. We got plenty of strongly-worded letters asking us to stop, and they played whack-a-mole with our instances. But we never faced a serious challenge to what we were doing.

We've had the same experience in 2022. An afternoon with an HTTPToolkit interceptor is usually all it takes to reverse engineer a brokerage's API; we spend most of our time paving over various brokerage-specific idiosyncrasies and responding to breaking changes in their APIs. We've discovered that building sane abstractions over the various retail brokerages in the US is a hard design problem given the variability in supported assets, account types, order strategies, authentication strategies, etc.

Thankfully we haven't had to field any calls from irate, sleep-deprived CTOs yet - running experiments against APIs during local business hours only could be a good hack for avoiding those :)

> We take an entirely different approach by building direct integrations...

> Private APIs need to be reverse engineered and are liable to change at any moment, so we had to develop systems to catch breaking changes and are always on alert to address them.

Isn't this still, essentially, screen-scraping? Reverse-engineering private APIs (presumably from their mobile apps, I'd imagine) and doing the abuse/block dance with their protective systems?

While we try to form relationships with all of the brokerages we integrate with (including the ones we reverse engineer), we do still have to do the abuse/block dance with their protective systems occasionally. We've found that cutting out headless browsers has made it much easier to do this, for two main reasons:

1) Some brokerages have fairly sophisticated anti-screen-scraping protections, but their private APIs are comparatively undefended. 2) It's generally more difficult to create protective systems for private APIs, since there are fewer ways to fingerprint non-browser clients.

I think "direct integrations" as a euphemism from "using reverse-engineered private APIs in violation of their terms" is dishonest.

That's a fair point - we've been trying to determine the best way to compress "using reverse-engineered private APIs in violation of their terms, but in practice brokerages don't really take enforcement actions against this," and "direct integrations" is what we came up with. We'll work on finding a better way to express this and are open to suggestions.

I think "unofficial API" is probably the most succinct phrase without being dishonest. A direct integration does imply some kind of professional relationship with the other company.

This sounds good - thank you for the feedback.

It's not as long as they expressly state there is no relationship or endorsement with the brokerages where there isn't one.

Perhaps. The current site and documentation appears to lack anything of the sort.

It’s a brand new company. Give them a chance to work these things out.

Well, they're taking shots at players like Plaid (who use majority direct oAuth integrations) while doing the exact same kind of skirting around companies that don't play nice and share permissioned user data.

Aggregators aren't scraping because they enjoy using headless browsers, the US doesn't let end users own their data and this is the industry workaround. I don't expect new players to change the system so much as I expect them to accurately represents it to those outside of fintech

> 2) It's generally more difficult to create protective systems for private APIs, since there are fewer ways to fingerprint non-browser clients.

There are? I think what you meant to say is “they haven’t worried much about key distribution, yet”?

In a sense. There are certainly protections they can implement against non-browser clients; what I meant is that it would be more difficult for them to implement the usual sorts of defenses you see against screen scraping since the surface area available for fingerprinting is much smaller.

We haven't seen brokerages expend significant effort on this, and the industry seems to be moving in the direction of providing more open access to APIs, so we're (cautiously) optimistic that we will be able to convince them to provide more sanctioned integration paths such that we don't need to continue playing cat-mouse with them.

What incentives do mainstream brokerages have to building public APIs? It seems to me data asymmetry is the name of the game in Wall Street and it’s no different for retail brokers.

Wrong analogy. You’re describing theft. It’s More like, my neighbor planted an apple tree in their yard and told me, “this is your tree. You can pick any fruits off of it, anytime you’d like.” I told the jam making shop down the street that they can come get apples on this tree anytime if they give me some of the apple jam they end up making. My neighbor didn’t explicit permit me to do this, but also didn’t forbid me. I think? So now the jam making shop owner goes and grab my apple on my neighbor’s tree.

Maybe the solution is just to have the jam maker give the neighbor a can?

Except that it isn’t you inviting the jam maker, it’s the jam maker saying “I have a direct integration with the guy who manages your apple tree” , when they actually mean “I’ll dress up like you and pick the apples when nobody’s looking”

Who is liable if the user's brokerage account gets blocked?

It depends on the nature of the activity that got the account blocked - we place limits on the types of legitimate account activity that are likely to get a user blocked (sending too many orders too quickly, sending orders that could be batched as a flood of single orders, etc.), but for fraudulent or otherwise illegal activity, that liability is on the user.

When starting a new integration, we schedule a meeting with the brokerage in question (if they'll have us) to discuss issues of this nature. The response we've gotten so far has been "as long as you don't enable illegal activity or put unnecessary load on our service, we won't take action against you or your users," though we're sure some brokerages will have a more aggressive stance on this in the future. We aim to work in partnership with them and advocate for the ability to integrate in this way, and we encourage the brokerages that gives us an audience to build public APIs.

For a copy trading app, what compliance problems do you envision using your service? Is the trader being copied liable if the people copying him lose money (generally speaking)?

While I'm not fully qualified to comment on this (I'm not a lawyer/have no formal experience with securities law), my understanding is that it would depend on if the trader in question is providing investment advice. The SEC seems to have no clear position on the legality of copy trading at the moment - some of our customers are building copy trading apps, and they all seem to be in agreement that regulatory uncertainty is just one of the risks of building that sort of product at the moment.

There is probably a reason eToro, the premier copy trader, only does crypto copy trading in the US. Just food for thought. Effectively managing others' money would effectively make the trade-makers RIAs

We spoke with some lawyers while building our social investing app to gain a clearer understanding of this. Like Tim said, we're not lawyers, but the ones we spoke to said that this is a major gray area.

This sounds like backwards to how this industry should be evolving...

We agree, we would MUCH rather be implementing sanctioned integrations and we will go the sanctioned route whenever possible. We're trying to establish relations with these big institutions to push them towards sanctioned access and also get feedback on what would be best practices for integrating with them. Our bet is that the industry in the long-run will be moving towards enabling sanctioned access delegation. That being said, at the end of the day users want to export data from their brokerage apps and they want the means of exporting this data to be stable.

Either force through regulations or gotta make it in their interests to support a public API. Financially or else. I don't think they'll do just for the sake of it.

This gave me PTSD on dealing with algorithmic stock market stuff. Glad you are doing it, I feel like this model accumulates tech debt too quickly, you are stuck doing integrations over and over again.

Everyone that can write code just moved over to crypto, where trading is 24/7, the CeFi exchanges have free, standardized APIs and the onchain stuff is super easy to code too.

In TradFi like this, a whole nother decade has gone by and barely anything has changed, the ridiculous barrier of entry is what makes people believe you have to be an investment banking quant just to write a trading algorithm. When its really just the cost of getting direct market access.

Agreed - there's no fundamental reason interfacing with traditional brokerages should be as difficult as it is today. We're working to form relationships with all of the brokerages that we integrate with and are advocating for them to focus on exposing and maintaining public APIs so people can delegate access to (and interface with) their accounts more safely.

In the meantime, the technical debt is manageable, but probably only if you're doing this as a full-time job - in my experience, trying to build an investing app and the integrations that power it at the same time is a losing battle.

I'd LOVE to use this, but seems legally dubious. I'd love to see some written approval from Robinhood and Webull. Seems like an obvious solution, there must be a reason it hasn't been done before...

Financial services firms aren’t gonna sign off on this due to liability and cyber risk (fully permissioned financial identity auth token loss could equal substantial asset theft), and they won’t provide it themselves unless required to by statute or regulatory rulings. It’s possible there’s eventually enough uptake for Realize to convince those they integrate with to provide endpoints with read only scoping. Fidelity in particular seems to be running quick from a tech transformation perspective, making them more open about sanctioned integrations.

Europe got this right with PSD2, the US will catch up eventually.

https://en.wikipedia.org/wiki/Payment_Services_Directive

That's how we are thinking about this as well.

Interactive Brokers lets you create a whitelabelled sub-brokerage on their platform, and their APIs are sufficient to build this. Perhaps Realize is using something like that on the back end.

This looks great! Going to talk this over with my co-founder to include in our list (currently have direct TD Ameritrade interaction)

Feature wishlist: - Include Interactive Brokers - Support Options in trades

Thank you! We're going to be adding support for options sometime next week. IB is also on our roadmap, though we don't have an exact timeline for an integration yet.

Thanks! Feel free to reach out to me at sean@realizefi.com if you & your co-founder want to talk about your use case.

Congrats on launching.

I'm not familiar with the space so forgive me but when you say we "build direct integrations", what does that mean? Is the data available by APIs or did you get someone to do something custom for you? If it's available by API, why would others screenscrape?

Thanks! Where possible, we integrate with brokerages' public APIs (we refer to these as "sanctioned integrations"). Brokerages like TD and Alpaca implement OAuth such that we can get delegated access to user accounts, but that's not the case for other brokerages (ex: Robinhood, Webull, etc.). In the latter case, we'll reverse engineer brokerage APIs, which we refer to as "direct integrations" since they use the same endpoints that the brokerage's official clients use - this has some advantages over screen-scraping, specifically in regards to auth success rates and reliability.

Hmmm also ignorant on this, but is that legal? I’d assume it’s a TOS violation at least.

Would using this cause accounts to be banned in these direct integrations?

Different brokerages take different positions on these sorts of integrations - some go after all third-party integrations aggressively (including screen scrapers), while some will turn a blind eye as long as you're not abusing their platform. For a brokerage like Robinhood, we've only seen them take enforcement actions against individuals if they send a high volume of orders in a short timeframe.

It's worth noting that even with sanctioned integrations (such as the one we developed for TD Ameritrade), sending too many orders at once or not appropriately batching orders will still get you in trouble - we guide people that integrate with us through these nuances so that their users don't get angry calls from risk departments :).

Haha awesome thanks for your response this seems like a super useful service.

Congrats on the launch and good luck! :)

Thanks for checking us out - really appreciate it.

It would be nice to limit scopes on the oauth request. For example an app used just to report on positions and historical performance. I would be very hesitant to give access to by TD account when it says it could make trades on my behalf, but would happily give read-only access.

Definitely - we've gotten this feedback from several of our users and it's a high-priority item for us. We'll be adding the ability to limit scopes on a per-app basis this week.

As a consumer, I’ve had significant difficulty getting my Schwab Equity Award Center balances to sync with apps like Wealthfront. The connection is always buggy and I have to reauthenticate all the time.

I wonder if this is the problem. If so, I’m glad you are working on this. Best of luck!

When a consumer logs in with our application we save their access/refresh tokens. We can use these keys to keep a long lived session such that an app using our API should never have to re-auth their users again. The only instance where a session may need to re-auth is if their password gets changed, or some equivalent account modification such that the long lived refresh tokens expire. We specifically chose to integrate with institutions with refreshable tokens directly in order to maintain secure non-buggy connections.

First off, congrats! The problem I always run into with existing offerings, which as you mention all go through Plaid or Yodlee, is that there is never enough transaction history available for what I need. Typically, its only 3 months' worth at most.

We pull up to 15 years of transaction history which we believe should cover the majority, if not the entirety of a users transaction history.

Thanks!

Awesome pain point yall fixing here. Do any of these firms provide actual, document APIs intended for external use?

I'd happily drop my current brokerages and switch to a consumer-friendly brokerage that supported this.

TD Ameritrade is the biggest brokerage we deal with that has a documented public API intended for external use, but the documentation isn't entirely accurate and the rate limits on some endpoints are fairly restrictive by default (120 req/min, which is shared across all accounts connected to an OAuth app - we had to have this bumped by several orders of magnitude for our use case). TDA has been great to work with overall though; getting in contact with the right people there was the main challenge.

Alpaca provides a great API for equities (and now crypto) trading, but the instrument and order strategy support is limited compared to the likes of TD/IBKR. They've been API-first from the start, so their API is more modern and pretty painless to work with.

Congrats on the launch - what you've built is incredibly cool. When do you plan to add European investment accounts?

I cofounded Nordigen (Plaid competitor in Europe) and we use PSD2 bank connections, which are great for payments data but do not cover investment data, which is less than ideal. Aggregating OAuth APIs for European brokerages would make so much sense.

Thanks! Just checked out Nordigen - love what you're doing.

We've gotten a lot of requests to support European investment accounts and plan on moving into that space in a few months.

Reminds me of https://www.businesswire.com/news/home/20190403005265/en/Tra...

How does your pricing work?

We see ourselves as somewhat of a spiritual successor to TradeIt - we're trying to provide high-quality access to brokerage accounts so that people can build better investing apps on top of existing brokerages.

In terms of pricing: we charge a $300/mo base fee for your first 300 linked brokerage accounts, then $1/linked account/mo thereafter, with reduced pricing at various levels of scale.

Ha, nice! I used to work at TradeIt, and was about to reach out to some of my former co-workers and tell them about you. It's no small undertaking, congrats on the launch.

Hi Daniel, we're already in the comments section :) Hope you're doing well!

Thank you!

Howdy, I used to run engineering at TradeIt. Just curious if any of y'all ever had any interactions with us back in the day, and if any of the brokerages mentioned us (I'm guessing they will either have really nice or really not nice opinions if they remember us, depending on the nature of our integration with them ). We had so many partners on both the broker and developer side, would be fun to know who picked up the torch after we dropped it. Feel free to DM if you ever want to chat about it.

Hey! We first learned about TradeIt a few weeks ago from a friend who works at Drivewealth. It'd be great to chat - please shoot me an email at sean@realizefi.com

why not offering first 3 accounts for free to test integrations? would help massively rather than paying $300 to discover it can't integrate.

We provision both a live and sandbox app with 3 free test links each so that you can test out the API after signing up - we'll make sure to display that more prominently on our site/in our docs to avoid confusion on this point. Thanks for the feedback!

probably my bad, I didn't pay attention to it enough, I just read this post on this particular point. very good, my criticism is not valid then.

Do you plan to offer a more developer friendly pricing?

We're still experimenting with pricing and would be happy to hear your thoughts on what sort of price structure would be more developer friendly. To set our current pricing, we looked at comparable companies like Plaid.

By the way, you can start testing with live accounts for free (maxed out at 3) by creating an account here https://www.realizefi.com/register.

It would be better if e.g. the first 50 can be priced at $5 per user per month and once the growth hits $300, revert to $1 per user.

My co-founder and I almost made the exact same transition you mentioned. Frustration with Plaid and MX made us wonder if we should just built the integrations ourselves and make that our company. We'd be interested in staying in touch and potentially partnering

Sounds good - feel free to email me at sean@realizefi.com

co-founder shot you an email

This is awesome. Reminds me of Plaid. Congratulations on launching and good luck.

We appreciate it!

Thanks!

This is what I exactly need for my startup. We have been struggling with the plaid updates (https://www.watchr.org if anyone is curious).

I'll send you a message!

Congrats on the launch :) I built an integration for 2 brokers and it was such a pain. Plaid didn't work and TradeIt just disappeared. Will definitely take a look.

Thanks! Let us know if you have any questions / want to discuss anything while you're testing it out.

Are you guys planning on adding IBKR integration?

Absolutely. We don't have a timeline on it as of yet, but we've received several requests for IBKR support (especially from developers building apps that serve non-US markets), so it's something we'll be looking into soon.

Congrats on the launch and happy to see you integrated with us (Alpaca Markets - YC W19 - https://alpaca.markets) for both live trading and simulated 'paper' trading!

Thanks!

We <3 Alpaca

Congrats on the launch! I'm the CEO and co-founder of https://teller.io that uses private mobile banking APIs to provide access to bank accounts too, and you're right it's the way to go. We don't think regulation or OAuth based APIs will ever yield an improvement on this approach (explained why here - https://blog.teller.io/2021/06/21/our-mission.html)

You're going to quickly find out that these API endpoints are commonly very well protected as build out your coverage however!

Thanks! Teller looks really cool - there's definitely a real market for what you're doing, though I don't envy your position having to deal with the big banks given how misaligned incentives are in the retail banking industry.

You made some good points about direct integrations - some of the public APIs we deal with are totally separate from the brokerages' internal APIs and that's made painfully apparent during an integration. It has taken us months to get access to prod keys at some of the largest institutions and many of them seek to impose pretty onerous conditions on our customers and their users once we get through their compliance processes. Still, we've seen brokerages becoming more receptive to the idea of opening up their APIs, so we're optimistic that we can form partnerships with them and nudge them toward building better public APIs.

Yea, I'd agree that the misaligned incentives problem isn't nearly as bad for you guys as it in with retail banking. Good luck, rooting for you!

Thanks for commenting - funny enough I was actually telling our team about Teller the other day - it's awesome how much you've been able to achieve. Would be great to stay in touch!