

Ask HN: Demand for a cheaper, dev-friendly Yodlee alternative? - steveg

There's a lot of opportunity to build apps if you can collect a person's financial accounts (examples: Mint, inDinero).<p>Right now the options are DIY or contract prohibitively expensive services like Yodlee and CashEdge.<p>I'm wondering what sort of opportunity exists if there was a inexpensive, developer-friendly financial account aggregation service?
======
joncooper
I'm not sure that the total amount of money you can make by providing such a
platform to customers is greater than the amount of money it will cost to
build it.

The main problem from a cost perspective is that there isn't a whole lot of
engineering leverage to bring to bear. Every integration is custom, which
means that the number of integrations built scales roughly linearly vs the
number of people you have building them.

That said, Yodlee has already spent an enormous amount of money doing it.
(And, from what I can tell, is de-emphasizing providing this sort of service
as a component of their revenue mix.)

Yodlee can price the service at a margin above their marginal cost. (i.e.,
they have paid to build the integrations, now they just need to operate the
servers & do maintenance). I doubt very much that any startup can compete on
price.

It would be a layup to beat Yodlee in terms of developer friendliness (even
caring the tiniest amount would do it), but delivering the functionality is
IMO probably not going to happen.

(Note: I have written a Yodlee integration from scratch and am working on a
different (large) project using it now.)

~~~
steveg
Valid points.

There is no question that competing on account coverage is nearly impossible
since Yodlee/CashEdge claim to support 10-12k interfaces.

While I do agree that building out really wide coverage initially would be
extremely capital-intensive, what about just building out the top 20, 50, 100
institutions? I would imagine that accounts have a very long tail, but
supporting the top banks would yield the majority of accounts. Of course with
aggregation, limited bank support can ruin your value proposition. But what if
you build-on-demand? I mean, you build out support for the top 50 banks, then
rapidly build out new ones as they are demanded? Still costs a lot of money,
but if you can get revenue to roll in then it's more manageable.

A lot of online bank UI's offer the same data options (download CSV, MS Money,
Quicken, etc). I really see 3 big activities that can be abstracted, then
customized based on URL structure and UI: 1\. Login and security verification
2\. Gather account information (nicknames, balance, limits, interest, etc) 3\.
Gather account transactions (download statements in one of the provided
formats) Many of these formats even include categorization text or SIC
numbers.

Normalizing the data would be a pain the ass, but could get better as you have
more raw bank data to analyze.

Of course, there will be tons of outliers, but a lot of banks could be
supported with slight modifications.

Just feel like this whole aggregation space is ripe for some disruption.

~~~
joncooper
I would run as far and fast away from this idea as possible.

Implementing this is a horrendous sucking morass of death and the best
available evidence (Yodlee) suggests that it's not an especially profitable
service to provide.

------
djb_hackernews
I worked at a startup that was a financial account aggregator, and helped
build the technology behind it, though we targeted a different market than
Mint etc target.

I can answer questions but it takes a hell of a lot of engineering to build
something to even support 50-100 institutions. There are just tons of barriers
technically.

I think your best bet would be to license data from an existing provider and
build out your own support as you go along.

