A multi-source data fusion and intelligent risk prediction method for dynamic determination of wage guarantee margin

Abstract

The present application relates to the technical field of smart contract, and discloses a kind of multi-source data fusion and intelligent risk prediction's wage guarantee fund dynamic approval method, comprising: business processing end is associated with the record of entry record, wage instruction record and contract confirmation record as three-node event group, generates event group summary and event group complete mark, and carries out format uniformity to multi-source data.Business processing end forms end-to-end processing chain time interval with the record time of entry record and the contract confirmation time, determines the directed position of wage instruction write time, obtains three-node time sequence folding point value, and determines normal folding point value and folding point deviation value in combination with historical three-node event group.Based on this, business processing end updates current risk value and generates approved amount, and approved amount, event group summary, event group complete mark, folding point deviation value and exception chain segment mark constitute contract call data package;Intelligent contract executes approved amount write, temporary write or retry state write accordingly.

Description

Technical Field

[0001] This invention relates to the field of smart contract technology, and more specifically, to a method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction. Background Technology

[0002] In engineering project wage guarantee deposit operations, the verification process is typically handled jointly by a labor real-name registration platform, access control or attendance terminals, a project wage data gateway, a bank receipt interface, a business database, and blockchain smart contract nodes. On-site personnel entry and exit records, wage instruction database entries, payment status receipts, project status records, and on-chain confirmation records originate from different systems, resulting in inconsistencies in field definitions, time sources, data versions, and interface response statuses. In actual deployment, the business processing end needs to complete data collection, cleaning, correlation, risk assessment, amount generation, and contract invocation, while maintaining traceability across failure, retrieval, and review states.

[0003] Existing wage security deposit verification systems typically aggregate data at the project level, including the proportion of missing data, the proportion of abnormal records, the matching ratio of wage instructions and attendance records, the proportion of abnormal payment status, project status values, and historical processing status. They then calculate the current risk value based on preset weights and generate the verification amount accordingly. While this process can support routine batch verification, when delays in on-site data uploads, wage gateway database entry, and on-chain confirmation coexist, the end-to-end time only reflects the overall slowdown and cannot distinguish whether the delay primarily occurs before the on-site data enters the wage gateway or after the wage gateway calls the smart contract.

[0004] The unclear location of the aforementioned links will affect subsequent processing strategies. If late on-site data is treated as an on-chain confirmation anomaly, the system may trigger unnecessary contract retries; if short-term on-chain congestion is treated as a business data anomaly, the system may include verifiable link statuses in the wage guarantee risk input. For engineering projects, the verification task also needs to retain the event source, project number, personnel number, data version, and contract call status to ensure that the verification amount writing, postponement writing, and retry status writing are verifiable and traceable. Summary of the Invention

[0005] This invention provides a method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction, thereby solving the technical problems mentioned in the background art.

[0006] This invention provides a method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction. It is applied to a data processing environment including access control or attendance terminals, project wage data gateways, blockchain smart contract nodes, and business processing terminals. The business processing terminals correspond to the processing actions of the data access server and the business server, including:

[0007] The business processing terminal associates the entry record, the wage instruction writing record, and the contract confirmation record into a three-node event group, and generates an event group summary and a complete event group tag based on the three-node event group;

[0008] The business processing terminal unifies the format of multi-source raw data to form a project-approved dataset.

[0009] When the three-node event group satisfies the chronological order, the business processing end forms an end-to-end processing chain time interval based on the entry record time and contract confirmation time, determines the directed position of the wage instruction writing time in the end-to-end processing chain time interval, obtains the three-node time sequence inflection point value, and determines the normal inflection point value and inflection point deviation value based on the historical valid three-node event group.

[0010] The business processing terminal updates the current risk value based on the inflection point deviation value, and generates the approved amount based on the current risk value;

[0011] The business processing terminal will compose a contract call data packet consisting of project number, data version number, approved amount, event group summary, event group complete marker, three-node time sequence inflection point value, inflection point deviation value and abnormal chain segment marker;

[0012] The smart contract verifies the event group summary, the complete event group marker, and the inflection point deviation value, and performs the approved amount write, postponed write, or retry status write based on the verification results and the abnormal chain segment marker.

[0013] The beneficial effects of this invention are as follows: By organizing the entry record time, wage instruction writing time, and contract confirmation time generated by the access control or attendance terminal, the project wage data gateway, and the blockchain smart contract node into a three-node event group, and transmitting the event group summary, event group complete marker, three-node time sequence inflection point value, inflection point deviation value, and abnormal chain segment marker along with the contract call data packet, the wage guarantee deposit assessment no longer relies solely on aggregated delays or discrete business states. The business processing end can distinguish the delay position before and after the field data enters the gateway, and use the inflection point deviation value for updating the current risk value and generating the assessment amount. The smart contract can execute the assessment amount writing, postponed writing, or retry status writing based on verifiable data packets, thereby reducing misjudgments, duplicate updates, and inappropriate writing caused by confusion of link delay sources, and facilitating integration into existing project wage management, labor real-name system, and on-chain receipt environments. Attached Figure Description

[0014] Figure 1 This is a diagram illustrating the architecture and processing mechanism of the dynamic assessment method for wage security deposits of the present invention. Detailed Implementation

[0015] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0016] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" indicate that the element or object preceding the term encompasses the elements or objects listed following the term and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0017] This specific implementation takes the dynamic verification scenario of wage security deposits for construction projects as an example. The method is applied to a data processing environment including an access control or attendance terminal 100, a project wage data gateway 200, a blockchain smart contract node 300, and a business processing terminal 400. The processing actions of the business processing terminal 400 corresponding to the data access server and the business server can be undertaken by a single server, different service processes within the same business platform, or an equivalent data processing device.

[0018] like Figure 1As shown, the access control or attendance terminal 100 and the project salary data gateway 200 respectively provide entry records and salary instruction writing records to the three-node event group generation unit 410 within the business processing terminal 400 via the input arrows shown in the diagram. The three-node event group generation unit 410, the risk assessment unit 420, and the contract call control unit 430 are connected sequentially within the business processing terminal 400 according to their processing order. The bidirectional arrows shown in the diagram between the blockchain smart contract node 300 and the contract call control unit 430 correspond to two time-separated interaction stages: In the verification evidence acquisition stage, the blockchain smart contract node 300 returns the contract confirmation record formed for the salary instruction business transaction to the contract call control unit 430. This contract confirmation record was formed before the start of this salary deposit assessment. The contract call control unit 430 writes the contract confirmation record into its respective contract confirmation record cache, and the three-node event group generation unit 410 reads the contract confirmation record through the internal data access mechanism of the business processing terminal 400. During the verification and execution phase, the contract call control unit 430 sends the verified contract call data packet to the blockchain smart contract node 300. The blockchain smart contract node 300 returns a contract execution receipt, which carries the verified execution status. The contract confirmation record and the contract execution receipt have different business objects, generation times, and purposes. The contract execution receipt is not used as the third type of record in generating this three-node event group.

[0019] Example 1:

[0020] In construction project management, wage security deposits typically need to be verified based on project status, personnel entry and attendance records, wage instruction writing status, payment status, historical verification results, and smart contract execution status. While existing business systems can record multi-source data, when delays occur, they often only detect slower end-to-end processing, failing to clearly distinguish whether the delay primarily originates from the area between access control or attendance terminal 100 and the project wage data gateway 200, or from the area between the project wage data gateway 200 and the blockchain smart contract node 300. This distinction is essential for dynamic verification of wage security deposits because delayed on-site data and delayed on-chain confirmation correspond to different processing branches. Updating the current risk value solely based on total duration or a single abnormality percentage can easily lead to fluctuations in the verified amount, duplicate contract calls, or incorrect gating.

[0021] In this embodiment, the business processing terminal 400 utilizes the entry record time, wage instruction writing time, and contract confirmation time already generated by the three nodes during the business process to construct a three-node event group, and determines the three-node timing inflection point value when the three-node event group satisfies the chronological order. The three-node timing inflection point value is used to express the directed position of the wage instruction writing time in the end-to-end processing chain time interval, enabling the business processing terminal 400 to distinguish between input chain segment anomalies and confirmation chain segment anomalies when the entire closure duration is the same.

[0022] Access control or attendance terminal 100 can be a real-name access control device, attendance machine, mobile attendance terminal, or equivalent on-site recording device at the construction site, capable of generating entry records and entry record times corresponding to personnel entry or valid attendance. Project payroll data gateway 200 can be a server gateway that receives payroll documents, payroll instructions, project personnel associated data, and payment preparation data, capable of generating payroll instruction write time when the payroll instruction is written to the database. Blockchain smart contract node 300 can be a consortium blockchain node, a government regulatory blockchain node, or an enterprise internal trusted ledger node. When the business transaction corresponding to the payroll instruction reaches the confirmation state, blockchain smart contract node 300 forms a contract confirmation record and contract confirmation time. This contract confirmation record serves as the third type of evidence record for subsequent payroll security deposit verification. After receiving the contract call data packet for this verification, blockchain smart contract node 300 executes the verification amount write, postpone write, or retry status write, and forms a contract execution receipt carrying the execution status. The contract confirmation time refers only to the time in the contract confirmation record, not the return time of the contract execution receipt.

[0023] The business processing terminal (400) handles data access, data fusion, risk assessment, and contract call control. According to... Figure 1 The actual arrow relationship is as follows: the three-node event group generation unit 410 directly obtains two types of inputs provided by the access control or attendance terminal 100 and the project salary data gateway 200, and reads the contract confirmation record returned by the blockchain smart contract node 300 during the evidence verification stage from the contract confirmation record cache area to which the contract call control unit 430 belongs; the risk assessment unit 420 processes the output of the three-node event group generation unit 410; the contract call control unit 430 processes the output of the risk assessment unit 420, sends a contract call data packet to the blockchain smart contract node 300 and receives a contract execution receipt during the verification call execution stage. Therefore, Figure 1The bidirectional connections between the access control or attendance terminal 100 and the three-node event group generation unit 410, the project salary data gateway 200 and the three-node event group generation unit 410, the three-node event group generation unit 410 and the risk assessment unit 420, the risk assessment unit 420 and the contract call control unit 430, and the blockchain smart contract node 300 and the contract call control unit 430 correspond to the determined data objects and processing stages, and the contract execution receipt verified this time will not become the calculation input for this verification.

[0024] Example 2:

[0025] The business processing terminal 400 first establishes a data processing environment. This environment includes an access control or attendance terminal 100, a project payroll data gateway 200, a blockchain smart contract node 300, and the business processing terminal 400. The business processing terminal 400 can establish project master data, personnel master data, data source registration information, approved tasks, risk results, and smart contract call records. These data objects can be implemented using relational database tables, structured files, cached objects, or equivalent structured storage, as long as the traceability relationship between project number, personnel number, approval cycle, data version number, event group summary, and processing status can be maintained.

[0026] Before the three-node event group is formed, the business processing terminal 400 registers the data source registration information. The data source registration information includes the data source number, the project number, and a fixed correspondence between the data source number and the project number. For the access control or attendance terminal 100, the data source registration information enables the business processing terminal 400 to confirm which project a certain entry record belongs to; for the project payroll data gateway 200, the data source registration information enables the business processing terminal 400 to confirm the project boundary corresponding to a certain payroll instruction write record; for the blockchain smart contract node 300, the data source registration information enables the business processing terminal 400 to confirm the on-chain project ledger corresponding to a certain contract confirmation record.

[0027] Data source registration information may also include interface address, transmission protocol, certificate information, collection period, activation status, most recent collection time, and field mapping template number. These supplementary fields are standard engineering configurations in existing data access systems, used to ensure stable access to the business processing terminal 400 from different sources.

[0028] Project master data must include at least the project number, project status, project start and end times, and current margin record. Personnel master data must include at least the personnel number, project number, employment status, and valid time period. The business processing terminal (400) matches the data source registration information with the project master data using the project number, and associates entry records, payroll instructions, payment status receipts, and project status records with the same project and the same personnel using the personnel number and valid time period. For situations where different systems use different personnel numbers, conversion can be performed using the existing personnel master data's number mapping relationship; records where the mapping relationship cannot be determined are not included in this automatic verification and are marked as pending review.

[0029] Example 3:

[0030] The three-node event group generation unit 410 executes the formation of a three-node event group. Specifically, the three-node event group generation unit 410 associates the entry record generated by the access control or attendance terminal 100, the wage instruction writing record generated by the project wage data gateway 200, and the contract confirmation record generated by the blockchain smart contract node 300 into the same three-node event group according to the project number, personnel number, and verification period. The project number is used to limit the scope of the project, the personnel number is used to limit the personnel, and the verification period is used to limit the time range covered by this wage security deposit verification.

[0031] The three-node event group includes the project number, personnel number, verification period, entry record time, payroll instruction writing time, contract confirmation time, data source numbers for the three nodes, original business numbers for the three nodes, data version number, event group summary, and complete event group identifier. The entry record time comes from access control or attendance terminal 100, the payroll instruction writing time comes from the project payroll data gateway 200, and the contract confirmation time comes from blockchain smart contract node 300. The data source numbers for the three nodes indicate the record source, the original business numbers for the three nodes retain the original index in the source system, and the data version number indicates the data batch used in this verification.

[0032] When forming a three-node event group, the three-node event group generation unit 410 first checks whether the three types of records exist simultaneously. If any one of the following records is missing: entry record, wage instruction write record, or contract confirmation record, the event group completeness marker indicates that the three-node event group is incomplete, and the corresponding missing node is recorded. If all three types of records exist, the event group completeness marker indicates that the three-node event group is complete, and the three-node event group generation unit 410 further checks whether the entry record time, wage instruction write time, and contract confirmation time meet the chronological order.

[0033]

[0034] in, This indicates the entry record time, taken from the entry record generated by the access control or attendance terminal 100; This indicates the time when the payroll instruction was written, taken from the payroll instruction write record generated by the project payroll data gateway 200. This indicates the contract confirmation time, taken from the contract confirmation record formed by blockchain smart contract node 300 during the evidence acquisition phase. Only when the above time sequence is true will the three-node event group proceed to the subsequent calculation of the three-node time sequence inflection point value. If all three types of records exist but the above time sequence is not true, the business processing terminal 400 identifies the three-node event group as an uncalculate event group and writes it into a time sequence anomaly state. It does not calculate the three-node time sequence inflection point value, normal inflection point value, inflection point deviation value, current risk value, or verified amount, and does not generate a contract call data packet for writing the verified amount. The business processing terminal 400 only saves the three-node event group, event group summary, event group complete flag, time sequence anomaly state, and audit record. This branch is independent of the incomplete event group branch when records are missing.

[0035] When generating the event group summary, the three-node event group generation unit 410 normalizes and serializes the entry record time, pay order writing time, contract confirmation time, data source number of the three nodes, original business number of the three nodes, project number, personnel number, and data version number according to the above fixed field order. The entry record time, pay order writing time, and contract confirmation time are uniformly converted into millisecond-level timestamp decimal text in the same time zone; the number field retains the case of the characters as recorded, and removes leading and trailing whitespace; if the field does not exist, the fixed text NULL is written. Each field is encoded in the form of "field byte length, colon, field value", and the encoded results of each field are concatenated continuously in a fixed field order, with characters uniformly encoded in UTF-8.

[0036] This implementation uses the SHA-256 digest algorithm to generate an event group digest from the normalized serialization result. The digest algorithm identifier, data version number, and normalized serialization result for verification are provided to the smart contract along with the contract call data packet. The smart contract regenerates the event group digest according to the same field order, time format, null value rule, byte length rule, and UTF-8 encoding. The regenerated event group digest is then compared byte-by-byte with the event group digest in the contract call data packet. If they match, the event group digest verification passes; if they do not match, the smart contract refuses to update and writes an event group digest verification failure status. If the digest algorithm identifier and configuration version number do not match, it is treated as an event group digest inconsistency.

[0037] Under the same project number, personnel number, verification period, and data version number, the three-node event group generation unit 410 uses only one fixed field order and one summary algorithm for identification. Configuration version updates only take effect for the next verification period, and the already generated event group summaries continue to be reviewed according to their recorded configuration versions, thereby avoiding different event group summaries for the same three-node event group due to configuration switching.

[0038] The event group complete tag and the event group summary work together. The event group summary proves the set of fields and the order of fields in a three-node event group, while the event group complete tag indicates whether the three-node event group has all the necessary records for the three nodes.

[0039] When multiple candidate entry records, salary instruction write records, or contract confirmation records exist within the same project, the same personnel, and the same approval cycle, the business processing terminal 400 performs deterministic matching in a fixed order. First, completely duplicate records are deleted based on identical data source number, original business number, data version number, and record content. Second, for records corresponding to the same original business number, only the record with a valid business status and the largest data version number is retained; if the data version numbers are the same, only the record with the latest receiving time is retained. Third, records are matched based on the original business number correspondence, project number, personnel number, and approval cycle already saved in the source system. When each node has only one candidate record after the above processing, the three-node event group generation unit 410 uses this candidate record to form a three-node event group and includes the original business numbers and data version numbers of the three nodes in the event group summary. If, after the above processing, any node still has two or more candidate records that cannot be uniquely determined, or if any node has no valid candidate record, the business processing terminal 400 writes a candidate record conflict status, sends the corresponding record to the manual review queue, and stops the automatic three-node time-series inflection point value calculation and contract invocation. Therefore, the same source record set, data version number, and configuration version number can only result in one candidate record selection.

[0040] Example 4:

[0041] The business processing unit 400 unifies the format of multi-source raw data to form a project verification dataset. This multi-source raw data may include entry records provided by access control or attendance terminals 100, payroll instruction write records provided by the project payroll data gateway 200, contract confirmation records provided by blockchain smart contract nodes 300, payment status receipts provided by payment interfaces or bank receipt interfaces, and project status records provided by the project management system. The aforementioned data may have different field names, time formats, amount precision, and status codes in the source systems. The business processing unit 400 performs unified processing on this data before it enters the risk verification unit 420.

[0042] When generating the project verification dataset, the business processing terminal 400 converts the fields corresponding to the entry record time, wage instruction writing time, contract confirmation time, payment status, and project status into a unified format. Time fields can be standardized to timestamps in the same time zone or date and time text in the same format; payment status can be standardized to preset statuses such as success, failure, processing, or return; project status can be standardized to preset statuses such as under construction, suspended, completed, or settled. This field conversion is a standard data cleaning process, aimed at ensuring consistency in the meaning of the data used when subsequently calculating individual normalized values, current risk values, and verified amounts.

[0043] The business processing terminal 400 uses the project number as the project association key and the personnel number and valid time period as the personnel association key to link entry records, payroll instruction write records, payment status receipts, and project status records to the same project and the same personnel. The project number is used to prevent data from being mixed between different construction projects; the personnel number and valid time period are used to prevent data from being incorrectly merged across projects or employment periods for the same person. For records that cannot be associated using the project number, personnel number, and valid time period, the business processing terminal 400 marks the record as an unassociable record and records the corresponding exception information in the project verification dataset.

[0044] The project verification dataset must at least store the data version number, project number, verification period, statistical time range, number of records from each source, number of abnormal records, payment status, project status, historical processing status, and a summary of the event group corresponding to the project. When calculating the current risk value, the risk verification unit 420 reads the data missing ratio, abnormal record ratio, payroll instruction and attendance record matching ratio, abnormal payment status ratio, project status value, and historical processing status from the project verification dataset. The project verification dataset also retains the event group summary, enabling the risk verification results to be traced back to the specific three-node event group generated by the three-node event group generation unit 410.

[0045] To avoid duplicate verifications, the business processing terminal 400 can set unique constraints on the project number, verification period, and data version number, or verify whether the same data version number has already been processed before the contract call control unit 430 assembles the contract call data packet. This idempotent processing is a standard measure in existing business systems. Its purpose is to ensure that the same project verification dataset will not generate multiple conflicting verification amounts due to interface retries or duplicate task scheduling.

[0046] Example 5:

[0047] When the three-node event group meets the chronological order, the risk assessment unit 420 forms an end-to-end processing chain time interval based on the entry record time and the contract confirmation time. The start of the end-to-end processing chain time interval corresponds to the entry record time, and the end point corresponds to the contract confirmation time. The payroll instruction write time is located within this end-to-end processing chain time interval, indicating that the project payroll data gateway 200 is an intermediate processing node between the on-site entry record and the on-chain contract confirmation.

[0048] The risk assessment unit 420 first determines the total closure time. The total closure time is used to express the total processing time from the formation of an entry record by the access control or attendance terminal 100 to the formation of a contract confirmation record by the blockchain smart contract node 300.

[0049]

[0050] in, Indicates the duration of the entire closure. Indicates the contract confirmation time. This indicates the entry recording time. The total closure duration must be greater than zero; otherwise, the three-node event group will not meet the computability condition.

[0051] Subsequently, the risk assessment unit 420 determines the midpoint position value. The midpoint position value is used to represent the normalized position of the payroll instruction write time within the end-to-end processing chain time interval.

[0052]

[0053] in, Indicates the midpoint position value. Indicates the time the payroll instruction was written. Indicates the entry record time. Indicates the contract confirmation time. For those that meet the requirements... The three-node event group has a midpoint value between zero and one. The closer the midpoint value is to one, the closer the wage instruction was written to the contract confirmation time; the closer the midpoint value is to zero, the closer the wage instruction was written to the entry record time.

[0054] After determining the midpoint position value, the risk assessment unit 420 determines the three-node timing inflection point value based on the offset direction and magnitude of the wage instruction writing time relative to the start and end points of the end-to-end processing chain time interval.

[0055]

[0056]

[0057] in, Indicates the three-node timing inflection point value. Indicates the midpoint position value. Indicates the time the payroll instruction was written. Indicates the entry record time. This indicates the contract confirmation time. The three-node time-series inflection point values ​​retain both direction and magnitude. The direction is used to identify which end of the end-to-end processing chain time interval the wage instruction write time is closer to, and the magnitude is used to express the degree of deviation from the midpoint of the end-to-end processing chain time interval.

[0058] Risk assessment unit 420 first determines whether the inflection point deviation value meets the inflection point allowable deviation condition. When When this happens, no input segment verification flag or acknowledgment segment retry flag is generated. and When the wage instruction is written closer to the contract confirmation time, the risk assessment unit 420 generates an input chain segment verification mark; when and At that time, the wage instruction write time is closer to the entry record time, and the risk assessment unit 420 generates a confirmation chain retry flag. When and At that time, the risk assessment unit 420 closes the boundary branch in the direction of the current three-node time series inflection point value relative to the normal inflection point value: if Generate input chain segment verification markers; if Generate a confirmation retry flag for the chain segment. Since the allowable deviation of the breakpoint is not less than zero, when... There will always be a time for it. It will not satisfy both simultaneously. Therefore, there are no remaining branches with unassigned exception chain segment markers.

[0059] The three-node time-series inflection point value differs from simply calculating the total closure duration. The total closure duration only indicates the overall time consumption of the end-to-end processing chain and cannot distinguish the location of delays. The three-node time-series inflection point value places the wage instruction writing time corresponding to the project wage data gateway 200 into a directed location between the entry record time and the contract confirmation time, enabling the business processing terminal 400 to distinguish between the input chain segment and the confirmation chain segment when the total closure duration is the same. This processing relies entirely on the measured time of the three existing nodes and does not introduce new equipment data collection.

[0060] Example 6:

[0061] To avoid misjudgments caused by differences in network environment, terminal upload cycle, payroll instruction batch processing cycle, and blockchain confirmation cycle across different projects, Risk Assessment Unit 420 does not directly determine whether the three-node time-series inflection point value is abnormal based on a fixed value across projects. Instead, it determines the normal inflection point value based on historically valid three-node event groups. A historically valid three-node event group refers to a three-node event group within the same project that has met the time sequence requirements, whose complete event group marker indicates the integrity of the three-node event group, and which has already formed a valid three-node time-series inflection point value.

[0062]

[0063] in, Indicates the normal inflection point value; These represent the three-node time-series inflection points of the most recent multiple valid three-node event groups in the same project; This represents the number of historical samples. Using the median can reduce the impact of individual extreme three-node event groups on the normal inflection point value, making the normal inflection point value closer to the processing position of the project under normal operating conditions.

[0064] After obtaining the current three-node time series inflection point values ​​and the normal inflection point values, the risk assessment unit 420 determines the inflection point deviation value. The inflection point deviation value is determined by the degree of difference between the current three-node time series inflection point values ​​and the normal inflection point values.

[0065]

[0066] in, Indicates the inflection point deviation value. This represents the current three-node time series inflection point values. This represents the normal inflection point value. The larger the inflection point deviation value, the greater the deviation of the directed position of the wage instruction write time in the current three-node event group from the normal position of the same project. The inflection point deviation value is used to correct the current risk value and is used by the contract call control unit 430 to form the contract call data packet for verification by the smart contract.

[0067] This implementation method will consider the number of historical samples. The number of valid three-node event groups is fixed at 20, and the most recent valid three-node event groups for the same project are selected from newest to oldest according to data version number. When there are 1 to 19 valid three-node event groups, the risk assessment unit 420 uses the median of the three-node time series inflection points of all existing valid three-node event groups as the normal inflection point value, and records the historical sample insufficiency status. When there are zero valid three-node event groups, the normal inflection point value and inflection point deviation value are uncertain, the current risk value is not updated, and the assessment amount is not submitted; the current assessment task enters the state of waiting for supplementary samples. After reaching 20 valid three-node event groups, the risk assessment unit 420 uses the 20 most recent valid three-node event groups to determine the normal inflection point value. This priority order ensures that the same historical sample conditions produce only one processing result.

[0068] The allowable deviation of the inflection point is determined using the quantile of the historical inflection point deviation values ​​within the current historical window for the same project. The risk assessment unit 420 first determines the normal inflection point value for the current assessment period based on the three-node time-series inflection point values ​​in the current historical window. Then, using this normal inflection point value as a unified benchmark, it re-determines the corresponding historical inflection point deviation value for each three-node time-series inflection point value in the current historical window. The risk assessment unit 420 sorts the 20 most recent re-determined historical inflection point deviation values ​​in ascending order, using the sorted values ​​as the basis for determination. The historical inflection point deviation is used as the quantile result, and the quantile result is limited to between 0.05 and 0.50; when there are 1 to 19 valid three-node event groups, the allowable deviation of the inflection point is fixed at 0.20. The normal inflection point value and the allowable deviation of the inflection point are written to the configuration version and remain unchanged within a verification period, and are only re-determined using the updated historical window at the beginning of the next verification period.

[0069]

[0070] in, Indicates the current history window The historical inflection point deviation value corresponding to each of the three historical time series inflection points. Indicates the first Three historical time series inflection point values. This indicates the normal inflection point value used in this approval period. All historical inflection point deviations used for sorting are calculated based on the same normal inflection point value.

[0071]

[0072] in, This indicates the position after sorting from smallest to largest. The historical inflection point deviation value. Both the allowable inflection point deviation and the inflection point deviation value are dimensionless. The business processing terminal 400 and the smart contract store the allowable inflection point deviation in the same configuration version. The smart contract only uses the allowable inflection point deviation corresponding to the configuration version carried in the contract call data packet to perform the comparison.

[0073]

[0074] in, Indicates the allowable deviation at the inflection point. This represents the inflection point deviation value. When the inflection point deviation value meets the inflection point allowable deviation condition, the smart contract writes the approved amount if other verifications pass; when the inflection point deviation value does not meet the inflection point allowable deviation condition, the smart contract performs a delayed write or a retry write based on the uniquely determined input chain segment review flag or confirmed chain segment retry flag.

[0075] Example 7:

[0076] When the risk assessment unit 420 updates the current risk value, it uses the current project number, current assessment period, current data version number, and the statistical time range in the project assessment dataset to define a unique statistical range. It then sequentially reads the data missing rate, abnormal record rate, payroll instruction and attendance record matching rate, abnormal payment status rate, project status value, and historical processing status from the project assessment dataset, forming six risk data items in a fixed order. Therefore, the number of data items... The value is 6. All four proportional risk data items are determined using data from this unique statistical range, while the status-based risk data items have their individual normalized values ​​determined according to a fixed mapping in the same configuration version.

[0077]

[0078] in, Indicates the percentage of missing data. Indicates the number of missing required fields. This indicates the total number of required fields. Required fields are uniquely determined by the "Required" flag in the field mapping template of the current configuration version; the business processing end counts each field on a per-field basis for all records within the statistical scope, with each missing required field counted as one instance of missing required field. When the business processing terminal writes the field configuration to an abnormal state and stops the current risk value calculation, the corresponding required fields are counted as missing when the entire collection record is not obtained.

[0079]

[0080] in, Indicates the proportion of abnormal records. Indicates the number of abnormal records. This indicates the total number of standard business records. A standard business record is counted as an abnormal record if any of the following conditions are met: the time field cannot be parsed, the amount field is not numeric, the status code is not registered, the project number or personnel number cannot be associated, or there is a conflict between candidate records. If the same standard business record meets multiple abnormal conditions simultaneously, it is only counted once. At that time, the proportion of abnormal records is fixed at 1 and a data missing status is written.

[0081]

[0082] in, This indicates the matching ratio between payroll instructions and attendance records. This indicates that the number of payroll instruction details was successfully matched. This indicates the total number of payroll instruction details. The business processing terminal uses project number, employee number, and valid time period as matching criteria; a successful match is counted when a payroll instruction detail corresponds to at least one valid attendance record, and even if the same payroll instruction detail corresponds to multiple valid attendance records, it is still counted only once. At that time, the matching ratio between the wage instruction and the attendance record is fixed at 0 and a data missing status is written.

[0083]

[0084] in, This indicates the percentage of payments with abnormal status. This indicates the number of payment status error receipts. This indicates the total number of payment status receipts that have been completed. Payment status receipts that are successful are not counted in the number of payment status error receipts; payment status receipts that are failed or returned are counted in the number of payment status error receipts; and payment status receipts that are in progress are not counted in the total number of payment status receipts. At that time, the proportion of abnormal payment status is fixed at 1 and written to the payment status pending confirmation status.

[0085]

[0086] in, This represents the normalized value corresponding to the proportion of missing data. This indicates the percentage of missing data in the project's verified dataset. When the percentage of missing data is between zero and one, the normalized value for each item is the same as the percentage of missing data.

[0087]

[0088] in, This represents the single-item normalized value corresponding to the proportion of abnormal records. This indicates the proportion of abnormal records in the project's verified dataset.

[0089]

[0090] in, This represents the single-item normalized value corresponding to the matching ratio between payroll instructions and attendance records. This indicates the matching ratio between payroll instructions and attendance records. The lower the matching ratio, the higher the single-item normalization value.

[0091]

[0092] in, This represents the single-item normalized value corresponding to the proportion of payment status anomalies. This indicates the proportion of abnormal payment statuses in the project's verified dataset.

[0093] The project status value corresponds to the fifth risk data item. In an implementable fixed mapping, the single-item normalized value for "Under Construction" is 0.25, for "Settlement" it is 0.50, for "Stopped" it is 1.00, and for "Completed" it is 0. The historical processing status corresponds to the sixth risk data item: the single-item normalized value for "Writing Approved Amount" is 0, for "Confirmation Chain Retry" it is 0.50, for "Input Chain Review" it is 0.75, and for "Reject Update" or "Incomplete Event Group" it is 1.00. When the status field contains a status code for an unregistered configuration version, the corresponding single-item normalized value is set to 1.00, and the status mapping anomaly is recorded.

[0094] When proportional risk data items are missing, cannot be parsed, or conflict with each other and cannot be uniquely identified as valid records based on data version numbers, the corresponding single-item normalization value is set to 1.00; when proportional risk data items exceed the range of zero to one, they are truncated to the range of zero to one according to the above formula. The business processing terminal 400 always uses the configuration version locked at the beginning of the current approval cycle.

[0095]

[0096] This implementation sets the individual weights according to a fixed order of the six risk data items mentioned above: the weight corresponding to the data missing ratio is 0.20, the weight corresponding to the abnormal record ratio is 0.20, the weight corresponding to the matching ratio of payroll instructions and attendance records is 0.20, the weight corresponding to the abnormal payment status ratio is 0.15, the weight corresponding to the project status value is 0.15, and the weight corresponding to the historical processing status is 0.10. All individual weights are non-negative dimensionless quantities and their sum is 1. No temporary adjustments are made within the same configuration version.

[0097] The risk assessment unit 420 uses the above-mentioned fixed single-item weights to calculate the basic risk result, and then corrects it with the inflection point deviation value to obtain the current risk value.

[0098]

[0099] in, Indicates the current risk value; Indicates the first The single-item normalized value of each data item; Indicates the first The individual weight of each data item; Indicates the number of data items; Indicates the inflection point influence coefficient; This represents the inflection point deviation value. The individual normalized value, individual weight, inflection point influence coefficient, inflection point deviation value, and current risk value are all dimensionless quantities. The basic risk result is related to... The same dimensionless risk scale is used.

[0100] In this implementation, the inflection point impact coefficient is fixed at 0.25. Configuration verification requires the inflection point impact coefficient to be between 0 and 0.50; configuration versions outside this range must not be enabled. The inflection point impact coefficient is not obtained through training using this method; it can only be updated at the start of the next verification cycle with a new configuration version. Verification cycles that have already begun continue to use the locked inflection point impact coefficient. This rule ensures that the same data version number, the same configuration version number, and the same inflection point deviation value uniquely correspond to the same current risk value.

[0101] The risk assessment unit 420 generates the assessed amount based on the current risk value. Specifically, the business processing unit 400 reads the base amount, risk conversion factor, minimum amount, maximum amount, and currently stored amount, substitutes the current risk value into the amount conversion rules, first obtains the calculated amount, and then applies a limit between the minimum amount and the maximum amount to obtain the assessed amount.

[0102]

[0103] in, Indicates the amount to be calculated. Indicates the base amount. This represents the risk conversion factor. This represents the current risk value. The risk conversion factor is dimensionless; the base amount and the calculated amount use the same currency unit. The base amount and risk conversion factor are preferentially read from the regulatory rules locked in the current approval period; if the regulatory rules do not have corresponding parameters configured, the project configuration locked in the current approval period is read. Before configuration can be enabled, the base amount must be no less than zero and... If the conditions are not met, an abnormal status will be written to the amount configuration and the calculation of the approved amount will be stopped.

[0104]

[0105] in, Indicates the approved amount. Indicates the maximum amount. Indicates the minimum amount. This indicates the calculated amount. The minimum and maximum amounts use the same configuration priority as the baseline amount and are validated before the configuration is enabled. If the conditions are not met, an abnormal status will be entered in the amount configuration, and the calculation of the approved amount will be stopped. This restriction ensures that the approved amount will not be lower than the minimum amount or higher than the maximum amount.

[0106]

[0107] in, This indicates the amount of the adjustment. Indicates the approved amount. This indicates the current deposited amount. The base amount, calculated amount, minimum amount, maximum amount, approved amount, current deposited amount, and adjusted amount are all denominated in the same currency. A positive adjusted amount increases the wage security deposit; a negative adjusted amount indicates the current deposited amount is higher than the approved amount; and a zero adjusted amount does not adjust the wage security deposit.

[0108] In this implementation, all amounts are uniformly decimaled to two RMB yuan. The base amount, minimum amount, maximum amount, and current amount are all saved to two decimal places before calculation. After the calculated amount reaches the upper and lower limits, the approved amount is rounded to two decimal places, and then the current amount is subtracted from the approved amount to obtain the adjusted amount. This adjusted amount is also rounded to two decimal places. When outputting the approved amount, the risk assessment unit 420 also retains the current risk value, inflection point deviation value, event group summary, data version number, and configuration version number, so that the contract call control unit 430 can assemble a verifiable contract call data packet.

[0109] Example 8:

[0110] The contract invocation control unit 430 receives the current risk value, approved amount, current adjustment amount, three-node time-series inflection point value, normal inflection point value, inflection point deviation value, and abnormal chain segment marker output by the risk assessment unit 420, and reads the event group summary and complete event group marker generated by the three-node event group generation unit 410. The contract invocation control unit 430 assembles the project number, data version number, approved amount, event group summary, complete event group marker, three-node time-series inflection point value, inflection point deviation value, and abnormal chain segment marker into a contract invocation data packet.

[0111] In this embodiment, the contract call data packet also includes the verification period, current risk value, current adjustment amount, call request number, timestamp, configuration version number, digest algorithm identifier, and normalized serialization result for reviewing the event group digest.

[0112] The business processing terminal 400 generates a digital signature for each contract call data packet. The signature must cover at least the project number, data version number, approved amount, event group digest, complete event group marker, three-node time-series inflection point value, inflection point deviation value, abnormal chain segment marker, call request number, timestamp, and configuration version number. The text to be signed uses the same field length encoding rules as the event group digest. This implementation employs the SM2 signature algorithm and the SM3 digest algorithm. The business processing terminal 400 holds the caller's private key, and the blockchain smart contract node 300 verifies the digital signature based on the caller's registered public key. If any of the fields covered by the signature change after signing, the digital signature verification will fail.

[0113] The smart contract sequentially verifies the caller's identity, digital signature, project number, data version number, and event group digest. If the caller's identity does not exist, the caller's public key does not match the caller's identity, digital signature verification fails, the project number does not exist, or the configuration version number does not exist, the smart contract refuses to update the approved amount and writes a call verification failure status. If the event group digest recalculation is inconsistent, the smart contract refuses to update the approved amount and writes an event group digest verification failure status. Neither the call verification failure status nor the event group digest verification failure status triggers the approved amount writing, input chain review status, or confirmation chain retry status, and their triggering conditions do not overlap.

[0114] The smart contract performs idempotency checks using the project number, data version number, and call request number. If the same project number, data version number, and call request number have already been executed and the event group digests are consistent, the smart contract directly returns to the original execution state without rewriting. If the same project number and data version number correspond to different event group digests, the smart contract refuses to update and writes a data version conflict state. If the submitted data version number is lower than the data version number already recorded on the chain, the smart contract refuses to update and writes a data version expiration state. If the submitted data version number is higher than the data version number already recorded on the chain, the verification of event group complete marking, inflection point deviation value, and abnormal chain segment marking continues.

[0115] After the smart contract verifies the caller's identity, digital signature, project number, data version number, and event group summary, it verifies the event group integrity flag and inflection point deviation value. When the event group integrity flag indicates that the three-node event group is complete, and the inflection point deviation value meets the inflection point allowable deviation condition, the smart contract writes the approved amount, data version number, event group summary, three-node timing inflection point value, and execution status. When the inflection point deviation value does not meet the inflection point allowable deviation condition, the smart contract only accepts the input chain segment verification flag or the confirmation chain segment retry flag generated by the risk verification unit 420 according to the deterministic boundary rules, and enters the write branch in the delayed write or retry state respectively.

[0116] When an input chain segment verification flag exists, the smart contract maintains the original amount and writes the input chain segment verification status. The input chain segment verification status indicates that the current anomaly is more likely located between access control or attendance terminal 100 and project payroll data gateway 200, requiring verification of entry records, payroll instruction write records, data source numbers, original business numbers, or upload time windows. When a confirmation chain segment retry flag exists, the smart contract maintains the original amount and writes the confirmation chain segment retry status. The confirmation chain segment retry status indicates that the current anomaly is more likely located between project payroll data gateway 200 and blockchain smart contract node 300, requiring processing of the contract call queue, on-chain confirmation status, or retry tasks.

[0117] When the three-node event group is incomplete, the smart contract refuses to update and records the missing node. The missing node can be any node in the entry record, payroll instruction write record, or contract confirmation record. After the smart contract records the missing node, the business processing terminal 400 can generate a pending supplementary collection status or a pending manual review status based on the missing node. This process avoids directly writing the approved amount when evidence of a complete three-node event group is lacking.

[0118] The contract call control unit 430 receives the contract execution receipt returned by the blockchain smart contract node 300 for this contract call data packet, and reads the execution status from the contract execution receipt. The execution status includes the written approved amount, the input chain segment review status, the confirmed chain segment retry status, the update rejection status, the call verification failure status, the event group summary verification failure status, the data version conflict status, the data version expiration status, and the contract execution failure status. The business processing end 400 writes the execution status, failure reason, processing time, data version number, and event group summary into the verification result record and audit record. The contract execution receipt is not written to the contract confirmation record cache, nor is it used as a contract confirmation record for generating this three-node event group or for subsequent recalculation of the same verified task.

[0119] Before the start of a complete verification cycle, the business transactions corresponding to the payroll instructions have been confirmed by the blockchain smart contract node 300 and a contract confirmation record has been formed; the contract call control unit 430 through... Figure 1 The return direction of the bidirectional connection between the blockchain smart contract node 300 and the contract call control unit 430 retrieves the contract confirmation record and writes it into the contract confirmation record cache of the contract call control unit 430. At the start of this complete verification cycle, the business processing terminal 400 reads the data source registration information and locks the configuration version, confirming that the access control or attendance terminal 100, the project salary data gateway 200, and the blockchain smart contract node 300 have all registered the data source number, and that there is a fixed correspondence between the data source number and the project number. The access control or attendance terminal 100 uploads the entry record, the project salary data gateway 200 generates a salary instruction write record, and the three-node event group generation unit 410 reads the contract confirmation record corresponding to the salary instruction from the contract confirmation record cache. This order of obtaining evidence first and then verifying the call ensures that there is no circular dependency between the contract confirmation record and the contract call data packet in this verification.

[0120] The three-node event group generation unit 410, based on the project number, personnel number, and verification cycle, and following a fixed order of deleting completely duplicate records, filtering valid business status, selecting the maximum data version number, selecting the latest reception time, and matching the correspondence of the original business number, determines a unique candidate record from the records provided by the access control or attendance terminal 100 and the project payroll data gateway 200, as well as the contract confirmation records in the contract confirmation record cache, and associates them into the same three-node event group. The three-node event group generation unit 410 then checks... The event group summary is generated according to a fixed field order, millisecond-level timestamps, field byte lengths, and UTF-8 encoding rules. If any record is missing, the system enters the incomplete event group branch; if a candidate record cannot be uniquely determined, the system enters the candidate record conflict state; if all three types of records exist but the time sequence is incorrect, the system enters the time sequence abnormal state. In all three cases, the calculation of the current risk value and the approved amount is stopped.

[0121] The business processing end performs format unification on 400 pairs of multi-source raw data, converting entry record time, pay order writing time, contract confirmation time, payment status, and project status into a unified format. The project number is used as the project association key, and the personnel number and effective time period are used as the personnel association key to form a project verification dataset. The project verification dataset stores the data missing ratio, abnormal record ratio, pay order and attendance record matching ratio, payment status abnormality ratio, project status value, historical processing status, and a summary of the event group corresponding to this project. The data missing ratio is determined by the ratio of the number of missing required fields to the total number of required fields; the abnormal record ratio is determined by the ratio of the number of abnormal records to the total number of standard business records; the pay order and attendance record matching ratio is determined by the ratio of the number of successfully matched pay order details to the total number of pay order details; and the payment status abnormality ratio is determined by the ratio of the number of payment status abnormal receipts to the total number of completed payment status receipts. All four ratios use data limited by the current project number, current verification cycle, current data version number, and statistical time range.

[0122] Risk assessment unit 420 determines the entire closure duration, midpoint position value, three-node time series inflection point value, normal inflection point value, and inflection point deviation value. When there are 1 to 19 historical valid three-node event groups, all existing valid three-node event groups are used to determine the normal inflection point value, and the allowable deviation of the inflection point is set to 0.20. When there are zero historical valid three-node event groups, the system enters a state of pending sample replenishment. When there are 20, the normal inflection point value of the current assessment period is used as a unified benchmark to re-determine the deviation values ​​of the most recent 20 historical inflection points, and then the allowable deviation of the inflection point is determined according to the quantile rule. and At that time, according to The direction generates input segment verification flags or confirmation segment retry flags.

[0123] Risk assessment unit 420 determines six individual normalized values ​​based on proportional truncation, mismatched proportional conversion, and fixed state mapping. A basic risk result is obtained using a fixed individual weight summed to 1. This basic risk result is then corrected using a fixed inflection point impact coefficient of 0.25 to obtain the current risk value. Risk assessment unit 420 generates the assessed amount and the adjusted amount based on the baseline amount, risk conversion coefficient, minimum amount, maximum amount, and currently existing amount in the same configuration version. Amount parameters in regulatory rules take precedence over amount parameters in project configuration; the configuration must meet the requirement that the baseline amount is not less than zero. and Both the approved amount and the amount adjusted this time are denominated in RMB and rounded to two decimal places.

[0124] The contract call control unit 430 generates a contract call data packet and digitally signs all core fields. The smart contract regenerates the event group digest, verifies the caller's identity, digital signature, project number, data version number, event group digest, event group completeness marker, and inflection point deviation, and performs idempotency checks. All verifications pass and... The approved amount is written when the input chain segment verification flag exists; if there is an input chain segment verification flag, the original amount remains unchanged and the input chain segment verification status is written; if there is a confirmation chain segment retry flag, the original amount remains unchanged and the confirmation chain segment retry status is written; if the three-node event group is incomplete, the update is refused and the missing node is recorded. Blockchain smart contract node 300 returns a contract execution receipt for this call, and the contract execution receipt is not used as the contract confirmation record for this three-node event group.

[0125] In this embodiment, the access control or attendance terminal 100, the project payroll data gateway 200, and the blockchain smart contract node 300 can all be common devices or service nodes found in existing engineering project management systems. The access control or attendance terminal 100 only needs to be able to generate entry records and entry record times; the project payroll data gateway 200 only needs to be able to generate payroll instruction write records and payroll instruction write times; the blockchain smart contract node 300 needs to be able to generate contract confirmation records and contract confirmation times after the business transaction corresponding to the payroll instruction is confirmed, and also needs to be able to receive the current approved contract call data packet sent by the contract call control unit 430 and return a contract execution receipt.

[0126] The business processing terminal 400 can consist of a business server, a data access server, a database server, and a blockchain client program. The three-node event group generation unit 410 can be implemented as the association program in the data access service, the risk assessment unit 420 can be implemented as the risk calculation program in the business server, and the contract call control unit 430 can be implemented as the contract call program in the blockchain client service.

[0127] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction, applied to a data processing environment including access control or attendance terminals, project wage data gateways, blockchain smart contract nodes, and business processing terminals, wherein the business processing terminals correspond to the processing actions of data access servers and business servers, characterized in that, include: The business processing terminal associates the entry record, the wage instruction writing record, and the contract confirmation record into a three-node event group, and generates an event group summary and a complete event group tag based on the three-node event group; The business processing terminal unifies the format of multi-source raw data to form a project-approved dataset. When the three-node event group satisfies the chronological order, the business processing end forms an end-to-end processing chain time interval based on the entry record time and contract confirmation time, determines the directed position of the wage instruction writing time in the end-to-end processing chain time interval, obtains the three-node time sequence inflection point value, and determines the normal inflection point value and inflection point deviation value based on the historical valid three-node event group. The business processing terminal updates the current risk value based on the inflection point deviation value, and generates the approved amount based on the current risk value; The business processing terminal will compose a contract call data packet consisting of project number, data version number, approved amount, event group summary, event group complete marker, three-node time sequence inflection point value, inflection point deviation value and abnormal chain segment marker; The smart contract verifies the event group summary, the complete event group marker, and the inflection point deviation value, and performs the approved amount write, postponed write, or retry status write based on the verification results and the abnormal chain segment marker.

2. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 1, characterized in that, Before the three-node event group is formed, the business processing terminal registers data source registration information, which includes data source number, project number, and a fixed correspondence between data source number and project number.

3. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 1, characterized in that, The three-node event group includes project number, personnel number, verification period, entry record time, payroll instruction writing time, contract confirmation time, data source number of the three nodes, original business number of the three nodes, data version number, event group summary, and event group complete tag.

4. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 3, characterized in that, The generated event group summary includes: serializing the entry record time, salary instruction writing time, contract confirmation time, data source number of the three nodes, original business number of the three nodes, project number, personnel number and data version number in a fixed field order, and generating an event group summary from the serialization result.

5. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 1, characterized in that, The formation of the project verification dataset includes: the business processing terminal converts the fields corresponding to the entry record time, salary instruction writing time, contract confirmation time, payment status and project status into a unified format, uses the project number as the project association key, and uses the personnel number and valid time period as the personnel association key, and associates the entry record, salary instruction writing record, payment status receipt and project status record with the same project and the same personnel.

6. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 1, characterized in that, The determination of the three-node time-series inflection point values ​​includes: corresponding the entry record time to the start of the end-to-end processing chain time interval, corresponding the contract confirmation time to the end of the end-to-end processing chain time interval, and determining the three-node time-series inflection point values ​​based on the offset direction and offset magnitude of the wage instruction write time relative to the start and end of the end-to-end processing chain time interval.

7. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 6, characterized in that, The normal inflection point value is the median of the three-node time-series inflection points of the most recent valid three-node event groups for the same project; the inflection point deviation value is determined by the degree of difference between the current three-node time-series inflection point value and the normal inflection point value.

8. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 7, characterized in that, The abnormal chain segment markers include an input chain segment verification marker and a confirmation chain segment retry marker. When the three-node timing breakpoint value indicates that the wage instruction writing time is closer to the contract confirmation time and the breakpoint deviation value exceeds the breakpoint allowable deviation condition, an input chain segment verification marker is generated. When the three-node timing breakpoint value indicates that the wage instruction writing time is closer to the entry record time and the breakpoint deviation value exceeds the breakpoint allowable deviation condition, a confirmation chain segment retry marker is generated.

9. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 1, characterized in that, The process of updating the current risk value includes: the business processing terminal converting the data missing ratio, abnormal record ratio, matching ratio of payroll instructions and attendance records, abnormal payment status ratio, project status value and historical processing status into single-item normalized values, obtaining basic risk results according to preset single-item weights, and correcting the basic risk results according to the inflection point deviation value to obtain the current risk value.

10. The method for dynamic assessment of wage security deposits based on multi-source data fusion and intelligent risk prediction according to claim 8, characterized in that, The smart contract verifies the event group summary, event group integrity flag, and inflection point deviation value, and performs the following actions based on the verification results and abnormal chain segment flags: The business processing end generates a digital signature for the contract call data packet; the smart contract verifies the caller's identity, the digital signature generated by the business processing end for the contract call data packet, the project number, the data version number, and the event group summary; when the event group integrity flag indicates that the three-node event group is complete, and the inflection point deviation value meets the allowable deviation condition for the inflection point, the approved amount, data version number, event group summary, three-node timing inflection point value, and execution status are written; when an input chain segment verification flag exists, the original amount is kept unchanged and the input chain segment verification status is written; when a confirmed chain segment retry flag exists, the original amount is kept unchanged and the confirmed chain segment retry status is written; when the three-node event group is an incomplete event group, updates are rejected and missing nodes are recorded.

Images