{'fraction_non_alphanumeric': 0.0264914925694594, 'fraction_numerical': 0.002769145564751854, 'mean_word_length': 4.710119465917076, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 10, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
An Online Stream Monitoring Algorithm for Fraud Detection in the Transport of Goods

The process of monitoring vehicles used in road transports plays an important role in detecting fraud committed by drivers. Algorithm designers face a number of challenges, including large number of vehicles monitored, demands related to online calculations, and ability to easily explain fraud alarms triggered to supervisors who make final decisions about actions to be taken. In this paper, we propose rather general, lightweight stream, online heuristics. The vehicle’s position is periodically controlled by a GNSS device. The algorithm detects potential illegal activities along the route between the origin and the destination. Anomalies in the vehicle’s trajectory are detected, based on a multi-resolution analysis of the economy of routes. The economy metric is easily understood and verifiable by controllers. The solution is also capable of identifying clearly suspicious trajectories that popular geofencing approaches would overlook. The scale on which the solution may be adopted is obtained thanks to the stream – like nature of the algorithm: essentially, the resources used do not increase along with the size of the input stream (the number of GNSS frames generated for the vehicle). An experiment illustrating the algorithm’s viability is presented


Introduction and Related Work
The process of monitoring road transport operations [1] is usually understood as using a global navigation satellite system (GNSS) -in more cases GPS -to control the position of vehicles. A vehicle is equipped with an on-board unit (OBU) which identifies its GPS position and sends it, periodically, over the Internet, to a host computer system. An operator checks the position of the vehicle in order to control compliance with predefined routes and time schedules, to ensure the safety of the truck and its crew, and to identify any irregularities, such as extra pickups or drops. Let us focus on the last activity, i.e. detection of fraud. Usually, commercial vehicles travel between predefined origin and destination locations, transporting goods between these points. A similar situation is dealt with in the case of taxi operations, where the passenger needs to be transported from a particular starting point to a specific destination. In all such situations, there is a risk that the driver may commit fraud by transporting some additional goods or passengers, on their own initiative, along with the legal load. This may require the driver to visit additional locations along his/her route, to illegally drop or pickup additional goods. Drivers may also take care of their private business while working. The methods used to detect such cases of frauds are based on various concepts.
Such methods may be online-or offline-based. In an online analysis, a suspicious behavior of the vehicle is detected by the system quickly after or even before the forbidden behavior takes place. For example, the system detects that a truck is driving in the wrong direction, or that it takes a lengthy break between the loading/dropping locations. An efficient online detection system may be used for triggering an alarm informing monitoring center staff about such events. They, in turn, may contact the driver or send other employees to check on the suspicious vehicle. An offline analysis consists in analyzing journeys after these have been completed (one-by-one or as a set), in order to detect potential fraud.
The detection methods may be used on different scales. The number of vehicles monitored may grow rapidly in large companies. Monitoring systems may also be operated by governments, countrywide, and may cover considerable number of vehicles. For example, road transports of selected goods have been monitored in Poland since 2017, pursuant to the "Act on the goods transport monitoring system" dated 9 March 2017. The main goal of the solution is to control the movement of goods subject to the imposition of excise duty predominantly fuels. The key objective is to prevent unauthorized or unofficial loading or unloading operations that would result in avoiding the payment of taxes. Pursuant to the aforementioned Act, any operations involving transportation of specific goods must be preceded by a suitable notification submitted via a government-operated online system, known as SENT [2]. The notification contains: a CN (or the Polish PKU) classification code of the goods concerned, their quantity, address of loading and unloading locations, details of contractors involved, date on which the transport operation begins, vehicle details (mainly the license plate number) and owner's details. As of the end of 2018, vehicles transporting goods monitored with the use of the SENT system must also be monitored by GNSS. Therefore, a vehicle must be equipped with a mobile phone with a suitable tracking app. Alternatively, an on-board unit (OBU) already installed in the vehicle may be used in connection with the host system to collect information required by the government. A single frame of tracking information contains primarily GNSS coordinates of the truck, GNNS time corresponding to the specific position, and identification data (of the OBU). There are two sources of information: SENT declarations and tracking information. Several authorities are allowed to control the vehicles in order to verify, whether the actual status of the vehicle matches the declarations submitted. From the point of view of efficiency of the monitoring process, it is important how the vehicle's position is analyzed within the company. It seems that manual (visual) supervision seems to be the most common approach. The position of a vehicle is displayed on a map, along with its speed and trajectory. This information is analyzed by the operator. Interestingly, according to practitioners, may systems of this type are based on manual analysis. OBUs obtain GPS information periodically (in predefined intervals, upon a predefine distance has been covered, or of the speed has changed by a specific value). It needs to be borne in mind, however, that it is not always possible to send GPS data (to the host) online. The Internet connection may be temporarily unavailable due to switching between different base stations, the vehicle may be present in coverage holes, or the OBU may be switched off. Therefore, OBUs usually buffer GPS frames and retransmit them after the Internet connection has been regained. Interestingly, it is often the case that the current position is transmitted first, followed by the delayed frames. The current position of the vehicle is more important for the operator than its historical location. Therefore, OBUs do not preserve the order of GPS frames while sending. This indicates (though, clearly, does not determine with certainty) that the analysis performed is either manual or, even if automatic, is based on some simple logic that does not require the true order of GNSS frames. A clear drawback of the manual approach consists in its dependence on the mental and physical condition of humans performing the analysis, who are capable of supervising a small number of vehicles only. In order cope with this, new systems are usually equipped with automated solutions that are based on some simple logic. The logic uses additional information from vehicle sensors (see [3]). Load sensing capabilities are particularly useful, since they allow to easily detect anomalies in the weight of the commodity, caused by illegal drops or pickups made during the trip. Fraud evidence provided by such sensors is of the solid variety, since it is difficult to explain unplanned changes in load weight. On the other hand, equipping vehicles with specialized sensors is not al-ways possible due to cost, compatibility and scale-related considerations. Geofencing [4]- [6] is a good example of the automatic analysis-based approach. The area in which the vehicle may be present is defined, and each violation of the borderline triggers on alarm that calls for specific action to be taken. The permitted region is often defined as a corridor along a predefined route. The logic of geofencing is simple and an alarm may be generated based on analyzing a single frame, independently of the previous frames. The geofencing algorithm does not require a lot of memory. As explained in subsequent sections, one the main difficulties associated with geofencing consists in the need to deal with a potentially large number of routes between two points within the road network. This problem is faced unless we force the vehicle to use a particular route (which is not always viable, e.g. when transport monitoring systems are operated by governments). Some route variants can be complicated and winding, which makes them clearly uneconomical and fraud-suspicious, but still permitted by geofencing. Moreover, drivers may be required to make small detours to rest areas, service stations or by accident, when they get lost along the way or make a mistake at an intersection. Geofencing might be too sensitive for such scenarios. Not surprisingly, various machine learning techniques have been deployed to detect anomalies and fraud in transport. Various methods are used here, including statistical approach [7], statistical methods combined with the Dempster-Shafer evidence theory [8], separation through support vector machines [9], just to name a few works. Such approaches usually compare the current route to what they have learned about former routes during the learning phase. The approaches are perfectly capable of modeling proper routes inherited from the mathematical method relied upon a while learning. However, they also suffer from several drawbacks. The first one is shared with geofencing: there are the plenty of possible routes between any two points, which are equally reasonable and are characterized by similar lengths and, therefore, costs. Nonetheless, if we compare such routes using a simple similarity measure, e.g. based on distances between trajectory points, routes that are almost equal become dissimilar. This phenomenon complicates the learning process and hinders the process of identifying a good model. The second problem consists in the verdict given by the algorithm (e.g. detection of a suspicious route) being difficult to explain to a supervisor. This is a known drawback of many learning methods, but it plays an important role in our application. Usually, the algorithm triggers a suspicious route alarm that is later taken over by an operator whose role is to either initiate verification, commerce a pursuit or cancel the alarm. In order to make the decision, it is desirable that the operator knows why the system has triggered the alarm. Another drawback of learning methods consists in the fact that the learning phase has to take place, which means that the system cannot start operating without having collected a reliable history of routes, possibly manually marked by an operator as valid or fraud prone. Such approaches may also be of the heavy-weight nature, both in terms of their conceptual complexity and computing resources required, especially during the learning phase. Selected authors are aware of these drawbacks and apply various measures to prevent them. For example, in [7], a one-class learning approach is used which simplifies the learning phase by making it human-independent. Addition of the two-class learning approach, when a human introduces negative (suspicious) examples, is possible as well. This optimizes the learning effect and also allows the learned model to follow human way of reasoning. The authors of [8] observe the phenomenon of multiplicity of equivalent routes. Thus they assess the current route not only by a usual point-distance similarity measure in reference to typical routes, but also by examining the total length of the connection. The expected distribution of the length for a given starting and ending point is calculated based on the historical files. Sadly, the authors only consider the total length of the vehicle's trajectory. They do not deal with the sections of fragments of the trajectory, potentially omitting some local deviations from the proper route. An interesting approach to online work and to the large scale of computing is proposed in [10]. As usual, a dissimilarity measure is used to compare the current trajectory with the historical ones. The potentially resourceheavy method is accelerated with special indexing of trajectories performed via the so-called local clustering and vantage trees. In this paper, a fraud detection method based on on-line knowledge concerning development of the vehicle's trajectory is proposed. When the system detects an anomaly in the trajectory fragment observed so far, it triggers an alarm that draws the attention of the supervisor and requires them to take suitable action or to disregard the alarm. The proposed approach is based on a multi-resolution analysis of the route's economy, measured based on trajectory zigzagging (deflection from a straight line). This measure offers a multi-resolution functionality: both the shape of the entire route and the lengths of its fragments of various sizes are examined. The intention is to eliminate, from the algorithm, the many drawbacks referred to above. The approach accepts various route variants between the origin and destination locations and treats equally, as long as they exhibit similar economy metrics. It is conceptually easy and understandable for the operator assessing the alarm, who may easily assess the zigzagging of the route themselves. It is ready to run out of the box, without a lengthy and complicated learning phase, but some parameter tuning may still be necessary. The algorithm is also lightweight, facilitating its application in large-scale systems. It utilizes a para-stream character, and thus is suitable for on-line monitoring applications. Stream processing is strictly a synonym for "ideal data processing algorithm" [11]. Such an algorithm is characterized by constant memory usage per the size of input data. Thus, if the input data has the form of a stream of data, i.e. a set of GNSS frames for a given vehicle, memory usage does not reach a certain limit as the stream proceeds.

The Algorithm
The algorithm described in this section is used for detecting anomalies in the economy of the observed moving trajectory. Normally, a vehicle should approach its destination using a straight and short route. Whenever this requirement is not met, the route is treated as suspicious. There is a possibility (risk) that deviation from the straight line was caused by illegal activity. The concept of the algorithm may be easily explained by comparing it with geofencing. In geofencing, we define corridors along the projected route; whenever the corridor is left, an alarm is triggered. The most obvious drawback of this approach is the fact that multiple potential routes exist between the origin and the destination, as explained in the example of the grid layout of roads, as depicted in Fig. 1. Routes A, B, C look equally reasonable and the number of similarly reasonable routes grows exponentially along with the increase of the grid size. Therefore, it is not obvious how a specific corridor should be defined. If we define a "grid of corridors", i.e. those existing along all road segments present in the grid, we also accept such routes as D, which is lengthy and winding, and thus clearly suspicious in terms of potentially illegal loading and unloading operations. Another drawback of corridors is that they do not allow any small deviations to rest areas, parking lots, tire shops, etc., especially if reaching these requires some maneuvers on one way roads and clover leaf interchanges. Thus, in the proposed system, geofencing is replaced by an analysis of trajectory zigzagging. For given a trajectory T with points x 1 , x 2 , . . ., x n on a plane, we define its zigzagging Z(T ) as: where dist(x, y) denotes the Euclidean distance between x and y. Alternatively, the length of the shortest path between x and y along the existing roads could be used for dist if map information is available, as would be discussed later. Zigzagging is simply the ratio between the length of the trajectory and the distance between its end points. The main idea is to set a limit value (Z max ) for the permitted zigzagging of vehicle trajectories. If trajectory zigzagging exceeds Z max , the trajectory becomes suspicious and illegal activity is taken into consideration. The rationale behind such a setting is that zigzagging routes suffer from bad economy -if the driver does need to go to illegal locations, they would not need to take such routes. Note, for example, that routes A, B, C (if represented as sufficiently dense discrete trajectories, i.e. trajectories with sufficiently large numbers of points) are characterized by a zigzagging measure of approx. the square root of 2. Route D has a larger zigzagging measure. This example shows that should Z max be set at say 2 or a little more, in order to allow routing in a more complicated road grids. Assessment of simple zigzagging measure values of the entire trajectory between the origin and destination points does not eliminate the potential of falsely evaluating the correctness of a given route based on zigzagging. It needs to be noted that if we take any fragment of the trajectory into consideration, it also should be economical in itself, i.e. should be characterized by a limited zigzagging measure.
To cope with this, a multiresolution analysis of the route traveled so far, at a given point of the journey, should be performed. The zigzagging measure of the entire trajectory recorded so far, of a fragment of the trajectory ending at the current location, or even of a smaller fragment of the trajectory ending at the current location may be analyzed. Let us assume that the vehicle's route is given by the stream of points x 0 , x 1 , x 2 , . . ., with x 0 being its origin. The proposed stream algorithm, invoked upon receiving frame x i , is outlined as Algorithm 1 (variable therewasanalarm is initialized to false).
where r is the resolution level, n 1 , n 2 , . . . n r are not greater than the algorithm parameter N and x 1 n 1 = x 2 n 2 = x r n r = x i . 5: Compute Z(T 1 ), Z(T 2 ), . . ., Z(T r ) (zigzagging for empty or one-point degenerate trajectories is assumed to be 0). An alarm is generated only once for a given route in order to avoid the operator's distraction by a storm of alarms for consecutive trajectory points. This feature uses the Boolean therewasanalarm variable. Note that since variables n 1 , n 2 , . . ., n r approximating subtrajectories at particular resolution levels are limited by N, the number of resolution levels r is finite. Therefore, the algorithm conforms to the stream regime. The price that needs to be paid for this is that sub-trajectories may be approximated at N points at the most. In practice, it is difficult to implementing step 1 without storing all points x 0 , x 2 , . . ., x i in the memory.

Selecting Route Approximations at Specified Resolution Levels
At each resolution level, the zigzagging of approximations T 1 , T 2 , . . . , T r of the sub-trajectory is examined. These approximations are some trajectories made up of selected points of the sub-trajectory that has been observed so far. The selection of points and the construction of T i is based on keeping memory usage limited. Determination of T i is based on characterization of the resolution, performed by the reference length step for a given i. This reference length is called stride i . This is given by: The algorithm's minstride parameter defines the length of the reference segment of the trajectory at the finest resolution level. Parameter r itself is evaluated as: where rrbu f len = N − 1 is the assumed maximum number of segments in T i , maxroutelength is the maximum possible length (sum of segment lengths) of the entire trajectory. The default parameter settings are: rrbu f len = 4, maxroutelength = 20, 000 km, minstride = 2 km. Fig. 3. Approximating the trajectory created so far with trajectories at 3 different resolution levels (r = 3). Probably, only the medium resolution trajectory t 2 (yellow) has a zigzagging measure that exceeds the alarm threshold.
Trajectories T j for j = 1, . . . , r are updated upon receiving a current point x i of the trajectory according to Algorithm 2. Here, T j is a cyclic buffer storing a sequence of rrbuflen latest elements appended to this buffer. Ti j is initialized to empty sequence. Variable y j is initialized to x 0 . Append x i to T j (with deleting all but rrbuflen last element of the sequence stored in T j .

5:
Set y i = x i . 6: End if 7: Return current T j as sequence stored in T j (if it ends with x i ) or with appended point x i (otherwise).
In other words, sequence T j is designed by choosing points of sequence x i . The first is x 0 , any new point x i from the vehicle's trajectory is appended if and as soon as it is distanced from the previous appended point by at least stride i . Such a sequence is appended the current point, if it does not end with it. At most last rrbu f len appended points are finally taken to form sequence T j . Such an approach ensures limited memory usage during the construction process, which is O(rrbu f len). Moreover, sequence T j has segments of length of approximately stridei i , except for the last segment which was added to keep sequence T j as fresh as possible.
The settings for r and stride i (for i = 1, . . . , r) are selected so that: • the logarithms of numbers stride i form an arithmetic sequence, • the coarsest resolution level, T r is capable of covering the entire trajectory of the maximum length maxroutelength, i.e. to contain its first and last point. The T i for other (i.e. those used to assess local zigzagging of finer resolution levels), might obviously be shorter.

Extensions
The algorithm is equipped with several extensions. Different zigzagging limits may be used for Z(T 1 ), Z(T 2 ), . . . , Z(T r ), instead of a single Z max , in order to allow greater zigzagging at fine resolution levels. For given T i , the limit is: • Z max,long otherwise.
The reason for this extension is an observation that natural zigzagging of vehicles differs depends on the scale. In the case of routes that are less than 10 kilometers long, roads are often projected as being perpendicular to each other. Furthermore, drivers must perform maneuvers that increase the zigzagging measure, like bypassing one-way roads, making loops at multi-level intersections, obeying "no-turn" signs, etc. Hence, the default parameter settings are Z max,short = 2.0, Z max,long = 1.7, zigdistthershold =10 km. The second extension allows to include the destination point in the trajectory that has been covered so far. If we know the trip's destination (which is usually the case), we may not only examine various zigzagging measures based on the sub-trajectory covered so far, but we may also proactively check whether various zigzags will need to become excessive in the future, assuming that the vehicle will eventually reach its destination. This extension works as follows. Upon receiving of consecutive point x i , Algorithms 1 and 2 are invoked, but: • the zigzagging excess check is performed as in Algorithm 1 (possibly with the extension of various zigzagging limits), • the zigzagging check is performed again, not for approximate trajectories T 1 , . . . , T r , but for these trajectories, each with the destination point appended.
If any of these checks triggers an alarm, the entire algorithm generates an alert. This extension allows to trigger alarms in some situations. A typical situation is when a vehicle starts its trip in the direction that is opposite to its destination, in order to perform some illegal activity. Then, in the basic algorithm, any zigzagging activity observed increases extensively only after the illegal location has been reached and upon the vehicle starts moving towards the legal destination. However, an operator observing the route might be aware of the bad intentions of the driver even before the illegal location is reached. The vehicle driving in the opposite direction it allowed to continue doing so. By adding an artificial segment to the route covered so far, which predict the route ahead, allows the proposed algorithm to alert the operator before the illegal location is reached. This advantage is illustrated by one of the experiments presented further on.

Discussion
Parameter minstride of the finest resolution naturally determines the rank of distance corresponding to "nonsensitivity level" of the algorithm to small deviations from the route. Along short sections of the trajectory, comparable with minstride, zigzagging may reach high values without triggering an alarm. This allows the driver to safely deviate to roadside facilities, such as hotels, restaurants or service stations. This mechanism allows for some other maneuvers as well: passing multi-level intersections, bypassing local one-way roads, performing maneuvers required by road signs. These trip disturbances may cause considerable local trajectory zigzagging, even imply trajectory looping, but as long as they are limited to a specific area of the minstride rank, they will be accepted by the algorithm.

Memory usage. Memory usage of the presented algorithm is
The proposed algorithm assumes a limited length of the route and rrbu f len and minstride are arbitrarily chosen constants. While limiting the route length by constant maxroutelength, constant memory usage is ensured. This assumption is not very restrictive in practice and memory usage increases only logarithmically with a potential increase in maxroutelength.

Metrics used.
In the algorithm, the length of shortest line on the Earth surface between two points x, y is computed by function dist(x, y). However, there is a possibility of using map information instead, and of calculating the values of dist(x, y) as the shortest road-based route between x and y. Some additional care must be taken to account for potential noncommutativity of such a distance. This increases the precision of the algorithm and boosts its independence from specific road network configurations. Certainly, the zigzagging limits would be decreased in such a scenario. However, such a solution is complex to implement in largescale systems, i.e. for monitoring purposes. It requires additional memory to cache the map data locally in order to avoid extensive data traffic exchanges with the map server. Moreover, cache memory should also offer a mechanism for quickly calculating the distance between specific locations. Finding the shortest route online would clearly consume too much resources. The mechanism should perhaps contain some mesh of points with predefined distances and, based on this data, should approximate the distance between two given locations. This an interesting research problem in itself.
Traveling salesman case. It is often the case that a vehicle starting its trip has several destinations to visit. The algorithm may still be applied to such a scenario, even when the order of the visits is not known to the algorithm. The trajectory covered so far needs to be simply reset to empty and started anew upon any destination. This will allow only the zigzagging along the route section between two consecutive destination points to be examined. This fragment should be economical, i.e. no excessive zigzagging should be present. The extension expanding trajectories by destination locations is slightly more difficult to adopt in this case, since there are many destinations and we do not know which is to be reached first. Therefore, at the receiving point x i , we should try all destinations and select the scenario that is most favorable for the driver. If no attempts trigger the alarm, the algorithm should keep quiet.

Numerical Demonstration
Several experiments with the proposed algorithm have been conducted. Their aim was to simply validate the presented approach, and to showcase the specific features and the behavior of the algorithm in typical scenarios. The extension providing various zigzagging limits was on, while the extension making use of the destination location was off by default, and was only switched on in one experiment. Default parameter settings were used. A Java environment was used in the experiments. The code was written to retain the algorithm's efficiency, i.e. cyclic buffers were used to collect the selected past points of the trajectory. The routes were generated in using the Google MyMaps service as optimal routes form the town of Skierniewice to Warsaw (Poland). To obtain uneconomical variants of the route, specific mid-points were added to Google's route finder. These points served as illegal locations, while the algorithm was still simply aware of Warsaw as the vehicle's destination. The algorithm observed the trajectory online and triggered alarms, detecting suspected fraud. It needs to be remained that the algorithm is designed to alert once for each route to avoid a storm of alarms for consecutive trajectory points. The point of the trajectory at which the alarm occurred was registered and included in the subsequent presentation of the results.
The following experiments have been performed: • the route from Skierniewice to Warsaw without any mid-points. It was expected that this route would not be assessed as suspicious; • the route from Skierniewice to Warsaw with an additional mid-point in a forest in the village of Krakowiany, near the main road. This route includes an apparent deviation using a road leading to the forest and should trigger an alarm. The forest, however, is located near the main road (relatively to the length of the entire route). Thus, zigzagging measure along    the entire route could not be excessive. The example checks whether the algorithm reacts to an increase in zigzagging observed locally; • the route from Skierniewice to Warsaw, with a midpoint of Łódź. When going to Łódź, a driver leaving Skierniewice needs to go in the opposite direction than when heading to Warsaw. Therefore, such a route should trigger an alarm; • the route from Skierniewice to Warsaw, with a midpoint of Łódź and, unlike in the case of other experiments, the knowledge of the destination has been used in this test. This means that the algorithm augmented the trajectory covered so far with a segment between the current location and the destination. This augmentation should result in the alarm being triggered even earlier than in a scenario without augmentation.
The routes are presented in Figs. 4-7. The results of the experiments are presented in the form of icons in pink circles positioned at the locations where an alarm was detected.
Since the roads on which the alerts were triggered are of the two-way variety, it is difficult to see, in the pictures, which direction the vehicle was driving in while causing the alarm. This is stated in the captions. The alarms were triggered in concordance with our expectations. They appeared precisely along the routes with mid-points that emulated illegal load or drop locations. The route with the deviation to a forest shows the algorithm's ability to consider local route zigzagging. As far as the deviation to Łódź is concerned, the advantage of augmenting the route with a segment between the current location and the destination was shown. Without the augmentation, the alarm is triggered after visiting the town. With the augmentation, the alarm is generated earlier, on the way towards Łódź. This is beneficial, since the algorithm with augmentation is capable of making the same observations as a human being. The vehicle is supposed to head for Warsaw, but drives in the opposite direction instead. Also, the alarm is raised, in such a scenario, before the illegal activity takes place, which allows the proactive actions to be taken by the operator.

Conclusions
The proposed stream algorithm is capable of detecting truck fraud. In contrast to its numerous counterparts, the proposed solution uses an adequate and human-understood route economy measure. It is lightweight and does not require a learning phase. In experimental trials it turned out to behave reasonably and predictably.