Project fund supervision method, system, device, medium and program product

Abstract

The invention provides a project fund supervision method which can be applied to the technical field of block chains. The project fund supervision method is applied to a supervision system based on a block chain, the block chain comprises a plurality of nodes, the nodes at least comprise a supervisor node, a fund hosting node, a project establishment party node, a project owner node and a project owner representative node, and the project fund supervision method comprises the following steps: responding to a fund payment request operation; calling a preset smart contract to perform first verification on the fund payment request; after the first verification is passed, calling a preset risk identification model to carry out second verification on the fund payment request; and performing payment operation based on the second verification result. The invention further provides a project fund supervision system and device, a storage medium and a program product.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, specifically to the field of fund supervision technology, and more specifically to a project fund supervision method, system, device, medium and program product. Background Art

[0002] Funding management for installing elevators in existing multi-story residential buildings faces the following challenges: First, timely and accurate disclosure of accounting information is difficult, preventing owners from timely understanding fund usage. Second, there is a lack of effective account anomaly monitoring methods, making it impossible to intelligently identify abnormal fund flows, leading to risks such as misappropriation of funds. Therefore, a project fund monitoring method is urgently needed to help operations and maintenance personnel quickly identify and troubleshoot risks.

[0003] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute prior art known to ordinary technicians in the field. Summary of the Invention

[0004] In view of the above problems, the present disclosure provides a project fund supervision method, apparatus, device, medium and program product.

[0005] According to a first aspect of the present disclosure, a project fund supervision method is provided, which is applied to a supervision system based on a blockchain, wherein the blockchain includes a plurality of nodes, the nodes including at least a supervisory node, a fund escrow node, a project construction agent node, a project owner node, and a project owner representative node, including:

[0006] In response to a funds payment request operation, calling a preset smart contract to perform a first verification on the funds payment request;

[0007] After the first verification passes, calling a preset risk identification model to perform a second verification on the fund payment request; and

[0008] Perform a payment operation based on the second verification result,

[0009] Among them, the preset risk identification model includes a payment risk warning model and an account anomaly identification model. The payment risk warning model is implemented based on the standard score algorithm, and the account anomaly identification model is pre-trained based on the isolation forest algorithm and historical payment data.

[0010] According to an embodiment of the present disclosure, calling a preset risk identification model to perform a second verification on the fund payment request includes:

[0011] Input the fund payment request information into the payment risk early warning model to output the payment risk results;

[0012] Inputting the funds payment request information into the account anomaly identification model to identify the account status result; and

[0013] A second verification result is determined based on the payment risk result and the account status result.

[0014] According to an embodiment of the present disclosure, an account anomaly recognition model is obtained by pre-training based on the isolation forest algorithm and historical payment data, including:

[0015] Randomly select a certain number of samples from the historical payment data as training data samples, and randomly select n instances from the training data samples as a subsample set, where n is a positive integer;

[0016] Randomly assigning a payment sample attribute from a list of attributes in the subsample set and randomly determining a split point based on the payment sample attribute;

[0017] Performing left and right branch segmentation on the subsample set based on the segmentation point;

[0018] Repeat the above operations for the left and right branches respectively until the number of nodes is less than or equal to 1 or the height of the entire tree reaches the preset threshold; and

[0019] Repeat the isolation tree construction step a preset number of times to generate an isolation forest to obtain an account anomaly recognition model.

[0020] According to an embodiment of the present disclosure, inputting the fund payment request information into the account anomaly recognition model to identify the account status result includes:

[0021] Determine the payment stage category based on the fund payment request information;

[0022] Calculating anomaly scores of the data points to be identified based on the isolation forest corresponding to the payment stage category;

[0023] If it is determined that the anomaly score is greater than the first preset threshold, it is determined that the account status corresponding to the to-be-identified data point is abnormal.

[0024] According to an embodiment of the present disclosure, inputting the fund payment request information into the payment risk warning model to output the payment risk result includes:

[0025] Determine the standard score of the current fund payment request based on the fund payment request amount, the mean amount of payments of the same type, and the standard deviation of the payment amounts of the same type;

[0026] If it is determined that the absolute value of the standard score is greater than a second preset threshold, it is determined that there is a risk in the payment.

[0027] According to an embodiment of the present disclosure, calling a preset smart contract to perform a first verification on the fund payment request includes:

[0028] Determining whether the account funds of the fund payment request are less than a third preset threshold; and

[0029] Determine whether the transaction object is in the payment whitelist.

[0030] According to an embodiment of the present disclosure, performing a payment operation based on the second verification result includes:

[0031] After confirming that the second verification has passed, the payment review operation is performed;

[0032] If the payment review result is confirmed to be passed, the interface provided by the fund custody node is called to perform the payment operation.

[0033] According to an embodiment of the present disclosure, the method further includes:

[0034] In response to the information change operation, save the changed information on the chain; and

[0035] In response to the payment operation, the result of the funds payment request operation is saved on the chain.

[0036] A second aspect of the present disclosure provides a blockchain-based project fund supervision system, wherein the blockchain includes multiple nodes, the nodes including at least a supervisory node, a fund escrow node, a project construction agent node, a project owner node, and a project owner representative node. The system includes:

[0037] A first payment verification module is configured to, in response to a funds payment request operation, call a preset smart contract to perform a first verification on the funds payment request;

[0038] A second payment verification module, configured to call a preset risk identification model to perform a second verification on the funds payment request after the first verification passes; and

[0039] a payment module, configured to perform a payment operation based on the second verification result,

[0040] Among them, the preset risk identification model includes a payment risk warning model and an account anomaly identification model. The payment risk warning model is implemented based on the standard score algorithm, and the account anomaly identification model is pre-trained based on the isolation forest algorithm and historical payment data.

[0041] According to an embodiment of the present disclosure, the second payment verification module includes a payment risk identification submodule, an account anomaly identification submodule and a first determination submodule.

[0042] The payment risk identification submodule is used to input the fund payment request information into the payment risk early warning model to output the payment risk result;

[0043] An account anomaly identification submodule, configured to input the funds payment request information into an account anomaly identification model to identify the account status result; and

[0044] The first determination submodule is configured to determine a second verification result based on the payment risk result and the account status result.

[0045] According to an embodiment of the present disclosure, the system further includes a model training module, which is used to pre-train an account anomaly recognition model based on an isolation forest algorithm and historical payment data.

[0046] According to an embodiment of the present disclosure, the model training module includes a training sample generation submodule, a segmentation point determination submodule, a segmentation submodule and a loop submodule.

[0047] A training sample generation submodule is used to randomly select a certain number of samples from the historical payment data as training data samples, and randomly select n instances from the training data samples as a subsample set, where n is a positive integer;

[0048] a split point determination submodule, configured to randomly specify payment sample attributes from a list of attributes in the subsample set and randomly determine a split point based on the payment sample attributes;

[0049] A segmentation submodule, configured to perform left-right branch segmentation on the subsample set based on the segmentation point;

[0050] The loop submodule is used to recursively perform the above operations on the left and right branches respectively until the number of nodes is less than or equal to 1 or the height of the entire tree reaches a preset threshold; and repeat the isolation tree construction step a preset number of times to generate an isolation forest to obtain an account anomaly recognition model.

[0051] According to an embodiment of the present disclosure, the account anomaly identification submodule includes: a first determination unit, an anomaly score calculation unit, and a second determination unit.

[0052] A first determining unit, configured to determine a payment stage category according to the funds payment request information;

[0053] an anomaly score calculation unit, configured to calculate an anomaly score of a data point to be identified based on the isolation forest corresponding to the payment stage category;

[0054] The second determining unit is configured to determine that the account status corresponding to the to-be-identified data point is abnormal if it is determined that the abnormality score is greater than a first preset threshold.

[0055] According to an embodiment of the present disclosure, the payment risk identification submodule includes: a third determination unit and a fourth determination unit.

[0056] a third determining unit, configured to determine a standard score for the current funds payment request based on the funds payment request amount, the mean of the same type of payment amounts, and the standard deviation of the same type of payment amounts; and

[0057] The fourth determining unit is configured to determine that there is a risk in the payment if it is determined that the absolute value of the standard score is greater than a second preset threshold.

[0058] According to an embodiment of the present disclosure, the first payment verification module includes a first judgment submodule and a second judgment submodule.

[0059] A first judgment submodule is configured to judge whether the account funds of the fund payment request are less than a third preset threshold; and

[0060] The second judgment submodule is used to judge whether the transaction object is in the payment whitelist.

[0061] According to an embodiment of the present disclosure, the payment module includes: a payment review submodule and a payment submodule.

[0062] A payment review submodule, configured to perform a payment review operation after determining that the second verification has passed; and

[0063] The payment module is used to call the interface provided by the fund custody node to perform payment operations if the payment review result is determined to be passed.

[0064] According to an embodiment of the present disclosure, the system further includes a data uplink module.

[0065] The data chain module is used to save the changed information on the chain in response to the information change operation; and to save the result of the fund payment request operation on the chain in response to the payment operation.

[0066] A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0067] The fourth aspect of the present disclosure further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0068] The fifth aspect of the present disclosure further provides a computer program product, comprising a computer program or instructions, which implement the steps of the above method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] The above contents and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0070] Figure 1 The following schematically shows an architecture diagram of a project fund supervision system according to an embodiment of the present disclosure;

[0071] Figure 2 A flowchart of a project fund supervision method according to an embodiment of the present disclosure is schematically shown;

[0072] Figure 3 A flowchart schematically illustrates a method for training an account anomaly recognition model according to an embodiment of the present disclosure;

[0073] Figure 4 A flowchart schematically illustrates a method for performing a second verification on the fund payment request by calling a preset risk identification model according to an embodiment of the present disclosure;

[0074] Figure 5 A schematic diagram of a structure of a project fund supervision device according to an embodiment of the present disclosure is shown; and

[0075] Figure 6 The block diagram schematically shows an electronic device suitable for implementing the project fund supervision method according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0076] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present disclosure. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0077] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0078] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0079] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0080] First, the terms that appear in the embodiments of the present disclosure are explained:

[0081] Blockchain: A distributed ledger technology that records and stores data in a decentralized manner. In the disclosed embodiments, it is used to provide a decentralized data storage and verification method across multiple nodes, ensuring data immutability and traceability.

[0082] Smart contracts are automated contracts deployed on a blockchain that automatically execute their terms when pre-set conditions are met. The smart contracts in this disclosure are used to perform a primary verification of payment requests, determining whether the account has sufficient funds and whether the transaction partner is on a whitelist.

[0083] Payment Risk Early Warning Model: This model, based on a standard score algorithm, is used to assess the risk of payment requests. It determines whether a payment is risky by calculating the standard score of the payment amount.

[0084] Account anomaly identification model: This model, pre-trained based on the Isolation Forest algorithm and historical payment data, is used to identify abnormal account status. It can detect whether an account has abnormal payment behavior or potential risks.

[0085] Isolation Forest Algorithm: An unsupervised anomaly detection algorithm that constructs multiple isolation trees to assess the degree of anomaly in a data point. In this disclosure, it is used to analyze account payment data and identify anomalous accounts.

[0086] Standard score algorithm: This algorithm calculates the distance of a data point from the mean relative to the standard deviation, measuring the relative position of a data point in a dataset. In this solution, it is used to calculate the standard score of the payment amount to determine whether the payment is risky.

[0087] Funds custody node: A node responsible for funds custody in a blockchain network, usually performed by professional institutions such as financial institutions, to ensure the safe storage and management of funds.

[0088] Project Owner Node: A blockchain node representing the project owner that can query and understand the usage of project funds and account status.

[0089] Project construction agent node: The blockchain node representing the project construction agent is responsible for submitting relevant payment applications and other operations during the project construction phase.

[0090] Supervisory node: A blockchain node responsible for supervising project funds, capable of reviewing and monitoring fund payment requests through smart contracts and risk identification models.

[0091] Based on the above technical problems, an embodiment of the present disclosure provides a project fund supervision method, which is applied to a blockchain-based supervision system, wherein the blockchain includes multiple nodes, and the nodes include at least a supervisory node, a fund custodian node, a project agent node, a project owner node and a project owner representative node. The method includes: in response to a fund payment request operation, calling a preset smart contract to perform a first verification on the fund payment request; after the first verification passes, calling a preset risk identification model to perform a second verification on the fund payment request; and performing a payment operation based on the second verification result, wherein the preset risk identification model includes a payment risk warning model and an account anomaly identification model, the payment risk warning model is implemented based on a standard score algorithm, and the account anomaly identification model is pre-trained based on an isolation forest algorithm and historical payment data.

[0092] Figure 1 The following schematically shows an architecture diagram of a project fund supervision system according to an embodiment of the present disclosure.

[0093] like Figure 1As shown, the project fund supervision system provided by the disclosed embodiment includes an account opening module, an SMS notification module, an abnormal account monitoring module, a payment module, an information change module, a detailed query module, a payment statistics module, and a blockchain query module. The payment module includes payment application, payment warning, and payment review; the information change module includes information changes for the construction agent, elevator owner, elevator owner representative, and payment whitelist. The supervision company can access the functions of these modules through the supervision company client; the construction agent, elevator owner, and elevator owner representative can query block information, corresponding elevator account details, and payment statistics for other similar accounts through personal clients. Some functions of this system rely on the SMS sending interface, transfer interface, detailed query interface, and balance query interface provided by the fund custodian. This system calls the fund custodian's interface through the intranet. The supervision company, fund custodian, construction agent, elevator owner, and elevator owner representative can form multiple nodes. The regulatory company is required to upload all operational information to the blockchain when opening accounts, making payment requests, and making information changes. The system automatically uploads balance changes upon detecting changes in account balances. Fund custodians are also required to upload the latest transaction status to the blockchain after performing operations such as transfers. Regulatory companies can query blockchain information through the regulatory company client; fund custodians can query blockchain information through the interface; and construction agents, elevator owners, and elevator owner representatives can query blockchain information through their personal clients.

[0094] The Account Opening Module updates the bank account previously opened by the supervisory company to "valid" status and stores the update on-chain. To avoid account confusion, this system adopts a "one elevator, one account" model, meaning each elevator has its own account. Elevator account numbers in this system can be divided into two types: those for the construction phase and those for the maintenance phase. The SMS Notification Module notifies the owner of the elevator via SMS when an account is opened, closed, an anomaly occurs, payment status changes, information changes, balance changes, or insufficient balance occurs. The Abnormal Account Monitoring Module uses the Isolation Forest algorithm to monitor the severity of anomalies in different accounts. The Payment Module is used for payment. Payment Alerts: The system automatically determines whether a payment is risky based on past similar payment data. Payment Application: When payment is required, the supervisory company applies for payment through the supervisory company client. The system automatically stores the payment application on-chain, which then passes through a pre-defined smart contract. The smart contract incorporates three risk control components: first, determining whether the account balance is below a preset threshold; second, determining whether the transaction partner is on a whitelist; and third, invoking the payment warning module and abnormal account monitoring module to determine if the account and the payment are at risk. Only after verification is successful will the payment review process proceed. Regardless of verification success or failure, the system automatically notifies the elevator owner of the verification results through a text message notification module. The elevator owner can request the regulatory company to suspend the payment request. If no elevator owner objects within three days, the payment will proceed to the payment review process. Payment Review: The regulatory company's financial personnel are responsible for manually reviewing the payment request, and the system automatically records the review process on-chain. The Information Modification Module is used to add, delete, and modify various information. The Detail Query Module is used to query the details of each elevator account. The Blockchain Query Module is used to query blockchain information. Sensitive information such as ID numbers, balances, and transaction accounts are encrypted, making them visible only to participants. The Payment Statistics Module is used to view payment statistics for similar elevator accounts.

[0095] Figure 1 The architecture diagram shown is only an example of a system architecture to which the embodiments of the present disclosure can be applied, to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in other devices, systems, environments or scenarios. It should be noted that the project fund supervision method and device determined in the present disclosure can be used in the financial field, and can also be used in any field other than the financial field. The application field of the method and device for project fund supervision determined in the present disclosure is not limited.

[0096] The following will be based on Figure 1 Describe the architecture by Figures 2 to 5 The project fund supervision method of the disclosed embodiment is described in detail.

[0097] Figure 2The flowchart of the project fund supervision method according to the embodiment of the present disclosure is schematically shown.

[0098] like Figure 2 As shown, the project fund supervision method of this embodiment includes operations S210 to S230, and the transaction processing method can be executed by a server or other computing devices.

[0099] In operation S210, in response to a funds payment request operation, a preset smart contract is called to perform a first verification on the funds payment request.

[0100] According to an embodiment of the present disclosure, calling a preset smart contract to perform a first verification on the fund payment request includes: determining whether the account funds of the fund payment request are less than a third preset threshold; and determining whether the transaction object is in the payment whitelist.

[0101] In one example, after a payment request is made, a pre-set smart contract performs a primary verification. Based on pre-set rules, the smart contract quickly determines the compliance of the payment request, such as checking for sufficient account balance and whether the transaction partner is on a whitelist. This step provides a preliminary screening of basic financial and transaction compliance, promptly intercepting payment requests that clearly violate regulations. This reduces the burden of subsequent, more complex risk assessments and improves overall process efficiency. When a maintenance company submits a payment request for an additional elevator, the request is sent to the monitoring system. The system automatically invokes a pre-set smart contract, which first checks whether the current balance in the elevator project account is sufficient to cover the maintenance costs and whether the maintenance company is on the project's payment whitelist. If the balance is sufficient and the maintenance company is on the whitelist, the primary verification passes. For example, if the balance in an elevator project account is 50,000 yuan and the maintenance cost is 3,000 yuan, the smart contract will check the account balance and the whitelist to confirm that the conditions are met, thus completing the primary verification.

[0102] In operation S220, after the first verification is passed, a preset risk identification model is called to perform a second verification on the fund payment request.

[0103] According to an embodiment of the present disclosure, the preset risk identification model includes a payment risk warning model and an account anomaly identification model. The payment risk warning model is implemented based on a standard score algorithm, and the account anomaly identification model is pre-trained based on an isolation forest algorithm and historical payment data.

[0104] In one example, for payment requests that pass the initial smart contract verification, a pre-set risk identification model is invoked for a second verification. This model comprises a payment risk warning model and an account anomaly identification model, which together provide a comprehensive assessment of payment risk and account status. The payment risk warning model, based on a standard score algorithm, accurately determines whether the current payment amount deviates from historical data for similar payments. The account anomaly identification model, leveraging a pre-trained isolation forest algorithm, uses historical payment data to identify potential anomaly patterns in the account. This dual verification mechanism effectively identifies payment risks and account anomalies, significantly enhancing the security of fund supervision and reducing the risk of abuse or misuse. Specifically, after the first verification passes, the system invokes the risk identification model. The payment risk warning model calculates a standard score for the 3,000 yuan maintenance fee. By analyzing historical data for similar maintenance payments (with a mean of 2,500 yuan and a standard deviation of 300 yuan), it arrives at a standard score of approximately 1.67. The account anomaly identification model uses the isolation forest algorithm, combined with historical payment data, to analyze the payment behavior patterns of the elevator project account and determine whether there are any anomalies. If the account's previous maintenance payment frequency and amount fluctuations are within the normal range, the account status is normal and the second verification is passed. Figure 4 Operations S221 to S223 are shown.

[0105] In operation S230, a payment operation is performed based on the second verification result.

[0106] According to an embodiment of the present disclosure, after determining that the second verification has passed, a payment review operation is performed; if the payment review result is determined to be passed, an interface provided by the fund custody node is called to perform a payment operation.

[0107] In one example, if the second verification result indicates low payment risk and normal account status, the system will send the maintenance fee payment request to the supervisor and project owner representative for review. If approved, the system invokes the payment interface of the fund escrow node to transfer the 3,000 yuan maintenance fee from the project account to the maintenance company account, recording the payment result on the blockchain, completing the payment operation. Simultaneously, the system sends a text message notification of the successful payment to the project owner and relevant supervisor. By introducing a payment review process, combining the flexibility of manual review with the automated assessment capabilities of smart contracts and risk identification models, a dual-security mechanism is formed. This facilitates a more comprehensive assessment of the legitimacy of payment requests, avoiding risks that could be overlooked due to the limitations of automated assessment models. It can also address payment needs in special circumstances or complex business scenarios.

[0108] According to the embodiments of the present disclosure, in response to information change operations, the change information is uploaded to the blockchain for storage; and in response to payment operations, the results of the fund payment request operation are uploaded to the blockchain for storage. By storing the results of information change operations and payment operations on the blockchain, the integrity and authenticity of all relevant information changes and payment operation records are ensured by leveraging the blockchain's immutable and traceable characteristics. This provides reliable data support for subsequent fund supervision, auditing, and dispute resolution, making it convenient for all parties to query and trace the use of funds and the history of changes in account status at any time, thereby enhancing the transparency and credibility of fund supervision.

[0109] The project fund supervision method provided by the disclosed embodiments achieves multi-party participation and collaboration in project fund supervision by constructing a blockchain network consisting of supervisor nodes, fund escrow nodes, project construction agent nodes, project owner nodes, and project owner representative nodes. All parties can share and verify fund information in real time, ensuring transparent fund flows. After a payment request is issued, a pre-set smart contract performs a primary verification. Based on pre-set rules, the smart contract quickly determines the compliance of the payment request, conducting preliminary screening based on basic fund and transaction compliance, and promptly intercepting payment requests that are clearly non-compliant. This reduces the burden of subsequent, more complex risk assessments and improves overall process efficiency. Payment requests that pass the initial smart contract verification are further verified using a pre-set risk identification model. This model includes a payment risk warning model and an account anomaly identification model, which, combined, provide an in-depth assessment of payment risk and account status. The payment risk warning model, based on a standard score algorithm, accurately determines whether the current payment amount deviates from historical data for similar payments. The account anomaly identification model leverages a pre-trained isolation forest algorithm to mine potential anomaly characteristics for accounts using historical payment data. This double verification mechanism effectively identifies payment risks and account anomalies, greatly enhances the security of fund supervision, and reduces the risk of fund abuse or misuse.

[0110] Figure 3 The flowchart of the training method of the account anomaly recognition model according to the embodiment of the present disclosure is schematically shown.

[0111] like Figure 3 As shown, it includes operations S310 to S350.

[0112] In operation S310 , a certain number of samples are randomly selected from the historical payment data as training data samples, and n instances are randomly selected from the training data samples as a subsample set, where n is a positive integer.

[0113] In operation S320 , a payment sample attribute is randomly assigned from the attribute list in the sub-sample set and a split point is randomly determined based on the payment sample attribute.

[0114] In one example, a certain number of samples are randomly selected from the historical payment data for installing an elevator in an existing multi-story residential building. This historical payment data includes various payment records during the construction and maintenance phases of the elevator installation, covering different categories, such as equipment procurement and installation, design fees, and maintenance expenses. These data instances contain various payment-related information for each account, such as the average payment amount for each category, payment frequency, and cumulative payment amount for each category over the past month. For example, suppose we select payment data from 100 elevator installation accounts as the data sample. Then, we randomly select data from 10 accounts to form a subsample set X. This subsample set X becomes the root node of the isolation tree. The purpose of selecting random subsamples is to better capture anomalies in the data during the subsequent construction process, as anomalies are often more easily isolated in the data space.

[0115] In an example, assume that Q is a list of attributes of X and a random attribute is assigned , then randomly select a split point p, whose value lies between the maximum and minimum values of attribute q. The attribute list Q here refers to the various characteristic attributes in the aforementioned account data instance, such as the average payment amount by category, the payment frequency by category, and the cumulative payment amount by category in the past month. Because different payment stages correspond to different attributes, for example, the payment categories in the maintenance stage are categorized as equipment procurement and installation, daily management expenses, energy consumption expenses, maintenance expenses, inspection and testing expenses, insurance expenses, and others; while the payment categories in the construction stage are categorized as equipment procurement and installation, design expenses, approval expenses, renovation expenses, management expenses, and others. The disclosed embodiment trains data examples from different payment stages to obtain corresponding isolation forests. By establishing isolation forest models for corresponding categories, dynamic risk assessment of account status can be achieved. This helps to promptly detect abnormal changes in accounts at different payment stages, further enhancing the risk warning capabilities of the funds supervision system. Assume that the average payment amount is selected as the attribute q of the current operation. Then, a split point p is randomly selected within the range of all values of this attribute in these account data. For example, if the maximum value of the attribute in the subsample set X is 10,000 yuan and the minimum value is 500 yuan, then the randomly selected split point p may be 3,000 yuan. The role of this split point is to divide the data sample into different branches to facilitate the subsequent isolation process.

[0116] In operation S330 , the subsample set is segmented into left and right branches based on the segmentation point.

[0117] In an example, for each account data instance in the subsample set X, if its average payment amount is less than 3,000 yuan, it will be divided into the left branch X_left If it is greater than or equal to 3,000 yuan, it will be divided into the right branch X _right In this way, the data sample is divided into two parts based on the selected attributes and split points. The purpose of this step is to gradually distinguish normal points from abnormal points by continuously splitting the data. Because abnormal points are usually relatively isolated in the data space, they can be separated after fewer splitting steps.

[0118] In operation S340 , the above operations are recursively performed on the left and right branches respectively until the number of nodes is less than or equal to 1 or the height of the entire tree reaches a preset threshold.

[0119] In operation S350 , the isolation tree construction step is repeated a preset number of times to generate an isolation forest to obtain an account anomaly recognition model.

[0120] In an example, for the left branch X just divided _left and right branch X _right , continue to repeat the above attribute selection and split point selection process. For example, for X _left , another attribute is randomly selected—for example, average payment amount, payment frequency, or another attribute—and a split point is randomly selected for that attribute to continue splitting the data. This process continues until the number of data instances in a branch is less than or equal to 1, or the tree reaches a preset maximum height. This maximum can be set based on actual needs and data characteristics to control tree complexity and computational effort. Through this recursive splitting, a complete isolation tree is constructed. To improve the accuracy and stability of the algorithm, multiple isolation trees are constructed to form an isolation forest. For example, if the preset number t is 100, the above steps are repeated 100 times, each time randomly selecting a different subsample set X from the original data sample to construct an isolation tree. Ultimately, an isolation forest containing 100 isolation trees is formed. When performing anomaly detection on new data, the judgments of multiple isolation trees can be combined to obtain more reliable anomaly scoring results.

[0121] Figure 4 The flowchart of the method for calling a preset risk identification model to perform a second verification on the fund payment request according to an embodiment of the present disclosure is schematically shown.

[0122] like Figure 4 As shown, operation S220 includes operations S221 to S223.

[0123] In operation S221 , the fund payment request information is input into a payment risk early warning model to output a payment risk result.

[0124] According to an embodiment of the present disclosure, the standard score of the current fund payment request is determined based on the fund payment request amount, the average of the same type of payment amounts and the standard deviation of the same type of payment amounts; and if it is determined that the absolute value of the standard score is greater than a second preset threshold, it is determined that there is a risk in the payment.

[0125] In an example, the standard score corresponding to the current payment request amount is calculated according to the following standard score calculation formula:

[0126]

[0127] Where x is the amount of the payment, μ is the mean of the same type of payment, and σ is the standard deviation of the same type of payment. In the embodiment of the present disclosure, the second preset threshold value may be 2, for example. When the absolute value of z is greater than 2, the payment will be marked as possibly abnormal. By calculating the standard score of the amount of the fund payment request, the payment amount is compared with the mean and standard deviation of the same type of payment to quantitatively assess the payment risk. The risk assessment method based on the standard score algorithm can objectively and accurately measure the relative risk level of the payment request, providing a scientific basis for payment risk warning.

[0128] In operation S222, the fund payment request information is input into an account abnormality identification model to identify an account status result.

[0129] In operation S223 , a second verification result is determined based on the payment risk result and the account status result.

[0130] According to an embodiment of the present disclosure, the fund payment request information is input into the account anomaly identification model to identify the account status result, including: determining the payment stage category based on the fund payment request information; calculating the anomaly score of the data point to be identified based on the isolation forest corresponding to the payment stage category; if it is determined that the anomaly score is greater than a first preset threshold, it is determined that the account status corresponding to the data point to be identified is abnormal.

[0131] In an example, for an isolated forest with n instances, the average path length to find an outer node is :

[0132]

[0133] in

[0134] The degree of abnormality of each instance can be calculated using anomaly score express:

[0135]

[0136] in is the depth of the instance in each isolated tree, Isolated in the woods The average value of .

[0137] The closer the anomaly score is to 1, the more abnormal the instance is; conversely, the closer the anomaly score is to 0, the more normal the instance is; if the anomaly score of all instances is close to 0.5, then it can be considered that there are no abnormal instances. In the embodiment of the present disclosure, the first preset threshold can be, for example, 0.7, that is, when the anomaly score is greater than or equal to 0.7, it will be marked as a possible anomaly. If it is confirmed that the current payment is risk-free and the account status is normal, the second verification is determined to have passed; otherwise, it is considered to have failed.

[0138] Users can view the payment statistics of the same type of elevator account: To ensure the privacy of payments of other elevator accounts, the differential privacy method is used to add random noise to the statistical results. The distribution of random noise conforms to the Laplace distribution. The Laplace probability density function is:

[0139]

[0140] Where μ is the location parameter and λ is the scale parameter; the expectation of the Laplace distribution is μ and the variance is .

[0141] Based on the above project fund supervision method, the present disclosure also provides a project fund supervision system based on blockchain. Figure 5 The device is described in detail.

[0142] Figure 5 The structural block diagram of the project fund supervision device according to an embodiment of the present disclosure is schematically shown.

[0143] like Figure 5 As shown, the project fund supervision device 500 of this embodiment includes a first payment verification module 510 , a second payment verification module 520 and a payment module 530 .

[0144] The first payment verification module 510 is used to call a preset smart contract to perform a first verification on the fund payment request in response to the fund payment request operation. In one embodiment, the first payment verification module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0145] The second payment verification module 520 is used to call a preset risk identification model to perform a second verification on the fund payment request after the first verification passes. In one embodiment, the second payment verification module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0146] The payment module 530 is used to perform a payment operation based on the second verification result. In one embodiment, the payment module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0147] According to an embodiment of the present disclosure, the second payment verification module includes a payment risk identification submodule, an account anomaly identification submodule and a first determination submodule.

[0148] The payment risk identification submodule is used to input the fund payment request information into the payment risk early warning model to output the payment risk result;

[0149] An account anomaly identification submodule, configured to input the funds payment request information into an account anomaly identification model to identify the account status result; and

[0150] The first determination submodule is configured to determine a second verification result based on the payment risk result and the account status result.

[0151] According to an embodiment of the present disclosure, the system further includes a model training module, which is used to pre-train an account anomaly recognition model based on an isolation forest algorithm and historical payment data.

[0152] According to an embodiment of the present disclosure, the model training module includes a training sample generation submodule, a segmentation point determination submodule, a segmentation submodule and a loop submodule.

[0153] A training sample generation submodule is used to randomly select a certain number of samples from the historical payment data as training data samples, and randomly select n instances from the training data samples as a subsample set, where n is a positive integer;

[0154] a split point determination submodule, configured to randomly specify payment sample attributes from a list of attributes in the subsample set and randomly determine a split point based on the payment sample attributes;

[0155] A segmentation submodule, configured to perform left-right branch segmentation on the subsample set based on the segmentation point;

[0156] The loop submodule is used to recursively perform the above operations on the left and right branches respectively until the number of nodes is less than or equal to 1 or the height of the entire tree reaches a preset threshold; and repeat the isolation tree construction step a preset number of times to generate an isolation forest to obtain an account anomaly recognition model.

[0157] According to an embodiment of the present disclosure, the account anomaly identification submodule includes: a first determination unit, an anomaly score calculation unit, and a second determination unit.

[0158] A first determining unit, configured to determine a payment stage category according to the funds payment request information;

[0159] an anomaly score calculation unit, configured to calculate an anomaly score of a data point to be identified based on the isolation forest corresponding to the payment stage category;

[0160] The second determining unit is configured to determine that the account status corresponding to the to-be-identified data point is abnormal if it is determined that the abnormality score is greater than a first preset threshold.

[0161] According to an embodiment of the present disclosure, the payment risk identification submodule includes: a third determination unit and a fourth determination unit.

[0162] a third determining unit, configured to determine a standard score for the current funds payment request based on the funds payment request amount, the mean of the same type of payment amounts, and the standard deviation of the same type of payment amounts; and

[0163] The fourth determining unit is configured to determine that there is a risk in the payment if it is determined that the absolute value of the standard score is greater than a second preset threshold.

[0164] According to an embodiment of the present disclosure, the first payment verification module includes a first judgment submodule and a second judgment submodule.

[0165] A first judgment submodule is configured to judge whether the account funds of the fund payment request are less than a third preset threshold; and

[0166] The second judgment submodule is used to judge whether the transaction object is in the payment whitelist.

[0167] According to an embodiment of the present disclosure, the payment module includes: a payment review submodule and a payment submodule.

[0168] A payment review submodule, configured to perform a payment review operation after determining that the second verification has passed; and

[0169] The payment module is used to call the interface provided by the fund custody node to perform payment operations if the payment review result is determined to be passed.

[0170] According to an embodiment of the present disclosure, the system further includes a data uplink module.

[0171] The data chain module is used to save the changed information on the chain in response to the information change operation; and to save the result of the fund payment request operation on the chain in response to the payment operation.

[0172] According to embodiments of the present disclosure, any multiple modules among the first payment verification module 510, the second payment verification module 520, and the payment module 530 may be combined into a single module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of the present disclosure, at least one of the first payment verification module 510, the second payment verification module 520, and the payment module 530 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or implemented in any one of software, hardware, and firmware, or any suitable combination thereof. Alternatively, at least one of the first payment verification module 510, the second payment verification module 520, and the payment module 530 may be at least partially implemented as a computer program module that, when executed, performs the corresponding functionality.

[0173] Figure 6 The block diagram schematically shows an electronic device suitable for implementing the project fund supervision method according to an embodiment of the present disclosure.

[0174] like Figure 6 As shown, the electronic device 900 according to an embodiment of the present disclosure includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage unit 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present disclosure.

[0175] Various programs and data required for the operation of the electronic device 900 are stored in the RAM 903. The processor 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. The processor 901 executes the various operations of the method flow according to the embodiment of the present disclosure by executing the programs in the ROM 902 and / or the RAM 903. It should be noted that the programs may also be stored in one or more memories other than the ROM 902 and the RAM 903. The processor 901 may also execute the various operations of the method flow according to the embodiment of the present disclosure by executing the programs stored in the one or more memories.

[0176] According to an embodiment of the present disclosure, electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to bus 904. Electronic device 900 may also include one or more of the following components connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 908 including a hard disk; and a communication section 909 including a network interface card such as a LAN card or modem. Communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 910 as needed, so that computer programs read from the removable media can be installed into storage section 908 as needed.

[0177] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently without being incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the project fund supervision method according to the embodiments of the present disclosure.

[0178] According to an embodiment of the present disclosure, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but is not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present disclosure, a computer-readable storage medium may include the ROM 902 and / or RAM 903 described above, and / or one or more memories other than ROM 902 and RAM 903.

[0179] The embodiments of the present disclosure also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is executed in a computer system, the program code is used to cause the computer system to implement the project fund supervision method provided by the embodiments of the present disclosure.

[0180] The computer program executes the above functions defined in the system / device of the embodiment of the present disclosure when the processor 901 executes the computer program. According to the embodiment of the present disclosure, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0181] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 909, and / or installed from a removable medium 911. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0182] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from a removable medium 911. When the computer program is executed by the processor 901, the above-described functions defined in the system of the embodiment of the present disclosure are performed. According to the embodiment of the present disclosure, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0183] According to an embodiment of the present disclosure, the program code for executing the computer program provided by the embodiment of the present disclosure can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0184] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0185] Those skilled in the art will appreciate that the features described in the various embodiments of the present disclosure may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in the present disclosure. In particular, the features described in the various embodiments of the present disclosure may be combined and / or coupled in various ways without departing from the spirit and teachings of the present disclosure. All such combinations and / or couplings fall within the scope of the present disclosure.

[0186] The above describes the embodiments of the present disclosure. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present disclosure, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A project fund supervision method, characterized in that: Applied to a blockchain-based regulatory system, the blockchain includes multiple nodes, the nodes including at least a regulatory node, a fund escrow node, a project construction agent node, a project owner node, and a project owner representative node, the method includes: In response to a funds payment request operation, calling a preset smart contract to perform a first verification on the funds payment request; After the first verification passes, calling a preset risk identification model to perform a second verification on the fund payment request; and Perform a payment operation based on the second verification result, Among them, the preset risk identification model includes a payment risk warning model and an account anomaly identification model. The payment risk warning model is implemented based on the standard score algorithm, and the account anomaly identification model is pre-trained based on the isolation forest algorithm and historical payment data.

2. The method according to claim 1, characterized in that The calling of a preset risk identification model to perform a second verification on the fund payment request includes: Input the fund payment request information into the payment risk early warning model to output the payment risk result; Inputting the funds payment request information into the account anomaly identification model to identify the account status result; and A second verification result is determined based on the payment risk result and the account status result.

3. The method according to claim 2, characterized in that The account anomaly recognition model is pre-trained based on the isolation forest algorithm and historical payment data, including: Randomly select a certain number of samples from the historical payment data as training data samples, and randomly select n instances from the training data samples as a subsample set, where n is a positive integer; Randomly assigning a payment sample attribute from a list of attributes in the subsample set and randomly determining a split point based on the payment sample attribute; Performing left and right branch segmentation on the subsample set based on the segmentation point; Repeat the above operations for the left and right branches respectively until the number of nodes is less than or equal to 1 or the height of the entire tree reaches the preset threshold; and Repeat the isolation tree construction step a preset number of times to generate an isolation forest to obtain an account anomaly recognition model.

4. The method according to claim 2, characterized in that Inputting the fund payment request information into the account anomaly identification model to identify the account status result includes: Determine the payment stage category based on the fund payment request information; Calculating anomaly scores of the data points to be identified based on the isolation forest corresponding to the payment stage category; If it is determined that the anomaly score is greater than a first preset threshold, it is determined that the account status corresponding to the to-be-identified data point is abnormal.

5. The method according to claim 2, characterized in that Inputting the fund payment request information into the payment risk early warning model to output the payment risk result includes: Determine a standard score for the current funds payment request based on the funds payment request amount, the mean amount of similar payments, and the standard deviation of similar payments; and If it is determined that the absolute value of the standard score is greater than a second preset threshold, it is determined that there is a risk in the payment.

6. The method according to claim 1, characterized in that The calling of a preset smart contract to perform a first verification on the fund payment request includes: Determining whether the account funds of the fund payment request are less than a third preset threshold; and Determine whether the transaction object is in the payment whitelist.

7. The method according to claim 1, characterized in that The performing a payment operation based on the second verification result includes: After determining that the second verification has passed, performing a payment review operation; and If the payment review result is confirmed to be passed, the interface provided by the fund custody node is called to perform the payment operation.

8. The method according to any one of claims 1 to 7, characterized in that The method further comprises: In response to the information change operation, save the changed information on the chain; and In response to the payment operation, the result of the funds payment request operation is saved on the chain.

9. A blockchain-based project fund supervision system, characterized by: The blockchain includes multiple nodes, including at least a supervisory node, a fund custodian node, a project construction agent node, a project owner node, and a project owner representative node. The system includes: A first payment verification module is configured to, in response to a funds payment request operation, call a preset smart contract to perform a first verification on the funds payment request; A second payment verification module, configured to call a preset risk identification model to perform a second verification on the funds payment request after the first verification passes; and a payment module, configured to perform a payment operation based on the second verification result, Among them, the preset risk identification model includes a payment risk warning model and an account anomaly identification model. The payment risk warning model is implemented based on the standard score algorithm, and the account anomaly identification model is pre-trained based on the isolation forest algorithm and historical payment data.

10. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

12. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images