"Geofencing" gets used loosely in a lot of guard-management marketing, often meaning nothing more than "the app has a map." What actually stops attendance fraud is a specific, enforced rule: a punch is only accepted if the device's real GPS coordinates fall inside a boundary defined for that site โ and every part of that sentence matters.
The problem geofencing is solving
Without any location check, a guard-attendance app is really just a digital signature pad โ it proves someone with the right login tapped a button, not that they were on site. Two failure modes are common: one guard punching in for another who hasn't arrived yet ("buddy punching"), and a guard punching in from home or a nearby tea stall and arriving at site late, if at all. Both are invisible on paper and invisible to an app that doesn't check location.
Two boundary shapes, chosen per site
Most sites are well represented by a circle โ a radius in meters drawn around a single GPS coordinate at the site's entrance or center. That's fast to configure and works fine for a compact office, warehouse, or gated residential society. But some sites โ a sprawling industrial campus, an irregularly shaped compound with a long perimeter โ don't fit a circle well; a radius wide enough to cover the far corner of the site is also wide enough to include the street outside. For those, Raksha Kavach supports drawing a polygon boundary that follows the site's actual shape, so the geofence matches reality rather than approximating it.
Enforcement happens server-side, not just on the phone
A geofence check that only runs on the guard's own phone can be tampered with by anyone who can modify the app or its data. Raksha Kavach's punch-in and punch-out both independently re-validate the reported GPS coordinates against the site's configured geofence on the server, using the same point-in-polygon and radius math regardless of what the phone app itself decided. The phone captures the location; the server is the one that actually decides whether the punch is accepted.
Location isn't configurable to "off"
A geofence is only useful if it's actually set โ a site accidentally left with no location configured would otherwise be a silent hole in the whole control. Raksha Kavach requires a site's location to be set before attendance can be recorded there at all, so there's no path to running a site invisibly outside the geofence system.
Mock-location and GPS accuracy as a second layer
A geofence alone assumes the GPS coordinate reaching the server is real. Fake-GPS apps exist specifically to defeat that assumption, and Android exposes a signal when a location is coming from a mock provider rather than the device's actual GPS/network stack โ Raksha Kavach reads that flag and rejects a punch outright when it's set, rather than accepting a spoofed location just because it happens to fall inside the boundary. GPS accuracy is captured on every punch too, giving supervisors a second data point to review if a pattern looks off.
A geofence answers "was the device inside the boundary." Mock-location detection answers the follow-up question a geofence alone can't: "was that location actually real."
What this means day to day
For a supervisor, geofencing means attendance disputes stop being a matter of trust and start being a matter of record โ either a punch is on file with a location inside the site or it isn't. For an agency owner, it means a client asking "how do you know your guards are actually at my site" has a real, specific answer instead of "we trust our supervisors."
Conclusion
Geofencing isn't a single feature so much as a chain of checks โ a defined boundary, server-side enforcement, and a defence against spoofed locations โ that together make "the guard was physically at the site" something the system can actually stand behind, not something the agency has to take on faith.