Launch HN: Realize (YC W22) – Integrate brokerage accounts into your site or app (realizefi.com)
Plaid and Yodlee are the main two options for devs building investing apps. However, investment data updates on Plaid/Yodlee are capped at daily frequency, with pulls happening overnight, after market hours. Plaid/Yodlee support a lot of institutions, but the way they collect data causes unreliability when interacting with some of them. And there’s no way to place trades.
We encountered these problems while building a social investing app. We wanted our users to be able to subscribe to other users’ portfolios and be alerted when they placed new trades. This isn’t really possible when order pulls happen only once a day. We also wanted users to be able to “copy trade”, meaning they could replicate other users’ trades in their own brokerage accounts — another feature that wasn’t possible with existing APIs.
We then considered using an embedded brokerage solution like Alpaca, but our users would have had to open a new brokerage account. We talked to some friends who said they wouldn’t want to do that, especially with a brokerage they didn’t know of or trust. As a result of this, we started digging into the APIs of some of the major brokerages such as TD Ameritrade, and realized that although it would be super annoying, it is actually possible to integrate with these brokerages and aggregate them in a way that would allow us to build a fully-functioning investing app on top.
At some point we discovered that other companies were experiencing the same obstacles as us, so we decided instead to build a startup to solve this problem for app and website developers.
Plaid and Yodlee screen scrape in order to provide investing data. (Fun fact: some legacy brokerages have implemented significant countermeasures to screen-scrapers, including blocking suspect user agents and IP addresses, requiring non-headless browsers, presenting subtly different login pages to unfamiliar user agents, bricking links with 2FA, etc.)
We take an entirely different approach by building direct integrations, which increases authentication success rates and allows us to produce more accurate, more frequent data. Our API automatically pulls a user's portfolio positions, order history, transactions, and historical performance at per-minute frequency, and we allow users to send orders to their brokerages.
The quality and accessibility of both public and private brokerage APIs varies significantly. Public APIs for the largest retail brokerages are sparsely and inaccurately documented (the documentation sometimes contradicts the implementation) and many can only be accessed after completing arduous compliance processes with many-month delays. 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.
We have companies building a wide variety of products using our API, such as an app that looks at what is in your portfolio and shows you how those stocks are being discussed on social media, or a copy-trading app which lets you clone other people’s portfolios and execute orders for those positions in your own brokerage account.
We make money as users link accounts to apps that use our API. We’re still working out pricing, but currently charge a base fee of $300 per month for the first 300 linked brokerage accounts, and after that a monthly fee that ranges from $1 to $0.50 per account as the number of linked accounts grows.
You can begin testing our API by heading to https://www.realizefi.com/register and creating a developer account, which ...
96 comments
[ 60.6 ms ] story [ 2695 ms ] threadHow does your pricing work?
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.
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.
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?
Would using this cause accounts to be banned in these direct integrations?
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 :).
Congrats on the launch and good luck! :)
I wonder if this is the problem. If so, I’m glad you are working on this. Best of luck!
> 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?
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.
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.
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
There are? I think what you meant to say is “they haven’t worried much about key distribution, yet”?
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.
Maybe the solution is just to have the jam maker give the neighbor a can?
Europe got this right with PSD2, the US will catch up eventually.
https://en.wikipedia.org/wiki/Payment_Services_Directive
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.
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.
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.
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.
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 :)
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.
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.
- 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.
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.
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).
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.
We've gotten a lot of requests to support European investment accounts and plan on moving into that space in a few months.
Feature wishlist: - Include Interactive Brokers - Support Options in trades
I'd happily drop my current brokerages and switch to a consumer-friendly brokerage that supported this.
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.
You're going to quickly find out that these API endpoints are commonly very well protected as build out your coverage however!
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.