Enterprise financial data analysis management cloud platform system and programming method thereof

Abstract

The present application relates to the technical field of data mining, and more particularly to a kind of enterprise financial data analysis management cloud platform system and its programming method.The method comprises the following steps: collecting multi-source enterprise financial data, and carrying out analysis pre-classification and compression coding, to obtain time data acquisition event stream;Based on time data acquisition event stream, context-sensitive semantic alignment is carried out, to obtain high-dimensional semantic tensor;According to high-dimensional semantic tensor, external economic entity semantic constraint is carried out, to obtain financial entity relationship graph;The logical relationship between the nodes of financial entity relationship graph is structured chain encapsulation and consensus verification, to obtain encrypted verification financial chain package;The encrypted verification financial chain package is programmed logic constraint, to obtain pre-constructed logic execution unit set, and the pre-constructed logic execution unit set is uploaded to enterprise private cloud platform, to execute platform building task.The present application enhances the intelligent level and management efficiency of enterprise financial analysis management.

Description

Technical Field

[0001] This invention relates to the field of data mining technology, and in particular to a cloud platform system for enterprise financial data analysis and management and its programming method. Background Technology

[0002] Traditional financial management systems face multiple challenges, including massive data volumes, complex information processing, and difficulties in cross-departmental collaboration. The methods for collecting, classifying, analyzing, and sharing financial data urgently need restructuring. Meanwhile, the rapid development of emerging technologies such as cloud computing, the Internet of Things, and big data has provided new possibilities and architectural foundations for enterprise financial information processing. Most traditional enterprise financial data analysis and management systems adopt a centralized deployment structure, relying on manual data entry, rule template settings, and periodic batch processing mechanisms. Data updates are lagging, and system responsiveness is limited, failing to meet the requirements of modern enterprises for real-time and refined management of financial information. Especially when dealing with diverse data formats generated by heterogeneous business systems, traditional methods often require extensive manual intervention for data cleaning, format alignment, and indicator mapping, resulting in cumbersome and inefficient processes. Furthermore, traditional analysis methods focus on static report generation and linear indicator analysis, making it difficult to achieve real-time insights and predictive analysis of business dynamics. Summary of the Invention

[0003] Therefore, it is necessary for the present invention to provide an enterprise financial data analysis and management cloud platform system and its programming method to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, a programming method for an enterprise financial data analysis and management cloud platform includes the following steps:

[0005] Step S1: Collect financial data from multiple sources of enterprises, and parse, pre-classify, and compress the financial data to obtain a temporal data collection event stream;

[0006] Step S2: Perform adaptive semantic feature extraction based on the temporal data acquisition event stream to obtain an adaptive feature extraction matrix; perform context-sensitive semantic alignment on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor;

[0007] Step S3: Construct a set of internal financial entities of the enterprise based on the high-dimensional semantic tensor, and impose semantic constraints on the set of internal financial entities of the enterprise on external economic entities to obtain a financial entity relationship graph;

[0008] Step S4: Perform event-driven index orchestration on the logical relationships between nodes in the financial entity relationship graph to obtain an orchestration index meta-mapping set; encapsulate the orchestration index meta-mapping set into a structured chain and perform consensus verification to obtain an encrypted verification financial chain package;

[0009] Step S5: Anonymize the encrypted verification financial chain package and perform federated interactive computation on the anonymization result to obtain a federated interactive computation result set; perform programming logic constraints based on the federated interactive computation result set to obtain a pre-built logic execution unit set, and upload the pre-built logic execution unit set to the enterprise private cloud platform to execute the platform construction task.

[0010] The enterprise financial data analysis and management cloud platform programming method of this invention fully leverages the high scalability and real-time data processing capabilities of emerging technologies such as cloud computing, the Internet of Things, and big data. It achieves efficient collection, cleaning, processing, analysis, and sharing of financial data across departments and systems, effectively overcoming the problems of response lag and cumbersome manual intervention inherent in traditional centralized deployment structures. By de-identifying the chain head, chain body, and chain tail fields in the steps, data privacy and multi-party security isolation are ensured, avoiding the risk of sensitive financial data leakage. In the design of the timestamp of the event unit and the chain head identifier parameter of the indicator chain segment, the uniqueness of the timestamp and the identifiability of the indicator chain segment improve the accuracy and processing efficiency of event data splitting and task grouping, ensuring the synchronization and accuracy of data slicing and task distribution. By setting task execution identifiers and timestamp index parameters, it effectively supports task tracking, status monitoring, and data consistency management of multi-party participating nodes, ensuring the smooth execution of distributed computing tasks and the traceability of results. The introduction of the federated interactive computing framework not only breaks down data silos and enhances the security and collaboration of data sharing, but also promotes cross-departmental and cross-system indicator alignment and business unification through global consistency and feature distribution calculation of indicators, ensuring the global effectiveness and logical integrity of the enterprise's internal indicator system. By combining the indicator logic and event-driven relationships of the enterprise's internal financial entity set with the global federated interactive computing results, a programming logic constraint model is constructed, which avoids redundant calculations and strengthens the dynamic logical dependencies between indicators, laying the foundation for subsequent programming unit generation. The generation of pre-built logic execution unit sets and structured configuration files not only improves the automation level of business processes, but also facilitates the rapid deployment and management of the enterprise's private cloud platform, meeting the enterprise's actual needs for flexible, controllable, efficient, and secure cloud-based financial data analysis and management. The setting of parameters such as task execution identifiers, timestamp indexes, chain fragment index cache tables, and indicator field index information in the steps ensures the organic connection of data sharding, task execution, verification, integration, and programming throughout the entire process, realizing process continuity, task traceability, and data consistency, greatly enhancing the intelligence level and management efficiency of enterprise financial analysis and management.

[0011] Optionally, this specification also provides an enterprise financial data analysis and management cloud platform system, on which a computer program is stored, the computer program being used to execute the enterprise financial data analysis and management cloud platform programming method described above, including:

[0012] The data preprocessing module is used to collect financial data from multiple sources of enterprises, and to parse, preclassify, and compress the financial data to obtain a temporal data collection event stream.

[0013] The semantic feature analysis module is used to perform adaptive semantic feature extraction based on temporal data acquisition event streams to obtain an adaptive feature extraction matrix; context-sensitive semantic alignment is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor;

[0014] The entity relationship analysis module is used to construct a set of internal financial entities of an enterprise based on a high-dimensional semantic tensor, and to impose semantic constraints on the set of internal financial entities by external economic entities to obtain a financial entity relationship graph.

[0015] The consensus verification module is used to orchestrate event-driven indicators for the logical relationships between nodes in the financial entity relationship graph, resulting in an orchestration indicator meta-mapping set; the orchestration indicator meta-mapping set is then encapsulated in a structured chain and subjected to consensus verification to obtain an encrypted verification financial chain package.

[0016] The programming logic analysis module is used to anonymize the encrypted verification financial chain package, perform federated interactive computation on the anonymization result, and obtain a federated interactive computation result set. Based on the federated interactive computation result set, programming logic constraints are applied to obtain a pre-built logic execution unit set, which is then uploaded to the enterprise private cloud platform to execute the platform construction task.

[0017] The present invention relates to an enterprise financial data analysis and management cloud platform system. This system can implement any of the enterprise financial data analysis and management cloud platform programming methods of the present invention. It is used as a medium for connecting the operation and signal transmission between various modules to complete the enterprise financial data analysis and management cloud platform programming method. The internal modules of the system cooperate with each other, thereby enhancing the intelligence level and management efficiency of enterprise financial analysis and management. Attached Figure Description

[0018] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0019] Figure 1 This is a flowchart illustrating the steps of the programming method for the enterprise financial data analysis and management cloud platform of the present invention.

[0020] Figure 2 This is a detailed flowchart of step S1 in the present invention;

[0021] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0023] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0024] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0025] To achieve the above objectives, please refer to Figures 1 to 2 This invention provides a programming method for an enterprise financial data analysis and management cloud platform, the method comprising the following steps:

[0026] Step S1: Collect financial data from multiple sources of enterprises, and parse, pre-classify, and compress the financial data to obtain a temporal data collection event stream;

[0027] In this embodiment, financial information of the enterprise is collected from multiple data sources, including but not limited to general ledger, subsidiary ledger, financial vouchers, and transaction records, such as enterprise ERP systems, financial software, and inventory management systems. Subsequently, considering the structural differences between different data sources, multi-source data parsing rules based on JSONSchema are used to perform structured parsing of the collected raw financial data, generating an intermediate format containing data fields, timestamps, and event IDs. This intermediate format is then pre-classified according to the payment period dimension to form a payment period financial event table. To ensure the efficiency of subsequent calculations, Huffman coding is used to compress the field names and numerical fields of the parsed data, generating a compressed temporal data collection event stream. An example of the data format is: EventID: T20250529-001, Timestamp: 2025-05-29 10:00:00, Fields: {"Subject":"A101","Amount":12000,"Time":"2025-05-28"}. Finally, the compressed event stream is pushed to the data bus in the form of a Kafka data stream to support subsequent feature extraction tasks.

[0028] Step S2: Perform adaptive semantic feature extraction based on the temporal data acquisition event stream to obtain an adaptive feature extraction matrix; perform context-sensitive semantic alignment on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor;

[0029] In this embodiment, a semantic feature extraction framework based on the Transformer architecture is adopted for the acquired temporal data event stream. This framework includes a multi-layer encoder, each layer containing eight multi-head self-attention layers and a feedforward network, and a built-in positional encoding module to maintain the order of event timestamps. First, the input event stream data is sorted in ascending order of timestamps, and each event data is input into the feature extraction framework in the form of [EventID, timestamp, field content]. After passing through the multi-layer encoder, the feature vectors automatically learned in the output of each layer are assembled into a three-dimensional matrix, called the adaptive feature extraction matrix (dimension: number of events × number of features × time step). Next, a semantic alignment module based on a context-sensitive sliding window mechanism is used to perform context-sensitive sequence feature alignment on the adaptive feature extraction matrix to solve the temporal offset and semantic deviation between multi-source heterogeneous data, generating a high-dimensional semantic tensor (dimension example: 128×64×32) for subsequent financial knowledge modeling by the enterprise.

[0030] Step S3: Construct a set of internal financial entities of the enterprise based on the high-dimensional semantic tensor, and impose semantic constraints on the set of internal financial entities of the enterprise on external economic entities to obtain a financial entity relationship graph;

[0031] In this embodiment, based on the generated high-dimensional semantic tensor, the enterprise constructs an internal set of financial entities using an entity generation framework. This framework, based on a tensor slicing mechanism, first decomposes the high-dimensional semantic tensor into multiple two-dimensional tensor slices along the time step direction, with each slice representing semantic features within a specific time period. By performing density clustering (e.g., DBSCAN) on each two-dimensional tensor slice, vector representations of core financial entities (e.g., revenue, expenditure, cost centers) are extracted. An example of an entity set format is: {E1:[0.25,0.67,0.12],E2:[0.45,0.89,0.32],...}. Next, considering the external economic environment, semantic relationships from a knowledge graph (e.g., supply chain correlation) are used to add external constraints to the entities in the entity set, generating a financial entity relationship graph, which is stored in triplet form.

[0032] Step S4: Perform event-driven index orchestration on the logical relationships between nodes in the financial entity relationship graph to obtain an orchestration index meta-mapping set; encapsulate the orchestration index meta-mapping set into a structured chain and perform consensus verification to obtain an encrypted verification financial chain package;

[0033] In this embodiment, after the financial entity relationship graph is constructed, an event-driven indicator orchestration mechanism is used to extract and sequence the logical relationships between graph nodes based on indicator correlation. This mechanism first triggers the extraction of logical relationships between nodes based on business events (such as financial settlement or supplier reconciliation), then uses a matrix-form relationship template for indicator mapping to generate an orchestrated indicator meta-mapping set (example: indicator dimension: revenue, time window: quarter, calculation expression: Σ(current period revenue) / Σ(previous period revenue)). Subsequently, the orchestrated indicator meta-mapping set is input into a chain encapsulation engine based on a MerkleTree structure. Each indicator meta-mapping item is stored in a MerkleTree node as a node hash value, undergoing structured chain encapsulation and multi-node consensus verification. Finally, an encrypted verified financial chain package is output to ensure data integrity and traceability.

[0034] Step S5: Anonymize the encrypted verification financial chain package and perform federated interactive computation on the anonymization result to obtain a federated interactive computation result set; perform programming logic constraints based on the federated interactive computation result set to obtain a pre-built logic execution unit set, and upload the pre-built logic execution unit set to the enterprise private cloud platform to execute the platform construction task.

[0035] In this embodiment, after obtaining the encrypted verification financial blockchain packet, it is first hashed using the SHA-256 hash function to anonymize the data and eliminate sensitive enterprise fields and entity identification information. Then, the anonymized blockchain packet is transmitted to the enterprise consortium blockchain network. Combined with the multi-task distribution mechanism of the federated learning architecture, the packet is distributed to multiple participating nodes. Each node performs local computation on the blockchain packet data using a secure multi-party computation protocol, generating a federated interactive computation result set (format: {node ID: result vector}). Next, based on business needs, the enterprise sets logical constraint rules for the result set, such as a transaction volume exceeding 1000 transactions and a capital inflow exceeding 5 million yuan. Using a smart contract-based logical constraint script, the result vector is validated for business logic, and a pre-built set of logical execution units is output (example: LEU1: compliant transaction volume, LEU2: normal capital flow). Finally, the pre-built set of logical execution units is uploaded to the financial intelligent execution engine in the enterprise's private cloud platform, achieving automated deployment and operation of the enterprise's digital intelligent financial execution.

[0036] Optionally, step S1 specifically includes:

[0037] Step S11: Collect multi-source corporate financial data by connecting to the company's internal database and business processes;

[0038] In this embodiment, a data source collector is configured to establish an efficient data interface with the enterprise's internal database and business processes to collect multi-source enterprise financial data. The data source collector uses the Java JDBC protocol for underlying connection and combines multiple points of parallel connection with the enterprise's internal financial (such as Oracle ERP, SAP ERP) and business support (such as supply chain management, CRM). An example configuration file for the collector is as follows: {"sources":[{"name":"ERP1","type":"oracle","url":"jdbc:oracle:thin:In this embodiment, 192.168.1.10:1521:ORCL","user":"fin_user","password":"******"},{"name":"SCM","type":"mysql","url":"jdbc:mysql: / / 192.168.1.20:3306 / scm","user":"scm_user","password":"******"}]}. Data is collected from various data sources in a round-robin fashion within a preset time window (e.g., 00:00 to 04:00), using an incremental update mode. Each collection only retrieves data after the "last collection timestamp" to avoid duplicate collection. The data is initially encapsulated in JSON format, as shown in the example below: {"source":"ERP1","table":"GL","timestamp":"2025-05-29T23:50:00Z","record":{"account":"1001","amount":"5000","currency":"CNY","business_type":"Sales"}}; After collection, all data is saved in a temporary storage area according to its source and business identifier, and tagged with the initial data source label for easy alignment processing later.

[0039] Step S12: Timestamp align the financial data of multiple enterprises and add index labels to each aligned data to obtain time-indexed financial data;

[0040] In this embodiment, after multi-source data acquisition is completed, the timestamp alignment stage begins. Since different business operations may have second-level or millisecond-level differences in recording times for the same transaction, the time format is first standardized to the ISO8601 standard (e.g., 2025-05-29T23:50:00Z). For records with missing timestamps, time inference is performed using associated business documents (e.g., invoice number, document ID) and business log information (e.g., approval time, payment time). For example, if a record lacks a timestamp but contains invoice number INV1234, "2025-05-29T23:49:58Z" can be found in the invoice log and assigned a value. After timestamp alignment is completed, a unique index label is assigned to each record based on the data source, business type, and timestamp, with an example format: "ERP1-Sales-20250529T235000Z-00001"; where "00001" is the serial number, used to ensure that multiple records with the same timestamp can also be uniquely identified.

[0041] Step S13: Perform pre-parsing and preliminary semantic annotation on the time-indexed financial data to obtain semantically annotated data;

[0042] In this embodiment, the timestamp-aligned data enters the pre-parsing and preliminary semantic annotation stage. This stage uses a pre-built financial data dictionary (derived from the financial subject system, business document templates, and commonly used business terminology database accumulated by the enterprise's finance department over a long period. For example, a local dictionary is generated by extracting the accounting subject table from the ERP system (such as the SKA1 table in SAP), which includes subject number, subject name, category, and auxiliary information, etc.) for field identification and semantic association. Taking "ERP 1-Sales-20250529T235000Z-00001" as an example, the parsed fields include: "account" corresponds to "subject code"; "amount" corresponds to "amount"; "currency" corresponds to "currency"; and "business_type" corresponds to "business type". Simultaneously, semantic mapping is performed by loading the enterprise's custom financial terminology table (stored in the "finance_terms" table in a relational database), such as labeling "1001" as "cash" and "5001" as "main business revenue". Annotation result example: { "record_id":"ERP1-Sales-20250529T235000Z-00001","fields":[{"field_name":"account","field_value":"1001","semantic_tag":"cash"},{"field_name":"amount","field_value":"5000","semantic_tag":"RMB amount"},{"field_name":"currency","field_value":"CNY","semantic_tag":"RMB"},{"field_name":"business_type","field_value":"Sales","semantic_tag":"main business revenue"}]} All labeled data is written to the data warehouse as input for subsequent pre-classification.

[0043] Step S14: Perform multi-level data pre-classification based on semantically labeled data to obtain a preliminary financial data classification index table;

[0044] In this embodiment, after semantic annotation is completed, multi-level pre-classification is performed according to the enterprise's financial management requirements. First, a primary classification is performed based on the "Business Type" field, such as "Sales," "Purchase," and "Inventory." Then, a secondary classification is performed based on the category of the "Account Code" (obtained from the enterprise's accounting chart of accounts), such as "Assets," "Liabilities," "Revenue," and "Expenses." Finally, a tertiary classification is performed based on the specific accounts defined by the enterprise, such as "Cash," "Accounts Receivable," and "Main Business Revenue." The generated preliminary classification index table structure is as follows (JSON example): {"record_id":"ERP1-Sales-20250529T235000Z-00001","classifications":{"level_1":"Sales","level_2":"Revenue","level_3":"Main Business Revenue"}} If the same data has multiple business relationships (e.g., involving both "Main Business Revenue" and "Other Business Revenue"), it is recorded in the tertiary classification using "|" as a separator, such as "Main Business Revenue|Other Business Revenue," while also recording the priority of multiple tags. This priority is defined in the configuration file based on the company's financial policies.

[0045] Step S15: Compress and encode the data in the preliminary financial data classification index table according to the field type to obtain a compressed and encoded data stream;

[0046] In this embodiment, after the initial classification index table is completed, the data compression and encoding stage begins. An adaptive dictionary-based compression and encoding scheme is adopted: First, the repetition rate of field values ​​in the financial data is analyzed, generating frequent field combinations and their compression codes, such as: {"Main Business Revenue":"MBSR","Cash":"CASH","Accounts Receivable":"AR"}; then, multiple field combinations in each record are encoded and replaced, such as: {"record_id":"ERP1-Sales-20250529T235000Z-00001","compressed_data":"account:MBSR|amount:5000|currency:CNY"}; whenever a new field appears, the encoding table is updated and a version number is recorded. For example, if the encoding table version number is "V20250529", a reference is added to the compressed data to ensure consistency in subsequent decoding. The adaptive dictionary compression encoding scheme analyzes enterprise financial datasets collected over the past three months (stored in a time-series database or big data warehouse). MapReduce or Spark tasks are used to perform word frequency statistics on each field value (e.g., fields appearing more than 10 times are used to generate initial encoding entries). Combined with a "field usage frequency table" provided by the enterprise's finance department, the word frequency threshold is further optimized (e.g., only fields appearing more than 20 times are included in the encoding table; those appearing less than 20 times are not encoded). The word frequency statistics results are periodically (e.g., daily at midnight) incrementally updated and version-managed using automated jobs (e.g., AirflowDAG). The dictionary is stored in JSON format or a database table (e.g., MySQL), with each version containing field names, field values, encoded values, frequency of occurrence, and version numbers.

[0047] Step S16: Perform event-based splitting on the compressed encoded data stream, dividing each compressed encoded data stream into event units according to the data timestamp to obtain the temporal data acquisition event stream.

[0048] In this embodiment, after compression encoding, the data is split into events based on timestamps. Taking a 10-second time window as an example, the compressed encoded data stream is scanned sequentially, and data with timestamps within the same window are grouped into the same event unit. Each event unit includes an event ID (e.g., "Event20250529T235000Z-01"), start time, end time, business type involved, and number of records. For example: {"event_id":"Event20250529T235000Z-01","start_time":"2025-05-29T23:50:00Z","end_time":"2025-05-29T23:50:10Z","business_type":"Sales","record_count":12}; if the timestamp of a record spans a time window, it is allocated to a window according to the nearest timestamp principle. For example, if a record's timestamp is "2025-05-29T23:50:11Z", it will be assigned to the next event unit "Event20250529T235010Z-02". After splitting, the event stream is stored in an event log database (such as MongoDB) for subsequent temporal analysis and modeling.

[0049] Optionally, step S14 specifically includes:

[0050] Step S141: Obtain the enterprise's internal financial account structure and business process structure by connecting to the enterprise's business system;

[0051] In this embodiment, a data interaction channel is established with the enterprise's ERP system and business systems through a secure access interface deployed in the enterprise's private network. By configuring JDBC and RESTful API connectors, the internal financial account architecture and business process structure information are obtained. Financial account architecture data includes account codes (such as four-digit hierarchical codes), account names, parent accounts, account balance directions, and outstanding account attributes. Business process structure data includes business process identifiers, process node names, process node sequences, inter-node dependencies, and corresponding business scenario identifiers. This information is stored in a structured manner using a unified JSON format. Each data entry includes auxiliary fields such as business system identifier, data source identifier, and data version information. Data extraction batches are identified by timestamps (e.g., named in the format "YYYYMMDDHHMMSS") to facilitate subsequent time-series management and traceability analysis.

[0052] Step S142: Perform financial topology analysis based on the enterprise's internal financial account structure and business process structure to obtain the financial topology, and construct a semantic tag relationship mapping table using the financial semantic relationships in the financial topology.

[0053] In this embodiment, based on the obtained financial subject architecture and business process structure, a preliminary subject-process relationship network is first constructed according to the subject code and process node order using the financial subject relationship table and business process node relationship table in the relational database. Then, a Python script is used to traverse each subject-process relationship data sequentially, mapping each one to the financial topology relationship table in the form of triples of "subject code → process node identifier → association relationship type (including 'attribution relationship', 'calculation relationship', 'approval relationship', etc.)". Finally, the financial topology structure is represented in the form of an adjacency matrix, where each row and column is a set of financial subjects and business process nodes, and a matrix cell value of 1 indicates a direct association, while 0 indicates no direct association. The dependency relationship between nodes is analyzed through this matrix, and based on the principle of "direct association priority, hierarchical structure order", financial semantic relationships are extracted to generate a semantic label relationship mapping table. Each label relationship mapping table entry contains fields such as "source node, target node, semantic relationship type, and relationship weight".

[0054] Step S143: Group the semantically labeled data into financial topics based on the semantic label relationship mapping table to obtain a preliminary set of financial data topics;

[0055] In this embodiment, based on the constructed semantic tag relationship mapping table, each semantic tag data (including source node, target node, and semantic relationship type) is read sequentially. Then, according to the financial subject and process node identifier corresponding to the target node, the financial data for the same target node is grouped, initially divided into financial data theme sets. For example, all financial data related to the "Sales Revenue Confirmation" node is grouped into the "Sales Revenue" theme; all financial data related to the "Purchase Order Settlement" node is grouped into the "Purchase Cost" theme. Each theme set is organized as a JSON array, where each data entry contains a data identifier, theme identifier, original data source identifier, and timestamp, used for subsequent indicator extraction and theme hierarchy management.

[0056] Step S144: Extract financial indicators for each theme based on the preliminary financial data theme set, and construct a hierarchical indicator system based on the business process configuration requirements of the business process structure;

[0057] In this embodiment, within the initial set of financial data topics, for each topic, the field names and data content of each data record are analyzed one by one to extract financial indicator information, such as sales revenue, discount rate, purchase amount, and accounts payable. The indicator set is organized in the form of "Topic Identifier → Financial Indicator Name → Indicator Unit → Indicator Field Name → Business Process Configuration Identifier". Based on the business process structure information in step S141, a hierarchical structure of indicators is generated according to the "process node order" and "dependency weight". Financial indicators involved in the same process node are set to the same level, and the indicator relationships between different process nodes form a hierarchical indicator system according to the order of the business processes. Finally, a hierarchical indicator system organized by topic is obtained, and each record contains fields such as "Topic Identifier, Indicator Name, Hierarchical Identifier, Parent Indicator Identifier, and Business Process Configuration Identifier".

[0058] Step S145: Align the hierarchical indicator system with the preliminary financial data subject set to generate an indicator mapping matrix; perform multi-level data cross-validation on the indicator mapping matrix, identify and correct conflicting data, and obtain a validation indicator mapping matrix.

[0059] In this embodiment, based on the hierarchical indicator system, the data structure of the preliminary financial data theme set is first read, and associations are made according to theme identifiers. Financial indicators under the same theme are mapped one-to-one with data records to generate an indicator mapping matrix. This indicator mapping matrix is ​​in two-dimensional form, with rows representing theme identifiers and columns representing financial indicator identifiers. The value of each matrix cell is the frequency or weight of the indicator field in the corresponding theme set. Multi-level data cross-validation is performed on this matrix. First, cross-validation is based on timestamps to identify duplicate records of the same indicator at the same time point and remove conflicting data. Second, cross-validation is based on business process sequence to check for errors in the process dependency order of indicators under the same theme and correct the data order according to the business process structure. Finally, the corrected matrix is ​​output as a verification indicator mapping matrix, where each matrix cell contains a data quality identifier (e.g., "0: Abnormal; 1: Normal") in addition to the frequency value.

[0060] Step S146: Combining the thematic hierarchy of the preliminary financial data thematic set, the verification indicator mapping matrix is ​​extracted and sorted hierarchically to obtain the preliminary financial data classification index table.

[0061] In this embodiment, after completing the verification indicator mapping matrix, when extracting and sorting indicators hierarchically based on the theme hierarchy of the preliminary financial data theme set, it is first necessary to determine the strength of the dependencies between each business process node. The definition of the strongest process dependency is based on three aspects: 1) Strength of upstream and downstream relationships of nodes (weight 0.5): Analyzing the upstream and downstream connections of each node in the business process structure. Nodes with strong dependencies usually have more upstream nodes and fewer downstream nodes, indicating that the node plays an important role in aggregation and transmission; 2) Degree of correlation between indicators (weight 0.3): Statistics on whether indicators under the same theme frequently appear in the same data records in the verification indicator mapping matrix. The higher the frequency of occurrence, the closer the correlation between these indicators and the stronger the process dependency; 3) Data quality status (weight 0.2): Considering the quality of indicator data, indicators with complete data and no anomalies have higher priority because high-quality data can more reliably reflect the actual dependencies of the business process. Combining the above three points, a comprehensive weight is assigned to the business process node where each indicator is located. Nodes with higher weights indicate that they have the strongest dependencies in the process. Then, the matrix is ​​extracted hierarchically according to the indicator hierarchy, prioritizing the extraction of upper-level indicators with the strongest process dependencies, followed by lower-level indicators, ensuring strict consistency between the logical order of thematic hierarchy and indicator dependencies. Each extracted indicator is sorted according to its weight value and a sorting number is added, ultimately outputting a preliminary financial data classification index table. This index table is organized in JSON format and includes fields such as "theme identifier, indicator identifier, hierarchy identifier, sorting number, indicator weight value, and data verification status," used for subsequent data compression encoding and cross-system sharing.

[0062] Optionally, step S16 specifically includes:

[0063] Step S161: Standardize the timestamps of the compressed encoded data stream to obtain a timestamp-standardized data stream;

[0064] In this embodiment, timestamp information in the compressed encoded data stream undergoes unified format conversion and precision adjustment. Specifically, timestamps from different source systems are converted to a unified time format (e.g., the ISO 8601 standard), and the time precision is uniformly adjusted to the millisecond level to ensure time alignment accuracy in subsequent processing. This standardization process employs a timestamp standardization function library, which contains format conversion rules and time deviation correction tables to ensure that timestamp data from different systems are standardized, forming a timestamp-standardized data stream.

[0065] Step S162: Perform time continuity verification on the timestamp-standardized data stream, detect and mark missing points, duplicate points and abrupt jumps in the data stream, and obtain a list of time continuity verification results;

[0066] In this embodiment, the time continuity verification of the timestamp-standardized data stream mainly relies on time series continuity detection rules. These rules identify data interval anomalies by scanning the timestamp sequence, including missing points (time intervals exceeding a preset threshold), duplicate points (the same timestamp appearing multiple times), and jump points (abnormally large differences between adjacent time points). The preset thresholds, for example, allow a maximum interval of 500 milliseconds, and the jump difference threshold is set to 1 second. The detection results form a time continuity verification result list, including the anomaly type, anomaly location, and related data record indexes.

[0067] Step S163: Perform time gap interpolation repair based on the time continuity verification result list to obtain the time gap repair data stream;

[0068] In this embodiment, a time gap interpolation repair method is used to repair detected missing points. Specifically, time supplement points are inserted based on consecutive valid timestamp data to fill in the missing time gaps. The interpolation method can be linear interpolation or piecewise constant interpolation, with the interpolation interval consistent with the time standardization precision, typically on the order of milliseconds. The interpolation results form a time gap repair data stream, ensuring the integrity and continuity of the time series data.

[0069] Step S164: Based on the timestamps and corresponding semantic tags of the time gap repair data stream, extract the event boundary points in the time gap repair data stream, and determine the event demarcation conditions based on the business logic structure of the financial topology to obtain the event boundary point index table.

[0070] In this embodiment, event boundary points in the data stream are extracted using the repaired timestamps and corresponding semantic tags. The determination of event boundary points relies on the business logic structure defined in the financial topology; for example, key nodes in the business process (such as the start of a financial transaction or the settlement point) serve as event boundary conditions. By scanning time gaps to repair changes in semantic tags in the data stream and matching key business nodes, the start and end times of events are determined, generating an event boundary point index table. This index table contains the timestamps of the event boundaries, the corresponding semantic tags, and the event type identifier.

[0071] Step S165: Divide the time gap repair data stream into event units using the event boundary point index table to obtain the event unit set;

[0072] In this embodiment, the time gap repair data stream is divided into event units using an event boundary point index table. Specifically, based on the time range of the event boundary points, corresponding data intervals are divided to form independent event units. Each event unit contains all compressed and encoded data within that time period and its related semantic information. The division results form an event unit set, and the structure of each event unit is defined as including a start timestamp, an end timestamp, a set of event semantic tags, and data content.

[0073] Step S166: Index and label the event unit set and reorder it to obtain the temporal data acquisition event stream.

[0074] In this embodiment, the event unit set is labeled with index tags and reordered. First, a unique index tag is assigned to each event unit, which encodes the event type, time sequence, and business theme. Then, the event unit set is sorted according to the start timestamp order of the event units to ensure that the event unit stream is strictly incremental on the timeline. After sorting, the final temporal data acquisition event stream is generated, which is a serialized set of event units for easy subsequent real-time processing and analysis.

[0075] Optionally, the adaptive semantic feature extraction in step S2 specifically involves:

[0076] The time window length is set to 10 seconds. The temporal data acquisition event stream is segmented and sliced ​​according to the fixed time window length to obtain a time series slice set.

[0077] In this embodiment, a time window length of 10 seconds is set to segment the temporal data acquisition event stream. First, the timestamp of each event data is read from the event stream and converted into a unified "YYYY-MM-DD HH:MM:SS" format to ensure the accuracy of the slicing operation. Then, according to the 10-second time window length, the data stream is segmented sequentially, with each segment containing event data with consecutive timestamps; if the timestamp of a data exceeds the current window, it is included in the next window segment. During the slicing process, each time period is marked as a slice number, forming a time series slice set. Each slice contains fields including slice number, timestamp range (start and end timestamps), original event index, and compressed encoded data fields, providing a good data foundation for subsequent decoding and feature analysis.

[0078] The threshold for the number of principal components is set to 5. The principal component fields of the compressed coded data in the time series slice set are decoded, and the data are hierarchically reorganized according to the decoded field attributes to obtain a multi-level field matrix.

[0079] In this embodiment, principal component field decoding is performed on the compressed coded data in the time series slice set, with a threshold of 5 for the number of principal components. Specifically, the compressed coded fields of each slice are first decoded, converting the binary or hexadecimal compressed data into numerical fields to form an initial field matrix. Then, the fields are sorted according to their variance contribution rate, and the top 5 fields with the highest contribution rates are selected as principal component fields, while noisy fields with low contribution rates are removed. After decoding, based on the business attributes of each principal component field (such as account number, amount, and transaction type), the fields are hierarchically reorganized according to their level (such as primary financial indicators and secondary detailed indicators) to construct a multi-level field matrix. The rows of the matrix represent the timestamp order, and the columns are arranged sequentially according to the field level. The matrix format is T×F (T is the time step, and F is the number of fields), laying the foundation for subsequent context modeling.

[0080] Within a fixed time window, the context dependency relationship of each field in the multi-level field matrix is ​​modeled using the field attributes and event timestamps in the multi-level field matrix to obtain the context feature weight matrix.

[0081] In this embodiment, for a multi-level field matrix, contextual dependency modeling is performed using field attributes and event timestamps. Specifically, the business attributes of each field (such as "revenue amount," "taxes," and "depreciation") are first read. Then, a context window is configured for each field according to the order of event timestamps, with the window size consistent with a fixed time window length (10 seconds). Within this context, based on the historical values ​​of the fields and the upstream and downstream relationships of fields at the same level (e.g., in a business process where "revenue amount" depends on "revenue confirmation"), the contextual association strength between fields is calculated, forming a contextual feature weight matrix. This matrix has a dimension of F×F, representing the degree of association between each field and other fields within the same time window. The weight values ​​are set between 0 and 1 for subsequent aggregation of dynamic semantic features.

[0082] Dynamic semantic aggregation is performed on the multi-level field matrix based on the context feature weight matrix and the labels of the event units. The semantic cross-fusion window size is set to 3, and the features of the event units are cross-fused in the timestamp dimension and the field dimension to obtain the dynamic semantic feature matrix.

[0083] In this embodiment, dynamic semantic aggregation of multi-level field matrices is performed using a context feature weight matrix and event unit labels. Specifically, the semantic cross-fusion window size is set to 3, indicating that context aggregation is performed at both the field and timestamp levels. For each data entry, its corresponding field attributes and context feature weights are extracted, and combined with event unit labels (such as "revenue confirmation event," "settlement event," etc.), the field features within adjacent time windows are cross-fused. During fusion, the weights of the same field in the preceding and following time steps are weighted and summed with the weight in the current time step to calculate the semantic interaction effect across time steps, generating a dynamic semantic feature matrix. This matrix has a dimension of T×F, and each element records the comprehensive semantic weight of the field across time steps and at the field level, facilitating subsequent identification of local outliers.

[0084] Local outlier identification is performed based on the dynamic semantic feature matrix, and the identification results are adaptively corrected by weights to obtain an adaptive feature extraction matrix.

[0085] In this embodiment, the dynamic semantic feature matrix is ​​first read, and local fluctuation analysis is performed on the field values ​​according to the upstream and downstream dependencies of the fields and the order of timestamps. When a field is detected to have a significantly deviated weight within a time window (e.g., more than twice the context average), it is identified as a local outlier. For the detected local outliers, a weighted average of adjacent fields in the context dependency is used for correction, with the correction weight coefficient set to 0.8 (indicating that the context weight accounts for 80%) to avoid excessive correction that could lead to information distortion. The final generated adaptive feature extraction matrix retains the row and column structure of the dynamic semantic feature matrix and adds a "correction identifier" field to identify corrected local outliers. The output data structure is complete, ensuring the continuity of subsequent analysis.

[0086] Most importantly, the adaptive weight adjustment is specifically as follows:

[0087] Statistical analysis was performed on the feature value distribution in the timestamp dimension and field attribute dimension of the dynamic semantic feature matrix to identify and label local outliers within the sliding time window, thus obtaining preliminary local anomaly labeling data.

[0088] In this embodiment, a sliding time window is constructed based on the timestamp dimension and the field attribute dimension for the dynamic semantic feature matrix. Specifically, the time window length is set to 10 seconds, and the field attributes are arranged in hierarchical groups according to the dynamic semantic feature matrix, with each group containing at least 5 fields. Through the sliding window operation, the window slides gradually in 1-second increments along the timestamp dimension of the dynamic semantic feature matrix to extract the distribution of field values ​​within the window. Distribution statistics are performed on the field feature values ​​within each sliding time window, mainly calculating the range, mean, and standard deviation of the field values, and comparing them with the distribution of the preceding and following time windows. If the distribution statistics of a certain field deviate significantly from the context mean in the current window (e.g., the deviation exceeds 2 times the standard deviation), it is identified as a local outlier, and a preliminary anomaly marker is added to the field within the window. Finally, preliminary local anomaly marker data is output, including timestamp, field attribute, window number, and anomaly marker status.

[0089] Using the context feature weight matrix, the context feature values ​​of the same field in the timestamp dimension are extracted from the preliminary local anomaly labeling data. The context mean, variance and local trend are calculated to generate context neighborhood feature data.

[0090] In this embodiment, the context feature weight matrix is ​​first read. This matrix has dimensions F×F (F is the number of fields), and each element represents the dependency strength between fields, with weight values ​​ranging from 0 to 1. Then, according to the anomalous fields in the preliminary local anomaly labeling data, a context window is extended forward and backward by 3 seconds along the timestamp dimension of the dynamic semantic feature matrix to extract the context feature values ​​of the same field. For each field, the mean, variance, and local trend (such as trend slope, unit: unit field value / second) within the context window are calculated. The statistical results are stored in the context neighborhood feature data. The data structure includes field ID, timestamp window range, context mean, variance, and trend information, which are used for subsequent confidence estimation and anomaly correction.

[0091] The confidence level of the fluctuation range is estimated from the context neighborhood feature data to obtain the confidence estimation matrix;

[0092] In this embodiment, confidence level estimation of the fluctuation range of the context neighborhood feature data is performed. Specifically, based on the context mean and variance, the upper and lower bound fluctuation ranges of each field are calculated, with a confidence level threshold set at 95%. The calculation method is: upper and lower bounds of confidence level = context mean ± 1.96 × standard deviation. For each data point, the field ID, timestamp window range, and confidence upper and lower bounds are recorded. Values ​​within the fluctuation range are marked as high-confidence intervals, and values ​​outside the range are marked as low-confidence intervals. This information is combined into a confidence estimation matrix. The dimensions of the matrix are consistent with those of the context neighborhood feature data, including field ID, timestamp range, confidence upper and lower bounds, and confidence label fields, which are used to guide subsequent correction of abnormal feature weights.

[0093] By combining the confidence estimation matrix and the preliminary local anomaly labeling data, the abnormal feature points in the dynamic semantic feature matrix are corrected by feature weight regression and then fused to output an adaptive feature extraction matrix.

[0094] In this embodiment, when correcting the dynamic semantic feature matrix by combining the confidence estimation matrix and the preliminary local anomaly labeling data, all field entries marked as "anomaly" are first selected from the preliminary local anomaly labeling data, and accurately located to the corresponding row in the dynamic semantic feature matrix based on the field ID and timestamp. For each anomaly field point, the context mean and standard deviation of the field and its time window are extracted from the confidence estimation matrix, and the context mean is used as the correction reference baseline. To reflect the dependency on contextual information, the context correction weight is set to 0.7, and the anomaly correction weight is set to 0.3. A weighted superposition method is used to correct the eigenvalues ​​of the anomaly feature points. The formula for calculating the corrected eigenvalue is: Corrected eigenvalue = (Context mean × 0.7) + (Original anomaly eigenvalue × 0.3). This preserves the local information of the anomaly feature points while incorporating the contextual stability within the time window. After calculating the corrected eigenvalues, within the same matrix structure, the field ID, timestamp, corrected eigenvalue, context correction weight, anomaly correction weight, context mean from the confidence estimation matrix, and original anomaly eigenvalue are all retained to construct the output adaptive feature extraction matrix. This matrix contains seven fields: field ID, timestamp, corrected eigenvalue, context correction weight, anomaly correction weight, context mean, and original anomaly eigenvalue. The matrix dimension is set to [N×7], where N represents the total number of field entries in the dynamic semantic feature matrix. This matrix clearly traces the source of each corrected value and its contribution to the context, while providing sufficient context and anomaly information to support subsequent feature selection, time series modeling, and event-driven analysis. It achieves a closed-loop output of correction and fusion, ensuring the traceability and adaptive dynamic characteristics of the feature extraction process.

[0095] Optionally, the context-sensitive semantic alignment in step S2 specifically involves:

[0096] For the fields in the adaptive feature extraction matrix, the context semantic neighborhood window is divided according to the timestamp of the event unit and the field attribute to obtain the semantic neighborhood index set;

[0097] In this embodiment, based on the [N×7] structure of the adaptive feature extraction matrix (field ID, timestamp, corrected feature value, context correction weight, anomaly correction weight, context mean, original anomaly feature value), the data is first grouped by field ID, and then sorted by timestamp order within each group. The context semantic neighborhood window length is set to 20 seconds, and the time step is 5 seconds. A sliding window approach is used to slice the data in each group, with each window containing 5-8 field entries (set according to actual data density), ensuring that each window contains at least one anomaly field point. For each field entry in each window, the corresponding row index is recorded, constructing a semantic neighborhood index set (e.g., {window1:[0,1,2,3], window2:[2,3,4,5]}) for subsequent context semantic analysis. This index set is stored in JSON format, with fields including "window number," "field ID," and "timestamp index range," ensuring the flexibility and traceability of the index.

[0098] The semantic similarity score of each field in different contextual semantic neighborhood windows is calculated based on the semantic domain index set to obtain the contextual semantic similarity matrix;

[0099] In this embodiment, for the generated semantic neighborhood index set, the corrected feature values ​​in the adaptive feature extraction matrix are retrieved sequentially according to the field ID and timestamp index range. The normalized cosine similarity method based on Euclidean distance is used to calculate the similarity of the corrected feature values ​​of fields within the same window. Specifically, a vector is constructed by combining the corrected feature value of each field entry with the corrected feature values ​​of other field entries within the window, and a cosine similarity score is calculated. The score is then normalized, with the value range limited to [0,1] to ensure comparability of similarities across different windows. The similarity score in each window is stored in a contextual semantic similarity matrix with an [N×N] structure, where N is the total number of field entries. Rows in this matrix represent target field entries, columns represent comparison objects within the neighborhood, and element values ​​are similarity scores. The matrix uses a sparse storage structure and is stored in JSON format. Each record includes information such as "field ID," "timestamp," "target field index," "comparison field index," and "similarity score," facilitating subsequent processing.

[0100] By combining the semantic neighborhood index set and the sensitive word dictionary of the pre-set financial domain ontology lexicon, sensitive fields are marked in the context semantic similarity matrix to obtain a sensitive semantic tag set;

[0101] In this embodiment, a semantic neighborhood index set and a contextual semantic similarity matrix are used, combined with a sensitive word dictionary (including terms such as "account," "balance," "transfer," and "voucher" and their synonyms) from a pre-defined financial domain ontology lexicon, to mark sensitive fields in the contextual semantic similarity matrix. Specifically, for each field entry within a context window, the original abnormal feature value corresponding to the field ID is first extracted. Through word segmentation and dictionary matching, if the field entry contains sensitive words or synonyms, the field is marked as "sensitive"; otherwise, it is marked as "non-sensitive." The sensitivity label results for each field entry are output in the form of a sensitive semantic label set. Each record includes "field ID," "timestamp," and "sensitive label (1-sensitive / 0-non-sensitive)." The sensitive labels are associated with the similarity scores in the semantic similarity matrix to form a one-to-one correspondence, facilitating subsequent dynamic weighted processing.

[0102] Based on the field weights and weight time change trends in the context semantic neighborhood window, the similarity scores of the context semantic similarity matrix are dynamically weighted, and combined with the semantic sensitivity of the sensitive semantic tag set, a context semantic weight matrix is ​​generated.

[0103] In this embodiment, based on the sensitive semantic tag set and the context semantic similarity matrix, the context correction weight (0.7) and anomaly correction weight (0.3) of each field within each context window are first extracted, and the weight change trend under adjacent timestamps is calculated. Specifically, the first-order difference of the weight between adjacent timestamps is calculated for each field entry and standardized to the range of [-1,1] to reflect the weight fluctuation characteristics of the field in the time dimension. Subsequently, the average of the context correction weight and the anomaly correction weight is used as a dynamic weighting coefficient to weight and correct the similarity score of the context semantic similarity matrix. For field entries marked as "sensitive" by the sensitive tag, an additional semantic sensitivity coefficient (set to 1.2) is introduced to further amplify the weighted correction value to increase the weight ratio of sensitive fields. Finally, a context semantic weight matrix is ​​generated with a structure of [N×N]. Each element in the matrix contains the target field index, the comparison field index, the weighted corrected similarity score, and the sensitivity coefficient, ensuring that the weight matrix can reflect both the context similarity between fields and the dynamic characteristics of sensitive fields.

[0104] Construct a context dependency graph using the context semantic weight matrix and the timestamps of event units;

[0105] In this embodiment, based on the context semantic weight matrix, the weight matrix is ​​first mapped by row and column according to field ID and timestamp information. A directed edge is formed by connecting the target field index and the comparison field index of each similarity pair, with the edge weight being the context semantic weight score. Nodes represent field entries, and node attributes include field ID, timestamp, corrected feature value, context correction weight, anomaly correction weight, sensitive semantic tags, etc. To ensure the accuracy of time information, the timestamp is converted into a continuous time step (in seconds), and the edge weights within adjacent time steps are corrected by the reciprocal of the time step to reflect the impact of temporal tightness on contextual dependencies. Finally, a context dependency graph is constructed, stored in a directed graph format, with node set V = [N] and edge set E = [(i,j,weight)], used for subsequent generation of high-dimensional semantic tensors.

[0106] By combining the context dependency graph and the context semantic weight matrix, sensitive semantic alignment processing is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor.

[0107] In this embodiment, based on the constructed context dependency graph and context semantic weight matrix, firstly, according to the field ID and timestamp dimensions, each field entry in the adaptive feature extraction matrix is ​​used to find nodes in the context dependency graph, and the context semantic weight scores of its associated edges are extracted. Then, the context correction weights, anomaly correction weights, and sensitive labels of the nodes are integrated with the context semantic weights of the edges, forming a high-dimensional semantic tensor through tensor concatenation. The tensor structure is set to [N×D×T], where N represents the number of field entries, D represents the fused context dimension (including corrected feature values, context correction weights, anomaly correction weights, sensitive labels, and context semantic weights), and T represents the time step dimension. To ensure the interpretability of the model, each tensor element is appended with field identification information and time index information to ensure the temporal and semantic integrity and traceability of the features. Finally, the output high-dimensional semantic tensor not only preserves the context dependency of dynamic features but also provides rich contextual information support for event prediction and risk identification in subsequent model tasks.

[0108] Optionally, the semantic constraints on external economic entities in step S3 are specifically as follows:

[0109] External economic data streams are collected by accessing the data interface of an external economic analysis platform; the external economic data streams are timestamped and linked based on the fields of the enterprise's internal financial entity set to obtain a pre-linked set of external economic data;

[0110] In this embodiment, a standardized data interface connection with an external economic analysis platform is first established, supporting the RESTful API protocol. A scheduled task retrieves external economic data streams in batches every 5 minutes. The data formats include JSON and CSV, and the data fields cover macroeconomic indicators, industry dynamics, market prices, and other information. The collected data streams are first processed to perform timestamp alignment, uniformly adjusting all timestamps to UTC standard time and interpolating them based on a minimum time interval of 1 minute to resolve inconsistencies in data collection times. Subsequently, based on the field list in the enterprise's internal financial entity set (e.g., key fields such as "enterprise name," "tax number," and "industry category"), corresponding fields in the external economic data stream are mapped and associated using field matching rules (field name, semantic tag, field type), generating a pre-association set of external economic data. This pre-association set is stored in a table format, containing field IDs, original data field names, associated enterprise field IDs, timestamps, and association status markers, facilitating subsequent semantic processing.

[0111] By utilizing the fields and tags of the enterprise's internal financial entity set, and based on the financial domain ontology lexicon, semantic mapping is performed on the pre-association set of external economic data to obtain the external economic semantic mapping matrix.

[0112] In this embodiment, a pre-defined financial domain ontology lexicon contains approximately 5,000 core terms and their hierarchical relationships, a thesaurus, and domain-specific vocabulary. The lexicon structure adopts the OWL format and supports multi-level semantic mapping. External economic data pre-associations are used as input. For each data field, ontology lexicon matching is performed using the field name and its corresponding tags (such as "asset" and "liability"). Key semantic units are extracted using semantic rules. During the mapping process, word vector similarity evaluation (using a pre-trained financial word vector model with a vector dimension of 300) is employed to ensure semantic accuracy. The mapping results are stored in an external economic semantic mapping matrix. This matrix has a structure of [M×K], where M is the number of external economic data fields, K is the number of mapped ontology terms, and each element represents the confidence level (range 0-1) of the semantic match between the field and the ontology term. It also retains the field ID, timestamp, and mapping score. The matrix is ​​stored in a sparse matrix format for easy and rapid retrieval and updating.

[0113] External economic entities are extracted from the external economic semantic mapping matrix, and the extracted results are labeled with entity attributes and entity relationships by combining the context dependency graph to obtain the external economic entity label set.

[0114] In this embodiment, potential external economic entity fields are identified by filtering high-confidence mapping items (confidence threshold set to 0.85) in the semantic mapping matrix. Each entity is uniquely identified by its field ID, timestamp, and corresponding ontology term ID. Combining the previously constructed context dependency graph, the identified entities are expanded in time and semantic dimensions using contextual semantic weights between fields to extract entity attribute information, such as company size, financial indicator values, and regional information. Relationships between entities are labeled based on the edge weights in the context dependency graph, including "related transactions," "supply chain relationships," etc., with 15 preset relationship types. All labeling results are summarized to form an external economic entity label set, with a record format of [N×7], containing entity ID, attribute name, attribute value, relationship type, relationship strength, timestamp, and context label. A relational database is used for management, supporting flexible querying.

[0115] The entity attributes in the external economic entity annotation set are cross-referenced in multiple dimensions. The entity labels and field attributes in the enterprise's internal financial entity set are combined to establish semantic dependencies between entities based on the cross-reference results, and an external economic entity relationship matrix is ​​generated.

[0116] In this embodiment, for the entity attributes in the annotation set, the cross-feature dimensions are set to include time (grouped by month), attribute category (financial indicators, regional attributes, operational indicators, etc.), and enterprise tags (such as industry classification and risk level). A three-dimensional tensor-form feature cross-matrix is ​​constructed, with a tensor shape of [P×Q×R], where P is the number of entities, Q is the number of attribute categories, and R is the number of time slices. During the cross-feature process, attribute pairs with significant correlation (correlation threshold 0.7) are selected, multiplied, and normalized. Subsequently, combined with tag information from the enterprise's internal financial entity set, such as financial risk tags and industry tags, the cross-feature results are matched and mapped to determine the semantic dependencies between entities. The generated external economic entity relationship matrix is ​​a [S×S] square matrix, where S is the number of entities, and the matrix elements represent the semantic dependency strength between entities, ranging from 0 to 1. It is stored as a symmetric matrix, supporting fast indexing and subsequent analysis.

[0117] Perform semantic consistency checks on the relationship pairs in the external economic entity relationship matrix to generate an external economic semantic consistency weight matrix.

[0118] In this embodiment, the semantic consistency test compares the semantic labels, attribute consistency, and time series correlation of each pair of relationships in the entity relationship matrix. Specifically, first, the semantic label overlap of the two entity attributes is calculated, with an overlap threshold set to 0.6, indicating that relationship pairs exceeding this value are considered consistent. Second, the time series characteristics of both parties are compared, and the matching degree of attribute change trends is evaluated using a dynamic time warping method, with a threshold set to 0.7. Relationship pairs that meet the above two conditions are assigned a higher consistency weight (weight range 0.8-1), otherwise a lower weight (0-0.3). Finally, the weights are aggregated to form an external economic semantic consistency weight matrix, which also has a [S×S] structure, where each element represents the semantic consistency strength of the corresponding entity pair. The matrix is ​​stored in a sparse format for easy dynamic updating.

[0119] By combining the set of internal financial entities and the external economic semantic consistency weight matrix, entity fusion and relation constraint calculations are performed to generate a financial entity relation graph.

[0120] In this embodiment, entities from the internal financial entity set and external economic entity set are initially fused and matched based on unique identifier fields (such as the unified social credit code) to eliminate duplicate entities. Subsequently, high-weighted relationship pairs from the external economic semantic consistency weight matrix are used to establish strong semantic connections between the fused entity pairs. A threshold for entity relationship constraints (threshold 0.75) is set based on the weights, and connections below the threshold are filtered or weakened. Finally, a financial entity relationship graph is constructed. The graph structure consists of nodes (entities) and edges (relationships). Node attributes include company name, industry tag, and financial indicators, while edge attributes include relationship type, semantic weight, and valid time interval. The graph is stored using graph database technology (such as Neo4j), supporting multi-dimensional queries, path analysis, and dynamic updates, providing fundamental data support for enterprise risk control and correlation analysis.

[0121] Optionally, step S4 specifically includes:

[0122] Step S41: Perform event timestamp scanning on the entity relationships between nodes in the financial entity relationship graph, identify key event units, and construct an event-driven relationship triggering matrix based on the event type and occurrence frequency of the key event units, thereby generating an event triggering node index table;

[0123] In this embodiment, for all nodes and edges in the financial entity relationship graph, the timestamp information of each entity relationship is first extracted to form time series data. By scanning the event timestamps in the entity relationships one by one, key event units that frequently occur within a specific time interval are identified, such as financial anomaly reports, peak cash flow, and contract changes. The time window size is set to 1 day to 1 week to capture short-term and medium-term key events. Subsequently, based on the category of event units (such as "cash flow" and "asset restructuring") and their frequency of occurrence, an event-driven relationship trigger matrix is ​​established. This matrix has a [E×E] square structure, where E is the number of key event units, and the matrix elements represent the trigger probability and time dependency weight between events. Finally, an event trigger node index table is output based on the matrix analysis results. The index table is stored in tabular form and contains event ID, trigger event ID, trigger weight, and time interval information to support subsequent event-driven analysis.

[0124] Step S42: Based on the event units and associated entity fields in the event trigger node index table, and combined with the business process configuration requirements, define the financial indicator system to obtain the event-driven indicator requirement set;

[0125] In this embodiment, the generated event trigger node index table is used as input, and a financial indicator system is defined according to the specific business process configuration requirements of the enterprise. The enterprise business process is subdivided into multiple modules such as sales, procurement, and capital management. Each module corresponds to a set of key financial indicators, such as sales revenue growth rate, procurement cost control rate, and cash flow indicators. By mapping the associated entity fields (including enterprise account, department identifier, product line, etc.) in the event trigger nodes to the financial indicator definitions, an event-driven indicator requirement set is constructed. The indicator requirement set adopts a list structure, including indicator name, indicator calculation formula, associated entity fields, event trigger node ID, and indicator priority. To ensure that the indicators adapt to dynamic business changes, an indicator update time period parameter (default is daily update) and an indicator threshold warning parameter are set to facilitate subsequent dynamic monitoring and adjustment.

[0126] Step S43: Perform multi-dimensional feature cross-referencing on the entity attributes in the event trigger node index table of the event-driven indicator demand set, establish a correlation matrix between indicators, and perform semantic weighting on the correlation matrix to generate an indicator feature cross-weight matrix.

[0127] In this embodiment, the financial indicators in the event-driven indicator demand set are cross-referenced with the entity attributes in the event trigger node index table using multi-dimensional features. The cross-reference dimensions cover time (divided into hours), event type, indicator category (e.g., profitability indicators, liquidity indicators), and entity attributes (e.g., department, region attributes). Based on this, a correlation matrix between indicators is constructed. The matrix has an [I×I] structure, where I is the total number of indicators, and the element values ​​represent the correlation strength between two indicators under different event and entity attribute backgrounds, ranging from 0 to 1. Subsequently, a semantic weighting mechanism is introduced, using a predefined financial semantic weight table to adjust the weights of the matrix elements, reflecting the weight differences between indicators due to business context. The weighted matrix is ​​the indicator feature cross-weight matrix, stored in a dense matrix format, supporting fast matrix multiplication and feature extraction operations, facilitating the next step of indicator mapping.

[0128] Step S44: Based on the cross-weight matrix of indicator features, construct an index meta-mapping set according to the timestamp of the event unit and the correlation between indicators;

[0129] In this embodiment, an index meta-mapping set is constructed based on the cross-weight matrix of index features and the timestamp information of event units. This mapping set organizes the indicators according to their time series order and correlation to reflect the temporal dependencies and interactions between indicators. Specifically, the index data is first sorted according to the event unit timestamps to ensure temporal continuity. Then, based on the weight information of the index correlation matrix, indicators with strong correlations are paired or grouped to form mapping meta-units. The mapping set is represented in two-dimensional matrix form with a shape of [M×N], where M is the number of mapping elements and N is the index dimension. Each row corresponds to an index element and its associated index list, containing the index ID, correlation strength, and time offset. The mapping set data structure is designed for convenient and rapid retrieval and dynamic adjustment, supporting future expansion and optimization of index orchestration.

[0130] Step S45: Divide the orchestration index meta-mapping set into structured chain segments, and set chain head, chain body and chain tail identifiers for each chain segment to obtain a structured index chain segment set;

[0131] In this embodiment, the orchestration index meta-mapping set is divided into multiple structured chain segments, each representing a group of index elements with temporal continuity and correlation. During division, the mapping elements are segmented based on timestamp continuity and a correlation threshold (set to 0.75) to ensure strong correlation and temporal proximity among the index elements within each segment. Each chain segment is assigned a head (starting index element), a body (intermediate continuous index elements), and a tail (ending index element) identifier to distinguish the temporal hierarchy of the indexes. Chain segments are stored in a linked list format, containing the chain segment ID, its corresponding time interval, the index element IDs of the head, body, and tail, and the corresponding timestamp. This structure facilitates the orderly management and hierarchical processing of index data, providing clear unit boundaries for subsequent verification and transmission.

[0132] Step S46: Combine the pre-set verification mechanism of the enterprise private chain node to perform consensus verification on the structured indicator chain fragment set and generate an encrypted verification financial chain package.

[0133] In this embodiment, a consensus verification process is executed on each structured indicator chain fragment set, based on the enterprise's pre-defined private blockchain node verification mechanism. The private blockchain network includes multiple nodes, each holding a copy of the distributed ledger and relying on consensus rules based on proof-of-stake or authorization verification. When each chain fragment is submitted to the private blockchain network, the node verifies the chain fragment's data structure (including metadata such as the chain head, chain body, chain tail, and timestamp) to ensure data integrity and correct chronological order. After successful verification, the chain fragment generates a chain packet identifier using a cryptographic hash function and is recorded in the block, achieving data immutability and traceability. The final generated cryptographically verified financial chain packet includes a chain packet ID, chain fragment set, timestamp, and verification status. The chain packet storage format conforms to the private blockchain network specification, supporting secure transmission and subsequent auditing.

[0134] Of particular importance is that step S46 specifically includes:

[0135] Step S461: Extract the chain head, chain body, chain tail and associated timestamps from the structured index chain fragment set to construct a chain fragment index cache table;

[0136] In this embodiment, the head, body, and tail information of each chain segment are extracted from the structured indicator chain segment set, along with metadata such as timestamps, indicator IDs, and indicator field indexes, to construct a chain segment index cache table. The chain segment index cache table is designed in tabular form, containing chain segment ID, head ID, body ID sequence, tail ID, chain segment start timestamp, end timestamp, and indicator field index information. During implementation, the timestamp format is set to ISO8601 standardized time (e.g., 2025-05-30T12:00:00Z) to ensure cross-system time consistency. This cache table is stored and managed using a database table structure, supporting high-concurrency queries and multi-dimensional index retrieval, meeting the needs of subsequent verification and index optimization.

[0137] Step S462: Perform timestamp-dimensional integrity verification on the chain segment index cache table, verify the correspondence between the chain head, chain body and chain tail, and generate an integrity verification report;

[0138] In this embodiment, the chain segment index cache table undergoes timestamp-level integrity verification to ensure that the timestamps at the chain head, chain body, and chain tail strictly increase sequentially, avoiding time inversion issues. Time difference analysis is employed to calculate the time difference values ​​of each node within the chain segment, setting a time continuity threshold of no more than 5 minutes to meet the real-time and continuity requirements of financial data. Subsequently, the indicator fields at the chain head, chain body, and chain tail are compared one by one to verify that the indicator fields at the chain head and chain tail can be completely connected within the chain body. If any indicator fields are missing or incorrectly linked, an error log is generated and the error type is marked. Finally, an integrity verification report is generated, with a structure including the chain segment ID, verification status, timestamp continuity test results, field matching status, and a list of error types, providing foundational support for subsequent anomaly removal and consensus verification.

[0139] Step S463: Perform multi-dimensional comparison of the indicator fields of each chain segment in the structured indicator chain segment set, and combine the indicator feature cross-weight matrix and event-driven relationship trigger matrix to perform logical dependency consistency verification and obtain indicator consistency verification report;

[0140] In this embodiment, a multi-dimensional comparison of the indicator fields of each chain segment in the structured indicator chain segment set is performed. Specifically, this includes cross-field cross-analysis of the indicator ID, indicator field index, and corresponding indicator value within the chain segment. An indicator feature cross-weight matrix is ​​introduced to compare the weighted correlation between each indicator field and other related indicator fields. The weight matrix is ​​a [I×I] symmetric matrix, where I is the total number of indicators, and the matrix element values ​​range from 0 to 1. Combined with the event-driven relationship trigger matrix, the strength and dependency between event nodes are analyzed. The dependency coefficients in the relationship matrix (with a threshold of 0.65) are superimposed with the indicator weight matrix to calculate the completeness and consistency of logical dependencies. Inconsistent parts are marked, and an indicator consistency verification report is output. The report includes the chain segment ID, indicator dependency completeness, field matching status, and consistency score, providing a basis for subsequent processing.

[0141] Step S464: Use the integrity verification report and the indicator consistency verification report to remove abnormal chain segments from the structured indicator chain segment set to obtain the chain segment set to be verified;

[0142] In this embodiment, anomaly chain segments are removed from the structured indicator chain segment set using integrity verification reports and indicator consistency verification reports. First, based on the chain segment IDs and error type list marked in the integrity verification report, chain segments with verification statuses of "failed" or "partially passed" are filtered out and cross-filtered with chain segments in the consistency verification report whose consistency score is below 0.6. The filtering results are then sorted according to error priority, with chain segments exhibiting multiple anomalies (such as timestamp errors and indicator dependency errors) being removed first. This results in a set of chain segments to be verified. This set of chain segments to be verified stores the chain segment ID, remaining timestamp information, indicator field index, verification status, etc., and is output in JSON format for easy cross-platform distribution and sharing between nodes.

[0143] Step S465: Combining the preset verification mechanism of the enterprise private chain node, based on the timestamp and indicator dependency relationship in the chain segment index cache table, perform cross-node consensus verification on the set of chain segments to be verified to obtain a consensus verification tag set;

[0144] In this embodiment, a cross-node consensus verification is performed on the set of chain fragments to be verified, based on the timestamps and metric dependencies in the chain fragment index cache table, in conjunction with a pre-defined verification mechanism for enterprise private chain nodes. The enterprise private chain network consists of multiple authorized nodes, each holding a complete copy of the chain fragments and a verification weight rule base. During cross-node consensus verification, each node independently verifies the chain fragments to be verified based on its local metric weight matrix and timestamp index. Nodes compare the verification results for consistency through bidirectional hash signatures. A verification weight threshold of 0.8 is set; if the percentage of nodes passing the verification reaches 75%, the verification is considered successful. Finally, a consensus verification tag set is output, which includes the chain fragment ID, verification status, number of passing nodes, verification hash value, and timestamp, used for the encryption and encapsulation process.

[0145] Step S466: Based on the consensus verification tag set, the set of verified chain fragments to be verified is chained together. The chain head, chain body, and chain tail, along with their timestamps and indicator field index information, are encrypted to generate a financial chain package. A security hash value and digital signature are set to obtain the encrypted verified financial chain package.

[0146] In this embodiment, based on the consensus verification tag set, the set of verified chain segments to be verified is encapsulated in a chain-like manner. Specifically, during encapsulation, the chain head, body, and tail of each chain segment, along with their timestamp information and indicator field index information, are encrypted to generate a financial chain package. Within the chain package, the indicator fields are encrypted using AES256 symmetric encryption technology, and a secure hash value is generated using the SHA-256 hash function to ensure data integrity and immutability. Each chain package is appended with a digital signature field, and the RSA public key system is used for digital signature authentication to ensure data verifiability and traceability. Finally, the generated encrypted verified financial chain package contains a chain package ID, encrypted fields, timestamp index, hash value, digital signature, and verification status, and is uniformly stored in an enterprise-level data security repository, supporting blockchain-style distributed verification.

[0147] Optionally, step S5 specifically includes:

[0148] Step S51: De-identify the head, body, and tail fields in the encrypted verification financial chain packet to generate an anonymized financial chain packet;

[0149] In this embodiment, for the encrypted verification financial chain package, the head, body, and tail fields and their timestamp indexes are first extracted. A de-identification strategy based on the enterprise's internal permission system is applied to perform field-level de-identification processing on fields involving sensitive enterprise information. The de-identification process uses a configured field mapping table to replace fields. Enterprise identification fields (such as "Enterprise ID," "Department Name," and "Financial Account Number") in the head, body, and tail fields are replaced with random codes (e.g., truncated using an 8-bit random number + 3-bit enterprise private key hash, such as "12345678ABC"). Simultaneously, the timestamp, indicator field index information, and verification hash value in the chain package are preserved. The processed chain package is uniformly stored in a distributed file system (e.g., HDFS), and an anonymous identifier (AnonymID) is generated and mapped to the original encrypted verification financial chain package for convenient subsequent event splitting and task scheduling.

[0150] Step S52: Based on the timestamp of the event unit and the chain head identifier of the indicator chain segment, perform event splitting and grouping on the anonymized financial chain package to generate a federated interactive computing task set;

[0151] In this embodiment, based on the timestamp information and chain head identifier field in the anonymized financial chain package, the chain package is split into events according to the timestamp dimension of the event unit. For each chain head identifier, the corresponding timestamp range is first read (e.g., from the start timestamp of the chain head to the end timestamp of the chain tail). Then, according to the event window size set internally by the enterprise (e.g., 10 minutes), the chain package is split into multiple event unit sets. Each event unit set contains a chain package ID, a chain head ID, a list of chain body IDs, a chain tail ID, and an event time range. Subsequently, the events are grouped according to the timestamp order of the event units to form a federated interactive computing task set. The task set is represented in JSON structure, including fields such as event unit ID, chain segment index, time range, indicator field index, and task priority, which facilitates distribution to multiple participating nodes to perform federated interactive computing.

[0152] Step S53: Distribute the federated interactive computing task set to the preset multi-party participating nodes, and set the task execution identifier and timestamp index on each node to obtain the federated interactive computing framework;

[0153] In this embodiment, during the distribution of federated interactive computing task sets, the enterprise deploys a multi-party participating node management system in a private cloud environment. This system adopts a layered distributed architecture, mainly including a task scheduling layer, a node management layer, and a data distribution layer. The task scheduling layer is responsible for receiving the federated interactive computing task sets generated by the central node and distributing tasks based on task ID, event unit ID, and priority. The node management layer is responsible for managing the metadata of all participating nodes, including node ID, node running status, computing power information, and availability tags. Node status data is stored in a distributed NoSQL database (such as Cassandra). The data distribution layer distributes task data to each participating node through a secure transmission protocol (TLS 1.3), uses message queues (such as Kafka) for asynchronous task delivery and status monitoring, and supports task retry and failover mechanisms to ensure high availability and secure execution of federated interactive computing tasks. Through this architecture, task distribution can flexibly adapt to node computing resources and task priorities, realizing a secure, controllable, and scalable federated computing system within the enterprise.

[0154] Step S54: Use the federated interactive computing framework to perform federated interactive computing on the indicator chain segments corresponding to each event unit, calculate the global consistency and feature distribution of the indicators, and thus generate a federated interactive computing result set.

[0155] In this embodiment, relying on the federated interactive computing framework, cross-node federated interactive computing is performed on the indicator chain segments corresponding to each event unit to calculate the global consistency and feature distribution of the indicators. The federated interactive computing relies on a preset indicator feature cross-weight matrix (size N×N, where N is the total number of indicators) and an event-driven relationship triggering matrix (size M×M, where M is the total number of event units). Each node calculates the local statistical characteristics (mean, variance, quantiles, etc.) and field distribution (histogram form) of the indicator fields based on local chain packet data. Subsequently, the local calculation results are aggregated to the central node through an encrypted communication protocol (e.g., TLS 1.3). The central node performs indicator consistency fusion, calculates the global mean, global variance, and cross-node feature deviation values ​​of the indicators, and outputs the federated interactive computing result set. The result set is stored in CSV format, including the event unit ID, indicator fields, global consistency score, and global feature distribution matrix.

[0156] Step S55: Summarize the federated interactive computation result set, perform global sorting and feature fusion according to the orchestration index meta-mapping set, and obtain a global federated interactive computation result set;

[0157] In this embodiment, the federated interaction computation result sets reported by each node are aggregated at the central node. The central node performs global sorting based on the indicator field indexes in the preset orchestration indicator meta-mapping set, using global consistency scores and feature distribution matrices. The sorting strategy is to arrange the indicators in ascending order of global variance to prioritize the analysis of stable indicators. Subsequently, the sorted indicators undergo feature fusion using a weighted average strategy. The fusion weights are jointly determined by the indicator feature cross-weight matrix and the event-driven relationship trigger matrix (example: fusion weight = 0.7 × cross-weight + 0.3 × relationship weight), ensuring that the fusion results take into account both indicator relevance and event dependence. Finally, a global federated interaction computation result set is output, including indicator ID, fusion weight, global consistency score, and timestamp index information.

[0158] Step S56: Based on the global federated interactive calculation result set, and combined with the indicator logic and event-driven relationships in the enterprise's internal financial entity set, construct a programming logic constraint model;

[0159] In this embodiment, a programming logic constraint model is constructed based on the indicator logic and event-driven relationships in the global federated interactive computation result set and the set of internal financial entities of the enterprise. This model includes an event-driven relationship sub-model (using event unit ID as the primary key and associating it with an event-driven relationship trigger matrix), an indicator logic sub-model (using indicator ID as the primary key and referencing the indicator feature cross-weight matrix and global consistency score), and an indicator dependency table (fields include dependency ID, dependency type, and dependency strength). The constraint model adopts a graph database structure (such as Neo4j), with model nodes containing event unit nodes, indicator nodes, and dependency relationship nodes. A threshold parameter (e.g., dependency strength ≥ 0.6) is set for each dependency relationship as a judgment condition. Through this model, multi-dimensional constraint reasoning can be performed on the global federated interactive computation result set, achieving semantic verification and logical constraint control of the results.

[0160] Step S57: Using the programming logic constraint model, the global federated interactive computation result set is transformed into programming units, generating a pre-built logic execution unit set and a structured configuration file. The pre-built logic execution unit set and its structured configuration file are then uploaded to the enterprise private cloud platform to execute the platform building task.

[0161] In this embodiment, the global federated interactive computation result set is transformed using the constructed programming logic constraint model. First, each indicator field is divided into programming units according to the dependencies of the logic constraint model. Each unit includes an event unit ID, indicator ID, indicator logical relationship, and field index information. Then, a structured configuration file (YAML format) is configured for each programming unit. The file includes input fields, output fields, dependency fields, execution order, logical relationships, and security policies. An execution ID and timestamp index are set for each unit to support task scheduling and backtracking. Finally, the pre-built logical execution unit set and its structured configuration file are uploaded to the enterprise's private cloud platform via a secure transmission protocol (such as SFTP) for the enterprise to build an execution environment and perform business logic verification, achieving intelligent deployment and operation across nodes and systems.

[0162] Optionally, this specification also provides an enterprise financial data analysis and management cloud platform system, on which a computer program is stored, the computer program being used to execute the enterprise financial data analysis and management cloud platform programming method described above, including:

[0163] The data preprocessing module is used to collect financial data from multiple sources of enterprises, and to parse, preclassify, and compress the financial data to obtain a temporal data collection event stream.

[0164] The semantic feature analysis module is used to perform adaptive semantic feature extraction based on temporal data acquisition event streams to obtain an adaptive feature extraction matrix; context-sensitive semantic alignment is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor;

[0165] The entity relationship analysis module is used to construct a set of internal financial entities of an enterprise based on a high-dimensional semantic tensor, and to impose semantic constraints on the set of internal financial entities by external economic entities to obtain a financial entity relationship graph.

[0166] The consensus verification module is used to orchestrate event-driven indicators for the logical relationships between nodes in the financial entity relationship graph, resulting in an orchestration indicator meta-mapping set; the orchestration indicator meta-mapping set is then encapsulated in a structured chain and subjected to consensus verification to obtain an encrypted verification financial chain package.

[0167] The programming logic analysis module is used to anonymize the encrypted verification financial chain package, perform federated interactive computation on the anonymization result, and obtain a federated interactive computation result set. Based on the federated interactive computation result set, programming logic constraints are applied to obtain a pre-built logic execution unit set, which is then uploaded to the enterprise private cloud platform to execute the platform construction task.

[0168] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0169] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A programming method for an enterprise financial data analysis and management cloud platform, characterized in that, Includes the following steps: Step S1: Collect financial data from multiple sources of enterprises, and parse, pre-classify, and compress the financial data to obtain a temporal data collection event stream; Step S2: Perform adaptive semantic feature extraction based on the temporal data acquisition event stream to obtain the adaptive feature extraction matrix; Context-sensitive semantic alignment is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor; Step S3: Construct a set of internal financial entities based on the high-dimensional semantic tensor, and apply semantic constraints on the set of internal financial entities to external economic entities to obtain a financial entity relationship graph; the semantic constraints on external economic entities in step S3 are specifically as follows: External economic data streams are collected by accessing the data interface of an external economic analysis platform; the external economic data streams are timestamped and linked based on the fields of the enterprise's internal financial entity set to obtain a pre-linked set of external economic data; By utilizing the fields and tags of the enterprise's internal financial entity set, and based on the financial domain ontology lexicon, semantic mapping is performed on the pre-association set of external economic data to obtain the external economic semantic mapping matrix. External economic entities are extracted from the external economic semantic mapping matrix, and the extracted results are labeled with entity attributes and entity relationships by combining the context dependency graph to obtain the external economic entity label set. The entity attributes in the external economic entity annotation set are cross-referenced in multiple dimensions. The entity labels and field attributes in the enterprise's internal financial entity set are combined to establish semantic dependencies between entities based on the cross-reference results, and an external economic entity relationship matrix is ​​generated. Perform semantic consistency checks on the relationship pairs in the external economic entity relationship matrix to generate an external economic semantic consistency weight matrix. By combining the set of internal financial entities and the external economic semantic consistency weight matrix, entity fusion and relation constraint calculations are performed to generate a financial entity relation graph; Step S4: Perform event-driven index orchestration on the logical relationships between nodes in the financial entity relationship graph to obtain an orchestration index meta-mapping set; encapsulate the orchestration index meta-mapping set into a structured chain and perform consensus verification to obtain an encrypted verification financial chain package; Step S4 specifically includes: Step S41: Perform event timestamp scanning on the entity relationships between nodes in the financial entity relationship graph, identify key event units, and construct an event-driven relationship triggering matrix based on the event type and occurrence frequency of the key event units, thereby generating an event triggering node index table; Step S42: Based on the event units and associated entity fields in the event trigger node index table, and combined with the business process configuration requirements, define the financial indicator system to obtain the event-driven indicator requirement set; Step S43: Perform multi-dimensional feature cross-referencing on the entity attributes in the event trigger node index table of the event-driven indicator demand set, establish a correlation matrix between indicators, and perform semantic weighting on the correlation matrix to generate an indicator feature cross-weight matrix. Step S44: Based on the cross-weight matrix of indicator features, construct an index meta-mapping set according to the timestamp of the event unit and the correlation between indicators; Step S45: Divide the orchestration index meta-mapping set into structured chain segments, and set chain head, chain body and chain tail identifiers for each chain segment to obtain a structured index chain segment set; Step S46: Combine the pre-set verification mechanism of the enterprise private chain node to perform consensus verification on the structured indicator chain fragment set and generate an encrypted verification financial chain package; Step S5: Anonymize the encrypted verification financial chain package and perform federated interactive computation on the anonymization result to obtain a federated interactive computation result set; perform programming logic constraints based on the federated interactive computation result set to obtain a pre-built logic execution unit set, and upload the pre-built logic execution unit set to the enterprise private cloud platform to execute the platform construction task.

2. The programming method for the enterprise financial data analysis and management cloud platform according to claim 1, characterized in that, Step S1 is as follows: Step S11: Collect multi-source corporate financial data by connecting to the company's internal database and business systems; Step S12: Timestamp align the financial data of multiple enterprises and add index labels to each aligned data to obtain time-indexed financial data; Step S13: Perform pre-parsing and preliminary semantic annotation on the time-indexed financial data to obtain semantically annotated data; Step S14: Perform multi-level data pre-classification based on semantically labeled data to obtain a preliminary financial data classification index table; Step S15: Compress and encode the data in the preliminary financial data classification index table according to the field type to obtain a compressed and encoded data stream; Step S16: Perform event-based splitting on the compressed encoded data stream, dividing each compressed encoded data stream into event units according to the data timestamp to obtain the temporal data acquisition event stream.

3. The programming method for the enterprise financial data analysis and management cloud platform according to claim 2, characterized in that, Step S14 is as follows: Step S141: Obtain the enterprise's internal financial account structure and business process structure by connecting to the enterprise's business system; Step S142: Perform financial topology analysis based on the enterprise's internal financial account structure and business process structure to obtain the financial topology, and construct a semantic tag relationship mapping table using the financial semantic relationships in the financial topology. Step S143: Group the semantically labeled data into financial topics based on the semantic label relationship mapping table to obtain a preliminary set of financial data topics; Step S144: Extract financial indicators for each theme based on the preliminary financial data theme set, and construct a hierarchical indicator system based on the business process configuration requirements of the business process structure; Step S145: Align the hierarchical indicator system with the preliminary financial data subject set to generate an indicator mapping matrix; Multi-level cross-validation of the indicator mapping matrix is ​​performed to identify and correct conflicting data, resulting in a valid indicator mapping matrix. Step S146: Combining the thematic hierarchy of the preliminary financial data thematic set, the verification indicator mapping matrix is ​​extracted and sorted hierarchically to obtain the preliminary financial data classification index table.

4. The programming method for the enterprise financial data analysis and management cloud platform according to claim 2, characterized in that, Step S16 is as follows: Step S161: Standardize the timestamps of the compressed encoded data stream to obtain a timestamp-standardized data stream; Step S162: Perform time continuity verification on the timestamp-standardized data stream, detect and mark missing points, duplicate points and abrupt jumps in the data stream, and obtain a list of time continuity verification results; Step S163: Perform time gap interpolation repair based on the time continuity verification result list to obtain the time gap repair data stream; Step S164: Based on the timestamps and corresponding semantic tags of the time gap repair data stream, extract the event boundary points in the time gap repair data stream, and determine the event demarcation conditions based on the business logic structure of the financial topology to obtain the event boundary point index table. Step S165: Divide the time gap repair data stream into event units using the event boundary point index table to obtain the event unit set; Step S166: Index and label the event unit set and reorder it to obtain the temporal data acquisition event stream.

5. The programming method for the enterprise financial data analysis and management cloud platform according to claim 1, characterized in that, The adaptive semantic feature extraction in step S2 is specifically as follows: The time window length is set to 10 seconds. The temporal data acquisition event stream is segmented and sliced ​​according to the fixed time window length to obtain a time series slice set. The threshold for the number of principal components is set to 5. The principal component fields of the compressed coded data in the time series slice set are decoded, and the data are hierarchically reorganized according to the decoded field attributes to obtain a multi-level field matrix. Within a fixed time window, the context dependency relationship of each field in the multi-level field matrix is ​​modeled using the field attributes and event timestamps in the multi-level field matrix to obtain the context feature weight matrix. Dynamic semantic aggregation is performed on the multi-level field matrix based on the context feature weight matrix and the labels of the event units. The semantic cross-fusion window size is set to 3, and the features of the event units are cross-fused in the timestamp dimension and the field dimension to obtain the dynamic semantic feature matrix. Local outlier identification is performed based on the dynamic semantic feature matrix, and the identification results are adaptively corrected by weights to obtain an adaptive feature extraction matrix.

6. The programming method for the enterprise financial data analysis and management cloud platform according to claim 1, characterized in that, The context-sensitive semantic alignment in step S2 specifically involves: For the fields in the adaptive feature extraction matrix, the context semantic neighborhood window is divided according to the timestamp of the event unit and the field attribute to obtain the semantic neighborhood index set; The semantic similarity score of each field in different contextual semantic neighborhood windows is calculated based on the semantic domain index set to obtain the contextual semantic similarity matrix; By combining the semantic neighborhood index set and the sensitive word dictionary of the pre-set financial domain ontology lexicon, sensitive fields are marked in the context semantic similarity matrix to obtain a sensitive semantic tag set; Based on the field weights and weight time change trends in the context semantic neighborhood window, the similarity scores of the context semantic similarity matrix are dynamically weighted, and combined with the semantic sensitivity of the sensitive semantic tag set, a context semantic weight matrix is ​​generated. Construct a context dependency graph using the context semantic weight matrix and the timestamps of event units; By combining the context dependency graph and the context semantic weight matrix, sensitive semantic alignment processing is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor.

7. The programming method for the enterprise financial data analysis and management cloud platform according to claim 1, characterized in that, Step S5 is as follows: Step S51: De-identify the head, body, and tail fields in the encrypted verification financial chain packet to generate an anonymized financial chain packet; Step S52: Based on the timestamp of the event unit and the chain head identifier of the indicator chain segment, perform event splitting and grouping on the anonymized financial chain package to generate a federated interactive computing task set; Step S53: Distribute the federated interactive computing task set to the preset multi-party participating nodes, and set the task execution identifier and timestamp index on each node to obtain the federated interactive computing framework; Step S54: Use the federated interactive computing framework to perform federated interactive computing on the indicator chain segments corresponding to each event unit, calculate the global consistency and feature distribution of the indicators, and thus generate a federated interactive computing result set. Step S55: Summarize the federated interactive computation result set, perform global sorting and feature fusion according to the orchestration index meta-mapping set, and obtain a global federated interactive computation result set; Step S56: Based on the global federated interactive calculation result set, and combined with the indicator logic and event-driven relationships in the enterprise's internal financial entity set, construct a programming logic constraint model; Step S57: Using the programming logic constraint model, the global federated interactive computation result set is transformed into programming units, generating a pre-built logic execution unit set and a structured configuration file. The pre-built logic execution unit set and its structured configuration file are then uploaded to the enterprise private cloud platform to execute the platform building task.

8. A cloud platform system for enterprise financial data analysis and management, characterized in that, It stores a computer program, which is used to execute the enterprise financial data analysis and management cloud platform programming method as described in claim 1, including: The data preprocessing module is used to collect financial data from multiple sources of enterprises, and to parse, preclassify, and compress the financial data to obtain a temporal data collection event stream. The semantic feature analysis module is used to perform adaptive semantic feature extraction based on temporal data acquisition event streams to obtain an adaptive feature extraction matrix; context-sensitive semantic alignment is performed on the adaptive feature extraction matrix to obtain a high-dimensional semantic tensor; The entity relationship analysis module is used to construct a set of internal financial entities of an enterprise based on a high-dimensional semantic tensor, and to impose semantic constraints on the set of internal financial entities by external economic entities to obtain a financial entity relationship graph. The consensus verification module is used to orchestrate event-driven indicators for the logical relationships between nodes in the financial entity relationship graph, resulting in an orchestration indicator meta-mapping set; the orchestration indicator meta-mapping set is then encapsulated in a structured chain and subjected to consensus verification to obtain an encrypted verification financial chain package. The programming logic analysis module is used to anonymize the encrypted verification financial chain package, perform federated interactive computation on the anonymization result, and obtain a federated interactive computation result set. Based on the federated interactive computation result set, programming logic constraints are applied to obtain a pre-built logic execution unit set, which is then uploaded to the enterprise private cloud platform to execute the platform construction task.

Images