Live data from Hacker News

Selling Data to Hedge Funds (2017)

alternativedata.org

51–59 of 59 posts

Re: Selling Data to Hedge Funds (2017)

#51
post #32
post #23

Earlier quoted context omitted.

Trying to get my credit union to allow users to opt in to sell bulk annon checking account transactions to a hedge fund. Having that much point of sale data would be huge.

uh no, please don't do that. Individual decisions that seem harmless can be incredibly destructive in the aggregate, and this is one of them.

I'm not saying you're wrong, but I am curious what negative trends you believe will emerge from someone actioning this data.

Re: Selling Data to Hedge Funds (2017)

#54
post #32
post #23

Earlier quoted context omitted.

Trying to get my credit union to allow users to opt in to sell bulk annon checking account transactions to a hedge fund. Having that much point of sale data would be huge.

uh no, please don't do that. Individual decisions that seem harmless can be incredibly destructive in the aggregate, and this is one of them.

For those that need an example, a great reminder is the target data mining story at https://www.forbes.com/sites/kashmirhill/2012/02/16/how-targ...

Re: Selling Data to Hedge Funds (2017)

#56
post #44

Earlier quoted context omitted.

If all it is some data scraped off a few web sites that they could get an intern to do in a week or three, then it's unlikely to be valuable enough for them to pay you a substantial sum of money. The most valuable data is data that is difficult to gather. Think things like proprietary (i.e. unpublished) industry data. The canonical "sexy" alternative data set sold to hedge funds is counts of cars in retail parking lo…

> If all it is some data scraped off a few web sites that they could get an intern to do in a week or three, then it's unlikely to be valuable enough for them to pay you a substantial sum of money. If the data is compelling and clearly correlates to earnings KPIs, I can tell you from experience that "some data scraped off a few websites" can be salable to the tune of $50,000/quarter. Hedge funds will frequently choos…

Tbh I've yet to find successful hedge funds that try to reverse engineer stuff. It's just not worth the time for most of these companies.

Re: Selling Data to Hedge Funds (2017)

#57

I recently published a data dashboard( https://public.quantale.io/dashboards/50778f4a-02bb-4d31-b6e... ) using Quantale[1] to show the correlation between Tweet activity of a stock vs the price during the recent stock split of Tesla and Apple. While I believe there are softwares that can collect such data which can definitely be useful to hedge funds but at the same time we should note that the data available to gene…

Hey this is really cool! I am a current data scientist masters student and would love to learn more about your platform! Do you have a way to contact?

thanks, I have my email on my profile.

Re: Selling Data to Hedge Funds (2017)

#58

Numerai hedge fund buys data anonymously, and pays you in cryptocurrency based on its performance: https://medium.com/numerai/building-the-last-hedge-fund-intr...

Um, how is this not an attempt to attract insider information? And trade on it?

Re: Selling Data to Hedge Funds (2017)

#59
post #2

The article mentions having a long history of data, but I want to stress a corollary of this: if you think you might eventually want to sell data, either put your data in an append-only data format now so that history is preserved, or at least take regular snapshots. Otherwise, any time you update the data in place, you make it impossible to reconstruct what the data "looked like at the time" for a backtest.

What do you mean by this? I'm imagining, say, rainfall per day, with a column for date, and a column for rainfall. What's useful about getting the data as it was vs. just having a total dataset with accurate dates.

For something as simple as a sensor reading, you're right, the most natural way to store it is basically an append-only time-series database so it doesn't require much special care.

But say the Rainfall table had a foreign key to a Sensor table that had the coordinates of the sensor. If the physical sensor were moved, the most straightforward data schema would call for the coordinates for the Sensor table to be updated, but then the historic data would have the wrong coordinates if you did a join.

The ideal solution is to design a bitemporal schema so that rows are only ever inserted, not updated, but failing that, regular automatic database snapshots are a good start.

Post reply on HN