Bloomberg Country Codes: 2026 Reference

What are Bloomberg country codes?

A Bloomberg country code is the one or two character pricing-source suffix appended to a ticker root to identify the venue or country in which that specific line trades, as in BMW GR Equity. It is not a description of the issuer, and it is not an ISO country code, although it looks like one and sometimes coincides with one.

That last point is where most reconciliation work goes wrong. The phrase "Bloomberg country code" is used in the field for at least three different data elements: the suffix inside the ticker string, the descriptive country fields attached to a security record such as country of risk and country of domicile, and plain ISO 3166-1 alpha-2 codes that happen to appear in the same file next to Bloomberg-sourced columns.

Every reference list that ranks for this term publishes the flat two-column table and stops. A flat table is useful for reading a ticker out loud. It is not sufficient for loading a constituent file into a mapping table, because a bare two-letter string carries no indication of which scheme emitted it.

This guide separates the three meanings, shows exactly where Bloomberg's suffixes and ISO 3166 disagree using only codes Bloomberg publishes itself, and then deals with the part the lists ignore: reconciling a suffixed ticker against FIGI, ISIN and MIC when index and ETF constituent files land daily.

The three things people mean by a Bloomberg country code

Three distinct data elements share the name. The pricing-source suffix identifies a trading venue or country of listing, the country of risk and country of domicile fields describe the issuer, and ISO 3166-1 alpha-2 is an external standard that neither of the first two is bound to follow.

The practical consequence is that "country" in a holdings file answers at least three different questions, and the column header rarely tells you which one. A German-incorporated manufacturer with a London line and an over-the-counter US depositary receipt can legitimately carry three different two-letter codes in three different fields of the same record, none of which is wrong.

Portfolio and risk systems almost always want the issuer-level field, because they are aggregating exposure. Execution and market data systems want the venue-level suffix, because they are pricing a specific line. Regulatory extracts usually want ISO. Storing one value in a column called country and expecting all three consumers to be satisfied is the root failure.

Bloomberg country codes vs ISO 3166 country codes

They are different schemes with different purposes, and they disagree on several major markets. ISO 3166-1 alpha-2 identifies countries and territories; Bloomberg's suffix identifies where an instrument prices, which is why the two lists diverge exactly where a large exchange sits in a country whose ISO code was already taken or where the suffix follows the venue rather than the state.

The ISO side is the stable one. As published on isin.net's ISO 3166-1 page, the standard's list contains 249 official short names and code elements, and it is updated when the ISO 3166 Maintenance Agency makes a change. That gives you a dated, versioned reference with a named custodian.

Using only codes that appear on Bloomberg's own Help Center page covering common country and exchange codes, the divergences are easy to see:

Note what this table does to naive validation logic. AU, HK, JP and US are identical in both schemes, so a test suite built on those four passes cleanly and tells you nothing. The first German or French line that arrives is where the mapping breaks, and it breaks silently, because GR is a perfectly valid ISO code for Greece.

That is the sentence worth keeping: a two-letter string is not self-describing. GR means Germany if Bloomberg emitted it as a pricing source and Greece if an ISO-based system emitted it, and nothing in the value itself resolves the ambiguity. You must record the scheme alongside the code or you have stored a guess.

How a Bloomberg ticker is actually assembled

A Bloomberg ticker is a composite of three parts: a root symbol, a country or exchange code, and a market sector qualifier such as Equity, Index, Corp or Curncy. The three together identify one tradeable line on one venue in one asset class, which is why the same issuer can hold several valid tickers at once.

Take BMW. Bloomberg's own help material writes the root and country pair in colon form, BMW:GR, while terminal and file conventions append the market sector to give BMW GR Equity. The root BMW is the issuer's symbol, GR is the German pricing source, and Equity states the asset class so the same root cannot collide with an index or a bond.

Drop any one component and the string stops being an identifier. BMW alone is ambiguous across markets, BMW GR is ambiguous across asset classes, and a root reused in a second market resolves only through the suffix. This is precisely why the suffix cannot be treated as decorative metadata when parsing a constituent file.

Composite versus primary-exchange codes

A composite code aggregates activity across the trading venues of a country or region, while an exchange-specific code points at one venue. The distinction matters because the two can return different values for the same field on the same day.

Pull shares outstanding or market capitalisation against a composite ticker and you are asking about the issuer's line at the country level. Pull against a single exchange and you may be asking about one listing of several. In an index-weight reconciliation, mixing the two across files is a common cause of a country bucket that moves for no economic reason.

The practical rule is to fix one convention per pipeline, record which one you chose, and never let two upstream files with different conventions merge on ticker alone. If you are already grouping holdings for analysis, the same discipline applies to classification joins, which is the subject of our ETF List by Sector: 2026 Classification Guide.

Bloomberg country of risk codes and why they differ from the ticker

Country of risk is an analytical assignment about where economic exposure sits. It is a judgement about the issuer, not an observation about the venue, so it can differ from the country implied by the ticker suffix and from the country of domicile at the same time.

Picture a company incorporated in Ireland, primarily listed in London, and earning most of its revenue in the United States. The ticker suffix says the line prices in the UK, domicile says Ireland, and a risk assignment could reasonably say the United States. All three are correct answers to different questions, and a system that collapses them into one column has destroyed information it cannot recover.

The downstream effects are not cosmetic. Index eligibility rules frequently reference domicile or risk rather than listing venue, country weight aggregation changes depending on which field you group by, and regulatory reporting usually specifies the field explicitly. Two analysts producing a country exposure report from the same holdings file can differ by hundreds of basis points purely on field choice.

One honest limit here: Bloomberg does not publish its country-of-risk methodology on an open page. Any third-party restatement of how the assignment is made, including confident summaries circulating in forums and PDFs, should be treated as unverified and checked in the terminal against the field definition itself.

Bloomberg country codes list: what to trust and what to verify

Trust the codes Bloomberg publishes on its own Help Center page, and treat everything else as a lead rather than a source. The set Bloomberg publishes there is explicitly a common set covering major markets, not the full universe of pricing sources, and treating it as exhaustive is its own failure mode.

The widely circulated "full" lists are the problem. The Scribd document titled "Bloomberg Country Codes Overview" that ranks for this query is a user upload with no publication date, no named author and no revision history, which means you cannot tell whether a code in it was accurate in 2013 or last month. Loading an undated user upload into a production mapping table is how a retired pricing source survives in your reference data for years.

A workable verification path has three steps:

1. Resolve the code inside the terminal itself, which is the authoritative source for Bloomberg's own definitions.
2. Cross-check the venue against a Market Identifier Code reference, such as the Bloomberg exchange code mapping InfoReach publishes, so you have a second scheme pointing at the same venue.
3. Date the entry in your own table with the day you verified it, and keep the prior value rather than overwriting it.

If you cannot complete step one for a given code, do not add the row. An unresolved suffix sitting in a mapping table with a plausible-looking country attached is worse than a null, because nothing downstream will ever flag it. Our Bloomberg Extensions page covers how AmericanETP files carry Bloomberg-format identifiers so that fewer of these lookups are needed in the first place.

Mapping country codes to FIGI, ISIN and MIC

Identifier triangulation beats string parsing. A country code is a one-dimensional hint; FIGI, ISIN and MIC each pin down a different dimension of the same security, and joining on them removes the need to interpret a suffix at all.

ISIN introduces yet another country code into the same record, and it means something different again. The two-character ISIN prefix reflects the national numbering agency that issued the identifier, not the trading venue and not the country of risk. An issuer can therefore show an ISIN prefix that matches neither its ticker suffix nor its domicile field, which is entirely correct and entirely confusing if you assumed the three would agree.

FIGI works the other way. It is venue-specific by construction, so a single share line carries a separate FIGI for each exchange it trades on, plus a composite level identifier and a share class level identifier above those. That hierarchy is exactly what you need when the question is whether two rows in two files are the same listing, the same security in two venues, or two share classes of the same issuer.

AmericanETP includes Bloomberg FIGIs in its constituent list holdings files, which gives a join key that does not depend on parsing a suffix or trusting a country string. For teams evaluating how constituent-level identifier coverage differs across vendors, ETF Global vs FactSet: 2026 Compared walks through the same question from the product side.

Where country codes break in ETF and index constituent workflows

Country codes break in predictable, repeatable ways, and almost all of them show up as a country weight that moves without a corresponding price move. The four most common are double-counted depositary receipts, cross-listings inflating a country bucket, reused ticker roots, and silent domicile changes between files.

Here is a constructed example with arithmetic you can follow; the numbers are illustrative, not reported index data. Suppose a global equity ETF holds a German manufacturer at 0.40% weight on the local line, tagged GR, and an unsponsored US depositary receipt on the same issuer at 0.15%, tagged US. Group by ticker suffix and the German bucket reads 0.40% while the US bucket carries 0.15% of German exposure. Group by issuer FIGI at the share class level and you get one position at 0.55%, correctly assigned. The 15 basis point discrepancy is small enough to survive review and large enough to matter in an attribution report.

The other three failures follow the same shape. A cross-listed issuer appearing in two country buckets inflates both. A ticker root reused in two markets, where the suffix is the only disambiguator, merges two unrelated companies if the suffix is dropped during a CSV import. A corporate domicile change moves a holding from one country bucket to another between two consecutive files, with no trade and no announcement in your own data.

Catching these depends on when you see the change. AmericanETP refreshes constituent lists twice daily, with a 6pm EST primary run and a secondary run around noon EST, across 3878 US and global indexes and US-traded ETFs, which means a country reassignment surfaces in a file-to-file diff on the day it lands rather than at month end when the attribution report is already circulating. Running that diff is your own step: two consecutive constituent files, compared row by row on a stable identifier. Teams comparing delivery models for this kind of monitoring may find Best ETF Global Alternatives 2026 a useful survey.

A reconciliation checklist for country-coded holdings files

The procedure below turns the three-way distinction into storage and join rules. It is deliberately boring, and it eliminates the majority of country-attribution defects before they reach a report.

1. Record the emitting scheme with every code. Never store a bare two-letter string. A country_code column needs a companion code_scheme column with values such as bloomberg_pricing_source, iso_3166_1_alpha2 or isin_prefix.
2. Separate venue from issuer. Keep the ticker suffix and the issuer-level country fields in different columns, and make the reporting layer state which one it grouped by.
3. Join on FIGI or ISIN first. Use the country code as a validation check on the join, never as the join key. When the key and the country disagree, flag the row rather than picking a winner.
4. Version the mapping table. Keep dated rows with effective dates rather than overwriting. A code that was correct in 2019 and wrong now should be visible as a history, not erased.
5. Re-run against a point-in-time snapshot when a weight moves. If a country bucket shifts unexpectedly, rebuild the same aggregation from the archived file for the prior date and diff the two outputs rather than debating the current one.

Step five needs an archive to be possible at all. AmericanETP retains archived constituent list datafiles back to July 2009 and offers FTP access, so a point-in-time re-run is a file fetch rather than a vendor request, and the Downloads area is where those files are pulled from. For a side-by-side on how this archive-and-diff workflow compares with a research-platform approach, see AmericanETP vs Morningstar: 2026.

Do you need a terminal to work with country-coded data?

For Bloomberg's own code definitions and country of risk assignments, yes. The terminal is the authoritative source for what a pricing source means, how a field is defined and which value Bloomberg currently assigns to a given security, and no third-party file replaces it for adjudicating those questions.

It is also better than any file feed at the interactive work: resolving an unfamiliar suffix in seconds, reading the field definition alongside the value, checking how an issuer's listings relate to each other, and doing it for one security at a time while a question is still open. If your job involves answering ad hoc identifier questions, that is what the instrument is for.

Where a per-seat terminal is the wrong instrument is bulk constituent ingestion. Loading thousands of index and ETF holdings lists into a research database every evening is a file-delivery problem, and it does not become a better problem by attaching a seat licence to it. AmericanETP's pricing is published plainly: $1500 per year or $150 per month for an individual, and $2500 per year or $250 per month firm-wide.

Most competing constituent data vendors publish little or no open pricing, so any figure you have seen quoted for them in a forum or a slide deck should be treated as unverified until you see it on their current pricing page. We have written up what is and is not publicly documented in Morningstar Pricing 2026: Every Tier, and surveyed the wider field in Morningstar Alternatives: 2026 Options.

FAQ

What is the list of Bloomberg country codes?

Bloomberg publishes a set of common country and exchange codes on its Help Center, including FP for France, GR for Germany, IM for Italy, LN for the United Kingdom, SM for Spain, AU for Australia, HK for Hong Kong, JP for Japan, BZ for Brazil and US for the United States. That published set is the common list, not the complete universe of pricing sources. Longer lists circulating as undated PDF uploads have no revision history and should not be loaded into a production mapping table without verification in the terminal.

What are the Bloomberg index codes?

Index tickers follow the same three-part structure as equity tickers, with a root, a country or exchange code where applicable, and the market sector qualifier Index in place of Equity. The qualifier is what prevents an index root from colliding with an equity root that happens to share the same characters. When you are loading index constituent files, the qualifier should be preserved in storage rather than stripped during import.

What is the Bloomberg code for a stock?

The Bloomberg code for a stock is its ticker: a root symbol, a country or exchange suffix, and the market sector qualifier, written for example as BMW GR Equity. Bloomberg's own help material also shows the root and country pair in colon form, BMW:GR. The same issuer can hold several valid tickers at once, one for each venue where a line trades, plus composite forms.

How do I check a country code in a holdings file?

First determine which scheme emitted the column, because a two-letter code is meaningless without that. Compare the value against the ISO 3166-1 list and against Bloomberg's published pricing source codes; if it resolves differently in each, the scheme matters and you must find out which one the file uses. Then confirm the security through FIGI or ISIN rather than through the country string, and treat the country value as a check on that join instead of as the join key.

Are Bloomberg country codes the same as ISO 3166 codes?

No. They agree on some markets, including AU, HK, JP and US, and disagree on others, including Germany where Bloomberg uses GR against ISO DE and the United Kingdom where Bloomberg uses LN against ISO GB. The overlap is what makes the difference dangerous, because validation logic tested only on the matching codes will pass. ISO 3166-1 is maintained externally: according to isin.net, the list holds 249 official short names and code elements and is updated when the ISO 3166 Maintenance Agency changes it.

What is the difference between country of risk and country of domicile on Bloomberg?

Country of domicile records where an issuer is legally incorporated or based, while country of risk is an analytical assignment about where its economic exposure actually sits. The two diverge routinely for holding companies, cross-border operators and issuers whose revenue base differs from their incorporation jurisdiction. Bloomberg does not publish its country-of-risk methodology on an open page, so the field definition should be read inside the terminal rather than taken from a third-party summary.

---

AmericanETP has been publishing constituent data since the 1990s, originally as MasterDATA, and delivers twice-daily ETF and index constituent files with Bloomberg FIGIs, fundamentals and archives back to July 2009. See what is in the files, or get in touch with a mapping question and we will tell you what the files can and cannot resolve.