| Related links | Project home | What market? | Data services | Charts and data | ||
| International standards | Some financial terms | Other papers | Data babble |
If you are new to charting and are undecided about the markets you intend to follow, here are some services you should check. These services are very comprehensive, and very different in sectors and content. Medved Quote Tracker,
is not exactly an on-demand charting software, nor an end-of-day
data downloader, but i has almost all the features. For free. Nice free on-line charts expandable to premium services:
More international coverage (free but register): |
On-line charting services:
Off-line charting software:
|
![]() |
Some kind of a road map. My goal is to consolidate financial data from varying sources and find a way to deduct hopefully wise trading decisions. I obviously will need data, store them somewhere. As I am the graphical type of guy, generate some charts.
The data:
Real time data vs. delayed data.
And, do I really need real time?
Can I trade based on delayed data? To the contrary, there are some indicators one could follow as the deep pockets all use the same basic algorythms and will react in concert. So, the trick would be to find indicators which are not acted upon by the short term arbitrageurs, neither traded upon by deep pockets position traders. Say that I can miss the 30% moves of the arbitrageurs, miss the 30% move of the deep pockets position traders, try to keep the 40% between. So, I would have 3 sorts of indicators to rank: the short term ones (mostly generated by real time data), the long ones (deep pockets moving the market to trap the crowd), in the remaining those which could work. Let's face it, equities markets are a market for paper: more and more funds and mutual funds buy an index of shares and the supply is limited. And there are funds of funds. Most of the market for shares currently is bidding up a limited amount of paper (which trend to price higher), arbitrageurs and deep pockets do not care about the fundamentals but can to a certain point manage to make profits by controlling te price movements. Up to a certain point as, with all man-made sytems, something unexpected can happen. A disrupting event can trigger a cascade of trading programs before a human would interfere. This means that we are at the mercy of harsh corrections we cannot predict, even with sophisticaded trading signals, and could lose all our positions. Here again, real time data are a necessity. So, there is a middle point somewhere: some sort of real time data is needed. For the remaining, a good database of end of day data, eventually completed with more or less delayed current data should suffice. One could subscribe for about $12 a month for real time US indexes data. These data (streaming) usually will not be easily grabbed by an alien sytem to the available application. But some index sites do have real time data which can be grabbed from a webpage. Hence, not too difficult to get (not quite real time but) snapshots. As there is a choice to be made of the universe of instruments we want to follow, and a diversity of sources, I feel the need of a database system versatile enough to handle a variety of sources.
What I want: a couple of T1 lines with a Reuters or a Bloomberg terminal ranging $4000 a month. Hence, I can spend a good deal of $4000 a month in time writing my own system, or expense what I really need, can't handle myself or find cheaper than my own time. And in any case make cross-referencing of data possible, which cannot even on a $4000/mo. system: there always will be data you gather on your own. As an own index for instance: the only way to beat a widely diffused index is to design your own, better performing, index. |
![]() |
As in all databases, junk in, junk out. It is to the front end to apply the needed, mostly actuarial, corrections.
It is OK, in my opinion, to only keep one active table for an instrument with our own correction factors provided that: Active table. In my words, the table we are working on. As said before, this one is based on corrections to raw data, but also can be a synthetic table (Cowles plus Dow Industrials as said earlier). As said also, the table should be the exchange's official one, which is not necessarely published every day. A second table (third set of data) is needed for "anything" between the last official update and last day's end of day file. Obviously, the current (real time or delayed) data have to be added. But these series of data should also hold "anything" between the last EOD update and the current prices. On some exchanges 6 or 7 weeks of data can be needed before an EOD update can be made. Some other data are officially "year-to-date". So, a working table really is synthetic collating data of various origins and trustability. Although database engines allow us sophisticated queries, I prefer to keep different tables by origin. Collected data can have any type of structure. It is better, in my opinion, to keep "raw" data as they were collected and pass them through a script in order to arrange them in our own standard structure. Now, if we were hair-cutting some, a closing price has no significance of it's own as it contains a promerited payment of dividends which leads us to fair-value, a concept more common in the futures industry. But deep pocket investors do the math, and they trade on actuarially correct data. Again, to the penalty of not knowing what we analyze, data must be kept as raw as possible, the front-end is the one which handles the corrections and will perform analysis. Ideally, the dates and period for which the corrections are made will better be kept in a table.
We should end up with:
We might, to the penalty of some errors, only work with a "trusted historical" and a dynamically updating year to date table. We also could work, as all the financial packets I know, only with an updating table with full history. We have to use daily downloaded historical if we use the adjusted close field (or have to fill that value with our own math). We can construct a daily table containing the some 40 fields of financial data Yahoo diffuses. Day to day as there is no history available here. Yahoo is taken as an example, there are many other available sources. We could with the help of a "corporate actions" table trace the variations of the fundamentals and calculate the financial data by ourselves based on the synthetic table. As long as we know what we are doing. In my opinion, a one table fits all can only be inaccurate: the wrong solution. Well, this is a goal. In the meantime, I wil use a junk-in, junk-out table as I first would like to generate some charts. But keep the schema in mind. Some data as the commitment of traders reports have to be split in historical plus year-to-date. And further add the complexity of being snapshots on a Tuesday, and have to be compared to daily composite prices with day-1 volumes and open interest which are a sum of individual contracts and many other complexities. As this is the table I am the most interested in, a proper design could easily be extended to the rest of the instruments I follow. Note: one the the big advantages to work with a database you can access is that you would be able to analyze your portfolio, get dated values converted to any chosen base currency and chart every position, determine the winners and the losers, know your risk factor... treat your portfolio as your own index. The prtfolio would be a "corporate action" file among the others and the corporate action file could produce North American profit and losses forms. |
Tools I would use for my charting project:
Some code to get a feeling of it. Not that complcated. |
![]() |
Compilation of 2002 on data and charts for commodity futures. Errors and omissions included. New services appeared, other were merged. As usual, many links are from the old days, before webmasters switched to active content pages.
|