A financial vehicle risk early warning method and system based on multi-source data fusion

Abstract

The application provides a financial vehicle risk early warning method and system based on multi-source data fusion, a double-layer fusion system of a periodic rule calculation layer and a real-time streaming early warning layer is constructed, and two types of early warnings are uniformly converged and written into the same risk early warning record table; the periodic layer calculates the driving mileage increment and the maximum continuous offline duration according to a preset period, and realizes cyclic early warning deduplication by combining the mileage change with the joint key of the terminal identifier, the model identifier and the condition type; the real-time layer subscribes to independent message topics according to the risk type, and uniformly falls into the database after parallel consumption of multiple topics; the vehicle health state and the offline duration are obtained, when the vehicle state is abnormal, a compact threshold ladder is used, when the vehicle state is normal, a loose threshold ladder is used, the offline risk is divided into low, medium, high and high risk levels according to the corresponding offline duration threshold, and is persisted. The application generates a risk early warning which is credible and can be graded in a unified view, noise reduction and timeliness are considered, and false positives and false negatives are significantly reduced.

Description

Technical Field

[0001] This invention relates to the fields of vehicle networking and auto finance risk control technology, specifically to a risk warning method and system for financed / leased vehicles, and more particularly to a multi-source data risk warning method that integrates real-time streaming alarms and periodic rule calculations, and performs adaptive risk classification based on vehicle health status. Background Technology

[0002] In auto finance (consumer loans, financial leasing) businesses, financial institutions conduct full-process monitoring of loaned vehicles. They need to promptly identify various risk events such as "vehicle idleness, abnormal cross-border or border activities, periodic operational anomalies, deviation from frequently used operating areas, and terminal offline malfunction," in order to take measures such as collection and vehicle locking before borrower default. Vehicle risk data sources are highly heterogeneous, mainly including: real-time satellite positioning, vehicle speed, and online status reported by in-vehicle terminals; mileage or activity statistics calculated by big data platforms; electronic fence entry / exit and dwell events; and device anti-tampering alarms, etc.

[0003] Traditional financial / financial leasing vehicle risk warning systems typically employ two technical approaches: one is based on periodic scanning of vehicle status using scheduled tasks and comparing it against fixed thresholds; the other is based on real-time event subscription via message queues (such as Kafka). These two approaches are usually deployed independently, resulting in fragmented storage of warning results and making it difficult to create a unified view of vehicle risk. Furthermore, existing warning methods generally suffer from the following technical shortcomings: First, the aforementioned fragmentation directly leads to a scattered risk view. Because periodic calculations and real-time event alarms are deployed independently and their results are stored in a scattered manner, operators need to query across multiple systems one by one to grasp the complete risk status of a vehicle, which is inefficient and makes it difficult to make an overall assessment of the risk of a vehicle—risk information cannot be viewed and assessed uniformly in the same view.

[0004] Second, the fragmented nature of the data leads to duplicate and untimely warning results. Due to the lack of a unified risk record and deduplication basis, periodic scans will repeatedly trigger the same warning for stationary vehicles, generating a large number of duplicate alarms and drowning out real new risks. Once the vehicle status changes (such as starting to drive again), it will be missed due to the lack of a cross-cycle deduplication mechanism, making it difficult to balance noise reduction and timeliness.

[0005] Third, the scattered and repetitive warnings further complicate risk classification, resulting in both false alarms and missed alarms. Because the alarms on which the classification depends are scattered and contain a lot of repetitive noise, the existing technology can only use a uniform risk assessment standard for all vehicles, and cannot take into account the differences in the health status of the vehicles themselves. For vehicles with abnormalities (such as equipment failure) and healthy vehicles, the same offline duration threshold is used for classification, resulting in both false alarms and missed alarms, and the risk assessment granularity is coarse.

[0006] Fourth, the fragmented architecture leads to insufficient coverage of risk types and inadequate business coordination. Due to the lack of a unified organizational and coordination foundation, the existing early warning system lacks systematic coordination of business elements such as border / port risks, electronic fences, and vehicle whitelists. Port configuration, fence creation, and vehicle whitelist synchronization rely heavily on manual maintenance, resulting in configuration delays and timeouts for large-scale synchronizations, which affects the timeliness of identifying real-time border risks.

[0007] As the above shows, the shortcomings of scattered, repetitive, crudely graded, and insufficiently coordinated early warnings all stem from the same source—the root cause lies in the lack of a unified, reliable, and actionable risk data foundation in existing technologies. These technologies cannot converge periodic and real-time warnings to a single view, nor can they deduplicate and refine alarms within this view, thereby enabling differentiated grading based on reliable alarms. Existing technologies have never addressed the technical problem of "generating reliable and graded risk warnings for a massive number of regulated vehicles under a unified view," nor have they provided corresponding solutions, resulting in operators consistently being unable to make accurate and timely decision-making based on the warning view. Therefore, there is an urgent need in this field for a technology capable of generating reliable and graded risk warnings under a unified view. Summary of the Invention

[0008] The purpose of this invention is to address the shortcomings of existing technologies by proposing a financial vehicle risk early warning method and system based on multi-source data fusion.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A financial vehicle risk early warning method based on multi-source data fusion includes the following steps: S1. Construct a two-layer fusion system: Construct a periodic rule calculation layer and a real-time streaming early warning layer, so that the periodic early warnings generated by the periodic rule calculation layer and the real-time early warnings generated by the real-time streaming early warning layer are uniformly converged and written into the same risk early warning record table to form a unified risk view.

[0010] S2, Periodic Layer Sliding Window Indicator Calculation and Recurring Early Warning Deduplication: The periodic rule calculation layer performs risk indicator calculations on the monitored vehicles according to a preset period, calculating the mileage increment and the maximum continuous offline time; before determining whether to trigger an early warning, the most recent early warning record is queried using the joint key of terminal identifier, model identifier, and condition type. If the cumulative mileage recorded in the most recent early warning record is equal to the current last mileage, it is determined that the vehicle status has not changed and the current round of early warning is skipped; if the mileage changes, a new early warning is generated.

[0011] S3, Real-time multi-risk type consumption and unified database entry: The real-time streaming early warning layer subscribes to independent message topics according to risk type, and after multi-topic parallel consumption and processing, the messages are uniformly entered into the risk early warning record table.

[0012] S4, Adaptive Risk Classification: Obtain the vehicle health status and offline duration corresponding to the terminal abnormal event. When the vehicle health status is abnormal, a compact threshold ladder is used; when it is normal, a loose threshold ladder is used. The offline risk is divided into low, medium, high, and high risk levels according to the corresponding offline duration threshold, and is persisted to the risk warning record table along with the abnormal event.

[0013] Furthermore, before the periodic rule calculation layer performs risk indicator calculation, it requests a distributed lock from the cache with a fixed key. The lock lease is set to a preset duration. If the request fails, the node exits directly, ensuring that only one node performs scanning at any given time. The lock is released when the task ends. The entire set of regulated vehicles is queried in batches, the regulator's identifier is extracted, and the warning model configuration of type activity is loaded according to the regulator group, skipping the models that have been deactivated.

[0014] Furthermore, after the periodic rule calculation layer loads the early warning model configuration, it reads the model's push frequency field and performs calendar gating according to the push frequency: when the push frequency is timely or daily, it is executed every time; when it is weekly, it is executed only when the day is Monday; when it is monthly, it is executed only when the day is the first of the month; models that fail the gating are skipped in this round.

[0015] Furthermore, the triggering conditions for each early warning model are persisted in the form of an array. Each condition includes a condition type, a threshold, and a number of monitoring days. Condition types include leaving the fence, less than the required mileage, continuous offline status, and a combination of less than the required mileage and continuous offline status. When calculating the mileage increment, the starting point of the sliding window is determined according to the number of monitoring days for each condition. The last satellite positioning data sequence of the terminal within the window is queried, and the difference between the cumulative mileage of the first and last two data points in the sequence is taken as the mileage increment. When calculating the maximum continuous offline duration, the data sequence is traversed in reverse order, and the offline duration of each segment is accumulated and the maximum value is converted to hours. When comparing thresholds, a trigger is given if the mileage increment is less than the threshold or the maximum continuous offline duration is greater than or equal to the threshold. For compound conditions, all sub-conditions must be met simultaneously. When a model contains multiple conditions, the monitoring time window takes the maximum value of the number of monitoring days for each condition.

[0016] Furthermore, when querying the most recent warning record using the joint key of terminal identifier, model identifier, and condition type for cyclical re-warning deduplication, if the cumulative mileage recorded in the most recent warning record is exactly equal to the current last mileage, it is determined that the vehicle status has not changed, and the current round is skipped without generating a new warning. If the mileage has changed, a new warning is generated when the triggering condition is met. This not only suppresses repeated warnings when the vehicle is stationary, but also allows for reassessment and re-warning after the vehicle has started moving again.

[0017] Furthermore, the real-time streaming early warning layer subscribes to independent message topics based on risk type, including: vehicle idle risk topic, which generates early warnings based on vehicle mileage alarms calculated by the consumer big data platform and after verifying the channel and service activation status, according to the configured number of idle months and idle mileage; border activity risk topic, which generates early warnings based on consumer electronic fence stay alarms, only handling events where the stay in the area exceeds the time limit and the alarm starts, using the fence identifier carried by the alarm to look up the port configuration, and generating early warnings based on the port name, radius, and stay duration after a match; stage operation anomaly topic, which generates early warnings based on the configured number of consecutive months and mileage threshold; and frequently visited area anomaly topic, which generates early warnings based on the abnormal city array calculated by the consumer big data platform; each topic is configured with independent consumer groups and container factories that do not block each other, and each type of consumer is batch inserted into the risk early warning record table and early warning SMS messages are sent in batches according to the SMS switch.

[0018] Furthermore, the method also includes automatic synchronization of port and fence linkage configuration and whitelist: maintaining the port's latitude and longitude, monitoring radius, stay duration threshold, and neighboring country information; when the port is saved, if the coordinates, radius, and stay duration are complete, the electronic fence service is called to create a circular fence and set fence rules, the fence identifier is written back to the port configuration, the fence and rules are updated synchronously when the configuration changes, and the fence is disabled or deleted when the configuration is incomplete or deleted; after the fence is created, all vehicles with activated services are asynchronously queried, and the fence whitelist interface is called in batches according to the configurable batch size to avoid timeouts for large-scale single calls.

[0019] Furthermore, after obtaining the vehicle health status and offline duration corresponding to the terminal abnormal event, a compact threshold ladder is used when the vehicle health status is abnormal; and a loose threshold ladder is used when the vehicle health status is normal; so that the same offline duration indicator can be differentiated in risk assessment under different vehicle health statuses.

[0020] This invention also provides a financial vehicle risk early warning system based on multi-source data fusion, including a periodic rule calculation layer, a real-time streaming early warning layer, a port and fence linkage module, an adaptive risk classification module, and a unified risk record table; wherein, the periodic rule calculation layer and the real-time streaming early warning layer are respectively connected to the unified risk record table and jointly write risk early warning records, the port and fence linkage module is connected to the real-time streaming early warning layer and provides fence and whitelist support for port risks in the real-time layer, and the adaptive risk classification module is connected to the unified risk record table and writes offline risk levels into the unified risk record table.

[0021] It should be further pointed out that the aforementioned unified risk record table, cyclical re-warning deduplication, and adaptive risk grading are not independent optional means, but rather three interdependent structural links that constitute the complete technical solution of this invention. These three are closely technically related: First, without a unified risk record table as a common data foundation, periodic and real-time warnings are stored separately, making cyclical re-warning deduplication impossible due to the lack of a unified deduplication basis across periods and types. Adaptive grading will also lack a basis due to the lack of a reliable alarm set after convergence. Second, if only a unified risk record table is established without cyclical re-warning deduplication, the table will be filled with repeated alarms triggered by vehicles in a stationary state, drowning out genuine new risks. Any risk grading based on this will be meaningless due to distorted input data. Third, if only unified data entry and deduplication are implemented without adaptive grading based on vehicle health status, even if reliable, deduplicated alarms are obtained, it will be impossible to use differentiated judgment criteria for vehicles in abnormal states (such as equipment failure or signal abnormalities) and healthy vehicles. False alarms and missed alarms will still coexist, and the manageability of warnings will be impossible to implement. Therefore, the unified risk record table provides a reliable and convergent risk data foundation. The cyclical re-warning and deduplication on this foundation suppresses repetition and retains new risks. The adaptive classification is based on the reliable deduplicated alarms and accurately classifies them according to the vehicle's health status. These three elements constitute a progressive and closed-loop technical chain of "unified foundation → alarm purification → accurate classification". The absence of any link will cause the warning view to be unable to support accurate and timely handling decisions. Therefore, the above features must be implemented in a coordinated manner and cannot be separated. This is a technical effect that cannot be achieved by the existing technology of separating periodic and real-time warnings and storing them separately.

[0022] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention generates a reliable and tiered unified risk view. It unifies the periodic rule calculation layer and the real-time streaming warning layer into a single risk warning record table. On this unified table, a combination of terminal identifier, model identifier, and condition type key, along with mileage changes, is used to achieve cyclical re-warning deduplication. Based on the deduplicated reliable alarms, adaptive tiering is performed according to vehicle health status. These three elements constitute a progressive data chain of "unified view → alarm refinement → precise tiering." The quality of downstream tiering depends on upstream alarm refinement, collectively solving the technical problem that existing technologies cannot generate reliable and tiered risk warnings under a unified view. This achieves an unexpected technical effect through holistic collaboration, something that no single technical means could accomplish.

[0023] It achieves a unified view by integrating periodic and real-time data. Periodic rule calculations and real-time streaming alerts are converged into a single risk alert record table, allowing operators to view all risks in one place. This eliminates the inefficiency of cross-system queries and provides a unified foundation for overall vehicle risk assessment.

[0024] This invention employs an adaptive grading system based on vehicle health status to significantly reduce false alarms and missed alarms. It uses a differentiated dual-threshold tiered approach to offline duration based on vehicle health status: when a vehicle is in an abnormal state (such as equipment failure or signal anomaly), its offline status often indicates a greater risk (possibly due to human intervention or loss of control), so a tight threshold is used to escalate the risk as early as possible; occasional short-term offline status of healthy vehicles (such as entering a signal blind spot) carries a lower risk, so a lenient threshold is used to avoid false alarms. Therefore, the same offline duration metric yields a more realistic risk assessment under different vehicle health states—even using only this adaptive grading method, it can independently address the shortcomings of existing technologies where "uniform standard grading leads to both false alarms and missed alarms," ​​effectively reducing both. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the overall implementation process of the present invention. Detailed Implementation

[0026] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0027] Reference Figure 1 One embodiment of the present invention proposes a financial vehicle risk early warning method based on multi-source data fusion, which constructs a two-layer fusion system of "periodic rule calculation layer + real-time streaming early warning layer", with both types of early warning falling into the same risk early warning record table, and adaptive risk classification is performed in combination with the vehicle health status.

[0028] The system of this invention includes: a periodic rule calculation layer, a real-time streaming early warning layer, a port and fence linkage module, an adaptive risk classification module, and a unified risk record table. Multi-source data flows into the corresponding modules, and the periodic and real-time layers are jointly written into the unified risk record table. The port and fence linkage module provides fence and whitelist support for port risks in the real-time layer, and the adaptive classification module writes offline risk levels into the same record table.

[0029] The specific implementation of this embodiment will be described in detail below, step by step.

[0030] S1, Loading of the distributed lock access control and early warning model for the periodic rule calculation layer. S11, Distributed Lock Admission. A distributed lock is requested from the cache using a fixed key, with the lock lease set to a preset duration (e.g., 30 seconds). Nodes that fail to obtain a lock exit immediately, ensuring that only one node performs the scan at any given time, avoiding duplicate alerts from multiple nodes in a cluster environment. The lock is released upon completion of the task.

[0031] In a cluster deployment scenario, without a distributed lock, multiple computing nodes will simultaneously perform periodic scans on the same batch of vehicles and generate their own warnings, resulting in a large number of duplicate alarms. The distributed lock ensures that only one node scans at any given time, eliminating duplicate warnings from the source.

[0032] S12, Load regulated vehicles and early warning models. Perform a batch query of the entire set of regulated vehicles, extract their regulator identifiers, and load early warning model configurations of type "activity" by regulator group. Skip deactivated models to ensure efficient model loading and avoid triggering deactivated rules.

[0033] S13, Push Frequency Calendar Gating. Read the push frequency field of the model and perform calendar gating according to its value—execute every time if timely, execute every time if daily, execute only if weekly, execute only if the day is Monday, and execute only if monthly. Models that fail the gating are skipped in this round.

[0034] Different regulators have different requirements for the frequency of early warning pushes (some require real-time updates, while others only require weekly / monthly summaries). Calendar gating makes the push frequency configurable, allowing for output according to the regulator's differences without modifying the code, while avoiding frequent and invalid calculations in low-frequency scenarios.

[0035] S14, Parse multi-condition rules. The trigger conditions for each warning model are persisted in the form of an array, including condition type, threshold, and number of monitoring days; the condition types include: leaving the fence, less than the driving mileage, continuous offline time, and a compound condition of less mileage and continuous offline time.

[0036] S2, Sliding window index calculation and cyclical re-early warning deduplication Calculate risk indicators for each vehicle on each model and remove duplicates.

[0037] S21, Monitoring window determined. Calculate the starting point of the sliding window based on the number of days specified (the zero point of that number of days prior to the current date), and query the last satellite positioning data sequence of the terminal within the window.

[0038] S22, Calculation of mileage increment. Sort the data sequence within the window by time, and take the difference between the cumulative mileage of the first and last two data points as the mileage increment, denoted as Equation (1): ΔM = M_end - M_start In the formula: M_end is the cumulative mileage of the last location record in the window, M_start is the cumulative mileage of the first location record in the window, and ΔM is the mileage increment.

[0039] The technical effect of this formula is that when a vehicle hardly moves within the monitoring window (ΔM is less than the threshold), it reflects that the vehicle is in an idle or abnormally stagnant state, which is the basic indicator for determining whether the "mileage less than" condition has been triggered.

[0040] S23, Calculation of maximum continuous offline duration. The data sequence is traversed in reverse order, and the time difference between segments in the offline state is accumulated. If an online segment is encountered, it is disconnected, and the accumulated duration is added to the offline segment list. Finally, the maximum value among all offline segments is taken and converted to hours, which is the maximum continuous offline duration, denoted as Equation (2): T_off = max{t_1,t_2,…,t_k} In the formula: t_1…t_k is the duration of k consecutive offline time periods in the data sequence.

[0041] The technical effect of this formula is that it uses "the longest offline time" instead of "cumulative offline time" as the indicator, which is more in line with the semantics of risk. Continuous long-term offline time (such as the device being disassembled or the vehicle losing connection) is often more risky than multiple short-term offline times. The longest continuous offline time can more accurately characterize the risk of terminal loss of control.

[0042] S24, Threshold Comparison. Compare the incremental mileage with the conditional threshold (trigger if less than the threshold), and compare the maximum continuous offline time with the conditional threshold (trigger if greater than or equal to the threshold); for composite conditions, both sub-conditions must be satisfied simultaneously; when the model contains multiple conditions, the monitoring time window takes the maximum value of the number of monitoring days for each condition.

[0043] S25, repeat warning deduplication. Before triggering, query the most recent warning record of the terminal, model and condition type using the joint key of terminal identifier, model identifier and condition type. If it exists and the cumulative mileage of the record is exactly equal to the current last mileage, it is determined that the vehicle status has not changed, and the warning is skipped in this round and no new warning is generated; if the mileage has changed, a new warning is generated. The judgment condition is denoted as Equation (3): Trigger warning ⇔ (Mileage less than threshold ∨Offline reaches threshold) ∧Mileage changes; The logical OR indicates that the mileage is less than the threshold or the offline time reaches the threshold, while the logical AND indicates that the mileage has changed. An alert is triggered only when both conditions are met.

[0044] The technical effects of this formula are as follows: for stationary vehicles (such as those parked for a long time without driving), the mileage does not change, and even if the offline / mileage threshold is repeatedly met, warnings will not be repeatedly generated, thus suppressing repetitive alarm noise; once the vehicle is driven again (the mileage changes), the assessment is re-evaluated and a warning is issued again, balancing noise reduction and timeliness, and ensuring that new risks are not missed.

[0045] S3, multi-topic consumption and unified database entry in the real-time streaming early warning layer. Subscribe to independent message topics based on risk type. Each topic is configured with an independent consumer group and container factory, which do not block each other. After processing, all messages are uniformly recorded in the risk warning log table, which includes four categories: S31, Vehicle Idle Risk. The consumer big data platform calculates vehicle mileage alerts, verifies channel and service activation status, and generates warnings based on the system-configured "number of idle months + idle mileage".

[0046] S32, Border Activity Risk. Consumer electronic fence stay alarm, only handles the event of "staying in the area for longer than the time limit and alarm starting", uses the fence identifier carried by the alarm to check the port configuration, and if it is matched, an alert is generated according to the port name, radius and stay duration.

[0047] S33, Abnormal Operational Stage. An alert is generated based on the system's configured "number of consecutive months + mileage threshold".

[0048] S34, an anomaly in the frequently accessed area. An alert is generated based on the abnormal city array calculated by the consumer big data platform.

[0049] S35, Batch data entry and SMS outbound calling. For each type of consumer, batch insert risk warning record table, and send warning SMS messages in batches by pressing the SMS switch.

[0050] The technical effects of this mechanism are as follows: independent topics are subscribed to according to risk type without blocking each other, ensuring that the consumption of various real-time risks (idle / border / operational / frequent) does not affect each other, and the warnings of the S1 cycle layer are uniformly included in the same risk warning record table, realizing the integration of "cycle + real-time" under a unified view.

[0051] S4, Port and Fence Linkage Configuration and Automatic Whitelist Synchronization S41, Port Configuration Management. Maintain the port's latitude and longitude, monitoring radius, stay duration threshold, neighboring country information, and perform verification of the upper limit for the number of newly added ports.

[0052] S42, Fences are automatically created or updated. When a port saves data, if the coordinates, radius, and duration of stay are complete, the electronic fence service is invoked to create a circular fence and set fence rules. The fence identifier is written back to the port configuration. When the configuration changes, the fence and rules are updated synchronously. If the configuration is incomplete or deleted, the fence is disabled or deleted, and an alarm is triggered.

[0053] S43, vehicle whitelist synchronization in batches. After the fence is created, all vehicles with activated services are queried asynchronously, and the fence whitelist interface is called in batches according to the configurable batch size to synchronize, avoiding timeouts for large-scale single calls.

[0054] The technical effects of this mechanism are: automatic creation and updating of electronic fences at ports and batch synchronization of vehicle whitelists, eliminating the lag of manual maintenance; batch synchronization avoids timeouts caused by large-scale single calls to the fence whitelist interface, ensuring the timely identification of real-time risks (corresponding to S32) at borders / ports.

[0055] S5, Adaptive Risk Classification Based on Vehicle Health Status For terminal offline abnormal events, a dual-threshold tiered risk classification is used based on the vehicle's health status.

[0056] S51, Consumer terminal abnormal event, obtain the vehicle's health status (0 for abnormal, 1 for normal) and offline time.

[0057] S52, dual threshold grading. When the vehicle status is abnormal, a compact threshold ladder is used (a shorter offline time indicates a higher risk); when the vehicle status is normal, a loose threshold ladder is used (a longer offline time indicates a higher risk). The grading function is denoted as Equation (4): Risk level = f(offline duration, vehicle health status) Among them: vehicles with abnormal health status are subject to a tight threshold (e.g., 2 hours offline is medium risk, 6 hours is high risk, and 24 hours is high risk); vehicles with normal health status are subject to a loose threshold (e.g., 8 hours offline is medium risk, 24 hours is high risk, and 72 hours is high risk).

[0058] The technical effect of this formula is as follows: when a vehicle is in an abnormal state (such as equipment failure or signal anomaly), its offline status often indicates a greater risk (possibly due to human dismantling or loss of control), so a tight threshold is used to upgrade the risk as early as possible; while the risk of a healthy vehicle occasionally going offline for a short time (such as entering a signal blind spot) is lower, so a loose threshold is used to avoid false alarms. Thus, the same offline duration indicator can be used to obtain differentiated and more realistic risk assessments under different vehicle health states, reducing false alarms and missed alarms.

[0059] S53, Data Storage. The risk level (low, medium, high, high risk) is persisted along with the abnormal event, allowing the operator to handle it according to the level.

[0060] For example, a vehicle terminal in a financial leasing company reports an offline anomaly event. After processing the event, the vehicle's health status is determined to be "abnormal" and the offline duration is 5 hours. Based on a compact threshold tier for abnormal vehicles, vehicles offline for 5 hours (≥6 hours below the high-risk threshold, ≥2 hours above the medium-risk threshold) are classified as medium-risk. The risk level and the anomaly event are then persisted to the risk warning record table, and the operator handles them according to the medium-risk level. If the same vehicle's health status is "normal," then 5 hours of offline time (less than the 8-hour medium-risk threshold) is classified as low-risk to avoid false alarms.

[0061] Through the above steps S1-S5, this invention unifies periodic rule calculation and real-time streaming early warning into the same risk early warning record table. By cyclical re-early warning and deduplication, it takes into account both noise reduction and timeliness, and adaptively classifies according to the vehicle health status, thus realizing multi-source data fusion risk intelligent early warning for vehicles after auto finance loans.

[0062] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A financial vehicle risk early warning method based on multi-source data fusion, characterized in that, Includes the following steps: S1. Construct a two-layer fusion system of periodic rule calculation layer and real-time streaming early warning layer, so that the periodic early warning generated by the periodic rule calculation layer and the real-time early warning generated by the real-time streaming early warning layer are uniformly converged and written into the same risk early warning record table to form a unified risk view. S2, the periodic rule calculation layer performs risk indicator calculations on the monitored vehicles according to a preset period, and calculates the mileage increment and the maximum continuous offline time; Before determining whether to trigger an alert, the most recent alert record is queried using the joint key of terminal identifier, model identifier, and condition type. If the cumulative mileage recorded in the most recent alert record is equal to the current last mileage, it is determined that the vehicle status has not changed and the current alert is skipped. If the mileage has changed, a new alert is generated. S3, the real-time streaming alert layer subscribes to independent message topics according to risk type. After multiple topics are consumed and processed in parallel, they are uniformly included in the risk alert record table. S4. Obtain the vehicle health status and offline duration corresponding to the terminal abnormal event. When the vehicle health status is abnormal, a compact threshold ladder is used; when it is normal, a loose threshold ladder is used. The offline risk is divided into low, medium, high, and high risk levels according to the corresponding offline duration threshold, and is persisted to the risk warning record table along with the abnormal event.

2. The method according to claim 1, characterized in that, The use of a compact threshold ladder in S4 refers to the following: for vehicles with abnormal health status, a shorter offline time is sufficient to classify them as having a higher risk level. The compact threshold ladder is as follows: an offline time of the first duration indicates medium risk, the second duration indicates high risk, and the third duration indicates extremely high risk. The use of a lenient threshold ladder refers to the following: for vehicles with normal health status, a longer offline time is required to classify them as having a higher risk level. The lenient threshold ladder is as follows: an offline time of the fourth duration indicates medium risk, the fifth duration indicates high risk, and the sixth duration indicates extremely high risk. The first to third durations are respectively shorter than the fourth to sixth durations.

3. The method according to claim 1, characterized in that, Before the periodic rule calculation layer described in S2 performs the risk indicator calculation, it also includes: applying for a distributed lock from the cache with a fixed key, setting the lock lease to a preset duration, and directly exiting if the application fails, ensuring that only one node performs scanning at the same time, and releasing the lock after the task ends; and batch querying all regulated vehicle sets, extracting the regulator's identifier, loading the early warning model configuration of activity level according to the regulator group, and skipping the deactivated models.

4. The method according to claim 1, characterized in that, When determining whether to generate a new warning in S2, the most recent warning record is queried using the joint key of terminal identifier, model identifier, and condition type: if the cumulative mileage recorded in the most recent warning record is exactly equal to the current last mileage, it is determined that the vehicle status has not changed, and this round is skipped and no new warning is generated. If the mileage changes, a new warning is generated when the triggering conditions are met, thus both suppressing repeated warnings when the vehicle is stationary and reassessing and issuing warnings again after the vehicle has started moving again.

5. The method according to claim 1, characterized in that, The real-time streaming early warning layer described in S3 subscribes to independent message topics based on risk type, including: vehicle idle risk topic, which generates early warnings based on vehicle mileage alarms calculated by the consumer big data platform and after verifying the channel and service activation status, according to the configured number of idle months and idle mileage; border activity risk topic, which generates early warnings based on consumer electronic fence stay alarms, only handling events where the stay in the area exceeds the time limit and the alarm starts, using the fence identifier carried by the alarm to look up the port configuration, and generating early warnings based on the port name, radius, and stay duration after a match; stage operation anomaly topic, which generates early warnings based on the configured number of consecutive months and mileage threshold; and frequently visited area anomaly topic, which generates early warnings based on an array of abnormal cities calculated by the consumer big data platform; each topic is configured with independent consumer groups and container factories that do not block each other, and each type of consumer is batch inserted into the risk early warning record table and early warning SMS messages are sent in batches according to the SMS switch.

6. The method according to claim 1, characterized in that, The method also includes port and fence linkage configuration and automatic whitelist synchronization: maintaining the port's latitude and longitude, monitoring radius, stay duration threshold, and neighboring country information; when the port is saved, if the coordinates, radius, and stay duration are complete, the electronic fence service is called to create a circular fence and set fence rules, the fence identifier is written back to the port configuration, the fence and rules are updated synchronously when the configuration changes, and the fence is disabled or deleted when the configuration is incomplete or deleted; after the fence is created, all vehicles with activated services are asynchronously queried, and the fence whitelist interface is called in batches according to the configurable batch size to avoid timeouts for large batches of single calls.

7. A financial vehicle risk early warning system based on multi-source data fusion, characterized in that, include: The periodic rule calculation layer is used to calculate risk indicators for regulated vehicles according to a preset period, calculate the mileage increment and the maximum continuous offline time, and before determining the triggering of an early warning, query the most recent early warning record using the joint key of terminal identifier, model identifier and condition type to perform cyclical re-early warning deduplication; The real-time streaming alert layer is used to subscribe to independent message topics according to risk type, and to consume and process multiple topics in parallel before storing them in the database. A unified risk record table is connected to the periodic rule calculation layer and the real-time streaming early warning layer, respectively, for unified convergence and writing of periodic early warnings and real-time early warnings to form a unified risk view; The adaptive risk classification module, connected to the unified risk record table, is used to obtain the vehicle health status and offline duration corresponding to abnormal events of the terminal. When the vehicle health status is abnormal, a compact threshold ladder is used, and when it is normal, a loose threshold ladder is used. The offline risk is divided into low, medium, high and high risk levels according to the corresponding offline duration threshold and written into the unified risk record table.

8. The system according to claim 7, characterized in that, In the adaptive risk classification module: for vehicles with abnormal health status, a shorter offline time is used to determine a higher risk level. The compact threshold ladder is that an offline time of the first duration is used to determine medium risk, the second duration is used to determine high risk, and the third duration is used to determine high risk. For vehicles with normal health status, a longer offline time is required to determine a higher risk level. The relaxed threshold ladder is that an offline time of the fourth duration is used to determine medium risk, the fifth duration is used to determine high risk, and the sixth duration is used to determine high risk. The first to third durations are respectively shorter than the fourth to sixth durations.

Images