Google and Singapore's GovTech train a Gemma model to catch scams as a conversation unfolds

Scammers can spend days building trust through messages, TechRepublic reported ^[11]. The message that finally asks for money can look like any other. In our view that is the sound case for scoring a whole conversation, and it is the fraud the new model targets: schemes that develop across multiple exchanges ^[2].

The design has two stages. A lightweight classifier screens incoming messages first. Only suspicious exchanges reach a fine-tuned Gemma model, which examines more of the conversation before it decides whether to warn ^[3]. The split is meant to limit battery consumption ^[4]. The model aims at gradual manipulation such as impersonation and investment scams, and Google is separately testing protections against call-forwarding scams, which are a different method of fraud ^[5].

The pitch is a warning before someone transfers money or shares sensitive information, and TechRepublic says the model could deliver it ^[1]. What exists is an announced model with phased deployment and no public date ^[9]. Google has not disclosed supported devices, enterprise management controls, or accuracy and false-positive rates ^[10]. TechRepublic names the next milestone as identifying which apps can use the detector and how reliably it performs outside testing ^[17].

On privacy, Google says apps using the detector will need user consent before accessing conversations ^[7]. It also says that because analysis runs on the device, neither Google nor Singapore's government will have access to those conversations through the detector ^[8]. TechRepublic adds a caution: local processing alone does not establish a system's overall security ^[15]. The model was fine-tuned on anonymized Singapore-specific scam material, including examples involving banks, government institutions and local figures ^[6]. Similar deployments elsewhere are under consideration, with no confirmed schedule ^[18].

The stakes are visible in Singapore Police Force figures released August 26. The first half of 2026 brought 16,821 scam cases and S$410.6 million in losses ^[12]. Cases fell 14.4% and losses fell 17.9% on the same period in 2025 ^[13]. Dividing losses by cases gives roughly S$24,400 per case ^[16]. TechRepublic notes that scams are costliest when victims are manipulated into authorizing payments themselves ^[14], and a warning that lands before authorization is aimed at that loss. Without a false-positive rate, the price of a false alarm cannot be set.

For an operator, TechRepublic says the technology could eventually complement employee verification procedures against messaging-based impersonation and payment fraud ^[19]. We would keep those procedures as the control and treat the detector as a later addition. The trade-off is that staff keep paying the manual verification time until then.

Two facts sort the decision. The first is whether the app your people use is on the supported list. The second is whether a false-positive rate exists. With both, run a pilot. With the app list but no rate, pilot with a small group and count false alarms yourself. With a rate but not your app, there is nothing to deploy. With neither, and that is today's position, keep the existing procedures.