timothygoltser

Hey all, one of the co-founders of Olli here - I'll be around to answer any questions you might have

Hey Charles, we're really excited to be working on tooling to make data sharing easier for companies and their customers!

The activation energy for setting up robust direct-to-customer pipelines is still too high on the provider’s end - it’s great to see this approach getting more investment recently.

All the best to Prequel as well!

Thank you - we'll submit a proposal shortly!

Thanks!

Hey all, one of the co-founders of Pipebird here - I'll be around to answer any questions you might have. Would love to hear your feedback!

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.

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.

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.

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!

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.

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.

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 :)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 :).

Thanks!

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.

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.