A booth number, three signal layers and one very large percentage
Frogo, the fraud prevention and risk management platform owned by the RedCore international business group, is taking its latest iGaming anti fraud technology to SiGMA World 2026 in Rome, where it will sit at Booth H1-1047 in Hall 1 demonstrating device fingerprinting, behavioural biometrics and risk scoring. That is the announcement. The interesting part is the claim attached to it: a high-recall, cross-domain device identification architecture that the company says catches up to 99% of multi-accounting and cross-site anomalies without adding friction for genuine players.
Ninety-nine percent is the kind of figure that ends conversations in a procurement meeting. It should start one.
What Frogo actually said
Strip the announcement down and there are four concrete things in it. Frogo is an all-in-one fraud prevention and risk management platform under RedCore. It will be at Hall 1, Booth H1-1047. It is presenting advances across three signal layers rather than one product. And its chief executive, Volodymyr Todurov, is involved in the company’s presence beyond the booth itself.
The framing around it is the standard vendor diagnosis, and it happens to be correct: fraud schemes have outrun the detection methods most operators still run, and the methods that do work tend to punish honest users. Anyone who has watched a legitimate player get stuck in a manual review queue for eleven days because they logged in from a hotel in another country knows the shape of the problem. Catching fraud is not hard. Catching fraud without wrecking the funnel is hard.
Following one duplicate account through the stack
Take the most common abuse case in the industry and walk it through. A player who already holds an account decides the welcome offer is worth a second one. New email, slightly different name spelling, a VPN, a fresh browser profile with cookies cleared. Five years ago that was enough.
The first layer it meets is device fingerprinting. The browser or app reports a bundle of characteristics, screen dimensions, installed fonts, GPU and rendering quirks, audio stack behaviour, timezone, language settings, and the combination is distinctive enough to re-identify the same hardware across sessions. Cleared cookies do nothing to it. The cross-domain part is what matters commercially: if the same device signature has appeared on another brand in the network, the second signup is flagged before the first deposit lands.
If the fingerprint has been deliberately spoofed, the second layer is behavioural. Typing cadence, the rhythm between keystrokes, how a cursor accelerates toward a button, touch pressure and swipe arcs on mobile, how quickly someone moves through a registration form they have completed before. People are consistent in ways they cannot easily fake, and someone filling in their own details for the second time this month moves through the flow faster than a genuine first-timer.
Both layers feed the third: a risk score. This is the part that decides what happens next, and it is where most of the real engineering sits. A score is only useful if it maps to a graded response. Low risk and the player proceeds untouched. Medium and they get a step-up check, a document request, a phone verification, maybe a bonus withheld pending review. High and the account is held. The alternative, a binary block, is how you end up with a 99% catch rate and a support inbox full of furious legitimate customers.
| Signal layer | What it reads | What weakens it |
|---|---|---|
| Device fingerprinting | Hardware and browser characteristics, re-identified across sessions and brands | Shared or identical low-cost devices, the few browsers with anti-fingerprinting features, native app sandboxing |
| Behavioural biometrics | Typing rhythm, cursor and touch dynamics, navigation speed through known flows | Short sessions with little interaction, automation that replays human-recorded input |
| Risk scoring | Combined signals plus account, payment and session history | Thin data on new accounts, thresholds tuned for recall rather than precision |
Recall is the easy half
Here is where the standard pitch stops being useful. Recall measures how much of the fraud you catch. It says nothing about how many honest players you catch alongside it, and the two numbers move in opposite directions. Loosen the thresholds and recall climbs while false positives climb with it.
Work it through with illustrative numbers, not Frogo’s, since no false-positive rate was published. Say 100,000 signups in a quarter and 2% of them are duplicate accounts. At 99% recall you catch 1,980 of the 2,000. Excellent. Now apply a 1% false-positive rate to the 98,000 genuine signups and you have also flagged 980 real players. Roughly one in three of everything in your review queue is a customer who did nothing wrong. Push the false-positive rate to 2% and the honest players outnumber the fraudsters in that queue. The fraud rate is low, the legitimate population is enormous, and that asymmetry is why precision, not recall, determines whether a fraud system is worth owning.
So the number I would want on paper before signing anything is not 99%. It is the false-positive rate measured on the same dataset, over the same period, at the same threshold that produced the 99%. If a vendor can quote one and not the other, you are being sold the flattering half of a pair.
Shared devices and the problem nobody demos
Device identification assumes a device belongs to a person. In large parts of the world it belongs to a household. Two brothers betting on the same mid-range Android handset on the same home connection will look, to a fingerprinting layer, very much like one person running two accounts. Cheap devices compound it: identical model, identical OS build, identical default settings, very little entropy to separate them.
This is exactly where behavioural biometrics earns its place, because two people do not type alike even when they share hardware. It is also where the “no friction for genuine users” promise gets tested, since the honest resolution of an ambiguous case is a step-up check, and a step-up check is friction. Small, proportionate friction, applied to a small slice of traffic, is the correct answer. It is just not the same answer as none.
What the browser actually blocks
Browser fingerprinting largely persists despite cookie restrictions and private browsing, because most browsers, Chrome included, currently do little to block it. Clearing cookies or opening a private window does not strip the signal. Anti-fingerprinting defences exist but are limited, Firefox’s blocking feature being the main example, so the cross-domain effectiveness of device identification has not been substantially reduced. Native mobile apps are still a cleaner environment for it than the web, which is one reason fraud tooling keeps drifting toward SDK integrations.
The regulatory side is the real constraint. Fingerprinting is personal data processing, and in licensed European markets it has to sit on a defensible lawful basis with retention limits and a documented purpose. An operator buying this needs the data processing agreement reviewed with the same seriousness as the detection benchmarks, because a fraud stack that fails a privacy audit is a liability wearing a dashboard. Frogo’s own public positioning leans on privacy-conscious fraud prevention, which suggests the vendor knows this; buyers should still read the paperwork.
Bonus abuse is not the valuable use case
Multi-accounting gets the headlines because it is measurable in lost bonus spend. The signals that catch it matter more for things that carry licence risk. A self-excluded player opening a fresh account on the same handset is the single clearest case: self-exclusion only works if the operator can recognise a returning device and a returning behavioural profile, and KYC at registration cannot do that on its own. Account sharing, an adult’s verified account being used by someone else in the household, sits in the same bucket, and so does the early detection of accounts showing patterns consistent with problem play.
That is the argument for treating this class of tool as player protection technology rather than a cost-recovery line item. Operators should also keep the simpler tools in front of players regardless of what runs behind the scenes: deposit and loss limits, session reminders, cool-off periods and self-exclusion, which remain the controls that actually help someone whose play has stopped being recreational.
Three things worth asking in Hall 1
If you are walking the floor in Rome and Booth H1-1047 is on the list, the demo will look impressive, because these demos always do. The questions that separate a genuine detection advance from a well-tuned threshold are the precision figure beside the recall figure, the measured review-queue volume per thousand signups, and what the system does when device entropy collapses, as it does on shared and identical low-cost handsets. Nothing in the announcement answers those yet. Whether the booth does is the only reason to stop at it.