We incorporated FIGI data which, at the moment, is only visible in a screen Report. We added it to the default P123 report, and you can also add it to your custom reports. There's also a new function FIGI("figi1,figi2,..") which you can use to search for specific FIGIs.
Let us know how you want to use FIGI so we can add support in other places. The next obvious ones are in the Stock → Issues page and when you download using Factor List or API. Let us know precisely where you need them so we can focus our efforts where needed. Thanks
Edit: You can choose between Share Class and Country Composite FIGIs.
I’m exporting my ranks from p123 using the /rank/ranks API endpoint, so that I can simulate my short trading with accurate borrow rates. Without FIGIs available on the p123 side, I have to map symbols using symbology which fail to map ~4-8% symbols depending on the heuristic employed – not to mention any false positives which I’m not currently catching. If I had FIGI identifiers on my p123 ranks, this error rate should drop to near 0.
For this use case, it would be great if I could just add “FIGI” to the additionalData parameter of the /rank/ranks API so that I could download it just like any other data series.
FIGI is an open security identification standard developed by Bloomberg for all kinds of financial instruments. For stocks, it’s important to reference the securities by a security id instead of by ticker as the ticker can change over time due to corporate changes (hence why p123 internally uses a StockID) and different organizations may adopt different symbol naming schemes.
It’s common to use security identifiers when joining financial datasets or integrating two systems, and there are other commonly used security identifiers in use like CUSIP, ISIN, and SEDOL, but those are proprietary. Bloomberg opened their standard up and it is free to use and query.
Will do. We need to nail down which FIGI level is ideal. Is the Global Share Class the best to expose ? The time to switch is now since nobody is using them, and I don’t think we need other two levels.
No, I believe “Country Composite Level” is the best FIGI identifier to expose if you were going to pick one. If I look at BDT:CAN and BIRDF:USA (its F share equivalent in the US), they both map to the same shareClassFIGI, but I probably will want to differentiate when I map to a security in the downstream trading system as the former trades ~150k shares a day while the latter only ~1k shares a day.
The system I am integrating with, QuantRocket, uses compositeFIGI identifiers for this reason, so if p123 were to expose compositeFIGIs, it would also make integration trivial.
For both clarity and future proofing, it’s probably best in p123 to label the FIGI identifiers with the names used in the OpenFIGI schema/API (shareClassFIGI, compositeFIGI, and figi) in case other levels are needed in the future.
Marco, another use case where it would be useful to support FIGIs is Imported Stock Factors. I upload these indexed by ticker now, but it would be less error prone to upload factors indexed by a FIGI id, much like you can do today with CUSIPs. This would be another argument to support compositeFIGIs so that you could do a one-to-one mapping of securities even if they are cross-listed in multiple countries.
scFIGI has some things going for it. Namely, you can create holdout sets that exclude BIRDF:USA, when you are datamining a group of stocks that includes BDT:CAN. @feldy
But to add another wrinkle, I just checked UHRN:CHE vs SWGAY:USA and those have different scFIGI because they are indeed different share classes, so scFIGI is not going to help ALWAYS in the above sense.
IsPrimary seems most useful then for excluding secondary listings from your holdout.
Thank you to Marco and Dan and the rest of the p123 team for the addition of FIGI identifiers. Prior to their availability, I was using a multi-faceted heuristic of fuzzy ticker matching and delisting status to map p123 rank data to QuantRocket securities. For older dates, I was failing to map 8+% of security-dates which means I had to discard ranks for those symbols, and those failed mappings were more frequent with smaller cap names. I'm also not even accounting for false positive mappings where I've mistakenly mapped a p123 rank to the wrong security.
With FIGIs now available in the /rank/ranks endpoint, the mapping is trivial and these problems go away.
Would still be nice to eventually support FIGIs for imported stock factors.
