Each vendor has their own symbology universe and each exchange, market, or country may have their own standard identifiers. To date the majority of identifiers have also been dynamic, i.e. when a company renames, merges, relocates, the identifier may change. Some symbology systems operate on different levels of granularity whereby prices can be filtered to the exchange rather than just the market. This means you may need a tuple of date, exchange, and identifier to maintain a symbology master.
Standard practice in the U.S. has been to maintain symbology master using agnostic identifiers such as ISIN, SEDOL and CUSIP. Each market data vendor has some form of service for which these identifiers can be converted to their own form.
Continuing the example of Apple Inc,
Ticker: AAPL
Exchange: <US Composite>
RIC: AAPL.O
PermID: 4295905573
ISIN: US0378331005
CUSIP: 037833100
SEDOL: 2046251
Exchange: Nasdaq (US primary)
RIC: AAPL.OQ
PermID: 55835312773
SEDOL: 2046251 (same)
Exchange: Arca
RIC: AAPL.P
PermID: 55837087061
SEDOL: 2046251 (same)
Exchange: <German Composite>
RIC: AAPL.DEU
PermID: 21474884975
SEDOL: 4033819
Exchange: Berlin
RIC: AAPL.BE
PermID: 55836323023
SEDOL: 4033819 (same as German composite)
Both Bloomberg and Reuters are making attempts at permanent identifiers with Bloomberg Open Symbology and Open PermID respectively.
Programmatically you have options with Bloomberg as listed in the comments by @assylias and similarly Thomson Reuters has new features with Eikon. For larger apps one would have to look at developing a dedicated symbology service that can be updated and managed independently. I
I have written an example service for Thomson Reuters TREP that uses Tick History or the Data Scope Select service for sourcing the Reuters universe. One re-uses any existing TREP API to resolve the symbology then can pull in the underlying instrument, example viewing of the data:
