Named Entity Recognition: Finding Names

Open the SMS inbox on your phone and find a message from your bank. It probably looks something like this:

Rs.500.00 debited from A/c XX4521 on 15-Aug-26 to
SWIGGY BANGALORE. Avl Bal Rs.12,340.50. -HDFC Bank

Now open your banking app, or a spending tracker built into an app like Google Pay. Somehow, without you typing anything, it has already sorted this transaction into "Food & Dining," logged the merchant as "Swiggy," recorded the amount as ₹500, and stamped it with today's date. The app did not understand this SMS the way you do. It did something narrower and more mechanical: it scanned the raw text and pulled out the pieces that are names — the name of a merchant, an amount of money, a date, a bank. Then it looked up what kind of name each one is. That exact task — finding which spans of text refer to real-world things, and labelling what kind of thing each one is — is called Named Entity Recognition, or NER. It is one of the oldest and most quietly useful problems in Natural Language Processing, and by the end of this chapter you will be able to build a small working version of it yourself.

What Exactly Is a "Named Entity"?

A named entity is a real-world object that has a proper name: a specific person, a specific organisation, a specific place, a specific date, a specific amount of money. "Swiggy" is a named entity — it refers to one particular company, not food delivery companies in general. "Bangalore" is a named entity — it refers to one particular city. Compare this to a word like "restaurant" or "city," which name a category, not one single thing.

Named Entity Recognition is the NLP task of doing two things to a piece of text, together:

• Detection — finding the exact boundary of each entity mention (where it starts and where it ends, since an entity can span more than one word, like "Reserve Bank of India").
• Classification — deciding which category that entity belongs to (is "Swiggy" a person, a place, or an organisation?).

This is different from simply searching for a list of known words. A search for the string "Kohli" in a news archive finds every occurrence of it, whether it appears in "Virat Kohli walked out to bat" or in an unrelated sentence about someone else who happens to share that surname. NER has to use the surrounding words — the context — to decide not just where a name sits in the text, but what kind of thing it names.

The Standard Entity Types

Most NER systems, whether built in a research lab or shipped inside a banking app, work with a small set of entity categories. The most common ones, with examples you would recognise from everyday Indian text, are:

• PERSON — a human being's name, e.g. "Virat Kohli," "Kalpana Chawla," "A.P.J. Abdul Kalam."
• ORGANIZATION (ORG) — a company, institution, or agency, e.g. "ISRO," "Infosys," "Reserve Bank of India."
• LOCATION (LOC) — a geographic place, e.g. "Mumbai," "Wankhede Stadium," "the Nilgiri Hills."
• DATE — a calendar date or period, e.g. "15 August 2026," "next Monday," "the monsoon season."
• TIME — a point or duration within a day, e.g. "6:30 pm," "midnight."
• MONEY — a monetary amount, e.g. "₹500," "Rs 12,340.50," "two lakh rupees."

Real systems sometimes add more categories, such as PERCENT or PRODUCT, but these six cover the large majority of entities you will meet in ordinary text. Your bank's SMS parser, for instance, leans mainly on three of them: ORG for the merchant and the bank, MONEY for the amount, and DATE for the transaction date.

Why Finding Names Is Harder Than It Looks

A tempting shortcut is: "just look for capitalised words." In English, proper nouns are usually capitalised, so "Swiggy," "Bangalore," and "HDFC" all stand out from lowercase words like "debited" and "from." This heuristic gets you partway, but it fails in at least three important ways.

First, capitalisation is ambiguous. The word "Apple" at the start of a sentence could be the fruit or the company. "May" could be the month, a person's name, or the verb in "you may go." A capitalisation rule cannot tell these apart — only the surrounding context can, by comparing "I bought an Apple laptop" against "I ate an apple."

Second, entities can span multiple words, and a system has to know exactly where they end. "Reserve Bank of India" is a single ORG entity made of four words, including a lowercase function word, "of," in the middle. A system that only ever looked for individual capitalised words would wrongly split this into separate fragments and silently drop the connecting word.

Third — and this matters a great deal for Indian text — the capitalisation trick does not work at all for many Indian languages. English uses uppercase and lowercase letters, so "Bangalore" visibly differs from "bangalore." But scripts like Devanagari (used for Hindi and Marathi), Tamil, Telugu, and Bengali have no concept of upper and lower case at all — every letter has exactly one form. An NER system built for Hindi cannot lean on capitalisation as a clue, and must instead rely much more heavily on context, on dictionaries of known names, and on statistical patterns learned from large amounts of text. Even English text on Indian phones causes trouble: casual SMS and WhatsApp messages are often typed entirely in lowercase, such as "swiggy order rs 500 debited," which strips away the one clue English NER relies on most.

There is a fourth complication worth knowing about: entities can hide inside other entities. "Bank of Baroda" is a single ORG entity, but it contains the word "Baroda," which is also a real place name — an older name for the city of Vadodara in Gujarat — that would match a LOCATION gazetteer entry all on its own. A naive system scanning for known place names would wrongly flag "Baroda" as a LOCATION in the middle of what should be tagged as one unbroken ORG entity. Modern usage creates the same confusion in the opposite direction: "Google" is almost always an ORG, except in a sentence like "just google it," where it has become an ordinary verb and is not a named entity at all. Deciding correctly, in either case, needs the surrounding sentence — never the word by itself.

The BIO Tagging Scheme

To describe precisely, to a computer or to another human, exactly where an entity starts and stops, NLP uses a labelling scheme called BIO tagging (sometimes written IOB). Every single token — every word — in a sentence gets exactly one tag:

• B-TYPE — this token begins an entity of the given type.
• I-TYPE — this token is inside an entity, continuing the entity that started with the most recent B tag.
• O — this token is outside any entity; it is not part of a name.

Let's tag a full sentence by hand, one token at a time, so the rule becomes concrete:

Virat Kohli scored a century at Wankhede Stadium in Mumbai.

First, split the sentence into tokens: Virat, Kohli, scored, a, century, at, Wankhede, Stadium, in, Mumbai, . — eleven tokens. Now assign a tag to each one, in order:

• Virat → B-PER (the first word of a person's name)
• Kohli → I-PER (continues the same person entity)
• scored → O (an ordinary verb, not a name)
• a → O
• century → O
• at → O
• Wankhede → B-LOC (the first word of a new location entity)
• Stadium → I-LOC (continues that same location)
• in → O
• Mumbai → B-LOC
• . → O

Look closely at the last location tag. "Mumbai" gets B-LOC, not I-LOC, even though "Wankhede Stadium" was also tagged LOC just three tokens earlier. The rule is strict: an I-LOC tag is only valid immediately after a B-LOC or another I-LOC of the same entity, with no O tag in between. Since the token "in" broke the sequence, "Mumbai" must be the start of a brand-new location entity, so it gets a fresh B tag. This is exactly how a tagging scheme lets a computer read off, mechanically, where one entity ends and the next begins: scan the tags and group every maximal run of a B followed by its I's into one entity. Applying that grouping rule to the sequence above recovers exactly three entities: "Virat Kohli" (PER), "Wankhede Stadium" (LOC), and "Mumbai" (LOC) — from a sentence of eleven tokens.

Building a Simple Rule-Based NER

The most direct way to build an NER system is to give it a list of names it already knows — called a gazetteer, borrowing the old word for a geographical dictionary — and have it scan text looking for matches. Here is a small one in Python:

PERSON_NAMES = {"Virat Kohli", "Sachin Tendulkar", "MS Dhoni"}
LOCATIONS = {"Mumbai", "Wankhede Stadium", "Delhi", "Bengaluru"}
ORGANIZATIONS = {"BCCI", "ISRO", "Reserve Bank of India"}

GAZETTEER = {}
for name in PERSON_NAMES:
    GAZETTEER[name] = "PERSON"
for name in LOCATIONS:
    GAZETTEER[name] = "LOCATION"
for name in ORGANIZATIONS:
    GAZETTEER[name] = "ORGANIZATION"

def find_entities(text):
    tokens = text.replace(".", "").split()
    entities = []
    i = 0
    while i < len(tokens):
        matched = False
        for span_len in (3, 2, 1):          # try the longest phrase first
            if i + span_len <= len(tokens):
                candidate = " ".join(tokens[i:i + span_len])
                if candidate in GAZETTEER:
                    entities.append((candidate, GAZETTEER[candidate]))
                    i += span_len
                    matched = True
                    break
        if not matched:
            i += 1                          # no match, move to next token
    return entities

sentence = "Virat Kohli scored a century at Wankhede Stadium in Mumbai."
for entity_text, entity_type in find_entities(sentence):
    print(f"{entity_text} -> {entity_type}")

Trace this function by hand on the sentence to see exactly why it works. After removing the full stop and splitting on spaces, tokens holds ten words, indexed 0 to 9: Virat(0) Kohli(1) scored(2) a(3) century(4) at(5) Wankhede(6) Stadium(7) in(8) Mumbai(9).

• i = 0: try the 3-word span "Virat Kohli scored" — not in the gazetteer. Try the 2-word span "Virat Kohli" — it is in the gazetteer, mapped to PERSON. Record it, then jump i forward by 2, to i = 2.
• i = 2 through i = 5: every 3-word, 2-word, and 1-word span starting at "scored," "a," "century," and "at" fails to match anything in the gazetteer, so i simply advances one token at a time.
• i = 6: the 3-word span "Wankhede Stadium in" fails, but the 2-word span "Wankhede Stadium" matches, mapped to LOCATION. Record it, jump i forward by 2, to i = 8.
• i = 8: the 2-word span "in Mumbai" fails, and the 1-word span "in" fails. i advances to 9.
• i = 9: the 1-word span "Mumbai" matches, mapped to LOCATION. Record it, jump i to 10, and the loop ends because 10 is not less than the token count.

The final printed output is:

Virat Kohli -> PERSON
Wankhede Stadium -> LOCATION
Mumbai -> LOCATION

Notice the loop always tries the longest possible span before shorter ones. This is essential: if it tried single words first, it would match "Wankhede" and "Stadium" as two separate, meaningless one-word entities instead of recognising them as a single two-word entity, because the code would already have committed to the short match before ever checking whether the longer phrase exists in the gazetteer.

Where the Gazetteer Approach Breaks Down

Run this same function on the sentence "Rohit Sharma scored a century at Eden Gardens in Kolkata," and it finds nothing at all — not because the sentence has no entities, but because none of those three names happen to be sitting in our small dictionary. A gazetteer only recognises what it has already been told about. New cricketers debut, new companies launch, and new restaurants open on Swiggy every single day, and a fixed list can never keep up. It also cannot use context to resolve ambiguity: if a place name were added to both a LOCATIONS list and a list of common surnames, a pure lookup table has no way to decide which sense applies in a given sentence.

This is why production NER systems — the ones inside libraries like spaCy, or commercial services like Google's Cloud Natural Language API and AWS Comprehend — are built differently. Instead of a fixed list, they are statistical or deep-learning models trained on large collections of text that has already been hand-labelled with B-I-O tags by human annotators. During training, the model learns general patterns rather than memorising a list: words that follow a phrase like "scored a century at" are usually stadium names; digits following "Rs" or "₹" are usually money amounts; a two-capitalised-word phrase before a verb like "scored" or "said" is usually a person's name. Because it has learned patterns instead of a fixed list, a trained model can correctly tag a name it has genuinely never seen before — a debutant cricketer's name on their very first appearance in the news, for instance — something a gazetteer can never do. You will meet exactly how such models are trained when you study sequence labelling with machine learning in a later chapter; the B-I-O tags you assigned by hand in the previous section are precisely the training labels that feed such a model.

No NER system, rule-based or learned, gets every span right on messy real-world text. This is precisely why your banking app still lets you manually re-tag a transaction that lands in the wrong category, or add a merchant it failed to recognise. That correction, quietly logged, often becomes a new training example that improves the model for the next user who receives an SMS from the same merchant.

NER at Work in India

Once you know what to look for, NER turns up everywhere in everyday software:

• Expense tracking: apps that read your bank SMS messages tag the merchant (ORG), amount (MONEY), and date (DATE) in every message, so they can show you "₹500 spent at Swiggy on 15 August" without you typing a single digit.
• News aggregation: Indian news apps tag every article with the people, organisations, and places it mentions, which is how a single tap can show you "more stories about ISRO" or "more stories from Bengaluru."
• Search: when you search "movies with Shah Rukh Khan," a search engine needs to recognise "Shah Rukh Khan" as a single PERSON entity — not three separate common words — to return relevant results instead of pages that merely contain the words "shah," "rukh," and "khan" scattered separately.
• Customer support chatbots: a railway or airline enquiry bot has to pull the train or flight number, the travel date, and the two station or city names out of a typed question like "Is the Rajdhani from Delhi to Mumbai running on 25 August?" before it can even look up the answer.
• Resume screening: job platforms extract a candidate's name, past employers, college names, and skills from an uploaded resume automatically, using NER as the very first processing step, before any ranking or filtering happens.
• Online shopping: e-commerce sites extract the brand from a product title like "boAt Rockerz 450 Wireless Headphones" so that filtering search results by brand works correctly — even though "boAt" itself breaks the usual capitalisation rule.

Back to Your Bank SMS

Return to the message this chapter opened with: "Rs.500.00 debited from A/c XX4521 on 15-Aug-26 to SWIGGY BANGALORE. Avl Bal Rs.12,340.50. -HDFC Bank." You can now describe precisely what your banking app does to it. It tokenises the message, then walks through the tokens applying the two ideas from this chapter together: a gazetteer of thousands of known merchant names, catching "SWIGGY" instantly, the same way our small Python function caught "Wankhede Stadium," backed up by pattern rules and a trained statistical model for everything the gazetteer misses — a new merchant it has never seen before, an amount written as "Rs.500.00" instead of "₹500," a date written as "15-Aug-26" instead of "15 August 2026." Each recognised span gets classified — MONEY, DATE, ORGANIZATION — and only then can the app move on to deciding that "Food & Dining" is the right category for a Swiggy transaction. Finding the names, precisely and correctly, always has to come first. That is the entire job of Named Entity Recognition: not understanding a sentence in any deep sense, but reliably answering two questions for every stretch of text — is this a name, and if so, a name of what?

Think About It

Think about this: How would you explain named entity recognition: finding names to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where named entity recognition: finding names is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting named entity recognition: finding names to at least 3 other topics you have studied.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind named entity recognition: finding names, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.