A transaction robot automatic scheduling decision method and a cloud management system

Abstract

The application discloses a kind of transaction robot automatic scheduling decision method and cloud management system.The decision method includes: calling the transaction business original data of transaction robot, and the original data is processed flow regularity and generates transaction association graph;According to transaction association graph, identify transaction business type, fill in corresponding business form according to business type, compare multiple versions of declaration materials based on business form, to mark modification area, generate preliminary examination message;According to preliminary examination message, measure transaction risk index, output risk alarm signal;Transaction association graph, preliminary examination message and risk alarm information are attached operation time stamp, and are encrypted and stored in trusted evidence account book.The scheme can realize the real-time linkage of each link data, feature mutual feedback and autonomous decision scheduling.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, specifically to an automated scheduling and decision-making method for trading robots and a cloud management system. Background Technology

[0002] Most automated processing solutions for trading robots adopt a segmented, independent processing architecture, which can only perform separate, mechanized execution of business processes such as transaction data collection, form filling, risk verification, and data storage. There is a lack of standardized data signal transmission and linkage scheduling mechanisms between the various processing processes, and a closed-loop automated decision-making logic has not been formed, which has become a core technical challenge restricting intelligent transaction processing.

[0003] The current conventional solution is to execute each business process step by step through fixed program scripts, or to rely on manual intervention to connect the preceding and following business links to complete the entire transaction processing work. However, this conventional approach can only ensure that the process runs in sequence, and it is difficult to achieve real-time linkage of data, feature feedback and autonomous decision-making scheduling between the links. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an automated scheduling and decision-making method for trading robots, which enables real-time data linkage, feature feedback, and autonomous decision-making and scheduling across all stages.

[0005] This application provides an automated scheduling decision-making method for trading robots, the decision-making method comprising: Retrieve the original transaction data of the transaction robot, and organize the original data into a transaction association graph. The transaction business type is identified based on the transaction association graph, the corresponding business form is filled in according to the business type, and multiple versions of the application materials are compared based on the business form. Modification areas are marked, and a preliminary review message is generated. Calculate transaction risk indicators based on the initial review message and output risk warning signals; The transaction association graph, the preliminary review message, and the risk alarm information are appended with operation timestamps and encrypted and stored in a trusted evidence ledger.

[0006] In one aspect, the step of streamlining the original data to generate a transaction association graph includes: Based on the original data, field extraction, missing value completion, and duplicate entity deduplication are performed, and the cleaned entity element signal is output. Based on the entity element signals, the transaction entity, transaction target and intermediary entity are identified, implicit relationships such as equity, entrustment, guarantee and cooperation between entities are explored, and entity relationship matching signals are output; Based on the entity association pairing signals, entity elements are mapped to graph nodes, and various association relationships are mapped to graph edges to construct a transaction association graph.

[0007] In one aspect, after the step of streamlining the original data to generate a transaction association graph, the method further includes: Incremental learning and updates are performed on the transaction association graph based on historical transaction graph samples to correct outdated and invalid association links within the transaction association graph.

[0008] In one aspect, the step of identifying the transaction business type based on the transaction association graph includes: Read the composite characteristics of the asset ownership attributes and transaction consideration payment mode of the transaction association graph; The composite features are input into a preset multi-level business classification model, matched with the classification standards for property rights transfer, capital increase and share expansion, bidding and procurement and rural asset transfer, and the corresponding transaction business type is output.

[0009] In one aspect, after the step of filling in the corresponding business form according to the business type, the method further includes: Based on the business form, the legal and regulatory knowledge base of the corresponding business category is retrieved, and the legal constraints are output. The form data is then compared and calculated field by field with the legal constraints, and the compliance differences of the form are output. Based on the form compliance differences, identify compliance defects in the form and generate rectification prompts.

[0010] In one aspect, the step of comparing the marked modification areas of multiple versions of application materials based on the business form includes: Based on the business form, the required and optional fields are distinguished. The required and optional fields are compared segment by segment, and traceable modification marks are generated for the differences in the required fields.

[0011] In one aspect, after the step of generating the initial review message, the following is also included: Extract key transaction elements from the initial review message, and construct a demand feature vector based on the key transaction elements; Based on the aforementioned demand feature vector, retrieve historical investment categories, investable amounts, and risk tolerance thresholds of existing investors; Perform feature matching to generate target recommendation clues with labeled matching weight scores.

[0012] In one aspect, the steps for calculating transaction risk indicators based on the aforementioned preliminary review message include: Extract the application text, entity qualification, and quotation information from the preliminary review message and output the message feature signal; Based on the message feature signals, external entity static credit records and multi-round dynamic fluctuation data of quotations are retrieved, and text similarity coefficient signals, entity association risk coefficient signals and quotation deviation coefficient signals are output respectively. Based on the text similarity coefficient signal, the subject association risk coefficient signal, and the price deviation coefficient signal, a weighted calculation is performed using preset weight parameters to obtain the transaction composite risk score signal. The corresponding trading risk index is obtained by comparing the composite risk score signal of the transaction with the preset score range.

[0013] In one aspect, after the step of outputting a risk alarm signal, the following is also included: Retrieve similar historical risk handling cases from the database, match the current alarm level, and push corresponding standardized handling guidelines.

[0014] To address the aforementioned problems, this application provides a cloud management system, which includes: The module is used to retrieve the original transaction data of the transaction robot, and to process the original data to generate a transaction association graph. The comparison module is used to identify the transaction business type based on the transaction association graph, fill in the corresponding business form according to the business type, compare multiple versions of the application materials based on the business form, mark the modified areas, and generate a preliminary review message. The calculation module is used to calculate transaction risk indicators based on the preliminary review message and output risk alarm signals; The evidence storage module is used to attach operation timestamps to the transaction association graph, the preliminary review message and the risk alarm information, and encrypt and store them in a trusted evidence storage ledger.

[0015] The beneficial effects of this invention are as follows: the transaction association graph after the original data is normalized is used for business type identification; the preliminary review message formed after the business form is processed is used for risk indicator calculation; each link carries out the next calculation based on the previous output data; a data linkage and feature feedback path is formed within the process; and each link can be autonomously scheduled and promoted by relying on the data transmission relationship of the process itself, without the need for additional manual connection or independent script segmented isolation operation. Thus, real-time linkage, feature feedback and autonomous decision-making scheduling of data in each link are realized. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0017] Figure 1This is a schematic diagram illustrating the process steps of the automated scheduling and decision-making method for trading robots in this application; Figure 2 This is a schematic diagram of the functional modules of the cloud management system of this application. Detailed Implementation

[0018] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are merely illustrative of the technical solution of the present invention and are therefore intended to limit the scope of protection of the present invention.

[0019] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0020] like Figure 1 As shown, this application provides an automated scheduling decision-making method for trading robots, the decision-making method including: Step S10 involves retrieving the original transaction data from the transaction robot and streamlining the data to generate a transaction relationship graph. The original transaction data refers to various basic business documents generated during the transaction process, including property transfer application materials, project bidding application documents, rural asset transfer registration forms, and written materials on enterprise equity changes. These documents can be in various formats, including electronic forms, scanned images and text, and online forms. The transaction robot continuously connects to the front-end business application portal, retrieving all pending original data in batches from the portal. The retrieval process is carried out sequentially according to the business submission time. Streamlining refers to standardizing the retrieved data and performing unified data processing operations, including standardizing field formats, removing duplicate records, and filling in missing basic information.

[0021] Step S20: Identify the transaction business type based on the transaction association graph, fill in the corresponding business form according to the business type, compare multiple versions of the application materials based on the business form, mark the modified areas, and generate a preliminary review report. The transaction business type refers to the business classification items for the transaction behavior, including four common business categories: property transfer, capital increase and share expansion, bidding and procurement, and rural asset transfer. Extract feature information from the transaction association graph, match the feature information with the preset business classification standards, and output the business type identifier corresponding to the current business after the matching is completed. The business form is a standardized filling template customized to different transaction businesses. Different business types correspond to independent form templates, and the form templates are set with various fields required for the corresponding business processing. After reading the business type identifier, retrieve the matched business form template, and fill in the basic field content of the form in combination with the entity data stored in the transaction association graph. Multiple versions of application materials refer to multiple rounds of filling documents submitted successively for the same transaction, and the content of the documents will vary as the application is adjusted. Historical versions of application materials are retrieved and compared item by item with the currently completed business forms. During the comparison process, discrepancies between the two documents are located, and identifiable markers are added at the corresponding locations to distinguish the modified areas. Calculations are performed based on the transaction relationship graph, eliminating the need for manual entry of basic business data. Business judgments and form processing are completed using the structured graph data output from previous steps, maintaining the continuity of data transfer within the process.

[0022] Step S30: Calculate transaction risk indicators based on the preliminary review message and output a risk alarm signal. Transaction risk indicators are quantitative reference values ​​used to reflect the potential risk level of a transaction. The risk alarm signal is a standardized data signal carrying the risk indicator value and transaction identifier, and it also carries information related to the risk level corresponding to the current transaction. After completing the indicator calculation, the corresponding risk alarm signal is output. This step uses the preliminary review message as the basis for calculation. The complete transaction information integrated from the message can support multi-dimensional risk value calculation. Autonomous risk assessment is completed based on the message data flowing within the process, eliminating the need for manual processing of transaction information before risk verification.

[0023] Step S40 involves attaching operation timestamps to the transaction association graph, preliminary review messages, and risk alarm information, and then encrypting and storing them in the trusted evidence storage ledger. The operation timestamp is an identifier recording the time of the current data processing action, including the year, month, day, hour, minute, and second corresponding to the action. Each set of data is bound to the same timestamp identifier. A symmetric encryption algorithm is used to encode and convert the three types of business data—graphs, messages, and alarm information. The encoded and converted data requires a matching decryption key to retrieve the original content. The trusted evidence storage ledger is a distributed storage data carrier. It stores the encrypted business data sequentially according to the data processing order, and retains the timestamp identifier and encrypted encoding content corresponding to each piece of data within the ledger.

[0024] In this embodiment, the transaction association graph after the original data is normalized is used for business type identification, the preliminary review message formed after the business form is processed is used for risk indicator calculation, and each link carries out the next calculation based on the previous output data, forming a data linkage and feature feedback path within the process. Relying on the data transmission relationship of the process itself, each link can be autonomously scheduled and promoted, eliminating the need for additional manual connection or independent script segmented isolation operation. This achieves real-time linkage of data, feature feedback and autonomous decision-making scheduling of each link.

[0025] In one embodiment of this application, the step of generating a transaction association graph by streamlining the original data includes: Step S110 involves performing field extraction, missing value completion, and duplicate entity deduplication on the original data, outputting a cleaned entity element signal. Field extraction refers to separating key information entries that represent transaction-related objects from the original data according to preset entity extraction rules. The preset entity extraction rules distinguish between subject-type fields, target-type fields, and intermediary-type fields for separate filtering and extraction. Missing value completion refers to filling in the corresponding blank content for entries with blank content in the extracted fields by retrieving the corresponding filing data of the same batch of business, and performing supplementary operations by matching publicly available filing information within the business scope. Duplicate entity deduplication refers to comparing different text records that refer to the same transaction object in multiple fields, unifying the entity naming format, and merging duplicated entity information of the same type. The entity element signal is a standardized data stream of cleaned entity basic information without redundancy or missing information.

[0026] Step S120 identifies the transaction entity, transaction target, and intermediary entity based on entity element signals, uncovers implicit relationships such as equity, entrustment, guarantee, and cooperation among entities, and outputs entity relationship matching signals. The transaction entity refers to a corporate legal person or natural person participating in the asset transfer or acquisition; the transaction target refers to the equity, real estate, business projects, and other assets transferred in this transaction; the intermediary refers to a third-party service unit providing transaction authentication, asset appraisal, and bidding agency services. These three types of entities together constitute the entire entity scope in the transaction scenario. The standardized entity information stored within the entity element signals is analyzed, and the three independent entity objects—transaction entity, transaction target, and intermediary—are identified according to entity attribute tags. Implicit relationships refer to business connections not directly stated in a single original document but deduced through cross-comparison of multiple fields. Equity relationships represent shareholding and control relationships between enterprises; entrustment relationships represent authorized agency business relationships; guarantee relationships represent debt repayment guarantee relationships; and cooperation relationships represent long-term business collaboration relationships.

[0027] Step S130: Based on entity relationship pairing signals, entity elements are mapped to graph nodes, and various relationships are mapped to graph edges, constructing a transaction relationship graph. Graph nodes are units within the transaction relationship graph used to carry complete information about a single entity. Each node uniquely corresponds to a set of cleaned and standardized entity elements, storing all attribute content such as entity name, entity type, and basic qualifications. Graph edges are connection carriers within the transaction relationship graph used to connect two nodes. Each graph edge is bound to a specific relationship, and the edge's identifier field records the relationship type information corresponding to equity, entrustment, guarantee, and cooperation. After completing node creation and edge connection operations, all nodes and graph edges combine to form a complete transaction relationship graph. The transaction relationship graph records all entity objects in this transaction scenario and various implicit business relationships between entities.

[0028] In one embodiment of this application, after the step of generating a transaction association graph by streamlining the original data, the method further includes: Step S11 involves incrementally learning and updating the transaction association graph based on historical transaction graph samples to correct outdated and invalid association links within the graph. Historical transaction graph samples refer to multiple sets of transaction association graphs generated and documented from completed transactions. These samples retain the entity nodes, various association edges, and corresponding transaction completion times for each historical transaction. Incremental learning and updating refers to a process that does not completely reconstruct the entire transaction association graph but only retrieves valuable entity attributes and association change information from historical transaction graph samples to perform localized data iteration and adjustments to the current transaction association graph. Outdated and invalid association links refer to entity association edges recorded within the graph where the status of equity, entrustment, guarantee, or cooperation related to the entity association has changed, and the original association content no longer matches the entity's current actual business relationship. After incremental learning and updating, the transaction association graph ensures that the association links between entities accurately reflect the current actual business interactions of the entities. The entity association information output by the transaction association graph to subsequent business identification stages has stronger scenario adaptability, reducing data deviations caused by outdated historical association information.

[0029] In one embodiment of this application, the step of identifying the transaction business type based on the transaction association graph includes: Step S210 involves reading the composite features of asset ownership attributes and transaction consideration payment modes from the transaction association graph. Asset ownership attributes are the descriptive information related to the entity's supporting assets stored within the graph nodes, including details such as the asset ownership entity, asset possession form, and asset disposal rights. Different transaction target nodes will carry differentiated ownership records. The transaction consideration payment mode is the transaction fund settlement information recorded in the graph's associated edges, including details such as the fund payment stage, payment settlement carrier, and payment performance constraints. Composite features refer to the combined feature dataset formed by integrating the asset ownership attributes and transaction consideration payment modes extracted from a single graph. The dataset is uniformly packaged into a standardized data format recognizable by the model. The process involves traversing all target nodes and transaction associated edges within the transaction association graph, extracting ownership-related textual and numerical information, as well as consideration settlement-related records, by region, and then integrating and packaging the two types of extracted information to form composite features.

[0030] Step S220: Input the composite features into the preset multi-level business classification model, match them with the classification standards for property rights transfer, capital increase and share expansion, bidding and procurement, and rural asset transfer, and output the corresponding transaction business type. The multi-level business classification model is a hierarchical recognition and operation model that has been pre-trained and has fixed parameters. The multi-level business classification model performs feature comparison operations in a coarse-to-fine hierarchical order, with each level corresponding to a set of business differentiation judgment rules. Property rights transfer, capital increase and share expansion, bidding and procurement, and rural asset transfer are four preset basic transaction business classification standards, each with its own exclusive ownership feature range and consideration mode matching threshold. The hierarchical automatic judgment is completed based on unified composite feature data, and the business type is distinguished based on the preset classification standards. There is no need for manual comparison of map information to determine the business category, and the output standardized business identifier can be used in the form filling process.

[0031] In one embodiment of this application, after the step of filling in the corresponding business form according to the business type, the method further includes: Step S21 involves retrieving the corresponding legal and regulatory rules knowledge base based on the business form, outputting the legal constraints, and comparing the form data with the legal constraints field by field to output the compliance differences. The legal and regulatory rules knowledge base is a standardized rules database categorized and stored according to different transaction business categories. It contains regulatory provisions, mandatory reporting requirements, and data format specifications corresponding to various businesses such as property transfer, capital increase, bidding and procurement, and rural asset transfer. Each business category corresponds to a business type. The business type identifier bound to the business form is read, and all rules matching the category in the knowledge base are retrieved based on the identifier. The legal constraints are data specifications extracted from the knowledge base and adapted to each field in the current form. These constraints include detailed constraints such as mandatory field requirements, numerical value ranges, and essential elements of written materials. All extracted specifications are integrated and output as a structured legal constraint data stream. By accurately retrieving and adapting the legal standards according to the business category associated with the business form, and completing compliance checks field by field, various information showing discrepancies between the form and legal requirements is uniformly collected, providing complete data evidence for identifying compliance defects.

[0032] Step S22: Identify compliance defects in the forms based on compliance discrepancies and generate rectification prompts. Compliance defects refer to various filling issues in business forms that do not comply with the regulatory constraints of the corresponding business category. Compliance defects include blank required fields, values ​​exceeding the legal range, missing qualification materials, and content that does not conform to regulatory requirements, among other situations. Retrieve the corresponding regulatory rectification instructions from the knowledge base and generate targeted text prompts based on the form fields and violations corresponding to the discrepancies. Rectification prompts are standardized business prompts that bind the coordinates of abnormal fields, problem descriptions, and standardized filling requirements. These prompts can be directly attached to the corresponding abnormal area of ​​the business form for display. By locating various filling defects based on the deviations between the forms and regulations, clear and referable rectification guidance items are generated. Personnel can quickly grasp the content that needs to be adjusted and improved in the forms based on these items, reducing the manual effort of checking forms item by item against regulations.

[0033] In one embodiment of this application, the step of comparing and marking modification areas of multiple versions of application materials based on business forms includes: Step S230 involves differentiating between required and optional fields based on the business form. Each required and optional field is compared segment by segment, and traceable modification markers are generated for discrepancies in the required fields. The form's built-in field attribute tags are read, and the entire set of required and optional fields within the form is divided according to these tags. During the comparison process, locations where text, values, or options differ between the two documents are recorded. All identified discrepancies are categorized, and for discrepancies belonging to required fields, traceable modification markers carrying version numbers and the original text before and after modification are generated and attached to the corresponding discrepancy locations on the form. This step differentiates between fields with different attributes for hierarchical comparison, adding traceability markers for required fields with higher review weight. This facilitates subsequent business personnel in quickly locating changes affecting business compliance. The form's built-in field tags automatically complete field segmentation and discrepancy marking, reducing the workload of manually verifying materials line by line.

[0034] In one embodiment of this application, after the step of generating the preliminary examination message, the method further includes: Step S201: Extract key transaction elements from the preliminary review report and construct a demand feature vector based on these elements. Traverse all structured entries within the preliminary review report, filter out the corresponding content belonging to the key transaction elements, and perform standardized numerical conversion to unify the data representation of elements in different formats. The demand feature vector is a one-dimensional data sequence formed by combining multiple standardized sets of key transaction elements according to a fixed dimension. Each dimension of the demand feature vector corresponds to the quantified value of a type of key transaction element. Extract the core information required by investors from the integrated preliminary review report, uniformly quantify and encapsulate it into a standard vector format, providing a unified and dimensionally fixed input for subsequent investor data retrieval.

[0035] Step S202 involves retrieving historical investment categories, investable amounts, and risk tolerance thresholds of existing investors based on demand feature vectors. Historical investment categories record the types of business transactions an investor has participated in, including investment records related to property transfers, bidding and procurement, and asset circulation. Investable amounts are the investment range self-reported by the investor and confirmed through filing. Risk tolerance thresholds are the upper limit of the overall project risk that the investor can accept. These three types of information together constitute the basic data for investor matching. The retrieved investor matching data is then bound to the corresponding unique investor identifier, forming a grouped dataset that is transmitted to the downstream feature matching stage. This step completes targeted database retrieval based on standardized demand feature vectors, batch retrieving investor profile information relevant to the current transaction target, eliminating the need for manual screening of investor profiles one by one.

[0036] Step S203 involves conducting feature matching to generate target recommendation leads with weighted matching scores. Feature matching refers to comparing the transaction attributes of the target, carried by the demand feature vector, with the historical investment categories, investable amounts, and risk tolerance thresholds of a single existing investor. The matching weight score is a quantified value calculated based on the degree of fit of each feature. Different dimensions of transaction elements correspond to pre-set weight ratios; the higher the fit, the higher the score for the corresponding dimension. The weighted summation forms the total matching score. Target recommendation leads are standardized business push files that integrate basic target information, corresponding investor identification, and matching weight scores. These files are used to push suitable potential investment information to business processing terminals. The calculated scores, basic target information, and investor registration information are integrated and packaged to generate independent target recommendation leads. By quantifying the degree of fit through multi-dimensional feature weighted comparison, the scores intuitively distinguish the degree of fit between different investors and the current project, producing standardized recommendation leads for business personnel to refer to in selecting potential investors.

[0037] In one embodiment of this application, the step of calculating transaction risk indicators based on the preliminary examination message includes: Step S310 extracts the application text, entity qualifications, and quotation information from the preliminary review report and outputs the report feature signal. The application text refers to the written records describing the transaction plan, asset overview, and cooperation agreement. Entity qualifications refer to the operating licenses, ownership certificates, and registration documents corresponding to the transferor, transferee, and intermediary institutions. Quotation information refers to numerical content such as the project's listing price, the price offered by potential investors, and negotiation records. After information extraction and format standardization, the report feature signal is generated and transmitted externally. The basic information required for the three types of risk assessment is separated from the unified and integrated preliminary review report, converted into standardized signal form, and transmitted externally, providing unified and standardized data input for multi-dimensional risk item calculation.

[0038] Step S320 retrieves external entity static credit records and multi-round bid dynamic fluctuation data based on message feature signals, and outputs text similarity coefficient signals, entity association risk coefficient signals, and bid deviation coefficient signals respectively. External entity static credit records are stored in a third-party credit database, recording long-term fixed credit information such as historical performance records, public disclosure of defaults, and qualification validity status of each transaction entity. Multi-round bid dynamic fluctuation data is stored in a local business database, recording historical bid ranges for similar projects and the price change range of multiple bids for the current project. This step automatically retrieves supporting external data based on message feature signals, performs independent risk value calculations across dimensions, and outputs corresponding signals, breaking down the multi-dimensional risk judgment logic and reducing the data processing pressure of a single computational process.

[0039] Step S330: Based on the text similarity coefficient signal, the subject association risk coefficient signal, and the price deviation coefficient signal, a weighted calculation is performed using preset weight parameters to obtain the transaction composite risk score signal. The preset weight parameters are fixed percentage values ​​pre-configured according to the transaction business review rules, corresponding to the three risk coefficients: text similarity dimension, subject association risk dimension, and price deviation dimension. Different business types can be matched with appropriate combinations of weight parameters. The risk results of the three independent dimensions are integrated, and a comprehensive quantitative calculation is completed through preset weights to output a unified composite score signal, realizing the integrated and unified processing of multi-dimensional risk information.

[0040] Step S340: Based on the composite risk score signal of the transaction and comparing it with the preset score range, the corresponding transaction risk indicators are obtained. The preset score range consists of multiple numerical ranges pre-defined according to the business review and risk control requirements. Each numerical range corresponds to a risk level identifier, and the range division standard is adapted to the conventional review standards of various transaction scenarios such as property transfer and bidding procurement. The transaction risk indicator is a standardized identifier used to intuitively reflect the overall risk level of the project. The indicator can be used for subsequent risk alarm push, risk handling guidance matching, and other follow-up operations. Automated classification and judgment are completed based on a unified composite risk score. Standardized risk indicators are divided according to the preset range standard, eliminating the need for manual risk level determination by comparing risk values. The output of unified and standardized risk identifiers supports subsequent business handling throughout the entire process.

[0041] In one embodiment of this application, after the step of outputting a risk alarm signal, the method further includes: Step S31: Retrieve the historical risk management case library for similar projects, match the current alarm level, and push the corresponding standardized handling guidelines. The historical risk management case library is a persistently stored data set containing complete handling records of various risk events generated by completed transaction projects. Each case record is bound to corresponding historical alarm level, business type, handling operation process, review and rectification requirements, and other supporting information. Cases are classified and archived according to business category and risk level. Different indicator value ranges correspond to different alarm levels, and alarm level identifiers are used to distinguish the degree of business control strictness brought about by project risks. The standardized handling guidelines are standardized operation instructions extracted from historical cases. The guidelines include directly implementable business operation content such as material supplementation requirements, entity verification process, and price review key points. Based on the current project risk level, the appropriate operation guidelines are automatically retrieved. Personnel can directly refer to the pushed content to carry out risk rectification work, reducing the operational waste caused by manually reviewing historical files and sorting out handling plans.

[0042] like Figure 2 As shown, this application provides a cloud management system. Since the local computing power and storage resources of multiple front-end trading robots are limited, they cannot handle massive amounts of transaction data, classification models, regulatory knowledge bases, and historical cases. The cloud can centrally connect to all trading robots and uniformly collect multi-source raw data. The cloud management system includes: a construction module 10, a comparison module 20, a calculation module 30, and an evidence storage module 40.

[0043] Module 10 is used to retrieve the original transaction data of the transaction robot, and to generate a transaction association graph by streamlining the original data. Module 10 is a functional unit of the cloud management system responsible for parsing basic transaction data and building the graph. Module 10 continuously connects to the data transmission channel of the transaction robot, and reads original transaction data of various transactions such as property transfer and bidding procurement in batches from the channel. Module 10 internally incorporates three types of processing logic: data cleaning, entity association mining, and graph mapping. It sequentially performs field streamlining, entity recognition, and relationship mining operations on the original data. Based on the standardized entities and association information obtained after processing, it completes the automated construction of the transaction association graph. The transaction association graph produced by Module 10 is synchronously transmitted to the comparison module 20 in the system to provide structured data support for subsequent business classification and form processing. Module 10 completes the complete conversion of all original data into a visual association graph without the need for external units to perform intermediate data streamlining operations.

[0044] The comparison module 20 is used to identify the transaction business type based on the transaction association graph, fill in the corresponding business form according to the business type, compare multiple versions of the application materials based on the business form, mark the modified areas, and generate a preliminary review report. The comparison module 20 receives the transaction association graph output by the construction module 10 as the core calculation data source. The comparison module 20 has three built-in processing logics: business classification, automatic form filling, and comparison of multiple versions of materials. The comparison module 20 first analyzes the asset ownership and consideration payment characteristics carried by the graph to determine the corresponding transaction business type, and then matches the standardized form template of the corresponding business to complete the automatic content filling. The comparison module 20 retrieves the previous application materials of the same project and compares them with the current form item by item. For the content deviation of the required fields, it generates traceable modification marks. Finally, it integrates the form content and version modification marks to assemble the preliminary review report. The preliminary review report generated by the comparison module 20 is simultaneously sent to the calculation module 30 to carry out risk calculation. The entire business judgment and form processing process is completed autonomously by relying on the upstream graph data, reducing the operation steps of manual data entry and material verification.

[0045] The calculation module 30 is used to calculate transaction risk indicators based on the preliminary review message and output risk alarm signals. The calculation module 30 uses the preliminary review message transmitted by the comparison module 20 as the input carrier for risk calculation. The calculation module is used to integrate the entire set of processing logic, including message feature extraction, external credit data retrieval, multi-dimensional coefficient calculation, and risk level classification. The calculation module 30 first splits the declaration text, subject qualification, and quotation information from the preliminary review message and converts them into standardized message feature signals. Then, based on the signals, it retrieves external credit records and quotation fluctuation data to calculate multiple types of risk coefficients. Combined with preset weights, it completes weighted calculation to obtain a composite risk score. After classifying the corresponding transaction risk indicators according to the preset score range, it outputs risk alarm signals. The calculation module 30 uses the generated risk alarm signals to push them synchronously to the front-end business terminal and the evidence storage module. Based on the complete transaction information integrated from the preliminary review message, it realizes multi-dimensional risk autonomous quantitative calculation.

[0046] The evidence storage module 40 is used to attach operation timestamps to the transaction association graph, preliminary review messages, and risk alarm information, and then encrypt and store them in the trusted evidence storage ledger. The evidence storage module 40 receives three types of core business data: the transaction association graph output by the construction module, the preliminary review messages output by the comparison module 20, and the risk alarm information corresponding to the risk alarm signals output by the calculation module 30. The evidence storage module 40 has built-in timestamp binding, data encryption, and distributed ledger writing processing logic. The evidence storage module 40 first binds and records the operation timestamps of the processing time points for the entire set of business data in the same batch, then uses encryption algorithms to complete the encoding conversion processing of the graph, messages, and alarm information, and finally writes the encrypted data with attached timestamps into the trusted evidence storage ledger for persistent storage. The evidence storage module 40 uniformly collects the core business data generated in each stage of the entire transaction process, and retains the entire set of original transaction processing data completely according to the business processing time sequence, providing a complete evidence data source for business backtracking and data verification.

[0047] To further illustrate the technical solution of this application, the following example is provided: For a property transfer transaction where Company A transfers an industrial plant to Company C, handled by intermediary agency B, the cloud management system's construction module 10 first retrieves multiple sources of original data, including business registration documents, property ownership certificates, entrustment agreements, and quotation documents. After extracting fields, filling in missing information, and removing duplicate entities, it outputs entity element signals. Based on these signals, it identifies the transferor, transferee, plant target, and intermediary agency entities, and mines implicit relationships related to equity and entrustment. After outputting entity association pairing signals, it maps nodes and edges to build a transaction association graph. Then, it calls historical transaction graph samples to incrementally correct expired association links within the graph. The comparison module 20 reads the graph, extracts composite features of asset ownership and consideration payment, inputs them into a multi-level classification model to determine the business type as a property transfer, matches the corresponding business form to automatically fill in information, distinguishes between required and optional fields in the form, and compares them segment by segment with previous application materials. For differences in required fields, it generates traceable modification markers and integrates the information to form a preliminary review report. The system simultaneously retrieves regulatory knowledge base data, compares forms to output compliance discrepancies, and generates rectification prompts. It extracts key elements such as the target price, industry, and entity qualifications from the message to construct a demand feature vector. It retrieves data on existing investors' investment categories, funding amounts, and risk thresholds to complete feature matching and outputs factory recommendation leads with matching scores. The calculation module 30 parses the initial review message to generate message feature signals, retrieves external entity credit records and price fluctuation data of similar projects, calculates three types of coefficient signals: text similarity, entity association, and price deviation, and combines them with preset weights to obtain a composite risk score signal, classifies transaction risk indicators, and outputs risk alarm signals. It simultaneously retrieves historical risk cases to match alarm levels and pushes standardized handling guidelines. Finally, the evidence storage module 40 binds the aforementioned transaction association graph, initial review message, and risk alarm information to an operation timestamp, encrypts them, and stores them in a trusted evidence storage ledger. The entire process relies on standardized signals output sequentially by each stage to complete data linkage and autonomous scheduling, without requiring manual connection between each business processing stage.

[0048] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be included in the scope of the claims and specification of the present invention.

Claims

1. A method for automated scheduling and decision-making of trading robots, characterized in that, The decision-making methods include: Retrieve the original transaction data of the transaction robot, and organize the original data into a transaction association graph. The transaction business type is identified based on the transaction association graph, the corresponding business form is filled in according to the business type, and multiple versions of the application materials are compared based on the business form. Modification areas are marked, and a preliminary review message is generated. Calculate transaction risk indicators based on the initial review message and output risk warning signals; The transaction association graph, the preliminary review message, and the risk alarm information are appended with operation timestamps and encrypted and stored in a trusted evidence ledger.

2. The decision-making method according to claim 1, characterized in that, The steps of generating a transaction relationship graph by streamlining the original data include: Based on the original data, field extraction, missing value completion, and duplicate entity deduplication are performed, and the cleaned entity element signal is output. Based on the entity element signals, the transaction entity, transaction target and intermediary entity are identified, implicit relationships such as equity, entrustment, guarantee and cooperation between entities are explored, and entity relationship matching signals are output; Based on the entity association pairing signals, entity elements are mapped to graph nodes, and various association relationships are mapped to graph edges to construct a transaction association graph.

3. The decision-making method according to claim 1, characterized in that, After the step of organizing the original data to generate a transaction association graph, the method further includes: Incremental learning and updates are performed on the transaction association graph based on historical transaction graph samples to correct outdated and invalid association links within the transaction association graph.

4. The decision-making method according to claim 1, characterized in that, The steps for identifying transaction business types based on the transaction association graph include: Read the composite characteristics of the asset ownership attributes and transaction consideration payment mode of the transaction association map; The composite features are input into a preset multi-level business classification model, matched with the classification standards for property rights transfer, capital increase and share expansion, bidding and procurement and rural asset transfer, and the corresponding transaction business type is output.

5. The decision-making method according to claim 1, characterized in that, After the step of filling in the corresponding business form according to the business type, the method further includes: Based on the business form, the legal and regulatory knowledge base of the corresponding business category is retrieved, and the legal constraints are output. The form data is then compared and calculated field by field with the legal constraints, and the compliance differences of the form are output. Based on the form compliance differences, identify compliance defects in the form and generate rectification prompts.

6. The decision-making method according to claim 1, characterized in that, The steps for comparing and annotating the modification areas of multiple versions of application materials based on the aforementioned business form include: Based on the business form, the required and optional fields are distinguished, and the required and optional fields are compared segment by segment. A traceable modification mark is generated for the difference area of ​​the required field.

7. The decision-making method according to claim 1, characterized in that, After generating the initial review message, the following steps are also included: Extract key transaction elements from the initial review message, and construct a demand feature vector based on the key transaction elements; Based on the aforementioned demand feature vector, retrieve historical investment categories, investable amounts, and risk tolerance thresholds of existing investors; Perform feature matching to generate target recommendation clues with labeled matching weight scores.

8. The decision-making method according to claim 1, characterized in that, The steps for calculating transaction risk indicators based on the aforementioned preliminary review message include: Extract the application text, entity qualification, and quotation information from the preliminary review message and output the message feature signal; Based on the message feature signals, external entity static credit records and multi-round dynamic fluctuation data of quotations are retrieved, and text similarity coefficient signals, entity association risk coefficient signals and quotation deviation coefficient signals are output respectively. Based on the text similarity coefficient signal, the subject association risk coefficient signal, and the price deviation coefficient signal, a weighted calculation is performed using preset weight parameters to obtain the transaction composite risk score signal. The corresponding trading risk index is obtained by comparing the composite risk score signal of the transaction with the preset score range.

9. The decision-making method according to claim 1, characterized in that, After the step of outputting a risk alarm signal, the following steps are also included: Retrieve similar historical risk handling cases from the database, match the current alarm level, and push corresponding standardized handling guidelines.

10. A cloud management system, characterized in that, The cloud management system includes: The module is used to retrieve the original transaction data of the transaction robot, and to process the original data to generate a transaction association graph. The comparison module is used to identify the transaction business type based on the transaction association graph, fill in the corresponding business form according to the business type, compare multiple versions of the application materials based on the business form, mark the modified areas, and generate a preliminary review message. The calculation module is used to calculate transaction risk indicators based on the preliminary review message and output risk alarm signals; The evidence storage module is used to attach operation timestamps to the transaction association graph, the preliminary review message and the risk alarm information, and encrypt and store them in a trusted evidence storage ledger.

Images