The First Filter Sets the Reach of an On-Device Scam Detector

Running deep conversation analysis on every incoming message would spend a phone's computation on messages a lightweight screen could dismiss. But a detector that saves power by dismissing a message also decides which evidence its deeper model will never examine at that moment.

That decision sits inside the two-stage design described in Google DeepMind's October 14, 2026 account of its collaboration with GovTech Singapore. A lightweight classifier screens inbound messages. A fine-tuned Gemma model then examines a larger snapshot of a conversation flagged by the first stage, confirming a threat or discarding a false alarm. The stated aim is local detection that warns a user to pause before they share money or sensitive information.

The architecture creates a specific evaluation problem. Testing the deeper model only on conversations it receives cannot reveal how many useful opportunities the first filter removed. A deployment needs to measure the complete path from incoming message to timely warning, while keeping the battery cost of that path visible.

Two stages make different decisions

The first model decides whether a message deserves more analysis. The second decides whether the surrounding conversation warrants an alert. Those decisions need not use the same threshold or optimize the same error rate.

A strict first filter can reduce the number of expensive checks. It can also leave the second model with an unusually easy test set, because the suspicious cases were already obvious enough to pass. A high score on that selected set may say little about the cases that looked harmless when first screened.

Consider a deliberately simplified example, not a result from the Singapore project. At one screening opportunity, 100 conversations require a warning. The first filter forwards 90. If the deeper model correctly flags 80 percent of those 90, the pipeline warns on 72 of the original 100. Reporting only the deeper model's 80 percent would hide the ten cases that never reached it. The arithmetic does not assume that the two models make independent errors, because the 80 percent is measured only on the cases the first stage forwarded.

The live problem is harder because conversations continue. A conversation missed at one screening opportunity may still trigger an alert on a later message. Whether that counts as recovery depends on what happened before the alert. A warning that appears only after credentials were disclosed is different from one that appears before the request to disclose them. Evaluation therefore needs a time boundary tied to the exposure the warning is meant to prevent, not just a label saying the conversation was eventually detected.

Measure the cases the filter keeps out

DeepMind says its model was fine-tuned on local scam conversations and tested with synthetic dialogues and local corpora. The post describes phased deployment through applications rather than a completed rollout. It does not publish the first-stage threshold, false-positive rate, recall, device-level latency or battery measurements. The post states that the partners have "proven the ability for local, real-time scam detection." That is the partners' own assessment, not a published evaluation result. Without such results, the post leaves room for an engineering analysis of the design, but not for a claim that its effectiveness or energy savings have been established publicly.

For another team implementing this pattern, an informative test would start with complete, authorized conversation sequences. Replay them in order, allowing the detector only the information available at each point. Record which stage first flags a case and whether the warning precedes the event the application is meant to prevent. This is a proposed test method, not a reported experiment on the Google-GovTech system.

The conversations the first stage rejects need attention too. Run a controlled evaluation in which the deeper model also receives a sample of conversations the filter dismissed. That comparison can show whether lowering the screening threshold would recover useful detections or merely increase computation. Sampling only forwarded conversations cannot answer that question.

There are at least two reasons the deeper model might fail to help. It may receive the necessary evidence and misclassify it. Or the window it receives, the snapshot of recent messages passed to it, may omit the earlier impersonation or qualifying exchange that gives the latest message its meaning. Improving the deeper model's classification and changing the conversation window address different failures. Logging the selected window in a protected evaluation environment lets the team tell them apart.

The threshold sets both cost and reach

A two-stage system saves work only when the first stage costs less than the deeper checks it avoids. As a rough accounting model, each screening opportunity incurs the lightweight classifier's cost, plus the deeper model's cost multiplied by the fraction sent onward. That relationship explains the purpose of the first filter. It supplies no battery-life estimate.

The same threshold that controls the fraction sent onward also controls which conversations the deeper model never sees. A setting that forwards few messages in a quiet test may forward many during a busy exchange, so the number of deeper checks depends on the traffic as well as on the threshold. Average energy and average response time taken across a whole test can conceal an alert that arrives too late in exactly those bursts.

The useful comparison is the same conversation workload on the intended devices, with several screening thresholds and a clearly defined warning deadline. Record the number of deeper checks, missed warning opportunities, unnecessary alerts, energy use and time to alert. The choice is then which threshold setting meets the application's detection requirements within its resource budget. Reducing the deeper model's invocation count alone is not evidence that the product improved.

Keep the local-processing claim separate

The post describes the model as running entirely on the user's device, with conversation access subject to the user's consent under each application's terms. It states that neither Google nor the Singapore Government would be able to access users' conversations through this deployment. That is a stated deployment design. It is not a measurement of classification quality, and it does not by itself show how a specific application handles consent, diagnostic records or retained conversation context.

A model can run locally and still make poor decisions. A detector can classify well in an offline study without establishing how the surrounding application protects data. Evaluating the proposed application means checking these concerns separately, without letting a privacy statement stand in for a detection result or the reverse.

The two-stage design is a plausible way to reserve heavier conversation analysis for selected traffic. Its practical test is whether that selection preserves opportunities to warn the user before the relevant exposure. Judge the first filter by what it passes on and what it keeps out. Judge the full system by the warning that reaches the user, when it arrives, and what the phone spent to produce it.