[HN Gopher] Launch HN: Realize (YC W22) - Integrate brokerage ac...
___________________________________________________________________
Launch HN: Realize (YC W22) - Integrate brokerage accounts into
your site or app
Hi HN, We're Sean, Curtis and Tim from Realize
(https://www.realizefi.com/). Realize is an API that lets you
integrate your website or mobile app with popular retail
brokerages. Your users can view near-real-time data and make trades
from their existing brokerage accounts. 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 will give you access to an app to which you can link
institutions. We'd love to hear your ideas and feedback! We'll be
online today to answer any questions - we're always excited to talk
about investing, fintech, APIs, etc.
Author : seandoh
Score : 67 points
Date : 2022-02-16 15:51 UTC (7 hours ago)
(HTM) web link (www.realizefi.com)
(TXT) w3m dump (www.realizefi.com)
| 8lueberry wrote:
| 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.
| seandoh wrote:
| Thanks! Let us know if you have any questions / want to discuss
| anything while you're testing it out.
| stefanba3 wrote:
| 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.
| wisdomtt wrote:
| 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.
| seandoh wrote:
| Thanks!
| vmception wrote:
| 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.
| timothygoltser wrote:
| 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.
| bradhilton wrote:
| 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...
| toomuchtodo wrote:
| 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
| seandoh wrote:
| That's how we are thinking about this as well.
| koolba wrote:
| 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.
| danielvaughn wrote:
| 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.
| timothygoltser wrote:
| 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 :)
| timothygoltser wrote:
| 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.
| sthatipamala wrote:
| 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!
| wisdomtt wrote:
| 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.
| melony wrote:
| Reminds me of
| https://www.businesswire.com/news/home/20190403005265/en/Tra...
|
| How does your pricing work?
| timothygoltser wrote:
| 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.
| melony wrote:
| Do you plan to offer a more developer friendly pricing?
| seandoh wrote:
| 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.
| LittleGecko wrote:
| why not offering first 3 accounts for free to test
| integrations? would help massively rather than paying $300 to
| discover it can't integrate.
| timothygoltser wrote:
| 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!
| danielvaughn wrote:
| 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.
| seandoh wrote:
| Thank you!
| wizwit999 wrote:
| 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?
| timothygoltser wrote:
| 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.
| [deleted]
| hemloc_io wrote:
| 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?
| timothygoltser wrote:
| 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 :).
| hemloc_io wrote:
| Haha awesome thanks for your response this seems like a
| super useful service.
|
| Congrats on the launch and good luck! :)
| seandoh wrote:
| Thanks for checking us out - really appreciate it.
| [deleted]
| ceejayoz wrote:
| > 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?
| rmbyrro wrote:
| This sounds like backwards to how this industry should be
| evolving...
| wisdomtt wrote:
| 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.
| captn3m0 wrote:
| Who is liable if the user's brokerage account gets blocked?
| timothygoltser wrote:
| 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.
| melony wrote:
| 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)?
| jhirschi wrote:
| 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
| timothygoltser wrote:
| 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.
| seandoh wrote:
| 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.
| timothygoltser wrote:
| 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.
| ceejayoz wrote:
| I think "direct integrations" as a euphemism from "using
| reverse-engineered private APIs in violation of their terms"
| is dishonest.
| timothygoltser wrote:
| 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.
| alistairclark7 wrote:
| 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.
| seandoh wrote:
| This sounds good - thank you for the feedback.
| namdnay wrote:
| "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..."
| not_exactly__ wrote:
| 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?
| namdnay wrote:
| 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"
| svnt wrote:
| > 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"?
| timothygoltser wrote:
| 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.
| fsn4dN69ey wrote:
| Are you guys planning on adding IBKR integration?
| timothygoltser wrote:
| 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.
| vmception wrote:
| 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.
| timothygoltser wrote:
| 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.
| KerryJones wrote:
| 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
| timothygoltser wrote:
| 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.
| kintalo wrote:
| This is awesome. Reminds me of Plaid. Congratulations on
| launching and good luck.
| seandoh wrote:
| We appreciate it!
| timothygoltser wrote:
| Thanks!
| jhirschi wrote:
| 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
| seandoh wrote:
| Sounds good - feel free to email me at sean@realizefi.com
| jhirschi wrote:
| co-founder shot you an email
| rmesters wrote:
| 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.
| seandoh wrote:
| 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.
| raja wrote:
| 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!
| wisdomtt wrote:
| Thanks!
| sv123 wrote:
| 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.
| timothygoltser wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-16 23:00 UTC)