ASSPLBangalore and other strange names on your credit card statement, decoded

You open your statement, see ASSPLBangalore ₹1,849, and spend a nervous minute wondering whether someone in Bangalore has your card.

Almost certainly not. It is Amazon.

Indian card statements rarely print the brand you paid. They print the descriptor: the name of the legal entity that holds the merchant account, often shortened, sometimes with a city attached, sometimes with the spaces removed. The brand on the app icon and the company on the bank's records are frequently two different names.

This post decodes the common ones. They all come from the rules cardkhata already uses to categorise spending.

What is ASSPLBangalore on my credit card statement?

It is an Amazon.in purchase. ASSPL stands for Amazon Seller Services Private Limited, the Indian company that runs Amazon.in. Bangalore is where that entity is registered, not where you shopped.

Depending on the bank, you will see it printed as ASSPLBangalore, ASSPL-Bangalore or ASSPL BANGALORE. All three are the same thing. If the amount and date match an Amazon order, you can stop worrying.

The word "Amazon" appears nowhere in that string, which is exactly why it caught us out. For a while, every Amazon India purchase landed in Uncategorised in cardkhata. Nothing errored. It just sat in the wrong bucket until someone noticed.

Why do merchants show up under a different name?

There are three common reasons, and most strange descriptors are a mix of them.

• The legal entity, not the brand. A card network knows the company that signed up for the merchant account. When that company is named differently from the brand, you see the company.
• The franchisee, not the chain. Many restaurant chains in India are run by regional franchise companies, and the franchisee's name is the one on the bill.
• Bank formatting. Some issuers squash words together (IndianOil, GcaFillingStation...), truncate names at a fixed width, or add a city or a reference code. The same shop can look different on HDFC and on SBI.

Common descriptors on Indian card statements

Here are the ones that confuse people most, all taken from cardkhata's categorisation rules:

• ASSPLBangalore / ASSPL-Bangalore: Amazon.in (Amazon Seller Services Pvt Ltd). Shopping.
• BLINK COMMERCE: Blinkit, the quick-commerce app. Groceries.
• AVENUE SUPERMART: DMart (Avenue Supermarts Ltd). Groceries.
• JUBILANT FOODWORKS: Domino's in India (Jubilant runs the franchise). Dining.
• CONNAUGHT PLAZA: McDonald's in North and East India (Connaught Plaza Restaurants). Dining.
• DREAMPLUG: CRED (Dreamplug Technologies), usually a bill payment. Bills & Utilities.
• BIGTREE: BookMyShow (Bigtree Entertainment). Entertainment.
• DISTRICT MOVIE: movie tickets booked on District, Zomato's going-out app. Entertainment.
• TRENT: Westside and Zudio (Trent Ltd, a Tata company). Shopping.
• MAX RETAIL: Max Fashion stores. Shopping.
• DEFMACRO: ClearTax (Defmacro Software). Software & Apps.
• GOOGLESERVIS: Google Play and other Google subscriptions. Software & Apps.
• KITE: Zerodha's trading platform. Investments.
• JIOHOTSTAR: the streaming service, not your Jio phone bill. Entertainment.
• IndianOil / IOCL / HPCL / BPCL: a fuel pump of that oil company. Fuel.
• UPI_SOMENAME / UPI-SOMENAME: a UPI payment made with a RuPay credit card. UPI Miscellaneous, unless the merchant is recognised.

If a descriptor on your statement isn't in this list, two quick checks usually solve it: search the name with "Pvt Ltd" added to find the company behind it, and match the amount against your order history or SMS alerts.

How do you tell JioHotstar apart from a Jio recharge?

Through rule order. Both strings contain JIO, so a naive "contains JIO means phone bill" rule would file your streaming subscription under Bills & Utilities.

cardkhata's rules are an ordered list, and the first match wins. The specific streaming names, JIOHOTSTAR and JIOCINEMA with and without the space, sit above the generic JIO telecom rule, so they are always checked first. A brand-specific rule always beats a generic one. Broad fallbacks like a bare FUEL or INSURANCE, which match the merchant-category words some banks print, sit at the very bottom.

Why not just match "ASSPL"?

Because it would misfile someone else's spending.

The rules are plain substring matches. They are fast, predictable and easy to check, but they only see letters. ASSPL sits inside CLASSPLUS, a real Indian edtech company. A bare ASSPL rule would quietly put every Classplus course subscription under Shopping.

So the rule matches ASSPLBANGALORE, and lists all three spacings, because a substring can't match across a separator it doesn't contain. That one example shows why we treat every rule as a small decision someone has to check, not a keyword list to keep adding to.

How does cardkhata categorise Indian spending with AI?

Rules first, the model second, and the person who owns the card above both. For every transaction, the order is:

1. Your own override. If you moved a transaction, or every transaction from a merchant, to a category, your choice wins over everything else.
2. Fees. Annual fees, late charges, finance charges and their GST go to Fees & Charges.
3. The keyword rules. Close to two hundred ordered rules like the ones above. No model is involved, and the result is the same every time.
4. The AI's answer, but only for a merchant string the rules have never seen.
5. UPI Miscellaneous, for a UPI payment that neither the rules nor the model could place. It is real spending to a merchant without a recognisable name, so it gets its own group.
6. Uncategorised, honestly labelled, for everything else.

The AI step is built to stay small:

• Only the merchant string is sent. The model sees something like SHREE BALAJI ENTERPRISES and a fixed list of categories it must choose from. It never sees your name, your card, the amount or the rest of your statement.
• One answer, shared by everyone. When a new merchant string arrives, it goes into a queue. Every 15 minutes, a background job sends the waiting strings to Claude Haiku in a single batched request, and the answer goes into a cache that is shared across all users. The next person who shops at the same place gets the answer instantly, and the model is never asked about that string again.
• The model is allowed to say "I don't know". If it can't place a merchant confidently, the transaction stays Uncategorised rather than getting a confident wrong label. A wrong category is worse than an honest blank, because it looks like an answer.
• Answers it invents are thrown away. If the model returns something that isn't on the fixed category list, the answer is dropped and the merchant is tried again in a later sweep.
• Mistakes get fixed at the source. When the model gets something wrong, we can override its answer for that merchant, and the most common ones become new keyword rules. Over time, more of the work moves from the model to the rules, and none of it moves the other way.

The result is a categoriser that is predictable for the merchants India spends at most, and still useful for the neighbourhood shop, registered as some Enterprises, that no rule list will ever include.

What should you do about a descriptor you don't recognise?

Don't panic, and don't ignore it either.

1. Match the amount and date against your SMS alerts, your email receipts and your app order history. Most mysteries end here.
2. Search the descriptor with "Pvt Ltd" to find the company behind it, as with ASSPL and Amazon.
3. Check for a subscription you forgot about. Small, round amounts that repeat every month are the usual suspects.
4. If it still makes no sense, call your bank. A charge you can't explain is worth disputing quickly. Most issuers make a dispute harder once the payment is overdue.

In cardkhata, if a transaction lands in the wrong place, move it once and choose whether the change applies to that one transaction or to every transaction from that merchant. Your choice wins from then on.