Automatically match traffic fines to drivers

Match traffic fines to drivers It means answering a very precise question: who had this vehicle on May 17 at 17:14? It is a trivial question to ask and boring to solve by hand, because it requires you to scroll through the contracts of that medium until you find one that covers that instant.

Automating it is conceptually simple: you cross plates and time with contracts. The interesting part —and the one where projects go wrong —is in the cases that do not return: the edges, the overlaps, the periods when the car was not rented.

This article describes how it was resolved in CRM for car rental of Rial Rent, after the data of the report have been extracted as described in read the fines in PDF.

The basic logic

1. It starts with the license plate. You look for the vehicle in the fleet. If there is not, the infringement is not about a managed vehicle and the process stops here.
2. He takes the moment of the infraction. Date and time, not just the date: two different rentals can happen on the same day.
3. You filter the contracts of that vehicle and you look for the one whose rental interval contains that instant.
4. It goes back to the customer and the driver data communication document is generated.

So far it's a search in a time interval. The real work begins when the instant does not fall within any interval, or touch two.

Edges: the problem no one puts in specification

One contract says the rental ends at 10:00. The customer returns at 11:40 because he has found traffic. In that hour and forty, for the system, the vehicle is not rented by anyone — but someone was driving it, and it was the customer.

It is the most frequent case among the "abnormal" ones, and it is not a data flaw: it is reality. Schedules on contracts are forecasts, not recordings.

In the project the tolerance is a few hours on both edges, and produces a different outcome from the one certain: the system signals that the match is approximate and asks for confirmation. It never closes on its own a pairing that falls into the tolerance zone.

The five outcomes

This table is the heart of the function, and the reason why the tool is used instead of being ignored.

The line that makes the difference is the third. In a poorly designed system, "no contract found" is a generic error, indistinguishable from a technical problem. Here is a Information Outcome: means that the infringement is borne by the company, and it is an information that is needed to proceed.

The overlaps

Two contracts covering the same moment should not exist, and in fact exist: a misregistered renewal, a mid-rental vehicle change, a manual entry with wrong dates.

The technical temptation is to choose the "most likely" with some rule — the newest, the longest, the first found. It is the wrong approach: choice has no real basis, and produces an attribution that seems certain and is not.

Why traceability matters more than speed

A combination of fine and driver is not an internal data: it becomes a communication to an entity, with consequences for the customer to whom it is attributed.

This changes the requirements of the system. It is not enough that the match is correct: it must be rebuildable. If a client disputes in six months, the manager must be able to tell which contract the attribution was based on, whether it was certain or approximate, and who confirmed it.

• Register the contract used for pairing, not just the name of the customer.
• Record whether the outcome was certain or approximate.
• Record who confirmed an uncertain match and when.
• Keep the original record attached to the practice.

It is the same principle that, in an automation, a failure must be made inspectable: what leaves no trace is not verifiable, and what is not verifiable sooner or later becomes a dataless discussion.

The personal data involved

It is worth saying this explicitly because in this process you handle data that deserves attention: driver's name, driving document details, address. They are personal data for all purposes, and communication to an entity is a processing with its own legal basis.

There are three practical implications for the system. First: access to driver data must be limited to the roles that need to process it, not anyone who opens the business management software. Second: generated documents must be stored with the same precautions as contracts. Third: retention has a time limit; it is not “forever”.

The overall picture is in AI and GDPR and in AI and corporate privacy. It does not replace an assessment made on the concrete case, but serves to not arrive unprepared to the question.

Practical examples

The normal case. Minutes with date and time, license plate recognized, one contract covering that instant. The system proposes the customer, who manages controls and communication starts. What used to require opening the contract archive becomes a confirmation.

Late re-entry. The infraction is at 11:15, the contract ended at 10:00 and the car returned at 11:40. It falls into tolerance: the system proposes the customer as an approximate match. Those who manage know that the re-entry had slipped that day and confirm.

The car in the garage. The infringement occurs in a period without contracts: the vehicle was used by the company for an internal shift. The system declares it, and the practice takes another route.

A badly read plaque. The OCR has produced a license plate that does not exist in the fleet. The system signals "vehicle not found" and allows manual correction, instead of looking for the most similar plate and making mistakes.

Mistakes to Avoid

Comparing only dates, not moments. Two rentals can happen on the same day. A comparison at the day level produces ambiguity where the data would not have any.

Treating "no contract" as a mistake. It is useful information, and presenting it as a failure causes one to lose confidence in the tool.

Automatically choosing in case of ambiguity. A plausible and wrong attribution is worse than a confirmation request.

Deciding the tolerance on paper. It is the only parameter that depends entirely on how that company works.

Sending communication without human control. It is a statement with consequences: the system prepares it, a person sends it. It is the same criterion applied in customer follow-up automation.

How to apply it in the company

The pattern moves to any situation where you have to understand who was responsible for a good at any given time: company vehicles, rental equipment, badges, assigned devices.

1. Verify that you have the instant, not just the date, both on event and assignments. Without now, pairing is ambiguous by construction.
2. Define possible outcomes before writing logic: they are the true specification.
3. Decide tolerances with those who work, and write them down somewhere.
4. Manage ambiguity as a predicted case, with a dedicated screen.
5. Track Manual Confirmations: they serve when someone asks why it was attributed so.

The link to contracts is described in contracts and digital signature in app; the general framework on data management in CRM Automation.

Conclusion

Match traffic fines to drivers It's a time interval problem, and the hard part is not the search: it's the cases where the data doesn't come back. A system that explicitly handles five different outcomes is used; one that returns "found" or "not found" is abandoned at the first odd case.

The two rules to take home: tolerance on the edges is decided with who does the work, and an uncertain pairing never closes on its own.

Do you want to understand what processes in your company can be automated with AI? Giallo Studio can help you turn the problem into a real workflow. The complete project is described in custom software.