SOLUTION: detecting NS strikes (when not marked in the data) As is nastily well known, some options data sources (for example YF-API ) do not differentiate between normal standard strikes and Non-Standard (NS) strikes, ie. both are mixed in the same chain table without any markings for the NS strikes. Of course such data is not usable! But at the same time it's not possible to know whether its usable or not usable b/c one simply does not know whether it's NS!... Of course a real dilemma... BUT I today finally have found a solution to make this data still usable! Some programming (or scripting) is required. Here the solution: Step 1: Before market opens, get a daily list that has all the valid strikes (see below). Step 2: Test whether strike is NS by looking up in the list from Step 1. Voila! Problem cleverly solved! Downloading daily list of US options as CSV file (UnderlyingTicker, ExpDates, Strikes, ...): $ wget -O options.csv "ftp://ftp.nasdaqtrader.com/SymbolDirectory/options.txt" Example excerpt: Code: ... SKLZ|N|C|03/15/2024|1.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|2.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|3.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|4.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|5.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|6.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|7.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|8.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|C|03/15/2024|9.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|1.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|2.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|3.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|4.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|5.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|6.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|7.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|8.000|SKLZ|Skillz Inc. Class A|N SKLZ|N|P|03/15/2024|9.000|SKLZ|Skillz Inc. Class A|N ... The options data from YahooFinance (Web or via API) has additionally the Put NS strike 1.5 and Call NS strike 0.5. As can be seen, these nasty NS strikes now can be detected and filtered out by looking up in the above list.
Just detected: The above solution not only detects the said NS strikes, but finds also other buggy strikes like this buggy case at YahooFinance: TMV ExpDate=2024-02-16 lists Call strike 115 (even with a huge IV of 3,433.59(!) ), and even some more strikes, which is/are non-existent at other brokerages nor in the above said options.csv file. Applying the above solution will detect also such buggy cases! Especially YahooFinance itself as the source of tons of such buggy options data needs to apply this very solution ASAP to their buggy options data, which it also sells to unsuspecting victim clients, customers, and API users... Really a shame for a such a big company to sell options data that is so much buggy. Clearly they need to fix this mess in their options data. Another company specialized on options data and sells options scanning services to their users, but which also has many bugs in their data is https://marketchameleon.com/. That company too needs to apply this fix to their buggy data. Example: they list MULN with a high IV on this scanner output, but MULN completely has become NS long ago, so the result is definitely wrong, and therefore should be removed from the scanner result. Maybe that company is using the same buggy YahooFinance data as their options data source
A Public Call to Everyone Regarding Buggy Market Data : All users, clients, customers (via Web or API) of such companies who use/publish/sell such massive buggy market data should file a complaint to the complaints department of the company, and demand that the data be fixed. Even SEC etc. should be informed, since these companies with their buggy data (and services based on such buggy data) commit knowingly or unknowingly or maybe even intentionally a mass fraud by misleading their users/clients/customers as well the public. Ie. one can say they practice or suport market manipulation by misleading investors, and also causing financial damage to investors (b/c it leads to making poor trade decisions), with such buggy/inaccurate market data. And we users should also publicly document the bugs we discover, so to force these companies to fix their mess. Such bad practices of such companies should not be tolerated by the users. Quality has to return to the market data, which as everybody knows is the basis for making trading decisions. Folks, collect and compile evidence, and then present your findings and file an official complaint.