From OpenStreetMap Wiki
Jump to: navigation, search

Proposed icon

Hello, I think, this amenity needs an icon, which will be displayed on rendered maps. Here my purposal:


Feel free to use it, if it convinced. I declare, that I'm the creator of this pictogram, so it is public domain.

TomsDidi 21:48, 09 May 2008 (UTC)

One problem: This symbol only apply to banks in Euro-zone. More international please. I remember there was a symbol with Euro, Dollar, Yen, and British Pounds. But forget where I saw it. Something like that in a house would work for me. --Bahnpirat 06:56, 10 May 2008 (UTC)

Hm... ;-) OK... perhaps like this one? I will try to get it sharper...


TomsDidi 18:16, 10 May 2008 (UTC)

Bureau de change.png
They are now in "diamond"-position (top-left-right-bottom). Wouldn't it be better in "square"-position (top-left,top-right, bottom-left,bottom-right)? Thus, the symbol is good enough to use now. What about a green house, like Dollar? Well Euro is blue and Yen is ...? Color doesn't matter at all. But I don't want just black symbols on the map. I found the symbol with the four currencies. --Bahnpirat 12:46, 13 May 2008 (UTC)

Yes, I know this symbol, but it is used for little offices, where you can exchange money. That's why I'm searching for an other symbol for a bank. A bank is more then money exchange.

TomsDidi 18:11, 14 May 2008 (UTC)

What about this? Bank2.png --Bahnpirat 06:35, 17 May 2008 (UTC)

atm tagging

Map_Features#Amenity says : "a bank (for a bank that also has an ATM, use amenity=bank and atm=yes)". there's also amenity=atm, so in the end we have at least two ways to tag atms... seems confusing to me. also, this supplemental tag is not listed on this page. i think amenity=atm would be better tag to use in all situations. marking it as connected to the particular bank branch could be done with relations (if required at all). User:Richlv 09:12, 17 September 2008

I agree. Although since the operator of the bank is going to be the same as the ATM, could we use "amenity=bank;atm, operator=HSBC"? User:Timmmm 14:39, 28 March 2009
This bank;atm semicolon notation is unlikely to be interpreted correctly by many existing tools. I appreciate that this isn't necessarily a reason to not use it, so let me give you other reasons...
As I see it, the preferred approach should be to put in separate nodes for these things. I will update the page accordingly. As User:Richlv said. amenity=atm is a better tag to use in all situations. But it's a level of detail thing. The level of detail we should strive for / progress towards, is to put the ATM (or multiple ATMs) as nodes separate to the bank. It's useful as the obvious way to indicate the number of ATMs and which side of the building they're on. However I can imagine mappers might prefer to slap in atm=yes on a bank node out of laziness, or because they don't have detailed notes of where the ATM is in relation to the bank.
Linking the ATM to the bank via some name/operator matching... yes it's a difficult problem, but it's also a very low priority problem. As and when somebody needs to write software which makes such a link (struggling to think why really) then the developer may have to do some basic location heuristics.
-- Harry Wood 11:48, 9 June 2009 (UTC)

I disagree about amenity=atm being the correct tag to use in all situations, simply because there aren't any really good ways to render that. If you have a bank with four atms outside and two inside and you mark all of them separately your render is going to be a mess even at zoom level 18 because it will be trying to render 7 nodes in approximately the same location. Also, using relations to show that an atm is connected with a bank is just an incredibly clunky and mapper unfriendly method. Also, the atm=* tag can easily denote the number of atms as well. Just use atm=# of atms (eg, atm=3.) When I map I actually use an extended version of the atm tag. The tags I use are as follows:

Tag Description
outside_atm=* Yes, No, #. These are atms that are outside and available 24 hours a day.
vestibule_atm=* Yes, No, #. These atms are available 24 hours a day but are in a vestibule. Access is granted by swiping your atm card through a reader in a door.
inside_atm=* Yes, No, #. These are atms that are only available during the banks hours of operation.
drive_through_atm=* Yes, No, #. Available 24 hours a day. Not all that common but you do see a few of them around.
depository=* Yes or No. A night depository box. Used by business customers who need to deposit money after hours. The boxes are usually outside but are sometimes in a vestibule as well.

This doesn't give you the which side of the bank is the atm on information but I don't think thats as big of a problem as being able to render the data in a sane manner. For standalone atms unconnected to a bank I use an operator tag to denote which company runs the atm tag and a capacity tag to denote how many atms are at that location. If there is a set of three HSBC atms I will only put one node and then a capacity=3 tag. The outside, inside etc information is important because it allows for time constrained routing. For instance if you told your OSM routing enabled phone to find you the nearest open Wells Fargo atm it wouldn't point you to one inside a closed bank or grocery store. I have been thinking however that changing the tags a bit to atm:inside=*, atm:outside=* might fit better with standard OSM conventions. Thoughts? Gregory Arenius 09:52, 21 June 2009 (UTC)

Name/Operator tagging

In Tag:amenity=atm the bank's name is proposed to be tagged by "operator". Mapnik does not render names at all. Osmarender does render 'name=' at zoom 17 but does not render 'operator='. I think it is very important to use whatever the Name finder is looking for to search on. I would think it is 'name', and not 'operator'.--Mdeen 11:08, 5 December 2008 (UTC)

Operator allows for a map with bank logos to be rendered, or even to single out only banks of one specific operator. That will increase the usability of the map, and gives us the ability to search for terms like "all the banks of <insert operator> in <city>" or nearest <bank of operator> to <my location>". --Skippern 11:48, 5 December 2008 (UTC)

Moved from main page (clean-up)

Original Proposal

We have no formal tags for banks, ATM (Automated Teller Machines) / Cash Points, or money changers. I propose that these be added specifically to the amenity= tag rather than anything else as the are indeed basic amenities sought by travellors and tourists.

MikeCollinson 05:03, 26 January 2007 (UTC)

I'd propose to add a feature to identify the bank. From what I know, the BIC (Bank Identifier Code) is an international unique number for banks. Thus I suggest a "bic = [BIC from your bank]" tag that can be added to banks.


Agree - amenity=bank would seem to fit with the other amenity values. -- Harry Wood 22:45, 8 March 2007 (UTC)


  • I approve this proposal. MikeCollinson 07:03, 18 March 2007 (UTC)
  • I approve this proposal. JonS 08:08, 18 March 2007 (UTC)
  • I approve this proposal. Kleptog 11:07, 18 March 2007 (UTC)
  • I approve this proposal. Ovidiusoft 11:22, 18 March 2007 (UTC)
  • I approve this proposal. Deelkar (talk) 12:20, 18 March 2007 (UTC)
  • I approve this proposal. Dtucny 17:57, 18 March 2007 (UTC)
  • I approve this proposal. KristianThy 18:54, 18 March 2007 (UTC)
  • I approve this proposal. Cagri 11:44, 19 March 2007 (UTC)
  • I approve this proposal. Rw 03:25, 21 March 2007 (UTC)
  • I approve this proposal. Bahnpirat 12:48, 13 May 2008 (UTC)


This should not be tagged on each individual bank, but rather as a value of a grouping relation, as BIC and SWIFT usually relates to all banks of a certain branch in the entire country. I use both terms as there are no global coverage of one or the other. Both values are good to know though. For instance, all HSBC banks in all of Brazil have the same value, while HSBC in Vietnam have another. --Skippern 17:04, 1 December 2008 (UTC)

Building Societies

Should we be using this tag for building societies, or should they have a separate tag? Frankie Roberto 16:17, 31 May 2009 (UTC)

I believe the answer should be "yes" since we should be indicating the type of services offered, rather than the ownership structure of the operator. Building societies offer banking services, even if they aren't legally a "bank" under English law. --ADMcD 21:21, 7 October 2012 (BST)
I agree. It's might feel a little clumsy and the pedants will say it's incorrect to use the word bank on a building society, but it would be even more clumsy to not use the same tag on something which is so similar (please no!!) Pretty sure most mappers are doing so anyway. Think of it as a regional eccentricity (rather like other tag usage e.g in the U.S. they're not called "motorways", but they use the highway=motorway tag) But I propose we mention something in the top description: "as well as building societies and similar financial institutions" to make it clear -- Harry Wood 14:08, 8 October 2012 (BST)

Bank without cashier

The HSBC branch on Edgeware Road in London has no cashiers, only ATMs and staff to speak to about mortgages and business accounts. Should there be a tag for this, maybe cashier=yes/no, or cashiers=count? Bitplane 18:29, 21 February 2010 (UTC)

Office number

In my bank, all the buildings have one reference (the number of office of bank). How can I tag it? As ref=number?

Thanks.--Xan 22:24, 23 May 2011 (BST)

I second that question. Also, all the buildings have a reference name. I'm using ref=number and agency_name=name for them. --Nighto (talk) 13:58, 8 February 2013 (UTC)
The discussion of this matter should definitely evolve into the official guide for the tag. It would be a HUGE differential, IMHO. By the way, I second the way Nighto is mapping. --Vitorrdias (talk) 23:24, 14 September 2015 (UTC)

"operator" or "brand" ?

Which one "operator" or "brand" should be used to mark that the bank belongs to a particular banking corporation?. On Tag:amenity=bank "operator" is advised, but Key:brand advises using "brand". Any suggestions which should be used?

brand sounds more reasonable. "Deutsche Bank" is a brand same as "Shell". Pull request for main rendering will use brand: --Stephankn (talk) 08:32, 8 December 2014 (UTC)
I find the description on this wiki quite vague, stating operator=* like Barclays and brand=* like Deutche Bank, gives me the understanding that these two keys are the same. Could somebody try to rewrite these two points to make it clearer? Also when this is done, the translated pages needs to be updated. --Skippern (talk) 12:38, 18 February 2015 (UTC)
I agree. Look at my edit, please.--Stemby (talk) 00:10, 27 February 2016 (UTC)
I'm still not clear of the distinction. Are we saying "brand" is a sort of "display name". The familiar name written on the bank (which might also be written on a map label) while the operator is the full company name? Was this to settle an argument among mappers between the pedantic full name "Deutche Bank AG" versus the pragmatic "Deutche Bank"? -- Harry Wood (talk) 10:55, 16 August 2016 (UTC)
How name, brand and operator have to used is still unclear to me and obviously many other mappers as well - for example in Freiburg (German city), all combinations exist, so e.g. (fictional values to make the point more clear) "Santander" as name and empty brand+operator, "Santander" as brand and/or operator with empty name or with "branch Freiburg" as name, sometimes at a point or way, sometimes at a relation (e.g. multipolygon). Consequence is that searching is much more difficult than it shall be (you have to consider all combinations) and that also the renderers display a useful text only in a fraction of cases. Is there anyone who really understands the name/brand/operator tagging scheme? If yes, please explain it in a really clear + unambiguous way, if not, we shall change the tagging scheme ;-) --Schoschi (talk) 14:09, 18 March 2017 (UTC)
I think they just need very concise definitions so there is no ambiguity. The way I see it is the operator=* would be the legally registered name of the company (which may not be obvious looking at the store) and brand=* would be the chain name they use to market their store (should be obvious from outside of the store). Then some stores have an additional unique name such as that of the town or manager which I would assign for the branch=*. As for the name=*, it's more subjective, should be intuitive from the outside of the store and would usually just be a concatenation of the other tags although sometimes this isn't the case such as "Hendrix's No Frills" where Hendrix is a unique name and No Frills is the name of the chain. The other tags, once filled out, help make it more machine readable somewhat analogous to having multiple address tags (addr:housenumber=*, addr:street=*, etc) instead of a single "address=*" tag. So once the other tags are filled out, apps should use them for improved labeling consistency and search functionality, and the name tag would likely become redundant. In Canada for example we have many 'different' supermarkets such as Loblaws, Superstore, No Frills, Box, etc, but they are infact all owned by the same company, Loblaws Companies Inc. There's a list here. Tangerine would be an example for a bank in Canada. If the operator and brand are the same, then both tags would be the same, but usually isn't the case. Looking at Walmart, I'd put brand=Walmart (what you see), and operator=Wal-Mart Stores, Inc. (legally registered). However where I get a little stuck is if the operator should be the subsidiary or the parent company. For example Walmart Canada Corp. is a subsidiary of Wal-Mart Stores, Inc. I'd be inclined to put the operator as the parent (holding) company, then just to create more confusion, add a new tag called subsidiary=*. The last bit of confusion for me comes with franchising and affiliation. I think I would use the owner=* as the name of the franchisee and the operator as the franchiser. McDonald's for example, has ownerships, affiliations and franchises of it's many locations and it might be nice to distinguish between them at some point. It would be good to have people with global experience in this field to come up with a classification scheme and some concise definitions to help nail this down. And just to complete this, there's ref=* to specify the branch number. DFyson (talk) 18:20, 18 March 2017 (UTC)

Mapping Bank with Drive-Through Separate from Bank Building

This is the second time I have run across a bank that has the drive-through area separate from the bank itself. (Underground vacuum tubes are used to exchange items.) The drive-through is usually nearby (such as across a street). How should I map the drive through area? --MRPockets 01:55 24 September 2015 (UTC)

name=* and brand=*

Currently name=* is mandatory, and brand=* is optional. IMO the importance of the two keys should be reversed: the brand is what people see on the premises, so it should be mandatory; name=* should be used only for the branch name, and only when a branch name exists, so the description of the name=* tag should be simplified:

  • name=* - the branch name.

(There is no point in duplicating the operator tag).

Do you agree? If so, I think this CartoCSS rule should be modified ("[name]""[brand]"). See also here.--Stemby (talk) 01:05, 27 February 2016 (UTC)

name=* and branch=*

Why is the name tag used for specifying the branch when the branch tag exists for that exact purpose?

As it stands, the name tag has become too technical and thus highly prone to inconsistancis unless every editor reads this amenity=bank page. The name should simply be left to what is most intuitive to the mapper, novice or advanced alike which usually ends up as whatever is most obvious on the ouside of the building, in this case usually the operator. It's even mentioned if the branch isn't known then use the operator. So what I'm seeing is the name tag for amenities like banks is an inconsistant mix of operator and/or branch names which is annoying for how to best render the label.

So I suspect the best way would be to render the label with the branch and operator/brand tags if they are filled out, otherwise use the name tag. DFyson (talk) 07:46, 11 September 2016 (UTC)