How a bank knows
where you swiped.
a card swipe carries forty characters of "where". some banks keep them, some throw them away. this is what happens to them on the way to a pin.
The forty characters
When a card is tapped at a register, the payment network sends the bank a message with a field the industry calls the merchant name and location. It is old, fixed-width and tiny: twenty-five characters for the shop's name, thirteen for the city, two for the state. That is the whole budget for "where".
Shop names get truncated to fit ("WHOLEFDS", "DDBR" for a doughnut chain, "PACSUN"). Cities get cut at thirteen letters, so "SAN FRANCISCO" loses its last letter and "MOUNTAIN VIEW" becomes "MOUNTAIN VI". Some processors glue the name and the city together when the name is short. A store number often rides along, which is the single most useful character string in the whole field — it names one branch, not a chain.
Where the "online" tell hides
For a purchase where the card wasn't present, the big networks don't send a city at all. They put a phone number or a web address in the city slot instead. So a descriptor like this one is not a place:
That structural quirk is the most reliable "this happened online" signal there is, better than any keyword list. TallyMap keeps online purchases in their own bucket for exactly this reason: a phone bill, a streaming plan or a marketplace order never lands as a pin on a branch it never touched.
What your bank does with it
This is where it gets uneven. The descriptor reaches the bank intact. Whether it reaches you is the bank's choice. Some banks pass the raw field through to their statement and to the data aggregators that budgeting apps use. Others "clean" it: they replace the raw text with a tidy merchant name and drop the city and state on the floor, because a tidy name looks better in a banking app. The tidy name is nicer to read and useless for a map.
A common belief is that the data aggregator (the service that connects a budgeting app to a bank) gets coordinates from the card network. It doesn't. The coordinates you sometimes see are parsed out of that same descriptor and looked up afterwards. If the bank stripped the city, there is nothing to look up.
From a string to a pin
TallyMap resolves each purchase with a ladder, and the first rung that holds wins:
| rung | what the app has | what it does |
|---|---|---|
| online | a phone or URL in the city slot, an online channel, a telecom or utility | files it under the merchant's "online" place; never pinned |
| exact | coordinates from the bank's data | a solid pin |
| city | a parsed city and state | searches the map for the shop inside that city, with a leash so a result 4,000 km away is ignored |
| that day | no city, but a trusted pin from the same day | searches within 6 km of where you provably were |
| home | only a name | searches near your home city and draws the pin dashed, tagged "near?" |
| you | a tap | you fix it once; the app remembers the shop for next time |
The dashed "near?" pins are the honest part. When the bank kept nothing but a name, the app says so instead of pretending. Fixing one takes a tap, and a fixed pin is never overwritten by a guess again.
What never happens
TallyMap does not track your location to do any of this. The pin comes from the purchase, not from the phone. Transactions are stored on the iPhone, not on a server. There is an optional on-device signal you can turn on to make pins exact; it never leaves the phone and the app works fully without it.
If you want to see your own map
TallyMap is free to count by hand: drop a stroke on the map where you paid. Core links a bank and does the forty-character work for you. If your bank turns out to be one that strips the city, the app tells you and you fix the few that land as "near?".
Get TallyMap for iPhone