Phone networks carry an enormous number of calls and text messages, and some of them are traps. A message claims to be from a bank. A call says a parcel is stuck. A text offers a prize that does not exist. Operators, regulators, and security apps all try to filter these out before people act on them.
AI can do that filtering, but it learns from labeled examples, and the labels are harder than they look. "Spam" is not one thing. Scam call labeling and spam message labeling have to separate fraud, unwanted marketing, and perfectly legitimate alerts, often from just a few words. This post explains what the labels need to capture and why careful reviewers matter.
A typical project labels each message or call record against a defined set of classes:
Fraud usually gets a second level of labels for the type of scam. These categories are broader than any single script, since scammers rewrite their wording often.
The line between unwanted marketing and fraud is the source of many labeling disagreements. A heavily promotional message from a real company is annoying, not criminal. A message that impersonates a real company to steal money or credentials is fraud.
The two can look alike. Both use urgency, offers, and links. What separates them is intent and honesty: is the sender who they claim to be, and are they trying to deceive?
Policies add another layer. Rules about consent, promotional messages, and what counts as unsolicited vary between regions and between operators. Annotators should work from a written policy, and every labeled batch should record which version of the policy it followed.
The most durable labels describe what the sender wants the recipient to do. Does the message push the reader to click a link, call back a number, share a code, make a payment, or install something?
Intent labels hold up when wording changes. A scam that uses different words but wants the same action still gets the same label. A model trained on intent can recognize variations it has not seen before, while a model trained on specific phrases is easily fooled by a rewrite.
For this reason, SMS fraud detection data should record both the scam type and the action the sender is pushing for.
Text is only part of the picture. Messages carry other signals that help classify them:
Annotators should record these as separate fields. Doing so lets the team see which signals the model relies on. Annotators should examine how a link is built without opening it, and the guidelines should make that a firm rule.
Fraud is an adversarial field. When a filter catches one pattern, scammers adjust. Wording shifts, links change, and new stories appear around current events.
A dataset labeled once and left alone ages quickly. Teams need a steady flow of fresh samples, a way for annotators to flag patterns that fit no existing category, and a review process that catches drift. Old labels should stay, since older scams still circulate, but the mix needs to reflect what people are receiving now.
Many real messages look suspicious by accident. A bank's one-time code includes urgency and a short number. A delivery notice carries a link. A government notice asks the reader to act by a deadline.
These cases cause the most costly mistakes. If a model blocks a real one-time code or a real delivery alert, people are locked out of their own accounts or miss their deliveries. Labeling guidance should therefore include many examples of legitimate messages that share features with scams, and annotators should know what verified senders typically look like.
A false alarm has a cost, just as a missed scam does. Reviewers should check both kinds of errors.
Messages often mix languages and scripts, and scammers sometimes misspell words on purpose so filters miss them. A swapped letter, a spaced-out word, or an unusual symbol can hide a familiar term.
Annotators should know these tricks and treat them as signals, not noise. Rules should say how to label a message in a mixed script and when a misspelling counts as evasion.
Messages and call records hold personal data: phone numbers, names, account details, and addresses. Projects should mask or remove these before annotators see them, and limit access to raw data. Clear rules about what is masked, and how, protect the people whose messages make up the dataset.
People who work in fraud analysis, telecom security, or trust and safety recognize scam patterns quickly. They know how fraud shifts, what legitimate bulk messaging looks like, and how policies differ by market. They also write the rules that keep a large team consistent: the class list, the intent labels, and the handling of unclear cases.
This matches Globik's approach of using verified domain experts for work that depends on judgment. For telecom fraud AI training data, that experience keeps real alerts flowing and scams out.
Before a scam and spam labeling project starts, a team can settle five things:
Scam and spam filtering works when labels separate fraud from marketing and real alerts, focus on intent, and keep pace with changing tactics. For an example of labeling on the physical side of telecom networks, see our guide on cell tower and antenna inspection imagery annotation: checking what is installed, not just what is broken. Strong scam call labeling depends on people who understand how fraud works.
It is the labeling of calls and messages as fraud, marketing, spam, or legitimate so AI can filter them.
A scam deceives the recipient about who is sending it or what it wants, while marketing is only unwanted.
Scammers change their words often, but the action they want stays the same, so intent labels last longer.
Real one-time codes and delivery alerts share features with scams, and blocking them harms users.
Messages contain numbers, names, and account details, which should be protected during annotation.
