Privacy Policy

This notice applies to the NexoPlus lane access and FASTag platform in its three forms: the website, the installable PWA and the mobile application. It covers personal data the software processes while operating a site.

It does not cover the operator's own practices — how they staff the gate, what they film for, or what they do with records outside this software. Those are set by the site's own policy.

Where this notice describes a capability, it describes what this build does. Features that exist as a database column but have no working screen are not claimed.

This is a notice about data, not about title to the software. The platform is the sole property of NexoPlus Automations and is supplied by NexoPlus to any organisation it chooses to supply; nothing in this notice grants an operator or a user any ownership of it, and nothing here transfers ownership of anyone's personal data either. The full position is set out in the Terms of Service.

Outside services are described here by the kind of service they are, not by name. Which provider an operator ends up using is a matter of the credentials that operator configures, and naming them would put commitments about companies NexoPlus does not control into this document.

The platform keeps records for four different kinds of person, and they are not the same. An account that signs in is a separate thing from a vehicle record that a gate opens for.

Alongside those records, the system writes operational data that can identify a person or a vehicle indirectly:

• Access events — tag ID, reader, lane, granted or denied, the reason, the timestamp, and where a camera is fitted, the path of a captured image and a recognised plate.
• Camera captures — still images written to the server's disk, including frames kept because something moved in view rather than because a vehicle was read. See section 4.
• Barrier and relay events — every open, close and forced state, with the actor and the time.
• Sign-in history — successful logins, failed attempts with the source IP, and the sessions currently active.
• Audit and activity logs — which account changed which record, and when.
• Machine API call logs — the request and response of calls the server makes on the operator's behalf.

Passwords are stored as salted hashes. The account table has an unused email column; no screen in this build collects an email address, so it is normally empty.

Three different things in this product touch a camera, and they have different privacy profiles. Read this section before deciding what a site films.

The lane camera, reporting its own reading

An automatic number-plate recognition camera fitted to a lane can read plates on the device itself and report each reading to this server over the local network. The server stores the plate text, a confidence value, the time, the lane and the camera, and a snapshot image on the server's own disk.

Recognised plates are matched against vehicle records to decide access. A plate with no record is still stored as a detection; it is not discarded.

The server reading the stream itself

Where a camera cannot report a plate on its own, this build can pull the camera's video stream over the local network and do the work itself. The stream is analysed continuously for movement, and a still image is written to the server's disk when motion is detected — not only when a tag is presented.

That is a wider net than a lane reader, and it should be understood as such: motion is the trigger, so a saved frame may contain people, vehicles and activity that never came near a gate. Where a stream is being analysed, the camera's address and credentials are held on the server. No face capture, face matching or person-identification feature is provided; the software looks at whether something moved, and then at the plate.

The optional recognition service

A superuser screen can enable plate recognition on the server itself, which runs a recognition container on the same machine, on a local port, under a licence key the operator supplies — that key and its token are stored in the site's settings. An image given to it is read there and does not leave the server.

The one qualification: the recognition address is configurable. If an operator points it at a machine elsewhere, or at a hosted recognition service, images go to that address and are then handled under that party's terms, not this notice.

The camera test screen

The camera diagnostic tool runs the same stream analysis while testing a device and can save captures from it. Those images are written to the server's disk like any other capture, so a test performed while a lane is live produces records.

The platform supports an identity mode where a person is registered against the last four digits of an Aadhaar number instead of a FASTag ID.

• The field rejects anything that is not exactly four digits, so a full Aadhaar number is never written to the database.
• Scanning a Aadhaar QR yields the same masked last-four value plus a name and a verification reference; the QR is not stored as a substitute for the number.
• The stored combination of name, last four digits, vehicle and contact number is still sensitive. Treat the site's Aadhaar records as high-risk data and restrict the permission that reads them.

No biometric data is captured or matched by this software. A staff record has an optional identifier field, which is a text label the operator types; the platform performs no biometric verification.

The mobile application and the installable PWA sign in with the same accounts as the website. A vehicle owner signs in with their ten-digit contact number as both username and password, which is convenient and, plainly, weak — the operator decides whether to allow it on their site.

Push alerts

Alerts are opt-in per device. Registering for them stores a push-messaging device token, of the kind issued by the mobile platform's notification service, together with the device's browser, operating system, user agent, source IP and the account it belongs to. Delivering an alert therefore passes the token and the alert text through that notification service. Turning alerts off, or uninstalling the app, leaves that row until it is cleared or expires.

Location

The platform does not track a phone. The one place it records location is guard patrolling: a checkpoint scan captures the guard's latitude, longitude and accuracy at the moment of the scan, so that a round can be proved to have been walked. Between checkpoints nothing is recorded, and continuous tracking is not a feature.

• Deciding access. Comparing a tag, plate or person against the records that are allowed at that lane and that hour, then driving or refusing to drive the barrier.
• Running the site. Parking assignments, visitor approvals, staff attendance, patrol rounds, watchlist refusals.
• Enriching a record. Looking up vehicle details, FASTag balance or challan history from the outside services in section 8, and caching the answer.
• Reporting. Dashboards, scheduled reports and exports the operator generates for their own use.
• Security and support. Login and audit history, and the log files the operator reads when something misbehaves. That same trail is what establishes who changed a record or opened a barrier, and it may be reviewed with the operator — or supplied by the operator — during a support engagement.
• Recovery. Database backups, kept locally and, only if the operator turns it on, copied to a cloud drive account the operator authorises.

There is no automated decision-making with legal or similarly significant effect on an individual. The one automatic decision the software makes — open or hold — is a mechanical gate check against a rule the operator wrote, and a human can always override it from the manual control screen.

Some features answer questions this server cannot, so it asks someone else. Each call is made on the operator's behalf, from the operator's server, using credentials the operator holds.

Which company stands behind each of those rows depends on the account and credentials the operator configures; this notice names none of them on purpose. Each service sees only what a single lookup needs — usually a registration number or a tag ID — and not the rest of the database. Responses are cached on the operator's server to avoid repeating the call. Every such call is logged, so an operator can reconstruct what left the site and when. Each provider handles the data under its own terms, which NexoPlus Automations neither sets nor speaks for, and which the operator is responsible for reading before enabling the feature.

Backup to a cloud drive is off until an operator turns it on and authorises their own account with the drive provider they choose.

• The authorisation token is stored on the server with owner-only file permissions.
• The account password for the drive provider is never seen or stored by this software.
• A backup is a complete database copy — every account, owner record, plate detection and log. Anyone able to read that drive account can read everything in it.
• Access can be withdrawn at any time from the drive account itself, which leaves the stored token useless.
• Nothing in that account other than the software's own backup files is read.

All of it sits on the operator's own hardware: an SQLite database file, captured images on disk, and log files. Nothing is mirrored to a NexoPlus system.

• Passwords are salted and hashed, never stored in plain text.
• Every screen and every API route checks a permission before it answers; a locked page is not merely hidden from the menu.
• Five failed sign-ins lock an account for fifteen minutes.
• Sessions are carried in HttpOnly, SameSite cookies.
• Only one active session per account is kept; a new sign-in displaces the older one.
• Encryption in transit depends on how the operator fronts the application. Access over a private network or a VPN is the recommended arrangement.

No security measure here is a guarantee. The controls are proportionate to a lane-control system and are the operator's to configure.

Retention is not one number. The operator sets a period per data type on the Data Retention screen, and a daily schedule deletes what has aged out. The defaults are short for high-volume machine data and longer for records that carry accountability:

Vehicle-owner, visitor and staff records are kept until the operator removes them; they are the thing the gate needs to know. Cached vehicle details are kept until refreshed or cleared. Captured images are a data type of their own on the same screen, so a site can age snapshots out on a schedule as well — where no policy is set for them, they stay on the disk until the operator clears them.

Because the operator controls the data, requests to access, correct or delete it go to them, not to NexoPlus. What the software makes possible:

• Access and correction — the operator can view and edit any record from its own screen.
• Deletion — the operator removes accounts, owner records, visitors and staff directly. Deleting an account ends its sign-in immediately.
• Push alerts — opt in or out per device; uninstalling the app stops delivery.
• Cloud drive access — revocable by the operator from their own drive account at any time.
• Export — reports and CSV exports let the operator hand a person their own records.

There is no self-service privacy portal, and no automatic anonymisation of historical rows: this build deletes records rather than rewriting them. A column exists in the schema for an anonymised flag, but no screen sets it, so no such feature is offered here.

• One session cookie is used to keep a person signed in. It is HttpOnly and SameSite.
• A browser that chooses "remember me" on a phone or PWA stays signed in for up to thirty days.
• Theme and font choices are kept in that browser's local storage, not sent to the server.
• There are no analytics cookies, no advertising cookies and no third-party tracking scripts.

The service is business software operated by an organisation for its staff, residents and visitors. It is not directed at children, and no feature asks for a child's data. Where a resident registers a household helper or a visitor, that is the operator's record to hold lawfully.

This notice is updated when the software's behaviour changes. The date at the top of the page is the version in force; continuing to use a site after its operator updates the software means accepting the notice that describes it.

Direct privacy questions to the administrator of the site you used — they hold the data and are the only party who can act on a request about it. Their contact details come with your access to that site; this document deliberately prints no address, phone number or mailbox, because the correct one depends on which site you used.

Nothing in this notice grants, assigns or transfers any right in the software itself. The platform, its source code, its design and its trade marks are the exclusive property of NexoPlus Automations and are reserved. Our license terms, including who may be supplied the software and what no operator or user may claim over it, are set out in the Terms of Service.

This notice is read under the law of India and, like the license terms beside it, before the courts of Coimbatore, Tamil Nadu.