A false trade monitoring method and system based on data cross-verification
By establishing a fraudulent trade monitoring system based on cross-verification of data, the problems of data silos and information asymmetry from multiple sources have been solved. This system enables full-process monitoring of trade data, enhances the ability to prevent fraudulent trade, and, by building a technological foundation, provides a virtualized fraudulent trade monitoring system. This system realizes the application of fraudulent trade monitoring technologies, enabling accurate identification of fraudulent trade and timely risk control.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA HUADIAN GROUP IND & FINANCIAL HOLDINGS CO LTD
- Filing Date
- 2025-11-04
- Publication Date
- 2026-05-12
AI Technical Summary
In traditional trade monitoring, the scattered storage of multi-source trade data leads to data silos, information asymmetry, and difficulty in timely identification of fraudulent trade activities. Existing technological defense capabilities are weak and cannot meet the needs of trade security.
A fraudulent trade monitoring system based on cross-verification of data is adopted, including a data acquisition module, a dynamic blockchain storage module, an intelligent cross-verification module, a self-learning contract module, and a real-time early warning and handling module. It achieves collaborative communication through encrypted data structure, constructs a multi-dimensional data correlation graph, and combines anomaly quantification algorithm and self-learning contract module for real-time monitoring and early warning.
It has enabled trusted data sharing across entities and industries, improved the accuracy of identifying and preventing fraudulent trade, built a closed loop for risk prevention and control, ensured trade security, and provided a trusted closed loop for monitoring, early warning and handling.
Smart Images

Figure CN121436995B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information monitoring technology, and in particular to a method and system for monitoring fraudulent trade based on cross-verification of data. Background Technology
[0002] Trade is a core component of economic activity, encompassing various activities such as commodity exchange and buying and selling in domestic and international trade. Its smooth operation depends on the effective flow and verification of multi-dimensional data such as contracts, logistics, financing, and supervision generated by trade participants, regulatory agencies, and third-party institutions. The authenticity and relevance of this data are directly related to trade security.
[0003] In current traditional trade monitoring, multi-source trade data is stored in separate systems of different entities, forming "data silos." Cross-entity information sharing is difficult, resulting in serious information asymmetry among trade participants. False trade behaviors (such as forged documents and false financing) are difficult to identify in a timely manner. Existing technologies have weak capabilities to prevent false trade and cannot meet the needs of trade security.
[0004] Therefore, there is an urgent need for a method and system for monitoring fraudulent trade that can improve the accuracy and effectiveness of such monitoring. Summary of the Invention
[0005] To overcome the shortcomings of existing technologies, the purpose of this invention is to provide a method and system for monitoring fraudulent trade based on cross-verification of data. This solves the problems of data silos and information asymmetry in traditional trade, significantly improves the ability to prevent fraudulent trade, and lays a technological foundation for trade security.
[0006] To achieve the above objectives, the present invention provides the following solution:
[0007] One of the objectives of this invention is to provide a fraudulent trade monitoring system based on cross-verification of data, including a data acquisition module, a dynamic blockchain storage module, an intelligent cross-verification module, a self-learning contract module, and a real-time early warning and handling module. Each module achieves collaborative communication through an encrypted data structure.
[0008] The data acquisition module is used to collect real-time multi-source trade data, which includes unique enterprise codes and dynamic feature identifiers, covering structured business data provided by enterprises, unstructured public data released by regulatory agencies, and semi-structured related data from third-party authoritative institutions.
[0009] The dynamic blockchain storage module adopts a consortium blockchain architecture to deploy endorsement nodes, ledger nodes, and cross-chain gateways. It is used to store offline trade data that is updated dynamically. The data is guaranteed to be tamper-proof through hash encryption, timestamps, and node signatures. Data synchronization with industry vertical chains is achieved through cross-chain gateways.
[0010] The intelligent cross-verification module is used to retrieve offline trade data from the dynamic blockchain storage module, compare it with real-time multi-source trade data in terms of dimensions, calculate the comprehensive anomaly degree through an anomaly quantification algorithm that integrates industry characteristics, and identify data inconsistencies and logical conflicts.
[0011] The self-learning contract module has a built-in initial compliance rule library. It generates a dynamic rule update model by training through historical verification results, automatically verifies the compliance of real-time data and offline data, and outputs compliance verification results with confidence.
[0012] The real-time early warning and handling module is used to generate an early warning level by combining the comprehensive anomaly degree and compliance verification results, trigger the corresponding level of business freeze interface, and write the early warning and handling records into the dynamic blockchain storage module to form a closed loop.
[0013] Preferably, the data acquisition module includes:
[0014] The enterprise-side data acquisition unit is configured with an adaptive interface to adapt to different enterprise ERP systems, and collects structured business data with dynamic feature representation in real time.
[0015] The regulatory data collection unit extracts information from unstructured public data through OCR recognition and semantic parsing technology;
[0016] The third-party data collection unit uses an API gateway to aggregate semi-structured related data, performs format conversion and feature extraction, and then synchronizes it to the monitoring system.
[0017] Preferably, the consortium blockchain architecture of the dynamic blockchain storage module includes:
[0018] The endorsement nodes are deployed by the trade participants and regulatory agencies respectively, and adopt a role-based access control mechanism;
[0019] The accounting node adopts a distributed storage cluster, and the storage partitions are divided according to the data sensitivity level.
[0020] The cross-chain gateway enables data interaction and verification with vertical industry chains in energy and finance through atomic swap protocols.
[0021] Preferably, the intelligent cross-verification module includes:
[0022] Feature-based association units, with the enterprise's unique code as the core, establish a dynamic association graph between trade data, financing data, and warehousing data;
[0023] The anomaly calculation unit, wherein the anomaly quantification algorithm formula integrating industry characteristics is:
[0024] ;
[0025] in, , , All are weighting coefficients that are dynamically adjusted based on industry characteristics and , C For data consistency, T For data timeliness, R For data correlation, if D When the threshold is reached, it is judged as suspected fraudulent trade.
[0026] Preferably, the self-learning contract module includes:
[0027] The rule base unit is used to store trade process rules, industry-finance linkage rules, and industry rules.
[0028] The training unit uses the gradient descent algorithm to train on historical verification data to generate rule adjustment coefficients;
[0029] The execution unit verifies the compliance of the data based on the initial rules and adjustment coefficients, and outputs the verification results containing a confidence level in the range of 0-1.
[0030] The second objective of this invention is to provide a method for monitoring fraudulent trade based on cross-verification of data, comprising the following steps:
[0031] S1. Collect real-time multi-source trade data, which includes unique enterprise codes and dynamic feature identifiers, covering structured business data, unstructured public data and semi-structured related data.
[0032] S2. Offline trade data is stored through a dynamic blockchain storage module. The offline trade data is updated dynamically and periodically. Hash encryption, timestamps and node signatures are used to ensure that the data is tamper-proof. Data is synchronized with energy and financial vertical industry chains through a cross-chain gateway.
[0033] S3. Using the enterprise's unique code as the core, construct a dynamic correlation graph of trade data, financing data, and warehousing data, and clean and extract features from offline trade data.
[0034] S4. Cross-compare the offline trade data in the dynamic correlation graph with the real-time multi-source trade data, and calculate the comprehensive anomaly degree using an anomaly quantification algorithm that integrates industry characteristics. D ;
[0035] S5. Based on the initial compliance rule base and dynamic rule update model of the self-learning contract module, it automatically verifies the compliance of real-time data and offline data and outputs compliance verification results with confidence.
[0036] S6. Combining the aforementioned comprehensive anomaly degree DThe system generates an early warning level based on the compliance verification results, triggers the corresponding business freeze interface, and writes the early warning and handling records into the dynamic blockchain storage module.
[0037] Preferably, in S1, the collection of real-time multi-source trade data includes:
[0038] S11. Collect structured business data from the enterprise ERP system through an adaptive interface and add dynamic feature identifiers;
[0039] S12. Extract unstructured data information from regulatory agency publications using OCR recognition and semantic parsing technology;
[0040] S13. Aggregate third-party semi-structured related data through the API gateway, convert the format, extract features, and then synchronize it to the monitoring system.
[0041] Preferably, S2 specifically includes:
[0042] S21. The endorsement node performs signature verification on the offline trade data, and generates a hash value and timestamp after successful verification.
[0043] S22. Ledger nodes are stored in corresponding partitions according to data sensitivity level, and cross-chain gateways are synchronously verified with energy and financial vertical industry chains through atomic swap protocols.
[0044] S23. Dynamically adjust the storage cycle according to the data update frequency, and shorten the update interval for high-frequency changing data.
[0045] Preferably, in S4, the anomaly metric algorithm that integrates industry characteristics includes:
[0046] S41, Computational Data Consistency C : C =Base field matching rate × ω 1 + Industry-specific field matching rate × ω 2, of which ω 1. ω Both 2 are industry characteristic coefficients;
[0047] S42. Calculate the timeliness of data T : T = Duration exceeding industry allowable deviation / Duration of industry maximum reasonable deviation T ≤1;
[0048] S43, Calculate data correlation R : R =Trade-finance data matching rate × λ 1+ Trade-Warehouse Data Matching Rate × λ 2, of which λ 1. λ 2 represents the dynamic correlation coefficient;
[0049] S44. Dynamic allocation based on industry type α , β , γ Weights, substitute into the formula for calculation .
[0050] Preferably, in S6, the warning level includes:
[0051] S61. If D ≥ industry high threshold and compliance verification confidence ≥ 0.8, generate a level 1 warning and trigger the core business freeze interface;
[0052] S62, If the industry threshold is ≤ D <If the industry's high threshold or compliance verification confidence level is 0.5-0.8, a level 2 warning will be generated and the associated business interface will be frozen;
[0053] S63, If the industry's low threshold is ≤ D <If the industry threshold or compliance verification confidence level is 0.2-0.5, a level 3 alert is generated and pushed to the management terminal;
[0054] S64. Finally, the warning information, handling records and verification evidence are written into the dynamic blockchain storage module through node signature.
[0055] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:
[0056] (1) This invention solves the problems of data silos and information asymmetry. By covering structured business data of enterprises, unstructured public data of regulators and semi-structured related data of third parties through the data acquisition module, and combining the alliance chain architecture of dynamic blockchain storage module and cross-chain gateway, it realizes trusted data sharing and cross-industry vertical chain synchronization among trade participants, regulatory agencies and third-party institutions. At the same time, it constructs a dynamic association graph with the unique code of the enterprise, and connects the scattered data into an organic whole, which completely solves the problem of "data silos" in traditional trade, which is characterized by scattered data storage and difficulty in cross-entity communication. It significantly alleviates the information asymmetry among the participants and provides a complete data foundation for monitoring false trade.
[0057] (2) This invention improves the accuracy of identifying fraudulent trade and strengthens the ability to prevent it. Relying on the intelligent cross-verification module's fusion industry characteristic anomaly quantification algorithm, it transforms data consistency, timeliness, and correlation into a calculable comprehensive anomaly degree, realizing the transformation from manual subjective comparison to objective quantitative verification. It can also adapt to the exclusive data verification needs of different industries such as energy and finance. In conjunction with the self-learning contract module, it dynamically updates compliance rules based on historical data, avoiding the lag of fixed rules, and greatly improving the accuracy of identifying behaviors such as forged documents, inflated value of goods, and fraudulent financing, effectively strengthening the ability to prevent fraudulent trade.
[0058] (3) This invention constructs a closed-loop risk prevention and control system to ensure trade security. By combining the comprehensive anomaly degree with the compliance verification results through the real-time early warning and handling module, it generates a graded early warning and triggers the corresponding business freezing interface. When a high-risk anomaly is detected, core business (such as fraudulent financing and lending) can be intercepted in a timely manner, which solves the shortcoming of traditional early warning that only "notifies" but does not "handle". At the same time, the early warning information and handling records are written into the blockchain through node signature, forming a complete closed loop of monitoring, early warning, handling and traceability. This not only improves the timeliness of risk prevention and control, but also provides a credible basis for subsequent verification and accountability, and finally lays a solid technical foundation for trade security. Attached Figure Description
[0059] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0060] Figure 1 A schematic diagram of a fraud monitoring system based on cross-verification of data is provided for an embodiment of the present invention.
[0061] Figure 2 This is a schematic diagram illustrating the principle of a method for monitoring fraudulent trade based on cross-verification of data, provided in an embodiment of the present invention. Detailed Implementation
[0062] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0063] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0064] One embodiment of the present invention, such as Figure 1 As shown, a fraud monitoring system based on cross-verification of data is disclosed. The system includes a data acquisition module, a dynamic blockchain storage module, an intelligent cross-verification module, a self-learning contract module, and a real-time early warning and handling module. Each module achieves collaborative communication through an encrypted data structure. This multi-module collaborative approach addresses the problems of data silos, subjective verification, rigid compliance, and lack of a closed-loop prevention and control system in traditional trade monitoring. The specific implementation of each module is as follows:
[0065] The data acquisition module includes an enterprise-side acquisition unit, a regulatory-side acquisition unit, and a third-party acquisition unit. Each unit is designed with adaptive acquisition logic tailored to the characteristics of data from different sources: The enterprise-side acquisition unit adapts to the trade data systems of different enterprises through an adaptive interface, collects structured business data (such as purchase contracts and warehouse receipts) submitted by enterprises themselves, and adds dynamic feature identifiers such as the associated enterprise's unique code, data generation time, and data type to the data; The regulatory-side acquisition unit processes unstructured public data (such as equipment registration announcements and administrative penalty notices) issued by regulatory agencies, first converting the public documents into recognizable text, and then extracting key information (such as enterprise code and registration number) through semantic parsing and associating it with the enterprise's unique code; The third-party acquisition unit aggregates semi-structured associated data (such as test reports and warehouse inventory records) from authoritative third-party institutions at home and abroad through a unified interface, converts data of different formats into a unified standard format, and extracts core feature fields (such as test results and inventory quantity).
[0066] The working principle of the above technical solution is as follows: the data collected by each unit is uniformly aggregated into the system buffer. The buffer is indexed according to "data source-enterprise code", and data integrity checks are performed regularly to delete duplicate data, fill in missing information, and finally push qualified data to the dynamic blockchain storage module to ensure the continuity and quality of data flow.
[0067] The above technical solution achieves the following effects: By collecting and standardizing multi-source data (such as enterprise procurement contracts, regulatory equipment filing announcements, and third-party authoritative reports) from enterprises, regulatory agencies, and third-party authoritative institutions, it can more comprehensively cover the entire trade process information, avoiding the one-sidedness or limitations brought about by a single data source (such as relying solely on enterprise-owned data); Adding dynamic feature identifiers to the data ensures that the data is traceable to specific enterprises and business scenarios, reducing verification errors caused by data confusion; Through adaptive interfaces and unified format conversion, it can adapt to different enterprise data systems and third-party data formats, breaking down compatibility barriers to data access; Performing integrity checks on the collected data can effectively remove duplicate data, correct erroneous data, improve the accuracy and reliability of the data, and lay a high-quality data foundation for subsequent verification processes.
[0068] The dynamic blockchain storage module adopts a consortium blockchain architecture, deploying three types of nodes: endorsement nodes, ledger nodes, and cross-chain gateways. Endorsement nodes are deployed by trade participants, regulatory agencies, financial institutions, and third-party testing institutions, employing a "multi-signature mechanism" requiring at least three types of signatures before data can be written. Ledger nodes are deployed in a distributed cluster, divided into core, general, and public partitions based on data sensitivity levels. The core partition stores sensitive data such as corporate financial data and financing contracts, using encrypted storage. The general partition stores non-core data such as logistics data and testing reports, using differentiated encryption based on field sensitivity. The public partition stores regulatory disclosure data and industry benchmark data, and is open to access. The cross-chain gateway synchronizes data with vertical blockchains in industries such as energy and finance, verifying data consistency during synchronization to ensure that system data and industry blockchain data share a common and trustworthy source.
[0069] The working principle of the above technical solution is as follows: When offline trade data is written, a data hash value and timestamp are generated first, and after being signed by multiple endorsement nodes, it is encapsulated into a transaction and stored in the corresponding partition according to the data sensitivity level; when data is read, the system automatically verifies the data hash value and the endorsement node signature. If the hash value does not match or the signature is invalid, it is marked as "abnormal data"; the cross-chain gateway periodically listens for the data synchronization needs of industry chains, adds a "cross-chain identifier" after synchronizing the data and writes it to the public partition to realize cross-industry data interoperability.
[0070] The effects of the above technical solutions are as follows: By deploying endorsement nodes and multi-signature mechanisms across multiple entities in a consortium blockchain, a decentralized and trusted data storage environment can be built, avoiding the risk of fraudulent trade caused by data tampering by a single entity and improving data credibility; dividing storage partitions according to data sensitivity levels and using differentiated encryption can protect corporate privacy and sensitive information while achieving data sharing, balancing the needs of data sharing and privacy protection; synchronizing vertical blockchain data in industries such as energy and finance through cross-chain gateways (such as coal inventory data in the energy industry and financing filing data in the financial industry) can break down industry data silos and achieve correlation verification between trade data and industry-specific data; offline trade data is updated dynamically based on the update frequency, which can optimize storage efficiency while ensuring data timeliness and avoiding resource waste caused by frequent updates.
[0071] The intelligent cross-verification module includes a feature association unit and an anomaly calculation unit. The feature association unit uses the enterprise's unique code as its core to construct a three-layer dynamic association graph of "trade-financing-warehousing." It connects trade data (contracts, logistics information), financing data (financing contracts, pledge information), and warehousing data (inventory records, inbound / outbound documents) through business relationships (such as contract numbers, pledge item numbers) to form a data network. The unit dynamically adjusts the weights of these associations based on historical verification results, marking associations with weights below a preset value as "key verification." The anomaly calculation unit employs an anomaly quantification algorithm that integrates industry characteristics, considering data consistency, data timeliness, and other factors. The comprehensive anomaly score is calculated based on three dimensions: timeliness, data correlation, and data consistency. Data consistency measures the degree of field matching between real-time trade data and offline trade data (such as contract amount and delivery date). Data timeliness measures the degree of deviation between the data collection time and the time of key trade nodes (such as delivery deadline). Data correlation measures the degree of logical matching between trade data and financing data and warehousing data (such as the ratio of financing amount to contract amount and the matching degree between inventory quantity and pledged quantity). The weights and anomaly thresholds of each dimension are assigned according to industry characteristics (such as the energy industry focusing on calorific value data and the financial industry focusing on financing data). If the comprehensive anomaly score reaches the threshold, it is judged as suspected fraudulent trade.
[0072] The working principle of the above technical solution is as follows: the module synchronizes offline trade data from the dynamic blockchain storage module and real-time trade data from the data acquisition module. The dynamic correlation graph constructed by the feature correlation unit establishes the correlation between the two types of data. Then, the anomaly calculation unit calculates the data consistency, timeliness, and correlation parameters in sequence, substitutes them into the algorithm formula to obtain the comprehensive anomaly degree, compares them with the industry threshold to determine the anomaly and marks the anomaly type (such as "heat value data mismatch" or "financing amount exceeding the limit"). Finally, the results are pushed to the self-learning contract module and the real-time early warning and handling module.
[0073] The effects of the above technical solution are as follows: By constructing a dynamic correlation graph of "trade-financing-warehousing," it is possible to connect scattered multi-dimensional data into an organic whole, avoiding the one-sidedness caused by verifying only single trade data (such as only looking at contracts), and realizing the correlation monitoring of trade data across the entire chain; by adopting an anomaly measurement algorithm that integrates industry characteristics, it is possible to transform traditional subjective human judgment (such as "judging data anomalies based on experience") into objective and calculable values, reducing verification errors caused by human factors and improving the consistency of anomaly identification; by allocating weights and thresholds according to industry characteristics (such as increasing the weight of calorific value data in the energy industry and increasing the weight of financing-related data in the financial industry), it is possible to adapt to the trade characteristics of different industries and improve the accuracy of anomaly identification; marking anomaly types can provide clear guidance for subsequent compliance verification and risk disposal, reduce invalid verification steps, and improve the efficiency of identifying fraudulent trade.
[0074] The self-learning contract module includes a rule base unit, a training unit, and an execution unit. The rule base unit stores three categories of compliance rules: trade process rules (such as "delivery time deviation ≤ industry allowable range"), industry-finance linkage rules (such as "financing amount ≤ preset ratio of trade contract amount"), and industry-specific rules (such as "coal calorific value deviation ≤ ±50 kcal / kg in the energy industry"). Rules are managed by industry category, and additions / modifications require confirmation from regulatory agencies. The training unit generates rule adjustment coefficients based on historical verification data from the past 12 months (including normal and fraudulent trade cases) through algorithm training. The coefficients are dynamically optimized based on industry business changes (such as seasonal factors causing changes in delivery cycles) and risk case feedback. The execution unit calls the corresponding industry's compliance rules and adjustment coefficients, calculates the actual allowable threshold, compares the deviation between real-time trade data and offline trade data to determine the compliance status, and outputs a confidence level in the range of 0-1 (the higher the confidence level, the more reliable the judgment result).
[0075] The working principle of the above technical solution is as follows: the module receives the abnormal identification results (including enterprise industry type and abnormal type) pushed by the intelligent cross-verification module, calls the compliance rules of the corresponding industry and abnormal type from the rule base unit, reads the adjustment coefficient generated by the training unit to calculate the actual allowable threshold, compares the data deviation to determine the compliance status and calculates the confidence level, and finally synchronizes the "compliance status-confidence level-rule basis" to the real-time early warning and handling module.
[0076] The above technical solution achieves the following effects: by storing three types of compliance rules—trade processes, industry-finance linkages, and industry-specific rules—it comprehensively covers trade compliance scenarios, avoiding compliance loopholes caused by relying on a single rule (such as only considering trade processes); training rule adjustment coefficients based on historical verification data enables rules to dynamically adapt to business changes (such as relaxing delivery time deviations in the energy industry during the winter heating season), avoiding the problem of traditional fixed rules lagging behind actual business; outputting compliance judgment confidence levels provides quantitative basis for early warning level determination, reducing the risk of misjudgment caused by "absolute judgments" (such as judging non-compliance only due to slight deviations); rule additions / modifications require confirmation from regulatory agencies, ensuring the authority and impartiality of the rules and preventing compliance failures caused by companies adjusting rules themselves.
[0077] The real-time early warning and handling module includes an early warning level determination unit and an early warning push unit. The early warning level determination unit combines the comprehensive anomaly degree of the intelligent cross-verification module and the compliance confidence degree of the self-learning contract module to divide the early warning into three levels: Level 1 early warning (high risk) corresponds to "comprehensive anomaly degree ≥ industry high threshold and confidence degree ≥ 0.8" (e.g., comprehensive anomaly degree 0.9, confidence degree 0.95); Level 2 early warning (medium risk) corresponds to "industry medium threshold ≤ comprehensive anomaly degree < industry high threshold or 0.5 ≤ confidence degree < 0.8" (e.g., comprehensive anomaly degree 0.7, confidence degree 0.6); and Level 3 early warning (low risk) corresponds to "industry low threshold ≤ comprehensive anomaly degree < industry medium threshold or 0.2 ≤ confidence degree < 0.5" (e.g., comprehensive anomaly degree 0.5, confidence degree 0.8). 3) Thresholds at each level are set according to industry characteristics; the early warning push unit adopts differentiated push methods for different levels. Level 1 early warnings are pushed to the person in charge of the trading entity, the risk control director of the financial institution, and the specialist of the regulatory agency through SMS, system pop-up, and email, and at the same time trigger the high-risk business freeze interface (such as the freezing of financing and loan disbursements); Level 2 early warnings are pushed to the trading business department and the account manager of the financial institution through system pop-up and email, and trigger the related business suspension interface (such as the suspension of warehousing and acceptance); Level 3 early warnings are only displayed in the system backend and the data operation and maintenance team is notified for verification; after the relevant entities complete the risk disposal, they need to upload the disposal results (including disposal description and supporting materials). After the system verifies the completeness, it will associate the disposal record with the early warning record and write it into the dynamic blockchain storage module.
[0078] The working principle of the above technical solution is as follows: after receiving the comprehensive anomaly degree and compliance confidence degree, the module determines the warning level according to the combination logic of multiple conditions, and executes the corresponding push and business linkage operation; it tracks the handling process, and records it on the chain for storage after the handling is completed, forming a complete closed loop of "monitoring-early warning-handling-traceability".
[0079] The effects of the above technical solution are as follows: By combining comprehensive anomaly and compliance confidence levels to classify early warning levels, accurate risk classification can be achieved, avoiding resource waste or risk omissions caused by "one-size-fits-all" early warnings (such as treating low-risk data and high-risk data the same); Differentiated push notifications and business linkages for different early warning levels can ensure timely interception of high-risk businesses (such as fraudulent financing), efficient verification of medium-risk businesses (such as minor data deviations), and flexible handling of low-risk businesses (such as data update delays), improving the pertinence and timeliness of risk prevention and control; Writing the handling records to blockchain storage can provide a reliable basis for subsequent risk tracing and liability determination, avoiding the lack of evidence in the handling process; Through closed-loop management, subsequent verification rules and early warning strategies can be optimized based on the handling results, continuously improving the system's risk prevention and control capabilities and providing long-term protection for trade security.
[0080] One embodiment of the present invention, such as Figure 2As shown, a method for monitoring fraudulent trade based on cross-verification of data includes the following steps:
[0081] S1. Collect real-time multi-source trade data, which includes unique enterprise codes and dynamic feature identifiers, covering structured business data, unstructured public data and semi-structured related data.
[0082] S2. Offline trade data is stored through a dynamic blockchain storage module. The offline trade data is updated dynamically and periodically. Hash encryption, timestamps and node signatures are used to ensure that the data is tamper-proof. Data is synchronized with energy and financial vertical industry chains through a cross-chain gateway.
[0083] S3. Using the enterprise's unique code as the core, construct a dynamic correlation graph of trade data, financing data, and warehousing data, and clean and extract features from offline trade data.
[0084] S4. Cross-compare the offline trade data in the dynamic correlation graph with the real-time multi-source trade data, and calculate the comprehensive anomaly degree using an anomaly quantification algorithm that integrates industry characteristics. D ;
[0085] S5. Based on the initial compliance rule base and dynamic rule update model of the self-learning contract module, it automatically verifies the compliance of real-time data and offline data and outputs compliance verification results with confidence.
[0086] S6. Combining the aforementioned comprehensive anomaly degree D The system generates an early warning level based on the compliance verification results, triggers the corresponding business freeze interface, and writes the early warning and handling records into the dynamic blockchain storage module.
[0087] By leveraging multi-source data collection and cross-chain synchronization, the limitations of fragmented and industry-isolated traditional trade monitoring data are broken, enabling trusted data sharing across entities and industries, and significantly improving data coverage dimensions. Quantitative algorithms incorporating industry characteristics transform manual experience-based judgment into data-driven calculations. Multi-dimensional verification avoids single-dimensional omissions, and industry-differentiated parameters reduce one-size-fits-all misjudgments, significantly improving the objectivity and accuracy of anomaly identification and optimizing the consistency of verification results. The dynamic adjustment coefficients of self-learning contracts address the problem of traditional fixed rules lagging behind business changes, improving rule adaptability and reducing the risk of misjudging non-compliance due to slight deviations in confidence output, thus enhancing the flexibility of compliance verification. Tiered early warning and business linkage upgrade risk prevention from post-event remediation to pre-event interception, with high-risk businesses immediately frozen and medium-risk businesses handled within a limited time, reducing the risk spread rate to an extremely low level. On-chain handling records ensure traceability, improving regulatory verification efficiency. The end-to-end data loop provides continuous feedback data for anomaly algorithms and compliance rules, continuously improving the system's ability to identify fraudulent trade as business progresses, forming a virtuous cycle of monitoring-optimization-re-monitoring, ensuring long-term trade security.
[0088] Wherein, S1 includes:
[0089] S11. Collect structured business data from the enterprise ERP system through an adaptive interface and add dynamic feature identifiers. Specifically, identify the interface protocol type of the enterprise ERP system and match the corresponding adapter to access the data. The collected structured business data includes purchase contracts, inbound orders, outbound orders, etc. After collection, generate dynamic feature identifiers according to "enterprise unique code + data generation timestamp + data type code" and embed them into the data metadata fields. Perform field validation on the collected data to check whether the required fields such as "contract number", "transaction amount" and "delivery date" are complete and whether the data type meets the requirements (e.g., "transaction amount" is numeric). If the validation passes, temporarily store the data; if it fails, return a prompt to re-upload the data.
[0090] S12. Extract unstructured data information from regulatory agency publications using OCR recognition and semantic parsing technology. Specifically, convert PDF and image-format publications (such as equipment registration announcements and administrative penalty notices) issued by regulatory agencies into grayscale images. After preprocessing with binarization, noise reduction, and tilt correction, extract text information using an OCR engine. Input the extracted text information into a semantic parsing model to parse out key information such as "enterprise code," "registration number," "public notice date," and "reason for penalty." Set a confidence threshold (e.g., 0.95) for the parsing results. Information with a confidence level ≥ the threshold is automatically associated with the enterprise's unique code, while information with a confidence level < the threshold is marked as "awaiting manual review."
[0091] S13. Aggregate third-party semi-structured related data through the API gateway, convert the format, extract features, and then synchronize it to the monitoring system. Specifically, the API gateway calls the open interfaces of third-party authoritative institutions (such as testing institutions and warehousing institutions) at set intervals to obtain semi-structured data (such as test reports and inventory records) in XML and CSV formats. The data of different formats is unified into JSON format through a data conversion tool, and core feature fields such as "test number", "test item", "test result", "inventory location" and "inventory quantity" are extracted. Value range validation is performed on the extracted feature fields (such as "inventory quantity" ≥ 0 and "test result" conforming to the industry standard range). After the validation is passed, the data is synchronized to the system buffer.
[0092] The working principle of the above technical solution is as follows: First, considering the structural differences of the three types of data sources—enterprises, regulators, and third parties—differentiated collection logic is designed: structured data is adapted to enterprise systems through adaptive interfaces, unstructured data is extracted and key information is identified through OCR + semantic parsing, and semi-structured data is standardized through API gateway aggregation and format conversion; Second, dynamic feature identifiers are added to all collected data to ensure that the data can be traced back to specific enterprises and business scenarios; Finally, qualified data is filtered through multiple rounds of verification (field verification, confidence verification, value range verification) and aggregated into the system buffer to provide high-quality data input for subsequent storage.
[0093] The above technical solution achieves the following effects: by collecting multi-source data from enterprise ERP structured data, regulatory unstructured public data, and third-party semi-structured related data, it can cover the entire trade chain information and avoid the information bias caused by relying solely on enterprise-owned data; the application of adaptive interfaces and API gateways solves the problem of incompatibility between data formats of different enterprise systems and different third-party institutions, improving the compatibility of data access; the addition of dynamic feature identifiers ensures data traceability and reduces verification errors caused by data confusion or tampering; the multi-round verification mechanism can effectively eliminate missing and erroneous data, improve data accuracy, and lay a reliable data foundation for subsequent cross-verification.
[0094] In this embodiment, S2 includes:
[0095] S21. Endorsing nodes verify the signatures of offline trade data, generating hash values and timestamps upon successful verification. Specifically, the data collected and verified by S1 is aggregated into offline trade data according to a set period (the initial period can be set to 1 hour). The offline trade data is sent to multiple endorsing nodes (at least one each from trade participants, regulatory agencies, and financial institutions). Each endorsing node verifies the data integrity and the validity of the enterprise's unique code, and then generates a node signature using an asymmetric encryption algorithm. After collecting valid signatures from at least 3 endorsing nodes, a SHA-256 hash calculation is performed on the offline trade data to generate a hash value, and a UTC timestamp (accurate to milliseconds) is added.
[0096] S22. Ledger nodes store data in corresponding partitions according to data sensitivity levels. The cross-chain gateway synchronizes and verifies the data with the energy and financial vertical industry chains through atomic exchange protocols. Specifically, the ledger node receives a data packet containing "offline trade data + hash value + timestamp + endorsement signature" and divides it into core partitions (storing corporate financial data and financing contract data), general partitions (storing logistics data and testing report data), and public partitions (storing regulatory disclosure data and industry benchmark data) according to data sensitivity levels. The core partition data is stored using AES-256 encryption, the general partition data is encrypted only for sensitive fields (such as "contact information"), and the public partition data is stored in plaintext. The cross-chain gateway sends data synchronization requests to the energy and financial industry vertical chains through atomic exchange protocols. After receiving the data returned by the industry chains, it verifies the consistency between the data hash value and the industry chain block hash. If the consistency is successful, it adds a "cross-chain identifier" and writes it to the public partition.
[0097] S23. Dynamically adjust the storage period based on the data update frequency, and shorten the update interval for high-frequency data. Specifically, calculate the update frequency of offline trade data for the past 7 days (e.g., number of daily updates, amount of data per update). If the update frequency is greater than 1 time / hour, adjust the storage period to 1 hour; if 0.5 ≤ update frequency ≤ 1 time / hour, adjust to 2 hours; if the update frequency is less than 0.5 times / hour, adjust to 4 hours. Ensure the timeliness of high-frequency data (e.g., real-time inventory data) while avoiding resource waste caused by frequent updates of low-frequency data.
[0098] The working principle of the above technical solution is as follows: First, by using multi-endorsement node signatures and hash encryption, an immutable foundation for offline trade data is built—signatures ensure that the data is recognized by multiple entities, and hash values and timestamps ensure that the data cannot be tampered with after it is generated; second, data is stored in partitions according to sensitivity levels, which protects enterprise privacy and sensitive information while realizing data sharing; finally, by dynamically adjusting the data timeliness and storage efficiency, cross-chain synchronization breaks down industry data silos and realizes the correlation and verification of trade data and industry-specific data.
[0099] The effects of the above technical solutions are as follows: multi-endorsement node signature and hash encryption mechanism completely solve the problem of data tampering in centralized storage and improve data credibility; partitioned storage and differentiated encryption balance the needs of data sharing and privacy protection, and avoid the leakage of sensitive data; cross-chain synchronization enables data interoperability between the energy and financial industries (such as coal calorific value benchmarks in the energy industry and financing filing data in the financial industry), expanding the dimensions of data verification; dynamic storage cycle adjustment ensures the timeliness of high-frequency data while reducing storage costs and optimizing system resource allocation.
[0100] In this embodiment, S3 includes:
[0101] S31. Using the enterprise's unique code as the root node, construct a dynamic association graph of trade data, financing data, and warehousing data. Specifically: create a root node with the enterprise's unique code in the graph database; use the offline trade data (contracts, logistics data) stored in S2 as the first-level child node, and associate it with the root node through the "contract number"; use the financing data (financing contracts, loan records) as the second-level child node, and associate it with the first-level trade data node through the "trade contract number"; use the warehousing data (inventory records, inbound and outbound documents) as the third-level child node, and associate it with the second-level financing data node through the "pledged item number"; dynamically adjust the association weights between nodes based on historical verification results. The association weight for nodes with no abnormalities in the last three verifications is increased by 0.1, the association weight for nodes with abnormalities is decreased by 0.2, and the association weight < 0.3 is marked as "key verification".
[0102] S32. Clean and process offline trade data; specifically: delete duplicate data based on dynamic feature identifiers (retain the latest record of data with the same identifier); correct erroneous data based on reasonable industry ranges (e.g., coal calorific value data exceeding 4500-6000 kcal / kg in the energy industry is marked as "pending verification"); handle missing data by filling in the mean or notifying the collection unit to re-transmit (e.g., if the "test report number" is missing, notify the third-party collection unit to re-transmit).
[0103] S33. Extract features from the cleaned offline trade data; specifically: extract core feature fields by industry type—for the energy industry, extract "contract amount", "delivery period", "coal calorific value", "equipment registration number" (trade data), "financing amount", "loan disbursement time" (financing data), "inventory quantity", and "pledged goods location" (warehousing data); for the financial industry, extract "trading counterparty", "financing interest rate" (financing data), and "pledged goods value" (warehousing data); the extracted feature fields are associated with the corresponding node IDs in the graph database and stored in the feature library for subsequent verification and retrieval.
[0104] The working principle of the above technical solution is as follows: First, the scattered trade, financing and warehousing data are linked into an organic whole through dynamic correlation graphs, breaking the data isolation and providing a data correlation basis for multi-dimensional cross-verification; Second, data cleaning removes noisy data (duplication, errors and missing data) to ensure data quality; Finally, feature extraction focuses on key information, reduces the interference of redundant data on subsequent anomaly calculations, and improves verification efficiency.
[0105] The effects of the above technical solutions are as follows: Dynamic correlation graphs avoid the one-sidedness of verification based on a single data dimension, enabling correlation monitoring of trade data across the entire chain. For example, by linking "trade contracts - financing contracts - collateral inventory," fraudulent trades that "apply for financing without actual inventory" can be identified. Data cleaning significantly improves data accuracy and reduces verification misjudgments caused by data errors. Feature extraction focuses on core information, reducing the complexity of subsequent anomaly calculations, improving system computational efficiency, and providing adaptability for industry-specific verification (e.g., focusing on calorific value data in the energy industry and financing data in the financial industry).
[0106] In this embodiment, S4 includes:
[0107] S41, Computational Data Consistency C : C =Base field matching rate × ω 1 + Industry-specific field matching rate × ω 2, of which ω 1. ω 2 are industry-specific coefficients; specifically: basic fields include "contract number", "transaction amount", and "delivery date", with a matching rate = number of actually matched fields / 3 (e.g., if 2 fields match, the matching rate = 0.667). The field matching criteria are "transaction amount deviation ≤ ±1%, delivery date deviation ≤ ±2 hours, and contract number completely consistent"; industry-specific fields are determined by industry type—for the energy industry, they are "coal calorific value" and "equipment registration number", with a matching rate = number of actually matched fields / 2 (e.g., if 1 field matches, the matching rate = 0.5). The matching criteria are "calorific value deviation ≤ ±50 kcal / kg, and registration number exists and is within its validity period"; ω 1. ω 2 represents the industry characteristic coefficient, set for the energy industry. ω 1 = 0.4 ω 2 = 0.6, financial industry setting ω 1 = 0.5 ω 2 = 0.5;
[0108] S42. Calculate the timeliness of data T : T = Duration exceeding industry allowable deviation / Duration of industry maximum reasonable deviation T ≤1; Specifically: Determine the key trade milestones (such as "delivery deadline" and "test report validity expiration date"); calculate the deviation between the real-time data collection time and the key milestone time. If the deviation is ≤ the industry-allowed deviation (allowed deviation for delivery period in the energy industry = 12 hours, allowed deviation for financing filing in the financial industry = 24 hours), then T =0; if the deviation > the allowable deviation T= (deviation - allowable deviation) / industry's maximum reasonable deviation duration (energy industry = 72 hours, financial industry = 48 hours), and T The maximum value is set to 1;
[0109] S43, Calculate data correlation R : R =Trade-finance data matching rate × λ 1+ Trade-Warehouse Data Matching Rate × λ 2, of which λ 1. λ 2 represents the dynamic correlation coefficient; specifically: the trade-financing data matching fields include "trade contract number" and "financing amount", and the matching rate = the number of actual matching fields / 2 (e.g., if "financing amount ≤ 80% of trade contract amount", then "financing amount" is considered a match); the trade-warehousing data matching fields include "pledged item number" and "inventory quantity", and the matching rate = the number of actual matching fields / 2 (e.g., if "inventory quantity ≥ quantity corresponding to the value of pledged item", then "inventory quantity" is considered a match). λ 1. λ 2 is set to 0.5 (uniform across industries). R =Trade-finance matching rate × 0.5 + Trade-warehousing matching rate × 0.5;
[0110] S44. Dynamic allocation based on industry type α , β , γ Weights, substitute into the formula for calculation D Specifically, the energy sector requires a focus on verifying the authenticity of data, and therefore... α =0.4、 β =0.3、 γ =0.3; The financial industry needs to focus on controlling financing risks, so it is set... α =0.3、 β =0.3、 γ =0.4; Calculated from S41 to S43 C , T , R Substitute into the formula D = α ×(1- C )+ β × T + γ ×(1- R ),like D If the value is greater than or equal to the industry's preset threshold (0.6 for the energy industry and 0.65 for the financial industry), it is judged as suspected fraudulent trade and marked as an anomaly (such as "mismatch in calorific value data" or "excessive financing amount").
[0111] The working principle of the above technical solution is as follows: First, it constructs an anomaly quantification system covering the entire trade chain risk points from three dimensions: data consistency (field matching degree), timeliness (time deviation), and correlation (multi-dimensional data logic matching); second, it uses industry differentiation coefficients ( ω 1. ω 2. α , β , γ The algorithm incorporates multiple parameters and thresholds to adapt to the trade characteristics of different industries. Finally, it substitutes these parameters into the algorithm formula, transforming "data anomalies" from subjective human judgment into an objective and calculable comprehensive anomaly degree. D This enables the standardization of anomaly detection.
[0112] The effects of the above technical solution are as follows: multi-dimensional anomaly quantification avoids missed detections in single-dimensional verification (such as only looking at contract field matching and ignoring logical conflicts between financing and warehousing data), improving the comprehensiveness of fraudulent trade identification; industry-differentiated parameters ensure the algorithm's adaptability to different scenarios such as energy and finance, reducing misjudgments caused by a one-size-fits-all approach; and comprehensive anomaly degree... D The calculation standardizes anomaly identification, reduces human interference, and improves the consistency of verification results; the anomaly type marking provides clear guidance for subsequent compliance verification and risk handling, reducing the cost of invalid verification.
[0113] In this embodiment, S5 includes:
[0114] S51. Call the initial compliance rule library of the self-learning contract module to determine the compliance rules to be verified; specifically: based on the anomaly type marked in S4 (such as "calorific value deviation anomaly") and the enterprise industry type, call the corresponding rules from the initial compliance rule library - "calorific value deviation rule" for the energy industry (such as "the deviation between the actual delivered calorific value and the contractually agreed calorific value ≤ ±50 kcal / kg"), and "financing amount rule" for the financial industry (such as "financing amount ≤ 80% of the trade contract amount"); each rule in the rule library contains fields such as "rule ID", "industry type", "rule description", "basic threshold", and "applicable scenario";
[0115] S52. Call the rule adjustment coefficient generated by the dynamic rule update model; specifically: the dynamic rule update model extracts historical verification data (including normal and fraudulent trade cases) from the blockchain for the past 12 months, and generates industry-specific rule adjustment coefficients (range 0.8-1.2) through gradient descent algorithm training; if the misjudgment rate of a certain rule in historical cases is high (e.g., the misjudgment rate of the "delivery date rule" in the winter energy industry is >10%), the adjustment coefficient is set to 1.1 (relaxed threshold), and if the misjudgment rate is low, it is set to 0.9 (tightened threshold); call the corresponding adjustment coefficient according to the current industry type and rule ID;
[0116] S53. Calculate the actual allowable threshold to verify data compliance; specifically: actual allowable threshold = rule base threshold × adjustment coefficient (e.g., in the energy industry, the base threshold for the "calorific value deviation rule" is 50 kcal / kg, and the adjustment coefficient is 0.9, so the actual allowable threshold is 45 kcal / kg); extract the corresponding fields of real-time trade data and offline trade data (e.g., "real-time calorific value" and "contract calorific value"), and calculate the actual deviation = |real-time field value - offline field value|; if the actual deviation ≤ the actual allowable threshold, it is judged as "compliant", otherwise it is "non-compliant";
[0117] S54. Output the compliance verification result with a confidence level in the range of 0-1. Specifically, input the actual deviation, adjustment coefficient, and historical matching rate of the rule in the past 3 months into the dynamic rule update model. The model outputs the confidence level of the compliance judgment (e.g., if the actual deviation = 40 kcal / kg, adjustment coefficient = 0.9, and historical matching rate = 92%, then the confidence level = 0.93). The higher the confidence level, the more reliable the judgment result. Finally, the result of "compliance status (compliant / non-compliant) + confidence level + rule basis" is output.
[0118] The working principle of the above technical solution is as follows: First, it provides a standardized basis for compliance judgment through an initial compliance rule base; second, the dynamic rule adjustment coefficient solves the problem that traditional fixed rules lag behind business changes (such as trade rule adjustments caused by seasons and policies); finally, it calculates confidence levels by combining historical data to provide a quantitative reliability reference for compliance judgment results and avoids absolute judgments.
[0119] The effects of the above technical solution are as follows: the initial compliance rule base ensures the standardization of compliance verification and avoids the chaos caused by enterprises making their own rules; the dynamic adjustment of coefficients makes the rules adapt to actual business changes, improving the flexibility and accuracy of compliance verification; the confidence output provides a quantitative basis for subsequent warning level determination, reducing the risk of misjudgment of "minor deviations but non-compliance", and at the same time provides feedback data for rule optimization (such as rules with persistently low confidence need to be retrained and the coefficients adjusted).
[0120] In this embodiment, S6 includes:
[0121] S61, if D If the industry high threshold is ≥ and the compliance verification confidence level is ≥ 0.8, a Level 1 warning is generated and the core business interface is frozen; specifically: the industry high threshold is set by type (energy industry = 0.8, financial industry = 0.85), if D ≥High threshold and confidence level ≥0.8 (e.g.) DIf the risk level is 0.82 and the confidence level is 0.85, a Level 1 warning (high risk) is generated. The warning information is simultaneously pushed to the person in charge of the trading entity, the risk control director of the financial institution, and the specialist of the regulatory agency via SMS, system pop-up, and email. At the same time, the "financing and loan freezing interface" of the financial institution's core system is called, and the financing contract number and warning ID are passed in to suspend the loan disbursement operation.
[0122] S62, If the industry threshold is ≤ D <For industries with high thresholds or compliance verification confidence levels of 0.5-0.8, generate a level-two alert and trigger the freezing of related business interfaces; specifically: the industry threshold is set to 0.6 for the energy industry and 0.65 for the financial industry. If 0.6 ≤ D <0.8 (energy sector) or 0.5 ≤ confidence level <0.8 (e.g.) D If the risk level is 0.7 and the confidence level is 0.6, a Level 2 warning (medium risk) is generated. The warning information is pushed to the trade business department and financial institution account managers through system pop-ups and emails. The "Inbound Acceptance Suspension Interface" of the trade enterprise's ERP system is called, and the inbound order number is passed in to suspend the inbound process. If the situation is not resolved within 12 hours, the warning will automatically be upgraded to Level 1.
[0123] S63, If the industry's low threshold is ≤ D <If the industry threshold or compliance verification confidence level is 0.2-0.5, a level 3 alert will be generated and pushed to the management end; specifically: the low industry threshold is set as 0.4 for the energy industry and 0.45 for the financial industry. If 0.4 ≤ D <0.6 (energy sector) or 0.2 ≤ confidence level <0.5 (e.g.) D If the confidence level is 0.5 and the risk level is 0.3, a Level 3 alert (low risk) will be generated. The alert information will only be stored in the system backend and pushed to the data operation and maintenance team via internal message. The operation and maintenance team must complete the data verification within 24 hours and provide feedback on the verification results.
[0124] S64. Finally, the warning information, handling records, and verification evidence are written to the dynamic blockchain storage module through node signatures; specifically: after the relevant entities complete the risk handling (such as trading companies submitting supplementary testing reports, financial institutions conducting on-site inventory verification), they upload the handling instructions and scanned copies of supporting materials; after the system verifies the completeness of the materials (such as signatures and seals, and compliant format), the "warning information ( D The data is linked together with the following: "Value, confidence level, and grade" + "Disposal record (disposer, time, and conclusion) + verification basis (scanned document hash value)". After being signed by at least two endorsing nodes, it is written into the dynamic blockchain storage module. The blockchain record supports querying by "early warning ID" and "enterprise unique code" to form a risk traceability ledger.
[0125] The working principle of the above technical solution is as follows: First, by combining the conditions of "comprehensive anomaly degree D + compliance confidence degree", the early warning level is accurately classified to avoid over-warning or under-warning; Second, differentiated push and business linkage strategies are designed for different early warning levels, high-risk businesses are intercepted in real time, and medium and low-risk businesses are verified efficiently; Finally, the handling records are stored on the blockchain to build a complete closed loop of "monitoring-early warning-handling-traceability" to ensure that risks are traceable and the system is optimizable.
[0126] The effects of the above technical solution are as follows: tiered early warning enables precise risk control, preventing the spread of high-risk businesses (such as fraudulent financing) while reducing the interference of medium- and low-risk businesses on normal trade; the call to business linkage interfaces upgrades the early warning from "only prompting" to "active interception," significantly improving the timeliness of risk control; the on-chain recording of disposal records ensures that the data is tamper-proof, providing a reliable basis for subsequent regulatory traceability and liability determination; closed-loop management provides data support for the optimization of intelligent cross-verification algorithms and self-learning contract rules through the feedback of disposal results, continuously improving the system's ability to identify fraudulent trade.
[0127] Therefore, the aforementioned method and system for monitoring fraudulent trade based on cross-verification of data solves the problems of data silos and information asymmetry in traditional trade, significantly improves the ability to prevent fraudulent trade, and lays a technical foundation for trade security.
[0128] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.
Claims
1. A fraudulent trade monitoring system based on cross-verification of data, characterized in that, It includes a data acquisition module, a dynamic blockchain storage module, an intelligent cross-verification module, a self-learning contract module, and a real-time early warning and handling module. Each module achieves collaborative communication through an encrypted data structure. The data acquisition module is used to collect real-time multi-source trade data, which includes unique enterprise codes and dynamic feature identifiers, covering structured business data provided by enterprises, unstructured public data released by regulatory agencies, and semi-structured related data from third-party authoritative institutions. The dynamic blockchain storage module adopts a consortium blockchain architecture to deploy endorsement nodes, ledger nodes, and cross-chain gateways. It is used to store offline trade data that is updated dynamically. The data is guaranteed to be tamper-proof through hash encryption, timestamps, and node signatures. Data synchronization with industry vertical chains is achieved through cross-chain gateways. The intelligent cross-verification module is used to retrieve offline trade data from the dynamic blockchain storage module, compare it with real-time multi-source trade data in terms of dimensions, calculate the comprehensive anomaly degree through an anomaly quantification algorithm that integrates industry characteristics, and identify data inconsistencies and logical conflicts. The intelligent cross-verification module includes: Feature-based association units, with the enterprise's unique code as the core, establish a dynamic association graph between trade data, financing data, and warehousing data; The anomaly calculation unit, wherein the anomaly quantification algorithm formula integrating industry characteristics is: ; in, , , All are weighting coefficients that are dynamically adjusted based on industry characteristics and ; C For data consistency, C =Base field matching rate × ω 1 + Industry-specific field matching rate × ω 2, of which ω 1. ω Both 2 are industry characteristic coefficients; T For data timeliness, T = Duration exceeding industry allowable deviation / Duration of industry maximum reasonable deviation T ≤1; R For data correlation, R =Trade finance data matching rate × λ 1+ Trade and warehousing data matching rate × λ 2, of which λ 1. λ 2 is the dynamic correlation coefficient; if D When the threshold is reached, it is judged as suspected fraudulent trade; The self-learning contract module has a built-in initial compliance rule library. It generates a dynamic rule update model by training through historical verification results, automatically verifies the compliance of real-time data and offline data, and outputs compliance verification results with confidence. The real-time early warning and handling module is used to generate an early warning level by combining the comprehensive anomaly degree and compliance verification results, trigger the corresponding level of business freeze interface, and write the early warning and handling records into the dynamic blockchain storage module to form a closed loop.
2. The fraudulent trade monitoring system based on cross-verification of data according to claim 1, characterized in that, The data acquisition module includes: The enterprise-side data acquisition unit is configured with an adaptive interface to adapt to different enterprise ERP systems, and collects structured business data with dynamic feature representation in real time. The regulatory data collection unit extracts information from unstructured public data through OCR recognition and semantic parsing technology; The third-party data collection unit uses an API gateway to aggregate semi-structured related data, performs format conversion and feature extraction, and then synchronizes it to the monitoring system.
3. A fraudulent trade monitoring system based on cross-verification of data as described in claim 1, characterized in that, The consortium blockchain architecture of the dynamic blockchain storage module includes: The endorsement nodes are deployed by the trade participants and regulatory agencies respectively, and adopt a role-based access control mechanism; The accounting node adopts a distributed storage cluster, and the storage partitions are divided according to the data sensitivity level. The cross-chain gateway enables data interaction and verification with vertical industry chains in energy and finance through atomic swap protocols.
4. A fraudulent trade monitoring system based on cross-verification of data as described in claim 1, characterized in that, The self-learning contract module includes: The rule base unit is used to store trade process rules, industry-finance linkage rules, and industry rules. The training unit uses the gradient descent algorithm to train on historical verification data to generate rule adjustment coefficients; The execution unit verifies the compliance of the data based on the initial rules and adjustment coefficients, and outputs the verification results containing a confidence level in the range of 0-1.
5. A method for monitoring fraudulent trade based on cross-verification of data, characterized in that, Includes the following steps: S1. Collect real-time multi-source trade data, which includes unique enterprise codes and dynamic feature identifiers, covering structured business data, unstructured public data and semi-structured related data. S2. Offline trade data is stored through a dynamic blockchain storage module. The offline trade data is updated dynamically and periodically. Hash encryption, timestamps and node signatures are used to ensure that the data is tamper-proof. Data is synchronized with energy and financial vertical industry chains through a cross-chain gateway. S3. Using the enterprise's unique code as the core, construct a dynamic correlation graph of trade data, financing data, and warehousing data, and clean and extract features from offline trade data. S4. Cross-compare the offline trade data in the dynamic correlation graph with the real-time multi-source trade data, and calculate the comprehensive anomaly degree using an anomaly quantification algorithm that integrates industry characteristics. D ; In S4, the anomaly metric algorithm that integrates industry characteristics includes: S41, Computational Data Consistency C : C =Base field matching rate × ω 1 + Industry-specific field matching rate × ω 2, of which ω 1. ω Both 2 are industry characteristic coefficients; S42. Calculate the timeliness of data T : T = Duration exceeding industry allowable deviation / Duration of industry maximum reasonable deviation T ≤1; S43, Calculate data correlation R : R =Trade finance data matching rate × λ 1+ Trade and warehousing data matching rate × λ 2, of which λ 1. λ 2 represents the dynamic correlation coefficient; S44. Dynamic allocation based on industry type α , β , γ Weights, substitute into the formula for calculation ; S5. Based on the initial compliance rule base and dynamic rule update model of the self-learning contract module, it automatically verifies the compliance of real-time data and offline data and outputs compliance verification results with confidence. S6. Combining the aforementioned comprehensive anomaly degree D The system generates an early warning level based on the compliance verification results, triggers the corresponding business freeze interface, and writes the early warning and handling records into the dynamic blockchain storage module.
6. The method for monitoring fraudulent trade based on cross-verification of data according to claim 5, characterized in that, In S1, the collection of real-time multi-source trade data includes: S11. Collect structured business data from the enterprise ERP system through an adaptive interface and add dynamic feature identifiers; S12. Extract unstructured data information from regulatory agency publications using OCR recognition and semantic parsing technology; S13. Aggregate third-party semi-structured related data through the API gateway, convert the format, extract features, and then synchronize it to the monitoring system.
7. A method for monitoring fraudulent trade based on cross-verification of data as described in claim 5, characterized in that, Specifically, S2 includes: S21. The endorsement node performs signature verification on the offline trade data, and generates a hash value and timestamp after successful verification. S22. Ledger nodes are stored in corresponding partitions according to data sensitivity level, and cross-chain gateways are synchronously verified with energy and financial vertical industry chains through atomic swap protocols. S23. Dynamically adjust the storage cycle according to the data update frequency, and shorten the update interval for high-frequency changing data.
8. A method for monitoring fraudulent trade based on cross-verification of data as described in claim 5, characterized in that, In S6, the warning levels include: S61. If D ≥ industry high threshold and compliance verification confidence ≥ 0.8, generate a level 1 warning and trigger the core business freeze interface; S62, If the industry threshold is ≤ D <If the industry's high threshold or compliance verification confidence level is 0.5-0.8, a level 2 warning will be generated and the associated business interface will be frozen; S63, If the industry's low threshold is ≤ D <If the industry threshold or compliance verification confidence level is 0.2-0.5, a level 3 alert is generated and pushed to the management terminal; S64. Finally, the warning information, handling records and verification evidence are written into the dynamic blockchain storage module through node signature.