Geofenced Clock-In: Ending Buddy Punching in Security

You end buddy punching in a security operation by making the clock-in event carry evidence of where and how it happened, and by deciding in advance what the system does when that evidence is missing. A GPS coordinate inside a site geofence, a scan at a physical checkpoint, or a biometric match at a control room terminal all produce a record that is difficult to fake from a sofa. A username and password do not, because credentials travel.

The second half of that sentence matters more than the first, and it is the part most implementations get wrong. What happens when the GPS cannot get a fix in a basement car park? If the answer is that the clock-in is accepted unverified, then the verification is optional and the fraud simply routes through the exception. This article is mostly about that decision.

Why attendance is the load-bearing record

Attendance sits underneath almost everything else an agency does commercially and legally. Payroll pays against it. Client invoices bill against it. Wage compliance is calculated on it. A dispute about whether an officer was on post at 03:00 is resolved by it, or is not resolved at all.

This is why a scheduled roster is not a substitute. A roster records intent. Attendance records what happened. Every downstream number that gets paid or billed should trace to the second, and where an agency bills from the roster because attendance is unreliable, it is billing an assumption.

The four capture methods and what each is good for

Mobile GPS with geofence. The officer clocks in from their own phone, and the system checks the coordinate against a polygon drawn around the site. This is the workhorse method for mobile and distributed posts because it needs no site hardware. Its weakness is signal: basements, plant rooms, and steel-framed industrial buildings degrade GPS accuracy or lose it entirely.

QR or NFC checkpoint scan. A physical tag at a fixed location. Presence at the tag is the evidence, which sidesteps GPS reliability entirely. The design requirement is that the tag cannot be duplicated or photographed and reused, which means the scan payload has to be something other than a static readable code.

Biometric terminal. Fingerprint or face at a fixed reader, typical in control rooms and larger sites with a permanent installation. Strongest identity assurance, highest cost, least flexible.

Web kiosk. A shared terminal, usually a control room fallback. Weakest verification and worth treating as an exception path rather than a primary method, because a shared device with shared access is exactly the buddy-punching vector you are trying to close.

Most agencies need more than one, assigned per post rather than globally. A lobby post at a commercial tower is a good NFC candidate. A mobile patrol covering four industrial units needs GPS. Choosing one method for the whole operation guarantees it fits some posts badly.

Fail-closed, and why it is uncomfortable

When verification cannot be obtained, there are two possible defaults.

Fail-open accepts the clock-in and marks it unverified. It is operationally smooth and it destroys the control, because the unverified path becomes the normal path wherever it is easier, and nobody can distinguish a genuine basement signal failure from a deliberate one.

Fail-closed refuses to record a verified clock-in without verification, creating an explicit exception that a supervisor must resolve. It is operationally uncomfortable, generates real friction in the first month, and it is the correct default. The reason is that the exception queue is itself the useful artefact: if one site generates forty geofence failures a month and every other site generates two, you have either a coverage problem worth fixing with an NFC tag or a behaviour problem worth a conversation. Fail-open hides both.

What makes fail-closed workable rather than merely strict is a decent exception workflow. The officer can still record that they are on post, flagged as pending verification, with a reason. The supervisor sees it in a queue, resolves it with a reason code, and the resolution is logged. The hours become billable and payable once verified. Nothing is lost; it is just no longer automatic.

Offline queuing is not the same as fail-open

These two get conflated and they are different. Offline queuing means the app captures the clock-in locally with its timestamp and GPS fix, holds it, and syncs when connectivity returns. The verification evidence was obtained; only its transmission was delayed. That is legitimate and necessary, because guards work in places with no data coverage.

Fail-open means the evidence was never obtained at all. An app that queues offline is doing the right thing. An app that accepts a clock-in with no location fix because the GPS was disabled is not.

The practical implication for procurement: ask specifically whether the app captures and queues the location fix offline, or whether it simply defers the whole check. The answers sound similar and the behaviours are opposite.

What the system should flag automatically

Once capture is reliable, the value comes from automatic exception detection rather than from anyone reading attendance logs.

• Late clock-in against expected shift start, past a configurable grace window.
• No-show, raised proactively once the grace window closes rather than discovered later.
• Early clock-out, which is where quiet shift-shortening lives.
• Out-of-geofence clock-in or clock-out, including clock-outs from a different location than the clock-in.
• Missing clock-out entirely, which otherwise produces either an unpaid shift or a wildly overstated one depending on how the system handles it.

The no-show flag is the one with operational teeth, because it is what gives a supervisor usable time to find a replacement. Everything else is reconciliation; that one is deployment.

From verified attendance to timesheets

The step that removes most administrative load is generating timesheets from verified attendance rather than from separate submission. Hours split by contract, site and post, with regular, overtime, night differential and public holiday hours derived from the shift times and the applicable contract rules.

Two controls matter here. Only verified attendance records should feed timesheet generation, otherwise unverified time enters payroll and billing through the back door. And any adjustment to a generated timesheet line should require a structured reason code rather than free text, because coded reasons aggregate into patterns while free-text notes are only ever read one at a time. If late clock-in adjustments cluster at one site, that is worth knowing.

Once a timesheet is approved it should lock, with reopening requiring an explicit unlock that is itself logged. Approved-then-quietly-edited is the condition under which nobody trusts the numbers.

How Moxogo implements it

Moxogo Security supports mobile GPS clock-in with per-site geofencing, QR and NFC checkpoint scanning, and biometric or kiosk capture where sites have the hardware, assigned per post rather than globally. Geofencing is fail-closed by design: a clock-in without a valid location fix does not become a verified record, and instead raises a supervisor exception with a reason. The guard app queues clock-ins locally with their captured location and timestamp when offline, syncing through a background queue when connectivity returns, which keeps genuine coverage gaps from becoming either lost records or unverified ones.

Late, early, absent, out-of-geofence and missing clock-out conditions are detected automatically against expected shift times. Timesheets generate only from verified attendance records, split by contract, site and post, with regular, overtime, night and public holiday hours derived from contract rules; adjustments require reason codes, and approved timesheets lock against further edits without an explicit unlock. Every mutating action writes an audit entry.

A practical test

Pick a night shift from last week at your least-supervised site. Ask what evidence exists that the officer was physically present at 02:00. If the answer is a roster entry and a signature on a paper log filled in at shift end, that is not evidence of presence at 02:00; it is evidence of presence at shift end plus an assertion about the intervening hours. Whether that matters depends entirely on whether anyone ever disputes it, and the problem with that reasoning is that you find out which shifts get disputed only afterwards.

Frequently Asked Questions

What actually prevents buddy punching? Making the clock-in carry evidence of place and method: a GPS fix inside a site geofence, a scan at a physical checkpoint, or a biometric match at a fixed terminal. Credentials alone cannot prevent it, because credentials can be shared and used from anywhere.

Should geofencing fail open or fail closed? Fail closed. If a clock-in without a location fix is accepted as verified, the unverified path becomes the normal path wherever it is easier, and genuine signal failures become indistinguishable from deliberate ones. Fail-closed with a supervisor exception queue keeps the control intact and surfaces which sites have real coverage problems.

Is offline clock-in the same as accepting unverified attendance? No, and the distinction is important. Offline queuing captures the location fix and timestamp locally then syncs later, so the evidence was obtained and only its transmission was delayed. Accepting a clock-in with no location fix at all means the evidence never existed.

Which clock-in method suits which post? GPS geofencing for mobile patrols and distributed posts needing no site hardware, QR or NFC for fixed posts where GPS is unreliable such as basements and steel-framed buildings, biometric terminals for control rooms and larger permanent installations. Assign per post rather than choosing one method for the whole operation.

Why should timesheets generate only from verified attendance? Because unverified hours otherwise enter payroll and client billing through the back door, which creates both wage compliance exposure and disputed invoices. Verified attendance is the only defensible basis for hours that get paid or billed.

Related in this series

• Overview: What Does a Security Agency in Singapore Actually Need From an ERP?
• constraint-based rostering
• contract billing
• patrol verification