A large New Zealand vehicle dealer and lender needed to know where its financed vehicles were, and — where a loan agreement allowed it — to prevent a vehicle from being started again after a payment default. The client is not named here at their request; the architecture below is described in general terms for the same reason.
Flipmind built the platform end to end: the cloud system on AWS IoT Core, the integration with the lender's finance and CRM systems, and the operational tooling their team uses day to day. Each vehicle carries a telematics unit wired into the ignition circuit, reporting location, ignition state and device health over cellular.
Offline is the normal case
New Zealand has a great deal of territory with no usable cellular coverage, and a vehicle is a thing that drives into it. The system was designed on the assumption that any given unit is out of contact right now — telemetry buffers on the device and replays on reconnect, and every command is expressed as desired state in an AWS IoT Device Shadow rather than a message fired at a device that may not be listening. The unit reconciles against that state when it next connects, and reports back what it actually did. Nothing in the platform assumes a command was received because it was sent.
The safety design
Remote immobilisation is the feature people ask about first, and it is the one where the engineering matters most. The controlling principle was that the safe outcome has to be the one that happens by default — when the network drops, when the cloud is wrong, or when a command arrives at the wrong moment.
In practice that meant the decision to inhibit a start is enforced in firmware, on the device, and never by a live instruction from the cloud:
- A running vehicle is never affected. The interlock prevents the next start; it cannot interrupt a vehicle that is in use.
- Immobilisation only ever applies at rest, with the ignition already off, and is re-checked by the unit before it is applied.
- The driver is warned before it happens, with an escalating notification sequence rather than a vehicle that silently fails to start one morning.
- Override is immediate and local. Staff can clear the state, and the unit is designed so that loss of contact with the platform can never cause an immobilisation on its own.
Consent and disclosure sit upstream of all of it: the capability only applies to agreements that provide for it, and the audit trail records who changed what and when.
Fleet, not devices
At scale the useful unit of work is the fleet rather than the vehicle. Per-device X.509 identity and scoped policies mean a compromised unit stays a single compromised unit. Fleet-wide indexing makes "which units haven't reported in 48 hours" a query rather than an investigation. Firmware updates roll out as managed jobs, in waves, with the ability to stop.
Wired into the business
Telemetry that nobody acts on is an expensive hobby. Device state flows through the IoT rules engine into the lender's own systems, so account status and vehicle state are reconciled continuously — and the collections team works from one view rather than reading a separate telematics console alongside the finance system.
The result is a platform the client operates themselves: thousands of connected vehicles, a support team that can answer "where is it and what is it doing" in seconds, and a control capability whose safety properties are enforced in the vehicle rather than assumed in the cloud.