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.

“I ask my neighbours for some of their apples, but if they don’t give them, I go into their garden at nighttime with a big ladder…”

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.